Years after it was stated that “software is eating the world,” many organizations are still grappling with the fact that this was not only true for multiple industries (transportation, hotels/tourism, news) but also for traditional IT disciplines and practices. Waterfall gave way to agile and DevSecOps; paper-based requirements and design gave way to digital engineering; system administration gave way to site reliability engineering; database administration gave way to PaaS and SaaS persistence and data stewardship; and data centers gave way to cloud and IoT. However, many organizations are still finding this digital transformation difficult to achieve because they continue to cling to their historical practices around provisioning and configuration of infrastructure and resources vs. adopting Infrastructure as Code and Configuration as Code (IaC/CaC). So, to help those organizations that may be struggling with whether or not to embrace IaC/CaC, let’s explore some of the benefits and challenges therein.
Efficiency, Consistency, Reuse & Speed
Similar to any domain space where you automate repetitive tasks, automating your infrastructure provisioning and configuration through code drives efficiency. No different than the philosophy of automating your unit and integration testing in Test Driven Development or your business process execution through Robotic Process Automation, simply put, the processor of even the most primitive computer is an order of magnitude more efficient when compared to humans otherwise performing the same tasks. While there is certainly up-front investment and time spent developing IaC/CaC compared to a paper-based playbook or script for a human to follow, the return on that investment is quickly realized in a world where ephemeral, on-demand infrastructure is a key tenet to operational success.
Consistency is perhaps even more important than the efficiency gained by automating your IaC/CaC. Human error is inevitable in any manual or even semi-automated process – as the saying goes “to err is human.” To be clear, the term “error” here does not necessarily mean a bug or issue was introduced, but rather a deviation from the playbook or script. It is that uncertainty and risk that yields inconsistency and ultimately a non-deterministic result. With IaC/CaC, you have the guarantee that provisioning and configuration of your resources will be executed exactly as prescribed every time. It also offers the confidence that if there is something wrong, it is a bug in your code that, once fixed, will be fixed everywhere.
Further building on this consistency is the evolution of declarative over imperative scripting. Simply put, imperative scripting is effectively automating the step-by-step playbook that would otherwise be manually executed. While that certainly provides efficiency and consistency gains, it also results in the same cumbersome playbook model of old that requires a high degree of cognitive load to understand and maintain. Declarative scripting, on the other hand, allows you to define your IaC/CaC as the outcome or desired state in code, which not only yields the efficiency and consistency in execution of your IaC/CaC, but also in the maintenance of your code itself.
A prime example of declarative language for IaC/CaC is in HashiCorp’s Terraform, which establishes a consistent domain-specific language for describing the desired state of your infrastructure and resources across a wide variety of public and private cloud service provider solutions. In addition, Terraform makes modular reuse a first-class citizen in its design principles and therefore drives even greater organizational efficiency through enterprise solutions for common IaC/CaC use cases. For example, consistent provisioning and configuration for a secure, n-tier web application could be established once as a module that all teams leverage to rapidly develop, test and deploy their web applications.
Ultimately, the efficiency and consistency gains and declarative reuse equate to speed – speed to test, speed to deployment, speed to market, speed to solution and speed to mission effect. Any organization that is not embracing IaC/CaC will continue to be hamstrung by the delays inherent in manual, inconsistent and human-driven processes and will never be able to keep pace within their market and the larger competitive landscape.
Collaboration, Autonomy, Mastery & Teamwork
Somewhat more subjective, but no less important in terms of benefit, is the resultant collaboration that ensues when your organization embraces IaC/CaC. Establishing a common language between developers, site reliability engineering, security operations and management teams is fundamental in creating a space where all disciplines can work together for effective delivery. By collaborating around a single source of truth IaC/CaC codebase, all stakeholders enjoy unambiguous requirements, transparent implementation details and consistent language and tooling. As a bi-product, a natural empathy emerges for the cross-discipline demands and priorities across secure development, secure operations and security accreditation.
Teams that adopt IaC/CaC also experience two pillars of Daniel Pink’s Motivation 3.0 in autonomy and mastery across all disciplines in the DevSecOps organization. Everyone is empowered to propose changes to any dimension of the IaC/CaC codebase through peer-reviewed pull requests, provide constructive feedback on every aspect of the codebase, and have the opportunity to be exposed to expertise and implementation details across disciplines to truly build out T-shaped skills required for DevSecOps.
The high-trust, empowered, continual learning DevSecOps culture supported by IaC/CaC also serves as a consistent and welcoming talent onboarding experience that is fundamental to attract and retain superlative engineers across all disciplines throughout your organization.
Security and Accountability
IaC/CaC also results in objectively higher security in delivery and operations. First, software-defined IaC/CaC enables security accreditation automation, eliminates cumbersome paper-driven security control baselines and eliminates gaps/drift between what is implemented and what is documented (as the code itself is self-describing and centrally controlled). Second, having your IaC/CaC extend through to software-defined security policy empowers your organization to leverage CI/CD to respond in near real time to threats as they are identified/detected and effectively address zero-day threats. Third, IaC/CaC and software-defined policy opens the door to AIOps detecting, quarantining and containing threats in operation without a human in the loop.
The same benefits of having central source control for your system and application codebase of full accountability and non-repudiation are also realized when adopting IaC/CaC. Having a full trail and change history of every line of IaC/CaC creates unparalleled accountability of who changed what, when, and why. This is critical in terms of not only securing your supply chain all the way from application down to infrastructure, networking and security, but also in terms of documentation of the oral history of the codebase. In effect, a team member is able to look at the change history to understand how we got here at both a macro and micro level.
Challenges
Like any technology or innovation, IaC/CaC is not without its challenges and introduces opportunities for some missteps. But as you’ll find, they all can be mitigated and/or avoided with proper attention. A common challenge with IaC/CaC, as with any software coding effort, is analysis paralysis around what tooling to use, what domain-specific language to adopt, which tools and platforms to use, etc. Coupled with the fact that the software community is well known for strong and often widely varied opinions, this can be a recipe for infighting and feuding in terms of “the right way.”
This can be effectively mitigated with the establishment of foundational organizational principles and philosophies and then reference implementations and governance that align to those principles. This approach helps teams that would otherwise be paralyzed by choice, while not stifling the innovation in the organization by leaving room for alternate implementations in alignment with the organization’s foundational philosophy. The added benefit to this approach is that it allows for the establishment of enterprise quality and performance and capacity metrics around delivery, frequency, and velocity.
Conclusion
Ultimately, the benefits of IaC/CaC and software-defined everything clearly outweigh the challenges. Organizations looking to embrace DevSecOps and deliver on true digital transformation therein should view IaC/CaC as a table stakes requirement and foundational pillar of the ecosystem. Yes, software ate your infrastructure – along with the rest of the world’s – and that’s a good thing!
