Eight reasons why enterprises move workloads from public cloud back on-premises

There is a lot of confusion and misinformation as to why enterprises would move an application or workload from public cloud back to their corporate data center. Enterprises are moving applications to…and from public cloud. Unlike the perception, repatriation is rarely done all-or-nothing as enterprises consider moves on an application by application basis

Here are the top eight reasons:

Culture Incompatibilities

One of the biggest issues with leveraging cloud is culture. That is, how the enterprise thinks about cloud-based resources. Many have slipped into this mode of thinking of cloud as ‘just another data center’. They often bring traditional thinking and methodologies to public cloud expecting something similar to their corporate data center.

However, that is gravely misleading and misses the opportunities that cloud really delivers. It also brings additional challenges to architecture, process, cybersecurity and many other aspects to running a stable environment. When these mismatches present themselves, enterprises are often looking at how to bring the application back to the corporate data center.

Mandate

A few years back, executive teams and even boards of directors were mandating that the company use a cloud-first methodology. I caution any governing board to dictate a specific technology. Much of this was done without the guidance of those that use and manage cloud. As such, enterprises were forcing themselves to move applications to the public cloud. Unfortunately, many of these applications, the organizations that supported them and the processes that surrounded them were ill-equipped for the move. Hence, many of these applications are now moving back on-premises.

Cloud-ready Workloads

There is a common narrative that public cloud is just someone else’s data center. Unfortunately, that meme stuck. Moving an application to cloud requires planning and a lot of forethought before actually making the move. Many of the workloads moving back on-premises were never designed or refactored for cloud. This led to performance and cost issues that are difficult or impossible to address in short order. The quickest solution for many of these applications is to repatriate them on-premises.

Sticker Shock

Another common misconception about cloud is that it is cheap. Cloud is not cheap. It is actually very expensive. The upside is that it provides significant opportunity that many struggle to justify using traditional approaches. A similar example is rental cars. Is renting a car cheap? Sure, if you only need it one day. But depending on your usage and the business value you get from that usage; the cloud bill can present sticker shock.

For another blog but be careful not to optimize to the cheapest approach here. Just because you spend $2m/year on public cloud services may not be a bad thing.

Technical Requirements

Some are finding that their applications were never designed for cloud and actually start to see latency issues once they move to cloud. This is likely due to a mismatch between application requirements and architecture. Corporate data centers leverage many, many assumptions that start to show up when an application is moved to cloud. It is best to think this through before making the move. The most common issue here is latency requirements.

Regulatory, Compliance and Privacy Requirements

It is easy to think about public cloud as just another data center. It especially becomes interesting when developers realize the value from containers and ephemeral services. The problem is that these architectures…and cloud in general presents additional complexity to regulatory, compliance and privacy requirements. Sure, it may be okay to use headless data in a dev/ test cloud environment. Production data is a whole different story. And as time goes on, these requirements will only get more complicated.

Business Requirements

There is a lot of belief that moving from a CapEx to OpEx model is advantageous as it provides flexibility. That is sort of true. However, that’s really dependent on the business’ financial structure. If you’re a utility, the ‘cost recovery model’ will favor CapEx models over OpEx. This conflicts with the cloud model. This is a good time to have a chat with your CFO and understand the business financial structure and why.

Scale and Architecture

While somewhat related to technical requirements, at a certain scale, an application makes more sense to run in a corporate data center than public cloud. The other reason that pushes these applications back to the data center is due to specific architectures. In the end, all public cloud providers provide a (relatively) generic set of resources. They have to be in order to address the needs to millions of customers. However, your specific application at scale may suffer from this general approach and need a more specific infrastructure that is specifically tuned for that specific application. While this is not common due to scale and performance, it does happen.

A nasty side effect to each of these is that they create a chilling effect and bad experience with using public cloud. That is unfortunate as all of these issues can be avoided with enough forethought and planning.

With each of these, it is not an all-or-nothing approach with public cloud or repatriation. Enterprises are indeed moving some applications back to corporate data centers from public cloud. However, that does not represent a mass exodus from public cloud nor a failure of the public cloud solutions.

For further reading:

Why are enterprises moving away from public cloud? (2017)

Is public cloud more or less expensive than corporate data center options? (2017)

Eight ways enterprises struggle with public cloud (2017)