A Guide to Understanding Sidecar Deployment With Istio Service Mesh

Industry analysts predict that 83% of all enterprise workloads will be in the cloud by the end of 2020. To leverage the scalability and flexibility of the cloud, developers can deploy independent microservices into their cloud environments. Yet, transitioning to a distributed microservice architecture isn't without its challenges. As organizations grow, it becomes increasingly difficult to connect, secure, control, and monitor those services.

That's where Istio service mesh comes in.

Today, we're sharing how Istio can help developers establish and maintain a distributed microservice architecture that's built to last. Read on to learn how it works and why it could be one of the most important investments your organization makes this year.

Microservices vs. Monolith Architecture

The term "microservices" or "microservices architecture" is used to describe a cloud-native architectural approach in which a single application is comprised of multiple, independently-deployable smaller components or services.

These components operate as autonomous processes, communicating with one another through APIs. Each individual microservice can be implemented in a unique programming language on a separate platform. This allows developers to organize them around specific business capabilities while enjoying improved speed, scalability, and flexibility.

Conversely, in a monolith architecture, all code components are interconnected and interdependent. They also work cohesively and share within the same memory space. Thus, if developers ever need to change or update the system, they're required to build and deploy the full stack at once.

Shifting from a monolith architecture to a distributed microservices architecture presents many benefits. Yet, the process can quickly become complicated and overwhelming. Development, deployment, updating, and scaling might be simplified, but you're left with more parts to manage.

How can developers maintain a network between the services as an application's footprint grows?

This is where a service mesh comes in.

What Is a Service Mesh?

A service mesh is a low‑latency infrastructure layer capable of handling the high volume of network‑based communication that takes place within a microservices architecture. It helps ensure that your service instances can communicate with one another quickly, securely and efficiently.

It also allows developers to define how their service instances will perform certain, critical actions, including:

• Load balancing
• Service discovery
• Data encryption
• Authentication
• Authorization 
• Failure recovery
• Monitoring and metrics

In addition, a service mesh usually includes more complex operational requirements, such as:

• A/B testing
• Access control
• Canary releases
• Rate limiting

At its core, a service mesh is designed to maximize flexibility. The application code is independently operated and has no knowledge of the work occurring within the service mesh. This means that developers can move a microservice onto a different server or cluster, without the burden of totally rewriting their application. 

How Does It Work?

The service mesh architecture is divided into two components:

• The data plane
• The control plane

The data plane is the proxy service that facilitates communication between services. They also allow developers to observe the performance of their microservices. The control plane does not handle any data. Rather, it's responsible for overseeing the data plane's unique policies and configurations.  

What Is Istio Service Mesh?

Developed as a collaborative effort between Google, IBM, and Lyft, Istio is an open-source service mesh that allows developers to connect, monitor, and secure individual microservices. In other words, it's designed to provide all of the fundamental tools you need to run a distributed microservice architecture.

These microservices can be deployed in a variety of environments, including:

• On-premise
• In the cloud
• Via orchestration platforms (e.g. Kubernetes, Open Shift 

As described above, the Istio service mesh contains both a data plane and a control plane.

Istio Data Plane

The Istio data plane is comprised of Envoy sidecar proxies. These facilitate the inbound and outbound traffic that occurs in all the services within the mesh. All of the traffic meant for assistance is sent to these proxies. From there, control plane policies determine how, when, or if that traffic should be deployed to the service.

Envoy is quickly gaining popularity and recognition in this space because it's specifically designed for use within microservices architecture. 

It's built-in features include:

• Failure handling
• Dynamic service discovery
• Load balancing 
• TLS termination
• Health checks
• Rich metrics 

Istio uses an extended version of the Envoy proxy. This is a high-performance proxy written in C++. 

Istio Control Plane

The Istio control plane is comprised of three components, including:

• Pilot (service discovery)
• Galley (configuration validation)
• Citadel (authentication and credential management)

Let's take a closer look at how each component works.

Pilot

Pilot is designed to provide service discovery for the Envoy sidecars in the data plane.

It also provides traffic management capabilities that facilitate intelligent routing and resiliency. Routing capabilities include A/B tests and canary rollouts, among others. Resiliency controls include timeouts, circuit breakers, retries, and more.

Pilot takes high-level routing rules designed to control traffic behavior and converts them into Envoy-specific configurations. At runtime, it then propagates them to the sidecars as required. It's also responsible for abstracting and synthesizing platform-specific service discovery mechanisms into a standard format that any Envoy sidecar can consume.

Galley

Galley is the top-level configuration validation component of the Istio control plane. It also manages ingestion, processing, and distribution.

The main function of Galley is to validate user-specified configurations on behalf of the control plane. Through this function, Istio can be used transparently across various orchestration systems.

Citadel

Authentication and credential management is required between Envoy proxies. Istio achieves this using Citadel, which provides a policy-directed security layer between those proxies that includes service-to-service and end-user authentication. If unencrypted traffic occurs in the service mesh, Citadel can upgrade it. 

In addition, it also oversees all keys and certifications across the service mesh.

Benefits of Using Istio

Now that we've covered some of the technical components behind Istio, let's take a look at some of the core benefits it provides.

Improved Traffic Management

Istio features accessible configuration rules and routing controls that allow users to better manage the flow of traffic within the service mesh. In addition to managing internal traffic between services, you can also manage traffic between API calls and related services. 

Robust Security

With Istio, users can manage various security measures, including:

• Authentication
• Authorization
• Encryption of microservices interactions at scale 

As such, developers are free to focus on maintaining security on a higher application level.

Better Observability

Istio includes robust monitoring and logging capabilities. These allow users deep and relevant insights into how their service mesh deployment is operating, as well as how it's operating with other components. 

Cloud Deployment, Made Simple

Within every transformation, complications and challenges can occur. Especially when an organization shifts to a hybrid deployment.

While tools such as the Istio service mesh can help simplify parts of the deployment process, we recommend engaging with a team of qualified tech experts to have by your side.