Truth is, most web projects made today can run on a raspberry pi or mini PC and be just fine. If you have enough users that you need to scale to more machines, you'll be in a position to know what to do to handle it, or hire someone who does.
Yet, for some reason, I see this repeated everywhere, always. Does it make the people who repeat it feel better? Are they actually informing anyone of anything? Who knows.
Granted, I'm sure the average engineer will be very relieved to find out they're paramount to production.
Go grab a similar server from Hetzner or something.
This is actually pretty apparent if you camp a web forum. People seem to either need a raspberry pi or a data center: this is the typical web-app vs mmorpg divide amongst possible computational fantasies people have. Questioning what motives people have is very sensible.
It's worth repeating, if only to raise awareness among devs that modern computers are _extremely_ fast. You can start a new one with commodity hardware and it will probably serve your needs for the lifetime of the project. If your project gets so popular/successful that you need more than a single machine, then I would hope by that point you know how to move it onto a cluster of machines, or into the cloud if the economics make sense.
I say "most web projects" because it's true - most web projects are simple CRUD apps in slightly different forms. Sure, there are some up-and-comers using AI to burn half a data center to produce fake comments and images for internet forums. Those won't run on a Pi or single mini PC. But people are making _so_ many web apps that will never see more than a few hundred or thousand users. Those don't need multi-instance load-balanced highly-available infinite-scaling systems to serve their users needs. That usually just adds cost and complexity until you're at a point where you _really_ need it.
That is super easy to do on AWS (and many other providers) but not so easy (or even impossible) anymore when you do things on-prem.
EDIT: due to the replies, let me clarify; this is not an argument for AWS specifically but for services that make it easy to spin up machines and that handle deployments and failover for you.
Also, there are more reasons to have more than one machine, e.g. being able to deploy with zero downtime and therefore without having to think when to deploy and what to do if a deployment fails etc.
You are absolutely correct
If someone has zero knowledge, then everything will take them a long time, including hosting on-prem or so.
Missing what point? You are apparently agreeing with me and disagreeing with the OP who said: "can run on a raspberry pi or mini PC".
This is what I objected to:
> And then, you probably want to do deployments in a way where you spin up 2 new machines and then, only once confirmed that the deployment works, shut down the old 2.
You don't need to spin up more machines or shut down machines. As long as you ensure you have the headroom you spin up containers and shut down containers. By doing that, it's also relatively easy to set up hybrid setups where you can handle load-spikes by scaling into EC2 or similar if you should ever need to.
Are you very sure you are not introducing potential additional problems with that approach? Because if you do, then I wouldn't say it's "not needed" to spin more additional machines - it would depend on those additional problems.
An hour? What happens if it breaks while I'm on vacation and no one is there to take care?
Nah, that argument might work sometimes but not in general.
What happens if you're on vacation and something breaks is that you call/email the DC and ask them to replace what's broken, same as if you were not on vacation. In my experience most DCs will have the replacement done in less than 30 min from receiving the ticket, good ones will do it in under 15. If the project is ran by more than one person, simply don't all take a vacation at the same time. Worst case scenario you point DNS to a free static page host that reads "Server broke. Working on a fix, check back tomorrow." (or the appropriate corporate-PR phrasing of the same if applicable) while you wait for the computer store to open so you can buy a new one.
Even if you are once-in-a-lifetime unlucky and the damn thing breaks while you're on vacation and for some reason your monitoring fails to notify you, big whoop. You can probably get away with just apologizing for the inconvenience and moving on. If a week long outage is enough to make or break your business, your business isn't gonna work out anyway.
This applies to practically all web projects from the home page of the pizza place on the corner of your street to 100-employee e-commerce sites. If a single machine can run it, it can probably run on a single machine. Use the dumbest tool that will get the job done, switch to a smarter tool when it won't.
If your business has an SLA with its customers, having a week long outage is going to break your business. Some contracts I saw had a 15 minute reaction time where you had to acknowledge the issue, and after 1 hour of downtime there are penalties. The same contract also required redundancy (of hardware, internet lines as well as location for the DCs). We could not have hosted that on a Raspi, or a single machine.
I don't think reducing the scale issue to "you ain't gonna need it" is right. Obviously to most projects it's not gonna be needed. But when it does and you need to grow, you'll be happy you have a redundant infrastructure that you can spin up/down easily instead of having to call your DC to ask for more hardware to be installed.
The answer might be to buy management services. Or an SLA for AWS.
If you're running an online shop/reservation system, a hour of downtime can be tens of thousands of lost revenue.
False. You can run kubernetes and/or some virtualisation engine as well and do the same on prem.
and overprovisioning physical hardware is much cheaper.
Can't do that with your own hardware unless it's also a Kubernetes cluster, which is a whole new set of crap you need to manage.
It’s as if an entire generation of tech workers are utterly unaware that these have been solved problems for decades.
You put two machines behind HAProxy with keepalived. If you want to do a new deployment, you can spin up new machines in the same manner, and cut them over (or any of the many other ways to accomplish this).
AWS isn’t inventing any of the HA stuff they offer; they’re taking existing technologies and packaging them.
I do agree that your projects should be designed to be well contained and easy to create a new instance of it, though.
The site was a blog with traffic of 1, load balancer, cloud run and storage bucket.
I shut it down. It was a nice exercise but not worth it to me long term.
Awesome, your 5 node Nutanix setup with 15 whole VMs is peaking at 5% of its total compute, 5% of its RAM, and 8% of its disk. Granted, I do work with medium sized businesses in the manufacturing sector, but so many get tricked into thinking they need 5 9s, when 3 is enough, and their setup isn't even providing 5 anyway because nothing else is downstream. Then 5 years later their warranty is up and they scrap it all and replace. It's crazy.
Kills me how many businesses contract this shit out and get tricked into spending a million on infra when they could just run 2 servers and pay a mid level engineer to manage it. "Not in the budget." Yeah, I wonder why.
(Started with proxmox but the installer’s kernel doesn’t have the Ethernet driver and they don’t provide WiFi because it’s stupid for the installed system - but they allow upgrading to a kernel which supports my adapter, so got a bit catch 22’d. Moved to Ubuntu server that would stop booting after creating a bridge interface because ‘waiting for network. no timeout’ and then a few more interesting issues.)