I recently started at Google as a DPE (developer programs engineer). Part of my job is to keep tabs on what happens in the open source world.
I have been looking around the CNCF landscape recently, and after attending some virtual talks at the end of last year, I wanted to dedicate time to have a better understanding of the world of OSS (open source software).
This article is just a soft intro in service meshes. With security being such a hot topic last year, I believe that service meshes will be highlighted (it already is!) into being leveraged as a security tool.
So, what is a service mesh?
I think an important question to ask first is why did the need of service mesh ever happen?
Well, with the rise of microservices, all of the service-to-service communication needed to be monitored. Developers found that communication logic needed to be included in within their pods. That's more overhead for developers - they primarily want to focus on the business logic of their apps.
Enter the service mesh. To put it simply, a service mesh is a way to connect, manage, and monitor your services as they communicate with each other. This decouples the tools of communication from your apps (low coupling high cohesion mentality), and pushes this logic to the infrastructure layer.
So how does it work??
Each service that you have is configured to route traffic to a local proxy (installed as a sidecar). A proxy is a 'sidecar' that sits next to your business application container. It exposes primitives that manage communication logic (retry, encryption info, routing rules, etc).
So to recap what we know so far, each service for your app has a proxy that sits right next to it. All these proxies together form the 'mesh' - hence the service mesh!
This is a high level description of service meshes, please let me know if you have any questions!! I plan to do a deeper dive in the components of the service mesh soon😎 Stay tuned!
Some useful reads
Istio - About
The Istio Architecture diagram is a great infographic for how it looks.