From DevOps Dynamics to Licensing Shifts: A Fresh Perspective on AWS Cloud Management
Written by Michał Lemke
Infrastructure as Code (IaC) has evolved into a cornerstone for modern cloud management. As an old-school server aficionado and an active member of the DevOps community, I've often found myself at a crossroads, juggling Terraform and AWS CDK. While Terraform has solidified its reputation as a standard and the go-to tool, there are newer, shiny tools worth our attention. In this piece, I'd like to offer my personal perspective, infusing the technical benefits with my experiences.
For starters, let's point out that Terraform is an industry standard. Absolutely. When you ask someone from the DevOps world the answer is straightforward and immediate: Hashicorp Terraform. Community is huge, and problems can be solved quickly. But.. Yeah, there is always a “but”.
Now, when you work with a particular cloud, like in this situation: AWS, you have another tool that is, let’s say - cloud native: CDK. Of course, there is Cloudformation, and CDK is based on that, but I would not like to dig into these JSON/YAML templates :) While Cloudformation underpins CDK, this piece will focus on the unique benefits and innovations CDK brings to the table when managing AWS resources.
The Quirkiness of HCL
Look, I'm an old-school server guy. Historically, I've been firmly planted on the operations side. Throughout my career, I’ve encountered a plethora of quirky syntaxes. From wrangling with tools such as awk, sed, and Perl to deciphering bizarre configuration file syntaxes, I thought I had seen it all. But then I met Terraform's HashiCorp Configuration Language (HCL). Examples like its looping constructs and the peculiar usage of the 'count' parameter for resource management left me puzzled. These nuances, while powerful, felt counterintuitive. It’s not a dismissal of Terraform's capabilities - it remains a key player in the IaC realm. And it does the job really well. However, its distinctive learning curve, especially when augmented with tools like ex. Terragrunt (and let’s not forget those ubiquitous shell scripts), can be daunting for many developers.
Bridging the Dev-Ops Divide with CDK
Historically, a chasm has persisted between developers and the underlying infrastructure. IaC promised a bridge. Yet, for several projects, the perceived complexity of Terraform posed a barrier. This is where AWS CDK stepped in. By allowing developers to work with familiar programming languages, CDK not only offers a smoother onboarding, but also serves as a conduit for cloud-native knowledge. As a developer, you can delve into CDK documentation in your preferred language, gaining insights into the resources you're deploying. For me, a TypeScript-based CDK project reshaped my operations-centric worldview. It propelled me from mere scripting in languages such as Perl, Ruby, and Python to a realm of robust development. The result? Enhanced DevOps collaboration and a newfound zeal for TypeScript. My capabilities, especially with AWS Lambda, skyrocketed.
Expanding Horizons with CDK
My foray into a Python-based CDK project was a revelation. Leveraging custom CDK constructs combined with tools like the Pydantic data validation library spotlighted the immense potential within CDK. That all actually transcends basic infrastructure offerings, presenting a dynamic ecosystem that caters to both developers and ops aficionados. What I mean is that the potential with CDK is expansive. Consider the plethora of well-maintained libraries available for each programming language supported by CDK. As of this writing, the AWS CDK offers support for TypeScript, JavaScript, Python, Java, C#/.Net, and Go. Interested in testing, data validation, automation, or even wrapping the CDK behind a REST API? The world is your oyster. However, a word of caution: be mindful of antipatterns. The allure of overengineering is ever-present. :)
The Licensing Elephant in the Room
Now something really funky here. The recent licensing pivot by Hashicorp has certainly set tongues wagging in the DevOps community. HashiCorp's decision to transition Terraform from the open-source MPL v2 license to the more restrictive BSL v1.1 license didn't go unnoticed.
There is an open discussion regarding OpenTF Manifesto. Professional tools using Terraform under the hood are under the question mark. Such a move risks curtailing community contributions, triggering compatibility concerns with other open-source initiatives, and might sow doubts regarding potential future restrictions. If I were donning the hat of a CTO, this would give me considerable pause before opting for Terraform.
Alternatives?
It's worth noting that the AWS CDK is not the only tool that allows the use of a "real" programming language for infrastructure as code. Pulumi is another notable choice that shares many of the same advantages as the AWS Cloud Development Kit. However, a significant portion of Pulumi's functionality is based on Terraform providers. With Terraform's recent license change, this reliance puts Pulumi's long-term viability into question. The same concern applies to the Cloud Development Kit for Terraform (CDKTF). While CDKTF brilliantly merges the principles of the CDK with the flexibility of Terraform, bypassing the vendor lock-in of CDK and the idiosyncrasies of Terraform's HCL, it is still fundamentally reliant on Terraform's underlying structure. This dependency is worth keeping in mind when assessing its future sustainability.
Conclusion
The IaC landscape is rich and varied. AWS CDK, especially in the wake of recent licensing shifts, positions itself as a formidable contender. It serves as a bridge, uniting developers and operations while championing a comprehensive approach to AWS cloud management. Beyond sheer technical might, due to the connection it creates between Dev and Ops silos, AWS CDK plays a pivotal role in fostering collaboration and widening the knowledge base for professionals. As the cloud domain continues its relentless march forward, tools such as CDK, which encapsulate a blend of power, user-friendliness, and commitment to open principles, are poised for the limelight.
While this article sheds light on the many advantages of the AWS CDK, it's essential to present a balanced view. The AWS CDK is indeed a work in progress. There's an impressive arsenal of L3 (Level 3) constructs, essentially being ready-made solutions for common cloud configurations that showcase CDK’s true power and capabilities. But it's worth noting that some AWS resources, especially the less common ones, are still implemented as L1 (Level 1) primitives - foundational blocks that directly represent AWS services with minimal abstraction. Moreover, despite the edge it might have over Terraform, CDK's reliance on CloudFormation is a double-edged sword, bringing with it inherent limitations and drawbacks. Like all tools, the CDK has its strengths and challenges; it's crucial to assess it holistically and in the context of specific project needs.
Top comments (0)