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

131–140 of 330 posts

Re: Use One Big Server (2022)

#131

Post by throwaway7783 »

troupo wrote: post #127
Spooky23 wrote: post #126

Earlier quoted context omitted.

It really depends on what you are doing. But when you factor the network features, the ability to scale the solution, etc you get alot of stuff inside that $200/mo EC2 device. The product is more than the VM. That said, with a defined workload without a ton of variation or segmentation needs there are lots of ways to deliver a cheaper solution.

> you get alot of stuff inside that $200/mo EC2 device. The product is more than the VM. What are you getting, and do you need it?

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 project, or when you reach a certain scale, it may makes sense to go the other way. U

Re: Use One Big Server (2022)

#132

Post by mannyv »

icedchai wrote: post #56
fragmede wrote: post #47

Earlier quoted context omitted.

That capacitor thing hasn't been true since the 90's.

Capacitor problem or not, hardware does fail. Power supplies crap out. SSDs die in strange ways. A failure of a supposedly "redundant" SSD might cause your system to freeze up.

One thing that we ran into back in the day was EEC failure on reboot.

We had a few Dell servers that ran great for a year or two. We rebooted one for some reason or another and it refused to POST due to an EEC failure.

Hauled down to the colo at 3AM and ripped the fucking ram out of the box and hoped it would restart.

Hardware fails. The RAM was fine for years, but something happened to it. Even Dell had no idea and just shipped us another stick, which we stuck in at the next downtime window.

To top it off, we dropped the failing RAM into another box at the office and it worked fine. .

Re: Use One Big Server (2022)

#133

Post by mannyv »

The one big box assumes that you know how to configure everything for high performance. I suspect that skill has been lost, for the most part.

You really need to tweak the TCP/IP stack, buffer sizes, and various other things to get everything to work really well under heavy load. I'm not sure if the various sites that used to talk about this have been updated in the last decade or so, because I don't do that anymore.

I mean, you'll run out of file descriptors pretty quickly if you try to handle a few hundred simultaneous connections. Doesn't matter how big your box is at that point.

Re: Use One Big Server (2022)

#134

Post by fock »

bob1029 wrote: post #10

This isn't even the end game for "one big server". AMD will give the most bang per rack, but there are other factors. An IBM z17 is effectively one big server too, but provides levels of reliability that are simply not available in most IT environments. It won't outperform the AMD rack, but it will definitely keep up for most practical workloads. If you sit down and really think honestly about the cost of engineering…

no. In the short time I work at a z/OS-shop, they had to IPL twice. And the IPL takes ages...

Now, if you can live with the weird environment and your people know how to programm what is essentially a distributed system described in terms noone else uses: I guess it's still ok, given the competition is all executing IBMs playbook too.

Re: Use One Big Server (2022)

#135

Post by alkonaut »

marcosdumay wrote: post #68
alkonaut wrote: post #57

Microservices vs not is (almost) orthogonal to N servers vs one. You can make 10 microservices and rent a huge server and run all 10 services. It's more an organizational thing than a deployment thing. You can't do the opposite though, make a monolith and spread it out on 10 servers.

> You can't do the opposite though, make a monolith and spread it out on 10 servers. You absolutely can, and it has been the most common practice for scaling them for decades.

That’s just _duplicating_ the nodes horizontally which wasnt what I meant.

That’s obviously possible snd common.

What I meant was actually butchering the monolith into separate pieces and deploying it, which is - by the definition of monolith - impossible.

Re: Use One Big Server (2022)

#136

Post by alkonaut »

const_cast wrote: post #81
alkonaut wrote: post #57

Microservices vs not is (almost) orthogonal to N servers vs one. You can make 10 microservices and rent a huge server and run all 10 services. It's more an organizational thing than a deployment thing. You can't do the opposite though, make a monolith and spread it out on 10 servers.

> You can't do the opposite though, make a monolith and spread it out on 10 servers. Yes you can. Its called having multiple applications servers. They all run the same application, just more of them. Maybe they connect to the same DB, maybe not, maybe you shard the DB.

That’s obviously not what I meant. I meant running different aspects of the monolith on different servers.

Re: Use One Big Server (2022)

#137

Post by twotwotwo »

themafia wrote: post #88
runako wrote: post #26

One of the more detrimental aspects of the Cloud Tax is that it constrains the types of solutions engineers even consider. Picking an arbitrary price point of $200/mo, you can get 4(!) vCPUs and 16GB of RAM at AWS. Architectures are different etc., but this is roughly a mid-spec dev laptop of 5 or so years ago. At Hetzner, you can rent a machine with 48 cores and 128GB of RAM for the same money. It's hard to overstat…

On AWS if you want raw computational capacity you use Lambda and not EC2. EC2 is for legacy type workloads and doesn't have nearly the same scaling power and speed that Lambda does. I have several workloads that just invoke Lambda in parallel. Now I effectively have a 1000 core machine and can blast through large workloads without even thinking about it. I have no VM to maintain or OS image to consider or worry about…

> [Hetzner] charges a "one time setup" fee to create that VM. That puts a lot of back pressure on infrastructure decisions and removes any scalability you could otherwise enjoy in the cloud.

Hetzner Cloud, then! In the US, $0.53/hr / $333.59/mo for 48 vCPU/192GB RAM/960GB NVMe. Includes 8 TB/mo traffic, when 8 TB egress would cost $720 on EC2; more traffic is $1.20/TB when the first tier of AWS egress is $90/TB. No setup fee. Not that it's EC2 but there's clearly flexibility there.

More generally, if you want AWS, you want AWS; if you want servers you have options.

Re: Use One Big Server (2022)

#138

Post by sysguest »

applied_heat wrote: post #123
shrubble wrote: post #91

Earlier quoted context omitted.

Paying someone $2000 to set that up once should result in the costs being recovered in what, 18 months? If you’re running Postgres locally you can turn off the TCP/IP part; nothing more to audit there. SSH based copying of backups to a remote server is simple. If not accessible via network, you can stay on whatever version of Postgres you want. I’ve heard these arguments since AWS launched, and all that time I’ve bee…

$2k? That’s a $100k project for a medium size Corp

hmm where did you get the numbers?

(what's "medium-size corp" and how did you come up with $100k ?)

Re: Use One Big Server (2022)

#139

Post by lelanthran »

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.

The RDS solution doesn't need a technical person to set it up?

It doesn't need someone who knows how to use the labrythine AWS services and console?

Re: Use One Big Server (2022)

#140

Post by fragmede »

garganzol wrote: post #58
fragmede wrote: post #47

Earlier quoted context omitted.

That capacitor thing hasn't been true since the 90's.

Hardware still fails. It isn't a question of "if", it's a question of "when". Nothing lasts forever, the naivety lasts only so long too.

Obviously. But you get duplicate hardware, set up HA, get vendor support contracts, use multiple colors in disparit location. Cloud providers have figured this out fairly well, as we all did in the aughts. (Well, some of us anyway.) You can definitely determine that's a bunch of really annoying work and just pay a cloud provider to deal with it, or not, and go your own way. But if you want to be credible when saying that hardware fails, maybe people shouldn't use a problem from three decades ago as their example and use anything more recent?
Post reply on HN