Enable your engineers to manage the edge (without blowing things up)

In traditional web applications, an API Gateway’s configuration is fairly static. A small number of monolithic applications are deployed on a predictable cadence. Each deploy may require a small configuration change in the API Gateway that is easily automated.

Cloud-native applications change this dynamic. Dozens or hundreds of microservices may be deployed at the edge, requiring the services of the API Gateway. Each of these services require different configuration changes (after all, they’re independent applications) and are deployed independent of each other. Your API Gateway’s configuration has become highly dynamic, with many configuration changes every hour or every day.

Traditional API Gateways are poor fits for this dynamic world:

1. Configuration changes require API Gateway restarts, impacting application availability. When configuration changes were infrequent, these brief outages were acceptable. When changes happen every hour or every day, these outages become more visible.
2. A centralized management console or API forces all changes to go through a single edge operations team. As configuration changes increase in frequency, this edge operations team starts to become a major bottleneck to application delivery.

Built on the new Ambassador 0.50 architecture, Ambassador Pro is designed to solve these problems for organizations deploying microservices on Kubernetes. Ambassador Pro tackles these problems in two fundamental ways:

1. Ambassador Pro uses Envoy Proxy’s Aggregated Delivery Service APIs to do reconfiguration with zero downtime.
2. Ambassador Pro extends the decentralized configuration model pioneered in Ambassador to more operational functions including rate limiting and authentication.

Decentralized configuration in action

Imagine that Jane is a service owner, and she knows that her service cannot handle more than 5 requests per second without returning crashing. Jane decides to configure a global rate limit for her service of 5 RPS. In a traditional API gateway, Jane opens a ticket with the edge operations team. Julian, an engineer on the edge operations team, is assigned the ticket. Julian reviews the ticket. He then uses the web UI or REST API to reconfigure the API gateway, noting the changes made in a change management system. Julian then closes the ticket.

With Ambassador Pro, Jane can manage rate limits directly. She writes a rate limit rule for her service in declarative YAML. She opens a pull request with the configuration change, which Julian then reviews. Julian merges the pull request, and the change is deployed to the gateway.

apiVersion: getambassador.io/v1beta1
kind: RateLimit
metadata:
  name: catalog-rate-limit
spec:
  domain: ambassador
  limits:
  - pattern: [{generic_key: catalog}]
    rate: 5
    unit: seconds

Note that this configuration change is for a very small portion of the total API gateway configuration. By supporting small, self-contained configuration, Ambassador Pro enables multiple teams to simultaneously manage different aspects of its total configuration.

How Ambassador makes decentralized management easy

Ambassador’s configuration is exposed as annotations on Kubernetes services or Custom Resource Definitions, depending on the specific configuration. Each of these annotation fragments is designed to be self-contained, managing a specific aspect of Ambassador’s configuration.

Ambassador then integrates these different configuration fragments into a single global configuration. To prevent a bad configuration fragment from corrupting the entire configuration, Ambassador performs extensive syntactical and semantic checks prior to passing a new configuration to the proxy. Configuration validation is one of the most complex parts of Ambassador, and will be covered in more detail in a future blog post.

Why is decentralized management such a big deal?

Imagine that, on average, Julian, the edge operations engineer, spends an hour processing a ticket. With a single monolith that’s deployed once a week, he only needs to spend an hour a week managing the gateway.

Suppose, though, that Julian’s company now has adopted Kubernetes and microservices, and there are 25 microservices that are being deployed daily. Julian now needs an entire team! He needs to spend 125 hours/week managing the edge. This is impractical — and the only solution is to delegate more of the management back to the the service owners (e.g., the Janes of the world).

Ambassador Pro

We’re incredibly excited about Ambassador Pro and how it’s evolving. With Ambassador open source, we focused on decentralized management of services by extending the Kubernetes service resource. With Pro, we’re now focusing on extending this management model to other aspects of edge management such as rate limiting, authentication, and routing (through Service Preview) — in ways that go beyond just extending the Kubernetes service resource.

Interested in learning more? Sign up for a free trial today!