Decentralized Ownership

Decentralized API ownership

Gloo Gateway’s developer-centric workflows can benefit from two specific parts of the Gloo Gateway configuration API. The first is that service teams 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

Gloo Gateway’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 Gateway’s VirtualService configuration can delegate to RouteTable objects which each developer or service team can own and potentially re-use.

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 to manage their APIs. Platform teams can own and manage the parts of the API infrastructure that the organization demands. 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 are part of the foundation of the Gloo Gateway open-source API gateway project. We encourage you to take a look at Gloo Gateway or reach out about Gloo Gateway Enterprise and join the growing open-source community.