A brief history
In the before times of 2017, Varun Talwar and Louis Ryan, sat under a forgotten waterfall at the edge of the world and contemplated the nature of Kubernetes and how it could be extended and integrated. Though mystic visions swirled between them, they both found that they had the same one - of a sail on a great ship. An Istio, derived from Greek meaning "sail", was born.
...okay, so, not quite like that, but Talwar and Ryan did come up with the name in 2017. Where Kubernetes comes from the word for Helmsmen, Istio does come from the word for sail. It has been an open source project since then and is available at Istio.io. Truly, it's a collaboration between Google and IBM, and a team from Lyft that created a big part of the engine. Originally released in 2017, it's currently on version 1.11 as of October 2021 and managed by Google's open-source team.
High-Level Overview
Istio works with Kubernetes and only Kubernetes. You can have a Kubernetes platform without Istio, but if you have Istio, you have Kubernetes.
At a high level, Kubernetes allows applications to run in the smallest manageable pieces on a platform that automatically brings those applications back when they fail, allows them to share and optimize use of hardware, and allows a lot of technical optimization. Kubernetes primarily focuses on getting those applications to run, be stable, and recover in case of failure.
Istio, is the next step, primarily concerned about the communication of those applications with each other, with the outside world, and integrations to existing and new applications. Istio is a type of service mesh, so named because each application, or service, is connected to each other and Istio in a mesh-like fashion. If you come from the traditional networking world, think of it like hub-and-spoke, except each spoke can also talk directly to one another.
Important terminology note: most applications are actually a collection of services, and each service is treated special in service meshes and on Kubernetes. Although we will use the words accurately going forward, that term is often used interchangeably.
Wedding Receptions: An Analogy
I've been to a variety of (American) weddings and their associated receptions and food service at each one seems to vary wildly. Perhaps you have been to a wedding in a barn with a taco bar, as well, but you have probably experienced a plated dinner as well. Oddly enough, these are also how we can look at things with Kubernetes and Service Meshes.
When my cousin got married in rural Kansas, there was indeed a taco bar in a machine shed for a reception. Open tables, kegs of beer, and the families made things such as cheese dip and taco meat to serve about 250 people. It was great, everyone got fed, there were plenty of places to sit, people mingled, there was a band for a little while, and no one missed out on the cake. People had to go get their own tacos, and my aunt and uncle had to keep doing the refilling of the taco bar and tap the kegs as necessary, but it was still a beautiful reception.
In many ways, this is what vanilla Kubernetes is like. There's a lot of work going on behind the scenes or preparing, such as buying several hundred taco shells or running to the store to get a replacement tap when the first one broke, but most people didn't know it. There was seating for everyone and if someone spilled something, they all just moved tables and eventually someone got the power washer out to clean them off. In the same way, Kubernetes is making sure there are plenty of places for your services to sit, that they all get what they need to run, and when something goes wrong, they can move and keep partying. There is still maintenance and behind-the-scenes work and love going into it, but by and large, things run nicely.
When a friend of mine got married after several years of being engaged for the wedding, it was a very different experience. People mailed in RSVPs with names and selecting chicken, steak, or vegetarian pasta dishes, mailing addresses were provided for any gifts that could be mailed, and there was a scheduled cocktail hour prior to the actual dinner and reception. The reception venue was a purpose-built one for receptions and events.
When we arrived, we provided our invitation and names and had assigned seats. The tables had water, plates and cutlery, a schedule of events, and as soon as we sat down, someone was over at the table to see if we wanted wine, soda, or anything else to drink. No sooner did I set down my empty drink than another one was provided. Our tables were arranged by how we might know one another, such as family, college friends, or coworkers, and we were given plenty of opportunity to talk and didn't have to make awkward conversation with randomly assigned people. Dinner was served as ordered on the RSVP, including cupcakes, and the events ran mostly on schedule. The music was managed by a DJ who also provided emcee services. A great wedding but very different than my cousin's taco bar wedding.
This is a lot more of what Istio, as a service mesh, does. It knows what you want to consume specifically, provides sidecars to collect information and provide necessary replacements of information, and encourages like services to talk to one another and maintain an even tighter schedule than pure Kubernetes. The entry has a certain kind of security to prevent unintentional services and even the ambient information - the music - is more integrated.
However, keen readers will notice very quickly - there is a huge difference in labor and cost to these two receptions. My cousin's reception was noticeably cheaper, required less maintenance, and less overall staff. However, it meant I had to awkwardly try to avoid talking to a distant relation who is very proud of her children and has all the pictures and stories to prove it, refill my own drink, and deal with someone dragging pickled jalapeños into the lettuce at one point. My friend's reception though had none of these, but no less than a dozen staff out where the reception was happening and many more behind the scenes running the kitchen and bar.
Wedding Reception Post-Mortum
Both weddings, I am glad to say, have the couples still married. There are definitely many pictures from both receptions and a lot of many personal memories from both. So, which is better?
As you, good reader, expect, it depends. However, mostly, it's a cost and scale versus demand. Instead of these weddings being a couple hundred people, imagine they were over 2,000 people. The taco bar reception would continue to be cheap, but would be harder to maintain with just my aunt and uncle and finding people who shouldn't be getting free tacos might be more tricky. However, it would still have good memories and be a good reception and would just need a lot more tables. My friend's plated dinner reception would likely run the same, perhaps with more people to host the door and a lot more people to run service and even more in the kitchen. It would continue to escalate in cost, but would be a more consistent experience and allow more security with names and required invites.
Back to the topic
Translating this back to Istio and plain Kubernetes - both are good experiences for your services and are considered the current standard for scaling enterprise applications. However, if you need to tightly manage your services and have a close handle on how they interact, Istio likely will provide success, but there is a labor component that is not cheap!
When deciding to use Istio, there's a lot of technical components that need to be considered with a dedicated team and a lot more planning than pure Kubernetes. It's not something you simply flip a switch and walk away! There are many experts that may be in your organization and definitely outside it to help guide you, and several different implementations of service mesh, such as Istio (which we have talked about here), Gloo Mesh, Kuma, and Consul.
Reach out! This is the kind of stuff that is fun and exciting to discuss!
