Gloo Mesh 2.0 – Friendly Application Networking APIs for Developers and Operators

In 2018, when we announced SuperGloo, we had a vision that we want to build a service mesh abstraction for our enterprise users based on 3 goals:

• Easy to onboard
• Easy to scale
• Self-service among multiple teams

For the past 4 years, we continue to build our expertise in Envoy and Istio, execute on the vision, while incorporating constant feedback from our user community plus service mesh experts in the industry.

Listening to our customers:

After speaking to many of our customers and our field engineers who work with customers to help them adopt Istio and Envoy technologies on a daily basis, we learned the following:

• It is typical for an organization to have multiple services and operators operating these services. They need multi-tenancy and isolation among the teams while declaring service dependencies as they move their services to the mesh.
• As customers are expanding their cloud native journey from edge (north-south traffic) to service mesh (east-west traffic) or from single to multiple clusters, they want consistent application networking APIs that are reusable and expandable.
• Developers want to focus on their applications. They understand labels, but everything else is additional overhead that they want to minimize as much as possible.

Rethinking application networking APIs:

The goal of service mesh from the beginning is to decouple developers from operators so that developers can focus on their application and business logic and don’t need to add resiliency, security or observability to their application via their application code or language specific libraries.

The fundamental problems we are trying to solve for our users remain unchanged:

• Application Owner/Developer: How do we connect applications? How is traffic shifted based on different headers or sources to one or more versions of the target application?
• Operator: How do we control communications? Can we remove all the implicit trusts? How can we add rate limiting or resiliency or failover to our application? How can I delegate route configuration to developers?
• Platform Admin: Who can do what and where can they do it? What are the boundaries of each team and how can we onboard a team easily?

Based on the above fundamental problems with the goal to decouple developers and operators, I am super excited that we are announcing the new application networking API for Gloo Mesh 2.0, to simplify developers and operators on their journey into cloud native and service mesh.

Introducing Gloo Mesh 2.0 API

The Gloo Mesh 2.0 API is built on top of the 3 fundamental problems we are trying to solve for our users:

The admin API group contains Workspace and WorkspaceSettings, KubernetesCluster, RateLimitServer, and similar resources for platform admins to onboard workspaces, define global workspace settings and the Kubernetes clusters for applications, and configure root of trust, rate limiting server and external auth server. Please refer to the workspace blog  for more details on Workspace, WorkspaceSettings, and KubernetesCluster resources.

The networking API group contains VirtualGateway, RouteTable, VirtualDestination etc. Regardless whether the traffic is east-west or north-south, you can use RouteTable resource to configure your host and the actions of the routes, for example where the traffic should be delegated or forwarded to. There are 3 types of destinations that a RouteTable resource can forward the traffic to: Kubernetes service, VirtualDestination or ExternalService. VirtualDestination can be formed from one or more Kubernetes service and/or ExternalServices.

The policy API group contains a set of policies covering these 5 functional areas: extensions, observability, resilience, security and traffic control. You may apply a given policy to route or destination or workload, or to both route and destination. Extension and observability policies can only be applied to workloads because these are policies at the workload level, while resilience, security and traffic control policies could be applied to either route or destination or both.

The above policy design enables operators to create highly reusable policies, where a developer who owns one or more workloads or destinations or routes could easily choose what policies to use by specifying the matching labels via label-based selector.

Let us check out some examples!

Want to enforce security for a given application? Operators can provide a simple AccessPolicy for the foo service, without needing any change to the foo application as long as it has the proper app: foo label in its Kubernetes deployment yaml:

Want to rate limit your application or a particular route to your application? Operators can provide a few policies, such as the 100-req-per-min-policy as shown below. Check out how simple it is for developers to apply the 100-req-per-min RateLimitingPolicy to a given route: just add the ratelimit: 100-req-per-min label to the route!

Want to have the global hostname or automatic failover for your foo application so clients can call it foo.gminaction.io regardless whether the clients are inside of the mesh or outside of the mesh, in the Kubernetes cluster or even outside of the cluster? Simply create a VirtualDestination resource for your foo application. As your foo application is deployed to multiple clusters that are part of the foo workspace, your virtual destination scales automatically to multiple clusters and failover automatically as needed to the next available foo service in a different cluster because the virtual destination resource is designed to be application centric without you specifying which cluster(s) where you have the foo service running.

Wrapping up

Designing the Gloo Mesh 2.0 API with our talented engineers has been a wonderful experience for me at Solo. We are super excited to bring the friendly application networking APIs to developers and operators to simplify their service mesh adoption. With this new API, developers can just use labels to leverage security or observability or traffic control policies, unless the operators delegate the routes to developers. To learn more about Gloo Mesh 2.0, check out our Gloo Mesh 2.0 sessions from SoloCon – join us!

• What’s new in Gloo Mesh 2.0 & Future Roadmap with Neeraj Poddar, Chris Gaun
• New Gloo Mesh 2.0 API & Multi-Tenancy with Scott Weiss, Lin Sun
• Hands on with Multi-tenant Istio Service Mesh with Gloo Mesh with Denis Jannot, Alex Ly

If you’d like to try Gloo Mesh 2.0, sign up for a demo here. We look forward to your constructive feedback and continued partnership!