Since this is from CloudFormation team, what can we expect about the performance vs calling the APIs directly? CloudFormation is not known for its speed.
Each API still needs to have its own custom body, with specific mandatory keys and values. The name of the verb is just another key and value ... so how is this different from existing APIs? Not different much.
The only addition introduced here is the support for third-party CloudFormation resources. So the same AWS APIs can now be used to directly manipulate third party resources without using CloudFormation at all.
Cloud Control provides a direct API to the primitive functions that underpin CloudFormation resources. So, if you look closely at what it's doing (hint: "desired state" parameter), Cloud Control is declarative on the resource side.
I don't think that replaces other AWS resource schedulers like Terraform and Pulumi, but it could, uh, embrace them into a more CloudFormation-oriented ecosystem, which is clever.
Pulumi lets me create custom providers, leverage providers for other clouds/ products, and build code-based abstractions. I see no reason why I'd stop using it.
Not really a moat, at least for HashiCorp. Consider that Pulumi was able to get off the ground by using Terraform providers, including HashiCorp's AWS provider, behind the scenes.
In addition to the other replies, Terraform has used ARM on Azure for a while now which is similar to this a unified API for all Azure Resource Management (hence ARM) and this hasn't caused any issues for them there.
In most places I've been, Terraform was used more for documentation than mobility. Sure, you don't need to unlearn Cloudformation if you switch to GCP, but you have a ton of AWS-specific stuff in your TF config that's going to need to be ported to the appropriate counterparts in your next cloud. But having a documented change history in Git for (almost) everything was much more useful than theoretical mobility.
I think this is really similar to the "we use kubernetes so we don't get locked into AWS" argument; true in theory, never pans out in practice.
I'd hazard that the number of engineering orgs using a single Terraform "stack" (repository? domain? whatever) to manage resources across multiple providers is in the single-digit percentages.
The ability to transfer knowledge has non-zero benefit, but the reality is; that knowledge is 10% "Terraform & HCL", 90% "AWS Resource Configuration & Best Practices". 90% of it doesn't transfer, and most of the remaining 10% could be learned quickly enough.
Maybe it enables you to transfer CI/tooling between cloud providers should your org switch. Probably the most reasonable argument.
I think the core of what you're saying is actually right, for the same reasons that the kubernetes statement above is right; AWS is really becoming its own isolated world. Terraform on AWS makes less and less sense, as their in-house options like CF, CDK, SAM, etc evolve maturity beyond what TF is capable of. TF (and Pulumi) (like Kubernetes) is for everything else.
Terraform has multi-cloud support but it is not cloud agnostic. You have to rewrite your terraform for the things that you want to move to another provider.
Moving to other providers is unfortunately rarely easy except for all but the most basic infrastructure.
I think that the main usage pattern for a tool like terraform is be able to version control your config, and , on the way, apply the git flow/git ops to infra changes (infra as code).
I don't think the (theoretical) ability to move to another infrastructure provider is the main motivation to use those tools. It might be a supporting motivation. But definitely not the real reason why they're using it. Hardly anybody actually changes their infrastructure provider anyway
I'll honestly just say it outright: this is horrible advice.
People using this argument has clearly never needed to be multi-cloud. If you can ever, ever, ever, avoid being absolutely forced into this, you should. Being able to move fast on infrastructure has such big implications, and being multi-cloud basically means that you can only rely on an extremely minimal subset of features that completely align across the clouds (hint: the less managed stuff).
You'd pretty much have to start from scratch switching between clouds even with Terraform. All the providers map pretty closely to the underlying nature of the resources defined in other clouds.
In what world does TF or pulumi code written for Aws runs on gcp or azure? I mean, maybe you can cook something with ts and pulumi but it is not realistic
I'm really excited about what Cloud Control API enables more broadly as well. I see this as a new high bar for cloud provider resource provisioning APIs, and it's an approach I hope to see more of across the industry going forward.
Previously, to provision and manage a resource, you would need to find the REST APIs for that specific resource, and define your own model for what set of REST API calls constitute a logical Create, Read, Update or Delete operation. This work was done and re-done in dozens or hundreds of cloud provisioning tools.
But AWS themselves had already built a model for doing this, and service teams at AWS were already defining their own well-defined resource model - the CloudFormation resource model for their services/features - it was just locked up behind CloudFormation templates as the only way to author and deploy resources using this resource model.
With Cloud Control API, all of the value of that resource model, and the work by teams at AWS to cleanly define that resource model, is now unlocked to be used by any sort of provisioning tool or service - not just CloudFormation templates.
At Pulumi, that has enabled us to build our new AWS Native provider on top of Cloud Control API, but it opens up tons of additional scenarios as well. Kudos to the AWS team for their work on this!
Now if we could just use cfn-signal (or something like it) when setting up an EC2 auto-scaling group without having to create a Cloudformation stack behind the scenes as the Pulumi awsx package does.
Will it? Given how Pulumi can use Terraform providers, I'd say the hard work there isn't the connectors (which this change makes easy) but the framework and the orchestration bits. These aren't made any easier by AWS standardizing their APIs.
I wonder how long before this becomes a standard like swagger. People will create a spec for a well-known endpoint and probably call it CURDL that allows APIs to be self documenting and automatically compatible with a general universal API client. No one will have to maintain their own clients any more and everyone will wonder why it took so long to think of this...
There's Smithy, which tries to help design API operations around a resource in a CRUDL-like fashion - I think that's what you're getting at? https://awslabs.github.io/smithy/
Readit News
[1]: https://www.lastweekinaws.com/blog/how-aws-dumps-the-mental-...
The only addition introduced here is the support for third-party CloudFormation resources. So the same AWS APIs can now be used to directly manipulate third party resources without using CloudFormation at all.
Terraform is declarative; this is imperative.
Terraform doesn't try to make a common CRUD interface to everything on AWS; that is the sole distinction between this and the pre-existing CLI.
I don't think that replaces other AWS resource schedulers like Terraform and Pulumi, but it could, uh, embrace them into a more CloudFormation-oriented ecosystem, which is clever.
I'd hazard that the number of engineering orgs using a single Terraform "stack" (repository? domain? whatever) to manage resources across multiple providers is in the single-digit percentages.
The ability to transfer knowledge has non-zero benefit, but the reality is; that knowledge is 10% "Terraform & HCL", 90% "AWS Resource Configuration & Best Practices". 90% of it doesn't transfer, and most of the remaining 10% could be learned quickly enough.
Maybe it enables you to transfer CI/tooling between cloud providers should your org switch. Probably the most reasonable argument.
I think the core of what you're saying is actually right, for the same reasons that the kubernetes statement above is right; AWS is really becoming its own isolated world. Terraform on AWS makes less and less sense, as their in-house options like CF, CDK, SAM, etc evolve maturity beyond what TF is capable of. TF (and Pulumi) (like Kubernetes) is for everything else.
I have no interest in using CloudFormation for the AWS parts, and then.. what, Terraform anyway for any other provider?
(Even if CF were on par, which IMO it isn't.)
Moving to other providers is unfortunately rarely easy except for all but the most basic infrastructure.
People using this argument has clearly never needed to be multi-cloud. If you can ever, ever, ever, avoid being absolutely forced into this, you should. Being able to move fast on infrastructure has such big implications, and being multi-cloud basically means that you can only rely on an extremely minimal subset of features that completely align across the clouds (hint: the less managed stuff).
Even going for the provider lowest common denominator implies maintaining different configurations.
Deleted Comment
I'm really excited about what Cloud Control API enables more broadly as well. I see this as a new high bar for cloud provider resource provisioning APIs, and it's an approach I hope to see more of across the industry going forward.
Previously, to provision and manage a resource, you would need to find the REST APIs for that specific resource, and define your own model for what set of REST API calls constitute a logical Create, Read, Update or Delete operation. This work was done and re-done in dozens or hundreds of cloud provisioning tools.
But AWS themselves had already built a model for doing this, and service teams at AWS were already defining their own well-defined resource model - the CloudFormation resource model for their services/features - it was just locked up behind CloudFormation templates as the only way to author and deploy resources using this resource model.
With Cloud Control API, all of the value of that resource model, and the work by teams at AWS to cleanly define that resource model, is now unlocked to be used by any sort of provisioning tool or service - not just CloudFormation templates.
At Pulumi, that has enabled us to build our new AWS Native provider on top of Cloud Control API, but it opens up tons of additional scenarios as well. Kudos to the AWS team for their work on this!