The Cloud Native Computing Foundation (CNCF) announced today that the open source Istio service mesh, originally developed by Google and IBM, has now officially graduated to become a top-level project alongside Kubernetes and other cloud-native technologies that the consortium helps advance.
Louis Ryan, CTO for Solo.io, a provider of integration platforms based on Istio, said while this change of status doesn’t have any technical implications, it does provide a milestone that instills confidence in the maturity of the service mesh project. Istio, which is built on top of open source Envoy proxy software, moved rapidly through the CNCF curation process because it was well advanced by Google before being donated to the CNCF.
The Istio project now has maintainers recruited from more than 16 companies. That effort has resulted in more organizations launching Istio offerings in addition to a merger with an Open Service Mesh project that Microsoft initially launched to provide an open set of interfaces for multiple service meshes.
The Istio team has also contributed technologies such as a traffic management model that is now used within the Kubernetes Gateway application programming interface (API).
Most organizations initially employ a service mesh such as Istio to manage APIs across a Kubernetes environment, but many are now discovering that service meshes also provide an abstraction layer that enables DevOps teams to programmatically invoke networking and cybersecurity services at a higher level. That capability is expected to play a major role in integrating network and security operations within the context of a larger DevOps workflow.
It’s still early days as far as the adoption of service meshes is concerned, but Ryan said just about every organization that embraces Istio will wind up standardizing on Istiod, a version of the service mesh platform that provides a lighter-weight control plane that is easier to deploy and maintain. Istiod runs natively on Kubernetes rather than depending on container sidecars to be deployed.
In the meantime, the debate over which service mesh to use rages on. Proponents of rival service meshes such as Linkerd contend that their approach is still lighter-weight than Istio and more accessible to developers. Others are making a case for service meshes that are designed to be deployed in both Kubernetes and legacy monolithic application environments.
Regardless of approach, the impact service meshes will have on the way IT teams are organized is likely to be profound. Many of the silos that today conspire to make IT management challenging have started to come down. Of course, which team is assigned to manage a service mesh tends to vary from one organization to the next. In many cases, it’s a DevOps team, while other organizations are assigning that responsibility to a network operations team.
One way or another, service meshes will soon be deployed pervasively in the enterprise. The issue is acquiring the level of expertise required to successfully manage them in an era where IT professionals with advanced skills remain hard to find and retain.