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

501–510 of 601 posts

Re: Use one big server

#501

Post by Wicher »

cerved wrote: post #471
tablespoon wrote: post #465

Earlier quoted context omitted.

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

Schemas can be useful in this regard

Indeed! And functions with security definers can be useful here too. With those one can define a very strict and narrow API that way, with functions that write or query tables that users don't have any direct access to.

Look at it as an API written in DB functions, rather than in HTTP request handlers. One can even have neat API versioning through, indeed, the schema, and give different users (or application accounts) access to different (combinations of) APIs.

The rest is "just" a matter of organizational discipline, and a matter of teams to internalize externalities so that it doesn't devolve into a tragedy of the commons — a phenomenon that occurs in many shapes, not exclusively in shared databases; we can picture how it can happen for unfettered access to cloud resources just as easily.

But here's the common difference: through the cloud, there's clear accounting per IOP, per TB, per CPU hour, so incentive to use resources efficiently is can be applied on a per-team basis — often through budgeting. "Explain to me why your team uses 100x more resources than this other team" / "Explain to me why your team's usage has increased 10-fold in three months".

Yet there's no reason to think that you can only get accounting for cloud stuff. You could have usage accounting on your shared DB. Does anyone here have experience with any kind of usage accounting system for, say, PostgreSQL?

Re: Use one big server

#502

Post by Tainnor »

tsmarsh wrote: post #245
BenoitEssiambre wrote: post #226

Earlier quoted context omitted.

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…

'over the wire' is less obvious than it used to be. If you're in k8s pod, those calls are really kernel calls. Sure you're serializing and process switching where you could be just making a method call, but we had to do something. I'm seeing less 'balls of mud' with microservices. Thats not zero balls of mud. But its not a given for almost every code base I wander into.

> I'm seeing less 'balls of mud' with microservices.

The parallel to "balls of mud" with microservices is tiny services that seem almost devoid of any business logic and all the actual business logic is encapsulated in the calls between different services, lambda functions, and so on.

That's quite nightmarish from a maintenance perspective too, because now it's almost impossible to look at the system from the outside and understand what it's doing. It also means that conventional tooling can't help you anymore: you don't get compiler errors if your lambda function calls an endpoint that doesn't exist anymore.

Big balls of mud are horrible (I'm currently working with a big ball of mud monolith, I know what I'm talking about), but you can create a different kind of mess with microservices too. Then there all the other problems, such as operational complexity, or "I now need to update log4j across 30 services".

In the end, a well-engineered system needs disciple and architectural skills, as well as a healthy engineering culture where tech debt can be paid off, regardless of whether it's a monolith, a microservice architecture or something in between.

Re: Use one big server

#503

Post by dijit »

flatiron wrote: post #130
phkahler wrote: post #120

Earlier quoted context omitted.

>> AWS going down is treated like an act of god rendering everyone blameless. Someone decided to use AWS, so there is blame to go around. I'm not saying if that blame is warranted or not, just that it sounds like a valid thing to say for people who want to blame someone.

“Nobody gets fired for using aws” is pretty big now a days. We use GCP but if they have an issue and it bubbles down to me nobody bats an eye when I say the magical cloud man made ut oh whoopsie and it wasn’t me.

That’s because your CTO is getting raked over the coals.

They just think it’s something they can justify- cloud is synonymous with velocity and the perception of lower staffing costs.

A little bit of unavailability is seen as a fair trade off.

This is my impression as a c-level.

Re: Use one big server

#504

Post by bluehatbrit »

SassyGrapefruit wrote: post #221

>Use the Cloud, but don’t be too Cloudy The number of applications I have inherited that were messes falling apart at the seams because of misguided attempts to avoid "vendor lockin" with the cloud can not be understated. There is something I find ironic about people paying to use a platform but not using it because they feel like using it too much will make them feel compelled to stay there. Its basically starving y…

Aggressively avoiding lock-in is something I've never quite understood. Unless your provider of choice is also your competitor (like Spotify with Amazon) it shouldn't really be a problem. I'm not saying I'm a die hard cloud fan in all aspects but if you're going with it you may as well use it. Typically trying to avoid vendor lockin really ends up more expensive in the long run, you start avoiding the cheaper services (lambda for background job processing) for what may never really be a problem.

The one place I can see avoiding vendor lock-in as really useful is it often makes running things locally much easier. You're kind of screwed if you want to properly run something locally that uses SQS, DynamoDB, and Lambda. But that said, I think this is often better thought of as "keep my system simple" rather than "avoid vendor lock-in" as it focuses on the valuable side rather than the theoretical side.

Re: Use one big server

#505

Post by bluehatbrit »

wiremine wrote: post #415

I see these debates and wish there was an approach that scaled better. A single server (and a backup) really _is_ great. Until it's not, for whatever reason. We need more frameworks that scale from a single box to many boxes, without starting over from scratch. There are a lot of solid approaches: Erlang/Elxir and the actor model comes to mind. But that approach is not perfect, and it's far from common place.

> We need more frameworks that scale from a single box to many boxes, without starting over from scratch.

I'm not sure I really understand what you're saying here. I suppose most applications are some kind of CRUD app these days, not all sure, but an awful lot. If we take that as an example, how is it difficult to go from one box to multiple?

It's not something you get for free, you need to put in time to provision any new infra (be it baremetal or some kind of cloud instance) but the act of scaling out is pretty straight forward.

Perhaps you're talking about stateful applications?

Re: Use one big server

#506

Post by julianbuse »

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…

I'm not sure if you know this, and it might not be useful to you even if you do, but workers can interact with the cache directly: https://developers.cloudflare.com/workers/runtime-apis/cache...

Re: Use one big server

#507

Post by Aeolun »

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…

> Once you get to that point, it becomes SUPER hard to start splitting things out.

Maybe, but if you split it from the start you die by a thousand cuts, and likely pay the cost up front, even if you’d never get to the volumes that’d require a split.

Re: Use one big server

#508

Post by gizzlon »

reillyse wrote: post #111
rubiquity wrote: post #39

Earlier quoted context omitted.

The line of thinking you follow is what is plaguing this industry with too much complexity and simultaneously throwing away incredible CPU and PCIe performance gains in favor of using the network. Any technical decisions about how many instances to have and how they should be spread out needs to start as a business decision and end in crisp numbers about recovery point/time objections, and yet somehow that nearly nev…

Ok, so to your points. "It depends" is the correct answer to the question, but the least informative. One Big Server or multiple small servers? It depends. It always depends. There are many workloads where one big server is the perfect size. There are many workloads where many small servers are the perfect solution. What my point is, is that the ideas put forward in the article are flawed for the vast majority of use…

> All in I'm well under $200 per month including database.

You forgot all the crucial numbers.. Like QPS.. My blog runs on 0 to 1 Cloud Run instances and costs < 3$ per month, including database

Re: Use one big server

#509

Post by Aeolun »

bigtunacan wrote: post #450
bigtunacan wrote: post #431

Earlier quoted context omitted.

You're not wrong. Probably more than 95% of applications will never outgrow one large relational database. I just think that this leads to an unfortunate, but mostly inevitable issue of complexity for the few that do hit such a level of success and scale. Alex DeVrie (author of 'The DynamoDB Book') discusses that his approach is to essentially start all new projects with DynamoDB. Now I don't really agree with him, y…

@ithrow, yeah I know he is clearly biased which is why I don't really agree with him. I do however think it would have helped me to start using/learning before I needed it since the paradigm is so foreign to the relational model that is now second nature.

DynamoDB (and Mongo) is nice, right up until you need those relations. I haven’t found a document oriented database that gives me the consistency guarantees of a RDBMS yet.

Re: Use one big server

#510

Post by Aeolun »

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…

> Teams not having the flexibility to evolve their own schemas because they have no idea who depends on them

This sounds like a problem of testing and organization to me, not a problem with single big databases.

Post reply on HN