Understanding configuration complexity

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.

Take a cue to supercharge your configurations

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!

How to migrate from CloudFormation to AWS CDK - part 1

Have you, at least partially, adopted AWS CloudFormation to have better management of your Cloud Infrastructure?

Do you feel that your endeavours with CloudFormation get messy and cumbersome to handle?

Do you want to find a better way to handle cloud infrastructure better, without redoing all your work?

These articles are for you if you answer yes to most of the questions!

How to become an infrastructure-as-code ninja, using AWS CDK - part 5

Now it is time to build a service, running in Elastic Container Service (ECS)!

In part 4 of our series, we set up an ECS cluster to run our containers using Fargate, so that we do not need to bother with underlying server infrastructure for the containers. We also added a Task Definition, so that we could manually start the container and get the Apache web server running.

We had a list of goals, which we could cover partially:

  • Expose an endpoint for a web server for HTTP traffic from internet.
  • Web server shall run in a container.
  • The container itself shall not be directly reachable from internet.
  • We should be able to have a service set up so that containers will automatically start when needed.
  • We should be able to build our custom solution for this web server.
  • We should be able to get container images from DockerHub.
  • We do not care about managing the underlying server infrastructure that runs the containers. I.e., we will use Fargate.

Let us now address more points in the goal list, one by one. Since we got the Apache web server running, but had to start it manually. Let us remove that manual step. We can accomplish this by setting up an ECS Service for the web server.

How to become an infrastructure-as-code ninja, using AWS CDK - part 4

It is now time to create an infrastructure in AWS to run container-based solutions!

We will use the Amazon Web Services (AWS) service Elastic Container Service (ECS) to run an application packaged as a container. We will also put a load balancer in front of it, so that we can run multiple copies of that containerised application and distribute the load among those copies.

This is part 4 in a series of articles about building cloud infrastructure solutions with AWS Cloud Development Kit (AWS CDK). If you have not already read them, I recommend checking out part 1, 2, and 3 as well, which are all on the Tidy Cloud AWS website.