Istio and 5 Things You Need To Know About it in 2021

Everyone here has used some form of GPS or mapping app right?

Think of Apple Maps as Linkerd.

“Our expert navigators wish you a most pleasant day and have charted a course for you, ETA 31 minutes.”

Not so bad, but what about Google Maps aka Consul Connect?

“Our latest algorithm has created the most efficient and optimal route – taking into account traffic conditions, ETA 27 minutes.”

Then there’s the Waze of service mesh: Istio…

“There’s a cop ahead so turn off the road here, continue along this dirt path for, I dunno, a mile and then take a right through some guy’s house, through his backyard, and pop out on the other side of that rose bush – you’ll get there in 14 minutes flat.”

See where we’re coming from? This is actually a pretty brilliant analogy to use when trying to explain what a service mesh is and how it works to someone who may not necessarily list tech savvy as one of their strong suits.

Back to Waze. The driver knows where they are (hopefully), and knows where they have to get to, but they have no real way of calculating the most effective way to get from point A to point B as they’re not privy to a whole bunch of variables that affect that journey.

Waze tracks literally millions of data points to chart a course for the driver that not only takes into account static data like speed zones and how many lanes a road has, but other randomized events like traffic lights on the fritz, road works, car crashes, police inspection bays, and a whole heap of others that drastically slow you down.

Just like Waze, service mesh like Istio operate in much the same manner by creating a custom path for data in the form of microservices traffic. Like Waze, Istio keeps up to date on the routing speeds and rules to utilize a dynamic process that diverts data flow through points with the lowest latency and the highest reliability.


Istio is an open-source service mesh tool developed by Google, IBM and Lyft, a layer of control built directly into an application to manage how different parts of an application speak with one another. It extends the Kubernetes container management by using the Envoy service proxy to establish an aware, programmable network within that application.

Each part of an app is referred to as a service, which calls on other services itself to exact changes on the user interface side of things. This could be something as simple as updating the amount of stock on a sales app, where the shopping cart service communicates with the service in charge of the company’s inventory database to confirm that yes, there is sufficient stock to process the transaction and complete the order.

Most modern apps are broken down into this network of services, with each reusable function performing a particular job within the system. As traffic increases and the database is overloaded with requests and queries, it’s the job of a service mesh like Istio to step in and ensure that all the parts are working together in the most efficient way.

More specifically, service mesh is a way to better manage microservices based applications by taking out the human element and pushing automation as far as it will go. Istio provides platform level automation that takes care of the network connectivity side of backend microservices. Istio takes care of the communications between containerised application infrastructure by intelligently routing the traffic and balancing the load across the available resources, while maintaining high performance and speed. Oh yeah, and controlling how each service is discovered, encrypted, authenticated, and authorized for use – all the while logging events and red flagging any inconsistencies that may signal a security breach.


Technology is a bizarre thing. Adopting new technology causes this cascading effect that results in this trend across an entire industry, where companies play a bit of “keeping up with the Joneses” by copying what the market leaders are doing.

The same can be said about service mesh, it’s relatively new and definitely a buzz word that we’re hearing more and more of. Microservices architecture has pretty much taken over classic monolithic architecture, it’s all about container management and packaging software as a bundle together with all the code, libraries, and everything else it needs to run.

Organizations and companies are looking for the best tools available to them in order to not only scale up their applications and runtime environments, but fully optimize how the traffic flows between microservices, to take out as much manual labour as possible.

Istio is now used to further modernize microservices based apps and backends by securing, connecting, and monitoring the functions and containers and other moving parts of the system. Istio improves on the Kubernetes container orchestration tool by injecting additional security, management and monitoring containers into each pod.

Kubernetes operates by combining pods into a node cluster that uses a kube proxy to communicate with the Kubernetes application programming interface to get info about the services within the cluster and the rules they need to follow for requests. Istio is a way to add even more proxies as a sidecar arrangement. One sidecar proxy for each pod in the cluster, so they can speak to any other pod in any other cluster without having to wait to go through the kube-proxy, the Kubernetes API, and then back again.



A service may have multiple dependencies in a complex chain, governing how it interacts with other services within the system. Generally, if one of these fails, it creates a cascading failure event that will quickly result in errors piling up and the service to become unresponsive. Istio shows how these errors are related in a waterfall type diagram, drastically speeding up the debugging process and repairing the problematic code.


Developers want to be able to monitor what’s going on, and love nothing better than to see things like latency, time in service, errors per traffic, and other metrics for system health as a visual dashboard. Istio provides this functionality, where Kubernetes does not natively.


As we touched on, by assigning a sidecar proxy to every pod within a node cluster, Istio is able to effectively balance the load across available resources and route traffic according to the fastest route – think back to the Waze analogy. Administrators can create labels to establish rules by simply tagging a configuration file.


When a service becomes overloaded, or it’s down for whatever reason, additional incoming requests fail and pile up – crashing the system. Istio offers a way to track errors and delays, but is also able to force a pause that allows that service to recover, deal with the pile-up of requests, and then continue normal operation. This pause policy can be enforced across an entire node cluster of pods with just a small text file.


The authentication, authorization and audit features Istio implements by default ensures that no malicious user can fake or spoof services queries – a safer system more resilient to cyber breaches is never a bad thing!


As a company, you want a dev team to be building the applications, not working on a security or administrative level of abstraction. By setting the policy for a node cluster as a single control panel, Istio automates a lot of the grunt work and makes life easier in general for the maintenance crew.



So, service mesh is a new and fairly immature technology. In theory, it’s all rainbows, sunshine, and unicorns but in reality, there are a few teething problems that you’ll no doubt run into. The documentation for new projects like Istio often becomes outdated fairly quickly due to the rapid release of updated features and functionality. Likewise, there may be a distinct lack of guides and how-to’s leaving you to be the guinea pig that has to sit down, make the changes, and see how they affect the system.


As Istio is based off Kubernetes, it has to be compatible with other tools and extensions like Jaeger, Prometheus, Grafana, Kiali, etc. This opens up an entirely new can of worms, as versions of these programs on your system may work fine with Kubernetes vanilla, but clash with the Istio layer built into the application. Problem solving compatibility issues awakens a special kind of rage in a programmer, if you know, you know.


Without someone experienced in Istio implementation, and there are relatively few, anything more than an easy configuration using the settings in Kubernetes may become time consuming. A development environment is quite easy to achieve, but something like a test environment requires a certain level of custom configuration, and trial and error.


The whole point of pod interconnectivity is to speed things up by a fair margin, however also be aware that like anything, more computations require more resources. Using the original kube proxies that forward function for the pods in each node increases the response latency due to all this cross chatter between the Istro pod sidecar proxies. To combat this either up the horsepower of the system, or add in a new series of abstractions to deal with the increased traffic.


For such a new technology, there are a surprising number of well-known companies using Istio to assist in the management of the microservices architecture and applications.

Walmart, Boeing, Dell, and SAP all use Istio as well as Google, IBM and Lyft who all worked together in its development.

Because Istio is built on the same code and API as Kubernetes, it provides a way to add an extra layer onto a microservices system that functions as a huge quality of life improvement for the staff involved in the administration and maintenance of that system.

Istio adds automation to day-to-day tasks with the addition of the service mesh and sidecar proxies, without actually changing any of the existing processes of the architecture or how they work.

At the end of the day, Istio is a tool for microservices that focuses on simplifying the user experience, optimizing the way traffic is diverting within the system, and improving security and monitoring to result in less errors and system downtime.

Money, Money, Money

Keeping in mind that this is a relatively small dataset of around 100 jobs, what becomes immediately apparent is that most of the service mesh-oriented jobs are listed

in North America and Europe – having roughly 40% of all advertised roles each, with the remaining 20% split across Asia and remote terminal work.

The average salary seems to be USD$125,655 which is very respectable compared to the average DevOps salary of $100k. Though the effective salary range for a systems mesh specialist extends from $100k right up to $220k per year, with a decent number in that $160k to $180k ballpark.

The net result is a bump of anywhere from 10-20% on top of your current salary when comparing a services mesh engineer role to a DevOps engineer role – so get out there and upskill!

Next Steps

We hope this blog helped you learn more about Istio and why you should give it a try!

If you enjoyed learning about Istio you may also enjoy our other blogs like, 5 Reasons why D3js is the best framework for Data Visualization or 7 Reasons Why Vuejs is so Popular.

Kofi Group is proud to be a source of knowledge and insight into the startup software engineering world and offers a multitude of resources to help you learn more, improve your career, and help startups hire the best talent. If you are interested in learning more about what we do and how we can help you then get in touch or watch our Youtube videos for additional information.