Managing IT infrastructure can quickly become complicated, especially if organizations have to manually manage and configure all of the hardware and software needed to run applications.
The development of cloud computing and Infrastructure as Code (IaC) has completely changed how businesses are managing and maintaining their IT infrastructure, making it easier and less complex.
Hence, we have asked experts in the industry to shed light on Infrastructure as Code (IaC) and everything that it entails.
What is Infrastructure as Code?
According to James Fletcher, Lead Infrastructure and Automation Engineer at iPipeline UK, Infrastructure as Code is a method used by teams in which the infrastructure is described in a programmatic way. From this, you are then able to repeatedly create your infrastructure and deploy it using similar techniques as what would normally be used within an application delivery pipeline.
He points out that IaC works in various ways depending on the target hosting platform but most commonly the code is interpreted by a tool that will then make the necessary API calls to create the infrastructure.
Moreover, Isaac Perez Moncho, DevOps Manager at Growth Street, adds that using code to manage resources like servers or firewalls is not new. Indeed, sysadmins have been doing this for decades. However, the main change has been with Cloud Computing, which made it easier to create all resources you need with code, hence giving birth to tools like Terraform and Infrastructure as Code as we know it now.
IaC is then the process of providing and managing computing resources with configuration files, enabling the use of software development techniques to building infrastructure. It works by defining your infrastructure resources using files and a software development life cycle to their management.
A common way to do so would be by using Terraform and its language to define a series of resources in your cloud provider, like AWS. Once the resources are defined, you would be able to create and manage those resources via the command line, or a deployment pipeline, instead of using a graphical interface.
The best practices & strategies
Keeping your IaC code DRY is probably the most important practice to maintain, James underlines.
DRY stands for “Don’t repeat yourself” and simply requires your code to be written in a reusable manner so that equivalent resources are created in the same way throughout the stack. The advantage of this is your code can be more readable, robust, and much easier to maintain.
Another good practice to maintain, James continues, is to define standards such as naming conventions and security standards within your code. Hence, discussing this upfront and deviating as little as possible will go a long way in the early days of adopting IAC.
Isaac points out that the best practices for IaC are similar to best practices used for software development. Gruntwork has excellent resources on best practices. He recommends using IaC for everything, even for choosing your providers based on having an API to codify your resources or not, as well as hiring someone with experience to make sure the team in charge learns about the best practices and applies them.
From a strategy standpoint, James says that it is essential that you choose a solution that suits your business objectives in the long term. He states that you need to consider things such as where your infrastructure will be hosted (Cloud or on-premise, if cloud, then which cloud provider?), what skills do your team possess already and what can they learn. Writing IaC requires time to be invested in both your employees and the projects they work on, so be prepared to have an adjustment period before the benefits of using IaC are visible, but trust that the benefits far outweigh the initial investment.
A good idea is to choose something which won’t tie you into a single provider, but perhaps allow the technical team members to research and find what tool suits them.
If the business is not using IaC, Isaac proposes to use a gradual approach to import all resources and draw a line in the sand to create anything new in code. The gradual approach will allow the team to learn, the rule of anything new is created in code will make the situation from getting worse.
IaC for business?
As more businesses rely on digital services, Isaac underlines how important it is to use good practices to manage your infrastructure. IaC can help in many areas like getting ISO certifications, reducing the cost to build new digital services, troubleshoot an existing problem, and enforce best practices and security standards.
James adds that IaC is important for business as it allows teams to be far more efficient whilst reducing the risks speed would normally bring.
IaC can bring a whole range of benefits to any business.
According to James, it helps to minimize risks when moving code from one environment to another, it hugely reduces the time to create environments or scale-out existing ones based on the demands of your users. Besides, it also enhances collaboration by involving both operations, development, and security teams together.
For Isaac, using a software development life cycle to manage your infrastructure allows the company to enhance the infrastructure creation processes and give them auditability, repeatability, and, hopefully, consistency. It will improve the overall ability to troubleshoot problems, and enforce best practices.
He then gives two scenarios, as a very simple comparison:
- A team member creates an AWS RDS instance manually in the AWS Console, stores the credentials and access details in a password sharing service, and the teams start using it. That person may or may not remember to set all the settings as per the lengthy How-To in your internal wiki.
- A team member creates a new branch in the infrastructure repo for an RDS Instance using your RDS Terraform module, which embeds all the best practices you want like password length for the root user, use of backups, Mult-AZ for production, Enhanced monitoring, etc…
When the code is pushed to the repo a set of security and standards checks run automatically. Credentials are created in AWS Secret Manager and passed to the application’s configuration system automatically. The engineer creates a pull request which is reviewed by another member of the team, who can also see green ticks for the automated checks. Once the PR is approved and merged, the deployment pipeline automatically creates the instance.
…And the drawbacks
Isaac emphasizes that there are several drawbacks to using IaC. It’s not trivial to have good processes and tooling, which you’ll have to build. It requires experienced engineers to create IaC that serves its purpose without becoming a burden. Creating resources manually will most of the time be quicker, creating resources using good practices will most of the time be easier with IaC.
He points out that if you get the code structure wrong, it can become difficult to manage and change. All the current strategies are a series of trade-offs with escalating complexity. In the short term, it may appear as a big burden, especially if the team is used to create resources manually.
The biggest drawback for James is the startup cost. Indeed, like any new or unfamiliar technology, it takes time and investment into staff and processes to fully utilize the benefits of IaC. A lot of businesses give up too soon and waste a lot of time and effort.
The future of Infrastructure as Code
James believes that IaC will start to become the norm. With more and more people using it with Cloud services, and some even within their own data centers you could already argue it is already the norm and if you aren’t using it, then you should be.
‘IaC is definitely something that will be an important factor to any successful business in the future.’
Isaac states that he would not join a company that is not using IaC unless they are a startup in their first months, and part of his job would be to start using IaC. He thinks that it would be a waste of time and resources to try to build good infrastructure without IaC, and anyone trying would probably fail…
Special thanks to James Fletcher and Isaac Perez Moncho for their insights on the topic!