Cloud Repatriation Options – On-Premise vs Colocation vs Hosted Private Cloud

More and more companies are facing the reality of high costs coming from their public cloud deployments on AWS, Azure, GCP and the other mega clouds. This has given rise to the concept of Cloud Repatriation.

As a cloud provider that merges public and private cloud benefits – i.e., private cloud at the speed of public cloud and with dynamic scaling – we are finding ourselves able to help customers that need to be cloud native but cannot realistically take an on-premise path and do not want to take a colocation path.

In this article I cover how companies can use OpenMetal to match what on-premise and colocation can provide but with a cloud native first attitude that matches efficient IT approaches.

Cloud Repatriation vs Workload Repatriation

First, getting caught in a formal definition of Cloud Repatriation is something we advise against. In reality, utilizing cloud native approaches is the efficient future for IT. Deciding where your workloads run is independent of being cloud native. For a longer treatment of this read more at our article that can help you decide if Cloud Repatriation is a misnomer for you.

With that out of the way, let’s focus on workloads that you are running on big public clouds and strategies we are seeing on how to get off the big bills.

Repatriation Phase 1 – Portable Systems

Identify your portable systems. Development related systems are very good candidates. Much of these workloads are not efficient in public clouds for the following reasons:

• Development is not running all the time but to get low cost resources from public clouds you often must commit to them running all the time.
• Designing a pipeline to use completely ephemeral short term Compute is actually quite hard and can slow down your Dev processes. Teams tend to not actually do this which is required to leverage ephemeral cost benefits. Ephemeral cost benefits for when considering cloud repatriation is the practice of spinning up Compute only when you need it and then destroying it right after. Costs, though high per minute, are ultimately low since you might only use it for 60 minutes out of a day. If your system is mature, i.e., actually works like this without accidental overruns, public cloud is a solid economical choice.
• Development environments don’t need production resiliency and uptime. Systems that provide 99.98% uptime are considerably less expensive than 99.998%. An easy example is you can choose triplicate redundancy or duplicate redundancy for your storage in a private cloud. Duplicate costs 50% less than triplicate and matches the majority of customer’s needs for Dev workloads. 

Other portable systems we have seen in the past:

• Back office
• Engineering and math modeling
• Customers that have low cost needs that allow tolerance in SLAs

Repatriation Phase 2 – Expensive Systems

This is the bigger and longer of the set of workloads you will repatriate from your public cloud. Here are a few key ways to look at what should move from the expensive cloud first to your hosted private cloud with us.

• When do your agreements sunset? You have some options to resell your agreements on an aftermarket, but you will lose a significant percentage when you do that. It may be worth it, but if you have other agreements already sunsetting those workloads might be enough work already for your team to move during this project.
• Egress bandwidth workloads. If part of your business is generating significant costs from egress bandwidth – the per GB transfer fees you see in your public cloud bill – those workloads are great targets for cloud repatriation. Costs of bandwidth when on-premise, in colocation space in a data center, or on hosted private cloud are significantly less than the public cloud charges.
• Steady state workloads. These workloads are not swinging up and down a lot from a utilization standpoint. Public cloud has a built in assumption you will need to scale up and down. The systems have been built with that in mind and they charge as if you will need to do that at anytime, instantly. It just isn’t the case for most workloads and you can trust the historical data that you have for your workloads. When repatriating off public cloud you will gain cost savings because you are going to trust your historical performance. For on-prem and colo, it can mean you should build in a bit of spare resources but trust your math. For hosted private cloud with OpenMetal, we support scaling easily and dynamically, but it is not built into the cost. Essentially you have your current cloud’s capacity to instantly scale on like any other cloud – but if you are at the edge of the cloud’s capacity you need to scale the cloud itself first. It will take an hour or so for new hardware units to be ingested into your cloud and usable for VM provisioning.
• Any workload that comes up to the top of the bill! Often this is very large VMs – think 128GB RAM, 64 vCPUs – or workloads that have lots of medium sized VMs (16GB RAM, 8 vCPUs). Workloads that are using very small VMs or containers actually may fit better inside of automated bare metal. This we often see with customers. At OpenMetal we make bare metal highly automated so that it functions like using VMs. We are still working on those systems but expect by the end of 2023 to have bare metal work almost identical to how VMs work for provisioning and networking ease.

Repatriation to On-Premise vs Hosted Private Cloud

The challenge of on-premise is several fold. We have customers that run on-premise, with us, and on the mega public clouds. I will put this in a table when I have a chance, but for now, the situations and why an OpenMetal private cloud turned out to fit the bill best.

• On-premise hardware access challenges. For 2021 through now (2023) there have been many hardware supply issues. Even as a large purchaser of hardware, OpenMetal has struggles getting servers. Often small parts hold up builds and large common parts like the CPUs or drives got very expensive due to the limited supply. Companies running on-prem typically did not have the purchasing power to get hardware. Customers that were already familiar with running on-prem, even running a similar cloud using OpenStack and Ceph – could not get hardware to meet customer demands. We could so we were able to meet their deadlines for customers. See the hardware stock.
• When a company gives up their on-premise data center to move to the cloud they also often give up the technical know how and hardware expertise to do on-prem. On-premise infrastructure and/or cloud requires certain scale in people, servers, and physical data center space/parts. When certain scale is met and the processes are mature, on-prem will beat out the public cloud, hands down.  Hosted private cloud will typically pencil to be almost the same TCO as a mature at scale on premise solution. It does this while also bringing the attributes most companies want. Risk free deployments, right now, and the ability to choose managed private cloud or to run the private cloud, at the root level, themselves to fully maximize their cloud repatriation cost benefits.  Check out our Cloud Cost Calculator for more details.
• On-premise typically also requires a DR solution that is remote from the on-premise. This is the same regardless of if you select public cloud, on-prem, hosted private cloud, or colocation. We typically recommend you choose from a new generation of DR systems that only require you to have the data ready in a public cloud so that in an event of a full failure, the necessary compute can be spun up on top of the nearby data. In this case, there is no repatriation of this workload – the public cloud works well for this.