Istio has become the second incubating project in the Cloud Native Computing Foundation (CNCF) with the most stars and contributors this year. We picked it for our Top CNCF Projects to look out for in 2023. Why is it so popular? What does it offer to developers? Is it going to replace Ingress? Is it better than Nginx? So many questions! And we are going to try to answer as many as we can fit in a blog post.

Does Kubernetes need Istio?

Kubernetes or more generally speaking, a microservice infrastructure poses a series of challenges that legacy code did not have to deal with. If we split a monolithic application into several loosely coupled microservices, each one of them will have to add some extra functions:

Since they are no longer part of a single process, nor even running in a shared environment, they need to configure means of communication among themselves.
Communication can fail. In order to make microservices robust, developers must include retry logic.
Any application, but especially sensitive ones — like banking solutions or those that handle personal data — needs to add security logic to make sure that legitimate requests come from verified microservices within the application.
Finally, metrics and tracing logic become necessary when a system is so complex that debugging becomes unattainable otherwise.

All these parts that act like the “glue” of a scattered application have to be implemented into every microservice, in addition to the actual business logic that it has to perform. Thus, developers spend too much time on code irrelevant to business logic, and microservices are more complex and heavy than they should be. Enter, stage left: Istio.

Is Istio a load balancer? What is Istio?

Istio is an implementation of service mesh. A service mesh is a part of the application layer that is all about the service in contrast to the content.

A service mesh solution like Istio has a data plane that takes charge of all the extra tasks that a microservice has to perform — communication configuration, robustness mechanisms, security logic, and metrics and tracing — in an infrastructure abstraction layer. Developers only need to focus on the application logic and rely on the mesh for the rest. For the data plane, Istio leverages Envoy, which is another CNCF project that we highlighted recently. During setup, an Envoy sidecar proxy is deployed inside each microservice’s pod. These proxies will intermediate and handle all the communication among microservices.

There is also a control plane that gives cluster-wide support for the data plane. Istio’s control plane is called Istiod and it offers:

Simplified configuration of the whole cluster — Istio receives high-level rules (in Kubernetes YAML configuration files, so no need to learn yet another configuration language!), converts them into Envoy-specific configurations, and propagates them into the sidecar proxies.
Dynamic service discovery — Rather than using a static configuration of endpoints, every time a new microservice enters the cluster, it is automatically registered and made available for others to use.
Certification authority (CA) — Istiod can generate certificates to enable secure TLS communication between microservices.
Telemetry — It gathers telemetry data from the Envoy proxies that can be consumed by monitoring servers like Prometheus.
Ingress gateway — The Ingress component of Istiod exposes services to the external world and thus it is the entry point for all the services running within the mesh. It is based on Envoy, just like the data plane. It acts as a load balancer operating at the edge of the mesh, and even more, it can perform traffic splitting for different deployment strategies.

So yes, it is a load balancer. But it is also so much more!

Istio vs Envoy

Sometimes the question is why to use Istio instead of simply Envoy. At a first glance, they both seem to offer the same: a unified, secure, and observable way of communication between microservices of a single application, freeing the developer to focus just on business logic. Why do we need Istio? What does it add that Envoy alone does not cover?

If you made it this far in the article, you may already have an understanding of what Istio has to offer. Istio heavily relies on Envoy — its whole data plane consists of Envoy sidecar proxies and its ingress gateway is also based on Envoy. However, what Istio adds — and this is really the reason to opt for it — is to bind together and coordinate all the Envoy proxies. It creates an abstraction level that receives high-level rules and takes charge of the rest. It is like a wedding planner or a contractor — you just have to deal with it instead of having to manage all the individual agents.

Napptive enables developer self-service. We encourage you to try our playground and experience accelerated cloud-native development. It’s completely free*, all you need to do is simply [sign up](playground.napptive.dev/campaign_source=blo..) and get started!*

Use cases for Istio

Istio was created by the Envoy team at Lyft, together with IBM and Google, as an open-source project in 2017. Since then, it has evolved and been widely adopted, making for some typical use cases:

Observability

Let’s face it: fails do happen. As an application gets relatively complex, it becomes more and more difficult to find out the source of a problem without the aid of a service mesh. The elementary data collected by Istio is immensely helpful in grasping the cause of unwanted behavior in almost no time. Efforts can be devoted to fixing it rather than figuring out what is wrong. Meanwhile, setting up a circuit breaker in the control plane will ensure that requests are served only by healthy instances.

Deployment Strategies

Deployment strategies, like canary or blue/green, are safe ways to release upgrades of a service. Istio can help you divert a portion of the traffic to specific instances — for example, 10% of all new requests will be served by the new version of a given service, while the rest are routed towards instances of the current version. This way, you can try the new version in production before going all in.

Testing

When you have a service mesh in place, you can test your application with delays, timeouts, bad requests, and disaster discoveries. For example, let Istio inject delays in the traffic rules. It will gather telemetry data of the outcome for you.

API Gateway

API gateways make it possible to manage service APIs so that the service users can make calls to a single-entry point. With the help of Istio, you can create complex API management schemes within your clusters for service-to-service communication.

How to get started

Chances are that you already have Istio available from your cloud provider — and maybe even managed! Istio implementations are built into many providers’ Kubernetes services.

You can check out the long list of providers, plus professional services that can implement Istio for you to fit your requirements, and also many other tools that integrate with Istio, on this page of Istio’s official site.
There you will also find extensive documentation on how to deploy, use and operate Istio.
For understandable, short, and sweet information pills about Istio, we highly recommend checking TechWorld with Nana’s videos.

And the best part is, once you have got it up and running, it will save you so much time and effort to focus on what truly matters to your work!

In case you have not yet tried Napptive, we encourage you to sign up for free and discover how we are helping propel the development of cloud-native apps.

Article originally published here: https://napptive.com/blog/istio-top-cncf-projects-2023/

Istio - Top CNCF projects 2023