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

151–160 of 601 posts

Re: Use one big server

#151

Post by bartread »

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…

Not to mention, backups, restores, and disaster recovery are so much easier with One Big Database™.

Re: Use one big server

#152

Post by jedberg »

Phil_Latio wrote: post #145
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…

> Where you'll get into trouble is if you get popular quickly. You may run into scaling issues early on Did it ever occur to you that you can still use the cloud for on demand scaling? =)

Sure but only if you architect it that way, which most people don't if they're using one big beefy server, because the whole reason they're doing that is to iterate quickly. It's hard to build something that can bust to the cloud while moving quickly.

Also, the biggest issue is where your data is. If you want to bust to the cloud, you'll probably need a copy of your data in the cloud. Now you aren't saving all that much money anymore and adding in architectural overhead. If you're going to bust to the cloud, you might as well just build in the cloud. :)

Re: Use one big server

#154

Post by [deleted] »

nrmitchi wrote: post #59
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…

There is also the consideration that this isn't even an argument of "other things are down too!" or "outsourcing blame" as much as, depending on what your service is of course, you are unlikely to be operating in a bubble. You likely have some form of external dependencies, or you are an external dependency, or have correlated/cross-dependency usage with another service. Guaranteeing isolation between all of these di…

[deleted]

Re: Use one big server

#155

Post by delecti »

robertlagrant wrote: post #127
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…

> Your product asks will consistently want to combine these data sources (they don't know how your distributed databases look, and oftentimes they really do not care). I'm not sure how to parse this. What should "asks" be?

The phrase "Your product asks will consistently " can be de-abbreviated to "product owners/product managers you work with will consistently request".

Re: Use one big server

#156

Post by efortis »

Some comments wrongly equate bare-metal with on-premise. Bare-metal servers can be rented out, collocated, or installed on-premise.

Also, when renting, the company takes care of hardware failures. Furthermore, as hard disk failures are the most common issue, you can have hot spares and opt to let damaged disks rot, instead of replacing them.

For example, in ZFS, you can mirror disks 1 and 2, while having 3 and 4 as hot spares, with the following command:

    zpool create pool mirror $d1 $d2 spare $d3 $d4
---

The 400Gbps are now 700Gbps

https://twitter.com/DanRayburn/status/1519077127575855104

---

About the break even point:

Disregarding the security risks of multi-tenant cloud instances, bare-metal is more cost-effective once your cloud bill exceeds $3,000 per year, which is the cost of renting two bare-metal servers.

---

Here's how you can create a two-server infrastructure:

https://blog.uidrafter.com/freebsd-jails-network-setup

Re: Use one big server

#157

Post by skyde »

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.

thanks a lot for this comment. I will borrow this as an interview question :)

Re: Use one big server

#158

Post by danpalmer »

rbanffy wrote: post #150
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…

> Use One Big Database. I emphatically disagree. I've seen this evolve into tightly coupled microservices that could be deployed independently in theory, but required exquisite coordination to work. If you want them to be on a single server, that's fine, but having multiple databases or schemas will help enforce separation. And, if you need one single place for analytics, push changes to that space asynchronously. Ha…

To clarify the advice, at least how I believe it should be done…

Use One Big Database Server…

… and on it, use one software database per application.

For example, one Postgres server can host many databases that are mostly* independent from each other. Each application or service should have its own database and be unaware of the others, communicating with them via the services if necessary. This makes splitting up into multiple database servers fairly straightforward if needed later. In reality most businesses will have a long tail of tiny databases that can all be on the same server, with only bigger databases needing dedicated resources.

*you can have interdependencies when you’re using deep features sometimes, but in an application-first development model I’d advise against this.

Re: Use one big server

#159

Post by mathisonturing »

bob1029 wrote: post #83

> 1 million IOPS on a NoSQL database I have gone well beyond this figure by doing clever tricks in software and batching multiple transactions into IO blocks where feasible. If your average transaction is substantially smaller than the IO block size, then you are probably leaving a lot of throughput on the table. The point I am trying to make is that even if you think "One Big Server" might have issues down the road,…

> batching multiple transactions into IO blocks where feasible. If your average transaction is substantially smaller than the IO block size, then you are probably leaving a lot of throughput on the table.

Could you expand on this? A quick Google search didn't help. Link to an article or a brief explanation would be nice!

Post reply on HN