How a Flexible Control Plane Helps Deploy Apps on Kubernetes
Wouldn’t it be nice if all developers had to worry about was creating killer apps in the programming languages of their choice, without knowing how Kubernetes works?
These scenarios might exist in isolated cases, such as when engineers have the freedom to create tomorrow’s applications when doing pure research for machine learning (ML) for the likes of Google or Tesla. However, the developer experience for most cloud native engineers doesn’t resemble that.
Today’s developers must acquire a solid understanding of Kubernetes — no small feat in itself — and typically need to have at least a working knowledge of GitOps processes and of the hundreds of tools under the Cloud Native Computing Foundation (CNCF) umbrella.
In the days of self-contained, full-stack DevOps teams, developers no longer simply create an application for the monolithic deployment and work just on that for further development, leaving the application-management part to operations teams.
But no dev can possibly know everything about every single tool available to them. Cobbling together platforms, tools and processes, just to develop apps to run in containerized Kubernetes environments, requires a major investment in resources — all too often resulting in failure due to the inherent complexities involved.
Organizations that have successfully made the shift to cloud native usually rely on a proper control plane for its developers, one that serves as an underlying tool- and platform-agnostic way to manage Kubernetes.
Ambassador Labs defines a developer control plane (DCP) as something that can guide cloud native developers as they create their code and apps, deploy them into production and manage them once they are deployed.
It should support everything from A to Z for source control, CI/CD, GitOps, both API and container management and, of course, Kubernetes runtime and observability. While Kubernetes is very complex, the DCP that facilitates its orchestration should be very easy for the developer to adopt and use.
Gluing the ‘Construction Kit’ Together
Organizations that have not yet adopted a control plane for Kubernetes environments are typically setting themselves up for a lot of hardship — if not now, then in near future, Torsten Volk, an analyst for Enterprise Management Associates, told The New Stack.
DCP often serves as the much-needed glue to maintain any semblance of security, automation and management of Kubernetes clusters, Volk said. This is because the Kubernetes universe consists of numerous categories and subcategories of product components that can make up an application stack, he said.
A developer control plane should also be accessible for any dev or dev team, regardless of where they are on their cloud native journey.
“CNCF has counted almost 2,000 of these cloud native elements that provide DevOps teams with a massive ‘construction kit’ to create loosely coupled stacks for building, deploying and running cloud native apps,” Volk said. “This incredible degree of flexibility comes at the cost of a lack of consistency that can only be addressed through a unified control plane.”
A DCP should also be accessible for any developer or developer team, regardless of where they are on their cloud native journey. This might include an organization already deploying applications in cloud native environments, or a startup seeking to expand its reach as a Software-as-a-Service provider running on a shoestring budget.
In both cases, the developers can benefit from a proper control plane. Again, its adoption should be easy, since the idea is for the DCP to make the developer process for Kubernetes as seamless as possible.
A proper DCP should, in this way, allow the developer to just create a cloud account in order to get started. Access to the real-time development environment that DCP offers should be completed “with just a couple of clicks,” as Richard Li, co-founder and CEO of Ambassador, told The New Stack.
Flexibility or Bust
The purpose of a DCP is also to orchestrate and simplify the processes of the tools and platforms already in place; the control plane should be tool- and platform-agnostic.
“A DCP is about orchestrating and managing the infrastructure you already have, as opposed to a vendor saying, ‘I know you’re using Argo and other tools, but let’s just rip it out and replace it with our platform, because there’s all this great stuff you should be using,’” Li said. “Instead, a DCP should serve as a cloud-user interface manager without you having to start over.”
The features of DCPs can vary. In Ambassador’s case, for example, its Ambassador Cloud product, a SaaS-based DCP, offers developers a single interface to:
- Improve the quality and speed of feedback for developers and testers with open source Telepresence — maintained by Ambassador — that facilitates working on single services locally, that are also connected to a remote Kubernetes cluster and the corresponding application dependencies.
- Ship software updates into production with Argo CD and Argo Rollouts for GitOps and CI/CD, and monitor the progress of releases via the service catalog
- Run services with Edge Stack that extends the API gateways and ingress controllers with edge features for a developer-led self-service and full-cycle development model.
Ambassador’s DCP shows promise, Volk said, thanks largely to its use of Telepresence, because most developers start their projects within their own — often local — development environments.
“Syncing local environments, with test, staging and production clusters takes away significant headaches for software engineers,” Volk said. “This all comes down to the ‘code once, deploy anywhere’ paradigm that lets developers focus on what they are good at: writing application logic, instead of worrying about infrastructure code.”
Case Study: Zipcar Automates YAML Configs
One of the main pain points Kubernetes developers struggle with is the much-dreaded YAML file configuration. This is where Ambassador has particularly honed its DCP in order to alleviate much of the work involved.
With Ambassador’s DCP, the developer inputs information in response to the API queries, and then a pull request is created automatically with the YAML file configured automatically.
“A DCP is about orchestrating and managing the infrastructure you already have, as opposed to a vendor saying, ‘I know you’re using Argo and other tools, but let’s just rip it out and replace it with our platform, because there’s all this great stuff you should be using.’”
— Richard Li, CEO, Ambassador Labs
“The idea is not to break the workflow but to further automate it. We’re reducing the amount of manual labor and possible human errors that you might make,” Li said. “And if you throw us out and decide to no longer use Ambassador, the YAML remains intact because it’s just the YAML. In other words, the DCP is not proprietary, so you’re not locked in.”
For deployments, Ambassador’s DCP YAML-configuration capability has helped to streamline developers’ code deployments across multiple geographical zones for the car-sharing provider Zipcar.
Zipcar developers create an application they “need to make accessible to the world,” Bo Daley, a DevOps platform engineer for Zipcar, told The New Stack.
“Without DCP, authentication systems and other security checks can slow deployments. The process can also be complicated and “full of security problems that you can fall into,” Daley said.
Ambassador’s DCP came in handy, he said, for automating the integration of developers’ YAML files in a secure way across the different clusters in Zipcar’s network.
The Zipcar developers, with Ambassador’s DCP, “take some relatively straightforward YAML” that the developers describe for how the applications are available for different URLs,” Daley said. “Ambassador takes care of writing all of the YAML configuration that will make that happen. This has definitely saved us a lot of time.”
Smaller dev teams than those at Zipcar’s international organization could also benefit from Ambassador Cloud, Li said. His company’s customers include global Fortune 500 companies, for example, but also much smaller organizations.
“We work with a lot of startups that don’t even have a CIO,” Li said. “Our sweet spot, regardless of an organization’s size, is for DevOps teams that have started to develop on Kubernetes and who have a specific program, whether it’s development CI/CD or runtime orchestration needs.”
