Service mesh is regularly pitched as the silver bullet for developing services, but in reality, it only addresses specific operations, security and traffic policies, not every possible aspect.
As enterprises move away from monoliths to microservices and cloud-native applications, it’s vital to have secure and easy to implement integrations that free up developer time for more critical work. Service mesh makes it unnecessary to re-implement infrastructure logic (e.g. routing, logging, etc.) inside the microservice, thereby keeping it truly agile to change.
Thought service mesh was a cure all for your infrastructure woes? Before you invest, I’ve dived into what is actually true about the technology and what is simply hype, helping you determine whether service mesh is a fit for your development cycle or one you should pass on for now.
Fiction: You don’t have to change anything in your microservices to implement service mesh
While service mesh allows enterprises to retrofit their applications with an infrastructure layer without rewriting the entire code, there are some changes you’ll need to make, especially if you didn’t build the applications with cloud-native design considerations in mind.
Service mesh doesn’t magically make an application cloud-native — it only supports
infrastructure to help manage microservices and won’t solve a poor microservices topology. If the domain boundaries are incorrectly defined, or if the services are too chatty, stateful or non-12 factor compliant, you will end up with more problems than what a service mesh could solve.
The onus is still on the developer to ensure microservices are built using the right development principles in the first place, following modern cloud-native, API management and DevOps CI/CD best practices. Resist the urge to re-build commodity infrastructure components (logging and monitoring) and leverage commercial or commodity OSS projects instead of having each service team build it from scratch in the name of autonomy.
Overall, service mesh is like having the best dashboard and controls in a car (e.g. having a “Sports” mode). However, the service mesh won’t be leveraged if the engine itself (i.e. the microservice it is managing) isn’t built for it. To get the best outcomes, the microservice design needs to be done right, and it likely means you’ll need to modify your already existing code.
Fact: Service mesh can’t replace your API management needs
Service mesh, as well as orchestration technologies like Kubernetes, could replace some API management functionality, but not every API management need.
The API gateway is the main area of overlap between API management and service mesh,
which introduced the concept of ingress gateways. The API gateway and service mesh both govern security (access control and authentication), traffic management (rate limiting and throttling) and routing to APIs.
This overlap is a problem many developers are struggling with. Even Google had to work on separating the concerns between its Apigee API management and Istio service mesh,
relegating the runtime to the ingress gateway, but routing all policy and key management back to Apigee via Istio Mixer adapters. Over time, expect tighter integrations and more overlaps as these technologies continue to evolve.
Fiction: Service mesh is consistent across its deployment
There is a lack of standardization across service mesh implementation, with some vendors creating their own meshes and opinionated distros, though there are some headways in standardization. For example, Microsoft and HashiCorp are working on a service mesh interface for the industry.
With service mesh you also run the risk of cloud vendors locking you into their service mesh. This runs counter to the initial concept of service mesh, which was for it to function with multi-cloud, but hopefully standardization will enable service mesh to truly support multi-cloud environments.
Fact: Service mesh requires deep knowledge of underlying tech to implement
Though service mesh will ultimately make microservice implementation a breeze, it still requires deep knowledge of the underlying tech like Kubernetes, Docker, Istio etc.
For many companies, it’s difficult to find and cultivate the right skill set. Without the right knowledge and expertise, you’ll end up with a poorly implemented service mesh. Service mesh is still a nascent technology — it’s continuously developing and developing fast. As an example, the above-mentioned Mixer adapters are already deprecated.
This “work in progress” can potentially slow down your implementation velocity in the long run, especially as developers struggle to stay up to date with all the technologies that a service mesh is built on, while trying to deliver business value.
Overall, service mesh is all about improving time to value and ease of development, like what middleware used to do, but leaping into the tech without understanding it will do more harm than good.
More important than implementing the latest technology is making pragmatic decisions on what’s going to be microservices vs. mini service vs. a major capability that’s simply exposed via a service interface via a facade. Don’t try to boil the ocean.
In many cases, API management and an effective API strategy for your microservices is what your enterprise should really be focused on. And in these cases, service mesh is simply overkill.
