AWS Cloud Control API, a Uniform API to Access AWS and Third-Party Services (opens in new tab)

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.

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.

Personally I use Terraform because it's multi-provider not so I can switch, but so that I can use whatever I want concurrently.

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.)

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).

If it only was so easy to move! Sure, one tool, one configuration format but it’s not so easy to simply change some configs and move.

Even going for the provider lowest common denominator implies maintaining different configurations.

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

Yes I know, I was sort of using it (new CLI designed to be a better interface) to say why is it so.

Apparently I hold a minority opinion that's so offensively contrary it deserves downvotes though!

I maybe didn't make it clear enough, but I think it's somewhere between 'don't care either way' and 'great' for non-interactive/scripted use. I just don't like the UX at all for using it interactively, I find it extremely slow and cumbersome.

This looks to be a big improvement, but - to me - just leaves such easy obvious trivial stuff on the table.

Re: positional arguments, I was surprised recently to find this one (`outfile`) in the AppConfig API.

https://awscli.amazonaws.com/v2/documentation/api/latest/ref...

What do you mean other than? I removed it, that is the (entire) difference.

> Warp it in a shell script

As I said, for non-interactive use of course I don't care. But trying to actually do/check/test anything with awscli interactively/'manually' is pretty painful IMO.

Well that's not really true, or at least incomplete. GNU & BSD have different styles; I believe both do positional/unnamed arguments.

It's true that awscli goes for all --named=args currently, but that's not decades of it not happening in general, and I just commented on wishing it weren't the case here.

I think this is a great simplification/abstraction, and I don't see why it couldn't go further and just be `aws <crud> <type> <resource>`. But that's apparently highly disagreeable even as a mere thought or suggestion, so I'll shutup.

Whatever language is used, there is a choice of either positional or named arguments.

Consistently using named arguments for a CLI to an API seems to be a good idea. Nothing to do with whether the API is written in Java.

All of the AWS CLI support input in JSON or YAML as well and will generate the skeleton of the call for you as well.

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.

Is a native provider planned for Cloudflare?

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 wouldn't say super easy, but at least much easier than before.

As a concrete example of what this enables, the Pulumi Automation API lets you embed IaC straight into a bigger program. Folks have used this to create infrastructure-oriented SaaS products, self-service portals, and new higher level abstraction frameworks and tools, for instance, often spanning multiple cloud resource types (AWS, Azure, Kubernetes, Cloudflare, others) -- https://www.pulumi.com/automation/. Transpiling to YAML and handing it over to CloudFormation is clumsy and wouldn't work for these cases among others.

> Not something you can easily do with the declarative version.

Its something that you can do easily with the imperative API for CloudFormation plus the declarative description of the stacks in CloudFormation.

That new game server could just be another cloudformation stack but I get your point.

I highly doubt that tools like Terraform/Pulumi will not have custom code for each type of resource. Each type still needs to have its own custom Body with specific data types, some mandatory, some optional. Even if TF supports Cloud Control as yet another resource, using it is going to be a huge mess of untyped/unchecked/undocumented bodies.