Selecting an API Gateway for Continuous Delivery of Cloud Native Applications
With most organisations either assessing a move to public/private cloud platforms or actually migrating workloads, much is being written about determining if your workloads and organisation are “cloud native” or “cloud-ready.” The excellent books “The DevOps Handbook”, “Architecting the Cloud” and “The Practice of Cloud System Administration” cover the organisational, design, and operation perspectives in depth.
In addition, individual cloud vendors like AWS, GCP, and Azure have written their own migration guides, each with their own approach. However, at Ambassador Labs we often see organisations struggle with assessing the cloud-readiness of their development teams, tools, and processes. One area in particular, which we will explore in this article, is selecting and using a cloud native API gateway
What is an api gateway?
An API gateway is a vital piece of infrastructure, as every inbound (user) request will pass through this platform component — it literally is the front door to your system. The API gateway is the place to implement support for cross-cutting concerns like release management (A/B testing, canary releasing, header augmentation), security (authz, authn), and basic fault tolerance (circuit breaking and exception catching).
This is not a particularly new technology area. Enterprise organisations have driven the development of API gateways focused on the “productisation” of APIs, such as API monetisation and API management. However, migrating to the cloud — and taking advantage of the associated benefits of “cloud native” technologies like containers (Docker), dynamic orchestration (Kubernetes), and the microservice architecture pattern — often require a different focus with the API gateway.
Increasingly we are seeing clients with dynamic and fast-moving businesses move away from enterprise-style gateways towards cloud-native API gateways. Although the newer gateways may not offer the GUIs and “drag and drop” management (which are useful for centralised API management and product teams), they do offer support for infrastructure as code (IaC) and declarative configuration that individual cross-functional, product-focused teams can use to release and manage services and business functionality as part of their typical development workflow.
Comparing API Gateways
We’ve compiled this table below, highlighting some of the features we believe are important for organisations looking to embrace cloud native technologies, architectures, and workflows. We often get asked about:
- Ambassador Labs vs. Kong,
- Ambassador Labs vs. OpenResty (NGINX)
- Kong vs Traefik,
Although this is by no means a complete list of available API gateways, we believe this is a representative sample from across the industry and should provide insight for teams looking to implement an API gateway:
Integrating an API Gateway into Continuous Delivery
Once you have chosen your API gateway, you can learn more about integrating a cloud native API gateway into your continuous delivery practices and tooling within our latest blog post: Continuous Delivery: How Can an API Gateway Help?
The next post in this series, “Next-Level Testing with an API Gateway and Continuous Delivery” covers how you can use your gateway to learn how your service will perform under realistic use cases, load, and failure scenarios.
If you have any questions, get in touch, or join Ambassador Labs Community on Slack
