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.
In part 1 we introduced an AWS CloudFormation feature called Drift Detection, with which we can detect (uncontrolled) changes to the resources we manage via CloudFormation. We showed this in the AWS Management Console.
In this part, we are creating simple scripts to start the drift detection process on our CloudFormation stacks, as well as checking the result of detected drifts on the stacks. This will allow us not only to check on a single stack at a time but also on multiple stacks and multiple regions in one operation.
If you use the principles of infrastructure as code to provision your cloud infrastructure, you get many benefits from it - repeatable, quick, and consistent deployments. You also need to apply discipline in how you update the infrastructure - it has to be through the same infrastructure as code workflow. If anyone modifies the infrastructure through other means, like the AWS Management Console, then all bets are off and you may end up with a mess.
Fortunately, some tools can help to keep your cloud infrastructure tidy. If you use AWS CloudFormation, then you have a feature called Drift Detection which may help you detect when someone changes the infrastructure through other means than CloudFormation. Read further to see how you can use Drift Detection for your benefit.
If you are looking to automate your AWS infrastructure provisioning, you may have heard of AWS Cloud Development Kit or AWS CDK for short. This is one of a multitude of tools that are offered when it comes to automating your infrastructure creation and management if you are using AWS as a cloud provider.
I will present the reasons for when I think AWS CDK is a good choice and to what extent it may be used. This will not be a comparison of features for different solutions, but more around an organization, way of working, and philosophy. Will AWS CDK fit the way you work and organize, or might be striving for?
