Avoiding Common Pitfalls: Infrastructure as Code

What is infrastructure as code?

Let’s clarify some terminology first. Infrastructure refers to the basic technology setup that supports your business, like servers, networks, and databases. It's the behind-the-scenes foundation that keeps your software and applications running smoothly.

Infrastructure as Code (IaC) is a way to manage and set up your tech infrastructure using code, similar to how software developers write code for applications. Instead of manually configuring servers or networks, you write scripts that automatically build and manage these resources. This approach makes it easier to keep everything consistent and repeatable.

Why should you care about that and why is it so important? Infrastructure as code is the only document you will ever have that explains what you’ve deployed and exactly how you’re application works. Let’s consider the alternative and assume you’re using AWS to deploy resources. If your developer simply logs into AWS and starts clicking buttons. Let’s click some buttons to deploy a server, let’s click some more buttons to deploy a database, so on and so forth. It’s not reasonable to capture the details of every button that was clicked - what was the configuration of the server? What region was it deployed in?

By using infrastructure as code, all of those details are captured. The code will be a living document that is used by you and your team to ensure your current environment is aligned with what you expect.

Example
Let’s look at a quick example, of what this looks like. In the image below, you can see “ec2.Instance” and “ec2.AmazonLinuxImage”. Now, it’s clear to us that we’re using an EC2 instance, and we’re using Linux (e.g. we’re not using Windows or Mac).

The risks of deploying without infrastructure as code

Deploying without using Infrastructure as Code (IaC) can lead to significant risks and challenges. Without IaC, manual configurations are prone to human error, leading to inconsistencies across environments that can cause unexpected issues or downtime. It’s difficult to track changes, which means you might not know who made what changes or why, making troubleshooting and auditing nearly impossible. Additionally, scaling or replicating environments becomes time-consuming and error-prone since there’s no automated way to ensure everything is set up exactly the same way each time. Overall, deploying without IaC can result in unreliable infrastructure, increased operational costs, and slower response times to issues.

The importance of following best practices

Following best practices in infrastructure management is crucial for maintaining a reliable, scalable, and secure environment. One key best practice is understanding the difference between stateful and stateless resources and keeping them separate.

Stateful resources retain data or session information between interactions, like databases or file storage systems. If these resources are disrupted, the data they hold can be lost, which is why they require careful handling. Imagine accidentally losing all the information on your active users.

Stateless resources, on the other hand, do not retain any data between sessions, such as web servers or APIs that process requests independently. By keeping stateful and stateless resources separate, you can design systems that are easier to manage, scale, and recover from failures. This separation ensures that critical data is protected and that your infrastructure remains robust and efficient.

Example

Example Imagine you have a growing e-commerce app, and to handle the increasing number of users, you decide to upgrade your web server to a more powerful one. The web server is stateless, meaning it doesn’t store any user data between sessions; it just processes incoming requests and sends back responses. However, your SQL database, which is stateful because it stores all your customer data, order histories, and product details, also happens to be running on the same server.

In your haste to upgrade, you accidentally apply the upgrade to both the web server and the SQL database without realizing that the database needs special care to preserve its data. During the upgrade, the database is wiped clean, and all the crucial information it held is lost. Now, despite your app running on a more powerful server, you’ve lost all your customer information, orders, and inventory data, leading to a major disaster for your business. This example highlights why it’s so important to keep stateful and stateless resources separate and to follow best practices in managing each type of resource.

Recommendations to get started

If you’ve read our article on the Cloud (link here) then you know we recommend using AWS. If you’re using AWS, then we recommend using CDK. CDK stands for cloud development kit. AWS developed an open-source software development framework for defining cloud infrastructure in code and provisioning it. CDK is specific to AWS so it won’t work on Azure and GCP.

If you’re using Azure or GCP then there are two great options: Terraform and Pulumi.

Terraform has been around since the early days of the cloud. It’s an intuitive and easy-to-use language. Hashicorp is no longer purely open source though. They updated their license so that if you compete with HashiCorp (the owner of Terraform) then you have to pay to use it. How is competition defined and exactly who is impacted by this license change? We encourage you and your legal team to read their FAQs (link here). For everyone else following along with our recommendations, that’s one less step you have to worry about.

Pulumi is a great open-source solution that works with all cloud providers. If your company would need to leverage multiple cloud providers then Pulumi is a great solution. This is most likely the case for large enterprises; however, some B2B SaaS offerings have similar requirements. In those situations, keeping all your infrastructure within the Pulumi ecosystem is a great option.