I’m a big fan of things like open source, Kubernetes, and now the Istio project that many have described as focusing on extend Kubernetes. It’s hard for non-programmers to digest software architectures, and certainly nobody involved with Istio has made it any easier, but I think the portrail of Istio as a Kubernetes extension project is way short of the mark. At the same time, I wonder if Google and IBM, the primary backers of the project, are perhaps expecting too much too soon.
Istio is really a microservice ecosystem, aimed at providing four things. First is the connection, meaning integration, of the APIs involved in a distributed microservice deployment. Second is security of the distributed microservice complex, and third is the control of policies and resources. Finally, Istio provides for observation, the monitoring of behavior that forms the basis for making any software system stable and responsive. Kubernetes really doesn’t do this stuff, so in that sense, Istio is an extension, but there are a lot of microservice tools and design patterns that don’t do any of this either. Istio is in fact a step in a broader and essential thrust toward cloud-native behavior.
Work distribution is essential to multi-component applications, and in a sense, work distribution tools anchor applications within the model they were designed to support. The idea behind Istio is that applications, particularly those designed natively for virtualization and the cloud, aren’t the familiar linear-bus-like processes of older models like SOA, but rather a mesh of services connected through API calls. Workflows are more dynamic, more diverse, in this kind of structure, and the complexity of integration and management for the service mesh that Istio creates demands a new platform, which is really what Istio is.
This point frames a reality for Istio, which is that it may well be essential for the future but (for many, or even most), it may be difficult to justify in the present. Microservice-based application models are well-suited for things like event processing and perhaps even some mobile front-end components, but most enterprise applications are transaction processing, and for these decomposition into a mesh of microservices is likely to require complete rewriting and introduce a lot of network delay, for limited benefit.
Another point is that not only is Istio not designed to extend Kubernetes, it doesn’t even require it. In fact, it doesn’t really require any orchestration tool at all, but Istio itself can be extended by linking it to orchestration, including Kubernetes but also Mesos, Marathon, and so forth. That’s because orchestration tools tend to create an implicit application model, and such a model provides a focus for the kind of operational integration Istio offers. Not to mention that architected deployment and redeployment facilitates our four Istio goals. Istio, then, is a part of this distributed-microservice, cloud-native, future evolution, not a complete toolkit to support it.
The principles of Istio are fascinating. If you look at the Istio model functionally, Istio has the typical data/control plane separation that defines its basic architecture. The core of Istio is a proxy-based distributed data bus that creates the Istio mesh architecture. What that means is that there is an adjacent component of this bus (which uses Envoy as its basis) that is a “sidecar” to a microservice. The microservices interact (meaning connect) via the Envoy sidecar, and the control plane of Istio does its monitoring and traffic management through control of the sidecars.
You can look at this as being the same basic principle as SD-WAN for branch offices or cloud subnets. In effect, Envoy provides an overlay to the “real” network, and the “nodes” that create that overlay (the Envoy sidecars) are then able to abstract the real network services, control access via policy, and provide management information that would likely be unavailable if some point of monitoring/observing were not added.
Data traffic between microservices never flows directly; it always goes through Envoy proxies, and that’s the separate data plane piece of Istio. The control plane is (at least in how I view it) created by another component, Mixer, that talks to the Envoy proxies and receives information on the flow of work among components and distributes policies that govern how the data plane works and how microservices can use it to connect. This is why I said that Istio was in effect a distributed data bus, a logical form of the old Enterprise Service Bus (ESB) technology. It’s also why it looks (as I’ve said above) something like an SD-WAN framework because it creates an abstract connection model that overlays the real network.
The data-bus association is important because distributed microservice meshes don’t have the kind of central control of work and policies that something like an ESB would offer. If you have an application or set of applications that are distributed because that’s the right way to build them (event-driven applications are the easiest example), then something like Istio would be the right approach to building them. If you wanted to modernize an existing application that’s componentized using an architecture like SOA and ESB, Istio would be the right way to frame the modernization.
But obviously the benefit of a distributed mesh depends on how much distributing you’re doing. For most virtualization and cloud users, the Istio approach would be overkill without some reason to do a lot of distributed microservices. The primary reason would be to support a highly scalable framework of components where new instances were regularly spawned and where load-balancing was therefore almost mandatory. If this spreads across a hybrid cloud or multi-cloud, the need is even greater.
Google announced Istio (in conjunction with IBM) as a part of its evolving cloud strategy, and this is one reason I said in a prior blog that Google was working harder to change culture than to support current business needs. Companies don’t typically run Istio-justifying applications today. They would have to be taught to frame the way they think about “transactions” and “worker productivity” in a very different way in order to justify the microservice-mesh model that Istio is so good at supporting.
There’s been some talk about who supports this approach (like Google and IBM) and who hasn’t yet jumped on the bandwagon (Amazon, Microsoft, and Red Hat), but I think that’s also missing the key point. Cloud-native is a class of applications that are designed for the cloud. Istio is for sure a cloud-native idea, but a mesh of microservices is only one of many different possible cloud-native application architectures within the cloud-native class. Further, as I’ve said, Istio isn’t a complete cloud-native framework. I like it a lot, but I think there’s another step needed here before things like Istio can really take off, and it’s a step I’ve advocated before.
Application architectures are frameworks for building applications, and to be useful they have to be embodied in a toolkit that’s sometimes called “middleware”. The middleware for the kind of application that runs only on virtual components, virtual hosts, virtual connections, and so forth, needs to be supported by what’s effectively a “Platform-as-a-Service” framework. Istio should be a strong candidate for inclusion in that framework, but so should Google’s Cloud Spanner distributed RDBMS, and so should things like SD-WAN connectivity. In short, to create true cloud-native stuff you need to abstract everything that an application sees, from its data through its hosting and connection, to even its users. Istio doesn’t try to do that, but it needs somebody to do what it doesn’t.
We need service-layer abstractions to represent network connectivity today; that’s what I’ve been harping about with my “logical networking” theme. We need a way to provide the cloud with the kind of workflow tools that we’ve had in monolithic data centers. We need to think of virtualization in terms of how one writes applications to virtual abstractions of hosting and networking. Istio might be a step to that, but it might also be just a tad too geeky to be accepted in the near term. The business problem that Istio solves may be, for most enterprises, too far in the future to worry about.
Is Istio going to be a success, at least a pathway to that cloud-native future? I don’t know, because the biggest problems that any new technology can face are that it requires a culture shift to understand at the business level, and that it’s too much of a stretch for most to understand it at the technical level. Istio has both problems, and if backers like IBM and Google want it to revolutionize the cloud world, they’ll have to make it approachable first and comprehensive second. That’s not happening yet.
As a former programmer and software architect, I really like Istio and what it represents, which is a step toward that illusive concept of a toolkit that programs the cloud like it was a server, that starts with an abstraction of resources and communications and build that into an application platform just like a traditional concept of OS and middleware would create, except for the virtual/cloud world. I’d like to see Istio take off, and I think that the concept will eventually rule the programming world. Just not the way, and at the speed, that Google and IBM hope.
The problem is that while software is essential to today’s world, and developers are essential to software, the process of buying and building software is still driven by business considerations first and foremost. Google, who values culture changes above all else, and IBM, who at least used to understand business, may be able to somehow average out to something that can address the way tools like Istio can be made business-valuable and not just developer-interesting.