I wonder how much the BOFH charges to co-loc/on-prem the installation from the BOFH cloud datacenter to the BOFH co-loc/on-prem datacenter.

Where are your cost alerts and someone to police cloud usage? I'm a firm believer in "horses for courses", you choose cloud, hybrid or onprem, but if you open cloud accounts to one and all then it's just giving an unlimited company credit card to all employees, don't complain when someone does something stupid with it!

We have sandboxes for our devs, max spend limits, we track costs and usage every 15-20 mins, we even restrict VM usage to max 2 CPUs and 16GB memory, max 2 machines per person. We don't allow databases, we dont' allow unlimited storage. Only about 6 people in the whole company are allowed into the test and prod cloud accounts out of 700 employees. We have hourly checks for costs exceeded, daily round ups, name and shame on spending, you spin it up and you're name will be on display for all to see so choose wisely.

Only 40 people in the company get a company credit card, like wise we don't let everyone in IT play in the cloud toybox!

It sounds like hell. Have you considered not having computers at all? Going back to pen and paper?

The problem for SMEs is that the cloud discounts are what makes cloud affordable for standard operations. Only the big players get the big discounts. Everyone else spends their lives chasing random cost instead of making new things (or fixing existing things). My own small cloud application (a few hundred TPS) costs next to nothing to run on GCP native services, mainly because it is part of a large GKE cluster and there are swinging discounts. If you're not operating at scale and you just lifted and shifted, you're almost certainly not going to get cost benefits.

Just moved a small low usage application off AWS to an independent, the typical £500~600.pcm AWS cost has been replaced by a flat rate £200 pcm.

Additional, support and maintenance savings will accrue as the migration took it off AWS services and onto our own LAMP platform (MariaDB instead of MySQL), which we can better manage the patch and version upgrades.

Businesses that run large, relatively stable, predictable workloads are likely to save money on-prem, long-term.

But they do sacrifice a degree of agility. If their customer base was to triple over the next three weeks, could they source, configure, and install enough hardware to cope with the additional load? Unlikely.

If they wanted to develop a new product with as yet unknown resource requirements, would they have enough spare capacity to do that, without affecting their production workloads, and without having to down tools to wait for new hardware to arrive? Because I've experienced this exact situation when relying on on-prem tin.

37Signals is literally at one end of the spectrum. The counter-argument at the other end of the spectrum is the UK charity Comic Relief, who provisioned serverless infrastructure that facilitated the processing of tens of millions of pounds in donations from hundreds of thousands of members of the public, for less than £100; their previous on-prem solution was IIRC 1000x more expensive, and sat doing nothing for the vast majority of the year.

Everyone else is somewhere in the middle. You don't have to run all of your workloads in the cloud; you don't have to run them all on-prem. There is a middle ground, but anti-cloud zealots like DHH seem to forget this and present their own experience as "look, this is true for us so cloud sucks".

It should be a pretty well paid job to be an anti-cloud zealot like DHH if the savings can be that big.

"But they do sacrifice a degree of agility. If their customer base was to triple over the next three weeks, could they source, configure, and install enough hardware to cope with the additional load?

...

Comic Relief, who provisioned serverless infrastructure that facilitated the processing of tens of millions of pounds in donations from hundreds of thousands of members of the public, for less than £100"

Comic Relief hold an annual events on dates decided well in advance. If they depend on agility to plan for that they're doing it wrong.

I have, in the past, worked with marketing who probably did hope for something like a tripling of turnover in three weeks. Having failed to work out that their campaign had a small flaw they were disappointed. (It was intended to let them sell direct instead of through distributors; the customers needed to arrange an installion, however, and the installers were also the distributors.)

> 37Signals is literally at one end of the spectrum. The counter-argument at the other end of the spectrum is the UK charity Comic Relief

Odd spectrum, I suspect if you ignore the annual telethon, their normal day-to-day operations load is boring and predictable. Thus, just like 37signals there will be few benefits from running this load in the cloud, although with charity pricing, I expect they will be a big user of 365 and cloud-based application as a service systems for accounting, customer relationship etc.

Also I suspect the annual telethon is such that they can get their cloud provider to donate the costs…

Remember that cloud computing is a for profit business, and they certainly won't settle for making 10 cents per dollar.

The "cloud" is just using someone else's hardware. There really is no benefit for an organization with a functioning brain cell in management to go cloud.

But functioning brain cells is a big ask for most corporate management...

Depends on how bursty or stable the load is.

Also depends on access (and budget) to the necessary skilled employees.

For most organisations with some critical mass (and a baseline workload), cloud is going to be more expensive for that element of what they do, but for smaller organisations, who can't fill a modern server, cloud likely is a good shout.

For bursty or massive spike workloads, cloud can be a great fit for elastic capacity on a temporary basis, but the MO needs to be "kick the arse out of it, then get back home" as soon as the workload drops.

To my mind, sizing on prem for the "once in a year" workload if you're Wimbledon, or putting all workloads in the cloud just because you're planning to run a big marketing campaign once a quarter, are equally bad approaches.

My current employer have been doing a costing exercise to see if on prem could save us money versus our AWS setup. We don't have "bursty" activity, just a steady steam of data processing and web traffic, so estimating the hardware requirements is straightforward. It also helps that every AWS feature we use can be replaced with an on prem equivalent - PostgreSQL, OpenSearch, Redis and storage to replace S3 essentially. Had we bought into the serverless snake oil like Lambda or other dubious AWS features I'm not sure we'd be considering a transition.

You make an excellent point, which I'm always surprised people miss - don't get locked in.

You'd have thought that IT had enough examples of people having buyers' remorse about lock-in being painful/expensive ***cough, ORACLE, cough***, that we'd have learned to stop doing that, but far too many people don't appear to pay enough attention to history and therefore are happy to take the short term easy option and suck it up/regret at their leisure when they're bent over by the vendor.

Pink fluffy handcuffs are still handcuffs......

IT people have experienced those examples. You can recognise them. They're the ones burying their heads in their hands when the decision makers meet the salesmen.

What always surprises me is that the manglement are so often snake -oil merchants themselves so why can't they recognise the same thing when they see it?

...the value of somebody else handling the operational complexity.

Take S3, he says they want to do this themselves? I'll assume he's not actually talking about multi-regional - even maybe multi-zonal S3?

So let's say you do this only in one location... do you use a SAN? Probably not because then you have another expensive vendor contract you didn't want.

So lets implement it as a service on utilising storage across your on-premise servers - I take it you've got all the servers RAID configured properly and monitored - or are you replicating across multiple machines instead?

Either way hardware fails, so you've got your on-call processes sorted, you've got your contracts with your hardware suppliers locked down because you know you'll be replacing failing disks with some kind of regularity.

You've either trained the datacenter staff or you have staff present near your datacenter location, and their access sorted to be able to go in and replace those failing disks.

Depending on how much you're leaning on the on-premise provider (in which case how much money are you really saving?) you need an entire ops team likely with a different skillset from your existing cloudops team.

"I'll assume he's not actually talking about multi-regional - even maybe multi-zonal S3?"

You can assume what you like, but considering his company provides SaaS apps as their product, and they tend not to work well when the infrastructure is down, I think the implied assumption he's going single site is bat-shit crazy.

He does actually cover lots of the concerns you raise in his article, and some others in the comments to his LinkedIn post.

They are still saving millions per year after paying for smart hands, architecting for in-site / cross-site redundancy and full support from vendors like Dell and Pure (so likely no disks to change - it will all be solid state, so most likely not failing with "some kind of regularity").

Finally, they didn't change the number of people supporting the infrastructure - so they're either super human, or the state of managing infrastructure has improved since you last did it.

Your "let's say" thought experiment is amusing, but I'm paying more attention to the guy who is already doing it for real and whose company is pocketing seven figures of savings per year (even before he does the same on the S3).

"somebody else handling the operational complexity"

That's the dream, isn't it? No complexity anywhere, or as Hans says in _Die Hard_: "We'll be sitting on the beach, earning 20%." And as everybody knows, there are no mosquitos in paradise. Whereas in the real world, managing suppliers is just as much work as managing employees. The complexity moves around, but it doesn't go away. This must be true, because if it were possible to outsource all the complexity, then anybody could be in the same business as you. Er, wait, that's what MBAs think already. Never mind, puts hand down.