When doing infra as code, you want to plan your deploys around what infra state—that is, resource graphs—you want to achieve, not around what graph manipulation your tooling restricts you to. To that end, here's a maturity model for CloudFormation support for AWS services 1/10
Stage 1: CloudFormation support at launch, for every launch. For cloud-native customers, if it's not in CloudFormation, it doesn't exist. This should be table stakes at this point. But it's not, so let's make it a milestone. 2/10
But CloudFormation support at launch isn't the real story. CloudFormation resource designs are constrained by the underlying control plane API of the service, and these are often designed long before CloudFormation support is even thought about. 3/10
What defines a good control plane API design? One that has no functionality that cannot be accessed through CloudFormation. But further than that, one in which *advanced* CloudFormation usage is planned for and well-supported. Let's see what that looks like: 4/10
Stage 2: Any (control plane) state of the service is representable in a single CloudFormation template (setting aside limits on number of resources).
Lambda, API Gateway, and Kinesis are among services that fail this test. 5/10
Lambda, API Gateway, and Kinesis are among services that fail this test. 5/10
Stage 3: It is possible to achieve any (control plane) state of the service in a single stack operation. You can move from any resource graph to any other graph without an defining an intermediate graph or arbitrary dependencies. DynamoDB fails this test. 6/10
Stage 4: The service's resources are designed to allow decoupled management of the service according to common use cases (e.g., managing primary definition and operational parameters as separate resources, so they could be deployed by separate dev and ops teams) 7/10
Very few CloudFormation resources look like Stage 4. Lambda's recent decision to have provisioned concurrency as a separate set of APIs is a start, though it did not show up in the same way in CloudFormation. 8/10
Note that Stage 4 implies engaging customers very early on to understand how they would want to manage a theoretical service or feature. It may also mean being more willing to make API changes in beta. 9/10
The move to open source resource provider development is great, but it also implies that resource design happens after the API is fixed, which means you're going to be stuck in Stage 1. CloudFormation resource design needs to happen in concert with API design. 10/10
