API Gateway
Your Kubernetes cluster requires that there be a "hosted zone" in Amazon Route 53 which is an Amazon service that acts as a domain registrar and DNS management system. When a Kubernetes cluster is provisioned a number of DNS records are created such as "api.$CLUSTER_NAME.$DOMAIN" (e.g. api.foobar.example.org). Unfortunately configuring DNS is a bit of a pain. This guide exists to walk you through the process which is as follows:
Get a domain (either buy one or reuse an existing domain (We strongly recommend buying a new one or reusing an unused one that already belongs to your Route 53 account.
Ensure DNS is setup properly.
April 9, 2020 | 2 min read
Kubernetes API Gateway
Cloud computing and container orchestration frameworks provide an excellent foundation for deploying and running modern software applications. However, in order for these technologies to support the move towards "full cycle development" -- where developers take increased ownership from idea to delivery -- there are several requirements that must be met for both the development and platform/SRE personas. Many teams design and build a platform in order to support these requirements, often using Kubernetes as a foundation. This platform must focus on offering self-service functionality, and it must support four core capabilities: container management, progressive delivery, edge management, and observability.
In part one of this series we covered the topic of "Why Cloud Native?" in detail. This article will explore the new dev/ops requirements, outline the four core platform capabilities, and provide guidance on avoiding common antipatterns when building an application platform.
Full Cycle Developers: More Feedback, Faster
March 12, 2020 | 13 min read
Kubernetes
Description
The Envoy proxy is fast becoming ubiquitous as the universal data plane API for cloud-native networking and communications. However, the power of Envoy comes at the cost of configuration complexity. In this talk, I’ll discuss what we learned from designing and implementing the Ambassador edge control plane for Envoy, built around the Kubernetes API and Envoy’s v2 configuration. I’ll talk about the evolution of Ambassador from a simple Envoy configuration engine built around Jinja2 templates and variable substitution to the more sophisticated, multi-pass, compiler-type architecture that is in use today. I’ll also discuss how engineers today are using Ambassador, the community that has developed around this project, and where we see the requirements and technology evolving.
Transcript
March 10, 2020 | 22 min read
API Development
The emergence of “cloud native” technologies and practices, such as microservices, cloud computing, and DevOps, has enabled innovative organisations to respond and adapt to market changes more rapidly than their competitors. Just look at the success of the initial web “unicorns”, Spotify, Netflix, and Google. Obviously not every company can be a unicorn, but there is much to learn from the early adopters of the cloud.
The Benefits of Being Cloud Native
Spotify’s now famous “squad, chapters, and guilds” organisational model ultimately led to the creation of their applications as independent microservices, which in turn supported the rapid rate of change they desired. Through a combination of a compelling vision and the whole-scale adoption of cloud services, Netflix was able to out-innovate existing market incumbents in the video streaming space. And Google’s approach to collaboration, automation, and solving ops problems using techniques inspired from software development enabled them to scale to a global phenomenon over the past two decades.
March 5, 2020 | 6 min read
API Gateway, Kubernetes
Refactoring applications into a microservice-style architecture package within containers and deployed into Kubernetes brings several new challenges for the edge. In particular, as an increasing number of microservices are exposed to end users, the edge must support managing a multitude of configurations for a wide range of microservices. For more on these challenges, see the article “The Two Most Important Challenges with an API Gateway when Adopting Kubernetes.”
This article explores three strategies that engineering teams can apply in order to effectively manage the edge when migrating to microservices and Kubernetes: deploying an additional Kubernetes API gateway; extending an existing API gateway; and deploying a comprehensive self-service edge stack.
The presentation of each strategy includes a technical overview, a discussion of the associated pros and cons, and an analysis of how the solution can meet each of the two primary challenges with an API gateway when adopting Kubernetes.
November 13, 2019 | 10 min read
API Gateway, Kubernetes
Building applications using the microservices pattern and deploying these services onto Kubernetes has become the de facto approach for running cloud-native applications today. In a microservice architecture, a single application is decomposed into multiple microservices. Each microservice is owned by a small team that is empowered and responsible to make the right decisions for the specific microservice.
This responsibility typically extends from the edge of the system where the user requests arrive, right the way through to the service’s business logic and down into the associated messaging and data store schema.
When integrating a Kubernetes API gateway with a microservices-based application running on Kubernetes, you must consider two primary challenges:
October 31, 2019 | 7 min read
