Actually, I predict that configuration management tools like Ansible will decrease in importance, while infrastructure provisioning tools like Terraform or CloudFormation will rise in importance.
Because of something called “immutable deployments.”
Simply put, immutable deployments refer to the practice of never altering your deployed infrastructure. In other words, your unit of deployment is a VM or a Docker container, not a piece of code.
So, you don’t deploy code to a set of static virtual machines, you deploy whole VMs, with the code already baked in.
You don’t change how the VMs are configured, you deploy new VMs with the desired configuration in place.
You don’t patch prod machines, you deploy new machines, already patched.
You don’t run one set of VMs in dev and a different set of VMs in prod, they are all the same.
In fact, you can safely disable all SSH access to all the prod machines because there is nothing to do there — no settings to change, no logs to look at (more on logs later).
You get my point.
When used correctly, this is a very powerful pattern and one I strongly recommend!
NOTE: Immutable deployments mandate that configuration be separate from your code. Please read the 12 Factor App manifesto which details this (and other awesome ideas!) in great detail. This is a must-read for DevOps practitioners.
The decoupling of code from config is super important — you don’t want to re-deploy the entire application stack every time you rotate your database passwords. Instead, make sure the apps pull it from an external config store (SSM/Consul/etc.)
Further, you can easily see how given the rise of immutable deployments, tools like Ansible start playing less of a prominent role.
Reason is, you only need to configure one server and deploy it a whole bunch of times as part of your auto-scaling group.
Or, if you are doing containers, you definitely want immutable deployments almost by definition. You do not want your dev container to be different from your QA container and that be different from prod.
You want the exact same container across all your environments. This avoids configuration drift and simplifies roll-backs in case of issues.
Containers aside, for those folks who are just starting out, provisioning AWS infrastructure using Terraform is a textbook DevOps pattern and something you really need to master.
But wait… what if I need to look at logs to troubleshoot a problem? Well, you won’t be logging into the machines to look at logs any more, you will instead be looking at the centralized logging infrastructure for all your logs.
In fact, some handsome chap already wrote a detailed post on how to deploy an ELK stack in AWS — give it a read if you want to see how it’s done in practice.
Again, you can disable remote access altogether and feel good about being more secure than most people out there!
To summarize, our fully automated “DevOps” journey begins with provisioning the computing resources needed to run our code — Configure stage. And the best way to accomplish that is via immutable deployments.
Finally, if you are curious about where exactly to start, Terraform+AWS combo is a solid place to begin your journey!
That’s all for the “Configure” stage.