Solo.io Donates API Gateway to CNCF to Advance Kubernetes Connectivity
Solo.io, today at the KubeCon + CloudNativeCon 2024 conference, revealed it is donating its application programming interface (API) gateway to the Cloud Native Computing Foundation (CNCF). Gloo API Gateway runs natively on Kubernetes clusters to enable IT teams to manage ingress access to a cluster.
In addition, Solo.io has made generally available an instance of Gloo Mesh, based on Ambient, a streamlined implementation of the Istio service mesh that eliminates the need for container sidecars to make it simpler for IT teams to deploy.
Finally, the company is adding a set of security guardrails to a gateway for accessing large language models, dubbed Gloo AI Gateway, that was launched last July. The guardrails are based on a small language model that Solo.io specifically trained to manage that task.
In general, Solo.io now provides a portfolio of gateways and service meshes that enable IT organizations that have adopted Kubernetes to manage ingress, egress and east-west network traffic within the cluster itself.
Solo.io CEO Idit Levine said Ambient mesh represents a major advance that addresses long-standing concerns about the complexity of an Istio mesh that is used to manage east-west traffic. Originally developed by Google and Solo.io, the Ambient edition of Istio makes use of a proxy developed by Istio maintainers, versus the previous iterations of Istio that are based on open-source Envoy proxy software.
Istio in its original form can be a nightmare to manage, so with the arrival of Ambient the Istio community, seven years after the first introduction of Istio, is now getting the implementation right, she noted.
Solo.io is also working to spur the adoption of this version of Istio by launching Ambientmesh.io, a community website that provides access to enterprise production-ready code, along with support for Ambient mesh in Gloo Mesh.
It’s not clear how many organizations will opt for Ambient over the version of Istio that requires sidecars. Some organizations prefer to isolate various components within their IT environments using container sidecars, however, in general, it’s expected Ambient will make the Istio service more accessible to a wider range of IT teams that lack the skills and expertise required to manage container sidecars.
There is, of course, no shortage of service mesh options. Organizations typically require a service mesh when they reach a critical mass of APIs that need to communicate across the internal network of a cluster. As the number of cloud-native applications being deployed in production environments has steadily increased, so too have the number of organizations that now require a service mesh to manage the network traffic created by the APIs embedded into the microservices that make up that application. A Techstrong Research survey finds well over half of respondents work for organizations that have already deployed cloud-native applications in a production environment, with another 22% now evaluating whether to follow suit.
Less clear is to what degree the service mesh is being managed by networking teams or DevOps teams that typically manage Kubernetes clusters. Alternatively, many organizations are starting to adopt platform engineering as a methodology for centralizing the management of IT operations. Regardless of approach, the one clear thing is a service mesh of some type is playing a critical role in enabling the deployment of modern microservices-based applications.
