What happens when you migrate to the cloud, then decide the cloud's just not working out? The answer is cloud repatriation, a strategy that has grown increasingly popular in recent years, with 80% of companies reporting plans to repatriate at least some of the workloads that they currently host in the public cloud.
At first glance, you might read statistics like these as evidence that there will be a massive shift back to on-premises architectures. Yet the reality is that cloud repatriation is more complex and nuanced. In many cases, it’s not about readopting the same on-premises configurations that companies were using prior to public cloud adoption; it’s more about taking advantage of new hybrid cloud opportunities or finding better ways to integrate on-premises workloads with public cloud services.
Here’s a look at what cloud repatriation means, why it has become a popular trend and how to craft the most effective cloud repatriation strategy--which typically requires more than just rebuilding the on-premises infrastructure you relied on before migrating to the cloud.
What Is Cloud Repatriation?
Put simply, cloud repatriation is the process of moving applications or data that currently run in the public cloud to an infrastructure other than the public cloud.
For example, you might have virtual machines hosted on a service like Amazon EC2 or Azure Virtual Machines that you migrate back to an on-premises data center. Or, you may replace a SaaS application running in the public cloud with one hosted on a private or hybrid cloud.
Organizations may opt for cloud repatriation for several reasons. They range from a determination that cloud costs turn out to be more expensive than anticipated to the realization that the cloud is not always ideal for certain needs (such as backup and recovery, where cloud-based backups may take longer to restore to an on-premises system than backups that are hosted locally).
How Repatriation Is Changing Cloud Computing
The simplistic assumption about cloud repatriation is that it means more organizations will shift back to an on-premises model, with cloud architectures becoming less important as a result.
But the reality is more complex. Although for some organizations cloud repatriation means simply converting workloads back to an on-premises model, for others it entails migrating to more sophisticated types of cloud-based architectures, not abandoning the cloud altogether.
For example, consider the following ways in which a cloud workload can be repatriated:
- A SaaS application that was previously hosted in a traditional public cloud is migrated to an edge computing model, in which the application itself remains in the public cloud but data processing takes place in on-premises servers to improve performance. In this case, only one facet of the workload is repatriated.
- A backup and recovery operation whose backup data storage once relied solely on the public cloud is expanded so that backups are retained both in the cloud and on-premises, to give the organization more options for recovery. In this example, cloud repatriation doesn’t even technically take place, although a workload that once ran only in the public cloud now consumes on-premises resources, as well.
- To meet compliance needs, a company takes advantage of a next-generation hybrid cloud framework, like Azure Stack or AWS Outposts, to move a workload that previously ran in the public cloud to on-premises servers. The workload continues to rely on public cloud services, but the hosting takes place on-premises, simplifying compliance challenges.
In these examples, cloud architectures end up being more complex than they were before cloud repatriation occurred. Architectures that once involved only the public cloud morph into hybrid or edge models.
Cloud Repatriation Best Practices
If you’re not happy with your public cloud strategy and are considering repatriating some of your workloads, here are some pointers to keep in mind:
- Repatriation is not a retreat: As noted above, cloud repatriation in many cases isn’t about going back to whatever architectural model you used before adopting the public cloud. Instead, it’s a way to improve performance, cost or other factors by adopting a more sophisticated architecture.
- Make sure you can handle the complexity: Because cloud repatriation tends to make architectures more complex by integrating public cloud and on-premises resources, it’s important to make sure the extra management burden is worth it. Is saving a little money on your storage or VM costs worth having to monitor cloud-based and on-premises components of a workload at the same time? Maybe, but assess these considerations before jumping on the repatriation bandwagon.
- Keep your workloads portable: You never know when you may need to shift your architecture yet again to meet a new goal or take advantage of a new opportunity. For that reason, strive to keep your workloads portable as you perform cloud repatriation, so that you can easily migrate again in the future if you choose.
- Think about the future of the public cloud: Before deciding to repatriate your workloads in a way that leads to more complexity, think hard about whether simply leaving them in the public cloud isn’t the best long-term strategy. A particularly important consideration here is that public cloud services have a history of becoming both cheaper and more functional over time. Thus, even if you decide the public cloud alone isn’t the ideal solution for a given workload today, it might become better in the future. You don’t want to go through the trouble of repatriatriation only to discover a year or two down the road that you would have been better off sticking with your original public cloud architecture.
Conclusion
As organizations reevaluate their cloud strategies, the repatriation of some resources is likely for most. But instead of thinking of cloud repatriation as merely a way to set back the clock to the pre-cloud age, approach it as an opportunity to build more powerful architectures--with the understanding, of course, that with added power comes additional complexity.
