Infrastructure as Code Through the Lenses of Code Quality

As the industry trends toward a serverless infrastructure and infrastructure is now mostly defined by code, the term “infrastructure as code” (see this chapter for a definition) is not unfamiliar to engineers. In the DevOps world, where speed and agility is required for fast changing infrastructure, many DevOps engineers make use of virtualization to stand up (or down) their infrastructure via code. Also, using infrastructure as code to perform these changes means that such actions can be scripted and automated, which in turn, serves the business need of satisfying customer. One business use case is to have the ability to host an ecommerce site that can handle the peak in web transactions during Black Friday sales. See this article by SeaLights for a detailed discussion on measuring infrastructure as code using code quality definitions.

What defines the code quality in code for infrastructure?

According to J.M. Juran and the definitions in his book, high quality products are observed to provide product satisfaction and are free from deficiencies.

To measure infrastructure using code quality definitions, firstly, the infrastructure code (or rather, the infrastructure that the code stands up) has to meet customer requirements and provide product satisfaction — which includes (but not limited to) providing services with high availability and little downtime. It also has to be free from deficiencies and this comprises of applying regular security patches; following principles of least privilege for access control; and achieving the security C.I.A triad goals.

Infrastructure is my responsibility now?

In a related post about responsibilities of a Dev(Sec)Ops engineer, infrastructure as code should be part and parcel of the engineer’s daily work. DevOps engineers are given the responsibility to stand up infrastructure as needed, on top of code that contains business logic. Infrastructure code should be managed like any other code, which involves version control, testing and deployment lifecycle, etc.

Responsibilities of a Dev(Sec)Ops Engineer in a Diagram

Measuring quality of infrastructure by its code?

Rules and alerts are generally good to have to manage and mitigate risks that exist in standing up infrastructure. In the process of standing up infrastructure, misconfigurations expose the software (and business) to unnecessary risks. Below are some examples that can be picked up in infrastructure code prior to setting up.

Rule #1 — Blacklist bad practices like opening port 22 (SSH) to the whole world:

server: dbnode
 base_image: rhel73
 network_segment: prod_db
 allowed_inbound:
 from_segment: public
 port: 22

Rule #2 — Blacklist bad practices like opening unusual ports and services to the whole world:

server: buildnode
 base_image: rhel73
 network_segment: prod_build
 allowed_inbound:
 from_segment: public
 port: 8080

In the case where the server is required to serve HTTP/S traffic to the whole world, engineers might want to be notified or whitelist this and continue with business as usual:

server: webnode
 base_image: rhel73
 network_segment: prod_web
 allowed_inbound:
 from_segment: public
 port: 443

Defining blanket rules for infrastructure as code can be difficult because there is no one-size-fits-all solution. If rules for infrastructure are required, then it should be scoped at an appropriate level based on different security and business needs. Another observation is that there is a drift between infrastructure from code and realization, servers are usually modified or updated after being launched. This drift undermines the accuracy of the state of the configurations written on code.

Although it is possible to measure infrastructure as code, the trend in the software industry is to measure its outcome — the infrastructure itself — instead of the static blueprints. It makes sense to measure the infrastructure directly to record its behaviour and configuration. Chef, Ansible, and Puppet are some examples of configuration management tools that measure or inspect the configurations on an infrastructure, especially for compliance and security. The tools provide dashboards that lay out the health of the infrastructure. The data from these tools can, in turn, measure the code quality in infrastructure as code to determine if the infrastructure met customer requirements, achieved product satisfaction and are free from deficiencies.

How much can `Infrastructure as Code` put the organization in the game?

Although measuring the infrastructure is more reliable as explained above, there is still value for writing infrastructure as code because this code is the basic unit block and blueprint of the entire, if not, partial infrastructure.

If your organization has some sort of infrastructure as code, it is one step ahead of the game and better than the rest who do not. Using what you have, for the least, your organization knows what unit blocks you are building upon. If your organization had already implement regular scans and inspections on the infrastructure as code, congratulations, that is two steps ahead of the game. But having achieved nirvana of DevOps infrastructure like Netflix and Google, one would be able to pass the test of an infrastructure resiliency testing tools like Chaos Monkey.

One common trend among top tech companies is that they measure and test their infrastructure endlessly and continuously. If you want your business to be as successful as them, applying similar code quality and metrics on infrastructure as code can be a way to measure your infrastructure and keep your business in a healthy, agile state — ready to respond to both good and bad changes.