English | EN 
Having witnessed and supported several organizations in their journey, it has become clear to me that it is sometimes more challenging than originally anticipated to realize the full advantages of a Microservices architecture. A Microservice architecture promises to enable faster delivery (… well aligned with agile principles), improved testability, enable more capability to do granular upgrades, be more scalable, etc., which is why so many organizations are either trying to break apart their Monolithic applications or start new projects with a Microservices architecture.
Some of the key advantages offered by Microservices is simply due to their very nature, as small bits of functionality. Challenges start to reveal themselves as the Microservices footprint begins to expand (horizontally or vertically). For instance, when trying to implement security, standards, discovery, observability, management, logging etc., it’s hard to keep your Microservices, well, “Micro” (…at least it’s hard without an externalized solution to these challenges). In fact, I have seen some clients work to document engineering standards to ensure core capabilities get built into every Microservice.
This is where a Service Mesh shines. As illustrated below, service meshes use a Sidecar Proxy (e.g., Linkerd2-prox, envoy, etc.) to intercept traffic in and out or your microservice workloads, allowing you to keep your microservice functionality/business logic small.
There are many different types of mesh providers all with different capabilities and different levels of complexity (e.g., Istio, Linkerd, AWS App Mesh, Open Service Mesh (OSM) and Nginx Service Mesh). Generally, however, service meshes tend to offer capabilities related to routing, discovery, security, and fine-grained access policies, enabling zero trust, decoupling operations such as monitoring and tracking container/service traffic. These capabilities are managed in the control plane and injected into the service via the side-car proxy, thus allowing your service logic to remain small. Also, the proxy is the middleman decoupling for service-to-service communication.
In addition, Service Meshes can enable efficiencies in other parts of the infrastructure. For example, interesting use cases include:
- leverage service mesh to prevent load-balance proliferation in order to enable routing and discovery of services.
- More easily enable various cluster isolation patterns (e.g. Physical Isolation, Logical Isolation by environment or domain)
- Some Service Meshes allow for the ability to control the network policy of east-west traffic within the data plane
It is wise to balance the complexity incurred with the complexity saved when making decisions regarding the use of a service mesh. Some organizations get anxious about the upfront work to establish the strategy and implement a Service Mesh.
Certainly, service meshes are not perfect solutions and I am continuing to learn more and more about their strengths and weaknesses, which will surely continue to evolve. It can, however, save a lot of pain and management in the long run. We all know environments and requirements will grow. Therefore, it is important that we invest in a solution that will offer us flexibility to meet that growth, while minimizing technical debt and keeping our microservices focused on their specific task.
