Cloud repatriation appears to be one of the new IT hot topics of 2023. For companies that invested time and money into transferring some of their workloads to the cloud, why would it now make sense to bring some of them back to on-premises resources?
Well, I’ll explain in this article why cloud repatriation is being part of more and more IT-related conversations this year, what the concerns are for customers, and how recent news might cause Microsoft Azure to lose customers.
Watch out: 2023 is another one of those “year of …” years. I’m still waiting on my Linux desktop hosted on a Citrix server (and my jetpack, hovercraft, and flying car), but one of those “year of …” articles caught my interest in early January.
I was sitting in a meeting room, waiting to start a few days of strategizing about business strategy with colleagues, and I started browsing the news. One article on InfoWorld, 2023 Could Be The Year Of Cloud Repatriation caught my attention and had me thinking “what the heck is cloud repatriation?”
I wrongly assumed, at first, that it was about moving services and data to a more local instance of the cloud. I started to read and the sub-heading wrapped up the article nicely:
With cloud costs and complexity higher than expected, many enterprises are making a U-turn and putting applications and data back in traditional systems.
InfoWorld – 2023 Could Be The Year Of Public Cloud Repatriation
To explain what cloud repatriation is in clear terms, it’s when an organization decides to leave a public cloud, such as AWS or Microsoft Azure, and bring things back to on-premises.
One of my talking points for 2022 (and 2023) is that organizations have not used a good process to get into the cloud. The “field of dreams” approach is commonly used: a consulting company is hired to build out Azure, the consultants hand the result over to the customer in a series of short workshops, and success will come.
Spoiler alert: it does not. I explained why in my previous 5 Essentials for Successful Cloud Adoption article.
In practice, organizations often undergo complexity shock. Something big and very different is dropped on their heads. A developer might next-next-next their way through an Azure Kubernetes Services deployment and discover that this thing is way more complicated than installing IIS on Windows Server.
In another case, someone might want to secure a web application with a database and find that a private endpoint won’t work (they forgot that DNS is still important in the cloud). As for routing, well, Azure’s version of shutter speed/aperture/ISO (photography terminology) controls all aspects of Azure networking and network security in ways that you must be able to figure out with almost no tooling and rarely available diagnostics data.
All in all, new skills are required within an organization, and this takes some time. I have over 25 years of experience working in IT and I forget how long I’ve been working with Microsoft Azure (you can probably date it by when I started to write about Azure instead of Hyper-V here on Petri.com).
Anyway, even with all that experience, I just know a small percentage of everything Azure-related. I know some stuff, like Azure networking, really well, but I still find new things out in areas that I commonly work with every now and then.
In the end, I can imagine how a cloud newbie might find Azure huge, confusing, and daunting. And that’s before we drop GitHub/DevOps and some infrastructure-as-code language on their head.
The fears and doubts that an organization has before migrating to the cloud change after the migration is completed. One of the top worries is cost management.
I worked with a client, let’s call them XYZ, for much of 2022, helping them move some of their services to Microsoft Azure. Every time we stood up a new resource, the CTO asked questions about costs. We followed good practices for setting up workloads in Microsoft Azure:
But even then, the big topic every week was the cost of using cloud services. The cost of cloud platforms like Azure is very different from traditional IT environments.
A traditional IT environment is predictable capital expenditure (or CAPEX): Once the hardware and software are bought, there are no more accounting actions other than depreciation until the next purchasing cycle begins several years later.
A cloud computing platform like Azure is a consumption-based operational expenditure (or OPEX): You use something and a cost is accrued. That cost is paid for every month. Those costs can be quite complicated:
Microsoft has never been good at simplifying or explaining these sorts of things. There are tools in Azure to help with this, though implementing governance to control costs is new and alien to most organizations.
Microsoft published a lovely-titled press release last month. The headline, Consistent global pricing for the Microsoft Cloud, makes it sound like an Azure customer is about to read something good.
Instead, they found out that prices would be increasing for European countries with the following currencies:
Woohoo! Prices are becoming more consistent by… going up? That’s not good at all! I feel robbed by that heading.
Imagine this perfect storm:
I can imagine the CTO of my previously mentioned customer, XYZ, seeing this news and asking “how do we get out of Azure?” and I doubt that they will be alone. If an organization is struggling to get value from the cloud and the costs are increased, then questions about reversing course must be expected.
I know that some dingbats will raise the topic of Azure being less stable than on-premises resources. We had a recent outage where the global WAN of Azure went down for a couple of hours. Surely that will push people over the edge?
Cloud outages happen. So do on-premises outages. The difference is that companies like Microsoft pay a lot of money to have really good people fix the issues when they eventually happen. Microsoft is better prepared to fix those issues than you or I are.
Yes, I know that the Southeast Asia region just suffered an approximately 12-hour outage because of a large-scale cooling issue. However, how long would it take you to fix that in your computer room or data center? And shouldn’t cloud workloads be architected to be fault tolerant across availability zones (data centers in the same region) and regions to survive such localized issues?
Let’s not forget that the people who wrote the software are running the software. I’d rather trust the authors of Microsoft Exchange to fix my Office 365 issues instead of me rebooting an Exchange server and hoping for the best (that was how I sold an Office 365 migration to a previous employer).
The team that I work in features a few people in their 40s, but everyone else is in their 20s or early 30s. Guess which ones have experience working with server operating systems, virtualization, and server/storage hardware? And guess which ones do not?
Finding someone who has on-premises skills and is still working/alive is getting harder every year. Young adults are leaving college armed only with knowledge of the cloud. And they are landing in jobs that only give them experience with working with cloud services.
If a CTO announces “we’re moving back to on-premises,” then they may see two things happen:
Maybe you can train younger staff members on Windows Server? When is the last time you heard of a Windows Server 2022 training course from Microsoft? Exactly…
A perfect storm of economic conditions, customer struggles, and price increases might just cause cloud repatriation to become a real trend. My gut is telling me that this might just be another one of those “year of …” things, but my head says the conditions might just be right.
If I was a gambler, I’d probably bet that there will be lots of op-ed headlines (like this article) and some reports about organizations leaving the cloud. However, I think growth (which is slowing as should be expected) will continue thanks to new customers and increasing adoption with existing customers. Anyway, I hope that I’m right because my on-premises skills are super rusty.