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

71–80 of 601 posts

Re: Use one big server

#71

Post by ustolemyname »

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.

Re: Use one big server

#72

Post by roflyear »

rubiquity wrote: post #39
reillyse wrote: post #12

Nope. Multiple small servers. 1) 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. 2) having multiple small servers allows us to spread our service into different availability zones 3) multiple small servers allows us to do rolling deploys without bringing down our entire se…

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…

I agree! Our "distributed cloud database" just went down last night for a couple of HOURS. Well, not entirely down. But there were connection issues for hours.

Guess what never, never had this issue? The hardware I keep in a datacenter lol!

Re: Use one big server

#73

Post by ozim »

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.

So it does not really work in B2B.

I don't really have much to do with contracts - but my company is stating that we have up time of 99.xx%.

In terms of contract customers don't care if I have Azure/AWS or I keep my server in the box under the stairs. Yes they do due diligence and would not buy my services if I keep it in shoe box.

But then if they loose business they come to me .. I can go after Azure/AWS but I am so small they will throw some free credits and me and tell to go off.

Maybe if you are in B2C area then yeah - your customers will probably shrug and say it was M$ or Amazon if you write sad blog post with excuses.

Re: Use one big server

#74

Post by ryanisnan »

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…

Definitely use a big database, until you can't. My advice to anyone starting with a relational data store is to use a proxy from day 1 (or some point before adding something like that becomes scary).

When you need to start sharding your database, having a proxy is like having a super power.

Re: Use one big server

#75

Post by roflyear »

kubb wrote: post #3

As per usual, don't copy Google if you don't have the same requirements. Google Search never goes down. HN goes down from time and nobody minds. Google serves tens (hundreds?) of thousands of queries per second. HN serves ten. HN is fine with one server because it's small. How big is your service going to be? Do that boring math :)

Correct. I like to ask "how much money do we lose if the site goes down for 1hr? a day?" etc.. and plan around that. If you are losing 1m an hour, or 50m if it goes down for a day, hell yeah you should spend a few million on making sure your site stays online!

But, it is amazing how often c-levels cannot answer this question!

Re: Use one big server

#76

Post by andrepew »

ozim wrote: post #73
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.

So it does not really work in B2B. I don't really have much to do with contracts - but my company is stating that we have up time of 99.xx%. In terms of contract customers don't care if I have Azure/AWS or I keep my server in the box under the stairs. Yes they do due diligence and would not buy my services if I keep it in shoe box. But then if they loose business they come to me .. I can go after Azure/AWS but I am s…

Depends on scale of B2B. Between enterprises, not as much. Between small businesses, works very well (at least in my experience, we are tiny B2B).

Re: Use one big server

#77

Post by softfalcon »

Nextgrid wrote: post #44
softfalcon wrote: post #37

So... I guess these folks haven't heard of latency before? Fairly sure you have to have "one big server" in every country if you do this. I feel like that would get rather costly compared to geographically distributed cloud services long term.

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 containers to k8s all over the world works very well for us.

Before you give me the "oh k8s, well you don't know bare metal" please note that I'm an old hat that has done the legacy C# ASP.NET IIS workflows on bare metal for a long time. I have learned and migrated to k8s on AWS/GCloud and it is a huge improvement compared to what I used to deal with.

Lastly, as for your CDN discussion, we don't just host CDN's globally. We also host geo-located DB + k8s pods. Our service uses web sockets and latency is a real issue. We can't have 500 ms ping if we want to live update our client. We choose to host locally (in what is usually NOT a small server) so we get optimal ping for the live-interaction portion of our services that are used by millions of people every day.

Re: Use one big server

#78

Post by radu_floricica »

Closi wrote: post #61
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…

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.

To note that quite a bit of the performance problems come when writing stuff. You can get away with A LOT if you accept 1. the current service doesn't do (much) writing and 2. it can live with slightly old data. Which I think covers 90% of use cases.

So you can end up with those services living on separate machines and connecting to read only db replicas, for virtually limitless scalability. And when it realizes it needs to do an update, it either switches the db connection to a master, or it forwards the whole request to another instance connected to a master db.

Re: Use one big server

#79

Post by cdkmoose »

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…

>>(they don't know how your distributed databases look, and oftentimes they really do not care)

Nor should they, it's the engineer's/team's job to provide the database layer to them with high levels of service without them having to know the details

Post reply on HN