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

221–230 of 601 posts

Re: Use one big server

#221

Post by SassyGrapefruit »

>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 yourself so you don't get too familiar with eating regularly.

Kids this PSA is for you. Auto Scaling Groups are just fine as are all the other "Cloud Native" services. Most business partners will tell you a dollar of growth is worth 5x-10x the value of a dollar of savings. Building a huge tall computer will be cheaper but if it isn't 10x cheaper(And that is Total Cost of Ownership not the cost of the metal) and you are moving more slowly than you otherwise would its almost a certainty you are leaving money on the table.

Re: Use one big server

#222

Post by namose »

lanstin wrote: post #126
kkielhofner wrote: post #81

Earlier quoted context omitted.

Nobody ever got fired for buying AWS!

The AWS people now are just like the IBM people in the 80s - mastering a complex and not standards based array of products and optional product add-ons. The internet solutions were open and free for a few decades and now it’s AWS SNADS I mean AWS load balancers and edge networks.

AWS services are usually based on standards anyway. If you use an architecturally sound approach to AWS you could learn to develop for GCP or Azure pretty easily.

Re: Use one big server

#223

Post by titzer »

stevenjgarner wrote: post #6

If you are not maxing out or even getting above 50% utilization of 128 physical cores (256 threads), 512 GB of memory, and 50 Gbps of bandwidth for $1,318/month , I really like the approach of multiple low-end consumable computers as servers. I have been using arrays of Intel NUCs at some customer sites for years with considerable cost savings over cloud offerings. Keep an extra redundant one in the array ready to sw…

This is pretty devious and I love it.

Re: Use one big server

#224

Post by titzer »

eastbound wrote: post #215
titzer wrote: post #212

Last year I did some consulting for a client using Google cloud services such as Spanner and cloud storage. Storing and indexing mostly timeseries data with a custom index for specific types of queries. It was difficult for them to define a schema to handle the write bandwidth needed for their ingestion. In particular it required a careful hashing scheme to balance load across shards of the various tables. (It seems…

When you say “screw the cloud”, you mean “administer an EC2 machine yourself” or really “buy your own hardware”?

The former, mostly. You don't necessarily have to use EC2, but that's easy to do. There are many other, smaller providers if you really want to get out from under the big 3. I have no experience managing hardware, so I personally wouldn't take that on myself.

Re: Use one big server

#225

Post by dougmoscrop »

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.

Can you imagine if even a fraction of the effort poured in to k8s tooling had gone in to the Erlang/OTP ecosystem instead?

Re: Use one big server

#226

Post by BenoitEssiambre »

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'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, better error propagation, avoiding the hundreds of impossible to solve roadblocks of distributed systems (https://groups.csail.mit.edu/tds/papers/Lynch/MIT-LCS-TM-394...).

But also it is about pushing the limits of what is physically possible in computing. As Admiral Grace Hopper would point out (https://www.youtube.com/watch?v=9eyFDBPk4Yw ) doing distance over network wires involves hard latency constraints, not to mention dealing with congestions over these wires.

Physical efficiency is about keeping data close to where it's processed. Monoliths can make much better use of L1, L2, L3, and ram caches than distributed systems for speedups often in the order of 100X to 1000X.

Sure it's easier to throw more hardware at the problem with distributed systems but the downsides are significant so be sure you really need it.

Now there is a corollary to using monoliths. Since you only have one db, that db should be treated as somewhat sacred, you want to avoid wasting resources inside it. This means being a bit more careful about how you are storing things, using the smallest data structures, normalizing when you can etc. This is not to save disk, disk is cheap. This is to make efficient use of L1,L2,L3 and ram.

I've seen boolean true or false values saved as large JSON documents. {"usersetting1": true, "usersetting2":fasle "setting1name":"name" etc.} with 10 bits of data ending up as a 1k JSON document. Avoid this! Storing documents means, the keys, the full table schema is in every row. It has its uses but if you can predefine your schema and use the smallest types needed, you are gaining much performance mostly through much higher cache efficiency!

Re: Use one big server

#227

Post by beachy »

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…

Another area for consolidation is auth. Use one giant keycloak, with individual realms for every one of the individual apps you are running. Your keycloak is back ended by your one giant database.

Re: Use one big server

#228

Post by evilotto »

Many people will respond that "one big server" is a massive single point of failure, but in doing so they miss that it is also a single point of success. If you have a distributed system, you have to test and monitor lots of different failure scenarios. With a SPOS, you only have one thing to monitor. For a lot of cases the reliability of that SPOS is plenty.

Bonus: Just move it to the cloud, because AWS is definitely not its own SPOF and it never goes down taking half the internet with it.

Re: Use one big server

#229

Post by [deleted] »

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.

[deleted]

Re: Use one big server

#230

Post by treis »

naavis wrote: post #182
treis wrote: post #89

Earlier quoted context omitted.

This is one of those problems that basically no one has. RTT from Japan to Washington D.C. is 160ms. There's very few applications where that amount of additional latency matters.

It adds up surprisingly quickly when you have to do a TLS handshake, download many resources on pageload etc. The TLS handshake alone costs 3 round-trips over the network.

TLS is cached though. Your 3 round trips is 1/2 second on initial load but then should be reused for subsequent requests.

Resources should be served through a CDN so you'll get local servers for those.

Post reply on HN