¿Cómo se usan puertas de enlace y proxies en microservicios?

I agree, and would like to add insight about some other functionalities. Some other tasks they perform: - Request de-duplication - SSL termination - Rate Limiting

Proxies and gateways are also helpful when used internally, within bigger system. This allows better security and in the event of a breach, provides natural containment of the "infection".

To add more ,we have been using API Gateways typically handle north-south traffic i.e., traffic entering and leaving the system, while there are service meshes like Istio with their proxies are more designed for east-west traffic i.e., the traffic between your services inside the system. We have this interesting thought in our enterprise or sometime now we have been thinking if we can replace API Gateway entirely with Service Mesh . Its not a easy choice yet and currently we are working with hybrid approach.

1. Try to decouple different functions (e.g. use different services for authentication and load balancing). 2. A good pattern (especially when deploying your services to a public cloud) is for each (micro)service to perform its own authorization. This is a requirement for secure systems design. 3. Unless you can guarantee the security of the communication channel between your services (i.e. both services are running in the same security context not accessible from external services or the Internet), the communications must be secured (e.g. via TLS encryption and service authentication).

Gateways and proxies help you separate out the business logic and cross-cutting concerns and allow you to adopt some readily made solutions that make your service better - faster, more reliable and cheaper to operate, etc. When done right, it helps you more quickly adapt to changing business needs without spread yourself too thin on difficult and specialized problems. Think hard on what is the core competencies for your engineering team to own, starting from the business logic and expand outwards. You still need to invest time to understand various solutions, their feature sets and trade offs. But it's typically time better spent comparing to rolling your own (typically far less than best in class) solutions.

Client-facing gateways are also commonly used to inject tracing data to the requests for better monitoring and bottleneck identification.

Performing authentication and authorisation in the gateway proxy enables more dynamic access policies, such that a request made by user A doesn't even have access to resources owned by user B.

As mentioned above, api gateway may do the authorization checks but if you need application-specific, extensive checks you should consider doing the checks in the microservice layer so your api gateway will be free of the specific business knowledge.

Using proxies for interacting with external services can simplify the processes and security for the developers building your application microservices. Some third party services (especially legacy systems) can often have weird authentication processes or have unreliable responses. That can all be abstracted away from the developers with a well designed proxy gateway. From a security perspective this also means that you only have to make credentials available for this single proxy service, instead of every microservice that needs to make requests to that third party. This reduces the chance of credential misuse and simplifies the deployment and management of those credentials.

Here's how we can use proxies for external services: Service-to-Service Communication: One of the common uses of proxies is to manage communication between your services and external services. In this case, the proxy acts as an intermediary, accepting requests from your service, forwarding them to the external service, and then returning the response. This abstraction allows your services to be decoupled from the specifics of the external service, simplifying integration and reducing coupling.

Proxies can also monitor and log the traffic to and from the external service. This information can provide valuable insights into how your services interact with the external service, helping identify issues or opportunities for optimization.

One popular proxy that can handle these tasks is Envoy, which is often used in conjunction with Istio. Envoy can be configured to automatically discover and communicate with external services, manage traffic, apply security measures, and more. Other options include Nginx, HAProxy, and Traefik.

Orchestrating proxies can be useful for preparing data and offloading data retention when employing designs with pure stateless microservices pattern. This will also reduce the overall complexity of your architecture, reduce the number of network requests, allow to make more efficient use of database engines, and streamline business process recognition and monitoring.

It feels like this section should be a bullet list, not an 83 word sentence that feels like it never ends. If you're using an API solution like GraphQL, your internal proxy can also be use to federate and enable discovery of your microservice APIs. This acts as a single point of reference instead of a developer having to go through each microservice to find the endpoint or query structure that they need.

i would highly suggest to make this section more structured , bullets. currently it looks so messy to add more meaningful content

For non cloud based services, or self managed Gateways or proxies - it is very critical to get the deployment models right. Gateways by being the single entry point for clients, if not deployed and configured right, can end up being the single point of failure.

Gateways excel in API composition by streamlining backend services into unified endpoints. However, they may foster tight coupling, constraining system flexibility. Proxies stand out in caching and detailed traffic control, enhancing overall performance. Yet, they can be vulnerable to Replay Attacks, making them a security concern. Both elements filter traffic and enforce security rules but can become system failure points. An extra layer adds latency and computational overhead. Moreover, proxies offer the advantage of logging data, valuable for incident analysis. The trade-off is increased system complexity due to extra configuration and maintenance, along with potential microservice dependencies on these intermediary features.

One fail mode to watch out for (among may others): Have you created unintentional functional dependency on these gateway? They are often meant to be transparent, but sometimes subtle dependencies can be created, for example, the gateway may add certain header to the requests where the business logic would later take a dependency on without knowing it came from the proxy not from the client. Or a backend workflow can end up relying on the logging / traces from the gateway for billing and other important business functions. Make sure to have visibility on how these added layers perform (do not blindly trust the brochure) and can test your system's correctness with and without these added layers.

Some techniques you might want to use with proxies are automated service discovery, automated service (re)configuration, semantic service descriptors, API call and response validation, telemetry and Service Oriented Architecture (2.0 or newer).