Microservices are complex and building a scalable and resilient Microservice architecture is challenging. As the number of services increase, you have to deal with the interactions between them, monitor the overall system health, be fault tolerant, have logging and telemetry in place, handle multiple points of failure and more. Each of the services needs to have these common functionalities in place so that the service to service communication is smooth and reliable.
In a Microservice architecture, handling service to service communication is challenging and most of the times we depend upon 3rd party libraries or components to provide functionality like Service Discovery, Load Balancing, Circuit Breaker, Metrics, Telemetry and more. Companies like Netflix came up with their own libraries like Hystrix for Circuit Breaker, Eureka for Service Discovery, Ribbon for Load Balancing which are popular and widely used by organizations.
However these components need to be configured inside your application code and based on the language you are using, the implementation will vary a bit. Anytime these external components are upgraded, you need to update your application, verify it and deploy the changes. This also creates an issue where now your application code is a mixture of business functionality and these additional configurations. Needless to say, this tight coupling increases the overall application complexity – since the developer now needs to also understand how these components are configured so that he/she can troubleshoot in case of any issues.
Service Mesh comes to the rescue here. It decouples this complexity from your application and puts it in a service proxy & let it handle it for you. These service proxies can provide you with a bunch of functionalities like traffic management, circuit breaking, service discovery, authentication, monitoring, security and much more. Hence from an application standpoint, all it contains is the implementation of Business functionalities.
Istio is one of the best implementation of Service Mesh at this point. It enables you to deploy microservices without an in-depth knowledge of the underlying infrastructure.
Istio is a open source project governed by Google & IBM that connects, manages, controls and secures microservices.
Istio solves complex requirements while not requiring changes to application code of your microservices. Istio reduces the complexity of running a distributed microservice architecture. It is Platform Independent and Language Agnostic – so it does not matter which language you use to containerize your application.
Istio Service Mesh has 2 components – Control Plane and Data Plane.
Control Plane – Controls the Data plane and is responsible for configuring the proxies for traffic management, policy enforcement and telemetry collection.
Data Plane – Comprises of Envoy proxies deployed as sidecars in each of the pods. All the application traffic flows through the Envoy proxies.
Pilot – Provides service discovery for the Envoy sidecars, traffic management capabilities for intelligent routing and resiliency (timeouts, retries, circuit breakers)
Mixer – Platform independent component which enforces access control and usage policies across the service mesh, and collects telemetry data from the Envoy proxy and other services.
Citadel – Provides strong service-to-service and end-user authentication with built-in identity and credential management.
All traffic entering and leaving the Istio service mesh is routed via the Ingress/Egress Controller. By deploying an Envoy proxy in front of services, you can conduct A/B testing, deploy canary services, etc. for user-facing services. Envoy is injected into the service pods inside the data plane using Istioctl kube-inject.
The Envoy sidecar logically calls Mixer before each request to perform precondition checks, and after each request to report telemetry. The sidecar has local caching such that a large percentage of precondition checks can be performed from cache. Additionally, the sidecar buffers outgoing telemetry such that it only calls Mixer infrequently.
Envoy is a high performance Open Source Proxy designed for Cloud-Native Applications.
Istio uses an extended version of the Envoy proxy.
Istio leverages Envoy’s many built-in features like Service Discovery, load Balancing, Circuit Breakers, Fault Injection, Observability, Metrics and more. Envoy is deployed as a sidecar to the relevant service in the same Kubernetes pod. The sidecar proxy model also allows you to add Istio capabilities to an existing deployment with no need to rearchitect or rewrite code.
Capabilities of Istio
Connect – Istio provides Traffic Management between services and let you control the traffic flow with Canary and Dark launches.
Secure – Istio provides a secure communication channel, and manages authentication, authorization, and encryption of service communication at scale.
Control – Istio provides enforcement of usage policies across the service mesh – with little or no application changes.
Observe – Istio provides Automatic Monitoring, Logging and Tracing for all services inside the service mesh.
If you want to read more about Istio, please visit https://istio.io
Categories: Architecture, Envoy, Istio, Microservices, Service Mesh
That is a pretty good writeup for the why of using Istio
So is it fair to say that, at this point in time, developing java based microservices using spring cloud+Netflix oss is old school? I am thinking so.
I see another spring cloud k8s project.. think that is also old school at this point in time.
If I were to implement microservices at this point(jan 2019) is it fair to say that I shld use springboot
based microservices deployed to k8s manager July the isitio servicemesh?
LikeLiked by 1 person
***managed by Istio servicemesh
Correcting last line of qn