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

101–110 of 601 posts

Re: Use one big server

#101

Post by Guid_NewGuid »

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 think a strong test a lot of "let's use Google scale architecture for our MVP" advocates fail is: can your architecture support a performant paginated list with dynamic sort, filter and search where eventual consistency isn't acceptable?

Pretty much every CRUD app needs this at some point and if every join needs a network call your app is going to suck to use and suck to develop.

Re: Use one big server

#102

Post by jedberg »

I'm a huge advocate of cloud services, and have been since 2007 (not sure where this guy got 2010 as the start of the "cloud revolution"). That out of the way, there is something to be said for starting off with a monolith on a single beefy server. You'll definitely iterate faster.

Where you'll get into trouble is if you get popular quickly. You may run into scaling issues early on, and then have to scramble to scale. It's just a tradeoff you have to consider when starting your project -- iterate quickly early and then scramble to scale, or start off more slowly but have a better ramping up story.

One other nitpick I had is that OP complains that even in the cloud you still have to pay for peak load, but while that's strictly true, it's amortized over so many customers that you really aren't paying for it unless you're very large. The more you take advantage of auto-scaling, the less of the peak load you're paying. The customers who aren't auto-scaling are the ones who are covering most of that cost.

You can run a pretty sizable business in the free tier on AWS and let everyone else subsidize your peak (and base!) costs.

Re: Use one big server

#103

Post by bilekas »

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…

I can't tell if this is a good thing or a bad thing though!

Imagine the clout of saying : "we stayed online while AWS died"

Re: Use one big server

#104

Post by rmbyrro »

altdataseller wrote: post #93
belak wrote: post #64

Earlier quoted context omitted.

This is absolutely true - when I was at Bitbucket (ages ago at this point) and we were having issues with our DB server (mostly due to scaling), almost everyone we talked to said "buy a bigger box until you can't any more" because of how complex (and indirectly expensive) the alternatives are - sharding and microservices both have a ton more failure points than a single large box. I'm sure they eventually moved off t…

What if your product simply stores a lot of data (ie a search engine) How is that weird?

a search engine won't need joins, but other things (ie text indexing) that can be split in a relatively easier way.

Re: Use one big server

#105

Post by MrStonedOne »

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…

i handled a 8x increase in traffic to my website from a youtuber reviewing our game, by increasing the cache timer and fixing the wiki creating session table entries for logged out users on a wiki that required accounts to edit it.

we already get multiple millions of page hits a months for this happened.

This server had 8 cores but 5 of them were reserved for the 10tb a month in bandwidth game servers running on the same machine.

If you needed 1,000 physical computers to run your webapp, you fucked up somewhere along the line.

Re: Use one big server

#106

Post by rmbyrro »

jedberg wrote: post #102

I'm a huge advocate of cloud services, and have been since 2007 (not sure where this guy got 2010 as the start of the "cloud revolution"). That out of the way, there is something to be said for starting off with a monolith on a single beefy server. You'll definitely iterate faster. Where you'll get into trouble is if you get popular quickly. You may run into scaling issues early on, and then have to scramble to scale…

Isn't this simplistic?

It really depends on the service, how it is used, the shape of the data generated/consumed, what type of queries are needed, etc.

I've worked for a startup that hit scaling issues with ~50 customers. And have seen services with +million users on a single machine.

And what does "quickly" and "popular" even mean? It also depends a lot on the context. We need to start discussing about mental models for developers to think of scaling in a contextual way.

Re: Use one big server

#108

Post by zasdffaa »

altdataseller wrote: post #93
belak wrote: post #64

Earlier quoted context omitted.

This is absolutely true - when I was at Bitbucket (ages ago at this point) and we were having issues with our DB server (mostly due to scaling), almost everyone we talked to said "buy a bigger box until you can't any more" because of how complex (and indirectly expensive) the alternatives are - sharding and microservices both have a ton more failure points than a single large box. I'm sure they eventually moved off t…

What if your product simply stores a lot of data (ie a search engine) How is that weird?

Depends what you mean by a database I guess. I take it to mean an RDBMS.

RDBMSs provide guarantees that web searching doesn't need. You can afford to lose a pieces of data, provide not-quite-perfect results for web stuff. It's just wrong for an RDBMS.

Re: Use one big server

#109

Post by Nextgrid »

softfalcon wrote: post #77
Nextgrid wrote: post #44

Earlier quoted context omitted.

As opposed, to "many small servers" in every country? The vast majority of startups out there run out of a single AWS region with a CDN caching read-only content. You can apply the same CDN approach to a bare-metal server.

Yeah, but if I'm a startup and running only a small server, the cloud hosting costs are minimal. I'm not sure how you think it's cheaper to host tiny servers in lots of countries and pay someone to manage that for you. You'll need IT in every one of those locations to handle the service of your "small servers". I run services globally for my company, there is no way we could do it. The fact that we just deploy contai…

> the cloud hosting costs are minimal

Disagreed. The cloud equivalent of a small server is still a few hundred bucks a month + bandwidth. Sure, it's still a relatively small cost but you're still overpaying significantly over the Hetzner equivalent which will be sub-$100.

> pay someone to manage that for you

The same guy that manages your AWS can do this. Having bare-metal servers doesn't mean renting colo space and having people on-site - you can get them from Hetzner/OVH/etc and they will manage all the hardware for you.

> The fact that we just deploy containers to k8s all over the world works very well for us.

It's great that it works well for you and I am in no way suggesting you should change, but I wouldn't say it would apply to everyone - the cloud adds significant costs with regards to bandwidth alone and makes some services outright impossible with that pricing model.

> We also host geo-located DB

That's a complex use-case that's not representative of most early/small SaaS which are just a CRUD app backed by a DB. If your business case requires distributed databases and you've already done the work, great - but a lot of services don't need that (at least not yet) and can do just fine with a single big DB server + application server and good backups, and that will be dirt-cheap on bare-metal.

Re: Use one big server

#110

Post by xen2xen1 »

stevenjgarner wrote: post #36
erichocean wrote: post #20

Earlier quoted context omitted.

> it is quite easy and cheap to register as a public telecommunication utility Is North Carolina one of those states? I'm intrigued…

I have only done a few midwestern states. Call them and ask [0] - (919) 733-7328. You may want to first call your proposed county commissioner's office or city hall (if you are not rural), and ask them who to talk with about a new local business providing Internet service. If you can show the Utilities Commission that you are working with someone at the local level I have found they will treat you more seriously. In…

What other benefits are there to being a "public telecommunication utility"?
Post reply on HN