You can use several languages today to define cloud infrastructure as code. Sometimes, you have a range of languages to choose from, even for a single tool.
So what language is the right choice? My intention with this article is to give you some guidance on how to pick the right language for you.
Do you have a love/hate relationship with YAML or JSON for configurations?
Are your configurations getting messed up because of simple typos, or problems with white space, or confusion between strings and numbers?
Do you try to manage some templating solution on top of YAML?
Is it hard to manage complex overrides across multiple configuration files?
If any of these questions resonate with you, then this article may interest you!
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.
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)