What is a Service Mesh?
An Introduction to Containers and Microservices
Containers are a lightweight, efficient and standard way for applications to move between environments and run independently. Everything needed to run the application is packaged inside the container: code, run time, system tools, libraries and settings. So, what are Microservices? Microservices is a architectural design for building a distributed application using containers. Microservices architecture treats each function of the application as an independent service that can be altered, updated, or taken down without affecting the rest of the application.
“Microservices architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API,” according to authors Martin Fowler and James Levis in their article Microservices. “These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”
Companies like Amazon and Netflix have re-architected monolithic applications to microservices applications, setting a new standard for container technology.
Monolithic Architecture versus Microservices Architecture
Applications were traditionally built as a monolithic pieces of software. Adding new features requires reconfiguring and updating everything from communications to security within the application. Monolithic applications have long lifecycles, are updated infrequently and changes usually affect the entire application. This costly and cumbersome process delays advancements and updates in application development.
Microservices architecture was designed to solve this problem. All services are created individually and deployed separately from one another. This allows for scaling services based on specific business needs. Services can also be rapidly changed without affecting other parts of the application.
| Monolithic Architecture | Microservices Architecture |
|---|---|
| Application is a single, integrated software instance | Application is broken into modular components |
| Application instance resides on a single server or VM | Application can be distributed across the clouds and datacenter |
| Updates to an application feature require reconfiguration of entire app | Adding new features only requires those individual microservice to be updated |
| Network services can be hardware based and configured specifically for the server | Network services must be software-defined and run as a fabric for each microservice to connect to |
Why Microservices Architecture Needs a Service Mesh
Applications require a set of services from their infrastructure—load balancing, traffic managing, routing, health monitoring, security policies, service and user authentication, and protection against intrusion and DDoS attacks. These services are often implemented as discrete appliances. Providing an application with these services required going to the appliance to implement and configure the service.
This process was possible when managing dozens of monolithic applications, but as these monoliths become modernized into microservices it isn’t practical to provision hundreds or thousands of containers in the same way. Monitoring, scalability, and high availability can no longer be provided by discrete appliances.
A solution to this problem is the service mesh — a new way to deliver services integrated within the compute cluster through APIs that doesn’t require any hardware appliances. The service mesh delivers a pervasive layer of services across all environments that containerized applications and microservices can be connected to as needed.
What Is a Service Mesh?
Service mesh is a new architectural paradigm that delivers services such as traffic management, security, and observability to container-based microservices applications directly within the compute cluster. A service mesh provides monitoring, scalability, and high availability services through software components controlled by APIs instead of using discrete hardware appliances. This flexible framework reduces the operational complexity associated with modern, disaggregated applications.
The advent of cloud-native applications and containers created a need for a service mesh to deliver vital application services, such as load balancing. By contrast, trying to place and configure a physical hardware appliance load balancer at each location and every server is challenging and expensive.
A service mesh provides an array of network proxies alongside containers. Each proxy serves as a gateway to interactions that occur between containers. The proxy accepts the connection and spreads the load across the service mesh to the appropriate downstream containers that can serve the request.
A central controller orchestrates the connections. While the service traffic flows directly between proxies, the control plane knows about each interaction. The controller delivers access control policies and collects performance metrics. The controller also integrates with platforms like Kubernetes and Mesos, which are open-source systems for automating the deployment and management of containerized applications.
How Does a Service Mesh Work?
The deployment of service proxies with a service mesh happens in a variety of ways:
- Discrete appliances: A set of discrete appliances (usually proprietary hardware). Deployment re-routes traffic for service chaining. As a result, this happens with manual configuration or a set of adapters and plugins to automate service creation. This approach is mostly impractical.
- Service proxy per node: Every node in the cluster has its own service proxy. Application instances on the node always access the local service proxy.
- Service proxy per application: Every application has its own service proxy. Application instances access their own service proxy.
- Service proxy per application instance: Every application instance has its own “sidecar” proxy.
