[danpalmer]

That depends on how much saturation you can get. Most end users/companies can’t saturate this reliably, or have much spoiler traffic. Only the biggest players can minimise their seasonality enough to get close to this, and doing that is a service that it’s probably worth paying for.

[mlyle]

Who cares if you can saturate it? Breakeven is 18 terabytes/month, or 0.6% utilization on that line.

You could do this even just pegging the line 9 minutes per day and otherwise leaving it unused. ;)

[EB66]

+1 for this.

People forget just how affordable it can be to maintain your own infrastructure. You can have the hardware and network capable of supporting 10X your average traffic loads and still have it operate far more cost effectively than the equivalent traffic on AWS.

At my work, we slashed our overall hosting costs by moving a data warehouse off of AWS and on to our own self-maintained infrastructure.

But with a bloated inefficient IT department or non-savvy negotiations with hardware vendors or transit providers, it can also be more expensive than AWS.

[geggam]

I have had this debate with so many people, AWS is not cheaper than your own hosting. Period.

What you get from AWS is the logistics pipeline is already built as is the infrastructure should you suddenly require to serve factors of traffic more.

The ROI of AWS comes from the backend and capex vs opex debates.

Example : The CFO can go to the board and explain we are getting ready to reduce opex by laying off 10 developers at 150k yr during any meeting. The capex cost is usually fixed and hard to explain away.

[satanspastaroll]

I think the best cases for AWS is counter to marketing, very small companies. Their native offerings do make things great for a while when you're starting out.

The other is stupendous burst activity, like you just need a thousand(s) cores for a couple hours. Of course this doesen't mean the baseload has to be in AWS, just easy for small teams.

[geggam]

Agreed.

[K0SM0S]

I hear more and more cases of businesses moving parts off of the cloud, back on-premises. I think, in a wider perspective, it's going to play back and forth. The 2010's were 'forth' towards the cloud, the 2020's might see a peak back on-prems, etc.

It's generally a function of network cost versus infra cost, and so the 'equation' solves differently based on the longest tech cycles, from inception to maturity to skill pool to diminishing returns and then back again on some other mode — this really is a decade+ thing.

Some "always true" inherent advantages of one approach (e.g. availability for cloud, or resources for on-prems) would remain across cycles as permanent gains; disruption then occurs when some new approach (e.g. containerization) fundamentally upsets the order of costs.

[snark42]

> It's generally a function of network cost versus infra cost, and so the 'equation' solves differently based on the longest tech cycles,

It used to be OpEx was easy, CapEx was hard to get approved. As people took advantage and OpEx went through the roof people are getting alot more pushback on reducing OpEx.

[K0SM0S]

Spoken like a true Chief Officer.

Pushing back on OpEx in favor of CapEx might be seen as a more long-term strategy too. Basically rent vs purchase, even for deprecating assets like infosys, as I think the current DevOps trend (scaling in pure software, virtualization, etc) makes it easier than ever to squeeze every last FLOP on-premises.

[paulddraper]

> Only the biggest players can minimise their seasonality enough to get close to this

Okay, like AWS

> and doing that is a service that it’s probably worth paying for.

Okay, but how many orders of magnitude?

[bsder]

Well, reverse it: Amazon is about $1K per 10TB.

That's an expensive disk drive.

[nostrebored]

Thinking of it as a disk drive is fallacious