As the enterprise IT world speeds towards a multicloud future, much of the industry dialogue has shifted toward the technology needed to tap into the potential that multicloud offers. But in the history of IT, it’s been the people, not the technology, that have proven the most durable barrier to progress. So, while the technology is absolutely required, discerning IT leaders will begin their pursuits with the teams with whom this technology will ultimately reside.
Recognizing an Operational Transformation
The key to preparing for multicloud is understanding that the meaningful change is not the shift of workloads from on-premises servers to servers that reside within the cloud. It’s not about the expense — either capital or operational. Cloud is generally about unlocking the operations made available by the major cloud providers, leveraging their heavy investment in application deployment and infrastructure management, to become more agile. As a derivative of the cloud movement, multicloud builds on this operational focus.
For most of enterprise IT, the concept of multicloud is simple: If you have a workload running in AWS and are leveraging a SaaS service somewhere, you might think you are running a multicloud environment. However, the distinction between multiple clouds and multicloud is important.
The objective is not to simply expand the existing IT operations teams, adding a new team for every venue in which an application is hosted. Multicloud is not just about utilizing diverse infrastructure — on-premises, cloud A, cloud B and more — but unifying operations. It’s about treating these pools of resources as a cohesive unit despite variances in the underlying building blocks.
As such, multicloud is about operations. And any IT leader who expects to benefit from this movement must first recognize that this is an operational transformation.
From Devices and Commands to Intent and Workflows
Most IT operations professionals have grown attached to the command-line interface (CLI) as the primary tool for their jobs. For IT leaders looking to adopt multicloud, there must be a fundamental shift away from managing discrete devices command-by-command.
The CLI is a bit like flying a plane using a yoke that is directly manipulating the rudder. It works, but it doesn’t scale beyond the most basic of operational workflows. In the same way that a pilot could not operate a modern plane efficiently with just a stick and rudder, an operations team cannot operate modern multicloud infrastructure using the IT equivalent.
This means that leaders need to encourage the elevation of interaction above the CLI. Importantly, this does not require multicloud workloads to get started.
It is somewhat surprising how many IT shops do not have a solid understanding of the workflows on which they rely. Even if it’s not a precursor to a multicloud migration, getting a better understanding of the workflows that power the business is good hygiene.
Begin by documenting common workflows. For example, every issue that is addressed represents an opportunity to capture the tribal knowledge that drives troubleshooting in even moderately sophisticated environments. IT teams that are beholden to a small number of individuals who happen to understand the nuances of the architecture are precariously perched.
These workflows become the foundation for automation and tooling evolution. Without knowing how tasks are executed, it is impossible to abstract them to the smallest set of inputs required. These inputs can then be mapped to the drivers behind the inputs, allowing operations teams to dabble in intent rather than esoteric device syntax. When done well, IT leaders should be able to distill from their workflows the meaningful pieces of intent — connect this application to that user — which will ultimately serve as the foundation for multicolor operations.
Feelings Are Important
One of the major mistakes that the IT industry has made for decades is positioning automation as a means of separating people from their livelihoods. When leaders use technology to fundamentally displace the workforce on which they are dependent, they are setting themselves up for failure.
Multicloud operations ought not be about speeding the workforce to obsolescence. It should be about connecting that workforce to the business, allowing them to be more efficient and deliver a more meaningful outcome for the company.
It’s clear when teams don’t understand this concept. Job descriptions are a great indicator, with listings that state: “Seeking a full-stack developer with 10 years cloud experience, seven or more years of working with containers, and production experience with serverless.” These technologies have not been around for that long. Beyond being impractical, even if these IT unicorns existed, they would be well out of reach for the average enterprise.
The move to multicloud begins with investing in the people on whose backs the current environment has been built. Training them on how the cloud works ensures that they see a future in the transformation. How can anyone drive full force toward an end state that doesn’t include them? Instead, leaders need to make their teams a part of not just the journey, but the final solution.
Measure What Matters
The OKR (objectives and key results) movement is about identifying the most important bits and measuring those. As multicloud continues to emerge, this means a shift in traditional IT metrics.
Whereas the last two decades have been primarily about uptime, asking questions such as “Is it running?” the next two decades will be about resilience. The goal is no longer to avoid failure. In large, distributed, scale-out systems, failure is a given. The key is making sure that failure doesn’t interrupt the service.
The major cloud properties are instructive in this practice. For example, when a piece of hardware experiences a software bug, companies such as Google and Amazon don’t troubleshoot it. They remove it and replace it with an identical component. The architecture ensures that a missing piece doesn’t mean a missing experience.
This means that metrics like uptime need to be replaced with application and experience-oriented measures. How long does it take to spin up a new application? How many user-generated issues were experienced? How quickly were user issues resolved?
Without the right metrics, the team will not know what they are pursuing.
The Bottom Line
The bottom line in any multicloud migration is understanding that the technology represents less than a third of the total issues that need to be resolved. Those issues will come with services and support from an ecosystem of suppliers eager to peddle their wares.
The real bottlenecks are within enterprises. Without identifying and shining a light on them, multicloud will be just another technology buying cycle: long on promise but short on delivery. Looking beyond the products is the only sensible way to manage managing multicloud.
Feature image via Pixabay.