Bringing Together the Gloo Products into Gloo Platform

With yesterday’s announcement and general availability of Gloo Platform, we thought it would be useful to explain some of the behind the scenes elements of the platform and the architecture. 

While each of the products within the Gloo portfolio also announced updates (see below), Gloo Platform is not just a renaming of existing products. It is an integrated architecture that we have been designing for 18 months. 

• Gloo Gateway updates
• Gloo Mesh 2.1 updates
• Gloo Network updates
• Gloo GraphQL updates

Evolving the Gloo portfolio – From Products to Platform

The Solo.io Gloo portfolio has evolved quite a bit over the last three years. From our initial API-Gateway product, based on Envoy Proxy, to our initial service mesh offering, based on Istio and Envoy, we’ve always built around a few guiding principles:

• Choose the technologies that will lead the future – Kubernetes, Envoy and Istio were those technologies.
• Design around operational best practices – Being based on GitOps and Kubernetes CRs enables that operational model. 
• Enable flexibility and consistency – Allow customers to start anywhere, but make it simple to expand. 

Since we launched Gloo Mesh 2.0 at SoloCon2022, we have been building towards a platform-centric model. While our initial product offerings had a consistent data plane (Envoy), they had independent operational models. With that SoloCon2022 announcement, we established several core platform fundamentals.

• Created a unified API for both API-GW and Service Mesh functionality. This enables consistency in provisioning for both inside “east-west” and outside “north-south” traffic patterns. 
• Created a unified control plane, based on Istio, for both API-GW and Service Mesh. This was unique in the industry, as most API-GW and Service Mesh combinations use different control planes.
• Reaffirmed a consistent data plane, based on Envoy, across API-GW and Service Mesh. Again, this was unique in the industry, as most API-GW and Service Mesh combinations use different data planes.
• Provided an embedded API-GW functionality in the Service Mesh.This is well ahead of the work happening on open source communities. 

At KubeConEU 2022, we expanded our portfolio into Kubernetes networking with formal support for Cilium CNI. This not only allowed us to offer customers the option of a fully supported CNI for their Kubernetes environments, but also allowed us to expand the focus we had previously done with eBPF (see: Project Bumblebee).It also enabled us to begin extending functionality from Gloo Mesh, such as multi-tenant workspaces and security policies, to the networking layer. 

Since the SoloCon launch, we’ve listened to our customers about how the products fit into their day-to-day operational models. What we heard from them was three common patterns:

1. While most of them have been successful in their early adoption of Kubernetes, they are beginning to experience a new set of challenges as they grow their environments – more microservices, more clusters, more APIs. Cloud-native 1.0 successes vs. Cloud-native 2.0 challenges. 
2. The continued merging of DevOps / Platform Engineering / SRE roles, with a need to have consistency in how applications, infrastructure and security are managed. 
3. A realization that while they may have “outside” challenges (traditional API-GW use-cases) and “inside” challenges (traditional service mesh use-cases), these two areas were merging together from a technology perspective.

This feedback has continued to push us to not only make the portfolio more integrated, but also to continue adding flexible ways for customers to make the technology fit their adoption patterns. 

What if we could allow our customers to begin their Cloud-native 2.0 journey anywhere in our portfolio, and they would automatically be adopting the Gloo Platform framework?

What if they could adopt any part of the portfolio now, and know that adding other components of the platform wouldn’t require any API changes?  

Enabling an Integrated Platform – Gloo Platform

There are several important aspects of Gloo Platform that we want to highlight.

Unified Operational Model 

All aspects of Gloo Platform follow a common operational model, where functionality is deployed as a Kubernetes CR (Custom Resource), and are aligned with Kubernetes and GitOps best practices. This allows operational teams to build consistent, highly-automated processes around all aspects of Gloo Platform. 

Unified Control Plane

Gloo Platform enables a unified control plane for managing all aspects of the platform. In the past, individual Gloo products had independent control planes, but now Gloo Platform will simplify overall operations, regardless of which aspects of Gloo Platform are used. 

Unified API

Gloo Platform delivers a unique, unified API for provisioning all elements of the platform. 

Modular Architecture 

A modular architecture that allows companies to start with any component of Gloo Platform and easily be able to add other components without making changes to the existing environment – no re-installations, no new APIs, no new operational model.

Consistent Technologies and Management

A set of consistent technologies across Layer 3 to Layer 7 to simplify operations and enable consistent deployments of policies and filters

Extended Support

An extended support model that enables Enterprise support for much longer periods that standard open source projects.