[overstay8930]

If you're at the point you're doing sophisticated cloud cost analysis you are doing the cloud right, because that is completely impossible anywhere else.

I swear the people who say go on premise have no idea how much the salary costs of someone who will not treat their datacenter like a home lab is. Even Apple iCloud is in AWS and GCP because of how economical it is, you suck at the cloud you think you have to go back on prem, or you just don't give a shit about reliability (start pricing up DDoS protection costs at anything higher than 10G and tell me the cloud is more expensive).

We spend 100k+ on AWS bandwidth and it's still cheaper than our DIA circuits because we don't have to pay network engineers to manage 3 different AZs.

[dzikimarian]

Apparently we're doing the impossible for over 12 years now. Who knew?

Some people act like it's some kind of black magic. It's not. We've some customers in our DC and some on AWS for various reasons. AWS isn't less problematic. AWS is about 10x more expensive. Both on prem and cloud require people familiar with them and cloud-engineers are in no way cheaper.

Only meaningful problem is that on-prem requires some up front cost&time. That can be mitigated by leasing and other means, but indeed can be an issue for small businesses.

[chongli]

Both on prem and cloud require people familiar with them and cloud-engineers are in no way cheaper.

I think the real story is a bit sordid: office politics. On-prem and cloud are different skillsets. Companies that have been around for a while can end up with both on-prem and cloud experts who end up competing with each other, often on separate teams. Throw in some slick consultants from Amazon who are able to bend the ear of the VP and you've got a real problem. From what I've seen it doesn't end well for the on-prem team!

[hirako2000]

I concur. Many VPs bend ears so easily you got to wonder. do they also get invited to some private dinner by those so called slick consultants, who pay the bill in a rush and leaves after forgetting some thick envelope on the table.

[chongli]

It’s a story as old as time itself. IBM has been doing it at least as far back as the 60’s. Fancy consultants who know the tech and also know how to sell and make themselves seem way smarter than the VP’s reports. Do one slick presentation and the VP is asking his team “why didn’t you guys come up with this stuff?”

Next thing you know these multi-million-dollar contracts are signed and the existing teams are just shaking their heads. The smart ones have already put out their resumes and started interviewing elsewhere.

[hirako2000]

I'm not one of those smart ones. So many things I was seeing for years make much more sense now.

It's an old story but I guarantee you many don't know about it.

[icedchai]

If you have a large enough on-prem infrastructure where you are using automation and not manually configuring everything, the skillsets will have a lot of overlap.

[overstay8930]

Cloud engineers can do the job of 4-5 on-prem people. Our AWS devs don't need to be BGP or ZFS experts, they just need to be AWS experts.

[rrrix1]

Hilariously ironic, with a sufficiently large cloud footprint, things like BGP (and more/other internetworking protocols) and OpenZFS become required skillsets. I have firsthand experience of this. :)

[FireBeyond]

Yeah, there was an amusement there. I've definitely had to understand BGP to configure cloud VPC setups.

"They just have to be an AWS expert".

Right. They just have to be experts in: EC2, S3, Aurora, DynamoDB, RDS, Lambda, VPC, LightSail, Athena, EMR, RedShift, MQ, SQS, SNS, ECR, ECS, EKS, ElastiCache, CloudWatch, CloudTrail, IAM, Cognito, and a few more. No big deal.

[dzikimarian]

Well our on-prem team doesn't need AWS pricing calculation and optymization expert, so there's that :-)

[owenmarshall]

AWS pricing and optimization is just capacity planning, which doesn’t go away if you run on prem - it just looks different, with longer time horizons & financial implications.

“Will my data center run out of floor space & I need to expand?” (years+)

“Will I have enough cooling & power to support the new racks we need?” (6 months+)

“When do I need to get the server order out to ensure we meet our capacity needs?” (6+ weeks)

Every one of those are capital expenditures, so line them up with the annual budget cycle - be sure to keep enough spare capacity to be responsive for last minute asks.

Don’t think my intent is to romanticize the cloud, either. It’s not better, nor worse, just a different way to manage things.

Of course if your company is sufficiently small, do whatever you know and can do quickly - customer acquisition will be more important than debating the cost of either infra in aws or a colo’d server or two in some racks somewhere. But the complexity doesn’t go away if you go to the cloud, OR if you are all on prem. TINSTAAFL.

[BackBlast]

2015 called and wants it's hype back.

[falserum]

Cloud clearly makes sense for:

- small business with at least some reliability expectation, and little to none IT expertise

- huge workload requirement volatility

- having someone else to blame

- solution is already working in cloud, with teams being very comfortable there, and perceiving on-prem as “enemy” (analogy: forcing devs to rewrite stuff from haskell to java)

- that extra cost is small budget line for you

On the other hand, it does not make sense to go cloud, if you are sufficiently big and already have on prem solution and expertise in house. (Extreme case: google, does not use aws for its main load; this upper threshold I wager is couple of orders of magnitude smaller)

[ipaddr]

Cloud doesn't make sense for small business. A vps would. If you are spending less than 100,000 you probably don't need it for your 10,000 million or less daily visitors

[Turing_Machine]

If you're spending less than 100,000, you almost certainly aren't spending enough to pay salary + benefits for a sysadmin.

[BackBlast]

Why does everyone always jump to this fiction?

You probably aren't paying a "cloud engineer" just to fiddle with cloud config full time with <$100k/yr spend. Why would you suddenly need a full time sysop to do the same capability level of on-prem? If you do 10 hours of "cloud engineering" a month to support an application, the same capability level of on-prem work is probably in the same ballpark. 5-30 hours. Yes, it can be lower than cloud. No, it's NOT suddenly 160 hours every month. Yes, it does mean you need someone who can wear the extra hat, cloud engineering skills are literally no different in this regard.

Internet sites ran on basement and closet servers for years, actual server rooms for larger stuff. The jokes were tripping over power cords and backhoes digging up internet lines were the causes of most outages. It's never been easier to run on-prem than today. It cost a fraction of even budget VPS providers like Hetzner.

For certain classes of applications, it's awesome. It's not everyone's cup of tea I'll grant. But if you are inclined to play with hardware or have someone in the org who does, and an extra 2-4 hours of downtime a year isn't that big of a deal (depending on general utility and network available at your chosen site). You can save tons of money.

[icedchai]

Exactly this. I've set up several VPSes for clients. They go for years without any maintenance because they don't want to pay for it. (They only bother when something is absolutely critical... like the OS is EOL and no more security upgrades.)

[ipaddr]

Why would you need additional people to manage a vps? The person managing amazon can very easily use cpanel because it is much simpler.

[MaxBarraclough]

> Extreme case: google, does not use aws for its main load; this upper threshold I wager is couple of orders of magnitude smaller

Not a good example in my opinion, as Google is also a major provider of cloud services. AWS isn't the only game in town.

I think Disney+ is a more interesting case. A quick google search turns up some articles saying their video streaming is powered by external CDNs. As I understand it, Netflix take the opposite approach and deliver all video data from their own Open Connect CDN, although they use AWS for other workloads (presumably including things like authentication, their recommendation engine, etc).

[dzikimarian]

Depending how small is small business, but I would probably go with VPS.

[coredog64]

Amazon retail runs on AWS, and I think we can agree that Amazon retail is reasonably described as “large scale”

[SOLAR_FIELDS]

Is that really a fair comparison though? AWS is a very weird argument to make because you could say that AWS is kind of “on premise” for Amazons purposes. Internally Amazon.com does not pay retail pricing or have the same level of support as third party end users. A better example would be looking at Jet.com/Walmart and asking if it runs on AWS.

[overstay8930]

Nobody who is big is paying retail prices, that's why saying "on premise is cheaper" is total copium.

As soon as you start factoring in discounts (i.e. bandwidth is nearly free at some point), the math of being on premise completely falls apart to the point you are paying more for licensing and support for the hardware than you are the entire lifecycle of your infrastructure in the cloud. It's just that bad to do it yourself.

[rstuart4133]

> licensing and support for the hardware

Sorry, but who pays for licensing and support of the hardware? I've never done that. You buy a Dell server or whatever, you pay for the 5 or 7 years warranty up front, you put in in a rack and you never literally touch it again until it's EOL'ed. If something breaks Dell touches it, not you. That typically costs around $500/year, albeit paid upfront.

But you usually don't do that. Instead you rent a dedicated metal from someone. The cost if of the order of $1000/year including some storage, no more to pay unless you exceed 100TB/year. A similarly configured AWS EC2 instance is $13,000/year, plus bandwidth, plus whatever other services you get sucked into. And you will get sucked into it because if you ask AWS about any problem (like say, monitoring why your bills are so high), the answer is invariably "use this paid service of ours".

You're kidding yourself if you think using AWS is cheaper than the alternatives. Those discounts you speak of are from an absurdly high starting point. I'm sure there are lots of reasons to use AWS or a similar cloud service, but unless you only need a lot of grunt for at most a few months price isn't one of them.

[BackBlast]

I ran the numbers the other day. For just compute with my particular load, my numbers say AWS costs 73928x more for lambda over my on-prem. Like for like is 1250x more. This is presuming the savings levels for being a big spender that I've heard about.

That's a lot of room to work with for some inconvenience.

[no_wizard]

This is a quirk of the business that is Amazon and AWS, as they started by selling excess compute and expertise, due to how Amazon was built as API first internally it was almost natural.

It’s in no way the norm for a smaller business.

[rented_mule]

This matches the public (i.e., non-Amazon) speculation I was hearing around the launch of S3 and later EC2. But not what I was hearing internally when I worked at Amazon. I was there when S3, the first AWS service, and EC2 were launched. I was working on what I believe to be the first Amazon (non-AWS) application that used S3 for storage. Getting that approved was not easy - all the same skepticism existed internally as externally (cost, availability, durability, security, etc.).

The story I was hearing internally was that it was too costly to scale infrastructure the way Amazon had been doing it, it was fragile, and the expertise wasn't keeping up with growth. So, set the bar a lot higher, and build infra that is big enough and flexible enough to be everybody's infra, and then Amazon's applications (e.g., retail) could run on AWS' excess capacity. Literally the opposite of what external folks were guessing. I believe they were completely physically separate data centers - even the physical location of AWS data centers were on a need-to-know basis internally (the internal lore was "under a mountain in Virginia" - this was years before Regions and Availability Zones). And any bugs in AWS could be worked out with outside usage before moving Amazon's applications onto it.

Also, Amazon needed the elasticity of AWS because of the nature of their retail business. At the time that the initial AWS services were being developed, a massive chunk of Amazon's traffic came during the holiday season. IIRC, something like half of the year's traffic and revenue, possibly more, came in November/December each year. That meant a lot of capacity was sitting idle most of the year. Selling that excess capacity would mean shutting AWS down every holiday season.

For a time, there was an internal mailing list that wasn't yet locked down that contained reports on S3 bandwidth usage. The growth rate was shockingly high. I would guess that within a year or two of release, S3 was using a few (at least) orders of magnitude more bandwidth than everything else at Amazon combined.

[no_wizard]

In broad strokes, the main point I was makings till stands though: AWS was deliberately made to back the demanding scale of Amazon, it was a bet on the future and the Amazon model as much as it was product service, and that did mean they built expertise and hardware up and sold that as a product none the less.

This still isn't the norm for most businesses, even big ones.

[no_wizard]

In many organizations the biggest appeal of services like AWS or GCP isn’t simply cost, it’s that the service is approved and therefore all the services of that service are approved and I no longer have to justify spinning up more compute or leveraging one of their more bespoke services like SQS (or wherever equivalent). It’s all just there, ready to be used.

It may not be true for you and where you work but this is a very real thing in a lot of organizations, where development teams want a quicker turn around on booting up services they need as the product evolves and having some control over how they act with each other. It (sometimes to negative results) opens up more architectural possibilities to solve problems

[dzikimarian]

I'm not saying using AWS is universality bad. Depends on your needs.

What I'm saying is some people are trying to portrait rolling your own k8s or on-prem as equivalent to rolling your own crypto - better left to the chosen ones with years of training in secret monastery. This is BS :-)

[tqi]

These types of debates always seem to go this way - one person saying one option works way better for them so the other option must be crazy, followed by another person saying the opposite. I'm not an infra guy, but my guess is the reality is both are choosing the right option for themselves, because is no one objectively "best" option. Just tradeoffs.

I also think if a company is unhappy with their current set up and thinks that switching from cloud to on-prem (or vis versa) is the answer, they're probably delusional because "the fault, dear Brutus, is not in our stars, but in ourselves."

[dzikimarian]

Completely not my point. I don't say that using cloud is crazy(we're using it sometimes). I'm saying that opinion that on-prem is much harder than AWS is IMO wrong.

Requires some planning ahead of time - yes. Harder - not really.

[holoduke]

My small business once spend 50k per month on AWS. We brought that back to 800 dollars for a similar setup at Hetzner. I find this a significant number.

[icedchai]

What's your Hetzner setup look like? 98% cost savings makes me curious...

[glintik]

Reliability differs, right?

[simplyinfinity]

I have hetzner vms going on 500+ DAYS without restart. I've been a hetzner customer for about 8 years now. Aws has been down x10 times more than hetzner has. And even when hetzner has issues they are localized to a single DC at worst, most often a single host is down. When aws has issue.. The whole internet has issues. Or their central region goes out, also can affect their other regions.

For the small/medium businesses infra I manage here in bulgaria , the same thing would cost 5-10 times as much on aws just for the compute, throw in 1tb of bandwidth.. And this makes no financial sense.

On hetzner I pay 40 euros for 2 vms, dedicated ips, daily backups, 100gb of ssd external storage, and firewall.

[mad182]

I have more than 10 servers on Hetzner (some dedicated, some VPS), for 5+ years and the same experience, once one of the dedicated servers had some hardware issues, and an hour later the drives were moved to another box and it was running again. Other than that time, I had downtime only because of my own fault.

Pretty sure over these years AWS has experienced a lot more issues overall.

[overstay8930]

"Yea this small VPS provider with 1% of the features is just as good as AWS to us" yea that's because you aren't using features as basic as AWS Nitro Enclaves and you are years behind even basic cloud security.

Hetzner is for running homelabs and basic compute, not businesses. That's why EU companies constantly ignore EU rulings on US-EU privacy shield because there's just no alternative to American cloud providers yet.

[fabian2k]

People have been running real businesses before the cloud providers existed. Of course you can run a business with rented dedicated servers.

[overstay8930]

Of course you can run your business on it, you will just suffer because there is practically 0 automation to it. I guess if you are a small business but we are very obviously not talking about mom and pop shops who need a web and email server.

[lillecarl]

Incorrect, there's automation for on-prem or smaller providers as well, just because you're unable to doesn't mean it's the truth.

How do you think AWS or Cloudflare is built?

[overstay8930]

You're arguing semantics, you are on massive copium if you think that automation is useful to anyone. Go ahead and set up cryptographic attestation (or just try and interface with a TPM ffs) for your apps on Hetzner to decrypt customer data and see how impossible it is.

[holoduke]

My business is running on Hetzner. And many others as well.

[snug]

AWS and GCP are giving companies like Apple huge discounts so someone could say something like, "Even Apple iCloud is in AWS and GCP because of how economical it is"

There is too much nuance to say one is better than the other. In some cases using a IaaS is more economical, in other cases it's not.

For Apple, the same is also true[0] to say "Even Apple is running their own datacenters because of how economical it is"

0 - https://dgtlinfra.com/apple-data-center-locations/#:~:text=a....

[overstay8930]

You know everyone gets those discounts right? Like that's why the cloud is so much more economical than a datacenter, once you are at scale AWS will give you MASSIVE (I'm talking 30-60% discounts) on compute and other compute-adjacent resources, and I've seen 99% discounts on bandwidth with multi year agreements too.

I think that's where the disconnect is, a lot of people don't actually realize how cheap cloud compute is because they're only seeing the price for like... 20-30 servers and some basic S3 or load balancer usage. There are entire departments at Amazon that run those numbers on a daily basis to make sure AWS is always competitive with building your own datacenter.

[qvrjuec]

>someone who will not treat their datacenter like a home lab

What does this mean? They steal company resources for themselves, or just configure things incompetently?

[ttul]

Incompetence. Take my friend’s company for instance. They were frustrated paying $60K/mo to Amazon so their brilliant sysadmin bought $600K of servers and moved them into a cheap colo.

Over Christmas, everything died, and the brilliant sysadmin was on holiday. Nobody could get things going again for many days and so their entire SaaS business was failing. They lost a lot of business and trust as a result.

The sysadmin is now gone and they are back on AWS.

[lijok]

No key person risk management -> no risk register -> no management. Your friends company will fail regardless of poor sysadmin decision making or not. They need to hire competent management ASAP.

[overstay8930]

This is basically the logic of people who say the cloud is too expensive, you have to ignore so many things to make being on premise logical. Basically you are lying to yourself if you think you can run a datacenter cheaper and better than Amazon or Microsoft can, because if you can you are just making huge sacrifices somewhere (usually time, which is why reddit sysadmins complain about how much work they have while defending being on-premise because they couldn't possibly be wrong).

[project2501a]

you must be management, cuz

1. you think it's the sysadmin's fault

2. there are no competent sysadmins out there

[123pie123]

>Basically you are lying to yourself if you think you can run a datacenter cheaper and better than Amazon or Microsoft

what magical things do they have? that every single reasonably sized enterprise doesn't have? it should be extremly easy for a small enterprise to beat any of the main clouds* - they make crap ton of profit from you

*making an assumption that your needs are reasonably static and not MASSIVELY busting up and down your infrastructure

[plywoodtrees]

The "magical" thing they have is thousands and thousands of people thinking about how to improve the performance/efficiency/availability of their datacenters.

And yes, they pay the costs of those people and take a good profit margin, and yes there are in some ways diminishing returns to go from 3 nines to 6. But most enterprises can't match that depth of concentrated expertise, certainly not most small enterprises.

[mdale]

With cloud and SaaS services you are paying to reduce person risk profile.

Your forming a larger dependency on a team lead against a custom system that now is a liability as new people come to the organization don't want to adopt an abandoned poorly understood project.

[ttul]

This company is reasonably well run. After going back to AWS, they doubled their revenue and things are going well. They are not incompetent. They did earnestly try to cut their costs and just didn’t see the iceberg.

[rzzzt]

Faint ISO 27001 sounds in the background

[OrvalWintermute]

> brilliant sysadmin was on holiday

> entire SaaS business

> [ Unmentioned - Single Point of Failure Service dependent on a single admin ]

If you are fully accounting for vacation, training, sleep etc then you need a minimum of 5 admins for mission critical services. Now, you can engineer around this to reduce your staffing requirement but I wouldn't recommend going under 2 ever because accidents happen.

This business seemed one below that, without the engineering, and I would point to the mgmt, not the brilliant admin as the problem.

[jjav]

> The sysadmin is now gone and they are back on AWS.

This story has nothing to do with AWS or on-prem.

It's a story about incompetent management allowing a single human point of failure. If they don't change that, they'll have the same problem wherever they go.

[overstay8930]

Non-scalable incompetence or basically pretending that the datacenter will never go down. Any high schooler with an iPhone can set up and maintain a datacenter full of servers.

But if you want something reliable that I can spend 30 seconds writing some terraform for, it will take an entire infra team to set up and maintain it, not to mention an entire procurement process and now having to integrate a new supply chain just for a basic multi-az setup (probably without things like backups and still without basic features the cloud gives you automatically).

[tiffanyh]

> on premise have no idea how much the salary costs of someone

I haven’t yet meet anyone at a company that heavily uses cloud and still doesn’t have the same number of salaried infra people as on-prem.

[echelon]

You act like these problems are especially hard.

Active-active, five nines, fault tolerance. Hard stuff. But managing on-prem is no harder.

This is what we're paid for.

[kevin_nisbet]

Managing on-prem hardware may not necessarily be hard, but it can be extremely time consuming. To me, the nice thing about dropping a bunch of hardware in a colo is you get to take a lot of shortcuts and take risks that you cannot buy from the public cloud providers.

I worked for a company and would do it again that did the colo route, and it gave immense cost savings compared to public cloud, taking on risks that you can't do elsewhere. Before they started investing in having folks take care of the infra as a raw startup, it was just some servers and some desktop unmanaged switches. But that gave the company breathing room to survive as the business model probably didn't work without it. But also had a reputation for unreliable service.

I've also built the five nines infra at telcos, and yes you can do it with average engineers, but it's going to be time consuming, slow, and expensive in costs and labor. To allow 26 seconds of unplanned outage a month, you're going to be testing every firmware update for every piece of equipment on an ongoing basis, and practicing every operation and change as best as possible. And you need the scale that you get that 26s by having most outages only impact a subset of your customer base, otherwise you're going to blow that outage budget fast.

[hobs]

Managing on prem is definitely harder because you are benefiting from the economics of scale of all the management problems that you have to pay yourself, and if you don't have scale then you will be significantly overpaying to get the same type of quality, reliability, or responsiveness.

Most people are not paid to manage infra, they are paid to talk to customers, ship features, fix bugs, and other "core business" items; just like most businesses don't build roads, they pay taxes and utilize them because the cost of doing it themselves for their preferred traffic patterns would be much more than they could justify (for now.)

[BackBlast]

If you don't have scale, you don't need most of the features. Fire up PC, load application. Setup egress port open to internet. Setup application backup on cron job. Done until scale problems arise.

[hobs]

Correct, my point absolutely doesn't apply to someone who is just doing their thing, even maybe 2 orders of magnitude more stuff than their thing.

But when your local IT goon says its going to be 8 months to procure the next set of hard drives for your next order of magnitude, it's a real problem and you have real money to invest in solving it, just not owning a data center money.

[overstay8930]

"this is what we're paid for" Nope, it's what YOU'RE paid for.

I am paid to relax on my holidays because I know my team and I don't have to drive to a colo to swap out a failing line card since I realized time is worth money and people quit jobs that take up too much of their time. I can A/B test (something on-prem guys NEVER get the luxury to do) so outages just don't happen at all (fingers crossed).

I have rarely met someone happy with their on-prem DC deployments, but after I moved to the AWS world it's just crazy how backwards it is to be anywhere but the cloud.

[icehawk]

Anyone serious wouldn't "drive to the colo to swap out a failing line card" they keep have excess capacity and spares in the colo, and have the on-site personnel from the facility replace it.

Honestly just sounds like the environment you describe has greater organizational issues not related to on prem vs cloud.

[jjav]

> backwards it is to be anywhere but the cloud

It's almost as if you feel the cloud is something magically different, it's actually just servers on racks owned by someone else.

You can own the same thing if you want and do everything exactly the same.

(See e.g. Oxide)

[echelon]

That feels really grumpy.

Compare something like rocketry or chemical engineering with running an on-prem DC. I don't see what the complaining is about. It's still a luxury compared to what other professions have to deal with.

[123pie123]

there's so much to unpack here!!

[acdha]

On-prem is massively harder if you can’t cut corners on security or reliability. Just things like testing & upgrading firmware, doing real DR testing (I know multiple places which spent lots of time and money doing annual failover tests, but went down hard every time they had a true failure due to something they’d missed), handling things like boot signing or secure logging, etc. all take up multiple FTEs worth of time, or are a checkbox from a platform which handles that for you.