A lot of my work over the past few years has involved introducing Terraform into teams that are unfamiliar with both Terraform and the AWS resources we’re building with. The challenge throughout has been to train each developer while ensuring high team productivity by delivering working software. I have not always been successful, but I’ve learned a thing or two along the way.

Terraform has changed a lot since I started using it back at the end of 2016. Getting into a technology early is like stepping on a treadmill—you’re going to have to work to stay in the same place. How can you introduce this technology into a working team while buffering them from the treadmill effect?

Also, when you’re programming with infrastructure you can’t just spin up a local instance of a service for a developer. Everything has to be built in the cloud. How can you make it easy for developers to create working environments for themselves? And how can you prevent developers working on the same service from stepping on each other’s toes?

Finally, Terraform is not prescriptive in how to architect your infrastructure. This is probably the single hardest thing for developers to overcome when they start working with Terraform. Terraform provides a lot of primitives, but it’s up to you to assemble them. How can you create a coherent architecture shared across services that a developer will find familiar even as they move from service to service?

Well, I wrote a script for that.

Introducing Fenna

fenna is a thin wrapper for Terraform built around a set of conventions extracted from my experience introducing Terraform into teams. It simplifies backend management and developer onboarding while not being overly prescriptive in how you structure your Terraform or your architecture.

I have more to share on how to apply fenna to your work, but in the meantime, give it a try and open an issue if you have any questions.

Fenna 2

I’ve just released Fenna 2. Check it out here.