Comment by fdgsdfogijq | Hacker News Reader

Comment by fdgsdfogijq | Hacker News Reader

Honestly, always surprised I don't see more about CDK. As far as I am concerned, this is the future of software development. Object oriented infrastructure, where you create abstractions over pieces of infrastructure, put them into a library, and then use them as composable components is incredibly powerful. We are just scratching the surface, and through libraries like constructs, large swaths of development will be automated.

Again, this is incredibly powerful.

For those that don't know, cloudformation is now often thought as the assembly language of cloud development, with CDK the higher level language.

I work at Amazon, and here we have a growing library of internal CDK constructs that make creating internally facing infrastructure, that works with other infra, incredibly easy. Even the databases that other teams have, their queues, etc, can be vended as common infrastructure packages, and then consumed, attaching your own AWS resources to theirs via library imports.

I guess the main question I have is what makes this different from any other abstraction? Specifically, is this that much better than a ton of vm orchestration that has existed for a while?

I'm also concerned about it throwing out the lines of infrastructure lifecycle versus software lifecycle. Runs heavily afoul of the common mono repo criticism that, just because you can commit the infra update with the software, does not mean they magically deploy together.

"Runs heavily afoul of the common mono repo criticism that, just because you can commit the infra update with the software, does not mean they magically deploy together."

Yeah funny you mention this, as the idea of vending infra resources as a common package runs into the issue of how to know if every consumer will be able to successfully ingest updates. From there you have the issue of "blast radius", how to handle rollbacks, etc. The complexity goes up, and now you have a problem. I think the answer is very sophisticated build systems, as well as CI/CD pipelines, which Amazon has. Upfront the team pushing changes can know if the deployment will work, before it gets to production. But this requires a huge amount of tooling, which I don't think most companies have. It also requires alot of cloud expertise.

"I guess the main question I have is what makes this different from any other abstraction?"

For one its all unit testable, with type completion (CDK is generally done in Typescript). The code has to compile, you can diff the new infra with the current infra and see whats changing. You have version control. You can use other design patterns from other teams, much like you would for OOP code, except now its infrastructure. A queue is just a variable in a CDK code base. It demotes infrastructure from a complex thing to manage, into something like a code variable.

The amount of tooling needed is impressive.

But my concern was more in the teams that try and get it all into one code source and pipeline.

Don't get me wrong. One team having to deal with dozens of deployment orchestrations is a straw man just as much as the complication that would be forced into a single pipeline. I would love finding that sweet spot without too much swinging between the fires.

It would be even better if most of your new features were actually supported by CloudFormation.

I wish I could upvote this more - if I can’t do it in CloudFormation I won’t use it.

Reply on news.ycombinator.com