7 min to read
Service Mesh is here to stay
The next layer in your microservices architectures
In this post we will explore the new native layer of the microservice architectures, you might have already heard of it, and if not, we will explore the basics; of course, I’m talking about Service Meshes.
An introduction
Adopting a microservices architecture to modernize your applications has numerous benefits, but it also presents a number of new challenges. Container orchestration engines such as Kubernetes help to address many of these concerns, but it’s not the tool to solve all other concerns. For example, let’s ask us the following questions:
- How do you find out why your application is suddenly running slow?
- How will one service find a remote service in another cluster?
- How can I limit which services should be allowed to communicate with each other?
- How to efficiently distribute traffic throughout my cluster as it grows and shrinks?
- How can I release a new version of software to only a single geographical location?
- How can I stop trusting my network completely?
All of these challenges can be addressed using a service mesh. In order to explain what Service Meshes are I will try to use a methodology on where the subject is explained answering key questions about the topic that needs to be addressed. In this case, the question will be What? Why(s)? and How?
What is a Service Mesh?
A service mesh is a web of encrypted persistent connections, made between high performance “sidecar” proxy servers like Envoy and Linkerd. It adds traffic management, monitoring, and policy - all without microservice/application changes. In simple terms, A service mesh is a distributed system that controls the configuration and behavior of all your microservices
Why do I need a Service Mesh in my Infrastructure?
In “Zero Trust” networks there may be no need for traditional firewalling or Kubernetes network policy, as every interaction occurs over mTLS (mutual TLS), ensuring that both parties are not only communicating securely but that the identity of both services is known. Why a high understanding and morning on you Mesh can be more prepared for any inconsistencies of your running applications.
Visibility is key when trying to develop microservices architectures when you have tools for monitoring your applications is less likely to suffer an attack and more importantly, you have the right tools to do preventive work and not reactive, although these tools also help when troubleshooting issues that are happening in all your microservices workloads.
How can I implement a Service Mesh?
Let’s wait a little bit on this one, I will try to answer it later on.
Benefits of Service Meshes
Using a service mesh offers plenty of benefits to all your engineering teams, including:
- Observability. Typically, teams have different tools for keeping track of logging, tracing, metrics, and things like security control. With a service mesh, you get all these benefits, eliminating the need for other tools and all of them in a centralized environment.
- Resiliency. Service mesh offers resiliency features like circuit breaking, latency-aware load balancing, eventually consistent service discovery, retries, timeout, and deadlines.
- Traffic control. A service mesh gives granular control of network traffic to determine where your request is routed and therefore strict policies can be applied in order to restrict or allow certain types of traffic going in the mesh (microservices).
- Security. A service mesh provides multiple ways to secure running workloads such as a certificate authority that generates a per service certificate for TLS communication between services, fine-grained policies for restricting access to specific ports, or setting request limits by Headers, authentication via these same headers are one of the multiple capabilities that a Service Mesh can bring to the table.
- Delay and fault injection. Service mesh allows you to inject failure and latency to simulate what would happen in a real situation. The benefit is that you can rest assured that you know how your services will behave in case of an issue, this can also be an introduction to chaos engineering in a microservice environment.
Adopting a Service Mesh increases delivery speed and reliability, improve security and governance of delivered services.
The Players
Several projects/companies offer service mesh technologies. The most popular ones are:
Any of these service meshes will solve your basic needs. The choice comes down to whether you want more than the basics stuff implemented in your clusters.
Istio has the most features and flexibility of any of these three service meshes by far, but remember that flexibility means complexity, so your team needs to be ready for that.
For a minimalistic approach supporting just Kubernetes, Linkerd may be the best choice. If you want to support a heterogeneous environment that includes both Kubernetes and VMs and do not need the complexity of Istio, then Consul would probably be your best bet.
Service Mesh Interface
Because Service Meshes are now all over the place and they are becoming a must-have in any microservice architecture a new organization/project has been created in order to have a better organization and to set standards when building and configuring Services Meshes, this new entity is called “Service Mesh Interface”, and is a Cloud Native Computing Foundation sandbox project.
The goal of the SMI API is to provide a common, portable set of service mesh APIs which a Kubernetes user can use in a provider agnostic manner. In this way people can define applications that use service mesh technology without tightly binding to any specific implementation.
Implementing a Service Mesh
Now that we understand Service Meshes, sort of, we are ready to deploy Istio on a Managed Kubernetes Cluster using istioctl . Sadly, this will be done in a separate blog, so stay tuned for the second part! :)
Conclusion
Service Meshes are a great way to address most of the service-to-service communication issues of microservices. Whether you are just starting on the path to microservices or looking to optimize your existing workloads, Service Mesh infrastructure is a way to optimize security and scalability, improve observability, tracing, and logging as your move into your microservices journey.
These benefits do not come for free, as service meshes such as Istio are famous for their management complexities. They are also relatively new and changing quickly. The potential of service meshes makes them likely to increase as more and more organizations move towards microservices architectures.
At the end, you will look somehow like this when explaining your microservice architecture:
Build On!
