Why I Chose Terraform #

If you are comfortable enough with the way your stack operates, then it is better to preserve it in the form of infrastructure as code (IaC). IaC can tremendously help us in managing our infrastructure stack with ease, especially if you plan to grow your infrastructure.

There are lots of IaC tools out there, and CloudFormation seems like a no-brainer choice because of its seamless integration with other AWS services. For now, I use AWS as the only vendor in my tech stack. But, I cannot simply rule out any possibilities of using other cloud providers in the future, especially after Azure starts to chip away at AWS’s domination in the cloud computing market share.

Therefore, I decided to pick Terraform as the IaC tool of choice mainly because of its platform-agnostic characteristics and its declarative configuration language. As I dug deeper into Terraform, I also found that their supporting systems (documentation and registry) are quite impressive.

Despite my minuscule infrastructure, I still think it’s harmless to get used to the best practices in managing it properly like big organizations do. Principally, IaC can help me enhance every aspect of my infrastructure, including cost, security, and scalability. But, one thing that I really like about using IaC is how convenient it is for me to document and inspect my infrastructure through lines of code rather than endlessly wrestling with the ever-changing AWS console UI.

Terraform Project #

This is a simple Terraform project that leverages existing public modules from the Terraform Registry to build a practical S3-hosted personal website suitable for personal usage like a blog.

I chose to use public modules from the Terraform Registry because they ticked all the boxes for a personal project. These modules are well-maintained by the community, comprehensive, and easy to apply. However, if you want to manage distinctive infrastructure for business or professional use, I strongly recommend using private modules. You can also share your private modules with limited groups for better change management.

As Terraform has become a household name in the cloud community, there are many emerging “denominations” on how to properly organize modules. There’s no absolute right or wrong approach, but I prefer using simplest approach available because it’s easier to maintain and understand, especially when involving non-technical people.

I believe that edge cases, though always possible, remain rare occurrences. The best thing we can do is create simpler projects, as it’s almost impossible to please everyone by covering all possible edge cases. Instead of trying to bring every solution to the table, creating overly complex modules or projects could backfire on us.