You must log in or # to comment.
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.
For deploying applications and associated infra in one fell swoop (often using higher level AWS compute services), it works well enough. In those cases, the dev teams are the infra and support teams, and it is an integrated part of their deployment pipelines. All good, probably.
Then you have a very typical scenario in larger companies, where you have a mix of centrally managed services (eg. Kubernetes clusters and VPCs/networking) shared by multiple teams and services, custom API gateways, and the dev teams of java/js developers fresh out of college who typically just want to write code and have it talk to a backend DB which they don’t particularly want to support. With services having to be supported for 10+ years, developers will come and go, and sometimes just go, leaving legacy apps and infra that need to be supported by some poor sods in low cost countries, along with CF, TF, Ansible, custom scripts, operators, and manually provisioned infra. In such an organization, you must encourage (and wherever possible enforce) standards.
If CDK is the company standard, and therefore well understood and supported, with guidelines and company standard libraries, then great. If not, it will be another snowflake.
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.