21 More AWS Services They Should Cancel
21 More AWS Services They Should Cancel
Please Amazon 🙏 kill these services too.
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.
The article makes some interesting points, but the author shows a complete detachment from reality by advocating against CloudFormation and CDK with simplistic and twisted logic (if any).
An interesting read in spite of this.
I'm not a fan of CDK as it seems to just introduce more cognitive load for developers and ops (as soon as something goes wrong / gets difficult), often long after the original authors have moved onto new shinier projects.
It's yet another way to create snowflakes, but it's not the worst, precisely because it uses CF behind the scenes.
If there were an org-wide (or "platform engineering") strategy based on CDK, it would be different. The same goes for pretty much any infrastructure management tooling choice.
I’m not a fan of CDK as it seems to just introduce more cognitive load for developers and ops (as soon as something goes wrong / gets difficult), often long after the original authors have moved onto new shinier projects.
I don't think so. If anything, CDK contributes to not only simplify deployments of complex web applications but it also makes said deployments testable and verifiable. Also, features such as constructs and basic modularization contribute to simplify and clarify any deployment. I don't know of any IaC tool that handles this better than CDK, frankly.