Software Engineers, Developers, etc. are all Builders in my mind. Builders try out a lot of things and most of them are eager to try out new technologies and possibilities.
While doing that, a lot of them behave like these engineers in real world:

What does that mean?

They go to the top of something, climbing somewhere and taking risks, but a lot of times they forget what is below what they are building.

For these workers in real life, it will most probably obvious that they are not risking their life by climbing up there because they can see what is below and are aware of the groundwork below the wall they are climbing on.

How is that different in our Cloud-Software/SaaS-industry?

I believe that the main difference to day is, that most of our Engineers (= Software Developers) are not aware of the infrastructure components that are required to bring their application or microservice up and make sure that it can consistently run.

Why are they not aware?

One of the challenges that I am seing in my day to day job is that we have a lot of abstractions that we have build for software developers to make it easy to develop and test software. Think of Docker or Kubernetes (k8s) as making it easy to test applications or microservices locally and make them look, feel and behave the same as in the target environment.
However, that is not essentially the truth.
During the development cycle, the engineer will test locally or maybe within a Continuous Integration environment but both of these environments will usually not have production like data assets and thus will never be comparable to a production environment.

So it is a real problem, because engineers test against infrastructure (and maybe even deployment strategy) that is not even close to how the service will run in a production environment.

How do we change that?

It should all start with a planand everyone that is part of a products lifecycle should be part of it.

CDK changes everything

CDK and for me this includes awscdk, cdktf, cdk8s gets the engineer where they feel home:

We can describe and write infrastructure in the developers native language Java, Typescript, Go, .NET.

With this, _everyone _can be empowered to write infrastructure code and feel responsible for it. No more excuses: I dont like YAML / JSON, I dont know HCL, I dont know the services, etc.
If you are a developer, you can now write infrastructure code.

This opens up new possibilities for building DevOps teams

Now, with CDK in the game, we can empower developers and operators to talk to help each other in one joined language.
Operators can help Developers understand the infrastructure required to bring their service up to speed and Developers can help Operators to develop infrastructure code.

On the other side, if you start a new DevOps team, you can directly start building out the infrastructure as it would look like in production using CDK!
This really makes the developers think about how the service should be running in the production environment later and that will help to drive the correct architecture decisions right from the start.

If you want to learn CDK look at the CDK Workshop: https://cdkworkshop.com/

More to follow around why I believe CDK is making every cloud developers and DevOps engineers life better soon!