Infrastructure as Code
Infrastructure as code is the idea that we can apply similar practices from version control systems to your infrastructure. The benefits? Visibility into your project infrastructure, greater automation, and control, rapidly tearing down and spinning up servers when and where you need it.
Full Transcript Below:
Cody:
And we know what’s deployed is actually kept track of, and is what we think it is right now.
Cris:
What is infrastructure as code? What does that mean? How does that apply?
Cody:
Modify it, keep track of the state, and make sure the server is exactly what you think it is.
Cris:
What are some other benefits of infrastructure as code when it relates to DevOps?
Cris:
Cody, today we’re jumping in on what I think is a very interesting topic to unpack, but it’s really a buzzword that’s floating around in our industry right now called infrastructure as code.
Cody:
Yeah.
Cris:
So, very buzzy term. There’s a lot to unpack there. What is Infrastructure as Code? What does that mean? How does that apply?
Cody:
All right. So, traditionally, we would use something like Git or some sort of version management control, for any type of code that exists within a software project, right. But when it came to infrastructure, i.e. the physical hardware that code is going to live on when it goes to production, or even in a Dev environment, there wasn’t really an easy way to orchestrate that, and to keep track of what is set to what. We do have Ansible and things like that, that can go and automatically change stuff. But how do we know that the stuff that was changed is still the same as the last time we saw it? How do we know what’s deployed is actually kept track of, and is what we think it is right now? Instead of just blindly sending in a script to change it, that is not super state aware.
Cody:
Ansible can be somewhat state aware, but not the whole everything within the server. So, that’s kind of where infrastructure as code comes in. Because what it does is, it allows you to take an entire server’s configuration, and basically make a file that creates that, using software like Terraform, is a really common one. That’s the most popular one right now.
Cris:
Right.
Cody:
And what that does is, you basically write a big configuration for your servers, tell it, “Okay, you’re going to have private IP addresses. You’re going to be called this. You’re going to have this much memory. You’re going to have this much that. You’re going to have this hard drive.” And then afterward, run this Ansible script to set yourself up or something of that sort. And you create that and check it out into a code repo, like Git, so you can keep track of it and edit it just like a normal software project, pull request this feature in instead pull request this size of random access memory and something of that sort.
Cris:
Oh interesting.
Cody:
And then push that up and it automatically can deploy. Or you can even do it locally and it’ll modify it, keep track of the state and make sure — or the server is exactly what you think it is. And that’s the whole goal.
Cris:
So, that seems very beneficial obviously for people like yourself being head of a DevOps department, for people working within large server architecture spaces. So yeah, let’s unpack that. We touched on them a bit, but what are some other benefits of infrastructure as code when it relates to DevOps?
Cody:
Well, yeah, the biggest thing here is configuration control. A lot of the time with various systems, whether it be Nginx, systemctl, anything else that lives on the server, let’s not go into an item, right?
Cris:
Sure.
Cody:
Anything that lives on the server, a lot of the time you end up with not a lot of control over what’s actually currently inside of a configuration. And keeping a central area where that can be, whether that is Terraform itself or another service, in addition, to Terraform to keep track of that stuff, that is hugely beneficial to know what’s actually deployed because a lot of the time, the only other way is to literally just SSH in and look, and that is how you know.
Cris:
Okay.
Cody:
And that can get really cumbersome when you’re starting to talk about clusters of servers. Now that said there, this is a little bit counterpoint because I’ve seen Terraform be used primarily with non-containerized services with Docker.
Cris:
Okay.
Cody:
So, typically it still kind of fits into that world of non-containerized services. I’m sure there’s a way to do it with containers, I just don’t often see it that way. And then there’s Docker, which is usually a whole separate game, which does not involve that. But regardless, infrastructure as code is the answer to traditional deployment, how to keep track of everything. That’s typically what you’d use.
Cris:
Okay. Then, I’m going to unpack this a little bit further.
Cody:
Sure.
Cris:
And fully because I don’t even understand completely. What’s the difference between what we would say is a declarative and imperative approach of kind of working within this whole paradigm of infrastructure as code?
Cody:
Yeah, for sure. So, I think a good way to look at declarative versus imperative, is that I believe imperative would be a lot like Ansible. And that is saying, hey Ansible, I need you to set up these things. And Ansible says, okay, I’m going to do those things in that order you gave me. Whereas declarative with Terraform says, hey Terraform, I need you to set up these things. And Terraform’s going to look at that and be like, okay, I know what the goal is. I’m going to figure out how to get there. You’re going to declare what needs to be done and then it’s going to figure out how to do it.
Cris:
Oh, got you.
Cody:
Yeah.
Cris:
So, the difference between: go walk this letter down the street and put it in this mailbox so it gets to said destination. You say, “I want to get to here,” and it basically determines how to get it there in a way.
Cody:
Correct. Yeah. That’s a hundred percent true.
Cris:
Interesting.
Cody:
Yeah. And that has pros and cons because at least with Ansible, if something is executing in the wrong order, you can just switch your code around and it’s now the right order. Whereas Terraform, if something is executing in the wrong order because you need it to do it in a way that it doesn’t know is the correct way, which rarely happens, but I’ve experienced it.
Cris:
Race condition.
Cody:
You kind of have to… Not even race condition stuff. It’s still synchronous. Yeah. Not everything is a race condition, but you kind of have to hack around it a little bit. You have to figure out what order will naturally want to do things and then kind of just work with what its rules are so you can get things to go the way you want them.
Cris:
That’s cool. So how are we, I think it’s kind of final thoughts moving ahead because there’s just a lot of information in here, so I’d love to see the tangible, how are we here at Bixly kind of leveraging infrastructure as code, either currently and where are we looking to kind of go and grow with this for the things that we’re not yet doing?
Cody:
I think it’s still trying to find a little bit of a home. I see infrastructure as code principally used in larger enterprises. We’re talking clusters of servers that are at least in the double digits, a lot of the time. But I think that that’s where we’re primarily using it, is to help our clients manage those clusters and slowly convert them into using infrastructure as code. So, if they need to spin down a server, add another one to a cluster, it’s as simple as one command, and it’s a really quick process. But when it comes to where we’d like to start using it probably for one on more own internal stuff, which is important.
Cris:
True.
Cody:
And then on top of that would be for smaller customers, because there’s still a lot of benefit to having even a non-clustered server as infrastructure as code because you can very quickly know what is set up and what is going on. And if there’s an issue with the server, you can tear it down and make it again within just a couple of minutes. And that’s a really valuable tool to have because sometimes server setups, especially for legacy stuff, can be almost an exploration in and of itself. And it can take days to weeks depending on how crazy it actually is. So yeah.
Cris:
Got you. I mean that’s a good point, that it doesn’t have to just be for these large companies, it can be for the smaller ones. And again, yes we are moving more towards internal processes on our side of trying to connect this in with our toolsets and how we’re doing stuff right now. So, I love it. Any other final closing thoughts?
Cody:
Yeah, absolutely, actually. There’s one more thing I’d like to add.
Cris:
Yeah.
Cody:
And that is, one of the biggest benefits I see through infrastructure as code is that, let’s say you are on AWS and you end up hating AWS billing structure because Amazon wants to make more money and they’re going to more for something you use a lot.
Cris:
Sure.
Cody:
And you find another host. It’s so easy to switch now with infrastructure as code because you just tear down the server and then use the same code with a different adapter and go pop it up on Linode or Heroku or something. And it is — just switch the DNS record. You’re done, job done. It was 30 minutes, in theory.
Cris:
Nice.
Cody:
So, that’s a really cool aspect I’ve seen, is people just kind of hop around to the best hosting provider for their large clusters that has the cheapest option for their stuff. That’s a lot of the reason I see infrastructure as code in addition to the control aspect of it, so you know what’s going on.
Cris:
Cool. Not only can you control it, but you can easily pivot it and move it wherever you need it to go.
Cody:
Exactly.
Cris:
The best fit your business strategies and mindset, so.
Alexandra:
Thank you for joining us for this episode of Bixly Tech Tuesday. I hope you enjoyed that conversation with Cris and Cody as they discussed the idea of infrastructure as code, a DevOps principle that’s really popular right now. If you have any questions at all, go ahead and leave them in the comments section. And don’t forget to check out the description box down below. We have a bunch of really helpful links for you guys, including a link to our free custom software guide, as well as a link to our website bixly.com. And right at the top of our website, you’ll see a button that says get my project roadmap. And that gives you a free 60-minute call with Cris, to talk about your next app idea. Until next time, this has been an episode of Bixly Tech Tuesday.
Originally published at https://blog.bixly.com on February 22, 2022.
