Redefining Automation in a Multi-Cloud World

The central thesis driving most enterprise IT decisions is that IT needs to become more agile. Not surprisingly, automation has taken a starring role in industry dialogue as enterprises focus on improving agility. But as the broad market stands on the precipice of cloud and multi-cloud, does the foundation of automation change? And if it does, how can enterprises simultaneously pursue a current-generation automation agenda while preparing for the inevitability of multi-cloud architectures?

Enterprise IT is complex

Let's first look at the state of enterprise IT infrastructure. For enterprises, the No. 1 impediment to more agile operations is complexity. Complexity arises out of diverse operating environments:  The more different things are, the more complex managing them becomes. 

Take, for example, large cloud properties. Many assume they have the most sophisticated, customized operating environments imaginable. While they are highly automated, the foundation that underpins them is actually uniform. Unburdened by decades of legacy equipment and applications, they had the freedom to start from scratch, and chose to make uniformity an explicit architectural consideration.

Contrast that with enterprises. It’s not uncommon to find applications that are decades old, running on equipment well past its prime. As a result, enterprises deal with infrastructure sprawl. Yes, the technical debt is piling up, but when IT is a cost center, the next dollar is frequently spent on a quick fix to address the next business requirement. In a somewhat cruel twist of fate, the need to move quickly actually prevents enterprises from being more agile.  

Containment as a strategy

The primary weapon to fight complexity in the enterprise has been containment. Enterprise IT has historically broken down their infrastructure into domains because there is no other practical way to handle something so complex than breaking it down into smaller, more consumable pieces. In the networking world, for instance, most enterprises do not have an enterprise network. Rather, they have a campus, and a data center, and a branch, and a WAN. Each domain has its own teams that have their own priorities and budgets. 

Relative to automation, domains also have their own architectures, tools, and processes. In fact, the domain boundaries are largely impermeable, meaning workflows and visibility tend to stop at the edges of a domain, needing human handoffs for anything that requires cross-domain coordination. 

Multi-cloud cannot be contained

The problem is that the migration to cloud and multi-cloud breaks this containment strategy. The promise of multi-cloud is uniform experience regardless of where a workload is. Users should be blissfully unaware whether an application is being served out of a private data center or AWS or Azure, or accessed from a campus, a branch, or over a VPN. 

For this to happen, policy and control must be uniformly applied across the whole of the infrastructure, meaning silos need to merge to offer a cohesive set of fungible resources. This means a strategy of containment will no longer work; for multi-cloud environments, a significant shift in IT management strategy is necessary. 

Automation and workflows

As part of this shift, it’s critical enterprises examine their workflows. In fact, the beginning of any automation strategy should start with companies identifying the workflows they are automating. This isn’t always as easy as it sounds – many enterprises don’t fully grasp the workflows that drive their infrastructure – but it’s an imperative one.

Workflows are the key to achieving automation; in other words, they are the verbs in IT that define what people are doing. Before the multi-cloud world, workflows oriented around the domains. They are dependent on a relatively small set of activities executed by a team across a fairly homogenous collection of systems. Because the scope is significantly narrower—by design—automation is actually simpler.

clouds-shutterstock.jpg

In a multi-cloud environment, though, the most meaningful workflows span domains. When a workflow crosses one of those boundaries, it means the context is different, the tooling is different, the policies are different, and the organizational responsibility is different. Workflows must be automated and set up in a way that these differences are seamlessly managed no matter the domain.

Automating in a multi-cloud environment

The most basic premise of automation is: see something, do something, so enterprises will want to start with multi-cloud visibility to prepare. To do this, companies should ask questions such as what information needs to be available? How is it collected? Is it real-time streaming or polling? Do the tools have reach across various domains and into whatever public cloud instances likely to be used?

Enterprises should then ask themselves, how are workflows executed? Because multi-cloud will necessarily be multi-vendor, can workflows be executed across a heterogeneous environment? What programmatic interfaces are required on the devices to support multi-cloud programmability? 

And most importantly, enterprises should ensure any automation efforts are initiated with all the relevant parties at the table. Having the data center team start down a path in isolation, for example, is a recipe for failure. Because operations places additional architectural requirements on the underlying systems, both the operators and the architects across all domains need to participate as well.

Ultimately, automation should become a leading consideration rather than a post-production tack-on. As discussed, the primary reason to move to cloud and multi-cloud is operational agility; it would be disastrous if agility was not an explicit architectural decision at the outset.