Repatriating cloud apps and data? Think it through
Repatriating cloud apps and data? Think it through
My January post on cloud repatriation seems to have struck some nerves. Indeed, I found the reactions a bit polarized when they should not have been. Cloud repatriation is about making unemotional decisions as to where to locate applications and data—a cost-benefit decision that comes down to simple math.
The question isn’t if cloud or traditional platforms are a good decision; it’s about making the best choice for a specific workload or data set. In many respects, we’re fixing mistakes made years ago as workloads and data sets were not evaluated properly, making the public cloud a questionable target in the first place.
Or perhaps the company didn’t invest in changing the application to be optimized for the cloud. Thus, you have an application that burns through many dollars on a public cloud when it is way cheaper to run on premises today.
However, all is not right in the world of repatriation. Today IT is making many common mistakes where repatriation does not work well or, more often, does not return the benefits that enterprise IT was expecting.
Let’s examine a few:
Not fully understanding the costs
One of the main reasons for repatriating workloads is to reduce costs, but it is essential to fully understand the expenses involved in managing on-premises infrastructure. Enterprises may underestimate the cost of purchasing and maintaining hardware, as well as hiring staff to manage the infrastructure and upgrade software and applications.
You would think these costs would be well understood by enterprise IT. In many cases, people are not correctly estimating the number, size, and cost of the hardware platforms that will be needed to support the workloads coming off the clouds. Moreover, some costs are often overlooked: humans, power, water, rent, taxes, etc. Many enterprises have not purchased hardware in a long time and are out of practice in understanding the true price tag.
Overlooking the benefits of the cloud
Although there may be valid reasons for repatriation, enterprises should not overlook the benefits of the cloud, such as scalability, flexibility, and access to the latest technology. After all, that’s where the investments and innovations are being made these days, at almost 10-to-1 in favor of cloud over traditional platforms.
You need to consider what you’re giving up to save in operational costs. This includes not having access to the best security systems, operations tools, and even more modern databases. Also, the “soft values” of agility and scaling are often lost when moving applications back in-house. You’re giving up push-button provisioning of any technology, at any time, for any reason. That’s a powerful benefit that you’ll likely be leaving behind. Worth it?
Not considering the impact on IT staff
Repatriating workloads may require additional IT staff to manage on-premises infrastructure, as we discussed above. Enterprises often grossly underestimate the skills and resources needed to manage the infrastructure, leading to increased costs and reduced productivity. In some cases, companies develop an unexpected morale problem.
Also, are there even people available who can be hired or trained to do the work? Many in IT have shifted their careers to cloud-based technologies and they may no longer exist in the numbers that you need in-house. Hiring contractors can be just as difficult, with some asking for highly inflated fees and salaries that you did not factor into the expense of repatriation.
The common theme is that not enough thought is going into many of these workloads that are looking to make the return trip back to on-premises systems. Although in many instances repatriation is a valid cost-saving approach that is well thought out and executed, still some enterprises are moving back to enterprise data centers to save money and end up spending more instead. Try explaining that one to your boss.