RESOLVE ’22: How to get multi-cloud done right

Multi-cloud is inevitable. With AIOps, struggling in its complexity doesn’t need to be.

Business technology stacks don’t appear out of a vacuum. For the modern cloud-enabled, cloud-dependent company (that is to say, most of them), the look from the inside looks more like an ongoing evolution than a monolithic choice. Every workload, process and even human-powered task can come with its own specific technological dependencies and needs—creating an environment where everything works in its own space—with a hard emphasis on in its own space.

The fourth event in our RESOLVE ’22 series, titled How to get multi-cloud done right, took aim at this all-too-common IT Ops problem. Moderator George Knoll, director of category management at AWS, shared insights and led discussion with two esteemed guests: Chris Archer, director of cloud products and future engineering at Cardinal Health; and Anthony Evans, a solutions engineer with Stackstate.

Read on for a breakdown of some of the key points from the talk. A link to the full panel can be found at the bottom of this post.

Understanding cloud complexity in the context of company growth

As Archer noted early in the panel, no amount of planning in the 2010s could have protected the average company from undue sprawl and complexity in the 2020s. Things have moved so fast in the space of a decade that it’s simply impossible to build an architecture in a way that suits current business needs, concrete technological plans and the conceptual wants and must-dos most companies use as guideposts.

Moreover, technological strategy isn’t the only factor governing a company’s technological growth over time. An anecdote Archer told in the same early segment exemplifies this: “Originally, we kind of did Amazon, and then we transitioned to Google,” he said. “So now Google is our primary, but we still have some footprint on Amazon… and then we also have to have Azure in the space due to an acquisition and that center being a .NET framework.”

Take this story and generalize some details and one has a tale that fits pretty much every cloud-enabled business’s growth over a given period. And however they get there, it results in an environment where even simple tasks—and transactions that appear seamless on the customer’s screen—require deep interplay between multiple cloud service providers (CSPs).

“Working across the three, it’s fairly complex,” Archer said. “You might have a business process that starts in GCP or through our SAP environments, then ends up in Amazon from a warehouse management perspective.”

And in terms of IT incident management (and the larger IT incident management process), that can result in further problems the company must contend with: “You drove that complexity through,” he continued, “stuff goes wrong, and you’ve got a longer area that you’ve got to check as you go through.”

Modernizing away from the lift-and-shift model

In his part of the panel, Evans said that today’s IT Ops environments look the way they do in part because limitations in technology—and, likewise, misunderstanding of available resources—impeded what companies could do with cloud as recently as “five, six, seven years ago.”

“That’s what [companies] really thought about cloud back then,” he said, noting that taking advantage of pay-as-you-go compute resources was effectively the primary reason people moved to the cloud in those days. “You didn’t have to wait seven months for a server to show up, and you didn’t have to then install that physical server.”

Because of that, the so-called lift-and-shift model allowed companies to meet that very limited objective. And while elastic usage and payment models are certainly still a major rationale in many a cloud migration today, CSPs also have a lot more to offer their clients—and the companies using their services are increasingly comfortable relying on them for various critical tasks and workloads.

Archer noted the advantages of a model he informally referred to as the “lift-and-shift plus.” In this case, he said, his business did largely focus on carrying native functions/workloads (and not much else) to the cloud, but also “looked for opportunities we might have to refactor or modernize that app” at the same time.

In Archer’s specific case, the company also had the sound judgment to focus on its “most important environments” from the start.

“Our ordering environments, or e-commerce environments, our back-end ERP or SAP, we actually did all those through new build,” he said. “Instead of doing lift and shift there, we built new servers, did fresh installs and tried to put them in the best scenario we could—short of going in and rewriting and refactoring the apps ourselves.”

Coaxing vendors into better multi-cloud support

The panelists agreed that wherever the data lives and however many CSPs a transaction may need to cross, companies evolving into a multi-cloud model often find themselves dealing with the same problem: getting the CSPs themselves—both the technology and the people governing it—on the same page.

In some regards, it’s an outgrowth of a phenomenon that has existed as long as IT vendors have, Knoll said. “I remember many, many late nights pre-cloud, early Saturday and Sunday mornings on conference bridges… You would end up having support resources from different vendors involved, and everyone would kind of point the finger at each other to try and identify root cause.”

Of all the problems cloud technology has stopped, finger-pointing is not one of them. Archer sang the praises of “weekly meetings where the teams come together” in the name of “trying to build that partnership specifically with the cardinal resources that are supporting our environment.

“We’ve seen a huge improvement to where—when we have an outage that impacts SAP [for instance]—SAP’s on the call, Google’s on the call, Google brings SAP resources… everyone’s working together to really try and figure out what’s going on.”

Exploring the role of AIOps in multi-cloud strategy and execution

In discussing how these factors culminated in a need for stronger incident management processes, Knoll dropped an insightful nugget of wisdom: “Intelligent application of AI and AIOps as a philosophy to observability in the era of microservice architecture is really a survival strategy.”

Following that, Evans stressed that viewers “treat observability as something separate. We need to make sure we have an accounting of everything that’s out there when it’s sitting high-level topology.”

Evans continued that this level of outlook can be critical to building a stronger AIOps approach both now and in terms of future outlook/capabilities. Treating observability as its own category with tools that “branch across” CSPs enables companies to implement other solutions that “bring together” their ability to make correlations from it all.

Supporting this, when asked about things companies earlier in their multi-cloud strategy can do to ensure less friction and greater success, Evans was clear in his reasoning: “Convert to microservices prior to migrating wherever you can. Convert as much as you can, and experiment as much as you can, in a world where you can do that without errors costing a ton of money, time, whatever.”

It’s a smart outlook, both in terms of AIOps and the larger topic of cloud migration—and one that companies can use at high-level to shape their approach as they take more steps into the inevitable future that is multi-cloud.

Full Panel Link

A link to our full RESOLVE ’22 panel, How to get multi-cloud done right, can be found at the following link.