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

91–100 of 330 posts

Re: Use One Big Server (2022)

#91

Post by shrubble »

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.

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 been running Postgres (since 2004 actually) and have never encountered all these phantom issues that are claimed as being expensive or extremely difficult.

Re: Use One Big Server (2022)

#92

Post by solid_fuel »

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…

Strong disagree here. Lambda is significantly more expensive per vCPU hour and introduces tight restrictions on your workflow and architecture, one of the most significant being maximum runtime duration.

Lambda is a decent choice when you need fast, spiky scaling for a lot simple self-contained tasks. It is a bad choice for heavy tasks like transcoding long videos, training a model, data analysis, and other compute-heavy tasks.

Re: Use One Big Server (2022)

#93

Post by theaniketmaurya »

cpursley wrote: post #67
fragmede wrote: post #44

Earlier quoted context omitted.

> the PaaS route certainly burns more money, Does it? Vercel is $20/month and Neon starts at $5/month. That obviously goes up as you scale up, but $25/month seems like a fairly cheap place to start to me. (I don't work for Vercel or Neon, just a happy customer)

Yeah, also a happy neon customer - but they can get pricy. Still prefer them over AWS. For compute, Fly is pretty competitive.

I’m using Neon too and upgraded to the scale up version today. Curious, what do you mean rhat they can get pricey?

Re: Use One Big Server (2022)

#94

Post by matt-p »

api wrote: post #82
matt-p wrote: post #77

Earlier quoted context omitted.

I have also found this happening. It's actually really funny because I think even I'm less inclined to run postgres myself these days, when I used to run literally hundreds of instances with not much more than PG_DUMP, cron and two read only replicas. These days probably the best way of getting these 'cloudy' engineers on board is just to tell them its Kubernetes and run all of your servers as K3s.

I’m convinced that cloud companies have been intentionally shaping dev culture. Microservices in particular seem like a pattern designed to push managed cloud lock in. It’s not that you have to have cloud to use them, but it creates a lot of opportunities to reach for managed services like event queues to replace what used to be a simple function call or queue. Dev culture is totally fad driven and devs are sheep, so…

Yeah I think that's fair. I'm very pro containers though, that's a genuine step forward from deploy scrips or vm images.

Re: Use One Big Server (2022)

#95

Post by yjftsjthsd-h »

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.

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.

Re: Use One Big Server (2022)

#96

Post by SatvikBeri »

A lot of these articles look at on-demand pricing for AWS. But you're rarely paying on-demand prices 24/7. If you have a stable workload, you probably buy reserved instances or a compute savings plan. At larger scales, you use third party services to get better deals with more flexibility.

A while back I looked into renting hardware, and found that we would save about 20% compared to what we actually paid AWS – in partially because location and RAM requirements made the rental more expensive than anticipated, and partially because we were paying a lot less than on-demand price for AWS.

20% is still significant, but it's a lot less than the ~80% that this and other articles suggest.

Re: Use One Big Server (2022)

#97

Post by immibis »

Nextgrid wrote: post #85
bearjaws wrote: post #28

Earlier quoted context omitted.

> Can you explain on this claim, beyond what the article mentioned? I run a lambda behind a load balancer, hardware dies, its redundant, it gets replaced. I have a database server fail, while it re provisions it doesn't saturate read IO on the SAN causing noisy neighbor issues. I don't deal with any of it, I don't deal with depreciation, I don't deal with data center maintenance.

> I don't deal with depreciation, I don't deal with data center maintenance. You don't deal with that either if you rent a dedicated server from a hosting provider. They handle the datacenter and maintenance for you for a flat monthly fee.

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.

Re: Use One Big Server (2022)

#98

Post by immibis »

andersmurphy wrote: post #41
matt-p wrote: post #6

A thoroughly good article. It's probably worth also considering adding a CDN if you take this approach at scale. You get to use their WAF and DNS failover. A big pain point that I personally don't love is that this non-cloud approach normally means running my own database. It's worth considering a provider who also provides cloud databases. If you go for an 'active/passive' setup, consider saving even more money by u…

If you're running on a single machine then you'll get way more performance with something like sqlite (instead of postgres/MySQL) which also makes managing the database quite trivial.

SQLite has serious concurrency concerns which have to be evaluated. You should consider running postgres or mysql/mariadb even if it's on the same server.

SQLite uses one reader/writer lock over the whole database. When any thread is writing the database, no other thread is reading it. If one thread is waiting to write, new reads can't begin. Additionally, every read transaction starts by checking if the database has changed since last time, and then re-loading a bunch of caches.

This is suitable for SQLite's intended use case. It's most likely not suitable for a server with 256 hardware threads and a 50Gbps network card. You need proper transaction and concurrency control for heavy workloads.

Additionally, SQLite lacks a bunch of integrity checks, like data types and various kinds of constraints. And things like materialised views, etc.

SQLite is lite. Use it for lite things, not hevy things.

Re: Use One Big Server (2022)

#99

Post by icedchai »

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…

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.

Re: Use One Big Server (2022)

#100

Post by dardeaup »

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…

At what cost politically? I would expect political battles to be far more intense than any of the technical ones.
Post reply on HN