Lift and shift
Despite the perils of lift and shift, it remains a common pattern for cloud migration. That’s understandable in cases where organizations have data centers that are approaching end-of-life, says Shaw. “In those circumstances, not many companies want to recommit to another 20 year data center contract, so lift and shift becomes a viable option.”
Shaw has worked with companies that have made that choice; nearly all have done so with a plan to rearchitect their applications at a later date. “Not many have actually achieved it,” he adds.
Replatforming business-critical systems
As a first stage to optimizing applications to run in the cloud, organizations might look to replatforming, perhaps moving an application from running on a traditional relational database to one that’s running in the cloud.
The advantage of replatforming is that it allows enterprises to leverage some cloud capabilities, without having to go through the laborious process of decomposing their large, complex, business-critical monolithic applications.
Rearchitecting your monolith
To take full advantage of the cloud may mean rearchitecing your monolithic applications — that is breaking them down in a piecemeal fashion and rebuilding them in a cloud native way, gradually over time moving the entire application into the cloud.
This can be a multiyear endeavor, says Shum, so it’s essential that business and IT teams are working together closely before they start. “If there is no business use case that we're actually trying to drive to, you're going to get to that cloud fatigue because no one will see cost benefit immediately,” she adds.
If you have that strong relationship between IT and the business, decomposing your monolith can dramatically increase your organizational agility in the long run.
Nonetheless, decomposing a monolith is a daunting task. ThoughtWorks typically advocates for a thin-slice approach — where a slice represents a complete function that can be transitioned to the cloud. “Typically, we’d build almost a matrix and look at what is the top business functionality that you can actually see immediate value from transitioning,” says Shum.
“When we think about a thin slice, it should cut through parts of the technical and architectural stack. You want one that would enable you to drive things like continuous integration and delivery pipelines that will be a core part of becoming cloud native.”
For some time, ThoughtWorks has been championing the notion of polycloud. This approach to cloud not only rejects the practice of signing one cloud enterprise agreement but also the notion that companies should take a lowest common denominator approach to cloud services in the hope that it would make it easier to migrate between cloud providers.
The idea of polycloud probably reflects a level of cloud maturity that few organizations have today, says Shaw. But there are strong reasons to aim for it, he adds.
Today’s big cloud providers have reasonably similar core offerings but important differences do exist — whether that’s around data privacy or machine learning capabilities. And for some workloads, you’re going to see significant advantages when choosing one provider over another.
Enterprises should also consider their applications’ lifecycle. “For something like a core banking system that might reasonably have a 10-year life span, do you really want to tie yourself to one provider for all that time?” Shaw asks.
There’s also a distinction to be drawn between polycloud and multicloud. Polycloud is using different cloud capabilities from multiple providers, based on the business’s assessment of which capabilities best fit their needs. Multicloud in this context is using the same capabilities — and deployed applications — in different places, sometimes as a backup for SLA problems. We often see companies embrace a multicloud strategy for business continuity reasons, says Goedert, especially if they’ve had issues with their providers’ ability to meet their service-level agreements.
Cloud is different
As we’ve seen, realizing cloud’s potential for the enterprise involves huge changes within your organization — from changing your IT purchasing behavior, to how your applications are architected, to how your teams work. “It’s a multiyear effort,” says Shaw, “and you’re probably not going to get everything right.”
The winners will be those courageous enough to learn from those mistakes, and not retreat to the old ways of working. “Ultimately, enterprise modernization can be expedited by moving to the cloud,” says Goedert. “You need to plan for how you’ll manage that.”