What’s up

As a developer, did you ever have this terrifying and unsecure feeling before deploying something to production?

“Fingers crossed, let’s do this” “Calm down, I told you everything will be fine” “F*** everything is F*****”

Everyone in IT for about a decade experienced this feeling and felt the pain of releasing in production. Hats off guys, it’s a huge risk you took, pressing a button that was gonna either deploy the brand new feature you worked on for months… or bring down your entire app.

In 2020, with the advent of devops practices, for those of you who are still experiencing that feeling, I am truly sorry for you. On top of that, your mental health is at stake so hire a devops or less costly, use KintoHub (yeah this article is sponsored, I have to feed my cat).

As an ops, it’s even worse. You don’t mess up just the app but the entire system. Imagine managing a firewall system and messing up with a rule without the possibility to rollback. And what if the change succeeded but you did not document it properly and your colleague deliver a new patch and f*** up the whole system again… It’s a loop of bad practices that can be fixed with… good practices and a set of configuration management tools such as Ansible, Chef or Puppet.

If you decide to not use good practices, your life will inevitably become hell.

Gateway Dooms Day

Disclaimer: I have been working as a DevOps Engineer for KintoHub for about 2 years now.

At KintoHub, we eat our own dog food, our developers use KintoHub to deploy and manage KintoHub. We scratched our heads because we had a chicken and egg problem… which version of KintoHub comes first… second… etc. Our solution? One version of KintoHub acts as the “KintoHub 0” to spawn all other versions of it (development, staging, production). We did this by using ArgoCD which deploys this “KintoHub 0” and also all the Kubernetes infrastructure components such as Network Policies and our Service Mesh.

~2 years ago, we were not using ArgoCD. KintoHub was f*****, production was down, my colleagues and I went all over the place to find the glitch. And the team was not able to work properly. It turned out that someone had deployed manually a fix on our gateway without telling us (the gateway is our reverse proxy authenticating all the external accesses to the services that are deployed on KintoHub). In our loop of bad practices, it was not the first time and we had no way to know what was the previous version of the gateway -> a nightmare.

~1 day of work was lost for 5 engineers in the team, very costly for a startup (even if it has been a life saver for the future — we all learn from our mistakes).

Never ever change something manually in prod — or anywhere else.

It’s a basic rule that we did not respect, finding excuses about time to devops and time to market. And it was a very bad excuse and it hit us back hardly.

KintoHub provides a platform abstracting devops for developers. The goal being that developers don’t care much about Infra but focus on their code and can easily build, deploy, rollback it. We aim to be the next Heroku but better, cool goal..

Ironically, we did not even respect our very own devops practices.

ArgoCD

Disclaimer: If you need a tutorial about “How to use ArgoCD”, this article is not for you. Instead, I would recommend to look at their quick and easy Getting Started.

That’s when we started looking online to see if we could use a tool for helping us (KintoHub is Kubernetes based). And that’s how we got to know the concept of GitOps and ArgoCD. What is GitOps? What is ArgoCD? And how do we use them so that our now well known (at least from us) “gateway dooms day” never happen again?

GitOps is a way to do Kubernetes cluster management and application delivery. It works by using Git as a single source of truth for declarative infrastructure and applications. With Git at the center of your delivery pipelines, developers can make pull requests to accelerate and simplify application deployments and operations tasks to Kubernetes.

So GitOps is like DevOps, a set of practices to achieve a similar goal -> faster delivery and higher reliability during deployment. We just had to find a tool to help us achieve GitOps practices. Enter ArgoCD!

Luckily, KintoHub is heavily using Argo for CICD (Continuous Integration Continuous Delivery) purpose and ArgoCD is its little sister (or brother I did not check).

Self promotion again, I wrote an article 1 year ago about Argo if you are interested.

ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes.

So we use ArgoCD to automatically and safely apply any changes we push on our Git repository to our Kubernetes cluster.