Infrastructure as code

Listen to the Kablamo team explain infrastructure as code (IAC) in this short discussion. Scroll down for the full transcription. 

Interviewer: So how does infrastructure as code work?

Liam: Well basically…Ben?

Ben: Uh, it's pretty simple. You define some code, you give it to the cloud provider, and they turn it into infrastructure. It's literally that simple.

Marley: I guess it's a key piece in enabling that cattle model. You can't have scaling up from 1 to 1,000 servers if someone has to sit there and install the application and run it on each of 1,000 servers, right? You need to start automating your workflow from scratch to run, basically.

Ben: Yeah, I mean there are a few ways to create servers. One would be you go into the console, you click "I would like one server, please," you log into it, you modify it. And the other one is, I build a script, and then I go "run" and I get 100 of them instantly. That's the infrastructure's code model.

Marley: Or you get as many as you need.

Ben: As many as you want, yeah. I just picked 100 because that's more impressive than, "I get two."

Marley: I want 1,000!

Liam: So the driving force behind it is the consistency model. Once I've created a definition I don't need to literally have someone on, so. Traditionally, build scripts were a thing, and organizations would typically have people run through it and go, "Hey, new server's up. This is how we build a data server. Here's how we built a web server. Here's how the application server runs. Here's every other permutation of server type that we have." And they're prone to human error, 'cause it's effectively someone following a checklist and then potentially going through it again and again. The build is only as good as the documentation is in that build run, and even when it is all that, you still don't incur zero error rate within that.

When you are building things in...and again, this is not a particularly new thing, and it's not necessarily something that didn't exist or only existed in the cloud. You've had DSLs in configuration management in the likes of Puppet and Chef, Ansible and Salt, well and truly before [inaudible 2:04] were in that space. The system is an investment and it's not a particularly an easy thing to get into sometimes.

But functionally the idea is that at two in the morning, when someone has to go rebuild said server, or you've got automation kicking up in building that server at 2AM, it's built to the exact same method it was before. You know that build script is roughly going to work, and it's how it was built before, and it's in a consistent way, so it's going back to a known state.

Marley: So it's assurance around the repeatability of your infrastructure, basically.

Ben: It's also safer. It's entirely possible to create a server and physically destroy it through code, whereas if you do it in a cloud environment, you can do that, you go, "Ah, I’m not going to do that again," and then just change it and keep rapidly iterating through all the different servers that you're doing.

Liam: Yeah, absolutely.

Allan: It's also something we're quite bullish about in terms of whether or not we automate or manually create servers. I mean, I think philosophically we will not create servers.

Liam: Philosophically it's never in the console.

Allan: Yeah.

Liam: Right? Whether it's API, whether it's SDK, whether it's against DSLs, it is functionally used...again, we do have our opinions on the tools that we do prefer, or write our own. But yeah, functionally it is never in the console. It's never in the GUI.

Ben: I mean you don't really have an option, really. Like yes, if you, going back to that lift and shift analogy, yeah sure, if you're doing that then you could create a server through the console and log into it and set it up, and have a server.

Liam: Ah, but you can, you can still orchestrate degrees of automation through the console and all the rest of it...

Ben: Yeah.

Liam: You've got to remember it's not just about the server orchestration. It's about all the other coupled services with it. It's about how do I stand up an entirety of a system next to itself. And I want to adapt things like Blue-Green, and I want to be able to do promotional pieces like integrated unit testing or integration testing or smoke testing or treat any of the pieces as security tests on the platform to understand whether it's good or bad relative to the other ones on performance tests. They're critical aspects that sort of form part of that infrastructure's code. 'Cause it's not just spit on the server and just go, it's consistent. That's sort of been around for quite some time. It's the wrapper and everything else around it. It's the, it's the completeness, I guess.

Allan: Mm-hmm.

Liam: As horrible as the word completeness is. 'Cause nothing's ever really complete. Let's be honest.

Ben: Yeah...