Article Written by Tanmai Gopal, CEO and co-founder of Hasura The Problem
DevOps in the cloud-native era is evolving at
a breakneck pace. While cloud-native promises developer agility, operational
agility and resource elasticity, the adoption of cloud-native suffers from
typical teething problems characteristic of a new, hyped technology.
The massive tooling overhead required to
choose between various patterns, services and tools and the increased blurring
of lines between ops and devs is resulting in a critical business problem: "As the organisation and its ops shifts to
cloud-native how are its developers going to be convinced, trained, and enabled
to move towards idiomatic cloud-native practices?".
This problem, unfortunately, is not easily
tractable because "shifting to cloud-native" is a long and continuous process
that requires frequent changes in tooling. Very frequently this results in an
unstable ecosystem of tools (eg: "we were using Mesos, now we are moving to
Kubernetes") that results in a tremendous waste of time and money for the
organisation and increased cynicism from developers.
Solution Approach
This problem can be solved by creating a
stable surface (tooling abstraction) for developers but without restricting the
ability of the operators to interface with the infrastructure or to enforce
controls and release processes.
"Below" this stable surface operators change
plumbing, and "above" this surface developers use consistent tooling to drive
relevant DevOps tasks regardless of the situation below.

Git as a boundary between developers and operators
From a developer experience point of view, Git
is the perfect tool for creating a "stable" boundary.
The extensibility provided by git, in the form
of git-hooks on the client-side (developer's machine) or the server-side (a git
remote on the target infrastructure) or in the form of webhook integrations
offered by centralised git-hosting providers (github, bitbucket etc) makes it
possible for operators to hook into git events and do anything. The constraint is that git-hooks and webhooks can only
make use of information inside the git repository or the environment that the
git-hook/webhook runs in.
Key constraint: Everything must become declarative.
On the developer front, git is perfect because
developers already have a strong mental model around how git works. Git push to
deploy is a comfortable and known workflow for developers to deploy their
microservices.

Provided that everything (infrastructure
configuration, application dependencies, environment configuration, stateful
migrations, tests) is made declarative, git is the only tool that developers
need to drive their DevOps tasks.
GitOps
is then this particular way of driving DevOps with git.
In summary, GitOps gives an organisation the
following benefits:
- Reduced
toolset: Developers only need to use git for all DevOps tasks
- Complete
extensibility: git-hooks and webhooks allow for infinite customisation and
tooling to be implemented by operators without affecting the developer
workflow in the slightest
In addition, the optionality with making
things declarative is very high because greater levels of automation, testing
and portability become possible!
Move your team to GitOps: A checklist
For
developers:
- Make
the microservice runtime declarative: Dockerfile
- Make
the environment configuration declarative: Kubernetes PodSpec
- Make
stateful actions declarative: Jobs as containers, migration files
For
operators:
- Set
up a programmable git-remote or a webhook listener on the cluster where
the deployment is to take place
- Make
the infrastructure requirements declarative: Cloud formation / deployment
manager / resource manager / terraform
- Make
the deployment declarative: Kubernetes Deployment/Service
- Make
the tests declarative and run as jobs in a pipeline triggered by a webhook
or as git-hooks on the git remote
- Implement
CI/CD tasks automation in git-hooks on the client side, or the remote side
or as webhooks
- Implement
deployment of stateful tasks like database migrations. Deploy them as
jobs/scripts as all or nothing git-hooks on the client-side/server-side.
- Use
a monorepo or a config repo where configuration, integration tests for the
application are stored
- Store
secrets/tokens as references to actual values that only live on the
Kubernetes cluster, or a vault
- Try
to define everything as files in
a git repository. The "everything-as-code" goal is actually tractable in
the Kubernetes world.
Examples of tools that enable GitOps on Kubernetes
- Setting
up a git-remote that can receive git events or webhooks:
- Gitkube.sh:
git push to your kubernetes cluster to build and deploy docker images
- Synchronising
state in git repo with state on a kubernetes cluster:
- Flux:
A controller running on a kubernetes cluster that synchronises the
declarative spec in the git repo with the state of the kubernetes cluster
- Setting
up git-hooks for running stateful migrations:
- Hasura:
A CLI that sets up git-hooks on the local and remote git that can apply
configuration, database migrations and can build/deploy docker images via
git events.
##
About the Author
Tanmai
is the co-founder of Hasura, the world's first kubernetes native application
development platform. Hasura helps teams build microservice based applications
rapidly on Kubernetes by providing a high-performance data layer on Postgres,
an API Gateway, and built-in GitOps for Kubernetes. Previously, Tanmai ran a
consulting firm helping enterprises build modern applications and migrating
legacy applications to microservices. He holds a Masters & Bachelors in
Computer Science at IIT Madras.
Tanmai will be speaking about "Git-push Workflows (using git hooks) for Deploying Applications
on Kubernetes" at KubeCon +
CloudNativeCon EU, May 2-4, 2018 in Copenhagen, Denmark.