Hello all!
Welcome to the next issue of the Tidy Cloud AWS newsletter! In this issue, I cover CloudFormation and some thoughts around it as a service. A recent blog post from AWS triggered this. What are your thoughts on CloudFormation, its past and its future?
Enjoy!
The state of CloudFormation
AWS recently published a blog post titled The history and future roadmap of the AWS CloudFormation Registry, which is a partially correct title. The blog post also contains information about the history of CloudFormation itself. I found it to be an interesting read!
CloudFormation started in 2011, when AWS only had a handful of services, and not that many feature updates. The CloudFormation team handled all service updates.
This explains a lot why it took so long time sometimes to get any support in CloudFormation for new features in AWS services, if they appeared at all.
In 2016, the responsibility was delegated out to each service team to add the CloudFormation support through an internal self-service platform. This was still not good enough. Another project worked on making it easier and more standardized to add CloudFormation support.
There seems to have been a fair amount of evangelization needed inside AWS to get service teams to adopt this new model as well. They also exposed this model to customers via the CloudFormation Registry in 2019, and with the public registry in 2021. The article also mentions migrating the AWS::RDS::DbInstance resource to the new model in September 2022.
They also mention the Cloud Control API, which supports this newer resource model, and which allows 3rd party providers, e.g. Terraform and Pulumi, to expose new resource features programmatically, instead of hand-crafting it.
Reflection
The article provides some insights into how CloudFormation has developed inside the AWS organisation. There are challenges, as with all most organisations.
I get a feeling that there is some pride and desire to evangelize about the improvements the CloudFormation team has done. It is an example of a platform engineering team inside AWS, which also has the triple responsibility to serve external customers as well - both customers building infrastructure and customers providing infrastructure-building tools.
Here lies one challenge with what they have done and are working on. The internal customer requirements are not quite the same as the external customer requirements, yet the internal customer requirements drive a lot of what they do.
This is not wrong. I think this makes perfect sense. However, I think their focus lies, and should lie, with making life easier for internal service teams and customers building infrastructure tools.
For the rest of us, I think we may be better off with these other tool builders, e.g. Pulumi (Pulumi), Hashicorp (Terraform), Upbound (Crossplane), etc.
If AWS splits the CloudFormation team into two very separate services, then things may change. One team for internal support and tool builders, and the other team for all of us infrastructure builders.
In that case, actual external customer-focused team could focus on these customer needs more. But for now I think that is probably better served by Pulumi, Hashicorp and others.
You can find older newsletters and more at Tidy Cloud AWS. You will also find other useful articles around AWS automation and infrastructure-as-software.
Until next time,
/Erik
Top comments (0)