Get to Know Service Mesh – Understand Your Options and How to Choose
The cloud-native ecosystem took the IT world by storm with containers and Kubernetes and have created new categories of technology designed to address the new challenges created when applications evolve from a static monolithic architecture to a
Hoot is a live video series hosted roughly every two weeks where engineers unbox various cloud-native technologies, dig into features of new releases and answer your questions live. To kick off the launch of Hoot, we start with a series on Get to Know Service Mesh as service mesh is the latest buzzword in our ecosystem. The questions come up often include: What is it? Why do I need it? and Which one should I choose?
Get to Know Service Mesh
What is it?
Service mesh is a dedicated infrastructure layer of abstraction that separates how the application services communicate from the business logic of the application. As you adopt microservices architecture, the service mesh solves the challenges of service to service communication (also known as east-west traffic). A proxy is deployed next to each application service (called a sidecar proxy). Traffic passes through the sidecars as it enters and exits the service. This is what facilitates the “mesh” and the service mesh can be managed independently of code changes to the application services.
Why do I need it?
As you adopt microservices architecture, your application goes from a single code base to potentially hundreds of services that are loosely coupled together, updated and scaled (up and down) independently of the other services. In this architecture, the network is critical to ensuring a properly functioning application and abstracting it allows for finer grained controls over the microservices application for developers and operators including load balancing, circuit breaking, security, observability and more.
An important question to ask yourself is When, as service mesh is part of the cloud-native adoption journey but not the first step. It is something that can be integrated into your environment at a later time, after you have operationalized Kubernetes and deployed your microservices application to production. Field CTO, Christian Posta wrote a blog on the topic called Challenges of Adopting Service Mesh in Enterprise Organizations which provides guidance on how to prepare your organization for service mesh and a way to incrementally adopt a service mesh pattern.
Which one should I choose?
The proxy and service mesh landscape is evolving, with new meshes being launched at a regular clip. This can be the source of frustration for anyone starting to research service meshes. All service meshes provide sidecar proxies though they use different proxy technology and provide different service mesh implementations based on the application networking problem set they are aiming to solve. To help explain the landscape, check out our video series Get to Know Service Mesh. In it, we dedicate entire episodes to explain the different service meshes including the architectural approach, unique capabilities, and provide a demo. We end the series with an episode that compares the meshes with guidance on how to select the right service mesh for the needs of the application and operator.
Episode Guide:
- Episode 1: Istio by Google and IBM
- Episode 2: Linkerd by Buoyant
- Episode 3: HashiCorp Consul Connect
- Episode 4: AWS App Mesh
- Episode 5: Kong Kuma and Containous Maesh
- Episode 6: Choosing a Service Mesh for you
Questions? Start a discussion on slack or DM us on Twitter. Subscribe to our Youtube channel and save the playlist to get the latest videos.
Watch the playlist here and set a reminder for the upcoming sessions
