This is the first blog in a five-part series on how migrating your IT infrastructure using a multi-cloud approach enables a truly transformative cloud adoption experience.
Would you like to take a guess at how old cloud computing is?
If we go by the birth of EC2, it would be 16 years this year. Happy birthday, cloud!
If cloud is so transformative, why are we now only 30%1 of the way there after all this time?
That’s right! Over a decade and a half later and we are still 70% on-prem or in a data center. Why is that? I like to compare this sweet 16 age to a teenager getting their license. Do you really want a teenager driving your infrastructure? Sure, if it is a true cloud-native application you absolutely do. But what if you are just migrating your traditional workloads into the cloud without application refactoring?
The short answer is it doesn’t go so well.
Let’s dig in a bit more and find out why.
Born in the Cloud vs. Pre-Existing
If your applications were born in the cloud, and especially if you do not have the burden of legacy systems, life is good! Born in the cloud means you created your infrastructure operations support from scratch. As you grew, you built things that would account for High Availability, Disaster Recovery, Backups, Security, Operational People, Processes, and Tools for administration and support – this list goes on. All this had to be created to support a new hyperscale platform for cloud-native applications.
But, if you have decades of traditional IT systems, whose operational people, processes, and tools have matured over decades, you are going to be reinventing the wheel when you do a lift and shift. This begs the question: for what business value? Cloud has reached a level of euphoria that has organizations approving migrations of legacy systems without a proper evaluation of costs or alternatives. Budgets are being approved without a clear path to business value!
Simply put, inadequate infrastructure evaluation is really hammering business from a cost, complexity, and security perspective. Let’s look at the numbers on this.
The Cost of Complexity
The real miscreant in the migration of legacy systems is complexity. Migrating traditional workloads to a hyperscale platform built for cloud-native applications is going to cause some pain. The reason? Because refactoring is not an application-only issue in this type of move. Your infrastructure team must recreate backups, DR, HA, security governance, strategy, and tactics, along with the tools and processes needed to administer and support this new environment. To pull this off you are also going to need new skills, which means new hiring, which unfortunately are extremely hard these days.
Industry Analysis:
Complexity Leads to Cloud Outages. Here’s the Proof.
-David Linthicum, Infoworld
If your existing team decides to pull this off on their own, your organization is taking a very big risk. It means you are trying something new, building an environment that must support your entire organization – while ensuring there is no data loss, you can recover from disasters, the systems perform optimally, and everything is secure. This is no small task. Without taking work off your team’s plate, you can easily overload the organization to a staggering degree.
Now the existing infrastructure team is burdened with a huge effort that is beyond their capacity and in many ways beyond their existing capabilities. For the migration and stabilization of legacy systems, it requires that you maintain people and resources in both environments for an extended period of time. These same operations resources are also needed to support the actual migration in addition to the support they must provide for the deployment of new applications being refactored in the cloud. This is clearly a herculean task in its scope!
Take this research conducted by Google and published in Forbes2 where the following quote can be found:
“Technical debt is both silent and far-reaching in its impact; in fact, the latest research conducted by Google found that respondents with high technical debt were 1.6 times less productive.”
“Silent and far-reaching in its impact” is the key phrase here. It would seem from the horrendous over-spend on cloud that almost everyone is reporting that there is a very real problem hidden in the under-belly of cloud adoption. Here is what this really means to your bottom line:
How many of us can afford to migrate traditional workloads to a hyperscale platform for the sake of experiencing an impact that is almost 40% of your infrastructure head count? Worse yet, what is the bottom-line impact on your business?
This approach to cloud adoption is like an interest-only loan and technical debt is the principal that never gets paid down. In truth, it is often even worse than that. The cost of managing resources is the beginning of the challenges faced when a technical approach to cloud – in other words, lift and shift – is used for the journey. What makes this complexity and overspend cut even deeper is the false expectation that a cloud migration will produce transformative business value.
Unfortunately, lift and shift does not target, nor does it produce transformative business value.
Stay tuned for the next post in this series, as we look at what is missing in the rush of today’s cloud euphoria. Feel free to reach out to me with questions, suggestions, or ideas, I can be reached at jim.gehring@expedient.com.
[1] Conservative estimate based on 2022 studies from Palo Alto and O’Reilly^
[2] Forbes: How IT Operations Can Dig Itself Out Of Technical Debt^
