IDG Contributor Network: Why we’re still talking about TCO, but for the cloud
In the late 1980s, Gartner popularized the term “total cost of ownership” (TCO) to define the long-term cost of maintenance in addition to the upfront price of an enterprise technology. Microsoft began using TCO as a key metric to show that although an open-source alternative, Linux, was free to adopt, it could lead to higher costs as more deeply skilled teams would need to manage and troubleshoot Linux over the long term.
Fast forward 30 years—our technology is more advanced and accessible, but TCO remains frustrating and unclear, even as software has largely moved from complex licenses to metered cloud services. The dollar amounts provided by mainstream cloud vendors for compute, storage, and other cloud-based services rarely provide customers with clarity about the full cost of running business applications in the cloud.
This is particularly true when considering migrating legacy applications to public clouds. What’s the TCO of a highly complex but still mission-critical application that runs on premises (with manual updates and maintenance), and how does that compare to its total cost running that application in a public cloud (including the costs to rebuild for cloud and migrate it there)? Here’s why it’s important to understand TCO in this scenario.
As cloud adoption enters its second decade, many organizations have stopped looking at their datacenter as the default and have instead adopted a cloud-first mentality. The problem is that no two applications are alike. While the first decade of cloud was driven by new application development in, for, and tailored to the cloud’s characteristics, customers are now trying to gain the same agility and scale benefits they’ve experienced with cloud-native applications for the legacy systems running their businesses. Unfortunately, many of these customers end up with unanticipated and massive bills for cloud migration, professional services, ongoing maintenance and unpredictable usage.
For example, I once worked with a major hotel chain that was going all in with a single cloud service. This migration effort included a complex, highly customized bookings and reservations application. After 18 months of engineering and nearly $10 million in professional services and consulting fees, the rewritten application still didn’t work in the chosen cloud service. The hotel was forced to start over with a different cloud and had nothing to show for the time or money spent.
Cloud TCO is particularly difficult to nail down when it comes to legacy applications that weren’t built for the cloud, applications that analysts estimate still represent the vast majority of enterprise workloads. Migrating systems of record comes with hard workforce costs that are detrimental to the bottom line:
- Datacenter costs: Until the migration is complete, you’re still in your datacenter. That means in addition to the people hours, service, and cloud resource costs of the migration, you also have the same power, maintenance, real estate, and other expenses related to your existing infrastructure.
- Labor: Someone has to do the migration. If you’re going to use existing headcount to rewrite and migrate an application or set of applications, you may double or triple their workload. If you’re going to bring in consultants and professional services, those contracts can rapidly escalate.
- Time lost: While you refactor or rewrite applications for migration, your team must still manage, maintain, and support your existing infrastructure and application stack. No efficiency is gained during the process and your team’s work potentially doubles with maintaining your existing system and working through the migration.
- Burnout: All the additional work can burn out your team, which can lead to poor performance, low morale, or even employee departures.
Think of migrating a traditional application to the cloud like renovating a decades-old home. Until your team “gets under the house” and fully understands all the old piping, electrical, structural design, and other components, it will be difficult to estimate costs or time required. Even then, unforeseen surprises or challenges are bound to arise, which can balloon costs and drag out the project.
What’s even more harrowing than the costs illustrated here is that while the migration work is in progress, there is no benefit. You’re simply maintaining the status quo and waiting for the project to deliver. Depending on the complexity of the application being migrated, this process can take months or years, time during which markets change, competitors emerge, and customer demand shifts.
The challenges with migrating legacy applications to the cloud, and the potentially massive costs associated with doing so, is why many organizations are adopting a multi-cloud approach. Doing so enables customers to address specific use cases and workloads, instead of trying to make their entire application portfolio fit a single service. In other words, use the right tool for the job, don’t just bang everything with a hammer. A study conducted by IDC in 2015 found that 86 percent of enterprises predicted they’d need a multicloud approach to support their solutions in the following two years. Now, that time has come, and today’s businesses want the best possible infrastructure, services, and platforms for their needs.
Assessing your applications’ workload requirements is the critical first step in gaining control over cloud TCO. Set aside category conversations about hybrid versus public versus private. Tune out vendor hype or pressure to standardize on a single solution. You know your applications and your team best. Only you truly understand what your business needs. Establish and communicate these priorities with clarity and conviction. From there, begin to assess cloud services for three characteristics:
- Predictability: How will the service handle your unique workload demands? What upfront migration costs exist and how well can you estimate future billing?
- Flexibility: Can the cloud service adjust to unique application dependencies, or is it one-size-fits-all? Are there multiple services available you can combine to best support your applications?
- Control: How much visibility do you have into usage? Do you have full transparency and granular control over use? Can you quickly react to user data to adjust spend accordingly?
The bottom line for cloud TCO is that it’s not about cloud at all. It’s about your business and the applications your business depends on to stay competitive. It’s about starting with what you know—workload demands and business objectives—then investigating multiple cloud services to find the best approach for your needs. The best solution will be one that meets you where you are today and takes you where you need to be tomorrow, not one that forces you to change overnight. Be willing to use a multicloud approach that gives you predictability, flexibility, and control across your entire application portfolio. The process will take time and won’t always be straightforward, but by committing to your business needs first, you’ll be in the best position to understand, control, and minimize cloud TCO over the long term.
This article is published as part of the IDG Contributor Network. Want to Join?
Source: InfoWorld – Cloud Computing
Recent Comments