Live data from Hacker News

Use One Big Server (2022)

specbranch.com

181–190 of 330 posts

Re: Use One Big Server (2022)

#181
post #90

Earlier quoted context omitted.

Very few providers charge setup, some will provision a server within a 90s of an api call.

Hertzner does on the server the OP was referencing: https://www.hetzner.com/dedicated-rootserver/ax162-s/

If you are scared off by the €80 setup on a server that costs €200 a month, it seems like the setup fee did its intended job no?

Re: Use One Big Server (2022)

#182
post #177

A lot of the time businesses just aren't that important. The amount places I've seen that stress over uptime when nothing they run is at all critical. Hell you could drop the production environment in the middle of the day and yes it would suck and you'd get a few phone calls but life would go on. These companies all ended up massively increasing their budgets switching to cloud workloads when a simple server in the…

I had a team member who would reiterate that during tough times. They come from much more consequential work, so they would often remark that at least nobody dies when we fuck up.

Every corporate meeting should start with reminding ourselves that we're all going to die. And it most likely won't be from anything happening at the office.

Re: Use One Big Server (2022)

#183

Being a big server proponent myself. Usually for one reason or the other there is need to introduce some socket style communication to the frontend and that becomes impossible in a single machine after a certain threshold. Is there something obvious that I'm missing?

Load Balancing, Redundancy and Fail-Over

Re: Use One Big Server (2022)

#184
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…

I don't get why people are so hell-bent on going to AWS, for the most minor applications, without looking at simpler options!

I am not even thousands km near the level of what you are doing, but my client was paying $100/m for an AWS server, SQS and S3 bucket, for a small PHP based web application that uses Amazon Seller API, Keepa API for the products he ships. Used MySQL for data storage.

I implemented the whole thing in Python, Django, and PostgreSQL (initially used SQLite) put it in a $25/m unmanaged VPS.

I have not got any complaints about performance, and it's running continuously updating product prices, details, processing PDF invoices using OCR, finding missing products in shipments, while also serving the website, and a 4 core server with 6GB RAM is handling it just fine.

The load is not going to be so high to require AWS and friends, for now. It's a small internal app, probably won't even get over 100 users, and if it ever does, it's extremely simple to migrate, because the app is so compact, even though not exactly monolithic.

And still, it probably won't need a $100 AWS server, unless we are scaling up much larger.

Re: Use One Big Server (2022)

#185

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.

I meant in the sense of ”machine A only manages thing authentication” and ”machine B only manages orders”.

If that’s possible (regardless of what was deployed to the two machines) then the app just isn’t a true monolith.

Re: Use One Big Server (2022)

#186

I helped bootstrap a company that made an enterprise automation engine. The team wanted to make the service available as SaaS for boosting sales. They could have got the job done by hosting the service in a vps with a multi-tenant database schema. Instead, they went about learning kubernetes and drillingg deep into "cloud-native" stack. Spent a year trying to setup the perfect devops pipeline. Not surprisingly the co…

Yep, this is why I'm a proponent of paas until the bill actually hurts. Just pay the heroku/render/fly tax and focus on product market fit. Or, play with servers and K8s, burning your investors money, then move on to the next gig and repeat...

The moment I sign up for a PaaS the bill hurts. I can never get over the fact I can get 1000x more compute for the same price, never mind that I never use it and have to set everything up myself. I’ll just never pay to lock myself in to something so restricted. My dedicated server allows me to do anything I want or need.

Re: Use One Big Server (2022)

#187

Earlier quoted context omitted.

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?

Like, you keep your server running for a month and you need to pay $255 pricey? I can get about 64 cores of dedicated compute for the price of a single neon compute (4c/16gb) unit.

And that’s before you factor in 500gb of storage.

Re: Use One Big Server (2022)

#188
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…

I don't get why people are so hell-bent on going to AWS, for the most minor applications, without looking at simpler options! I am not even thousands km near the level of what you are doing, but my client was paying $100/m for an AWS server, SQS and S3 bucket, for a small PHP based web application that uses Amazon Seller API, Keepa API for the products he ships. Used MySQL for data storage. I implemented the whole th…

How much did that reimplementing cost and when will the savings exceed that cost?

Re: Use One Big Server (2022)

#189
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…

I don't get why people are so hell-bent on going to AWS, for the most minor applications, without looking at simpler options! I am not even thousands km near the level of what you are doing, but my client was paying $100/m for an AWS server, SQS and S3 bucket, for a small PHP based web application that uses Amazon Seller API, Keepa API for the products he ships. Used MySQL for data storage. I implemented the whole th…

What are some cheaper and better hosting providers that you can recommend?

Re: Use One Big Server (2022)

#190

Earlier quoted context omitted.

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…

When you get duplicate hardware, it is not "One Big Server" anymore. "Two Big Servers" at least. In September 2015, the failure rate caused by capacitors was still around 30% [1].

[1] https://www.researchgate.net/figure/Failure-rates-of-differe...

Post reply on HN