Satish S. Aherkar, DevOps Evangelist.
Istio is the next generation platform to manage microservices!
In traditional applications like monoliths, a developer has all their business logic in one chunk of code. Matters seem simple here with utilization of only one programming language, building a small application, with a small team, with one small project to deploy.
But when everyone works on the same code base, a simple change made by a developer pushes the whole application into an intermittent stage.
This is where Microservices have been introduced. In Microservices, a developer can focus on a specific set of business logic without fear of application getting disturbed. Developers can pick any preferred programming language which is applicable for that business logic. This gives developers a lot of flexibility where they can scale & deploy the microservices independently of each other.
Microservices start to sound cool but there’s a spin to it.
The above case goes smooth if the Microservices are less in number. But when the number goes up to 1000 or 10000, it starts to get blurred. It becomes hard to understand which Microservice is talking to which. Also, with every Microservice opened and vulnerable to security threats, it’s hard to fortify these giant number of services successfully.
That’s exactly where service mesh enters the stage.
What is a Service Mesh?
A service mesh is a shapeable infrastructure layer for microservices applications. This mesh provides developers capabilities like service discovery, authentication and authorization, load balancing, and support among others. Istio is currently the best-known service mesh architecture.
What is Istio?
Istio is an open source service mesh started by Google & IBM. Developing a huge traction in the industry, Istio provides developers a broad framework and a lot of capabilities.
Istio’s capabilities include
● Allowing developers to manage service interactions across both containers & VM-based workloads.
● Independently existable on PREM, Cloud, and multi clouds.
Value Propositions of Istio
Istio provides three main tenants as its value proposition:
1. Uniform Observability
2. Operational Agility
3. Policy-driven Security
Under uniform observability, you get a common set of metrics that are automatically implemented without the involvement of the developer. This gives developer a pass where he can focus on business logics.
This proposition has the ability to change how traffic can traverse through the mesh. Also, it gives the developer an ability to deal with traffic in their preferred way.
This value proposition provides service-to-service security to the application. With microservices opened to security threats, developers don’t have to worry about implementing these capabilities, thanks to these value propositions.
Developers build robust microservices-based applications. However, there are certain things a developer needs when building these applications, like: i) ability to route the traffic between the services, ii) security for microservices which are opened and vulnerable to threats, iii) keep the latency stable, iv) arrange microservices which are distributed into disparate pieces.
Istio does all these above-mentioned functions and removes everything from code and get it into a service mesh, reducing pressure to the developer.
Why do I need Istio on the top of Kubernetes?
Kubernetes doesn’t help with higher-level problems, such as
Rate limiting and circuit breaking
Benefits of Istio
Talking about the benefits of Istio, first and foremost, it is very powerful. Other advantages of Istio include:
● Ability to write policy that applies across all applications
● Istio is not language-specific, i.e., multiple microservices can be written in any programming language preferred by the developer
● Authentication & Authorization, which one can extract out of an application and apply centrally
● Ability to control Routing flow
There’s a presumption that Istio is not necessary if you only have a few microservices. But in fact, even if you have 3 microservices, you need Istio because its impressive policy management, communication flows, ability to locate latencies and invoke services.
Istio Architectural Components
An Istio service mesh is generally split into two main components; a data plane and a control plane. And Istio has three major control plane architectural components which are Pilot, Mixer, and Citadel.
Pilot is the prime component used in Istio for traffic management. This component mainly controls your routing and forwarding policy and gives the ability to do many things like canary roll outs and A/B testing.
It also maintains a canonical model of all the services in the mesh and uses this mesh to let Envoy instances communicate with each other via its discovery services.
Mixer provides a good extensibility to the application. It has an open API & a pluggable architecture in itself. We can use Mixer to interconnect to any backend we want to and also to pull in policy into a service mesh.
Also, using Mixer, we can send telemeter, logs, and traces to our system of choice and also input policies from our choice of policy sources.
Citadel is all about providing security aspects of Istio. It provides service-to-service, end-user authentication with a built-in identity & credential management. Also, with Citadel, operators can enforce policies based on service identity rather than on network controls.
Security is not just a perimeter problem. One of the major drawbacks of using microservices is that so many channels of communication between services & between parts are open and vulnerable to security hacks. The advantage of using Istio is its mTLS (mutual Transport Layer Security) locks them down, making them impregnable.
Istio security authorize access based on strong service identity or any channel attribute. Also, more than authorizing access, Istio security can control the level of access.
For eg: Service A can communicate with Service B with full access. And Service B can only communicate with Service C with read-only access.
In Istio Authentication Model, peers are authenticated using non-repayable service identities bound to the mutualTLS channel. The end user or application level identity is propagated as a bearer token across service logs.