*(No, it’s not a magic trick)
Yes, you can snap your fingers and create a whole environment. We do it all the time. And we're going to lift the curtain and show you how we do it.
We’re not going to make you wait until the end of the film to learn how the magic trick works.
Here’s a common scenario. I could be working with a client and we start discussing resource management. We start analyzing their most labor-intensive processes, and we have an exchange that usually goes something like this.
Me: If you have a 20-step checklist for provisioning storage, why isn’t that scripted and automated yet?
Them: Because no one has allocated the time and resources we need to do it.
In many of my instances of consulting with large companies, infrastructure-as-code (IaC) environments can be a bit like the chupacabra. It’s talked about (with the occasional touch of awe and fear), but it’s never actually seen.
Is IaC Still a “Myth” in the Enterprise?
To this day, most of the time I still see companies manually standing up a production environment, a test environment, and maybe a lower-level dev environment. Those environments are often running 24/7, even when they’re in the cloud.
What if, instead of having one shared environment running all the time, you could just spin up an environment whenever you need it, and then get rid of it?
One of the major advantages of IaC is that you can spin things up very quickly. Being able to fire up something in an instant requires a lot of scripting using different tool sets. You’ve probably heard of many of those tools, but I’ll name a few just to make sure we’re on the same page:
- Docker
- Kubernetes
- Terraform
- CDK
- CloudFormation templates (AWS specific)
Whatever platform you use isn’t the point. The point is the innovation you introduce when you use it. IaC enables the organization to prioritize a culture where the developers are allowed to experiment. That freedom will never happen if every time the developer wants to try something out, they have to go make a list of demands from the ops team and cross their fingers they get it while the idea is still relevant.
Frictionless, Faster Deployments
Today, there’s almost no way that the operations team is going to give exclusive use of substantial resources to a single developer. Even if they could, creating that environment from scratch could take months.
Alternative: What if that dev could spin up environments as needed without having to interact or reach out to the operations side of the business? When the operations side builds scripts with adequate guardrails so the developers can do almost whatever they want to do, you’re allowing them to innovate without bringing the company to its knees.
Developers will get precisely what they need (speed and agility), and the operations side retains the confidence that the developer can’t infect nefarious code, over-provision the sandbox they’re using to develop a new feature, or (maybe worse) build something that breaks once it goes into prod.
If you deploy resources correctly to the cloud, you can spin up test environments that are just as fast and powerful as production resources so devs can run tests in “real life” scenarios. Getting to this point is a huge paradigm shift. But it could be a real game changer for the product side of the business. IaC introduces frictionless collaboration among teams, allowing devs to be experimental without flexing other resources.
Streamline the Sales Process
Then there’s also this advantage: Client demos. A sales person could (theoretically) spin up a custom environment for any client or prospect, let them play around with it using actual settings and features, and then spin it back down for them without bugging anyone.
Instead of dedicating resources to build “special” environments, you don’t need to seed data and manual config everything just so it’s ready for a test. When you set up your IaC properly, that’s done with a few mouse clicks. You could also spin it up with a special set of backup data that exists from an old demo (and test data) copy.
How’s that for a game changer?
Do You Know What's In Your Environments?
If it currently takes you months or years to architect test environments, you’re (incorrectly) assuming that the world you’re building software for isn’t going to change. Months in the world of software can be years, a century. An eternity.
Setting up automatic builds will take dedicated resources and time. It could also require some outside specialization helping your internal resources to set up your IaC environments quickly and effectively. Here’s the catch: Once you set it up, it’s done. Even if it takes longer to set this up as IaC than it would with point-and-click, that time upfront saves you plenty in the long run and introduces innovation for your customers.
Automated pipelines also help you take stock of everything that’s currently in your environment. I point that out only because we often see that over half the battle is that inventory itself. For application code, you can see all the changes in your version controls. You often don’t have that type of oversight in your infrastructure.
It’s one of the things that IaC buys you. Now, you have full traceability of everything that’s in your environment, like version of Java, patches, etc. With IaC, you have full auditability of everything that’s in that environment.
Let Computers Do Repeatable Things
Most operations teams spend too much time mired in those checklists and are painfully aware of how much time they need to execute them. Those checklists eat up days. The minute it’s scripted, you not only free up resources, you also free up creativity and lessen the likelihood of mistakes sneaking their way into the mind-numbing work you just got rid of.
Just imagine this: You never have to go back to the binders, the update logs, the spreadsheets, whatever. Instead, the infrastructure team can start to work on things that require critical thinking skills and brain power.
Back to that 20-step provisioning checklist. Today, an ops team has probably done that so many times, it’s mindless work. However, it’s still time consuming. As soon as it’s scripted, if there’s another issue that comes up somewhere that requires mindful attention, it’s available. Computers are way better at checklists than people.
Here’s a prime example. DBAs in enterprise environments usually spend their whole days filing requests for creating new tables, and doing other structural things. I had one team go to their DBA with performance issues and request some SQL tuning. The DBA was so backed up, they didn’t have time to address it. When you put in a tool to automate those mundane requests, the DBA has time to address that performance issue.
Usually, the operations team is stretched so thin, they’re just trying to survive the day. With some automation, they can be more forward looking and strategic, and can use their big, beautiful brains for anything other than following checklists. (Also, let’s be honest. When people feel rushed, they’re that much more likely to overlook something simple, and introduce an error they have to troubleshoot later.)
When it takes dozens (or hundreds) of hours to spin something up, you’re going to be that much more reluctant to tear it down. Keeping resources running is costly, often more costly than the time you needed to get it running. With IaC, you don’t have to get attached to those resources, because you can spin them up just as quickly as you tear them down. All of it is disposable (and, therefore, none of it is waste).
IaC removes guesswork that’s usually involved in the “what went wrong, it worked in prod?” scenario. When everything that gets promoted in different environments is scripted, you know exactly what’s going live.
If it sounds like magic, then you should definitely check out our free webinar where you can watch us do this very thing, and let you peek behind the curtain to see how it was done.
Watch our webinar, “How To Improve Security, Speed, and Savings with Infrastructure-as-Code” on-demand coming soon: here.
Tag(s):
Infrastructure-as-Code
