Environment Automation: The Good, Bad, And Ugly
When is automation too much automation? When is abstraction too much abstraction?
In the world of “making everything easier”, engineers constantly hear about “abstracting this” and “making that easier”.
The truth is, making things easier and implementing abstraction doesn’t always mean implementing more efficiency.
In this blog post, we’ll dive into the idea of environment automation, what an environment is, and how you can make your life easier from an efficiency perspective.
Define An Environment
What is an environment? Is it a particular stage (dev, staging, prod)? Is it a location (like a data center)? Is it a cloud?
The truth is that an environment is D) All of the above. As you begin to think about what processes you want to automate from the infrastructure creation to the
container deployment to the bug fixes, you’re going to want to implement the automation procedures into each environment. It creates a “flush” approach to how you’re doing things.
For example - let’s say you find an issue within a Pod that’s deployed to a Development environment. The initial thought may be to run kubectl get against the Pod, fix the value, re-deploy, and see the magic happen. You then go in and eventually update the Manifest so the same thing doesn’t happen in production. This shouldn’t be the case. Instead, you should make the fix in the Manifest and then re-deploy it to Development for testing purposes. With environment automation and creation, you always want to make sure to cut no corners.
An environment is:
1. Your cloud
2. Your application stack Environment Automation: The Good, Bad, And Ugly 2
3. Your cluster
4. Your on-prem servers
5. Reporting/Testing and anything else that falls under the tech stack that’s necessary for the overall structure of the application to perform as expected.
The idea of what an environment consists of will be crucial for when you begin thinking about automation and abstraction for more efficient workflows.
The Pragmatic Thought Process
Just do things the right way the first time. Sounds easier said than done, right? That’s because it is. The pragmatic approach to engineering is the same as life - take time to do things the right way or fix them later. When it comes to anything software-related, this could be ripping down what you built six months ago and implementing something new.
Sounds like a waste of time, right? That’s because it is. Take the time to do it right the first time and don’t wrap your environment in duct tape. When implementing the pragmatic mindset for environments, keep three things in mind:
- Understand the environment you’re deploying as close to 100% as possible. It’s impossible to reach 100% because things are always changing, so you want to get as close as you can.
- Ensure that the automation is well thought out. Don’t implement mythical deadlines that make no sense just because management wants it done. Take the time to ensure that what you’re building won’t send your engineering organization into a spiral 6-12 months later.
- Trust that the team can manage the work. If you’re attempting to implement some “easy” or “automated” method that no one knows internally just because you heard about it on social media, don’t. Everything sounds easy until you do it. Make sure proper testing is implemented.
Save Time, Lose Time
You’re saving time by not pointing and clicking, but you’re losing time when creating automation. Which are the lesser of two evils?
The answer is solved once you put a proper plan together. Too many times in the realm of engineering have management heard that something didn’t work as expected, it created more of a hassle, or it wasn’t as efficient as expected.
Just about everything engineering-related comes from:
- Proper planning
- Proper architecture
Unfortunately for the majority of small to mid-sized organizations (and of course even larger organizations), those two steps are pushed to the side. Stuff just “needs to get done” and “something something, deadline” comes in the way of implementing environments the right way.
If you do not plan and architect properly, you will fail.
Too Much Automation
Every tool, piece of software, and vendor wants to say how they’re going to save you time, create repeatable processes for you, and make your engineering life more efficient.
But what ends up happening? You add 2-5 more components that you have to put into your portfolio just so you can have that “repeatable process” completed for you.
Despite what you may hear, you typically need a lot of tools and software to make a truly automated environment, and even then, there’s still a ton you have to do. There’s no tool/software that requires zero effort from engineers. You always have to do “something” and more importantly, you have to understand the “why” and “how” for what’s happening underneath the hood. Otherwise, you’re at the mercy of everyone else.
Automation and repeatability should be implemented and it’s necessary. What you also have to remember is you need to know how to engineer the solutions because there are going to be a lot of tools and software that you have to use. Is there a way to alleviate being an expert in everything?
Enter Codiac
Here’s the problem (something we touched on in the previous section) with all environment automation - it takes a lot of tools.
If you really think about the list, it’s pretty long.
- IaC
- CICD
- Deployments
- Bug checks
- Reporting
- Automated cloud-based tools
... and you have to somehow know it all or at least have a large enough engineering org that knows it all.
There needs to be a way that gives you just enough automation and repeatability
where it matters.
Codiac is an interesting tool because it abstracts away things that you already know and implements them with best practices. For example, when you create a Kubernetes cluster with Codiac, you have to input all of the information to have it run (k8s version, subnets groups, node count, etc), but you don’t have to deal with the nuances of having multiple IaC configs or pipelines for deployment. It’s just enough automation and repeatability for it to be useful.
