Microservices Journey from Netflix OSS to Istio Service Mesh

Microservices are loosely coupled services with bounded contexts which give you the ability to develop, deploy, and scale your services independently. It can also be defined as an architectural pattern to build distributed systems which are independently developed and deployed. Handling the service to service communication in a microservice architecture is challenging since they need to communicate with each other over the unreliable network.

Complexities in a Microservice Architecture

A problem with distributed applications is that they communicate over the network — which is unreliable. Hence you need to design your microservices in such a way that they are fault tolerant and handle failures gracefully. In your microservice architecture, there might be a dozen services talking with each other. You need to ensure that one failed service does not bring down the entire architecture.

There are a number of moving components in a microservice architecture, hence it has more points of failures. Failures can be caused by a variety of reasons — errors and exceptions in the code, the release of new code, bad deployments, hardware failures, data center failure, poor architecture, lack of unit tests, communication over the unreliable network, dependent services, etc.

Netflix OSS to the Rescue

Netflix is one of the earliest adopters of microservices. To keep up with its growth rate, Netflix made the decision to move away from monolithic data centers to a cloud-based microservices architecture for achieving high availability, scale, and speed. Based on its success story, Netflix open sourced a number of tools/technologies which powers it microservices architecture. These tools and components have been the drivers for a number of enterprises in their journey from monolith to microservices.

Netflix OSS is a set of libraries and framework that Netflix open sourced to solve the issues with designing distributed systems at scale. Read more about Netflix Open Source Software Center here.

Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications. You can read more about it here.

With a few simple annotations, you can quickly enable and configure the common patterns inside your application and build large distributed systems with battle-tested Netflix components. The patterns provided include Service Discovery (Eureka), Circuit Breaker (Hystrix), Intelligent Routing (Zuul) and Client Side Load Balancing (Ribbon).

Issues With the Netflix OSS

• Netflix libraries are tightly coupled to the Java Platform and are a good fit if you are developing services in the Java platform. However, in a polyglot architecture you need to look for libraries beyond Netflix to handle the communication between services.
• Netflix libraries need to be embedded inside each microservice along with side business functionalities. This causes application bloat since you will need to duplicate similar code across all your services.
• Having both the business logic and infrastructure logic increases the overall application complexity.
• Operational complexity is also enhanced since you now need to handle the patching/upgrades to the Netflix components.
• Additional tooling is required to improve the observability of your microservices architecture.

What Is a Sidecar Design Pattern?

The sidecar design pattern is gaining popularity and wider adoption within the cloud-native community. Building a microservice architecture that is highly scalable, resilient, secure, and observable is challenging. The evolution of Service Mesh architecture has been a game changer. It shifts the complexity associated with the microservice architecture to a separate infrastructure layer and provides lot of functionalities like load balancing, service discovery, traffic management, circuit breaking, telemetry, fault injection, and more.

Benefits of Using a Sidecar Pattern

• Reduces the complexity in the microservice code by abstracting the common infrastructure-related functionalities to a different layer.
• Reduces code duplication in a microservice architecture since you do not need to write configuration code inside each microservice.
• Provides loose coupling between the application code and the underlying platform.

How Is a Service Mesh Implemented?

To implement the service mesh, you can deploy a proxy alongside your services. This is also known as the Sidecar Pattern. The Sidecars abstract the complexity away from the application and handle the functionalities like service discovery, traffic management, load balancing, circuit breaking, etc.

Envoy from Lyft is the most popular open source proxy designed for cloud-native applications. Envoy runs alongside every service and provides the necessary features in a platform agnostic manner. All traffic to your service flows through the Envoy proxy.

Istio Architecture

Istio is a very popular Service Mesh framework which uses Lyft's Envoy as the sidecar proxy by default. A Sidecar is deployed alongside each service instance and it provides an interface to handle functionalities like service discovery, load balancing, traffic management, inter service communication, monitoring, etc. Service Mesh gives you the freedom of not having to worry about the service to service communication as part of your application code. Instead of bloating your microservice with similar functionalities, you can let the Service Mesh handle that complexity for you.

Istio Service Mesh is composed of two primary components:

• The control plane's responsibility is to manage and configure the sidecar proxies to enforce policies and collect telemetry.
• The data plane's responsibility is to handle the communication between the services and take care of the functionalities like service discovery, load balancing, traffic management, health check, etc.

Please refer my other blog posts to learn more about the Istio Data Plane:

• Istio Service Mesh Data Plane