Ask HN: Cloud to on-premise (reverse migration). Is it a thing?
9 comments
I just left a $45B company that has many of the same issues you mention. There were efforts around consolidating competing technologies and vendors as well as a very large "digital transformation" effort which I was directly a part of. None of the efforts went very well for a variety of reasons including reorgs, two competing technology organizations, hard economic times, etc. Another underlying issue I saw was lack of accountability and communication. "Technical debt factory" is a great way to phrase it.
Ultimately, leadership has to make tough decisions cut costs while not impacting the company's continued growth.
Ultimately, leadership has to make tough decisions cut costs while not impacting the company's continued growth.
If you aren't the CEO, or have a direct line of influence to him, this issue can't be resolved. Your company didn't technically solution itself into this problem, and it won't technically solution itself out of this problem.
It requires painful, swift decisions and a massive culture shift. I would bet you have a CIO(or similar title) who owns the legacy stuff and a CTO where shadow IT lives. One of those people needs to report to the other and if that is the case today, one needs to go (which is likely the case regardless).
It requires painful, swift decisions and a massive culture shift. I would bet you have a CIO(or similar title) who owns the legacy stuff and a CTO where shadow IT lives. One of those people needs to report to the other and if that is the case today, one needs to go (which is likely the case regardless).
Absolutely. And not even for hardware specifically -- with software, too. I've been seeing a big uptick in customers wanting to go from SaaS/cloud to self-hosted/on-prem options. This is actually the main reason I chose to open source my SaaS after 7 years [^0], to provide more ways to self-host it on-prem. There's a lot of other reasons in that blog post, such as the current market, but also touches on things like bus-factor, security, and compliance.
In the end, it kind of boils down to the big questions "what do you own?" and "what do you control?"
When the markets get choppy, people start asking questions that they otherwise wouldn't ask. There's a lot of choppiness right now, and businesses want to reduce risk. Actually owning and controlling hardware, and software, can reduce risk via less reliance on third-parties. But it can also reduce costs, like with 37 Signals [^1], which is yet another risk reduction.
Another question to ask (from a business perspective), in order to reframe your concerns, would be "where is our risk?"
Perhaps they're reducing risk by having one foot outside of the cloud.
[^0]: https://keygen.sh/blog/all-your-licensing-are-belong-to-you/
[^1]: https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47...
In the end, it kind of boils down to the big questions "what do you own?" and "what do you control?"
When the markets get choppy, people start asking questions that they otherwise wouldn't ask. There's a lot of choppiness right now, and businesses want to reduce risk. Actually owning and controlling hardware, and software, can reduce risk via less reliance on third-parties. But it can also reduce costs, like with 37 Signals [^1], which is yet another risk reduction.
Another question to ask (from a business perspective), in order to reframe your concerns, would be "where is our risk?"
Perhaps they're reducing risk by having one foot outside of the cloud.
[^0]: https://keygen.sh/blog/all-your-licensing-are-belong-to-you/
[^1]: https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47...
Have the on prem team start deploying some assets that can utilized by the cloud team via a familiar interface like terraform. (metal as a service, kubevirt, Vsphere, nebula, whatever)
Start small, pick one service at a time (compute this quarter, postgres next quarter, secrets management the next) and use the emerging platform to strangle out paid services
Cloud team gets to stay cloudy, on prem team still gets to farm servers
Start small, pick one service at a time (compute this quarter, postgres next quarter, secrets management the next) and use the emerging platform to strangle out paid services
Cloud team gets to stay cloudy, on prem team still gets to farm servers
The choice doesn't have to be solely on-prem OR cloud. We're seeing a hybrid approach often as a first step. More predictable, fixed workloads can move back on-prem for cost-efficiency, while keeping elastic workloads in the cloud for flexibility.
The key to success is having the right on-prem solution to help bring both teams together while driving costs down. Our solution at Triton Datacenter (https://tritondatacenter.com) has helped various enterprises tackle this issue by providing a public cloud-like experience on-prem.
The key to success is having the right on-prem solution to help bring both teams together while driving costs down. Our solution at Triton Datacenter (https://tritondatacenter.com) has helped various enterprises tackle this issue by providing a public cloud-like experience on-prem.
If your management has been letting that wasteful situation go on for a long time, there's not much you can do. It sounds like there's some dysfunction in management. I've seen that in many businesses. Unfortunately, the money they're wasting on maintaining two environments is probably preventing the company from moving forward in other ways.
That said, a number of companies have left the cloud for cost reasons. 37 Signals is a recent high-profile example: https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47...
I've read of others leaving for cost reasons as well. Many run niche workloads that don't make sense in the cloud. One company, if I recall correctly, was doing scientific processing that required massive, but not unlimited, CPU and GPU resources. They found it was cheaper to buy a bunch of high-end workstations and run their jobs locally. They didn't need the cloud's 24/7 uptime guarantees, because they were doing offline processing with no public-facing apps.
That said, a number of companies have left the cloud for cost reasons. 37 Signals is a recent high-profile example: https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47...
I've read of others leaving for cost reasons as well. Many run niche workloads that don't make sense in the cloud. One company, if I recall correctly, was doing scientific processing that required massive, but not unlimited, CPU and GPU resources. They found it was cheaper to buy a bunch of high-end workstations and run their jobs locally. They didn't need the cloud's 24/7 uptime guarantees, because they were doing offline processing with no public-facing apps.
Ahrefs saved $400M for not going to the cloud
https://tech.ahrefs.com/how-ahrefs-saved-us-400m-in-3-years-...
https://tech.ahrefs.com/how-ahrefs-saved-us-400m-in-3-years-...
I guess the AHrefs case us a bit special...
They need to run queries from their own IP address space and using IPs from a cloud provider would get them banned...
The other option is to get their public iP space and have it announced by a cloud provider. So, in top of the VM pricing, there is some cloud and network engineering to do.
IPs is only part of their issues.
BIGGER is that managing huge datasets are expensive.
BIGGER is that managing huge datasets are expensive.
Doing a quick search it seems a number of articles suggest reverse migration is a thing. While I understand why one might be motivated to migrate in either direction it's hard to get a read on whether reverse migration is an actual trend.
Asking for myself. We are an IoT company stuck doing "digital transformation" since at least 10 years. And now are in a place where we run 2 parallel environments.
Our on-prem world has old-school sysadmins patching servers and managing on-prem tools, Active diredctory, mailservers, etc catering for ~500 engineers. The other half uses a different reporting line and is also an org-within-the-org that is fully cloud-native: AWS, Datadog, Agile teams, DevOps, etc and modern'ish business processes.
Both groups are hostile to another. Probably because by instinct they understand they ultimately know only 1 can survive in the long run.
And while I don't judge either camp (the company could deliver with either method), the amount of money that gets burned by running a shadow-IT within the same org is staggering. Say you need to roll out some tools because of compliance you have 2 teams duplicating benchmarks etc. It's like a technical debt factory.
It seems the best way would be for management to consolidate one group, but they are technically too far removed from reality of engineering struggles. At the same time they do complain about the current difficult climate, have hiring freeze and travel constraints because of budget.
I understand that this isn't a technical issue which is why we have communicated using cost comparison and business language. But to no avail. It seems the only way for things to become better is to let them get worse first.
But maybe I've missed something. Any advise how this could be resolved is highly appreciated.