Continuous Delivery with Declarative Config and DVCS as the Source of Truth

No code provides value to end users until it is running in production. Many of the architectural patterns that are associated with today's cloud-native applications, such as microservices and serverless, promote looser coupling between components, which enables a faster iteration cycle. However, traditional software continuous integration and delivery mechanisms need to adapt to be able to support this increase in speed.

Components of Cloud Native Continuous Delivery

Continuous Delivery is the ability to get changes of all types -- including new features, configuration changes, bug fixes and experiments -- into production and in front of customers safely and quickly in a sustainable way. In a complex and ever-changing cloud native environment, combining continuous delivery with declarative configuration -- focusing on the what, rather than the how -- is an obvious choice to reduce the burden of describing all of the low-level implementation detail, and also allow orchestration and scheduling frameworks to make optimal second-by-second modifications that wouldn't be practical for a human operator.

By using a distributed version control system (DVCS), like git, to store all code and configuration organisations get many benefits: there can be a single source of truth; engineers can apply contextual comments to code, and create discussion close to the issue being examined; and repetitive (but vital) review and delivery operations can be automated and changes written back to a repository in the form of an audit log.

High-performing organisations combine all three of these approaches to drive success within IT and business. This is supported by conclusions from the "State of DevOps 2018" report, and also the emergence of methodologies like "GitOps" and the "Software Defined Delivery Manifesto"

How Ambassador Supports Continuous Delivery of Cloud Services

As engineering teams take advantage of the ability to iterate faster by using loosely coupled architectures, such as microservices, they frequently find that they require a new workflow in order to expose their services to end users. With a monolithic application this was easy: there was typically a single ingress point (via an edge gateway or Application Delivery Controller), and routing additions or updates were simply added into the monolith's codebase. With microservices there may be multiple points of ingress into a system, and the routing is typically decoupled from any single (monolithic) application -- which is often pushed downstream into the edge gateway. This in turn means that the edge gateways becomes integral with your continuous delivery process.

What is required is a mechanism to decentralise edge configuration and also support the continuous delivery of new changes. Ambassador supports this by allowing routing configuration to be specified in code next to a team's Kubernetes' service definitions.

A microservice development team's workflow therefore moves from this deployment pattern when using traditional edge technologies:

  1. App developer defines configuration.
  2. App developer opens ticket for operations.
  3. Operations reviews ticket.
  4. Operations initiates infrastructure change management process.
  5. Operations executes change using UI or REST API.
  6. Operations notifies app dev of the change.
  7. App developer tests change, and opens a ticket to give feedback to operations if necessary.

To this with Ambassador:

  1. App dev opens Pull Request in Git with proposed edge configuration changes.
  2. Operations reviews PR, offers comments and ultimately merges PR.
  3. Automated CI pipeline applies changes to Ambassador.
  4. App dev tests changes.