Decentralized Ownership

Decentralized API ownership

Gloo Edge’s developer-centric workflows can benefit from two specific parts of the Gloo Edge 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 Edge’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 Edge’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 Edge open-source API gateway project. We encourage you to take a look at Gloo Edge or reach out about Gloo Edge Enterprise and join the growing open-source community.