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 plan…and 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 don’t like YAML / JSON, I dont know HCL, I don’t 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!
Views: 719