What Is Infrastructure As Code?

Infrastructure as code is a central idea in Continuous Delivery. The environment in which our software exists is a dependency of our software, so we need to control that environment as far as we can. If our aim is to release software reliably and repeatedly we need to control the variables so that the host environment is the one that our code needs. Infrastructure as code for cloud based systems is really table-stakes, but it also applicable for other kinds of software too. Infrastructure as code tools can be a big help, but the idea is about more than only tools.

In this episode Dave Farley describes three approaches to infrastructure management, describing ideas like immutable infrastructure and explores some of the techniques and devops approaches that help us to be confident in our ability to release change into production, and to re-create working environments on demand.

_____________________________________________________

📚 BOOKS:

📖 "Continuous Delivery Pipelines" by Dave Farley

📖 Dave’s NEW BOOK "Modern Software Engineering" is available here

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

-------------------------------------------------------------------------------------

Also from Dave:

🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses

📧 Get a FREE "TDD Top Tips" guide by Dave Farley when you join our CD MAIL LIST 📧

-------------------------------------------------------------------------------------

CHANNEL SPONSORS:

-------------------------------------------------------------------------------------

*This is a re-edit of a past episode previously published on the channel in order to meet our weekly upload schedule.

[RoelBaardman]

I've worked at the Dutch railways, where our software supplied the travelers with information about their journey. Everything ran in Docker containers and inside the docker containers configurations were updated every 20 minutes using puppet.
This meant that when a new train arrived from the factory, after installing the base system and configuring the identity, it was automatically updated with everything that was.

For me, this was a great example of how embedded systems (given they're connected) can also benefit from this kind of technique.

[Nghthavvk]

At my company we use helm / k8 with docker to deploy our immutable infrastructure. However, we depend on an outside partner (who hosts a different service that we use) and they... often make changes that lead to our environment being impacted.
It's a different problem (interfaces and system borders which you already covered in another video), and I'm very glad we have no issues on our end!

[vkfbab]

Great video Dave. I've been working on a project using Amazon CDK and I have a single repo with infra and code. So I can just run cdk deploy and it's all pushed. As you made comment it was slow. These days it's about 5 mins to make a simple code push because of all of the checks cdk does. This time is too slow for development. However using TDD I've been able to make this less of a problem. All code is in lambda so I can mock incoming requests reliably and I can also mock requests to other Amazon services. So I can make changes rapidly locally running one test, then run the entire suite locally and then deploy to AWS. The moto library for mocking AWS API calls is awesome. I'd never go back to development of 2010 or earlier. That said I see so many developers who don't get IaC. They see it as a DevOps job and they just want to write code. Amazon CDK / cloud formation is great for declarative infrastructure. It only does what needs to be done and will remove deleted infrastructure. The best part of CDK is that you express your infra as JS/python/c#/java etc. So you can use inheritance etc in your infra. So there is no reason for a developer not to do this. I find a programming language works better than YML, but understand that a lot of sys admins probably prefer configuration files.

[JeffreyLiss]

Yeesh, Dave, great content as always. But it sounds like you're talking through a tube.

[FuNIpoxi]

Hi Dave, first of all I just want to thank you for all the great content you provide. It's always super insightful!
This particular episode made me think again a lot about an "issue" I have with IaC regarding testability. Just like you, I like to test everything I do as much as I can, always trying to maximize the value each test can provide in term of effective feedback.
That's why, regarding IaC, I have kind of a small conceptual issue. Indeed, I feel like a 'unit testing approach' does not apply well to that kind of code, in the sense that, in very fine grained tests, we try to remove/mock external dependencies or actors to focus on the business logic. That's a thought I came across when writing Jenkins pipeline code. Scripts are mostly a succession of side effects, and trying to abstract away external actors just leads to what I call 'interaction tests', where you basically check via mock verifications that you called the right dependency with the right arguments... the kind of tests that you described in previous videos as coupled with the production code and hardly maintainable, and I totally agree with that.
Then if the 'unit test' approach is not suitable, the following one would be more about 'integration testing' - by that I mean 'where you actually don't mock away external actors'. But those are usually more costly, slower, harder to maintain due to interactions and coupling between services and environments etc...
Hence, I was wondering if you had insights or opinions about that particular subject of 'IaC efficient/effective testability' ? Maybe there's room for a whole video here :p
Again, thank you very much for all your work!

[TheApothecaryAus]

15:00 demonstrates why Dave is such a great systems thinker, not that anyone here needed that reassurance.

I would say another key benefit is that IaC gets your IT teams off of menial busy work and allows them to work on creativity and innovation driven projects. That "pushing the button", which provides auditability & other good bits, frees up your FTE to perform complex tasks that require a human brain, win win in my book.

Great video as always Dave.

[dxhelios]

When I was hired to become Team Lead, I have established IaC practice. Now it is a requirement for any solution and project delivered to customer. I never regret this decision. We made some smart choices and developed tools and tech internally without relying and hiding details behind 3rd party packages such as Terraform etc. Knowledge and productivity increased dramatically. This must be a requirement. I developed initial set of IaC tools myself and then passed it to others. Now team cannot get back to manual deployments of infra/networks/security.

[GeneraluStelaru]

Dave, make sure you have a healthy lifestyle. We want you around for a long time <3

[krccmsitp]

Great introduction and overview on the topic! But can you please add chapters to the video? That would be great.

[jonnyevason]

I am late to this one. However I have one question. Does the principle of not branching git and using main branch still count in things like Terraform and IaC?

[dinoscheidt]

5:38 Ehm, a clear pro is that if you need to get something online for the meeting with a client in 30min, you don’t need to know how to puppeteer infrastructure via APIs. If the demo system needs to be online, it needs to be online. Fast. You don’t always need repeatability. For the rest: Use pulumi

[ilovmuscx]

Would you recommend a GitOps approach for IaC? I attended an Istio workshop last year, and the presenter told us he heavily recommends comibing Istio with GitOps.
If so, does your "usual" recommendation of a trunk-based branching model with pair programming still hold up to IaC+GitOps?
Tbh, I get kind of nervous thinking about changing the foundation of my production system just by commiting something.

[crushingbelial]

Considering configuration management systems like Puppet/Ansible/Salt/Chef etc - This is an interesting scenario in which I have fully embraced trunk-based development towards all associated modules. For the conglomeration aspects such as a puppet control repo - do you feel that it is preferable to still utilize a version control everything approach vs. trunk-based development approaches towards it?

[willi]

How do you do IAC with databases? From experience those usually get setup once and then it stays like that until data has to be moved to a new architecture of some kind

[myronww]

This view of continuous delivery is limited to the delivery of software in a limited environment. When you are setting up continuous delivery for software running on hardware products that the company creates, you have to test the software across infrastructure with necessary hardware topological variation and so you can only partially approach config synchronization

[AleksandarIvanov]

The link to the IaC book seems to be missing

[myronww]

In other words, your running your software in different fields and some fields contain all cows, some contain 2 sheep and 1 cow, and another contains 3 cows, 2 sheep and a giraffe

[adrianohdsimao]

What are the usual technology that compose the IaC environment?!

[thought-provoker]

In the end, it comes down to laziness:
I'm way too lazy to log into all of my environments and go happy bug-hunting.
I just made the entire config a part of the CI/CD pipeline, so that even if my infrastructure ever burns down, I can rebuild from scratch without doing any work.🤷

[nir]

5:40 I find it hard to agree with you really. Pro: sometimes you just have to prioritize your efforts and the learning curve for this automation can have a lesser priority. And another thing, the fact that this is a common approach is not a con. We all breathe too, and I've never heard of anyone who stopped doing so because it's too common :)