Solo.io Delivers Istio Management Framework
Solo.io today announced general availability of a framework for managing the open source Istio service mesh deployed on top of Kubernetes clusters.
Idit Levine, Solo.io CEO, says Gloo Mesh Enterprise includes a set of tools for deploying, observing and securing Istio and the open source Envoy proxy software it is based on. In addition, Solo.io will make available tools based on WebAssembly (WASM) to make it possible to customize an Istio environment by adding additional functionality.
Finally, Solo.io will also make available its own internal Istio experts to help internal IT teams maximize their investment in a service mesh originally created by Google, IBM and Lyft.
Istio is the most complex of the available service mesh options IT organizations can employ to manage application programming interfaces (APIs) and abstract the underlying network infrastructure. The tradeoff, of course, is that it provides the most functionality.
Solo.io is betting that, over time, Istio will emerge as a de facto standard service mesh in the enterprise, especially as it becomes easier to deploy and manage. Solo.io has been at the forefront of an effort to make it possible to employ WASM to extend Istio’s capabilities. In addition to Google and IBM, Istio is supported by Cisco, VMware, Red Hat and Tigera. The Gloo Service Mesh, meanwhile, has been under development for more than two years. As organizations start to embrace Istio, the need to simplify the management of what will become a core enterprise element becomes more apparent.
However, there are rival open source and proprietary offerings that are less complex. Linkerd and Kuma are open source meshes that are both being advanced under the auspices of the Cloud Native Computing Foundation (CNCF). Kuma, unlike Istio, is also designed to run across multiple platforms. Istio, in contrast, is being advanced under a steering committee that Google is trying to construct while it retains control over the Istio trademark. Consul, meanwhile, is a proprietary service mesh created by HashiCorp that recently became available as a cloud service.
For the most part, a service mesh today is usually selected by a development team, many of which tend to prefer the lightest approach possible. However, as organizations start to deploy thousands of microservices, it’s already clear there will need to be a more standardized approach to employing a service mesh. In those instances, senior IT leadership is likely to make that decision. In the meantime, it may not be uncommon for organizations to find different development teams are employing a variety of services meshes, proxy software and ingress controllers to integrate APIs and microservices.
In the longer term, Levine says Solo.io is, eventually, likely to support whatever service mesh implementation the major cloud service providers embrace to foster interoperability across hybrid cloud computing environments. In the meantime, much of the initial Istio focus will be on enabling organizations to begin deploying a service mesh in a production environment before ultimately extending the capabilities of Istio across the enterprise.
