Live data from Hacker News

Use One Big Server (2022)

specbranch.com

141–150 of 330 posts

Re: Use One Big Server (2022)

#141
post #127

Earlier quoted context omitted.

> 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 proje…

You need database HA and load balancers on day 1?

You must be doing truly a lot of growth prior to building. Or perhaps insisting on tiny VMs for your loads?

Re: Use One Big Server (2022)

#142
post #124

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…

> Not surprisingly the company went out of business within the next few years. But the engineers could find new jobs thanks to their acquired k8s experience.

Get paid to learn and build your career instead, baby!

Re: Use One Big Server (2022)

#143

Earlier quoted context omitted.

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

> I meant running different aspects of the monolith on different servers.

Of course you can. I've done it.

Identical binary on multiple servers with the load balancer/reverse proxy routing specific requests to specific instances.

The practical result is indeed "running different aspects of the monolith on different servers".

Re: Use One Big Server (2022)

#144
I run on VPSs as well. I ditched cloud a long time ago. Once my project starts making money, I will definitely buy my own hardware and collocate. Cloud is like dating apps. We had fun for a decade but it's time to get serious and get some things actually done and be productive again.

Re: Use One Big Server (2022)

#145
post #72

Earlier quoted context omitted.

What’s the issue with running Postgres inside a docker container + regular backups? Never had problem and relatively easy to manage.

no PITB, but mostly just 'it's hassle' for the application server I literally don't need backups, just automated provisioning/docker container etc. Adding postgres then means I need full backups including PITB because I don't even want to lose an hours data.

Or use SQLite and your backups are literally a copy of a file.

You can abuse git for it if you really want to cut corners.

Re: Use One Big Server (2022)

#146

Earlier quoted context omitted.

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

What would be the point of actually butchering the monolith?

There is no limit or cost to deploying 10000 lines over 1000 lines.

Re: Use One Big Server (2022)

#147
post #127

Earlier quoted context omitted.

> 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 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 exclusivity. Caching? Distributed systems create latency that doesn’t need to exist at all, reliability issues that have to be avoided, thundering herd issues that you would otherwise not have, etc.

So while there are areas where you need to introduce distributed systems, this repeated disparaging comment of “toy hobby projects” makes me distrust your judgement heavily. I have replaced many such installations by actually delivering (grand distributed designs often don’t fully deliver), reducing costs, dramatically improving performance, and most importantly reducing complexity by magnitudes.

Re: Use One Big Server (2022)

#148

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 tiny KVM virtual machines.

Re: Use One Big Server (2022)

#149

Earlier quoted context omitted.

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-h…

> significantly more expensive per vCPU hour It's almost exactly the same price as EC2. What you don't get to control is the mix of vCPU and RAM. Lambda ties those two together. For equivalent EC2 instances the cost difference is astronomically small, on the order of pennies per month. > like transcoding long videos, [...] data analysis, and other compute-heavy tasks If you aren't breaking these up into multiple smal…

> If you aren't breaking these up into multiple smaller independent segments then I would suggest that you're doing this wrong in the first place.

Care to elaborate?

Re: Use One Big Server (2022)

#150

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…

You need database HA and load balancers on day 1? You must be doing truly a lot of growth prior to building. Or perhaps insisting on tiny VMs for your loads?

> Or perhaps insisting on tiny VMs for your loads?

This happens way too often. Early-stage startups that build everything on the AWS free tier (t2.micro only!), and then when the time comes they scale everything horizontally

Post reply on HN