Why AWS CDK is a thing?
In the IaC (Infrastructure as Code) space there are plenty of options. Services like: Terraform, AWS CloudFormation, Azure Resource Manager, Serverless Framework, are a daily bread and butter for most (but not limited to) cloud-oriented IT specialist. Those tools are quite often having a different approach and internal design, but the principle is the same — define infrastructure — and let the engine provision it for us.
DevOps
I hope you agree if I group all of them into a single declarative-like set of tools that are used for infra definition. To be more precise, in this context, “declarative” means that the author defines services, relations, and other properties and let the tool makes the heavy lifting for us and create requested infrastructure. It’s kind of like you would draw your interior design project and ask the builder to create it. In such a case you probably wouldn’t tell him what tools to use, how to paint your wall, and which screw to use for your drawer, right?
To keep the analogy, now imagine that probably most interior design experts never created a single wall of bricks or suspended ceiling. On the other hand, builders quite often build without having proper design from the designer. Please keep this analogy in your mind for a minute as I will get back to it soon.
So having defined the declarative nature of the mentioned tools, the other common aspect is the syntax. For simplicity, we can limit the available syntaxes to YAML-like syntax and JSON. Having those options available, you can’t be too creative (in comparison to other programming languages). Fluent DevOps engineer typically masters YALM/JSON but also knows ins and outs of the given tool. I would not be surprised if the tools’ specification website would be opened more often than Google. In fact, the DevOps profession is very complex. As the profession is still relatively new, I don’t know anyone who started his adventure in IT from a DevOps role. What I know is that, quite often if one decided to go that direction, it means all-in from the career perspective.
For the sake of this article, I will ignore the complexity that lays behind the infrastructure being defined and the fact that the DevOps specialist not only codes the IaC part but is one man army. I will also ignore the SRE movement, where DevOps skills are complementary to development skills and architectural skills.
Cloud engineer
Now, having said that — businesswise, DevOps could be interpreted as an operational overhead. Having such a role in the team is kind of a must due to the variety of IaC tools, but at the same time, it takes focus away from the business requirements. If we consider market shift into managed services by the cloud providers and the (already) production-grade serverless services, why can’t we try to focus on what is important in the software industry — and simply deliver functionality. I will not surprise you if I say it is developers, not DevOps engineers who code the functionality in most cases.
So why not enable developers, to use their skillset to define infrastructure?
Stay native, be imperative
To do so, first, we have to enable infra creation in the language they use on the daily basis. Well, tools like troposhpere enabled python developers to define infra a couple of years ago already. The challenge is that no matter the tool if it is not supported by the cloud vendor — it will be always lagged — a lot. It is a known fact, that new services and features gain IaC coverage from the cloud providers post-factum. Open source or 3rd party tools fall behind even more…
AWS is customer-centric. In the public cloud space, customers are not only entities like companies. For AWS, Software engineers are the same important (or I wish it would be like that) as executives. It might be an overstatement, but it is engineers and architects that select services that are going to be used. Tools with bad DX, will not last on the market too long.
A good developer is a lazy guy. Lazy in a good way of course. My other observation is that in many cases developers are biased into their comfort zone (well, who isn’t?). In my developers' hat, as a lazy guy that likes to stay in my comfort zone, I would like to treat infrastructure as yet another abstraction that I can create in the programming language I know. I would like to use the same tools that I use for development. So my developer experience should stay at least as it is normally.
If we connect the dots, it makes perfect sense to satisfy developers and businesses by enabling the development teams to be self-sufficient and have even more “full-stack” responsibility. AWS CDK is (or at least is trying to be) the answer.
Yes, it is an AWS owned project. It is also lagged (escape-hatches available though), it brings its own issues backlog and other problems. But at the same time, it enables developers to define infrastructure, it enables all the features of programming languages including their dynamism, it enables testing of your code, it enables easy abstraction creation. Also if coverage is missing in the CDK and CloudFormation, you can write your own handler for the resource you need.
Yes, you are vendor locked. But it is (sometimes) a good thing, you know? Having a bug in a terraform module? You fix it or wait for who knows how long for “some good OSS contributor” to fix it. Having a bug in the CDK? Consider opening AWS support ticket. I am pretty sure AWS will fix it asap or will provide you with a workaround.
Know your options
I’ve told you, that most of the IaC tools are declarative, what about the CDK? Since you use a programming language to define your infrastructure in the CDK, most of the technical community says it is an imperative tool. I would say it is not completely imperative. Keep in mind, in the CDK you instruct the engine on how to generate CloudFormation template which is an intermediate layer between your code and the final infrastructure.
Does it matter? I think yes — not the imperative/declarative part, but the fact there is a CloudFormation template that you can always refer to, all fallback to old-school plain CFN development if needed.
What about that interior design analogy?
If it would be possible to give a creative tools belt to builders, it would be so much simpler and faster to build and decor a new house.
Why?
One of the most time-consuming aspects of the project is communication time. No matter if it is a real estate project or IT project. If developers can define the infrastructure they need to handle the logic they are asked to build, the software can be delivered so much faster.
Is it the end of the DevOps era? Rather not.
Is it fit for all solution? Nope.
It is worth a shoot? Definitely yes.
For a hello world example, consider reading through this workshop. Is it cool? How about Terraform CDK or CDK8s?
Do you agree that CDK is a thing? Do you have already production grade systems designed with CDK?
Disclaimer:
There are so many over-simplifications in this article that it is hard to count. DevOps engineers are much much more than YAML/JSON experts.
Operations are not just overhead.
Bugs in your code will not be solved by AWS Support.
There might be a synergy effect when you combine DevOps with Developer.
