Do you want your Amazon Web Services (AWS) cloud infrastructure to be resilient and consistent?
Do you want quickly repeatable and automated AWS infrastructure set-up?
Tired of messy and time-consuming infrastructure management through AWS Console?
Do you use AWS CloudFormation, and find it verbose, clunky to manage?
If you answer yes to one or more of these questions, and want to find a better approach, then this article series may be for you!
Are you excited about using AWS Cloud Development Kit (AWS CDK) to define infrastructure-as-code?
Do you think that the AWS CDK project initialization is a bit clunky and does not give you what you need to hit the ground running with a new AWS CDK project?
Do you use Typescript? (by choice or by request)
If most of these have the answer yes, you do want to continue reading this article!
(Photo by ThisisEngineering RAEng on Unsplash)
It feels daunting, does it not?
Infrastructure-as-code promises to provide consistent, reliable, repeatable, and automated infrastructure provisioning and management.
If you look at some of these tools out there, it can be quite a lot to take in. Can we get started with a reasonable effort?
In this list, there is a mix of tools. It includes both versatile and more simplistic tools, tools with lower-level details, as well as higher-level abstractions. Find out more about these tools, and if they may be a good fit for you!
What is the deal with infrastructure-as-code, why does it matter to you?
Infrastructure-as-code, governance-as-code, and other “as-code” terms all deal with a set of desirable properties and outcomes. These properties and outcomes include getting consistent, reliable, repeatable solutions of some kind - with (relatively) fast feedback and delivery.
If you run business solutions at a cloud provider such as Amazon Werb Services (AWS), this will matter to you.
Have you been in a situation where you have chosen a specific solution to a set of problems because it seemed to be the right thing to use, only to discover later that it did not work well at all, was too expensive, or no one used it? I have been in that position multiple times. It is too easy to let the engineer brain find a solution before actually understanding the problem and directly believe what the problem is, without doing the research.
Whenever you start a new software project and set up a repository for it, what do you do? Run a package manager tool (npm/yarn init, poetry init, cargo init, etc.) to get some starting items in place, then start to copy various configuration files from previous projects that were useful?
Or use scaffolding to set up an initial project setup, and then start copying files from other repositories that have valuable configurations to tweak these?
Or have a repository template as a starting point and work from there?
Either way, setting up a project can sometimes be time-consuming work. There are testing tools, linters, version control workflows, CI/CD pipeline setup, and all sorts of things that add to the quality of life for a project but require time and work.
I have done and used all of the above, and while I usually can get some decent starting point for a project, I still need to spend some time tweaking things a bit more each time.
These issues are why Projen piqued my interest.