Let’s start by understanding how infrastructure was traditionally managed. Traditionally you would have an infrastructure team that would be assigned tasks that included creating virtual machines and any required underlying infrastructure to support them. This process was mostly manual, completed by an engineer accessing a management portal and using a point / click approach to deploy resources. Whilst this process worked well for on-premises infrastructure, which was mostly static, as we have transitioned to the Cloud and adopted a pay per minute model, it no longer makes sense.
Another compounding change is how software is developed. Software developers are moving away from building monolithic applications, which were well suited for virtual machines. Now they are adopting new technologies like containers to build microservices. The goal with microservices is to break an application down into small self-contained services that perform small tasks. An example of this would be at Facebook, deploying a microservice that is responsible for sending text messages to users. Instead of having this all on a single server, they would break out the part that runs text messaging and build this as a container. In the future, if they need to update the component, they can do so without taking down the whole platform and more importantly scale the task across multiple servers, datacentres, and even locations!
These changes have resulted in infrastructure becoming disposable. As a result, traditional management techniques no longer work. As we have now moved away from fixed cost infrastructure and moved to service orientated pay per the hour infrastructure, it makes sense to only use the resources that you need for as little as you need to. To demonstrate this let’s take a real-world problem. If you are going to be as cost-effective as possible in the Cloud, then you only want to run your task or process when it is absolutely required. Having an infrastructure resource for example a virtual machine running constantly is very cost-inefficient. To tackle this, you decide to shut down infrastructure when it’s not required. In the traditional infrastructure management methodology, you would need to send a ticket to your infrastructure team in the evening to shut down the servers and in the morning to turn them back on again. The result of this is that manual management of infrastructure no longer is able to cope with the demands of controlling a complex infrastructure environment. The solution is automation in the form of infrastructure as code.
Infrastructure as code is a list of instructions that describe how an infrastructure landscape should look. To demonstrate what infrastructure as code looks like we have put together a non-techie example version of a web server and database server. Here we are defining the infrastructure that will run in AWS.
Provider {
AWS
}
Network {
Subnet 10.0.0.0/8
}
Server 1 {
IP: 10.0.0.1
Disk: 10GB
Description: Web Server
}
Server 2 {
IP 10.0.0.2
Disk: 40GB
Description: Database Server
}
Using code like this allows us to ensure that the outcome (The infrastructure provisioned) is always the same. This means that we remove the human error elements and the contamination caused by installing and patching different versions of software on infrastructure resources. When we need to update we simply replace the infrastructure resource with a new updated one! Another benefit of infrastructure as code is placing our IAC (Infrastructure as code) in a source control system like GIT, enables us to see how our infrastructure has evolved over time. What was changed, by who and when? A complete audit log and detailed documentation all in one!
The ultimate result of this IAC is automation. Having our infrastructure provision using code allows us to automate an otherwise manual task. We can then use other data sources to define what infrastructure resources are required. During the day when a website is at its most busy, we might spin up more web servers, at night when the website is less busy, we will turn servers off to reduce cost. This elasticity allows us to get the best out of Cloud computing.
If you are looking to supercharge your Cloud capabilities whilst up-skilling your team give Next2IT a call, to see how we can help you unlock the true potential of Cloud computing today!
One thought on “Infrastructure as code: What is it? Why is it important?”
Comments are closed.