Use one big server • Hacker News Board

Re: Use one big server

#461

Post by banku_brougham » Wed, Aug 03, 2022, 5:39 AM UTC

throwfh80h82 wrote: post #406

endisneigh wrote: post #402

Earlier quoted context omitted.

Without details it's hard to really get anything from this. Could you share some?

I can share some. Had a similar experience as the parent comment. I do support "one big database" but it requires a dedicated db admin team to solve the tragedy of the commons problem. Say you have one big database. You have 300 engineers and 30-50 product managers shipping new features every day accountable to the C-Suite. They are all writing queries to retrieve the data they want. One more join, one more N+1 query…

I've seen this too. I guess 50% of query load were jobs that got deprecated in the next quarterly baseline.

It felt a system was needed to allocate query resource to teams, some kind of tradeable tokens that were scarce maybe, to incentivise more care and consciousness of the resource from the many users.

What we did was have a few levels of priority managed by a central org. It resulted in a lot of churn and hectares of indiscriminately killed query jobs every week, many that had business importance mixed in with the zombies.

Re: Use one big server

#462

Post by [deleted] » Wed, Aug 03, 2022, 5:41 AM UTC

cogman10 wrote: post #342

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. > 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 to combine these data sources (they don't know how your distributed databases look, and oftentimes they really do not care). This works until it doesn't and then you land in the position…

[deleted]

Re: Use one big server

#463

Post by [deleted] » Wed, Aug 03, 2022, 5:48 AM UTC

AtNightWeCode wrote: post #210

Closi wrote: post #61

Earlier quoted context omitted.

Breaking apart a stateless microservice and then basing it around a giant single monolithic database is pretty pointless - at that stage you might as well just build a monolith and get on with it as every microservice is tightly coupled to the db.

Agree. Nothing worse than having different programs changing data in the same database. The database should not be an integration point between services.

[deleted]

Re: Use one big server

#464

Post by fsdghrth3 » Wed, Aug 03, 2022, 6:12 AM UTC

Reading these comments make me sad. It's like everyone has forgotten the cookie cutter server architecture pattern.

https://dzone.com/articles/monoliths-cookie-cutter-or

I really don't understand microservices for most businesses. They're great if you put the effort into it but most business don't have the scale required.

Big databases and big servers serve most businesses just fine. And past that NFS and other distributed filesystem approaches get you to the next phase by horizontally scaling your app servers without needing to decompose your business logic into microservices.

The best approach I've ever seen is a monorepo codebase with non-micro services built into it all running the same way across every app server with a big loadbalancer in front of it all.

Re: Use one big server

#465

Post by tablespoon » Wed, Aug 03, 2022, 6:14 AM UTC

sanderjd wrote: post #421

throwfh80h82 wrote: post #406

Earlier quoted context omitted.

I can share some. Had a similar experience as the parent comment. I do support "one big database" but it requires a dedicated db admin team to solve the tragedy of the commons problem. Say you have one big database. You have 300 engineers and 30-50 product managers shipping new features every day accountable to the C-Suite. They are all writing queries to retrieve the data they want. One more join, one more N+1 query…

I think this hits the nail right on the head, and it's the same criticism I have of and article itself: the framing is that you split up a database or use small vms or containers for performance reasons, but that's not the primary reason these things are useful; they are useful for people scaling first and foremost, and for technical scaling only secondarily. The tragedy of the commons with one big shared database is…

> Defining service boundaries and APIs with clarity around backwards compatibility is a good solution.

Can't you do that with one big database? Every application gets an account that only gives it access to what it needs. Treat database tables as APIs: if you want access to someone else's, you have to negotiate to get it, so it's known who uses what. You don't have to have one account with access to everything that everyone shares. You could

Re: Use one big server

#466

Post by GeorgeDewar » Wed, Aug 03, 2022, 6:27 AM UTC

lmm wrote: post #458

lazide wrote: post #455

Earlier quoted context omitted.

It's resource intensive - but so is being in a giant tarpit/morass. Adding client query logging is cheaper and can be distributed. I just double checked, and neither Oracle nor Postgres warn 'never use it in production' And if you have logs, you can see what actually gets queried, and by whom, and what doesn't get queried, and by whom. That will also potentially let you start constructing views and moving actual unde…

> It's resource intensive - but so is being in a giant tarpit/morass. Agreed, but it means it's not really a viable option for digging yourself out of that hole if you're already in it. Most of the time if you're desperately trying to split up your database it's because you're already hitting performance issues. > Adding client query logging is cheaper and can be distributed. Right, but that only works if you've got…

If you are in the hole where you really cannot add load to your database server but want to log the queries, there is a technique called zero impact monitoring where you literally mirror the network traffic going to your database server, and use a separate server to reconstruct it into query logs. These logs identify the queries that are being run, and critically, who/what is running them.

A past workplace of mine has used this approach.

Re: Use one big server

#467

Post by anonymousDan » Wed, Aug 03, 2022, 6:27 AM UTC

adam_arthur wrote: post #260

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…

As someone who has only dabbled with serverless (Azure functions), the difficulty in setting up a local dev environment was something I found really off-putting. There is no way I am hooking up my credit card to test something that is still in development. It just seems crazy to me. Glad to hear Cloudflare workers provides a better experience. Does it provide any support for mocking commonly used services?

Re: Use one big server

#468

Post by nntp86 » Wed, Aug 03, 2022, 6:31 AM UTC

MockObject wrote: post #279

stevenjgarner wrote: post #65

Earlier quoted context omitted.

It depends on the scale - it does not have to be a major undertaking. You are right, it is a whole extra competency and a major customer support commitment , but for a lot of the entrepreneurial folk on HN quite a rewarding and accessible learning experience. The first time I did anything like this was in late 1984 in a small town in Iowa where GTE was the local telecommunication utility. Absolutely abysmal Internet…

In 1984, I am guessing the only use case for broadband internet was running an NNTP server?

NNTP wasn't a thing until 1986

Re: Use one big server

#469

Post by diffeomorphism » Wed, Aug 03, 2022, 6:35 AM UTC

throwaway787544 wrote: post #16

I have been doing this for two decades. Let me tell you about bare metal. Back in the day we had 1,000 physical servers to run a large scale web app. 90% of that capacity was used only for two months. So we had to buy 900 servers just to make most of our money over two events in two seasons. We also had to have 900 servers because even one beefy machine has bandwidth and latency limits. Your network switch simply can…

> If you don't want to learn new things, buy one big server. I just pray it doesn't go down for you

You are taking this a bit too literally. The article itself says one server (and backups). So "one" here just means a small number not literally no fallback/backup etc. (obviously... even people you disagree with are usually not morons)

Re: Use one big server

#470

Post by gbro3n » Wed, Aug 03, 2022, 6:45 AM UTC

Being too cloudy without being too cloudy, as per the article, I've gone with a full stack in containers under Docker Compose one one EC2 server, including the database. Services are still logically separated and have a robust CI/CD set up but the cost is a 3rd of what an ECS set up with load balancers and RDS for the database would have been. It's also simpler. Have scripted the server set up, with regular back ups / snapshots but admit I would like db replication in there.