Every so often, we see a blog post surface proclaiming that “cloud repatriation” or “moving workloads out of public clouds and back into data centers”is a trend that’s poised to take off.
The idea’s compelling; there absolutely are workloads that aren’t economically viable in the public cloud, and it sparks a ray of hope for vendors who are clearly on their way out in a world that’s embracing that public cloud.
The only slight problem is that I can’t find any evidence that cloud repatriation is a thing that companies are actually doing. For some reason, “going to the trouble of migrating a workload out of your data center into the public cloud, then laughing about it as you chalk the whole endeavor up to a funny misunderstanding” isn’t a thing that companies are doing at scale. Who knew? But let’s dig into this a bit.
Who’s talking about cloud repatriation?
So far, there seem to be two major constituencies who are excited about the concept.
Far and away the folks who seem the most enthusiastic about cloud repatriation are vendors who stand to gain a heck of a lot if people start turning their backs on public cloud. This includes data center providers, storage companies, and a host of companies that were asleep at the wheel for the past decade and are desperately hoping the slimming of their revenue streams is the result of a pitched fever dream from which they will soon awaken to find all of their previous business safely ensconced within their data centers once again.
The second constituency is analyst firms that cater to those vendors. I mean, I’m a consultant; I get it. It’s easy to become ensnared in ensuring that the overall theme of what you tell your customers is “you’re closer than ever!” It sounds uplifting, overwhelmingly positive, and doesn’t actually say anything at all. “You’re drowning in the sewer” as a messaging tone doesn’t really compel customers to remain your customers.
(Note to Oracle: “You’re drowning in the sewer” while your foot is atop the customer’s head is even less compelling.)
What about Dropbox?
The poster child for cloud repatriation (followed IMMEDIATELY by “please, whatever you do, do NOT ask us for a second example because we’re fresh out”) is Dropbox. Their S-1 filing claimed they’d reduced operating costs by $74.6 million over the two years following their going public.
Far be it from me to question the wisdom of a success story like Dropbox and their cloud migration strategy–but I will call out a few salient points:
This is around one very large, very expensive, very well understood workload: storing files that users upload via their desktop client. They’re still using AWS for most other things. You are probably not Dropbox. You probably do not have a giant scaled-out workload that’s very well-bounded and understood. One of the problems with a cloud repatriation exercise is that it steals focus from other projects you could be working on instead. In Dropbox’s case, this was a blessing; along with their godawful logo redesign, it kept their godawful resource glutton of a new desktop application from seeing the light of day a year or two sooner.
Remember, Dropbox is a shared folder that syncs everywhere. Nothing gold can stay; now it tries to do backups, collaborative document editing, a Slack replacement, etc. But their cloud repatriation boondoggle spared us all from that grim future for at least a good 18 months.
Now, Dropbox is of course the poster child for cloud repatriation stories. But there’s a far better one that few people talk about.
Remember Zynga?
Once upon a time, Farmville was a huge thing on the Facebooks. I couldn’t say whether it still is; I became a much happier person after I stopped visiting that trash site. But Farmville was huge and run by a company called Zynga.
One day, Zynga decided to move its architecture out of AWS and back to their on-premises data center buildout. The story is fascinating, and no–that link isn’t a mistake. If you click it, you’ll see that I am indeed pointing to an AWS-hosted customer case study about Zynga. That should give you a glimpse of where this story is going.
At a high level, “AWS is expensive, we’ll do it ourselves in our data centers instead! Okay, done! Holy crap, things are oh so very much worse, so we’re moving BACK TO AWS” is one hell of a case study.
It’s also a tale that’s conspicuously absent from most explorations of cloud repatriation–because once again, cloud repatriation that works isn’t a real thing.
Hybrid isn’t cloud repatriation
Now, before I get angry emails, let me clarify a few things.
I know I talk a lot about multi-cloud not being a real thing, but that’s not the same thing as hybrid. There are, in fact, some workloads that make no sense in the public cloud that should remain on-premises, even as your other workloads migrate to public cloud.
I spoke to a finance firm that had a bunch of HPC work a year or so ago. They were at capacity in an existing data center and were trying to figure out whether building a second data center or moving to the public cloud was economically superior.
I ran the numbers for them and concluded that the best path was indeed to build another data center. The economics weren’t even close! They knew their workload, their aggressive hardware refresh cycle had predictable economics, and their workloads were steady state with high fleet-wide utilization.
The only way that AWS (the cloud under discussion) would have made sense for their use case would have been to use Spot fleets for everything. But the way their software was architected, there wasn’t an ability to checkpoint the workload; if an instance was interrupted during its task, it couldn’t rejoin the fleet that was chewing on that workload later. (Yes, this was a problem. The real world is messy, regardless of the lies your cloud provider told you.)
Even that was a problem: The Spot economics were too variable to make choosing AWS a slam dunk for their predictive modeling. “Whoops, we didn’t save money at all” wasn’t a viable outcome for what was, as mentioned, a finance firm.
This isn’t a cloud repatriation story because the company did its diligence first. They reached out to folks like me who knew what they were talking about and ran the numbers before hurling ungodly piles of money into a failed experiment.
I’m not saying that everything belongs in the public cloud–”far from it. My point is that there are workloads that clearly don’t belong in the public cloud.
But aside from colossal blunders, they never make it there in the first place–much to the chagrin, I suppose, of the stakeholders so desperately trying to make cloud repatriation a thing.
