When you’re an early stage startup, you’re expected to deliver product features fast. In such a highly competitive environment, time means absolutely everything. But in the race to build features quickly and release frequently, many companies are tempted to trade best practices for quick fixes.
In some instances, it pays to move fast and support your technical infrastructure later. However, it’s no secret that in order to handle growth, you need to spend some extra engineering time on the foundations. Bypassing foundational work can cause huge drawbacks, and if there’s one mistake that constantly gets made in the startup world: it’s not putting IaC in place early on.
We have too often seen startups opt for “easier,” manual solutions that are tedious and not reproducible. Typically problems arise in the following areas:
Most RnD leaders and CTOs usually have the overall architecture of the product in mind, but not how to manage and deploy the underlying cloud infrastructure. They know that ECS or EKS is the way to go, but don't foresee a way to properly provision the infrastructure, or how to make changes once their customers have come to rely on it.
For software developers, CI/CD is already the norm. They are used to developing code, and they're used to building it and deploying it with code. However, infrastructure is still seen as an external part of the code base and the CI/CD pipelines. In many cases, it is provisioned on the fly, manually from the cloud’s web console as opposed to applying infra changes through code—similar to the application code changes— which developers have the expertise to do.
In other cases that we’ve seen, there is an IaC base created by development teams without enough DevOps guidance, leading to nice pieces of code that are not connected in a structured way, which makes them much harder to manage over time.
Another factor that contributes to a lack of guidance is the fact that many startup teams have experienced developers, but don’t have experienced DevOps engineers. This is because naturally when you start building your product, senior developers are a must-have, whereas hiring more senior DevOps engineers seems like overkill. While this is partially true—there is not enough “scale” for them—it doesn’t change the fact that architecting and coding cloud infrastructure well is something that requires expertise and experience.
Hiring a DevOps engineer will play a crucial role in speeding up the adoption of IaC. In this blog post, we explore the main misconceptions and obstacles young startups face when hiring a DevOps engineer, offering tips and strategies to overcome them.
Without IaC in place, you’ll find yourself spending valuable time and money trying to resolve issues manually. After reaching a certain scale, manually provisioned infrastructure will become a serious headache. Here’s why:
We worked with a growing startup that managed EVERYTHING manually. They didn’t use IaC, therefore found it hard to recover and find the root cause of breaks in production. Management was unaware of the tremendous risk associated with using one experienced developer—who also did a bit of infra (manually of course). This developer left the company and no one knew the manual changes that were made. The company then had to hire someone new to reverse-engineer what was done, costing them a considerable amount of time and money.
Another client we partnered with had a developer who changed network settings manually on Thursday evenings and then went home, leaving the rest of the team struggling to understand what had changed to cause an issue.
It's hard to define the correct moment for when your team should invest in IaC, although many people don't like this answer, it really 'depends' on many factors like the maturity of the product, the pace of the tech stack changes, the dev team size and its expertise in cloud infra.
Here are a few ideas for how your startup can approach the initiation of IaC implementation:
Play with new technologies in a sandbox and feel free to make POCs not as code, but once the tech stack is chosen, deploy the infrastructure as code. As soon as you know you have your first real bulk of paying customers (and a grasp on the initial infrastructure), we recommend you start managing the infrastructure as code.
Deploying infrastructure as code is not an absolute truth. When learning new technologies or performing POCs in sandbox environments, it’s fine to deploy infra manually in some cases. Our recommendation is to establish clear guidelines for infrastructure sandbox environments, if possible, as a separate cloud account/project. We also recommend setting up budget alerts for sandbox environments to catch “forgotten” test resources on time.
The earlier you start with IaC, the fewer issues you face with dev team velocity, production outages, and uncontrolled access in the future. To achieve it, we recommend choosing Terraform as your IaC tool, and utilizing its official and community-supported TF modules, rather than writing custom in-house IaC manifests ( Terraform AWS modules | AWS Integration and Automation repos | Google Cloud).
It can be challenging to explain to management why IaC is important, and there’s no definitive timeline for when your young team should begin to move away from manual processes. You’ll need to take note of the fact that once you do things with IaC, you need to continue. This may increase the time that it takes to implement infrastructure changes, especially when compared to doing things manually. Unfortunately—from management's point of view—you will be making changes slower to implement, making the value of IaC a tricky one to explain.
Here are some approaches you can use to win them over:
Implementing IaC can help you bring your cloud infrastructure to a new level. It may not be easy to master, but the invested efforts pay off when the infrastructure is well-architected. Remember, you can start manually. But once you have defined the core tech stack of your application, you can gain a lot of value by migrating to IaC—leaving mainly sandbox playground environments out of scope.
To make it an organization-wide initiative and remove internal objections, spend some time talking to management about why IaC is crucial. When choosing the best IaC solution for your needs, take into account how you’re going to manage your infrastructure code over time. As the amount of the infrastructure and the environment grows, it’s helpful to have the support of a big community relevant to the IaC tool you’re using. This will increase the likelihood of your next DevOps engineer coming to you with the relevant experience to speed up your infrastructure provisioning process.
IaC is a crucial part of the DevOps movement. If you think of cloud computing as the first step to solving many of the problems caused by manual IT management, then it’s fair to say that IaC is the next logical step. By employing IaC to automate repetitive manual processes and manage development, testing, and production environments, complex systems can be efficiently managed with reduced risk. Plus, it lowers costs and improves efficiency at all stages of the software development lifecycle.
Ready to up your infrastructure game but not sure where to start? The journey begins with understanding your unique needs and challenges. Our DevOps experts are here to guide you through the best ways to implement IaC, ensuring a seamless and efficient transition. Contact us today to learn more.