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.

Benefits of a Service Mesh

  • Enterprises can create application features using modular software development across disparate teams of developers.
  • Faster development, testing and deployment of applications.
  • More efficient and quick application updates.
  • A lightweight disaggregated data layer of proxies located alongside the container cluster can be useful and highly effective in managing the delivery of network services.
  • More freedom to create truly innovative apps with container-based environments.

Applications need a set of services such as load balancing, traffic managing, routing, health monitoring, application monitoring, security features and policies, service and user authentication, protection against intrusion and DDoS attacks, support for graceful application upgrades, and error handling (for microservices).

Traditionally these services were implemented as discrete appliances. where each appliance was managed individually. Monitoring, scaling, and providing high availability for these appliances is hard and impractical.

Service mesh is a new architectural paradigm that delivers these services integrated within the compute cluster. It scales with the cluster delivering highly available services and is programmable through APIs.

Types of Microservices

  • Stateless microservices — These services don’t save or store data. Any data required for the request is lost when the request is complete. Stateless containers may use limited storage, but anything stored is lost when the container restarts.
  • Stateful microservices — Requires storage to run. Stateful microservices directly read from and write to data saved in a database. Storage persists when the container restarts. However, stateful microservices don’t usually share databases with other microservices.

Microservice Design Patterns

  • Aggregator — The aggregator design pattern is the most common in microservices implementation. It works like a web page that calls up multiple services and displays all the results in one place. It can also use business logic to only show collated or consolidated responses.
  • Proxy — A variation of the aggregator. With proxy design pattern, no aggregation is necessary but different microservices can be called up based on user need.
  • Chained — Produces a single consolidated response to a request. All the microservices use synchronous HTTP request/response messaging.
  • Branch — Allows simultaneous response processing from multiple chains of microservices. The branch design pattern can also be used to call different chains based on user needs.

Microservice Benefits

  • Independence — Small teams of developers can work more nimbly than large teams.
  • Resilience — An application will still function if part of it goes down because modular microservices allow spinning up a replacement.
  • Scalability — Meeting demand is easier when microservices only have to scale the necessary components, which requires fewer resources.
  • Lifecycle automation — The individual components of microservices can more easily fit into continuous delivery pipelines when monoliths bring complexities.

Deployment of Microservices

Docker is a standard way to deploy microservices using the following steps:
• Package the microservice as a container image.
• Deploy each service instance as a container.
• Scale based on changing the number of container instances.

Kubernetes provides the software to build and deploy reliable and scalable distributed systems. Large-scale microservice deployments rely on Kubernetes to manage a cluster of containers as a single system. It also lets enterprises run containers across multiple hosts while providing service discovery and replication control. Red Hat OpenShift is a commercial offering based on Kubernetes for enterprises.

Are you interested in learning more about the Avi Vantage Platform?

Complete your digital transformation with our next-gen application delivery platform. Experience 5x faster application rollouts, visibility with actionable analytics, and up to 70% cost savings compared to F5 Networks and Citrix NetScaler.

Schedule a Demo Today