Cloud Development Kit (CDK) by AWS will completely change software | Hacker News Reader

Cloud Development Kit (CDK) by AWS will completely change software

21 pointslogicslave28 comments

My mind is blown by CDK and the abstractions it allows over software.

Modern infrastructure has been done via configuration files (cloudformation, ansible, salt stack, chef, docker), allowing the automation of the creation and scaling of infrastructure. This was once a major innovation.

CDK by AWS ups the level of abstraction, allowing for one to create object oriented abstractions over their complete software infrastructure. This, in the next five years, will completely change software development. We have never seen this level of abstraction, with the whole power of the AWS stack at the finger tips of the developer. How can a team justify not being on AWS?

CDK is to cloudformation as c++ is to assembly.

Templates of complete software stacks, with all devops built in, will be created and will completely automate dev ops. Whole websites can be spun up in minutes, pieces of them mixed and match with open source infrastructure templates pulled in.

Imagine a spring package where your ORM already has an aws database baked in, with the automated switching between dev and prod, profiling, etc. Right out of the box. Just a random example, but the automation here is massive

Why am I not reading more about this?

Big fan of AWS, but this reads like unabashed shilling.

>How can a team justify not being on AWS?

You can do the exact same thing with Pulumi and it's cross platform.

Also, in my experience, CDK is an absolute nightmare if you like running things locally and testing on your own machine

Yeah but this is native to AWS, completely different than third party software

So? Cloudformation is "native" to AWS and it's absolutely awful to use compared to Terraform.

The open source that can develop around CDK is completely different than something Terraform or Pulumi

Pulumi and Terraform are both open source and have substantial features that aren't even in CDK (As noted in a comment above).

Ditto.

To add to this, Pulumi has a few features not yet present in CDK like encrypted state, and dynamic resources. The TLS/Random provider also seems to be missing from CDK but present in Pulumi. I am using all of these features in some Pulumi projects and couldn't imagine using CDK, ever.

tl;dr Use your preferred tooling, but don't assume a team couldn't justify using their tools of preference.

Because it’s not proven. Smart people will not move their infrastructure supporting billion-dollar business onto something, that might break in unexpected ways while also hiding the reasons it broke. Abstractions are dangerous, most really big-scale folks seek ton understand their entire stack and have as little abstractions as possible down to their own hardware. Why? So you still have a reasonable chance to understand and control your entire stack.

Recently switched from CDK to pulumi. CDK was nice but having more products than just AWS is why we moved. If anybody uses pulumi make sure to look at using the S3 or similar of the state so you aren’t tied to their website https://www.pulumi.com/docs/intro/concepts/state/

Link to the pulumi docs on custom resources:

https://www.pulumi.com/docs/intro/concepts/programming-model...

I've been using AWS CDK since the first preview versions and experienced the same mind blown feeling. It really changes the way you think about IaC (Infrastructure as Code) when cloud resources are programmable and abstractable in TypeScript. This is particularly true when you develop serverless applications that are tightly integrated with cloud services (API Gateway, Lambda, etc).

I've recently started to merge IaC code with runtime code, so that Lambda functions and AWS CDK projects share the same dependencies and the same package.json. I think Pulumi does something similar, although I'm not familiar with it. It makes development one step simpler, because you only have a single set of dependencies to worry about in a project. Esbuild takes care of only deploying the code you actually need to the Lambda functions.

The next step I hope to see is TypeScript type support for AWS Step Functions. Currently there's no type checking for the input and output objects of Step Function States, or for the various selectors you can specify for them. With proper typings, AWS CDK could throw deploy-time errors when Step Functions are badly configured or don't match the input/output types of related Lambda functions. Actually, you might see the problems already while editing the project in Visual Studio Code.

The future direction here is that you can implement fully featured cloud applications, including runtime code, with very little boilerplate code, just by defining data structures, essential business logic and high-level cloud resources. AWS CDK will take care of all the details by default.

One of the reasons I loathe the Idea of WEF for the future that came recently to big spotlight (old WEF propaganda link: https://www.forbes.com/sites/worldeconomicforum/2016/11/10/s...) is the assumption that privacy and control are concepts of the past. This is the same case, companies driven by greed joined Facebook platform only fo find out how dependent they are afterwords, I predict different future, future in which lower cost of hardware and traffic will give option for full control of dev ops and stack without Google and Amazon. You can full small businesses to some extent, but in the era of data driven business ownership and full control are priceless. Trusting some big cloud corp with army of lawyers and complex agreement is questionable.

I raised similar concerns in

https://news.ycombinator.com/item?id=25641205

regarding privacy in Google, to be downvoted almost immediately. There's people that truly don't care about privacy and control, and see comments like this as a nuisance, because they can't see how this massive amount of information could be used against them. WEF itself has been selling the you won't own a thing, and you'll be happy mantra for a while, and there's more and more people buying it.

It would be palatable if the ones promoting it didn't have so much privacy and control themselves.

I have problem with Idea of lack of ownership. I have lived in communist regime in which secret services terrorised population with phone tapping, public shaming, making agents from your relatives, breaking families, turning careers to dust, while political elites lived in luxury and corruption was a leaders sport.

The proposed model for the future is obviously abstraction with same patterns in hand. People will buy it to some extent I guess but the idea of ownership is hardwired to our psychology naturally, ownership is connected to privacy in direct way, I cannot see how Bezos, Gates, Musk will comply with this. What will they do? Will give away all the money they have and live free of ownership? GTFO.:)

https://bazel.build if you want some actually mind blowing software.

especially docker and other infrastructure via bazel.

I wonder why CDK uses an old version of the AWS SDK for JavaScript. I really like that CDK has some sane defaults (compared to CloudFormation where you have to define almost everything everytime). I also like it shows you a detailed progress status of the deployment.

https://cloud.google.com/deployment-manager/docs/configurati...

If you have the money for it, as in, a developer may be able to create infrastructures at whim, but does he have all the necessary money to pay for all the bills related to that cloud? (Paying for processing, storage, networking, etc)

We already know of a few cases where a bug in code got a few thousands of dollars of damage.

Imagine that multiplied by the number of objects created on an array that generates clouds in real-time in a developer's code.

It's a pretty pricy bug.

There's also the issue with control and monitoring, giving a lot more control to the Cloud Provider and total surveillance of operations to third parties.

I can see a future where only 1 cloud remains and all our tools and resources are on the Cloud Provider's Infrastructure and we cannot control or even self-host our own tools and data and everything we do and host is being monitored. If someone does not agree with what we store or host, it may be rejected and even banned/deleted WITH our consent (because we accepted the EULA) but without our authorization. We would not own anything we create or send to the cloud.

We would all become Cloud Developers, Cloud Web Developers, Cloud Engineer, Cloud SRE in our resumees.

This should be more open and not be driven by Vendor Lock-in.

the thing is, it doesn't really matter. someone has to figure out how to provision & configure a bunch of resources for the app, & too often that toolchain bloats & becomes inaccessible to more & more of the company's developers, which wrecks the dev-ops feng-shui we all want. but it kind of doesn't matter. these are a kind of minor cost of doing software, truthfully.

the interesting bits in-development these days are not the toolkits to assemble cloud. the interesting bits are the cloud-ification of the application. rather than configuration & state being managed by the app, externalizing more & more of the inner-pieces of the app into external services really reduces the app foot-print, & gives all apps in the environment a common basis for operation. at the moment, it's pretty much only kubernetes doing anything here, & frankly, it's under-hyped, radically under-hyped, that this is the true-er goal of kubernetes. it's not just another platform. desired state management is a whole philosophy for computing, about writing what you want to do in to a central archive, then allowing autonomic systems to break down & accomplish the state you have told the system to set out for.

this hinges upon simple steps like externalizing your apps state into central/cloud systems along-side other app's state. it's practiced by writing separate controllers, a kind of inten-based CQRS 2.0. writing code to build state, as cdk does, is convenient & ops friendly. but still very procedural/computing 1.0. i very much look forward to a far better, far more expansive future, one that is far less isolated "me and my app" & much more bigger picture & all encompassing. kubernetes is bringing that. nothing else is, that i have seen.

And deployment scripts that are unit testable. That's been years in the making.

Because devil is always in the details.

More and more people are dying from heartattacks caused by understanding the true costs of losing control and relying on cloud religion and throwing money into Bezos' fireplace.

The question is why you're not reading more about Pulumi. It does all this in your language of choice across cloud providers. It works really well.

google has had this for years aha

>How can a team justify not being on AWS?

google is better

Not that impressed with Google products, open source, or their cloud in the last five years

okay well try to learn how to use it then idk

This year is year of multi cloud with Kubernetes.

Reply on news.ycombinator.com