How to adopt Automation as Code: Extending Infrastructure as Code into Policy as Code

Building on the strategic foundation of Infrastructure as Code (IaC), organizations are beginning to use these practices to automate IT processes at every stage of the operational life cycle. Just as IaC standardizes the build, provisioning, and deployment of infrastructure, IT teams can adopt Ops as Code (OaC) to codify the management and maintenance of systems after they are deployed. This approach can then be extended into Policy as Code (PaC) to automate governance, risk, and compliance processes for applications and solutions.

Automating to accelerate delivery and improve efficiency is a common objective for application and infrastructure teams, but most continue to rely on manual approaches to Day 2 operations and governance. Automation can provide just as many benefits in these areas, but using it to perform Day 2 processes also requires established teams to learn new tools and methods. Ops as Code and Policy as Code simplify this cultural change by extending established IaC strategy, allowing organizations to apply what they know—and the tools they use—to different tasks.

Following IaC’s methods, enterprises can adopt OaC and PaC to codify best practices and automate routine tasks for every operational process, making end-to-end automation an achievable state. These Automation as Code approaches ensure that processes are executed in a consistent, scalable way, so that teams can—with minimal manual intervention—build and maintain applications, infrastructure, and workloads that are compliant from start to finish.

Building and managing IT infrastructure like servers, cloud instances, operating systems, storage, load balancers, and other endpoints has historically been a time-consuming manual process. But as infrastructure is increasingly containerized and deployed across diverse platforms—from data centers to multiclouds and edge locations—some of it is deployed as code, particularly in the cloud.

When deployed as code, infrastructure can be spun up faster to meet rapidly growing demand and scalability needs. This benefit has also added more complexity and urgency to managing infrastructure, and organizations often need to provision, deploy, and take it down on a daily basis. To keep up, IT teams have adopted IaC to automate these processes.

What does IaC involve? 

An IaC approach defines, provisions, and manages infrastructure through code that is executed automatically. With IaC, configuration files are created that contain infrastructure specifications, which makes it easier to edit and distribute properly configured infrastructure and cloud instances. By codifying and documenting these specifications, IaC helps teams avoid undocumented, ad-hoc changes, and ensures that the same environment is provisioned every time.

Automating infrastructure with IaC means that developers don’t need to manually provision and manage infrastructure components each time they develop an application or push a deployment—which can drastically improve speed and consistency, while reducing human error and downtime. This approach also allows organizations to build best practices into automation code, so that the execution of every task is informed by teams’ shared expertise.

Read a guide to automating infrastructure workflows

Extending IaC strategy

IaC was a challenging transformation for most organizations, as it took time to develop new tools and implement different ways of working. But teams were also rewarded with the freedom to be more flexible in what they focused on and more agile in how they responded to problems. Now many automation tools can handle IaC and IT teams have largely embraced the cultural change, enjoying the many benefits that come with it.

By using the established methods and tools designed for IaC, IT teams are beginning to take an Automation as Code approach to processes beyond provisioning, configuration, and application deployment, across the entire operational life cycle. There is no single definition of the operational life cycle, but it is typically broken down into the following Days:

• Day 0: Design. Specifying the build, configuration, and provisioning constructs for infrastructure. 
• Day 1: Deploy. Installing, setting up, and configuring infrastructure.
• Day 2: Maintain. Managing, maintaining, and updating systems related to the deployed infrastructure.

While IaC offers a consistent way to build and provision infrastructure on Day 0 and Day 1, Ops as Code takes this approach to Day 2 operations like managing, maintaining, and updating systems—which continues until the application or service needs to be deprovisioned.

Day 2 tasks—like monitoring how systems are working, installing upgrades, and responding to issues—have traditionally relied on manual labor. When a server or application goes down, IT teams might receive a ticket alert, but this is just a symptom that needs to be investigated. An individual has to then evaluate the issue, so they might log onto the physical box, explore to identify the cause, and involve additional IT experts to resolve it. Eventually issues like this get resolved, but the process takes time, especially when multiplied to the scale of enterprise operations.

On top of that, the complexity of Day 2 operations has grown just as much as Day 0 and Day 1 infrastructure tasks, and yet automation hasn’t been widely used for Day 2 challenges. Many organizations have adopted IaC to automate Day 0 and Day 1 processes, but now this same approach can be applied to operations that stretch from data centers, across cloud environments, to edge deployments, to help limit tech sprawl and free up resources.

What does Ops as Code involve?

Ops as Code is a natural progression of IaC. It involves taking the accumulated knowledge of infrastructure and operations teams—all the experience they’ve gained by working through problems—and codifying it with automation. This means that operational knowledge becomes an accessible resource and doesn’t just live within individuals on teams.

OaC is the process of standardizing, codifying, and systematizing teams' how-to, operational knowledge of Day 2. To take steps toward adopting OaC, organizations should: 

• Standardize around a common codebase for use across the organization, improving operational consistency.
• Codify operational knowledge and build best practices into automated processes. 
• Systematize disparate tools and processes into an integrated, end-to-to end approach.

The how-to of Day 2 is converted into code—into something that can be automatically executed as systems become increasingly intelligent, complex, and interdependent.

As with all uses of automation, Ops as Code isn’t meant to replace people—it enables teams to minimize tedious, manual tasks and instead focus their attention on forward-thinking projects. By combining teams’ knowledge into shared approaches, OaC also supports collaboration across multiple operating models and team structures.

Extending IaC and OaC methods into governance can free IT teams from bloated, request-based processes, especially when it comes to enforcing policies—rules, conditions, or instructions designed to ensure that operations adhere to compliance requirements, best practices, and corporate directives. 

Once infrastructure and operations are defined and managed as code, security and compliance teams can use the same strategies to apply policies to that code and standardize how they manage governance—with a Policy as Code approach.

Automation doesn’t guarantee compliance and governance from the start; policies must be consistently enforced to ensure that IaC and OaC are properly applied across every stage of the operational life cycle. Traditionally, common governance methods have included: 

• Building workflows with approvals that make it harder for individuals to deliver ad hoc solutions.
• Implementing restrictive security permissions through role-based access control (RBAC) or attribute-based access control (ABAC) to control who can change which technologies in specific ways, under certain conditions or with particular characteristics.

These manual approaches can be error-prone and time-consuming. Policy as Code seeks to automate these processes. For example, automation can be set up to prevent IT staff from creating a cloud instance that doesn’t comply with corporate standards—or keep them from delivering code that doesn’t implement a compliance mandate. RBAC and ABAC are still needed, but PaC makes it possible to create a much more granular and automated process that determines what can be done and when.

What does Policy as Code involve?

Following strategies similar to IaC and OaC, PaC automates the compliance process by writing policies and security requirements into code, which makes it possible to build standards into every process and consistently enforce the same rules across teams. By defining, updating, sharing, and enforcing policies using code, PaC centralizes governance and makes it easier to efficiently apply policies to every IT action in a documented, consistent way.

If policies are defined as code, they can be more seamlessly applied to infrastructure when it’s spun up and deployed—and to operations when automated tasks are executed—to enforce a standard approach regardless of where or when the automation occurs. For example, if an employee is running automation to remediate an issue on a specific host, the policies coded into each action can stop that individual from doing something that violates the team’s rules.

PaC also aligns technical environments and resources to agreed standards. For example, teams could use PaC to make sure that sensitive computing resources don’t have a direct route to the internet—potentially violating security policy—or to limit their service ports to just HTTPS and SSH.

As AI is becoming a scalability multiplier for a wide range of systems, it is moving IT further beyond what humans alone can achieve and what humans alone can control. If teams are using an AI service—like Red Hat® Ansible® Lightspeed with IBM watsonx Code Assistant—to accelerate automation development, they can write policies into code and infuse governance into the learning model from the start. For example, once the AI tool has incorporated policies into its learning model, content creators can write code that automatically maintains their mandated compliance requirements.

Automating governance with PaC ensures that AI-driven management can deliver transformative efficiencies while also maintaining the expected control, so that what's done for IT teams already has compliance built in.

Put simply, any type of Automation as Code transformation is mainly a cultural challenge. Using the experience gained from automating IaC, IT teams can use the same methods and tools to take a more efficient, adaptable approach to operations throughout the development life cycle.

Implementing DevOps brought enterprises a variety of benefits and headaches, but the widespread effort showed that cultural change on such a huge scale is possible. Automation always involves changing how tasks are executed, but adopting a unified Automation as Code strategy requires organizations to transform how teams collaborate by sharing practices at every stage of operations. IaC, OaC, and PaC are at the heart of this effort.

To aid the cultural shift toward Automation as Code strategies, teams should:

• Think like software developers. Use git or other repositories, while cultivating a culture of modern development and deployment thinking in every area of the business.
• Develop an automation-first mindset. If you have a new project or something you want to build, don’t just build it—first, think about how you can automate it. Start with simpler automation projects and expand from there. 
• Start with individuals’ skills and experience. Fill talent gaps by building the accumulated knowledge of everyone in your organization into automation, so that content and expertise can be shared across teams.

Automation as Code can succeed by instilling this philosophy into every single team, from those who design systems to those who manage them. These approaches go beyond occasionally automating tasks on a few teams and hoping it’s all compatible—they give teams across an organization a shared strategy and discipline that they can shape together.

To put this strategy into action, teams must also move beyond ad-hoc solutions that only work for some use cases, on some teams. IaC and DevOps can become overly complex and generate technical debt when organizations use multiple tools to drive the process. With a unified automation platform, the same automation language used to perform configuration, network, infrastructure, or cloud tasks can be extended to operational tasks across domains, helping IT teams manage the full end-to-end life cycle.

Red Hat® Ansible® Automation Platform includes all the tools needed to implement enterprise-wide automation, including Event-Driven Ansible, analytics, added security, and a broad ecosystem of certified and validated content to jumpstart new automation initiatives. It uses human-readable YAML so users of various skill levels can share, vet, and manage automation content across your organization. 

With Ansible Automation Platform, your organization can codify the experience of operations, infrastructure, and application teams in YAML-based Ansible Playbooks and Ansible Rulebooks. Playbooks and rulebooks can be used to build known solution patterns into Automation as Code approaches, and Event-Driven Ansible can trigger that automation for you when a specific event occurs.

By building expertise into playbooks and rulebooks, your teams can automate IT responses to limit configuration drift, minimize long-term maintenance issues, and improve mean-time-to-resolution (MTTR). Event-Driven Ansible’s modular design empowers you to automate IT actions when and where you need to, across domains and for use cases at every stage of the operational life cycle.

Learn more about Event-Driven Ansible

Making Automation as Code approaches even more accessible, Red Hat Ansible Lightspeed with IBM watsonx Code Assistant helps you convert subject matter expertise into trusted YAML code that scales across teams and domains. Users can enter a task request in natural language, and Ansible Lightspeed interacts with IBM watsonx foundation models to generate code recommendations for creating Ansible Playbooks. This service can help team members of various experience levels be more productive, efficient, and accurate, driving more consistent automation across your organization.

Red Hat offers interactive labs in a preconfigured Ansible Automation Platform environment. You can use these labs to experiment, practice, and learn how to create, manage, and scale IT practices efficiently—from rapid development and deployment, to simplified operations and analytics, to consistent end-to-end user experiences.