As organizations move to a microservices architecture, they find they need to adopt decentralized, self-service infrastructure to really get the gains promised by this approach. This includes building self-service platforms around Kubernetes, Prometheus, Zipkin, etc. and more recently Envoy Proxy.

Envoy Proxy has become a foundational piece of a cloud-native infrastructure and can play multiple roles: edge gateway, internal gateway, service mesh service proxy, etc. Envoy as a technology is versatile, but no matter how great a technology is — it’s only as good as the workflows and organizational structure around it. We don’t want to adopt new technology just to create the same organizational bottlenecks — we want to explore workflows that allow for centralization where it makes most sense, but decentralization where bottlenecks historically formed.

Gloo is an open-source edge gateway/API gateway built on Envoy Proxy with a strong focus on operations and developer workflows that are best suited for a cloud-native, microservices architecture. Let’s see how it does that.

The API is important

As an API Gateway, Gloo, allows you to do things like:

• OAuth/OpenID Connect
• Web Application Firewall
• Rate Limiting
• Fine-grained request routing/splitting/canarying
• Transformations
• TLS/mTLS

And more. Please see the Gloo feature page for more detail.

Gloo’s API is built with declarative objects that specify what the final result should be, not the imperative steps to get there. This follows a Kubernetes approach and naturally on Kubernetes Gloo uses Custom Resource Definitions (though Gloo can run outside Kubernetes as well). When it comes to providing the right surface for decentralized workflows, APIs matter.

Gloo’s core API is the VirtualService construct which is where we define core API abstraction settings like matching clauses, routing pipelines, and target destinations. The VirtualService can enable both a fully centralized or decentralized model, or both at the same time.

Decentralized API ownership

Gloo’s developer-centric workflows can benefit from two specific parts of the Gloo configuration API. The first is service teams can completely own the VirtualService configuration in a “build it you run it” manner. The second is a delegation model that allows service teams to own certain aspects of the configuration while allowing a centralized API team to own some of the security and operation aspects. Let’s take a look at the second approach as it’s most applicable to our users and the workflows they wish to adopt.

Delegate to developers, centralize where needed

Gloo’s configuration API enables developers to focus on the concerns they most care about (routing tables, re-writing URLs, transformation of headers/body, traffic shadowing, etc) and offload the responsibility of configuring security and operational aspects to another team more suited for that (for compliance, organizational or other reasons). Gloo’s VirtualService configuration can delegate to RouteTable objects which each developer or service team can own and potentially re-use.

Here’s a snippet of a Gloo VirtualService that might be owned by a centralized platform

This is a simplistic example, but here we see three important operational concerns that are offloaded to operators:

• domain / virtual host configuration
• route table delegation to developers for the /api/riskscreen path
• control over security aspects of the exposed API

Now let’s look at the RouteTable API that developers / service teams would own:

In this RouteTable configuration, we see that service owners/developers can control the routing, matching, any path-specific settings like retries, fault injection, path-prefix rewriting, and GET/POST/DELETE/PUT controls, etc. We can also add transformation rules on either the request or the response.

Decentralize to go faster

With this delegation model, organizations can go faster without having to file tickets, wait for centralized teams, and give up control over how their APIs are managed. Platform teams can own and manage the parts of the API infrastructure that the organization demands, while developers can own the parts that are most relevant to them without the overhead and synchronization of a centralized team.

Organizational workflow, GitOps, simplicity, and self-service are a primary concern for cloud-native infrastructure, and these concerns have been designed from the foundation into the Gloo open-source API gateway project. We encourage you to take a look at Gloo or reach out about Gloo Enterprise and join the growing open-source community.