PRODUCT ANNOUNCEMENT

Introducing the Ambassador Developer Control Plane

Code, ship, and run your Kubernetes services faster and easier with a CNCF-powered stack

TL;DR

We’re announcing the Ambassador Developer Control Plane (DCP) to enable developers to manage the full Kubernetes development loop. Ambassador DCP gives developers a single interface to:

• Code Kubernetes services faster with Telepresence
• Ship software updates into production with Argo
• Run services with confidence using Edge Stack and Service Catalog

Read on for more.

The Kubernetes Developer Experience

You’ve been coding for awhile, so when you’re asked to write a new webapp with a REST API, you think, no problem! Then your boss tells you that their peers have all been talking about how Kubernetes has increased agility and velocity and saved them money to boot, and they want you to deploy the webapp on Kubernetes.

How hard could this be?

You Google around, and you get Minikube (or MicroK8s, or Docker Kubernetes) running, and your first task as always is to get a simple Hello, World application running locally. And you hit the wall.

A few days of research later, you’ve learned about containers and Kubernetes manifests. You’ve built a dev environment built around docker compose where all your services can be deployed locally. You use your IDE to code on your webapp, and it syncs with a container where you’ve set up hot reload, so you can code pretty productively.

This wasn’t so bad, you think.

Your team grows from just you to a few others, and a few other services get added. Everyone likes the convenience of the local development setup, and the Kubernetes experiment is off to a great start. Adding services is as easy as creating a new Dockerfile and re-running docker compose up.

The application grows.

Then, one day, you update your environment and docker compose up. And it doesn’t work. After a bunch of investigation, you realize that someone has added one more service, and… there’s not enough memory any more to run your development environment.

Welcome to Kubernetes the hard way.

Kubernetes the Hard Way

Kubernetes runs some of the world’s most sophisticated cloud applications. Unsurprisingly, this means that Kubernetes has a lot of functionality and use. Five years ago, Kelsey Hightower wrote Kubernetes the Hard Way, a guide to deploying Kubernetes in real life. TL; DR: it’s a lot of work.

It’s even more challenging to build and maintain a productive developer workflow on Kubernetes, as many different systems need to be wired together. Creating a development environment on Kubernetes requires integrating your source control system, your development environment, and a deployment system. Moreover, as your application grows in size and complexity, workflows start to break and collaboration across your team and organization becomes increasingly hard.

The CNCF landscape is complicated because of all the tools developers and operators need to build cloud-native applications.

Tool Sprawl

The core problem is that you’re no longer a full stack developer. To borrow a term from Netflix, you’re a full lifecycle developer. You’re not just coding software, you’re responsible for shipping and running software too. This also means you’re managing more tools than ever before. Not just development tools (e.g., IDE, libraries and APIs), but deployment tools (e.g., container registries and deployment templates) and runtime tools (e.g., API gateways and observability systems) as well.

Critically, all these systems need to work together to do what you want. Consider another common situation: canary releases. You’re shipping v1.1 of a service to replace v1.0, and you know you should deploy it incrementally. Yet, setting up infrastructure to do effective canaries is complex, requiring you to integrate Kubernetes, deployment workflows, observability, and some sort of traffic management solution.

The CNCF landscape is perhaps the most prominent example of tool sprawl in the CNCF ecosystem. However, if we group the landscape by user, we can simplify our view of the CNCF landscape. In the graphic below, we’ve highlighted SRE/platform-engineer targeted technology in pink, and developer targeted technology in purple.

Introducing The Ambassador Developer Control Plane

Having worked with thousands of developers using Kubernetes, we’ve seen the struggle to manage all these tools first hand. So we’re excited to announce today Ambassador Developer Control Plane (DCP). Ambassador DCP enables you to rapidly code, ship, and run your service. Best of all, Ambassador DCP integrates with many of the tools you are already using, as it is built entirely on CNCF projects: Argo, Emissary-Ingress, Envoy Proxy, and Telepresence.

Code

Coding services on Kubernetes can be a slog. The container-build-push-deploy loop saps productivity and impedes flow. Setting up a development environment that runs multiple microservices is a bunch of work, and keeping all the services up to date is even more work.

Powered by Telepresence, DCP lets you set up a fast, local development workflow. Code locally in your favorite IDE and immediately test your code against all of your remote services and datastores. Better yet, DCP lets you create shared development environments that integrate directly with your continuous integration workflow. This way, your development environment is always up to date, even if you have hundreds of microservices that are changing all the time.

With DCP and Telepresence, stay in your coding flow.

Ship

Shipping code changes to production requires a complicated dance between many different pieces of software. A canary release in Kubernetes involves a sequence similar to the below:

• A continuous integration job is triggered when a pull request is merged.
• The job creates a new image and pushes the image to a container registry.
• A second pull request is opened to update the Kubernetes manifests for the change. In this pull request, the deployment manifest is updated to point to the new image version, and traffic routing (either the Kubernetes service or ingress) is updated to route traffic accordingly to the new version as well.
• The pull request is merged, and the changes in the repository are synced with Kubernetes
• The amount of traffic to the new version of the service is increased. This can be done manually with a pull request that updates the manifests, or with an automated orchestration framework.

Ambassador DCP now supports using Argo and Edge Stack for fast, simple canary releases. Create a Rollout policy as a CRD, merge it into your repository, and incrementally rollout a new version of your code.

Run

No matter how careful you are with testing and canary rollouts, things still go awry in production. Rapid mitigation and response to production incidents is a critical part of your workflow. DCP integrates with Edge Stack and Emissary-Ingress, giving you advanced L7 traffic management capabilities such as load balancing, rate limiting, and circuit breaking. These capabilities are critical to ensuring the availability and scalability of microservices.

In addition, DCP also provides a single, developer-oriented view of all services. This dashboard view includes important information about your services such as the owner, location of the source repository, and more. If an incident happens, you’ll be able to quickly find the information you need to resolve the issue.

An important note is that DCP complements existing operationally-focused Kubernetes control planes. DCP is designed to expose the operational constructs a developer needs, e.g., routing, rate limiting, health checks, replicas. At the same time, operations will need to manage runtime infrastructure to ensure its continuous availability and scaling, and a dedicated operational control plane should be used.

Powered by Cloud Native Computing Foundation Technology

We’ve built Ambassador DCP to be a turnkey solution, powered by top Cloud Native Computing Foundation (CNCF) technologies, including:

• Emissary Ingress (formerly known as Ambassador API Gateway), our hugely popular Kubernetes ingress controller and API Gateway
• Envoy Proxy, the edge and service proxy that powers Emissary
• Argo, the Kubernetes-native continuous delivery framework
• Telepresence, the tool for rapid, local Kubernetes services development

We also recognize that not everyone is using all of these CNCF components today. We’ve designed DCP so that you can get started with any combination of tools, depending on your immediate challenges.

• Need a fast development workflow? Start with Telepresence.
• Want to set up canary workflows? Set up Argo with Edge Stack.
• Want full visibility into your services? Just connect your existing Emissary or Edge Stack deployment to the cloud and add some annotations to your Kubernetes services.

Start Shipping Software Faster

Ambassador Developer Control Plane gives developers and teams a single interface for managing all the different components of your cloud native development workflow. Best of all, getting started with the DCP is free:

• If you’re a single developer, get started with Telepresence first to accelerate your own personal cloud development loop.
• If you’re a development team on Kubernetes, get started with the DCP to accelerate your team’s cloud development workflow.
• If you have questions, join us on Slack or tune in to one of our weekly office hours sessions.

Happy hacking!