Microservices have lead the human race away from monolithic applications to a cloud native landscape. The dominance of microservices (containers) has impacted the modern development environment to be scalable, flexible and continuous. But as the number of microservices increases in a system, few problems creep out and start making things more complex.
Like, imagine having to manage communication between 1000s of microservices manually. It makes you cry? Indeed.
But every problem has a solution, and to save us from the clutches of complexity (Also, I don’t want you to cry), we today would talk about service mesh.
What’s a Service Mesh?
A service mesh is a dedicated piece of infrastructure that helps you to compose many discrete services into one functional application.
Complex? That’s what definition are meant to be. Let’s understand it clearly in the next section.
Why a Service Mesh?
A cloud native application relies on many microservices, or in a layman way, think of it as a service (no confusing names).
Now in an application, you would have a lot of services. For example, in your amazon app, you would have:
- Cart management service – keeps track of what’s in your cart
- Recommendation service– helps you buy unnecessary items (quite essential for amazon 😉)
- Payment processing service– helps you get these sweet useless credit card points
Yeah, I can continue, but would you like to know about thousands of services on Amazon? Probably not (even if you’re a geek).
PS: For simplicity, I broke down stuff in huge logical chunks. The cart management service has a lot of microservice in it. You see, things are complex out there.
Now, you need each microservice to talk to each other (you as a customer need to know how much money you would have to pay for items in your cart), but how would you do that? Easy way to mention the IP address of the containers into your code. But, now we have a problem.
So, assuming we, the developers, are geeks. We won’t either like to roast our brains with so many microservices and making sure they are connected by manually checking each container and the code.
And If traffic surges and few containers pop up (horizontal scaling), how would you connect them? You can’t possibly hard code all the IP address. Or worse, if some container goes down, how would you re-route the traffic till the replacement arrives? You can’t hard code that again.
We need some dedicated piece of infrastructure to do that while we are dealing with thousands of containers. Well, service mesh is that superhero.
It’s a dedicated piece of infrastructure that helps you compose many services into one functional product. Yeah, the definition makes sense now, and you won’t forget what the service mesh does. (More features just a scroll away)
The Service Mesh Architecture
If you dissect this mesh, you will find that it consists of two network planes.
Data Plane (Sidecar Proxy)
A sidecar proxy sits next to a microservice and forwards requests to other proxies. They aren’t hardcoded in the business logic present in the microservices and are made so that with APIs’ help, the cluster operators can manage them very easily.
The absence of hardcoding allows the developers to focus on the product and not worry about the networking.
It helps you inject the Sidecar proxy (the policy and configuration) to the microservices without caring about anything else.
The Control Plane with the Data Plane forms the Service Mesh.
Advantages of Service Mesh
Features provide you with advantages, and let’s talk about the benefits we get using a service mesh.
It’s complex to hard code IP addresses of different services as restarting and provisioning resources change the IP address on the cloud. Service Mesh helps you with facilitating a service registry. In a service registry, each client talks and register itself and makes sure the system can talk to each other in every scenario.
When you use a service mesh, you take control of your traffic. Now you can channel your users traffic to different versions of the deployments and facilitate A/B testing (Canary Deploys). While deploying a new release, you can also divert the traffic to a backup service (Rolling Deploys).
All these load balancing without hampering the user experience🤯
As seen, service mesh helps you get granular control and manages the incoming traffic. You can always use that to your advantage and keep your system fully functional.
With the help of trace id, you can assign a unique id to every incoming network traffic and debug the whole product when needed.
For TLS communication between services, Service Mesh provides a certificate authority that generates a per-service certificate.
Also, you can make sure the services are not talking to something they aren’t meant to with the help of tracing. Security 💯
Happy Developers 👨💻
Developers are focused on building the business logic, and the service mesh manages networking plus connectivity. I guess this makes them happy. Thinking of networking configuration alongside business logic builds makes me sad.
Final Thoughts 🥱
Service Mesh is a great technology that makes your life simple and secure. If you are interested to know more about the underlying technologies that the service mesh governs, I am attaching few posts down here.
And if you want to know about few of the popular service mesh. Here you go:
Don’t forget to implement them and make your developer’s life easy.
PS: We love making a developer’s life easier. Feel free to reach out to us if you want us to help you with a service mesh implementation 😉