3 ms·
Well, it depends. There are companies or individuals with tight budgets. And if you set something like that yourself, from my experience it needs very little ma
by vitro 2y ago
Well, it depends. There are companies or individuals with tight budgets. And if you set something like that yourself, from my experience it needs very little maintenance, if done right. My servers run without interruptions and interventions for months now. YMMV.
- deafpolygon 2y agoUntil a disaster happens. If you’re running a commercial site that sells products and it goes down… that translates to money lost. If you were paying 15k a year to put a portfolio site online, then I can see where it can be too much.
- bryanrasmussen 2y ago>Until a disaster happens. why not go cloud when the disaster happens while fixing your disaster, then close down cloud when disaster fixed?
- JohnFen 2y ago> If you’re running a commercial site that sells products and it goes down… that translates to money lost. True! It's also true that if you control your own servers, then you can fix the problem yourself instead of waiting until some provider somewhere gets around to it.
- vitro 2y agoIt's not like cloud providers don't have outages either. And for disasters you should always have backups and a migration plan, even if you are in the cloud, no? I'm not preaching against cloud, just saying that there are some cases where going bare metal is a better option instead of using cloud by default "because everyone does it".
- deafpolygon 2y agoI'm not arguing for or against cloud, but there are more costs to running bare metal than it would seem. I'm a sysadmin and have run schools on bare metal and on cloud. There are things like drive failures, hardware failures, connectivity issues, networking, user access, and all of those things that are much easier in the cloud. Much easier to spin up or down if you no longer need them. If you're running networked storage, then that needs to have both a fail-over node and backup solution. You probably need to run extra hardware, cabling, etc. Cloud trivializes this. If you're saving 15k in terms of hard cost, but spending 55k/yr for a sysadmin on-prem to maintain, then you're not saving money at all. A disaster can be as simple as a failed disk, or overheated server because you're not a sysadmin and you put the server in a cabinet (I've run into this, dealing with faculty). Dead computer, no lessons for the week - lost time for the school and the professor in question. Every place is different; you have to do a cost analysis and it's not as simple as "I saved 10x!"
- vitro 2y agoJust to be clear, I was not talking about on-prem bare metal, but more like hosted bare metal by providers like Hetzner or OVH. Like the guy in the article has. Speaking of drive failures, cables and other hardware failures - provider takes care of that and replaces failed parts.
- rmbyrro 2y agoThis is the issue in cloud vs. metal discussions online. All the time I think I'm reading apples and then realize people were talking bananas.
- caeril 2y ago> Much easier to spin up or down if you no longer need them. It takes 5 minutes to set up a Docker Swarm Mode cluster. It takes maybe 15 minutes for k3s or microk8s. After that, auto-scaling is dead simple, and no MORE complex than some shitty vendor locked-in cloud solution. > that needs to have both a fail-over node and backup solution ZFS pool replication, Ceph, GlusterFS, etc. Lots of options here. These are long-solved problems. > A disaster can be as simple as a failed disk Right, which is why you design your on-prem cluster with N+2 redundancy in the first place, and with a locked cabinet with spare parts. Cattle not pets, and all that. Do you think your EBS storage never fails? You'd need to do exactly the same thing in the cloud, anyway. > but spending 55k/yr for a sysadmin on-prem to maintain First, if you're paying only 55k for sysadmins, you should be planning to fail anyway. Competence is compensated quite a bit north of there. Second, assuming the context is small business, you're going to have role crossover anyway, it's inevitable - chances are that your developer(s) is(are) administering this. Not every business is Facebook.