How Ambassador’s Decentralized, Declarative Configuration Model Can Make Your Engineering Org Faster
In centralized systems, a central controller exercises control over the lower-level components of the system through a power hierarchy in order to align the system towards a common goal. In a decentralized system, however, lower level components operate on local information to accomplish global goals, without the influence a central controller.
In today’s cloud native world, it is imperative to decentralize decision making in engineering teams in order to move faster. When software engineers are responsible for the entire software development life cycle code/test/debug cycles become faster because they aren’t waiting around for others.
Ambassador enables decentralized decision making among developers by allowing them to individually configure a specific aspect of Ambassador’s configuration (usually a route) and then aggregating these individual bits of configuration into a master configuration for the gateway.
Declarative programming is a style of building the structure and elements of computer programs that expresses the logic of a computation without describing its control flow. This contrasts with imperative programming with implements algorithms in explicit steps.
In Ambassador, declarative configuration means a software engineer is able to declare the desired end state of the configuration and Ambassador then figures out how to achieve the desired end state. This makes Ambassador easier for developers to use than an imperative model, where they would be forced to understand how the gateway must be configured.
This decentralized, declarative configuration model leads to the following organizational benefits:
- Agility: Service owners can change their configuration without going through a central operations function.
- Organizational scalability: Individual service owners are responsible for configuring individual routes in Ambassador, rather than relying on a centralized team.
- Maintainability: In the case that a service is deleted, the route disappears with the service. All of the machinery used to manage Kubernetes manifests can be used with Ambassador out-of-the-box.
To learn more about Ambassador’s decentralized, declarative configuration model, check out this section in the Ambassador documentation, or visit https://www.getambassador.io. To discuss this with the community, join the Ambassador Slack or follow us on Twitter.
