The Evolution of Kubernetes Ingress, Gateway API, and Service Mesh
To be successful in our industry, it’s helpful to not only have the ability to see into the future, but also to have an appreciation of history and past trends. Especially in the context of open source software, it’s important to understand that good ideas are often copied or reimplemented once the market begins to mature.
At Solo.io, we have a track record of having strong insights into future trends, as highlighted by our choices of both Envoy proxy and Istio service mesh well before the industry recognized them as industry standards. We also recognized early on that thinking about Kubernetes Ingress, API Gateway and Service Mesh as distinct functional capabilities would lead to unnecessary complexity and additional costs for companies that tried to put all the pieces together. Our engineering teams have always been at the forefront of application networking for cloud-native applications.
While many technologies and products have evolved over the last 3-5 years, at Solo.io we strongly believe in several technology concepts:
- Istio is the best control plane for managing service mesh, multi-cluster mesh and API-GW functionality, for both north-south and east-west traffic patterns. This has been validated by Istio’s market leadership position in the service mesh space.
- Envoy is the best foundation on which to build a data plane especially for L7 as well as to build API Gateway functionality. This has been validated by Envoy’s wide usage across many implementations, as well as the proven extensibility of Envoy (e.g. WebAssembly, GraphQL, etc.).
- As the capabilities of API-GW (or Ingress) and Service Mesh converge, moving towards a more unified control plane across functional areas will reduce the work and complexity for DevOps/SRE teams. This will improve the ability to operate, secure and troubleshoot application networking environments. Creating multiple control planes across different areas of application networking will create more work for DevOps/SRE teams, as well as open opportunities for misconfigurations, security gaps and difficulty in troubleshooting distributed systems.
- Cilium and eBPF can bring critical performance and observability capabilities to cloud-native environments, and both Kubernetes and Istio should be Cilium-aware to leverage those capabilities when appropriate.
Gloo Platform with Kubernetes Ingress, Gateway API, and Service Mesh
It’s for all of these reasons that Solo.io Gloo Platform is built on an architecture that not only embeds Istio and Envoy, but that integrates those technologies for Kubernetes Ingress, API Gateway and Service Mesh management. Gloo Platform – Gloo Gateway, Gloo Mesh and Gloo Network – is the first platform in the industry to integrate these functionalities with a unified control plane, as well as a modular batteries-included-but-swappable architecture that allows for future innovation and flexibility.
Recently there have been a number of open source projects that are focused on integrating API-GW functionality into Kubernetes or Istio service mesh. But implementing the gateway API doesn’t mean interoperability between the control plane and data plane so you won’t be able to mix control plane and data plane from different service mesh providers. For example, Cilium service mesh control plane won’t be able to manage Istio data plane by simply having both implement the gateway API.
These efforts are still in pre-GA status across Kubernetes and Istio. These projects will need to determine what the long-term plan is for integration, control plane, security models, and more. Timeframes on when these projects will be fully GA is still TBD. Solo.io is an active participant in the Gateway API spec.
Solo.io has always been an innovator in both the service mesh and API-Gateway markets. Many of these proposed projects are attempting to implement a subset of the functionality that Solo.io has previously implemented, in some cases years in advance of the rest of the market.
As a leader in the Istio and Kubernetes communities, Solo.io is deeply engaged with both of these communities, and is evaluating how they will impact Gloo Platform customers. In the meantime, we will keep our customers informed about the status of these projects, and will adopt the community capabilities when the features and APIs are stable/GA.
NOTE: It is important to keep in mind that the gateway API could change based on service mesh requirements, so it is currently not in a “stable” status. It is not unusual for features or APIs to change between alpha, beta and stable, so it is typically not recommended to place alpha or beta features into production without knowing that future versions may not provide seamless upgrades. In addition, being in alpha or beta does not guarantee any timeline on getting to a stable version, or that a feature or API will be included in a stable release in the future.
In the near-term, we are providing the following guidance:
Solo.io will continue to work closely with our customers, and leverage our experience and leadership in open source communities, to ensure that new functionality aligns with their business and technical needs.
As we’ve always done, Solo.io will be at the forefront of the innovation happening in the application network market. We look forward to continuing to work with our customers to ensure that they have access to the best technologies and the best engineering teams as this market evolves.
