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

531–540 of 601 posts

Re: Use one big server

#531

Post by gwbas1c »

sanderjd wrote: post #425

I didn't want to write a top-level comment and I'm sure few people will see this, but I scrolled down very far in this thread and didn't see this point made anywhere: The article focuses almost entirely on technical questions, but the technical considerations are secondary; the reason so many organizations prefer cloud services, VMs, and containers is to manage the challenges of scaling organizationally, not technica…

I agree with almost everything you said; except that the article offers extremely valuable advice for small startups going the cloud / rented VM route: Yearly payments, or approaching a salesperson, can lead to much lower costs.

(I should point out that yesterday, in Azure, I added a VM in a matter of seconds and it took all of 15 minutes to boot up and start running our code. My employer is far too small to have dedicated ops; the cost of cloud VMs is much cheaper than hiring another ops / devops / whatever.)

Re: Use one big server

#532

Post by strgcmc »

fleddr wrote: post #527
lukeramsden wrote: post #490

Earlier quoted context omitted.

We're much more like artisans than engineers, in my opinion (maybe with the exception of extremely deep-in-the-stack things like compiler engineering). The problem seems to be that because there's no "right way", only wrong ways, discussions end up being circular. I'm not a civil engineer, but I imagine there is a "best way" to build a bridge in any landscape, where any decisions and tradeoffs have well defined param…

I get what you're saying but I reject the notion that some of these tech choices are 100% subjective and that there's no "right way" at all. If hardware has increased in speed/capacity by a factor 10-100 in a decade and our "accomplishment" is to actually make software increasingly slow, shitty and bloated with no new added value to the user, you'll have an idea of the absurd waste and efficiency of our stacks.

When you add lanes to a highway, it generally does not improve congestion or travel times. Drivers adjust and fill up the new lanes, until travel times are roughly the same as before (but with slightly more throughput now).

So it is with hardware and software. I don't see any reason to correlate faster/better hardware with an expectation that software must also get better. It would be economically irrational for the software industry (whatever that means) to spend resources/energy on improving efficiency when the "gains" from hardware are essentially a free lunch to eat... Who would pay for lunch or spend time making their own, when hardware guys are giving you bigger portions for free?

That doesn't mean you have to like the outcome, but at least it should be perfectly predictable, given what we know about economics and game theory and incentives.

Re: Use one big server

#533

Post by bigtunacan »

Aeolun wrote: post #509
bigtunacan wrote: post #450

Earlier quoted context omitted.

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

It's been a long time since I've used Mongo so I don't know if it only supports eventual consistency, but DynamoDB does support transactions and traditional consistency, but it comes at the cost of reduced read throughput.

DynamoDB also supports relations, but they aren't called relations because they don't resemble anything like relations in traditional relational databases.

You may already know this, but just to clarify DynamoDB isn't really a document oriented database. It's both a key/value database and a columnar database, so in that sense I'd closer to Redis and Cassandra than Mongo, but there's definitely a lot of misinformation on this front.

Re: Use one big server

#534

Post by strgcmc »

fleddr wrote: post #528
throwawaylinux wrote: post #430

Earlier quoted context omitted.

> Software engineers: let's completely undo all that engineering by moving everything apart as far as possible. Hmmm, still too fast. Let's next add virtualization and software stacks with shitty abstractions. That's because the concept which is even more impactful than agriculture and the computer, and makes them and everything else in our lives, is abstraction. It makes it possible to reason about large and difficu…

None of that means anything. The web is slower than ever. Desktop apps 20 years ago were faster than today's garbage. We failed.

Billions of people are on the internet now, vs 20 years ago. I dare say millions of lives have been saved (due to various things) in the past 20 years, due to the things built and deployed on the web.

We may have failed at some abstract notion of craftsmanship or performance efficiency. But we as an industry shipped. We shipped a lot, actually. A lot of it also sucked. But not enough to say the whole industry was a failure, IMHO.

Re: Use one big server

#535

Post by throwawaylinux »

fleddr wrote: post #528
throwawaylinux wrote: post #430

Earlier quoted context omitted.

> Software engineers: let's completely undo all that engineering by moving everything apart as far as possible. Hmmm, still too fast. Let's next add virtualization and software stacks with shitty abstractions. That's because the concept which is even more impactful than agriculture and the computer, and makes them and everything else in our lives, is abstraction. It makes it possible to reason about large and difficu…

None of that means anything. The web is slower than ever. Desktop apps 20 years ago were faster than today's garbage. We failed.

> None of that means anything.

What are you having difficulty understanding? I'll be happy to try help.

> The web is slower than ever.

No it isn't.

> Desktop apps 20 years ago were faster than today's garbage.

Some are, some aren't. For the same thing they clearly aren't. A typewriter makes your PC of 20 years ago look glacial garbage, if that's your standard.

> We failed.

Speak for yourself. Computers are used far more often, for more things, and by more people than they were 20 years ago, and nothing they used to be used for has been replaced by something else. You'll always have the get off my lawn types, but you did in the 2000s from the curmudgeons stuck in the 80s too.

Re: Use one big server

#536

Post by [deleted] »

journey_16162 wrote: post #492
hot_gril wrote: post #361

The way I code now after 10 years: Use one big file. No executable I'm capable of writing on my own is complex enough to need 50 files spread across a 3-layers-deep directory tree. Doesn't matter if it's a backend, a UI, or what. There's no way your React or whatever tutorial example code needs that either. And you don't gain any meaningful organization splitting into files when there are already namespaces, classes,…

Reminds me of a company I used to work at which took a similar approach. We used one file per person policy, each developer had their own file that contained functionality developed by them, named like firstName_lastName.ext - everyone owned their file so we didn't have to worry about merge conflicts.

[deleted]

Re: Use one big server

#537

Post by maxbond »

NorwegianDude wrote: post #259
maxbond wrote: post #195

Earlier quoted context omitted.

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

"Hitting the front page of Reddit" is a metanym for, "today you suddenly have many multiples of the previous day's traffic banging down your door, for reasons entirely outside of your control or ability to foresee." I agree this is a huge revenue opportunity - but if you can't stay up, you may not be able to capitalize on it.

This & sibling comments seem to imagine that every application is some special case of static web hosting, and if that is the domain you're working in I can see how you may be able to cheaply over provision to the point where you don't really worry about downtime. If you don't need distributed computing, definitely don't apply distributed computing to your problem and you'll have a cheaper and better time. I'm not some kind of cloud maximalist; if you're telling me you've done some diligence for your application and it's better off at Hetzner, sure, I believe it.

I'm pretty skeptical that this is most applications, however. Consider a browser based MMORPG where each interaction in the game will fire off one or many requests, and each player interacts several times a second. If hitting the front page results in hundreds of new players, it's easy to imagine having thousands of QPS.

Re: Use one big server

#538

Post by maxbond »

genousti wrote: post #296
maxbond wrote: post #195

Earlier quoted context omitted.

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.

Funily hitting reddit front page might ruin you if you run on aws

With great power comes great responsibility. When I start to learn a new cloud service, I definitely start with the billing, limits, and quotas. Concern here is definitely warranted. It's a bit like programming in C, there are some seatbelts but they're not absolutely guaranteed to work, and it's ultimately on you to do it right. I'd love to see this get much safer.

However, the corollary of this is; without this responsibility, you don't have access to the great power.

Re: Use one big server

#539

Post by lolinder »

oceanplexian wrote: post #140
andrepew wrote: post #32

Earlier quoted context omitted.

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.

I hear this repeated so many times at my workplace, and it's so totally and completely uninformed. Customers who have invested millions of dollars into making their stack multi-region, multi-cloud, or multi-datacenter aren't going to calmly accept the excuse that "AWS Went Down" when you can't deliver the services you contractually agreed to deliver. There are industries out there where having your service casually g…

> I hear this repeated so many times at my workplace, and it's so totally and completely uninformed.

> Customers who have invested millions of dollars into making their stack multi-region, multi-cloud, or multi-datacenter...

It sounds like the idea may be bad for your workplace, but that doesn't make it uninformed here. For the average B2C or business-to-small-business application, the customer doesn't even know what a region or datacenter is, all they know is that "the internet" isn't working and your service went down with it. These customers also don't have an SLA with guaranteed uptimes. The only thing they agreed to were the Terms and Conditions that explicitly say "no warranty, express or implied".

If you're selling to large enterprises, yeah, "AWS went down" won't cut it. But in most other cases it will.

Re: Use one big server

#540

Post by loxias »

Aeolun wrote: post #509
bigtunacan wrote: post #450

Earlier quoted context omitted.

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

Would a hybrid key-value & document store, indices on any user defined path, with optional strong consistency DWYW?
Post reply on HN