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

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.

>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

Ciagenix Review

Ciagenix is a big scam. So if you are going to put your money on this product; you are not going to get value for your money. There are so many things wrong about it and any sane person would easily tell this product is big scam. Take this for example; this formula has not been put through any clinical test. So we are not even sure; even if is safe or even effective.A lot of common health issues have been reported by some few people who have tried it before. The formula come associated with some serious side effects including; headaches, insomnia, racing heart and also feeling like you are going to pass out.

http://supplementstore4u.com/ciagenix-review/

https://sites.google.com/site/supplementstore4ucom/ciagenix-...

https://publons.com/researcher/4145675/ciagenix-1-sexual-pil...

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

google has had this for years aha

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.

>How can a team justify not being on AWS?

google is better

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

especially docker and other infrastructure via bazel.

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.

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

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/

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

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.

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.

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.