Welcome to Anvil

I remember filling out a ServiceNow ticket and waiting a week for someone on another team to spin up an EC2 instance for me. Then I started talking with a coworker about a security breach we had been reading about. A developer needed to test something “quickly” and left the EC2 instance and AWS account exposed, which led to a hefty Bitcoin mining bill. One process seemed too strict, and the other was the Wild West; there was no middle ground.

As someone with a weird obsession with Infrastructure as Code, I have been in positions to help teams upskill and adopt better practices. I thought, “Wouldn’t it be cool if it was easy to deploy resources but hard to deploy insecure resources?” Fast forward a little, and I’m knee-deep in a framework shaped by my experiences and consistent issues I see across teams of all sizes.

My name is Damien Pace, and I have been creating Anvil for a few months now. I have 6 years of experience spanning backend software engineering, Solutions Architect roles, and, currently, a Senior Cloud Consultant.

I have been blessed to find my way into this industry and be in a position to work as an individual contributor while also helping teams upskill and adopt better practices. I hesitate to say “best practices” because no situation is perfect, and many things can make projects stall.

I understand if you are asking why anyone would build an IaC tool. Great question. Many great tools already exist, but each has its own problems. But I have always found that most tools suit either DevOps-heavy teams or developer-led teams, with little room to move between them.

CloudFormation is verbose and is written in YAML; I don’t want to do that anymore. CDK is built on top of CloudFormation. Both are great going forward, but a nightmare to go backwards; if you design it a certain way and plans change, you risk corrupted stacks and end up passing around a bunch of hard-coded strings. It feels like deleting resources takes as much planning as creating them. Have you ever tried to work with nested stacks when something goes wrong? Not fun.

On the other hand, Terraform is a popular industry choice. I am on the side that Infrastructure as Code should be actual code, and Terraform has a learning curve for brand-new people. The syntax and structure of Terraform make it very hard to read and know what’s going on unless you actually understand HashiCorp Configuration Language and the ins and outs of Terraform. The deployment engine is the best by far in my opinion.

Pulumi seems to land in the middle: you can use code like CDK; since it’s real code, you end up declaring everything in a dependency order anyway, and you don’t get the full benefits of the powerful graph-based engine.

I have used SST and even contributed to creating the DSQL component for that project. I love that project and have a lot of respect for the team that built SST. It has been a massive inspiration in Anvil; if you have used SST, you will see a lot of similar syntax and functionality.

The team behind it has shifted priorities to OpenCode, which, as of this blog, has 17m monthly active users, and its development has now slowed to an almost stalled pace. Not to the SST team’s fault, I found it very hard to get approval at a big, publicly listed company because, at face value, there was no way to see what was being deployed or the wiring behind the scenes.

Anvil is the result of all these experiences, bundled into a framework that still has an escape hatch so your infrastructure fits your needs. You should be able to develop and deploy with confidence that you won’t be paying by burning a hole in your pocket or risking your company’s reputation because a security breach could have been avoided.

Why should you use Anvil? I have worked at a pre-seed startup, a scale-up that’s hit real market value, and a multi-account enterprise business. I’ve developed cloud-focused solutions at all of them. Over time, many problems were the same, and they always came back to the same thing; they probably would have been better off having something like Anvil from the start.

Anyone can use this - if you are starting, it helps to have good AWS and account hygiene. It’s better to have it and not need it before you get to a situation and realise you have no clue what’s actually being spent on the account, or that you don’t have any logging enabled anywhere.

On the other side of the coin, if you are in a complex multi-account environment where everyone is doing different things, Terraform one team, CDK the other, clickOps for 85% of the team. You can do your part and know your cloud infrastructure is safe, and if there is a security audit, you don’t have to halt your workload to gather evidence; it’s all in code, and it’s been safe since day one.

You can still develop quickly or provision shared infrastructure while knowing it’s secure and cost-effective. I like the idea of shifting left, but why shift at all if it's handled from the start?

Thanks for taking the time to read about Anvil's start. Please star Anvil on GitHub and follow along for what’s coming.

Anvil is just getting started. I want to do my part to make the cloud safer for everyone and help you own YOUR infrastructure in your account. It’s your infrastructure, not mine.

Damien.