Getty Images
Why policy-based automation matters for today's IT operations
IT environments are more complex than ever, and traditional automation might not be enough. IT leaders should consider policy-based automation for operational consistency, governance and incident response.
Enterprise-class organizations have long acknowledged that modern IT environments are far too dynamic and distributed to manage and maintain manually. However, traditional automation also has its limits. Automation was initially used to eliminate repetitive tasks while also reducing the potential for human error. However, this type of automation is largely compliance-agnostic.
This is where policy-based automation comes into play. Policy-based automation is an approach in which a predetermined set of policies and rules ultimately determines the automation engine's behavior. To put it another way, traditional automation centers on automating tasks; policy-based automation automates decision-making processes based on the rules that have been established.
Policy-based automation and its core components
Although each vendor has its own approach to policy-based automation, the available tools tend to be based around the same basic, high-level components.
Rules. These define the system's behavior and acceptable outcomes. Rules might be based around security policies, compliance mandates, resource allocation goals or desired state configurations.
Automation engine. Sometimes called an orchestrator, this is the component that actually performs the automated tasks.
Monitoring and telemetry. These tools monitor the organization's IT infrastructure in real time and detect situations that would warrant invoking automation. If the monitoring mechanism detected configuration drift, for example, it would likely invoke a rule to bring the system back into compliance.
Enforcement mechanism. The enforcement mechanism's job is to make sure that systems remain compliant with the policies that have been established. Think of it as a script, a workflow or a set of instructions that can be used to achieve a desired outcome.
For example, if the tool's monitoring engine detects configuration drift, and a rule indicates that the affected system must be configured in a specific way, the automation engine ultimately will reconfigure it. But it can't do it by itself; the enforcement mechanism must tell the automation engine how to fix the problem.
Auditing and reporting engine. Even though a policy-based automation system is designed to help with compliance, the tool itself must also be compliant with any applicable regulations. As such, auditing and reporting capabilities ensure transparency and provide the information that is required during compliance audits.
What makes policy-based automation different?
Traditional automation typically focuses on automating individual tasks. These types of tools generally revolve around a collection of scripts, which can be somewhat static and often lack any sort of transparency.
The big thing that makes policy-based automation different from traditional automation is that it is designed to automate decisions, not just tasks -- although it can perform task automation, too. It does this by using a collection of rules to determine intent and continuously enforces governance based on those rules.
Another factor that makes policy-based automation different from more general-purpose automation tools is that it incorporates policy as code. PaC is similar to infrastructure as code (IaC) but focuses on using machine-readable code to define policies. In many products, PaC is used to define the rules, while the tool as a whole operationalizes and enforces the rules.
Why policy-based automation matters
Modern IT environments experience constant configuration changes and generate massive amounts of telemetry data. Without automated policy enforcement, configuration drift and security holes would become inevitable. More importantly, compliance would be enforced inconsistently across the organization, potentially leading to costly regulatory fines.
Benefits of policy-based automation
When properly implemented, policy-based automation can provide enterprises with several benefits, including the following:
- Improved operational consistency.
- Faster incident response.
- Enhanced security and compliance.
- Better governance and auditability.
- Lower operational costs.
Implementation challenges
There can be any number of challenges associated with implementing policy-based automation. Some might stem from the automations themselves, though others might revolve around the organization as a whole.
Consider these potential challenges:
- Automation errors. If created incorrectly, automations could cause bottlenecks, generate false positives or prove to be incompatible with legacy infrastructure.
- Policy sprawl. Over time, an organization might accumulate redundant or overlapping policies. Worse yet, it might create contradictory policies that lead to inconsistent enforcement.
- Skills gaps. IT teams seeking to implement policy-based automation will need expertise in IaC, policy engines, cloud governance and automation frameworks. As such, providing the IT staff with the necessary training is critical.
Getting started with policy-based automation
For those just getting started with policy-based automation, it is unrealistic to expect to automate the entire organization all at once. Instead, begin by implementing policy-based automation in areas where it will deliver the highest impact, such as patch management, cloud cost controls or configuration drift remediation.
As the organization works toward full implementation, it is important to define clear objectives and establish a way of measuring outcomes. This might involve looking at metrics such as mean time to resolution, compliance adherence rates or operational cost savings. The important thing to remember is that the metrics the organization chooses to monitor should align with its stated goals and objectives.
Brien Posey is a former 22-time Microsoft MVP and a commercial astronaut candidate. In his more than 30 years in IT, he has served as a lead network engineer for the U.S. Department of Defense and a network administrator for some of the largest insurance companies in America.
