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

91–100 of 601 posts

Re: Use one big server

#91

Post by johnbellone »

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 agree with this sentiment but it is often misunderstood as a means to force everything into a single database schema. More people need to learn about logically separating schemas with their database servers!

Re: Use one big server

#92

Post by lliamander »

dugmartin wrote: post #4

I think Elixir/Erlang is uniquely positioned to get more traction in the inevitable microservice/kubernetes backlash and the return to single server deploys (with a hot backup). Not only does it usually sip server resources but it also scales naturally as more cores/threads are available on a server.

Going from an Erlang "monolith" to a java/k8s cluster, I was amazed at how much more work it is takes to build a "modern" microservice. Erlang still feels like the future to me.

Re: Use one big server

#93

Post by altdataseller »

belak wrote: post #64
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…

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?

Re: Use one big server

#94

Post by ansible »

rlpb wrote: post #55
porker wrote: post #23

I like One Big (virtual) Server until you come to software updates. At a current project we have one server running the website in production. It runs an old version of Centos, the web server, MySQL and Elasticsearch all on the one machine. No network RTTs when doing too many MySQL queries on each page - great! But when you want to upgrade one part of that stack... we end up cloning the server, upgrading it, testing…

You could just run system containers (eg. lxd) for each component, but still on one server. That gets you multiple "servers" for the purposes of upgrades, but without the rest of the paradigm shift that Docker requires.

I use LXC a lot for our relatively small production setup. And yes, I'm treating the servers like pets, not cattle.

What's nice is that I can snapshot a container and move it to another physical machine. Handy for (manual) load balancing and upgrades to the physical infrastructure. It is also easy to run a snapshot of the entire server and then run an upgrade, then if the upgrade fails, you roll back to the old snapshot.

Re: Use one big server

#95

Post by Koshkin »

ericd wrote: post #41
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…

On a big server, you would probably be running VMs rather than serving directly. And then it becomes easy to do most of what you're talking about - the big server is just a pool of resources from which to make small, single purpose VMs as you need them.

Why VMs when you can use containers?

Re: Use one big server

#96

Post by bob1029 »

bombcar wrote: post #70
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…

> 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 never happens. Nobody wants to admit that their business or their department actually has a SLA of "as soon as you can, maybe tomorrow, as long as it usually works". So everything is pretend-enginee…

> Nobody wants to admit that their business or their department actually has a SLA of "as soon as you can, maybe tomorrow, as long as it usually works". So everything is pretend-engineered to be fifteen nines of reliability (when in reality it sometimes explodes because of the "attempts" to make it robust).

I have yet to see my principal technical frustrations summarized so concisely. This is at the heart of everything.

If the business and the engineers can get over their ridiculous obsession of statistical outcomes and strict determinism, they would be able to arrive at a much more cost effective, simple and human-friendly solution.

The # of businesses that are actually sensitive to >1 minute of annual downtime are already running on top of IBM mainframes and have been for decades. No one's business is as important as the federal reserve or pentagon, but they don't want to admit it to themselves or others.

Re: Use one big server

#97

Post by MrStonedOne »

/tg/station, the largest open source multiplayer video game on github, gets cloudheads trying to help us "modernize" the game server for the cloud all the time.

Here's how that breaks down:

The servers (sorry, i mean compute) cost the same (before bandwidth, more on that at the bottom) to host one game server as we pay (amortized) per game server to host 5 game servers on a rented dedicated server. ($175/month for the rented server with 64gb of ram and a 10gbit uplink)

They run twice as slow because high core count slow clock speed servers aren't all they are cracked up to be, and our game engine is single threaded, but even if it wasn't, there is an overhead to multithreading things which combined with most high core count servers also having slow clock speed, rarely squares out to an actual increase in real world performance.

You can get the high clock speed units, they are twice to three times as expensive. And still run 20% slower over windows vms on rented bare metal because the sad fact is enterprise cpus by either intel or amd have slower clock speeds and single threaded performance then their gaming cpu counterparts, and getting gaming cpus for rented servers is piss easy, but next to impossible for cloud servers.

Each game server uses 2tb of bandwidth to host 70 player high pops. This works with 5 servers on 1 machine because our hosting provider gives us 15tb of bandwidth included in the price of the server.

Well now the cloud bill just got a new 0. 10 to 30x more expensive once you remember to price in bandwidth isn't looking too great.

"but it would make it cheaper for small downstreams to start out" until another youtuber mentions our tiny game, and every game server is hitting the 120 hard pop cap, and a bunch of downstreams get a surprise 4 digit bill for what would normally run 2 digits.

The take away from this being that even adding in docker or k8s deployment support to the game server is seen as creating the risk some kid bankrupts themselves trying to host a game server of their favorite game off their mcdonalds paycheck, and we tell such tech "pros" to sod off with their trendy money wasters.

Re: Use one big server

#98

Post by bilekas »

I don't agree with EVERYTHING in the article such as getting 2 big rather than multiple smaller, this is really just a cost/requirement issue though.

The biggest cost I've noticed with enterprises who go full cloud is that they are locked in for the long term. I don't mean contractually though, basically the way they design and implement any system or service MUST follow the providers "way" this can be very detrimental for leaving the provider or god forbid the provider decides to sunset certain service versions etc.

That said, for enterprise it can make a lot of sense and the article covers it well by admitting some "clouds" are beneficial.

For anything I've ever done outside of large businesses the go to has always been "if it doesn't require a SRE to maintain, just host your own".

Re: Use one big server

#99

Post by malkia »

It was all good, until NUMA came, and now you have to careful rethought your process, or you get lots of performance issues in your (otherwise) well threaded code. Speaking from first-hand experience, when our level editor ended up being used by artists on a server class machine, and supposedly 4x faster machine was actually going 2x slower (why, lots of std::shared_ptr use on our side, or any atomic reference counting) caused slowdowns, as the cache (my understanding) had to be synchronized between the two physical CPUs each having 12 threads.

But really not the only issue, just pointing out - that you can't expect everything to scale smoothly there, unless well thought, like ask your OS to allocate your threads/memory only on one of the physical CPUS (and their threads), and somehow big disconnected part of your process(es) on the other one(s), and make sure the communication between them is minimal.. which actually wants micro-services design again at that level.

so why not go with micro-services instead...

Re: Use one big server

#100

Post by kkielhofner »

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…

You don't need IT in every location or even different hosting facility contracts. Most colo hosting companies have multiple regions. From the 800lb gorilla (Equinix):

https://www.equinix.com/data-centers

Or a smaller US focused colo provider:

https://www.coresite.com/data-centers/locations

Between vendor (Dell, HP, IBM, etc) and the remote hands offered by the hosting facility you don't ever have to have a member of your team even enter a facility. Anywhere. Depending on the warranty/support package the vendor will dispatch someone to show up to the facility to replace failed components with little action from you.

The vendor will be happy to ship the server directly to the facility (anywhere) and for a nominal fee the colo provider will rack it and get IPMI, iLo, IP KVM, whatever up for you to do your thing. When/if something ever "hits the fan" they have on site 24 hour "remote hands" that can either take basic pre-prescribed steps/instructions -or- work with your team directly and remotely.

Interestingly, at my first startup we had a facility in the nearest big metro area that not only hosted our hardware but also provided an easy, cheap, and readily available meeting space:

https://www.coresite.com/data-centers/data-center-design/ame...

Post reply on HN