Infrastructure as code? It sounds like something you'd get if you mixed a sysadmin ,a developer,
too much alcohol, and waited nine months; but it's actually pretty clever stuff.
In fact I would go as far as to say that if you're deploying to the cloud
and you're not using infrastructure as code... you're doing it wrong!
Welcome back to The Pro Tech Show - the place for tech, tips, and advice for IT Pros and decision-
makers. Infrastructure as code isn't limited to the cloud. You can do it on-premises, too.
On-prem though, you need to decide whether it's worthwhile having a set of infrastructure to
manage your infrastructure. Is the overhead of having this management layer less than the time
it saves you? The answer to that will depend on the scale of your infrastructure as well
as how repeatable it is. By that I mean: does every server do something different or are you
frequently rolling out more of the same? The reason I'm going to focus more on the cloud in this video
is because whilst you can make an argument to do infrastructure as code on-premises, in the cloud
it's getting really close to being a no-brainer for a lot of workloads. The key difference is
that debate about whether the infrastructure overhead is worth the benefit just doesn't
exist in the cloud, because the overhead is handled by the cloud vendor. It's part of their platform.
So with a lot of that hard work already taken care of for you the case becomes very compelling indeed.
So what is infrastructure is code? Allow me to show you. I'm going to jump into Azure for this. You can
do this with AWS and Google as well. In fact the tool I'm going to use works with all of them.
Let's quickly create a Windows virtual machine. I'm just going to fill in some basic details here,
nothing fancy. This isn't the best practices guide - I'm going to blow this all away when I'm done.
It's just to show you the process in case this is new to you. I will fast forward the video at
certain points, because watching this deploy in real-time is going to get boring quickly.
There you go - there's my virtual machine. You see I have also created some other resources
as I was going along; like networking, and a disk for the operating system.
I'm not even going to bother booting this up. I'm just going to clear it all away. Yhe point of this
was simply to show you what the "normal" way of provisioning resources in the cloud looks like.
Now I am going to show you what it looks like using infrastructure as code. I'm going to use
a tool called Terraform to do this. Terraform works across different cloud platforms so if
you use a mixture of AWS and Azure this is a great option for you. We can define the same
resources in a text file. There's my networking: the virtual network, subnets, the network interface;
and here's a virtual machine itself with its operating system drive. Let's add in a SQL
server and a database while we're at it, because why not? If I run Terraform it's going to take
that infrastructure configuration I've defined and it will go and build it in Azure for me.
I appreciate I'm skipping over a lot of detail here. This isn't going to be
a Terraform tutorial any more than it's in Azure tutorial.
I've got some interesting concepts I want to introduce you to, so watch the end and if you
find this as exciting as i do then go find a tutorial and learn to do it yourself. Here we go
though - we've got our new virtual machine and our SQL database resources provisioned automatically.
Now, already this might have your brain turning over. There are possibilities for saving time
here, but we're just getting started. Repeatability is another great benefit. I can take that file that
defines my infrastructure; run it in dev, test, and live; and bang, bang, bang: three perfectly replicated
copies of my infrastructure. Or maybe instead of a dev, test, and live setup I need to provide some
kind of self-service provisioning to customers or internal business units. Maybe I want to set
up a lab or a training environment that needs to be blown away and recreated on a regular basis.
If I've got the solution defined in a terraform file it can be quickly sprung up at the click of a
button, without the end user needing to understand how it fits together or how to actually build it.
Hold that thought, though; let's talk scalability. Let's say instead of one database and one virtual
machine I need three databases and five virtual machines. I can change just a few numbers in my
Terraform file here, run it again, and there we go: three databases and five virtual machines.
Obviously they're not connected to anything. There are no load balancers or firewall rules
for starters, but you get the idea. I can define all of that in the Terraform file as well but
frankly I doubt you want to sit there and just watch me write code for the next few minutes.
You'd rather use that time to click the like button and subscribe to this channel, I suspect!
OK, so this is fast, it's repeatable, it's scalable, it's basically a script... right? No.
It's not a script, it's a blueprint. Let me put it a different way. A script is like a set of directions -
straight for a mile, left at the lights, third turn on your right, etc., etc. That's fine, but directions
are only useful if you're starting from a specific, known location. If you give me directions to get
to the supermarket from your house and I try to follow them from my house I'm going to get lost.
If you give me an address, though; I can pop it into my sat-nav and it will
figure out the unique set of directions I need to get from my starting location.
That's basically what Terraform does. The infrastructure definition I give it is my
desired end-state, the destination address, my target infrastructure. Terraform figures out
what changes are needed to achieve that target, and applies them. Let's say I don't want three
databases and five virtual machines, I want four of each. Let's update my Terraform file.
If this file was just a script and it blindly created whatever was in it then when I ran it
I'd end up with seven databases and nine virtual machines, which isn't what I want. I could delete
everything that exists before running it to start over, but that would be destructive and wasteful.
Instead, if I let terraform generate its plan it tells me what it's going to do. It has figured
out that to modify my current infrastructure to achieve my desired target it needs to add one new
database and destroy one existing virtual machine, so that's what it's going to do. The terraform file
isn't a series of steps; it's the definition of my target infrastructure and it's written in
code. Let that sink in. How do developers store their code? In source control. We can do that, too.
If all of our infrastructure is built using Terraform it's essentially self-documenting.
If we keep it in source control then we can accurately version-control our infrastructure
and track changes to it. How many times have you seen something stop working, and it was working
yesterday, so what's changed? Nobody knows. Everybody is always mysteriously quiet when this happens,
aren't they? If you build your infrastructure from code, and the code is version-controlled, you can
see exactly what has changed. Not only that, but if version 2.3.4 has a problem and you need to revert,
you just run the file for version 2.3.3. Terraform will figure out what changes are necessary to get
you back into that known good state, and it will go make that happen. This has implications for disaster
recovery as well. If you've sat any technical exams one of the questions they love to ask
is "What is the minimum amount you need to back up to be able to recover your service?".
Of course, in the real world you probably don't back up the minimum amount. Yes, if you only back
up the data itself it is possible to rebuild all of the infrastructure around it, but by the
time you've done that: how badly has the business been impacted in the meantime? So normally most
of us probably back up everything, so we can just hit the emergency button and restore everything.
Well, that's a luxury that costs money. If you've got your entire infrastructure defined in a file,
there's your infrastructure DR plan. You just need your data and somewhere to run that file.
OK, to be clear disaster recovery planning is a lot more involved than that,
but being able to type "Terraform apply" and have your entire infrastructure just rebuild itself
automatically? That's really going to help! Funny enough, another benefit of infrastructure as code
is how quickly your infrastructure can be destroyed as well. Now why would you want
to destroy your own infrastructure? Well take this stuff I've just built for your benefit. If I leave
it there it's costing me money, and I have no need for it once this recording is complete.
If I run "Terraform destroy" it will go and remove all of that infrastructure it's created,
returning me to zero. Except not actually zero; and that's important. I have other resources in Azure
that I really don't want deleted by accident. If I have a terraform file for a specific solution
I can safely and completely decommission that solution without affecting anything
else running, by using the "destroy" command. Which is what I'm going to do here. If I need to show
this to someone else or my video messes up and I need to re-record it that's fine. I can run
"Terraform apply" and bring it all back. That's one of the really nice things about infrastructure as
code, and a way it could help save you money in the cloud where you typically pay by the second.
Now we can't talk about infrastructure as code without mentioning DevOps. "DevOps." There.
I mentioned it. Come on, let's be honest, if DevOps is your thing then you were sold at "source control".
One thing I haven't really talked about is the configuration inside the servers themselves.
This is where you may have come across technologies like Puppet, Chef, Ansible and
PowerShell DSC being mentioned. There is some debate about terminology here. Some people would say that
spinning up servers and serverless infrastructure components using code is "infrastructure as code",
and managing the configuration inside those is "configuration as code" or "configuration management".
There is valid logic to that. The two sets of tasks occur at different levels in your infrastructure,
and generally speaking use different tools as well. You might use Terraform to build the servers
and network components, then Ansible to manage the configuration of the servers and switches.
There's a bit of overlap; but usually you'll have a clear divide of these tools build
the infrastructure, and these tools manage the configuration of the infrastructure. That said, both
of these tasks would typically set within the remit of an infrastructure team and whether you call it
"infrastructure as code" or "configuration as code", the concepts are incredibly similar. The best way I can
summarise this is that "infrastructure as code" and "configuration management" are different entities,
but both fall under a general umbrella called "infrastructure as code". I appreciate that can make
it a little confusing to understand what exactly someone might mean when they use the phrase, but
that's where the world seems to be with it. So far everything I've mentioned falls into this section
of the diagram. As for the configuration management side of infrastructure as code? I think that's going
to have to be another video. Comment below and let me know if that's a video you'd like to see.
As for this video? I think it's time to bring it to a close. Hopefully this has given you a taster
of what might be possible. Let me know if you've switched to using infrastructure's code, and share
the good and the bad that you've experienced from it. If you found this useful, hit the like
button and consider subscribing if you haven't already done so. YouTube has popped another couple
of videos up here for you. Go ahead and check those out. If you liked this one they might be
your sort of thing, too, because I made them. Thanks for watching, guys. See you next time!