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

161–170 of 330 posts

Re: Use One Big Server (2022)

#161

Post by mrweasel »

yjftsjthsd-h wrote: post #95
bspammer wrote: post #84

Earlier quoted context omitted.

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.

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 sysadmin, but have been labelled and sold as: Consultant (sounds expensive), DevOps engineer, Cloud Engineer, Operations Expert and right now a Site Reliability Engineer.... I'm a systems administrator.

Re: Use One Big Server (2022)

#162

Post by Cthulhu_ »

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.

While that's fair, most organizations I've worked at in the past decade have had a dedicated team for managing their cloud setup, which is also responsible for backups, updates, monitoring, security and access control. I don't think they're competing.

Re: Use One Big Server (2022)

#163

Post by 1dom »

immibis wrote: post #97
Nextgrid wrote: post #85

Earlier quoted context omitted.

> 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 .

> 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 has even already had the argument "if the cloud provider goes down, it's not your fault" as a cloud benefit. Either cloud is strong and stable and can't break, or cloud breaks often enough that people will just excuse you for it.

Re: Use One Big Server (2022)

#164

Post by kapone »

toast0 wrote: post #60
fogx wrote: post #34

Earlier quoted context omitted.

don't you think it's highly unlikely that someone will stumble over the power cable in a hosted datacenter like hetzner? and even if, you could just run a provisioned secondary server that jumps in if the first becomes unavailable and still be much cheaper.

I don't know about Hetzner, but the failure case isn't usually tripping over power plugs. It's putting a longer server in the rack above/below yours and pushing the power plug out of the back of your server. Either way, stuff happens, figuring out what your actual requirements around uptime, time to response, and time to resolution is important before you build a nine nines solution when eight eights is sufficient. :…

> It's putting a longer server in the rack above/below yours and pushing the power plug out of the back of your server

Are you serious? Have you ever built/operated/wired rack scale equipment? You think the power cables for your "short" server (vs the longer one being put in) are just hanging out in the back of the rack?

Rack wiring has been done and done correctly for ages. Power cables on one side (if possible), data and other cables on the other side. These are all routed vertically and horizontally, so they land only on YOUR server.

You could put a Mercedes Maybach above/below your server and nothing would happen.

Re: Use One Big Server (2022)

#165

Post by jiggawatts »

mystifyingpoi wrote: post #148
jiggawatts wrote: post #114

I'm in the process of breaking up a legacy deployment on "one big server" into something cloud native like Kubernetes. The problem with one big server is that few customers have ONE (1) app that needs that much capacity. They have many small apps that add up to that much capacity, but that's a very different scenario with different problems and solutions. For example, one of the big servers I'm in the process of teas…

Finally, someone said it. > 100 distinct code bases deployed to it I've worked in a company, where the owner would spend money on anything except hosting. Admin guy would end up deploying a new app on whatever VPS that had the most RAM free at that time. Ironically, consolidating this mess to "one big server", which was my ungrateful job for many months, fixed many issues. Though, it was done by slicing the host into…

> slicing the host into tiny KVM virtual machines.

That's my other option: a bunch of Azure VM Scale Sets using the tiniest size that will run Windows Server, such as B2as_v2. A handful of closely related apps on each so that firewall rules can be restricted to something sane. Shared Azure Files for the actual app deployments so that devs never need to know the VM names. However, this feels an awful lot like reinventing Kubernetes... but worse.

My job would be sooo much simpler if Microsoft just got off their high horse and supported their own Active Directory in App Service instead of pretending it no longer exists.

Re: Use One Big Server (2022)

#166

Post by b112 »

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…

Not to mention scaling. Most clients I know never, ever have scaled once. Ever. Or if they do, it's to save money.

One server means you can handle the equiv of 100+ AWS instances. And if you're into that turf, then having a rack of servers saves even more.

Big corp is pulling back from the cloud for a reason.

Re: Use One Big Server (2022)

#169

Post by andersmurphy »

immibis wrote: post #98
andersmurphy wrote: post #41

Earlier quoted context omitted.

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…

Not sure what you are talking about? In WAL mode (which is what you should be using) writes don't block reads and reads don't block writes. If you are connections pooling (which you should) the cache will stay hot.

Sqlite (properly configured) will outperform "proper databases" often by an order of magnitude in the context of a single box. You want a single writer for high performance as it lets you batch.

> 256 hardware threads...

Have you tried? I have. Others have too. [1]

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

Sqlite has blobs so you can use your own custom encoding which is what you want in a high performance context.

Here's sqlite on a 5$ shared VPS that can handle 10000+ checks per second over a billion checkboxes [2]. You're gonna be fine.

- [1] https://use.expensify.com/blog/scaling-sqlite-to-4m-qps-on-a...

- [2] https://checkboxes.andersmurphy.com

Re: Use One Big Server (2022)

#170

Post by fuckaj »

ozozozd wrote: post #146
alkonaut wrote: post #135

Earlier quoted context omitted.

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.

What would be the point of actually butchering the monolith? There is no limit or cost to deploying 10000 lines over 1000 lines.

[dead]
Post reply on HN