How Multi-Cloud Made Automation a Necessity

A survey conducted by the Tepilo in the UK found that it takes an average of four months for a new house to feel like a home. I am apparently not average.

I’m also not British so maybe that can be my excuse. You see, I’ve lived in my house for seven years now and I still have trouble remembering which light switch turns on the fan and which one turns off the outlets in the living room. As you might imagine, getting it wrong causes quite a bit of consternation for anyone enjoying a movie or playing a video game at the time.

No two houses are the same in this respect, by design. Though the mechanisms—the switches and rockers—are the same and we all know how to operate them, they are not standardized in terms of position or location within the house.

If, however, I committed to a home automation system and brought it with me, this would likely not be the occasional problem it is. Because operating the fan and the lights would be done through a familiar, standardized interface.

This is the reality of cloud properties. They all use the same mechanisms—APIs, consoles, processes—to perform common operational tasks. This is one of the benefits of cloud. And in terms of onboarding new technology professionals, it can dramatically reduce the time required for onboarding. The infrastructure management layer is the same for every company. Same APIs. Same consoles. Same processes.

In a bespoke data center—whether private cloud or traditional—this is not necessarily true. There are multiple frameworks in play (think OpenShift, OpenStack, etc.) that require specific knowledge and expertise to operate.

This ultimately reduces the time it takes to onboard a new technology professional, because they already have a working knowledge of “the cloud.” If you need to scale out your cloud operations team, you find someone who is familiar with Cloud X. This is not a new concept. If you need a developer to work on an app that requires JavaScript knowledge, you generally don't seek out a Python professional.

This is one of the reasons multi-cloud is challenging: it increases the domain knowledge required and returns to the onboarding process the need to train individuals on how to operate infrastructure. Like my house, no two clouds are the same and while basic infrastructure concepts may be similar, the terminology, object models, APIs, and consoles are not.

Unsurprisingly, the reality of domain specific tools and processes unique to a cloud property has given rise to cloud “silos” in the enterprise. Half of all respondents in our annual research described their current approach to managing multi-cloud as dedicated teams per cloud property. Moreover, the other half indicated it was their preferred model.

This is unsurprising to me. If you think about cloud as a product—which it is—you will quickly discover they incur the same operational debt as any other product. Models, APIs, and workflows are unique to each one. It makes sense to focus on developing expertise for one rather than settling for mediocre management across all.

Multi-cloud realities have given rise to the adoption of infrastructure automation tools. It is not just that automation makes provisioning, configuration, and operations easier, it is also the fact that infrastructure automation tools are cloud-agnostic. This means that the same Terraform templates or Ansible scripts used for one cloud can be used for another, because the tools themselves abstract away the differences that make managing multi-cloud complex.

This is an example of converging on a consistent methodology and toolset that enables everyone to move faster, with confidence. This theme is evident across enterprise IT. Standardization is a means to achieve consistency whether it’s at the application security and delivery layer, the application infrastructure (web and app server) layer, or the data storage layer. Consistency is, if you’ll forgive the redundancy, a consistent theme when it comes to the challenges of multi-cloud.

This is how multi-cloud made automation not a nice to have, not a competitive advantage, but a necessity.