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.