this post was submitted on 05 Oct 2024
1 points (100.0% liked)
Cloud
528 readers
1 users here now
This community was created to share news, hold discussions, insights, and knowledge sharing about cloud computing and different cloud services like AWS, Google Cloud, Azure, and many others.
Read our rules here
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
One of the key advantages of AWS had been that you could rely on a service being around long term. Anyone building a product/service around Google knows they're taking a risk that the whole rug can be pulled when they get bored with it. This isn't just for consumer services, but enterprise ones, like Google IOT (https://www.techradar.com/news/google-cloud-is-closing-iot-core-leaving-devices-stranded).
Having said that, it's been really disappointing seeing AWS slowly close down access to services like CodeCommit (which will have impact on other Code*) services.
The article lists a bunch of duplicative or half-baked services. The dupes at least give people somewhere else to go. And the half-baked ones (like Blockchain) never really got much traction but are still useful since you get the whole AWS security model and IAM access rules.
But deprecating CFN and CDK is the most braindead idea I've ever heard. I have no love for CFN and hope to never see another line of it in YAML or JSON ever again. And that also goes for Terraform.
The reason CFN is so slow is directly because of its state management and drift tracking, including rollback. CFN also closely tracks service changes so each time there's an update, all APIs, docs, and CLI tools update as well.
CDK was built on top of CFN because going back and creating yet another IaC interface and keeping it uptodate would be prohibitive, given how many services there are.
CDK is a great idea. Their L1 stacks give basic access to all CFN. L2 stacks make it dead easy to bring up services with sane defaults and without messing things up. L3 stacks make you feel like god, smashing together planets and creating galaxies with a few lines of code.
The reason they're slow is because there's so much state/drift/dependency tracking. The reason they keep a local cache is to try to speed it up. The reason you check the context into repo is so others working on the same project get all the benefits of caching and settings without now having to add yet another layer of cross-team consistency checking.
Advocating for closing down more services is just plain stupid.