We have discussed API gateway solutions extensively in relation to the success of the MSA paradigm. We all know that in order to increase the resiliency of microservices, the service mesh solutions are being pampered. And in this section, we are to discuss the key differences between API gateways and service meshes.
Firstly, the API gateway, as explained in the preceding section, the key objective of using an API gateway is to express and expose microservices to the outside world. With the attachment of API management modules, APIs are managed well. API data is captured and subjected to a variety of investigations to produce insights to steer API gateways in the right direction:
- API services call the downstream microservices that can be atomic and composite. The noteworthy capability of API gateways is to fuse multiple downstream services into something that is useful for the requesting services. That is, services are blended as per the stated requirements to produce process-aware, mission-critical, and composite services.
- API gateways also come with inbuilt support for service discovery, analytics, and security. The observability capability for capturing various metrics along with monitoring, distributed logging, and distributed tracing is the key differentiator for gateway solutions.
- API gateways closely work with several other software solutions, such as API management, marketplace/store, and portals in order to be comprehensive for the microservice era.
Secondly, service mesh—this is relatively a new solution type and approach for providing the resiliency characteristic, which is becoming an important one for microservice-based applications. As we all know, services ought to interact with one another in order to realize bigger and better business-scale services. When services talk to one another, several things can go wrong. In order to guarantee service communication resiliency, the IT industry is leaning towards embracing the new concept of a service mesh, which is a kind of network and communication infrastructure to ensure service resiliency. Service mesh implementations have embedded resiliency-enablement patterns such as circuit breaker, retry, timeout, and throttling/rate limiting. There are service mesh solutions such as Istio, Linkered, and Conduit. Advanced functionalities such as service discovery and observability are being incorporated into these solutions. The functionalities of API gateways and service mesh solutions are clearly demarcated. It is also possible to use both of them in a production environment.
The service mesh is used alongside most other service implementations as a sidecar. A service mesh provides a stream of utility and horizontal functionalities for enabling service resiliency.
In conclusion, API gateways facilitate API communications between a client application and a server application. Also, microservices within an application can be integrated through the API gateway solution. An API gateway operating at layer 7 (HTTP) enables internal as well as external communication. Other noteworthy services include user authentication, throttling/rate limiting, transformations, logging, and so on.
Service mesh solutions such as Istio, Linkered, and Conduit are for enabling service communication resiliency. That is, they mainly focus on routing internal communications. A service mesh operates primarily at layer 4 (TCP). All the resiliency and reliability design patterns such as circuit breakers, timeouts, retries, and health checks are intrinsically implemented and incorporated into service mesh solutions.