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