Terraform Starter Boilerplate for GCP using Terragrunt
A Terragrunt boilerplate to minimize regrets on GCP
Striving for One-Click Environments speeds up development, improves code quality, and improves recoverability.
I remember when I started working as a DevOps Engineer.
For me, âBest-Practicesâ was the most sacred phrase.
I searched for best-practices not only when I wanted to know how to do something. I searched for best-practices to get inspiration for what I should do.
â
In hindsight, big mistake. It happened because I didnât have a clear goal.
When you donât have a clear goal, youâll try to see what the experts do and copy. Youâll end up embracing their best-practices without knowing why they did them.
â
Iâll share with you here why âOne-Click Environmentâ is the ultimate DevOps goal.
As a bonus, Iâll share a framework to achieve it fast.
â
Looking back, the goal you should set is simple: Create an environment in âOne-Clickâ. Iâm saving you years of confusion that I had to go through.
â
Why is this the ultimate goal, you ask? Three reasons:
â
A âcleanâ and working version of the entire system.
The most popular environment is the Production environment, which serves the clients.
There are static testing environments, such as âdevâ, âstagingâ, âuatâ, and more.
There are also ephemeral testing environments, such as Pull-Request-Environments, Git-Branch-Environments, Developer-Environment, etc.
â
The company with the fastest development speed I ever saw was a supply-chain startup. They deployed high-quality code to production a lot, every day, with no downtime.
How? We deployed ephemeral environments for every pull-request. The environments were identical to production. After running automated tests they terminated.
We used Pulumi (Typescript) on AWS and documented how to change the environment. This way developers took part in contributing to the environments.
â
Edsger Dijkstra, was one of the pioneers of computer science. He envisioned programming as a mathematical discipline. He thought programmers will mathematically prove their code works.
When was the last time you wrote a mathematical proof for your code? Probably never.
â
Instead, you took the scientific approach: You ran some tests to see if your code works as expected. And how do you run tests? On an environment of course!
The easier it is to create an environment, the faster youâll be able to run your tests. The âcleanerâ your environment is, the more trust youâll have in the test results.
â
Another startup we work with has 15 Kubernetes clusters with 2,200 nodes on GCP - All created manually!
Developers asked for support many times a day; "Create this DB", "I need a new NodePool", etc.
With every new request, we had to ask - "Should this be automated?"
We ended up automating everything required for every new environment.
â
How? We created a Pulumi Typescript codebase and imported the entire infrastructure into it. On top of that, developers felt comfortable contributing to it, as it was a Typescript project.
â
I asked myself at least 1,836 times âshould this be automated?â, on lots of things. Sometimes I decided to automate nonsense.
If you want to understand if it's worth automating, ask yourself 2 questions:
â
Youâll need to remember every ad-hoc modification you did to an environment. If a change isnât done as part of the âOne-Click Environmentâ automation, youâll have to rely on your memory and do it again.
Imagine a developer creating a new environment, running its tests, only to find out the DB isn't there. Someone created it manually in the other environments.
â
Next time you ask yourself âshould this be automated?â
â
By the way, maybe you want to automate it, but youâre drowning in so many requests that itâs impossible.
In that case, send your management this article.
It's about calculating how much DevOps capacity your company needs.
Maybe itâll help understand how much DevOps capacity you need.
â
An IoT startup we worked with had 5 clients, with an AWS account per client.
It was supposed to be the same system per client, but it wasnât!
Each accountâs production was created with Terraform (Terragrunt) and Ansible. But, there were so many ad-hoc changes, it took about 2-4 days to create a full environment from scratch.
We decided to use Jenkins and created a pipeline that automated everything. When we finished, you could deploy a full environment from scratch in 50-minutes. (after some parallelization it went down to 20-minutes)
You should have heard the sigh of relief the team had when the demo finished â âNo more fear of not recovering from a production incident!â.
â
Think about your production â what would it take to create it from scratch? If your answer is âI donât knowâ, itâs most likely because some things were created manually or ad-hoc.
If your answer is âone-clickâ, we are hiring. Please click this link asap: Senior DevOps Engineer Position at MeteorOps.
â
Imagine a production failure that requires creating a new environment, and finding out you can't. Some things were modified manually.
Or, as the poet Capone-N-Noreaga wrote - âOh no, oh no, oh no no no no noâ.
When you have âOne-Click Environmentsâ, you can deploy a new environment fast and use it instead of the old one.
â
When you can create an environment from scratch, things become easier:
â
You can deploy many environments in different locations, and route traffic to an environment based on your needs.
â
â
It all boils down to 4 things you should be doing:
â
â
Choose tools that answer the below requirements:
â
This is where youâre flexibility is your number one priority:
â
â
Good documentation answers these questions:
â
This step is made easier if you chose idempotent tools with state management, and made harder if you didnât! (choose idempotent tools)
The guiding principle here is simple. If you run the pipeline twice with the same parameters, nothing should happen the second time.
Thatâs it, youâre good to go!
But firstâŚ
â
â
Whenever I think about going forward without a goal, Iâm reminded of this gem from âAlice in Wonderlandâ:
âAlice: Would you tell me, please, which way I ought to go from here?
The Cheshire Cat: That depends a good deal on where you want to get to.
Alice: I don't much care where.
The Cheshire Cat: Then it doesn't much matter which way you go.
Alice: ...So long as I get somewhere.
The Cheshire Cat: Oh, you're sure to do that, if only you walk long enough.â
â Lewis Carroll, Alice in Wonderland
â
You should know we (MeteorOps) took many companies from âno-automationâ to âone-click environmentâ. If youâre interested in learning more, get a free one-click-env consultation here đ