This is such a narrow perspective. It’s not always about load, most applications can benefit from some level of redundancy and using AWS etc doesn’t equal a massive scaling operation forced upon you. In fact, the other options would. I'll give you some common examples.

You have a script that needs to run, without fail, at a certain time every day.

You have an endpoint that is mission-critical and even a second of downtime would cause insane manual workload.

You have an endpoint that needs to have as little end-user latency as physically possible.

These are all real examples from my work in fintech. The solution to all of them is a few dollars in cloud functions in Lambda and Lambda@Edge. Now imagine having to provision, orchestrate and maintain dozens of dedicated hosts all by yourself, simply for these handful scripts. The expense of employee time alone would make it absolutely idiotic to go that route and if anything this would equal massive scale day - but even worse, because you didn't even plan for it beforehand.

I work in fintech (banking and payments) and most of our clients aren’t even allowed to host on aws; they have to go for a local provider because aws doesn’t have a hosting hub in their country. Not sure what part you work in but this has never been a problem in the past 20 years with just servers, switches, load balancers etc.

I prefer aws over metal for these kind of setups, but for many other cases I definitely do not; just a dedi or a vps with docker or k8s and/or something like openfaas is enough for almost all startups and beyond. Making it literally impossible to make mistakes like OP. And when needed maybe failover or load balancing.

I don’t know about that, the hedge fund I work for is US-based and AWS can be fully SEC and FINRA compliant.

We also have a few dedicated servers, but mostly only for infrequently accessed data and logging that doesn’t need to be highly available.

I really can’t understand why this argument keeps coming up. Different solutions for different usecases. Yet anytime Kubernetes or cloud functions are discussed people come in and go like “hurr durr my single Hetzner dedicated server can do all of that and doesn’t have these problems”

Because some people here do exactly the same thing with aws/cloud. Not you but many here treat aws like it’s the thing you should use ‘because scaling and failover and omg 1 sec downtime’. And then the stories like OP showing that it is dangerous and my experience that most who do this are overpaying and could do with a hetzner server or, better even, a $5/mo vps, even if they do it right (which they are not, generally from all setups I have seen).

I agree with you though on the case by case.

Obviously the billing mechanism (or, lack of control) is an issue but that doesn't negate the whole concept. They could (and should) easily fix this by implementing hard caps to activate if so required.

Nobody says there isn't any use case for AWS. The point is that "the cool kids" like to start their side projects on AWS. Nothing about it is mission critical. I guarantee you op is not working on some Fintech stuff.

How's that bad? Isn't this how we all learned? By playing with cool modern technology?

I feel like learning how to configure bird, bind, haproxy, rdbms clusters, redundant MXs, etc. has taught me far more than spinning up equivalent virtual infrastructure on a public cloud would have. Getting to play with the underlying FOSS technologies is far more rewarding to me than using the commercialized versions on someone else's stack. Plus it helps me evaluate and architect my products for competing clouds, rather than my "knowledge and understanding" being tied to one particular vendor's offerings & lexicon. (Another advantage of knowing the underpinnings of a cloud is that it makes reading post-mortems[1] with a morning coffee so much more enjoyable.)

Assuming we're talking about side-projects/hobbyist development: when I'm doing that I want as few variable expenses as possible, and they usually don't require the purported benefits of the cloud. If such a project needs to scale: I'll bolt it onto a cloud at that point, or sprinkle in specific services to address the pain points.

[1]: https://tritondatacenter.com/blog/manta-postmortem-7-27-2015

> I feel like learning how to configure bird, bind, haproxy, rdbms clusters, redundant MXs, etc. has taught me far more than spinning up equivalent virtual infrastructure on a public cloud would have.

I agree with this, but the choice of what other individuals play with is not ours to make. There's still countless of youngsters working on bare metal, for whatever it's worth, they just grow up in a world with a lot of existing abstractions now.

> Assuming we're talking about side-projects/hobbyist development: when I'm doing that I want as few variable expenses as possible, and they usually don't require the purported benefits of the cloud. If such a project needs to scale: I'll bolt it onto a cloud at that point, or sprinkle in specific services to address the pain points.

100%, but the choice is free for anyone themselves to make. OP is furthering his knowledge and experience in a very specialised and highly sought after sector. Maybe he'll come to the same conclusion at some point, or maybe he comes from bare metal and has different perspectives now and thinks that redundancy is always awesome.

Pretty easy, OP sounds exactly like a guy who would have been perfectly fine with a single (Hetzner) server. Then these arguments popup and they are most of the time right. I agree with you, that it always depends on the use. However, hurr durr Hetzner Server seems to be the more reasonable choice here (once again).

OP here.

Hetzner provides incredibly beefy machines for a good price.

I’ve been managing 2 machine cluster setup in the past using Hetzner and it worked fine.

Unfortunately I have had an incident with one machine going bad unexpectedly(RAM issue) and I was forced to spend whole day setting up a new one.

Why? If you had the choice between complete redundancy and infinite scaling by default while having almost zero work, or using a dedicated server that you need to configure and constantly maintain, what would you choose?

If with one thing, a single mistake can result in a $5k bill, and with the other I have a guaranteed fixed bill of 50 bucks a month, then unless I have enough money to burn, the choice is crystal clear. Maybe you wipe your butt with 100$ bills. Others aren't that lucky.

Exactly; if it is ‘the same’ but with a guarantee of max 50$/mo then sure, I would pick that, but that is not the case, also not with caps. So it is an entirely different case and usually the 50$ option actually brings you very far without any financial risk outside that $50/mo.

The choice is only crystal clear until AWS etc implement hard caps to activate if needed. Then having some Lambda functions is not only exponentially cheaper than a whole dedicated server and by default highly available and redundant, but also equally as safe financially wise.

> You have an endpoint that needs to have as little end-user latency as physically possible.

If you need the lowest possible latency then you should definetly do it yourself. Lambda, even with provisioned concurrency has a very high latency...

If the solution you're building is business-critical then you already have a problem day one: you need high-availability. That means you need at least two servers. As soon as you add that additional server your troubles have begun. Doesn't really much matter whether you add 1 server to your setup or 100.

Your problems compound if you have to consider disaster recovery (DR) and need an offsite location you can failover to. Now you have to contend with data replication and all its concerns.

So even if your application only has a few dozen users things can get quite complex quite fast. AWS makes it simple, practically push-button. Deploying in multiple Availability Zones (AZ) is a no-brainer, and it isn't horribly difficult to deploy in multiple regions, complete with data replication. All while having no servers to configure and maintain. No containers to contend with, no Kubernetes to fight with. To me it's the most stupid-simple solution available today and it's ridiculously cheap! At least so long as you test before you deploy for world exposure!

I completely agree with you. I really suspect some people have never seen themselves how insanely, mind-bogglingly powerful AWS is.

Try doing this [0] with your dedicated servers in under 10 minutes.

And then try attaching highly-available scripts/cloud functions and dozens of different integrated functionality in seconds.

And then try setting up good Network ACL, firewalls, route tables, NAT gateways, load balancers with a few clicks.

... and people here are seriously suggesting that instead using AWS would equal a massive forced scaling operation. Lol.

[0]: https://i.ibb.co/TKmB9HX/image.png

Sure, but not all of us are working at tiny startups or on personal projects. Many of us here work for large companies that have real scale already and are trying to solve those problems.

Why does everyone assume everyone else works at tiny startups?

At that point you're already at day 1000 and already know what scale you need for the project so none of this conversation is relevant. You already have hit the point you need to build it a certain way.

I've never worked at a startup, until last year I never worked at a company with less than 100k employees.