I'm not surprised at all: that's thanks to the beauty of lock-in effects. Especially all those cloud-specific managed services make it really hard to switch, and even if you are treating the cloud as a pure VM platform, it is considerable work and risk to switch to a self-managed bare metal setup.

Basically, if you don't start bare-metal (incurring having to assemble the necessary know-how to do so) you will have a hard time to get clean from the cloud drug later on, when you think you're ready to afford having the know-how. I think this aspect has been a main driver behind the linked article.

S3 costs pretty much what that infrastructure costs to run yourself.

But certainly, go ahead and run a Riak CS cluster (plus those other things) on top of some Herzberg servers, and try to outcompete S3 on price. I—and many others—will be waiting. :)

And that's ignoring the Glacier storage class (which probably didn't show up on that historical graph), which is a fifth of that.

And Glacier Deep Archive is a further fourth of that.

The latter number can be pricey. But, irrelevant with respect to the failing costs of hard drives.

You may be interested in the 'rclone' tool which does all of these things, and more, with all of the cloud providers:

https://rclone.org/

https://rclone.org/commands/rclone_mount/

$12 million/year for cloud seems like a high enough threshold to go internal but I'm not even sure that's enough money to sway executives away from cloud.

The main issue is that internal IT departments at corporations have slow service from the IT staff compared to AWS/GCP/Azure and its engineers. Corporate IT departments typically don't treat their coworkers in other departments as internal customers. Instead, they treat them as adversaries and a nuisance.

That's why at non-tech corporations, the first group that experimented with the new AWS cloud service were the development teams. They got fed up with IT service backlogs waiting for new dev/sandbox/text servers. They got tired of waiting for IT to requisition a server and then install the os, db, etc. If the programming manager then asked IT to install an Oracle update, the IT department might say "well, Susan our db admin is on vacation till next Monday so we'll get to it then." Those kinds of inter-department interactions were frustrating to the internal customers of the IT department. With AWS, the programmers got their sandbox servers in spun up minutes instead of weeks or months. Once the dev teams were sold, the more risk-averse and mission-critical production workloads eventually moved to AWS too.

The author of this article doesn't seem to understand the dysfunctional relationship between internal IT and their coworkers they serve. It's more about responsiveness and iteration speed of the AWS/GCP/Azure employees' vs the IT employees than expensive AWS EC2 compute power vs cheaper internal racks of cpu.

E.g. The Guardian pays AWS more for cpu+diskspace+network than what they can build on their own. That's the raw hardware costs. But it doesn't matter because Guardian's internal IT staff with an internal cloud stack just can't match AWS: https://www.computerworld.com/article/3427004/the-guardian-g...

To me, it totally makes sense for Dropbox to migrate off of AWS to save money. They're a tech company and have the engineering culture to do it. A lot of non-tech companies (like The Guardian) don't.

That's how it starts but not how it ends.

Once you move everything to the cloud, the same IT staff get put in charge of it. Because they have a requirement from somewhere up high to make sure everything has antivirus on it, and there is a Windows domain for the desktops so the servers need to be in it too, and they want to have a test environment with specific versions of specific software matching the ones in production which means you have to use the corporate VM images instead of the AWS ones and have IT go through their VM provisioning checklist for each new instance, etc.

And some of those reasons are bad and some of them aren't, but either way they exist, so if you want to provision something from AWS now it has to go through IT who takes just as long as they ever did to do what amounts to the same thing as before only now it's more expensive.

Even pre-virtualization, I could instantiate servers very rapidly with network based imaging. With pre-staged templates of various os/program combinations. Applied them to both lab and production deployment. So that Dev, QA, and Prod could all work from the same base images. With versioning of the images based on patch level.

Then I would subsequently get blamed for every program error by the dev team. With no other justification than "it worked in the lab. Fix your server!" Running a packet analyzer, I would often find things like queries trying to go to a lab db server rather than prod. Or a dependency on an out of date/unpatched/vulnerable version of some supporting software that the development team would then attempt to pressure into production rather than update their code.

For every obstinate sysadmin you've encountered, there is an ops pro who has received a ticket with nothing but a list of compiler errors combined with 'pls fix asap'.

One deep problem with the "internal customer" model is that you don't get a larger budget when you serve your "internal customers" better.

But people are REALLY REALLY expensive (not only the ongoing costs, but hiring, firing and overhead), and Cloud has another huge advantage: accounting tricks (which help a lot to said midsize firms).

Literally one of the first things they teach you at the Azure training is the difference between CapEx and OpEx: https://docs.microsoft.com/en-us/learn/paths/azure-fundament...