
How to become an infrastructure-as-code ninja, using AWS CDK -part 8
In this article, we are going to wrap up this article series on using AWS CDK for managing infrastructure as code. We will cover two topics in this article: Monitoring…
In this article, we are going to wrap up this article series on using AWS CDK for managing infrastructure as code. We will cover two topics in this article: Monitoring…
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.
In this article, we are going to expand on the service in ECS we have already defined in part 6 and make it a load-balanced service that can automatically scale…
AWS has a problem with its handling of customers’ adoption of infrastructure as code. This applies to CloudFormation, and by extension, to the AWS Cloud Development Kit (AWS CDK). This…
Have you had a task to fix a supposedly simple thing in a project, a code or configuration change, only to spend most of the time to set up the environment so you can do the fix in the first place?
The setup you just did for this now clutter your setup, and conflicts with other projects? In order to get back to your old working environment, you have to do some re-installs of software packages?
Have you struggled with increasing complexity of managing and maintaining software configuration? Some time ago, I saw a reference to what was called the Configuration Complexity Clock. It describes phases in how the complexity of software configuration grows. This name originally came from a blog post by Mike Hadlow in 2012.
This is something we should know and think about before we end up in a bad, unmaintainable place.