AWS CDK is not a silver bullet

Posted on August 12, 2023  •  4 minutes  • 676 words  • Other languages:  Korean

TL;DR (Generated by Notion AI)

While AWS CDK (Cloud Development Kit) has become a popular choice for infrastructure-as-code (IaC) development, it is important to note that it is not a silver bullet solution for all use cases.

Firstly, AWS CDK may not be the best choice for smaller projects or simple infrastructure setups that do not require a lot of customization. In such cases, using a simpler IaC tool or even writing code directly in the AWS console may be more efficient.

Secondly, while AWS CDK provides a high-level, object-oriented abstraction for defining infrastructure, it can also lead to increased complexity in certain situations. Developers must carefully consider the trade-offs between the flexibility provided by AWS CDK and the added complexity that may come with it.

Finally, AWS CDK is still a relatively new tool and is evolving quickly. While it has a large and active community, it may not yet have all the features or support required for some specific use cases.

Overall, AWS CDK is a powerful tool for infrastructure development, but it is not a one-size-fits-all solution. Developers should carefully consider their specific use cases and project requirements before deciding to use AWS CDK or other IaC tools.

Why did I get tired of CDK?

I’ve been working on a CLI crawler application in Go recently.
Initially, I wanted to create an application in a No Server & No DB environment.
However, there were a few problems in getting the chromedriver to work within my CLI application.
(I’ve written a bit about that in here , I’ll post more about that when the CLI application is complete)

Instead of running chromedriver on the user’s local PC, I looked for a way to run chromedriver on AWS Lambda.
I realized that docker-selenium-lambda had implemented this requirement.
But I wanted to write CDK-based code referencing this Serverless-based repository.
I didn’t even take into account the pros and cons of each tool.
It’s just that I was actually using CDK a lot in my company, and I thought CDK is the answer among IaC tools.

The biggest issue I encountered in my three days of trying to apply the CDK to my project was about ECR.
The CDK can’t create ECR repositories. - Related link
And unexpectedly, Serverless was doing a great job of supporting this.
This is where I realized that the CDK is not a one-size-fits-all tool.
I realized that I had been using familiar tools without thinking.

Serverless vs SAM vs CDK

Serverless

• Long time used → Large community
• Abstraction of the complexities of CloudFormation
• Simplicity for testing and deploying apps
• Various plugins
• Can be difficult to distinguish between Serverless configuration files and CloudFormation configuration files

SAM

• Similar to Serverless, it simplifies the complex layers of CloudFormation
• Local testing
• Integration with AWS build pipeline
• Can be combined with CDK
• May be difficult to configure complex infrastructures

CDK

• Easy to compose and reuse components
• Define infrastructure with familiar programming languages
• Easy to configure complex infrastructures
• Not limited to Serverless, supports all AWS services
• Some features such as local testing require integration with other services

Summary

The key difference is that Serverless and SAM are literally tools for serverless, while CDK is an IaC tool that supports all services in AWS.
So if the application is complex, better off using a CDK.
On the other hand, if the structure of my application is not complex, I would use Serverless or SAM.
If I were at this crossroads, I’d probably use the lightweight, simple structure of Serverless.

In addition, if I want to create an application that is more front-end oriented, it would be good to learn Amplify.

Conclusion

I realized how mindlessly I’ve been choosing and using development tools.
I was simply adopting solutions that were familiar or popular.
To become a better developer, I need to think about which tools are right for my project and how they can work together to create a good synergy.
In the future, I’ll make a habit of finding and using tools that work better for my project.