When we started Wet Dog Weather, we were really excited about Infrastructure As Code. If you’re not familiar with it, you lay out your servers, DNS, caching, scaling, containers, and so forth in code. Then, you run the code, and it sets it all up for you.
Our language of choice is Python, and our infrastructure is AWS, which means we use the AWS Cloud Development Kit. How did that go?
The Good: Seamless Infrastructure Provisioning
We’re still using it, so that says a lot. It mostly works as advertised so let’s start with the good.
Python bindings work and they’re pretty logical to use. The toolkit is updated regularly and there’s a deep well of answers online. Some are even correct!
A key goal was standing up stacks for development and multiple stacks per client. Sure enough, standing up a new stack is very easy, once you’ve sorted out the basics.
Challenges and Pain Points
The Python bindings work, but they’re clearly from another language and can be confusing.
Modifying an existing stack doesn’t work well. I have trouble getting it to update containers and restart load balancers. Your mileage may vary.
The error messages can be very weird and you find yourself digging through CloudFormation to figure out what happened. Deleting a stack, which is just CloudFormation, is fine except for s3 where it largely just punts.
You can see CDK addressing some of this with its own Lambda functions.
Lessons Learned
AWS wasn’t designed to do this. CDK sits on top of CloudFormation, which was a later addition. This is a tower of chairs being held upright through engineering muscle. It works well enough.
Overall, 4 stars out of 5. I would Infrastructure as Code again.