You are here

Lessons from DevOps: The future of automation is iteration

public://pictures/bhanu_singh_pic.png
Bhanu Singh, Senior Vice President, OpsRamp

As IT adopts automation for many back-office tasks, it's important to continuously monitor and update those practices. "Setting and forgetting" is a practice of a bygone era; in today's world of on-demand infrastructure, automation ought to be constantly evaluated for maximum benefit.

A recent Capgemini survey revealed that while enterprise-wide automation is still in its infancy, IT automation projects are moving along. IT is starting to view automation less tactically, and more strategically.

The survey also showed that IT automation can be responsible for several quick wins, including in the areas of self-healing, event correlation, diagnostics, application releases, cybersecurity monitoring, and storage and server management tasks.

These projects lead not only to massive IT cost savings but, more importantly, to an increase in reliability and responsiveness to customer demands and business services. This would indicate that while automation is a great solution for manual work, it's also a part of a high-level, strategic IT plan to innovate the business.

Here's why the future of automation is iteration.

[ Learn how to transform your IT with AIOps in TechBeacon's guide. Plus: Download the analyst paper on how AI is changing the role of IT. ]

The new expectations of automation

The reality for automation, of course, is that IT is living in a different world than even five years ago. DevOps practices such as agile methodology and continuous deployment and optimization are starting to take hold within the modern enterprise, and one wonders what automation can learn from DevOps. Can automation be continuous, contextual, on-demand, and always optimal? Can it be as fast as the changing speed of business?

Eventually, artificial intelligence for IT operations (AIOps) will meet these demands. But because automation has reached an inflection point of adoption and implementation and is not yet subsumed by AIOps, it's sensible to examine how modern automation ought to be orchestrated to meet these demands.

IT automation projects can have serious ramifications if anything goes wrong because, when the machines execute a policy, they do it in a big way. This is perhaps the chief reason why it's critical to take progressive steps to define and evaluate both the process being automated and the automation itself.

These steps mitigate the seriousness of any issue that can arise. This is why, when identifying a process to automate, it’s important to consider the following:

  1. Is this a good process, and is it worth automating?

  2. How often does this process happen?

  3. When it happens, how much time does it take?

  4. Is there a human element that can't be replaced by automation?

Here are the steps to see how they can provide the basis for an iterative approach to automation.

Is this a good process?

This may seem like a rudimentary question, but processes and policies are often set and forgotten, even as things change dramatically. Proper continuous optimization or agile automation development will force an IT team to revisit existing policies and identify if they are still right for the business service goals.

Some processes are delicate, and automation may threaten their integrity, whereas others are high-level, and automation neglects the routine tasks that underlie the eventual results. A good automation engineer understands what tasks are the best candidates for automation and sets policies accordingly.

Some traditional processes that are ripe for automating might include:

  • Patching: Applying patches can be policy-driven, with an if/then decision tree.
  • Updating: Creating this policy is very similar to what you've done for patching.
  • Event correlation: You can design a policy of creating groups for similar events.
  • Server orchestration: Creating a policy to optimize on-premises assets is easy and turnkey.
  • Application releases: On a small scale, application releases can also trigger a set of policy-driven automation tasks.
  • Diagnostics: Executing a policy-based script on your network or other resources to proactively scan for incidents.

[ Enterprise Service Management brings innovation to the enterprise. Learn more in TechBeacon's new ESM guide. Plus: Get the 2019 Forrester Wave for ESM. ]

How often does this process happen?

Patching, updating, load balancing, or orchestration can follow an on-demand or time-series schedule. As workloads become more ephemeral—moving to serverless, cloud-native infrastructure—these process schedules will need to change.

An automation schedule ought to be continuously adapted to the workload need, customer demand, and infrastructure form. Particularly as the business continues the march toward digital transformation, the nature and schedule of particular work may become more dynamic.

A note about continuous policies: These absolutely can be automated, but typically require additional oversight. For example, there's a need to manage cloud-native, serverless deployments or subscriptions according to cost guardrails. But these costs can be billed to the minute—or second in some cases—and budgets change every quarter, and so the process will require resetting.

When it happens, how much time does it take?

This also depends on the underlying infrastructure. Some legacy systems require updates that may take hours, and some workload orchestration will be continuous.

  • Server orchestration: Can be anywhere from once to annually, depending on maintenance schedules or manufacturer recommendations.
  • Patching/updating: These are dependent upon manufacturer release schedules.
  • Diagnostics: Again, refer to manufacturer recommendations for legacy equipment. Diagnostics automation is ruled by certain compliance/audit policies: How often must this task be performed to meet or exceed reporting guidelines?

Also remember that automation policies must be tested to be efficient and effective for the schedule and frequency of the formerly manual task.

Is there a human element that's irreplaceable?

As much as you may want to, it's difficult for automation to shift left (to more experienced tasks and teams) without the help of AI or machine learning. Many times there is a human element involved in deriving insights, creating new workflows, managing programs, or building architecture.

When creating an iterative automation practice, make sure you identify where human interaction must occur to evaluate and optimize. In our lifetime, technology has advanced at lightning speed, with robots now performing jobs once held by people. However, there are times when a machine just cannot deliver the same quality a human can.

Automation for all

Automation is perhaps one of the most defining signatures of the future of IT operations management. It relieves teams of routine work and helps improve overall efficiency, all while driving quick wins that turn an IT team into heroes.

But don't let automation be the end goal. Instead, consider it a tool, like any other tool, that can drive action from data. And until AI is an everyday option, it's incumbent on the IT professional to continuously optimize the data that drive that action.

[ Learn how robotic process automation (RPA) can pay off—if you first tackle underlying problems. See TechBeacon's guide. Plus: Get the white paper on enterprise requirements. ]