It’s not in retail, it’s in cloud.
I used to do AWS integration at my old job, mostly by stealth; our developers liked AWS, so they’d use our self-service form to provision themselves EC2 instances. By the time anyone else in the infrastructure and operations teams noticed what we were doing, we were already running 10% of our organisation’s entire server fleet in AWS, with 15% month-on-month growth, essentially supported by one single guy. We bought a DirectConnect link to our local AWS datacenter, and extended our internal domains to include AWS resources. Essentially, we treated AWS as a third datacenter (we already ran two ourselves). The only differences customers ever noticed between their EC2 instances and on-prem virtuals was that the EC2 stuff was deployed faster and never had any outages.1
We had a lot of on-prem outages. A lot. Networking shit, mostly, followed by endless bullshit hardware problems.
I worked a tech job but it wasn’t in a tech business, and the reality when you’re running tech for a non-tech company is that the business justifications for on-prem is thin at best. Really, the only reasons people have historically done it is that it’s been hard to get flexible datacenter-as-a-service offerings that scale to levels appropriate for enterprise. The word “historically” is in there for a reason; the cloud has caught up, and now large organisations (always slow to change) are following. AWS is really the only game in town, with Microsoft Azure playing catch-up. Everyone else is an also-ran.
- I should point out that this is pretty impressive, given cloud-native paradigms about infrastructure objects as disposable. Tl;dr, but if your physical server breaks, you’re supposed to fix it. If your cloud server breaks, you delete it and redeploy. Our organisation still operated very much in the former model, and even though AWS operated largely in the latter, their infrastructure was still more stable–and permanent–than ours was. Go figure.↩