2019 Trends: GitOps with Ambassador
Across the industry, thought leaders are arguing that Kubernetes has become so stable it’s actually boring (in a good way!). This means the tech is at a point where organizations can simply use the platform without losing their focus on delivering business value. That means we can expect community adoption of Kubernetes to continue to grow in 2019. Despite this, there are still plenty of unanswered questions around developer experience. We think GitOps will be the hot developer experience trend to watch in 2019.
In a GitOps workflow, Git is the single source of truth for declarative infrastructure and applications. Developers issue pull requests against a Git repo and a “diff and sync” tool is used to detect differences between the intended and actual states of the system when the pull request is merged by the Ops team. Tooling then triggers an update to synchronize the infrastructure to the intended state.
The Old Way vs. The New Way
In traditional environments, operations directly configures and manages infrastructure via specialized tools (e.g., command line tools, scripts, or web UIs). Given this amount of specialization, application developers who need infrastructure changes typically open change requests via a ticketing system. Thus creates a strong separation between development and operations.
In a GitOps-style workflow, all configuration is declarative and stored in Git. Thus, any person who wants to make a change in infrastructure configuration opens a pull request, which gets reviewed. A separate CI/CD process ensures that the infrastructure is continuously in sync with the configuration in Git.
GitOps Adoption
Popularized by the Weaveworks team, GitOps has sparked a lot of conversation. It was also a popular topic at KubeCon & CloudNativeCon in Seattle last month, with Chick-fil-A speaking about how they manage fleets of Kubernetes clusters with GitOps. The AppDirect engineering team has also written about how they write Ambassador configuration within each team’s Kubernetes service YAML manfiests. These manifests are stored in git and their CD pipeline listens on changes to the git repo and applies the diff to Kubernetes.
Implementing GitOps with Ambassador
Since Ambassador’s configuration is described via annotations in Kubernetes YAML files, you can easily implement a “GitOps” style workflow with no additional machinery or set up. We’ve written about what we think this developer workflow should look like and about cloud native continuous delivery in detail in the Ambassador docs.
If you’re interested in this topic, join our Community Slack to discuss with us and learn how other Ambassador users are implementing GitOps workflows at their organizations.