Yep, developers have been making those mistakes for quite a while already (even if just with CloudFormation, CDK or TFCDK). The problem isn't really "HCL is icky", it's the specialisation and knowledge required to make safe, secure and reliable systems.
In a way, the public cloud and their APIs are what zero trust is to classic corporate moat networks. You used to be safe 'inside' your code, and now you're not. On top of the security issues, you're now also getting real time billed for your mistakes.
This is of course where platform engineering (and the gradient of development and operations) comes in: give developers the self-serve resources they need so they can own their stuff. That also means safe-to-consume pre-made sets of cloud resources. That way you're not expecting everyone to bear the same additional cognitive load, while still having major benefits from the resources that are available.
Essentially the same thing the industry has been refining since the time of sending a deck of punchcards to the mainframe operator who will deliver the results of your batch compute once it's done. No cognitive load added, only the job at hand on your mind.
I think this is a great take. I'm on board on the HCL hate - it really reminds me of shoe-horning a templating solution into a complex, code level concern - but just removing YAML is not enough. My one caveat to this is a lot of the "platform engineering" products out there right now seem to want to abstract away all concerns behind a UI, which is just replacing YAML with UI problems. What we really need are open-source, cross-language sdks that allow self serving by developers using the tools they already know, but with additional configuration being able to color that settings by more specialized folks in their areas. For instance, an sdk that lets developers say ram is light, medium, heavy, etc. in whatever language they operate in; followed by a review of the sdk and some additional configuration layered on by the ops folks who monitor the entire company's spend and define what light/medium/heavy is. Too many of the platform engineering "solutions" seem to be about vendor lock-in.
That's essentially the idea with nitric, you ask for cloud resources in an abstracted request. How that request is fulfilled is determined by the provider used. What "read" access in nitric means can be up to the platform engineers.
To me, nitric seems to be a combination of TFCDK and the multi-provider abstraction (which limits you to the common denominator cloud resources -- generally not a good idea), which already exists, in multiple programming languages too. Even nitric itself already exists in the shape of pulumi.
Common denominator implies you're restricted to some subset of the cloud's features. I'm curious what restriction you see, since nothing about nitric limits combining nitric code with existing cloud libraries or extending providers to change the cloud interactions behind the abstractions.
You are indeed restricted to some subset, which is the only reason multi-cloud abstractions exist to begin with. The problem isn't punching through the abstractions, it's the pointlessness of the abstractions as a whole. Generic public cloud abstractions don't really work because the value is in the specificity. If you don't need that, don't use the public clouds since those are really expensive and impractical versions of resources for generic consumption.
If your project or BU is too small to make use of the specifics of a cloud, just don't use them. And if you are big enough to do so, you're also big enough to not be helped by some application specific IaC flavour of the day.
The reason for the abstractions is that the behavior of equivalent services from different clouds is functionally the same, but offered through subtly different APIs. If you think the value of each cloud is how unique their object storage (S3, Cloud Storage, etc.) is, you’ve missed the point entirely - the value is being able to store and retrieve data. The same is true for all the services nitric abstracts.
Saying they’re expensive and impractical because they’re not unique is obviously wrong. They’re valuable because they’re easy to use, safe, scalable, etc. while requiring almost no maintenance from the user. Storing data or sending messages, etc. aren’t uniquely valuable components worth spending time on for most applications. They’re basic building blocks, so why not minimize the effort and time to use them as much as possible?
There are unique and valuable services offered by cloud providers, those aren’t what nitric is focused on. I’d rather spend my time dealing with those unique, valuable tasks instead of wasting it on the basics.
In a way, the public cloud and their APIs are what zero trust is to classic corporate moat networks. You used to be safe 'inside' your code, and now you're not. On top of the security issues, you're now also getting real time billed for your mistakes.
This is of course where platform engineering (and the gradient of development and operations) comes in: give developers the self-serve resources they need so they can own their stuff. That also means safe-to-consume pre-made sets of cloud resources. That way you're not expecting everyone to bear the same additional cognitive load, while still having major benefits from the resources that are available.
Essentially the same thing the industry has been refining since the time of sending a deck of punchcards to the mainframe operator who will deliver the results of your batch compute once it's done. No cognitive load added, only the job at hand on your mind.