January 13, 2021
Everything as Code!
Code is beautiful. When I started coding in the late 1990s, I remember that one of the first things I learned is that code doesn’t lie. “Garbage in, garbage out” was my teacher’s frequent saying. Fast forward some decades, we still write code. This is obvious; many businesses depend on software to provide value or even to exist. But, in DevOps, we’ve recently started to see a tendency called “Everything as code.” We go beyond software applications on this philosophy to have the full ecosystem behind it, which has usually been created manually, as software-defined components.
The “-as-code” Movement
The most famous “-as-code” approach is related to the infrastructure, commonly identified with the IaaC acronym. In a world where hardware virtualization is the norm that powers the cloud, having machine-readable files to do the work seems like a natural evolution.
Some time ago, I asked someone in my team to create several AWS resources for an application testing environment. He achieved the goal using six different code files that, when executed, provided the required results. Then we decided to create an identical set of resources, now for Staging. We did it by running the exact same files, just providing the corresponding new arguments for the desired configuration adjustments.
When talking about the approach that he’ll follow, he said that it was easier for him to create those hundreds of lines than “spending time looking for where to click to create each thing.” I thought it was a funny response because graphic interfaces were designed to make things simpler for the end-user. Nevertheless, while clicks can be useful for non-techies, commands and code increase the software developers’ efficiency. And efficient developers are a good thing.
There are other “as-code” approaches that you can benefit from, like Configuration Management (knowing and tracking software and hardware company assets, present and future), Containers and Orchestration (creation, scaling, replication), and CI/CD pipelines.
Reaping the Benefits of Coding Practices
For example, let’s say you want to create a new web product. It will be cloud-native designed, using containers, and hosted in AWS. With an everything-as-code approach, you can have:
- Package your application binaries into Docker containers, defined using YAML.
- Push the images into a Container Registry using the AWS or Docker command-line-interface.
- Use JSON CloudFormation templates to create an AWS Elastic Container Service cluster to orchestrate the container execution.
- Define and adjust the network and security configuration using additional CloudFormation templates.
- All these steps could be performed in one or more Azure DevOps CI/CD pipeline YAML pipelines.
Now imagine that you need to do some of these steps multiple times because you want to have different resources for testing stages. With the “as-code” approach, you can add parameters with values corresponding to each environment, like the name, the number of assets, appropriate certificate, etc. You can also create temporary environments when the pipeline is executed and tear them down when no longer required.
This process can be completed within an hour or minutes timeframe, with no human intervention. If you want to do all this manually, you either depend on a well-documented process or a single person knowing what to do each time; else, you’ll end up with fragile environments. It’s the “cattle versus pet” analogy.
Borrowing Code Quality Practices
An attractive benefit of the “as-code” approach is the ability to follow similar quality processes or gates than those you use in your software development life cycle. For instance, you can use code reviews and pull requests to ensure that at least a second pair of eyes is aware of what a specific infrastructure piece or pipeline would look like. Automation is a crucial ally here because you can have tools for linting or static analysis that provide you with near immediate insights about the best practices you aren’t following and suggestions on improving your code.
By standardizing your resources, security measurements like patching, scanning, and testing are more straightforward because you can automate much of the process. Furthermore, when something needs to be fixed, you can do it once for all your assets.
Separation and Reusability
Just as you can organize your application code in multiple, well-defined components, it is possible to use “templates” that work as building blocks when creating a CI/CD pipeline, where each block has a single responsibility. You can follow a similar approach with root and nested AWS CloudFormation stacks, where specific templates can be reused in other environments. Nothing stops you from doing this, even across your entire organization.
Code becomes a shared dialect across your team. Regardless of whether someone is creating a Windows Server VM and someone else is creating a Web Application Firewall, the same tool language can do both things so that anyone may understand each other’s intentions.
Code Can Improve Your Life
When following any “-as-code” approach, you can do something once and then replicating it across the organization as needed, reducing the cost while, at the same time, getting the benefits of repeatability, like consistency and standardization, security, and efficiency. Manual repetition is tedious and error-prone; and, even though “automate everything” isn’t a realistic approach, I can say that, in every organization, there are a lot of efficiency opportunities through code. Code is beautiful. In code we trust.
Written by: Jorge Gaona