Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use One Big Server (2022)

specbranch.com

Post reply on HN
Print view View original

221–230 of 330 posts

Re: Use One Big Server (2022)

#221

Post by namibj »

Havoc wrote: post #79

>Unfortunately, since all of your services run on servers (whether you like it or not), someone in that supply chain is charging you based on their peak load. This seems fundamentally incorrect to me? If I need 100 units of peak compute during 8 hours of work hours, I get that from Big Cloud, and they have two other clients needing same in offset timezones then in theory the aggregate cost of that is 1/3rd of everyon…

In which cloud can I book a machine with a guaranteed (up to general uptime SLA) end/termination time that's fixed for both?

Re: Use One Big Server (2022)

#222

Post by steveBK123 »

bspammer wrote: post #84
matt-p wrote: post #74

Earlier quoted context omitted.

The difference between a fairly expensive ($300) RDS instance + EC2 in the same region vs a $90 dedicated server with a NVME drive and postgres in a container is absolutely insane.

A fair comparison would include the cost of the DBA who will be responsible for backups, updates, monitoring, security and access control. That’s what RDS is actually competing with.

My firm paid DBAs for RDS as well so..

Re: Use One Big Server (2022)

#223

Post by icedchai »

sgarland wrote: post #111
icedchai wrote: post #89

Earlier quoted context omitted.

UPSes always seem to have strange failure modes. I've had a couple fail after a power failure. The batteries died and they wouldn't come back up automatically when the power came back. They didn't warn me about the dead battery until after...

That’s why they have self-tests. Learned that one the hard way myself.

My UPS was supposedly "self testing" itself periodically and it still happened!

Re: Use One Big Server (2022)

#224

Post by namibj »

1dom wrote: post #163
immibis wrote: post #97

Earlier quoted context omitted.

They do rely on you to tell them if hardware fails, however, and they'll still unplug your server and physically fix it. And there's a risk they'll replace the wrong drive in your RAID pair and you'll lose all your data - this happens sometimes - it's not a theoretical risk. But the cloud premium needs reiteration: twenty five times . For the price of the cloud server, you can have twenty-five-way redundancy .

> And there's a risk they'll replace the wrong drive in your RAID pair and you'll lose all your data - this happens sometimes - it's not a theoretical risk. A medium to large size asteroid can cause mass extinction events - this happens sometimes - it's not a theoretical risk. The risk of the people responsible for managing the platform messing up and losing some of your data is still a risk in the cloud. This thread…

There's a reason semiconductor manufacturing is so highly automated, and it's not labor cost. Humans err. Computers only err when told. But they'll repeat a task reliably without random mistakes if told what to do by a competent (manufacturing process) engineering organization. Yes it takes more than one engineer.

Re: Use One Big Server (2022)

#225

Post by icedchai »

themafia wrote: post #103
icedchai wrote: post #99

Earlier quoted context omitted.

That's fine, except for all of Lambda's weird limitations: request and response sizes, deployment .zip sizes, max execution time, etc. For anything complicated you'll eventually you run into all this stuff. Plus you'll be locked into AWS.

> request and response sizes If either of these exceed the limitations of the call, which is 6MB or 256kB depending on call type, then you can just use S3. For large distributed task coordination you're going to be doing this anyways. > deployment .zip sizes Overlays exist and are powerful. > max execution time If your workload depends on long uninterrupted runs of time on single CPUs then you have other problems. >…

Of course, we can generally work around all these things. The point is it is annoying to do so. It adds friction and further couples you to a proprietary platform.

You're better off using ECS / Fargate for application logic.

Re: Use One Big Server (2022)

#226

Post by icedchai »

mrweasel wrote: post #161
yjftsjthsd-h wrote: post #95

Earlier quoted context omitted.

As long as you also include the Cloud Certified DevOps Engineer™[0] to set up that RDS instance. [0] A normal sysadmin remains vaguely bemused at their job title and the way it changes every couple years.

It's also interesting that the cloud engineer can apparently be both a DBA, network-, storage- and backup engineer, but if you move the same services on-prem, you apparently need specialists for each task. Sometimes even the certified cloud engineers can't tell you why an RDS behaves the way it does, nor can they really fix it. Sometimes you really do need a DBA, but that applies equally to on-prem and cloud. I'm a s…

I haven't seen a company that hired DBAs in over 15 years. I think the "DevOps" movement sent them packing, along with SysAdmins.

Re: Use One Big Server (2022)

#227

Post by sgarland »

whartung wrote: post #119
sgarland wrote: post #110

Earlier quoted context omitted.

Yep. I know people will say, “it’s just a homelab,” but hear me out: I’ve ran positively ancient Dell R620s in a Proxmox cluster for years. At least five. Other than moving them from TX to NC, the cluster has had 100% uptime. When I’ve needed to do maintenance, I drop one at a time, and it maintains quorum, as expected. I’ll reiterate that this is on circa-2012 hardware. In all those years, I’ve had precisely one act…

Being as I love minor disaster anecdotes where doing all the "right things" seem to not make any difference :). We had a rack in data center, and we wanted to put local UPS on critical machines in the rack. But the data center went on and on about their awesome power grid (shared with a fire station, so no administrative power loss), on site generators, etc., and wouldn't let us. Sure enough, one day the entire rack…

For sure, things can and will go wrong. For critical services, I’d want to split them up into separate racks for precisely that reason.

Re: power strips, thanks for the reminder. I’m usually diligent about that, but forgot about one my wife uses. Replacement coming today.

Re: Use One Big Server (2022)

#228

Post by andersmurphy »

Aeolun wrote: post #191
andersmurphy wrote: post #46

Earlier quoted context omitted.

Most industries are not bursty. Overprovision in not expensive for most businesses. You can handle 30000+ updates a second on a 15$ VPS. A multi node system tends to be less reliable and more failure points than a single box system. Failures rarely happen in isolation. You can do zero downtime deployment with a single machine if you need to.

> A multi node system tends to be less reliable and more failure points than a single box system. Failures rarely happen in isolation. Just like a lot of problems exists between keyboard and chair, a lot of problems exist between service A and service B. The zero downtime deployment for my PHP site consisted of symlinking from one directory to another.

Nice!

Honestly, we need to stop promoting prematurely making everything a network request as a good idea.

Re: Use One Big Server (2022)

#230

Post by viraptor »

eska wrote: post #147
throwaway7783 wrote: post #131

Earlier quoted context omitted.

Probably not for $200/mo EC2, but AWS/GCP in general * Centralized logging, log search, log based alerting * Secrets manager * Managed kubernetes * Object store * Managed load balancers * Database HA * Cache solutions ... Can I run all these by myself? Sure. But I'm not in this business. I just want to write software and run that. And yes, I have needed most of this from day 1 for my startup. For a personal toy proje…

Now imagine your solution is not on a distributed system and go through that list. Centralized logging? There is nothing to centralized. Secrets management? There are no secrets to be constantly distributed to various machines on a network. Load balancing? In practice most people for most work don’t use it because of actually outgrowing hardware, but because they have to provision to shared hardware without exclusivi…

> Centralized logging? There is nothing to centralized.

It's still useful to have the various services, background jobs, system events, etc. in one indexed place which can also manage retention and alerting. And ideally in a place reachable even if the main service goes down. I've got centralised logging on a small homelab server with a few services on it and it's worth the effort.

> Load balancing? In practice most people for most work don’t use it because of actually outgrowing hardware, but because they have to provision to shared hardware without exclusivity.

Depending on how much you lose in case of downtime, you may want at least 2x of hardware for redundancy and that means some kind of fancy routing (whether it's LB, shared IP, or something else)

> Secrets management? There are no secrets to be constantly distributed to various machines on a network.

Typically businesses grow to more than one service. For example I've got a slack webhook in 3 services in a small company and I want to update it in one place. (+ many other credentials)

> Caching? Distributed systems create latency that doesn’t need to exist at all

This doesn't solve the need for caching results of larger operations. It doesn't matter how much latency you have or not, you still don't want that rarely-changing 1sec long query to run on every request. Caching is rarely only about network latency.

Post reply on HN