Deploy AWS Resources using Crossplane on Kubernetes
Deploy AWS resources on Kubernetes with Helm and Crossplane. Step-by-step guide to configure the AWS provider and create a S3 bucket.
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 👈