At Perficient we are passionate about encouraging engineers as generalists and exemplifying unparalleled productivity by modernizing common engineering pain points. We’re also big believers in flexible teams and finding unique solutions that allow a group of creative individuals to take on projects of all types and sizes with high efficiency.
The Cloud Development Kit (CDK) and Fargate are new services from AWS that make it fun and easy to define and deploy your infrastructure. Fargate was introduced in 2017 to help developers focus on building applications rather than managing cluster infrastructure. With choices like Lambda and Fargate, the compute space is fun, but how about everything else? CDK was introduced in 2019 to make it easy to define and connect all your other cloud infrastructure. Today as I write this the CDK has matured with over 95 new releases, and 65 of those releases in the last year alone. It’s a code-first approach to defining infrastructure and supports the top favorite programming languages. CDK also has a neat trick in keeping all the programming languages in sync therefore no language has more features than another.
As with any infrastructure as code approach you get the flexibility to test, revert, review, and automate your infrastructure changes. But the spirit of the CDK was something larger than this. There are many products out there boasting infrastructure as code, but from an application engineer perspective, they are actually infrastructure as configuration files (eg, CloudFormation or ARM templates). Because CDK supports real programming languages, you have the freedom to have for loops, if conditions, and build up higher level classes to encapsulate best practices. As the CDK matured, AWS and the open source community also built up patterns and higher order architectural components with AWS suggested best practices. This ensured that just by using CDK, an engineer is following many principles of the AWS Well Architected Framework out of the box. This allowed for a major shift: Once you’re using these patterns, you feel like you are defining your architecture rather than your infrastructure. It shifts from explicitly defining every detail, to now implicitly saying what you want and letting the CDK figure out the details with AWS best practices that most people would want. It almost feels like you are writing architecture as code instead of infrastructure. You can even integrate with existing AWS services (eg. an existing VPC). If some best practice doesn’t align with your use case, you can eject to very low level CloudFormation details.
Once you’re in this mindset shift (that you are using architecture as code), it opens up a lot of doors. To see how much the CDK can simplify things, let’s examine the requirements to have a scalable API that queries DynamoDB (keeping in mind the alternative without CDK requires tens of thousands of clicks in the AWS web console).
Above is an example of CDK code that would have taken hundreds of lines of CloudFormation. You’re now defining big chunks of your architecture, rather than tiny infrastructure details. Reducing several orders of magnitude of details is great, but even after that, how much code would it take to build a typical API. Let’s examine typical requirements of an API that queries DynamoDB.
Typical Requirements of APIs
- DDOS protection / Throttling limits based on API Keys
- Auth
- Domain name mapping with flexibility of quickly changing targets
- Multiple environments (Dev, Staging, Prod, Blue/Green)
- Scalability with automatic maintenance of servers
- CI / CD
Using API Gateway, Fargate, and CodeStar we can have all these requirements satisfied. Sounds simple but wiring up all these services with only the AWS web console, or CloudFormation would be thousands of clicks or 4500+ lines of configuration. The diagram shows how to wire up these services. The good news is that the CDK can build this up in only ~150 lines of code. You can check out the github repo here with more details.
This 30x reduction gave us unparalleled productivity, and it made our infrastructure more manageable due to the higher level architectural components from the CDK.
Here at Perficient I work in the Custom & Product Development team. We’re always evaluating ways to provide more business value, by updating our strategies with new technologies that have matured. The CDK has made our teams more productive by reducing infrastructure complexity so we can spend more time building full-stack product code and hitting business goals. Contact us to learn how we can help your business too.
