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

311–320 of 601 posts

Re: Use one big server

#311

Post by rlpb »

0xbadcafebee wrote: post #213
rlpb wrote: post #198

Earlier quoted context omitted.

Huh? Using lxd would be identical to what you suggest (VMs on Xen) from a security upgrade and management perspective. Architecturally and operationally they're basically the equivalent, except that VMs need memory slicing up but lxd containers don't. There are security isolation differences but you're not talking about that here?

I would want the memory slicing + isolation, plus a hypervisor like Xen doesn't need an entire host OS so there's less complexity, vulns, overhead, etc, and I'm not aware if LXD does the kind of isolation that ex. allows for IKE IPSec tunnels? Non-hypervisors don't allow for it iirc. Would rather use Docker for containers because the whole container ecosystem is built around it.

> I would want the memory slicing + isolation...

Fine, but then that's your reason. "until there's a security vuln in an end-of-life piece of core software...and then it's a 4+ week slog of building a new server" isn't a difference in the context of comparing Xen VMs and lxd containers. As an aside, lxd does support cgroup memory slicing. It has the advantage that it's not mandatory like it is in VMs, but you can do it if you want it.

> Would rather use Docker for containers because the whole container ecosystem is built around it.

This makes no sense. You're hearing the word "container" and inferring an equivalence that does not exist. The "whole container ecosystem" is something that exists for Docker-style containers, and is entirely irrelevant for lxd containers.

lxd containers are equivalent to full systems, and exist in the "Use one big server" ecosystem. If you're familiar with running a full system into a VM, then you're familiar with the inside of a lxd container. They're the same. In userspace, there's no significant difference.

Re: Use one big server

#312

Post by threeseed »

manigandham wrote: post #200
Closi wrote: post #61

Earlier quoted context omitted.

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.

Why would you break apart a microservice? Any why do you need to use/split into microservices anyway? 99% of apps are best fit as monolithic apps and databases and should focus on business value rather than scale they'll never see.

> 99% of apps are best fit as monolithic apps and databases and should focus on business value rather than scale they'll never see

You incorrectly assume that 99% of apps are building these architectures for scalability reasons.

When in reality it's far more for development productivity, security, use of third party services, different languages etc.

Re: Use one big server

#313

Post by fleddr »

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…

The entire point of the article is that your dated example no longer applies: you can fit the vast majority of common loads on a single server now, they are this powerful.

Redundancy concerns are also addressed in the article.

Re: Use one big server

#314

Post by hamandcheese »

mgiampapa wrote: post #291
dsr_ wrote: post #282

Earlier quoted context omitted.

Here's the way it works for, say, Postgresql: - you rsync or zfs send the database files from machine A to machine B. You would like the database to be off during this process, which will make it consistent. The big advantage of ZFS is that you can stop PG, snapshot the filesystem, and turn PG on again immediately, then send the snapshot. Machine B is now a cold backup replica of A. Your loss potential is limited to…

This isn't really a backup, it's redundancy which is good thing but not the same as a backup solution. You can't get out of a drop table production type event this way.

If you stop at the first bullet point then you have a backup solution.

Re: Use one big server

#315

Post by lmm »

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…

If you do this then you'll have the hardest possible migration when the time comes to split it up. It will take you literally years, perhaps even a decade.

Shard your datastore from day 1, get your dataflow right so that you don't need atomicity, and it'll be painless and scale effortlessly. More importantly, you won't be able to paper over crappy dataflow. It's like using proper types in your code: yes, it takes a bit more effort up-front compared to just YOLOing everything, but it pays dividends pretty quickly.

Re: Use one big server

#316

Post by threeseed »

1500100900 wrote: post #163
markandrewj wrote: post #88

Earlier quoted context omitted.

Just FYI, you can have one big database, without running it on one big server. As an example, databases like Cassandra are designed to be scaled horizontally (i.e. scale out, instead of scale up). https://cassandra.apache.org/_/cassandra-basics.html

Cassandra may be great when you have to scale your database that you no longer develop significantly. The problem with this DB system is that you have to know all the queries before you can define the schema.

> The problem with this DB system is that you have to know all the queries before you can define the schema

Not true.

You just need to optimise your schema if you want the best performance. Exactly the same as an RDBMS.

Re: Use one big server

#317

Post by lmm »

Guid_NewGuid wrote: post #101
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.

I don't believe you. Eventual consistency is how the real world works, what possible use case is there where it wouldn't be acceptable? Even if you somehow made the display widget part of the database, you can't make the reader's eyeballs ACID-compliant.

Re: Use one big server

#318

Post by wizofaus »

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…

Surely having separate DBs all sit on the One Big Server is preferable in many cases. For cases where you really to extract large amounts of data that is derived from multiple DBs, there's no real harm in having some cross-DB joins defined in views somewhere. If there are sensible logical ways to break a monolithic service into component stand-alone services, and good business reasons to do (or it's already been designed that way), then having each talk to their own DB on a shared server should be able to scale pretty well.

Re: Use one big server

#319

Post by Nextgrid »

eastbound wrote: post #256
SoftTalker wrote: post #57

Earlier quoted context omitted.

I manage hundreds of servers, and use Ansible. It's simple and it gets the job done. I tried to install Kubernetes on a cluster and couldn't get it to work. I mean I know it works, obviously, but I could not figure it out and decided to stay with what works for me.

But it’s specific, and no-one will want to take over your job. The upside of a standard AWS CloudFormation file is that engineers are replaceable. They’re cargo-cult engineers, but they’re not worried for their career.

> But it’s specific, and no-one will want to take over your job.

It really depends what's on the table. Offer just half of the cost savings vs an equivalent AWS setup as a bonus (and pocket the other half) and I'm sure you'll find people who will happily do it (and you'll be happy to pocket the other half). For a lot of companies even just half of the cost savings would be a significant sum (reminds me of an old client who spent thousands per month on an RDS cluster that not only was slower than my entry-level MacBook, but ended up crapping out and stuck in an inconsistent state for 12 hours and required manual intervention from AWS to recover - so much for managed services - ended up restoring a backup but I wish I could've SSH'd in and recovered it in-place).

As someone who uses tech as a means to an end and is more worried about the output said tech produces than the tech itself (aka I'm not looking for a job nor resume clout nor invites to AWS/Hashicorp/etc conferences, instead I bank on the business problems my tech solves), I'm personally very happy to get my hands dirty with old-school sysadmin stuff if it means I don't spend 10-20x the money on infrastructure just to make Jeff Bezos richer - my end customers don't know nor care either way while my wallet appreciates the cost savings.

Re: Use one big server

#320

Post by dsr_ »

hamandcheese wrote: post #314
mgiampapa wrote: post #291

Earlier quoted context omitted.

This isn't really a backup, it's redundancy which is good thing but not the same as a backup solution. You can't get out of a drop table production type event this way.

If you stop at the first bullet point then you have a backup solution.

Precisely so.
Post reply on HN