Let’s face it, the days when a single person working in an IT department set up a server and was afterwards the only one remembering (if so) what s/he did are over, and this is good.

Long before cloud services or Linux containers came along, tools were available to streamline the maintenance of servers. They became better and better, but there was always this part of it that was manual --- and often even experimental. On the other end, there were the programmers, deploying their software on these servers. The skill-set and the ways of working differ between the programmers and IT departments.

With the rise of DevOps, software developers also began to configure services. Given that one did not need to do physical work in a server-room once cloud services came along, they started to configure cloud instances. In some cases, with disastrous outcomes (we invite you to perform a web search on data breaches caused by open S3-buckets on Amazon Web Services; these buckets are comparably the easiest to configure).

However, people learn and software developers started to write software to aid them in correctly completing cloud deployments. “Infrastructure as code” was born and has been rising ever since. It is truly beautiful to watch the tools and mind-sets of the IT and software development worlds merge.

With tools like Kubernetes, AWS Cloud Formation, Azure Resource Templates, Terraform, Ansible, Chef, Puppet, and many more, one might think that we reached a point of saturation.

WRONG!

Asides from adoption still being in progress, several ways of working that are common in the programming world are still not fully applied to it and have great potential to help us build more reliable, scalable and secure infrastructures. Some of these concepts are:

• Version control with review processes as common in software development.
• Unit testing.
• Linting.
• Images on e.g. Docker Hub or pre-made compute instances are the equivalent to software libraries. These need to be categorized and monitored, with security concerns for each version collected in a database.
• The whole setup and the underlying configurations need to be treated like code. Hence, all the static and dynamic analysis concepts need to be adapted to the code that defines infrastructure.
  

As one can see, there is much work ahead of us. The last item in the list above is the home of CoGuard. We are proud to be part of the Infrastructure as Code disruption and to be able to provide tools to make future deployments more secure and aid the DevSecOps specialists of today.

Photo by Matt Duncan on Unsplash

‍