Infra as Code (IaC) - Automate or Die in a Mountain of Config
Managing 10 databases and 10 services manually is a nightmare. Why we had to put infrastructure into code even when the team was only 2 people?
3 min read
Doing Microservices without IaC is like trying to move a whole forest by carrying one handful of soil at a time. Sooner or later, you'll burn out or confuse an oak tree for a pine tree.
Context: The "Click-Ops" Trap
In the beginning, we only had 1 RDS database on AWS and 2 services running on EC2. Clicking through the AWS web interface to configure things felt relatively fast and intuitive.
But as we grew to 10 services, each service needed:
- A separate Database user.
- A queue on NATS.
- A unique set of Environment Variables.
- S3 access policies...
Forgetting to check a single checkbox or mistyping an environment variable began to happen more frequently. We'd spend an entire morning just trying to find out why Service A couldn't connect to the DB, only to realize someone had misconfigured a Security Group.
1. What is Infra as Code (IaC)?
Simply put, you describe your infrastructure (Servers, DB, Network) using code (usually Terraform .tf files or .yaml if using CloudFormation).
Why is it important for small teams?
- Reproducibility: Want to create a Staging environment identical to Production? Just run one command. No need to remember everything you clicked on the console months ago.
- Change History: Infrastructure code is also pushed to Git. Who changed the DB RAM? Who opened port 8080? It's all in the
git log. - Safety: You can review infrastructure code just like business logic code before applying it.
2. Tool Choice: Don't Overload the Brain
We debated between Terraform and Pulumi.
- Terraform: Most popular, huge community. But you have to learn HCL.
- Pulumi: Let's you use the programming language you're already using (like TypeScript/Go) to write infrastructure.
Our choice: Terraform. Because when the system fails, you need a stable tool with the most answers on StackOverflow.
3. Trade-off: Initial Time Investment
Learning IaC and writing code for it takes 3-4 times longer than clicking through a web interface in the early stages. But trust me: This investment pays for itself by the second month, when you need to scale the system or create a new service.
Lessons Learned
- Tagging is Vital: Every resource created with code must be Tagged (e.g.,
Project,Env,Owner). It helps you know where the money is going when you look at the Cloud bill. - Don't "Import" Manually: Once you use IaC, absolutely do not go to the Console to change anything. If you do, the state of reality and the state in the code will drift (State drift)—the source of many bizarre errors.
- Start Small: Don't try to code the entire system at once. Start by IaC-ifying the hardest things to remember, like Networking and Database users.
Conclusion
IaC is not just for large corporations. For a small team managing a complex microservice architecture, IaC is the "third hand" that helps you maintain sanity and precision in a world full of configurations.