In a world full of microservices, two buzzwords are increasingly common — “API Management” and “Service Mesh.” We asked ourselves which challenges do the two approaches help with and whether it is an “either/or”? To do this, we have scrutinized both of them to see what is really behind them. Our opinion: An “and” can definitely make sense. But let's look at it together.
Service mesh to manage a service network
Software development in agile teams works great. Through independence, we achieve flexibility and speed and can therefore provide new functions quickly. First of all, this meets the most important criteria for successful development teams. The basic requirement for this is that we divide expertise into manageable units and provide them in the form of small, isolated systems (so-called microservices or self-contained systems). If you look at the entire IT landscape of larger companies, you will now very often find a lot of distributed microservices, which are managed by many agile teams.
All responsible development teams face similar challenges. In addition to implementing the actual business requirements, distributed architectures bring with them an ever increasing number of operational and non-functional requirements. In doing so, the teams must address these issues, among others:
- What can I do if network stability is poor?
- How can I communicate securely over the network?
- How do I quickly identify the causes of faults in the distributed architecture?
- How can I deploy new releases frequently without having a negative impact on other microservices?
The answers to these questions are often characterized by individual solutions, which are part of the logic of microservices. This is where service meshes come in. They ensure that development teams can concentrate more on the actual technical requirements again. They do this by managing and monitoring communication between the various microservices.
A proxy is deployed as a so-called sidecar with every microservice. All incoming and outgoing network communication is then carried out via the proxy. With every call, rule-based additional functions can now be fulfilled by the proxy. This means that new rules can be applied to individual services or to the entire service network at runtime, regardless of the actual application.
A service mesh can be used for many functions
In addition to numerous monitoring and tracing functions, which ensure transparency in a distributed system and thus also facilitate error analysis, service meshes also offer other useful functions:
- Security: Mutual SSL/TLS enables encryption, authentication and authorization of network access. The necessary certificates are regularly exchanged automatically. In this way, entire networks can be secured using a very simple mechanism.
- Routing: Canary releases make it possible to deploy new microservice versions in parallel and split traffic between the two versions using routing rules, so that only a defined portion of the requests go to the new version. In this way, the risk of introducing new versions can be reduced as only a portion of the users/system are affected by possible errors.
- Resilience: Circuit breakers, retries and timeouts can be used to define error situations and respond to rule-based services so that the individual service remains functional even in the event of failures and failures of other services. For example, if a system is called incorrectly multiple times, a backup (circuit breaker) can ensure that no further calls are made and that a fallback takes effect instead. If a system does not respond at all, timeouts can result in a defined error response and non-blocking processes.
- Fault injection: With this function, the fault resistance (and thus the resilience measures taken) of a microservice or entire microservice systems can be tested. For example, delays can be used to delay the response time of services in order to simulate a high utilization scenario. Aborts can be used to simulate complete failures.
APIs have been around for a long time — what is the difference with a service?
APIs have become increasingly popular over the last 10 years. Today, we see the use of APIs in many areas of our lives, such as connected homes and mobile applications. In addition, they are a core part of digital transformation for many companies to provide access to their own data and business functions. In general, they are therefore used (like services) to enable integration or access to certain data and functions.
What is important here is that, in contrast to services, APIs always have a defined technical meaning and are relevant beyond the individual system context. They encapsulate self-contained, meaningful technical logic, which could potentially be relevant for other callers. That's why we often talk about “API product” to underline the product nature of APIs. Products could also be offered on a marketplace for other interested parties. This is not always the case with services. These are often point-to-point connections or, in some cases, technical services that only make sense in the context of a larger microservice application.
Basically, in a service mesh, every service could also offer an API for comprehensive use. In the image below, this is the case for Product Service. Products could not only be relevant for online shop applications, but also, for example, for comparison portals that want to access them from outside.
Why do I need API Management?
Let's imagine the API as a product: What would be fundamentally necessary to market or sell this product? The product should:
- be quickly found via a catalog or marketplace,
- be clearly and comprehensibly documented
- contain clear sales conditions and price information, and
- are made available to the buyer after the purchase process.
For the further development of the product, it is also important to understand how and by which user groups the product is bought and used.
It is precisely these features that API management platforms offer. APIs are therefore managed centrally in order to:
- to be able to offer and describe for use by consumers, and
- to enable developers to use/purchase in the form of a subscription in a self-service approach
- to control, log and analyze access by authorized consumers.
Service mesh or API management or both?
The main difference between the two approaches is that service meshes are used more to technically manage network traffic between services, while API management refers more to technical aspects of managing APIs and their consumers.
However, both approaches can also complement each other very well, as there are some similarities:
- Both solutions are based on the simple concept of connecting proxies to network communication.
- Both solutions are able to map security and access controls.
It therefore makes sense to integrate the concept of service meshes with API management platforms. This makes it possible to cover the full range of functions should this be necessary. API management policies, such as authentication (e.g. through API key validation), rate limiting, etc., can thus be deployed and managed by the API management platform without having to manage an additional proxy. This is already supported by numerous API management platform providers, such as Apigee and WSO2, to name just a few.
The main differences are detailed again below:
