A 🧵 with a bit of background on our thinking around the #AWS #CloudFormation Registry. With the launch of the Public Registry, I thought it was a good milestone to share our journey so far. aws.amazon.com/blogs/aws/intr…
First, back in 2018, we started this journey by switching our internal coverage model from an older and tightly coupled implementation to a self-service mechanism. This allowed individual services teams at AWS to build coverage in a decoupled way.
Second, We externalized that at re:Invent 2019 with the launch of the Registry and CLI. The Registry is a place to discover and consume resource types, and the CLI is an open source client that lets developers (and internal teams) build these extensions.
Third, we built the ability to add additional types to the Registry, and at re:Invent 2020, launched modules - reusable components that can be shared across your IaC components and applications.
And today, with the public Registry, we’re making the Registry more discoverable. We’re also making it easy for developers and partners to publish extensions.
We launched with partners like MongoDB, Datadog, Atlassian Opsgenie, JFrog, Trend Micro, Splunk, Aqua Security, FireEye, Sysdig, Snyk, Check Point, Spot by NetApp, Gremlin, Stackery, and Iridium.
The nice thing about this evolution is that it’s allowed us to incrementally add value, make CloudFormation extensible, and solve coverage in a scalable/sustainable way.
It also means that things that we build for the Registry works in an elegant way across CloudFormation (eg all resource types get drift detection, resource import, etc.) out of the box with no additional effort!
And we’re not done! Customers have given us a bunch of great feedback, and you’ll see some more incremental innovation based off of the Registry work in the coming months/quarters! Happy to take questions and/or feedback.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
