| I've not been enjoying my CDK experience, the idea of it is a beautiful one, the practical application is far less so. The different libraries for the different services act extremely differently, there are frequently breaking changes (we did a minor point release, and now everything is broken) The tooling doesn't support SSO, even though amazon has been pushing people in that direction for years. I WANT to like it because you can see it is the way things should be, but until Amazon gets their documentation and tooling in a working state, it isn't nearly the beautiful thing it looks like it should be. It is a great idea, but really let down by a shitty implementation. Seriously. When you define a thing. Is it going to create it for you? Is it going to fall over if it already exists because you ran the same script yesterday? So the thing already exists? Is it just going to reference a thing which is already there? It could be any of these, and how it acts is WILDLY different for every service, and also undocumented. CDK could be good. But it REALLY isn't yet. There is a reason your Devops people are not falling over themselves to use it. |
That's...unlikely.
> It could be any of these, and how it acts is WILDLY different for every service, and also undocumented.
CDK is an abstraction over CloudFormation, which is an inconsistent (in how it deals with similar things at the next level down) abstraction over the individual APIs of AWS services, which themselves are not particularly consistent to start with.
> There is a reason your Devops people are not falling over themselves to use it.
Well, lots are, because it's less tedious than raw CloudFormation or thin improvements over it like the Serverless transform, and AFAICT most of the inconsistency is from the underlying CF behavior, so isn't avoided by cutting out the additional layer.