Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use one big server

specbranch.com

Post reply on HN
Print view View original

251–260 of 601 posts

Re: Use one big server

#251

Post by giardini »

danpalmer wrote: post #158
rbanffy wrote: post #150

Earlier quoted context omitted.

> Use One Big Database. I emphatically disagree. I've seen this evolve into tightly coupled microservices that could be deployed independently in theory, but required exquisite coordination to work. If you want them to be on a single server, that's fine, but having multiple databases or schemas will help enforce separation. And, if you need one single place for analytics, push changes to that space asynchronously. Ha…

To clarify the advice, at least how I believe it should be done… Use One Big Database Server… … and on it, use one software database per application. For example, one Postgres server can host many databases that are mostly* independent from each other. Each application or service should have its own database and be unaware of the others, communicating with them via the services if necessary. This makes splitting up i…

">Use One Big Database Server…

… and on it, use one software database per application.

FWIW that is how it is usually is done(and has been done for decades) on mainframes (IBM & UNISYS).

-----------------------

"Plus ça change, plus c'est la même chose."

English: "the more things change, the more they stay the same."

- old French expression.

Re: Use one big server

#252

Post by gorjusborg »

ustolemyname wrote: post #71
gregmac wrote: post #8

> However, cloud providers have often had global outages in the past, and there is no reason to assume that cloud datacenters will be down any less often than your individual servers. A nice thing about being in a big provider is when they go down a massive portion of the internet goes down, and it makes news headlines. Users are much less likely to complain about your service being down when it's clear you're just c…

This has given me a brilliant idea: deferring maintenance downtime until some larger user-visible service is down. This is terrible for many reasons, but I wouldn't be surprised to hear someone has done this.

Ah yes, the 'who cut the cheese?' maintenance window.

Re: Use one big server

#253

Post by travisgriggs »

andrepew wrote: post #32
gregmac wrote: post #8

> However, cloud providers have often had global outages in the past, and there is no reason to assume that cloud datacenters will be down any less often than your individual servers. A nice thing about being in a big provider is when they go down a massive portion of the internet goes down, and it makes news headlines. Users are much less likely to complain about your service being down when it's clear you're just c…

This is a huge one -- value in outsourcing blame. If you're down because of a major provider outage in the news, you're viewed more as a victim of a natural disaster rather than someone to be blamed.

"Value in outsourcing blame"

The real reason that talented engineers secretly support all of the middle management we vocally complain about.

Re: Use one big server

#254

Post by Joeri »

rbanffy wrote: post #150
cfors wrote: post #56

Yep, there's a premium on making your architecture more cloudy. However, the best point for Use One Big Server is not necessarily running your big monolithic API server, but your database. Use One Big Database. Seriously. If you are a backend engineer, nothing is worse than breaking up your data into self contained service databases, where everything is passed over Rest/RPC. Your product asks will consistently want t…

> Use One Big Database. I emphatically disagree. I've seen this evolve into tightly coupled microservices that could be deployed independently in theory, but required exquisite coordination to work. If you want them to be on a single server, that's fine, but having multiple databases or schemas will help enforce separation. And, if you need one single place for analytics, push changes to that space asynchronously. Ha…

I have done both models. My previous job we had a monolith on top of a 1200 table database. Now I work in an ecosystem of 400 microservices, most with their own database.

What it fundamentally boils down to is that your org chart determines your architecture. We had a single team in charge of the monolith, and it was ok, and then we wanted to add teams and it broke down. On the microservices architecture, we have many teams, which can work independently quite well, until there is a big project that needs coordinated changes, and then the fun starts.

Like always there is no advice that is absolutely right. Monoliths, microservices, function stores. One big server vs kubernetes. Any of those things become the right answer in the right context.

Although I’m still in favor of starting with a modular monolith and splitting off services when it becomes apparent they need to change at a different pace from the main body. That is right in most contexts I think.

Re: Use one big server

#255

Post by FpUser »

cfors wrote: post #56

Yep, there's a premium on making your architecture more cloudy. However, the best point for Use One Big Server is not necessarily running your big monolithic API server, but your database. Use One Big Database. Seriously. If you are a backend engineer, nothing is worse than breaking up your data into self contained service databases, where everything is passed over Rest/RPC. Your product asks will consistently want t…

>"Use One Big Database."

I do, it is running on the same big (relatively) server as my native C++ backend talking to the database. The performance smokes your standard cloudy setup big time. Serving thousand requests per second on 16 core without breaking sweat. I am all for monoliths running on real no cloudy hardware. As long as the business scale is reasonable and does not approach FAANG (like for 90% of the businesses) this solution is superior to everything else money, maintenance, development time wise.

Re: Use one big server

#256

Post by eastbound »

SoftTalker wrote: post #57
Nextgrid wrote: post #17

Earlier quoted context omitted.

> you need to get over the hump and build in multiple servers into your architecture from the get go (the author says you need two servers minimum), so really we are talking about two big servers. Managing a handful of big servers can be done manually if needed - it's not pretty but it works and people have been doing it just fine before the cloud came along. If you intentionally plan on having dozens/hundreds of sma…

I manage hundreds of servers, and use Ansible. It's simple and it gets the job done. I tried to install Kubernetes on a cluster and couldn't get it to work. I mean I know it works, obviously, but I could not figure it out and decided to stay with what works for me.

But it’s specific, and no-one will want to take over your job.

The upside of a standard AWS CloudFormation file is that engineers are replaceable. They’re cargo-cult engineers, but they’re not worried for their career.

Re: Use one big server

#257

Post by FpUser »

BenoitEssiambre wrote: post #226
cfors wrote: post #56

Yep, there's a premium on making your architecture more cloudy. However, the best point for Use One Big Server is not necessarily running your big monolithic API server, but your database. Use One Big Database. Seriously. If you are a backend engineer, nothing is worse than breaking up your data into self contained service databases, where everything is passed over Rest/RPC. Your product asks will consistently want t…

I'm glad this is becoming conventional wisdom. I used to argue this in these pages a few years ago and would get downvoted below the posts telling people to split everything into microservices separated by queues (although I suppose it's making me lose my competitive advantage when everyone else is building lean and mean infrastructure too). In my mind, reasons involve keeping transactional integrity, ACID compliance…

>"I'm glad this is becoming conventional wisdom. "

Yup, this is what I've always done and it works wonders. Since I do not have bosses, just a clients I do not give a flying fuck about latest fashion and do what actually makes sense for me and said clients.

Re: Use one big server

#258

Post by riquito »

goodoldneon wrote: post #181
danpalmer wrote: post #158

Earlier quoted context omitted.

To clarify the advice, at least how I believe it should be done… Use One Big Database Server… … and on it, use one software database per application. For example, one Postgres server can host many databases that are mostly* independent from each other. Each application or service should have its own database and be unaware of the others, communicating with them via the services if necessary. This makes splitting up i…

OP mentioned joining, so they were definitely talking about a single database

Not suggesting it, but for the sake of knowledge you can join tables living in different databases, as long as they are on the same server (e.g. mysql, postgresql, SQL server supports it - doesn't necessarily come for free)

Re: Use one big server

#259

Post by NorwegianDude »

maxbond wrote: post #195
kardianos wrote: post #54

Earlier quoted context omitted.

That sounds like you have burst load. Per the article, cloud away, great fit. The point was most people don't have that and even their bursts can fit in a single server. This is my experience as well.

The thing that confuses me is, isn't every publicly accessible service bursty on a long timescale? Everything looks seasonal and predictable until you hit the front page of Reddit, and you don't know what day that will be. You don't decide how much traffic you get, the world does.

Hitting the front page of reddit is insignificant, it's not like you'll get anywhere near thousands upon thousands of requests each second. If you have a somewhat normal website and you're not doing something weird then it's easily handled with a single low-end server.

If I get so much traffic that scaling becomes a problem then I'll be happy as I would make a ton of money. No need to build to be able to handle the whole world at the same time, that's just a waste of money in nearly all situations.

Re: Use one big server

#260

Post by adam_arthur »

I'm building an app with Cloudflare serverless and you can emulate everything locally with a single command and debug directly... It's pretty amazing.

But the way their offerings are structured means it will be quite expensive to run at scale without a multi cloud setup. You can't globally cache the results of a worker function in CDN, so any call to a semi dynamic endpoint incurs one paid invocation, and there's no mechanism to bypass this via CDN caching because the workers live in front of the CDN, not behind it.

Despite their media towards lowering cloud costs, they have explicitly designed their products to contain people in a cost structure similar to but different than via egress fees. And in fact it's quite easily bypassed by using a non Cloudflare CDN in front of Cloudflare serverless.

Anyway, I reached a similar conclusion that for my app a single large server instance works best. And actually I can fit my whole dataset in RAM, so disk/JSON storage and load on startup is even simpler than trying to use multiple systems and databases.

Further, can run this on a laptop for effectively free, and cache everything via CDN, rather than pay ~$100/month for a cloud instance.

When you're small, development time is going to be your biggest constraint, and I highly advocate all new projects start with a monolithic approach, though with a structure that's conducive to decoupling later.

Post reply on HN