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