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

231–240 of 601 posts

Re: Use one big server

#231

Post by ocdtrekkie »

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.

I find this entire attitude disappointing. Engineering has moved from "provide the best reliability" to "provide the reliability we won't get blamed for the failure of". Folks who have this attitude missed out on the dang ethics course their college was teaching.

If rolling your own is faster, cheaper, and more reliable (it is), then the only justification for cloud is assigning blame. But you know what you also don't get? Accolades.

I throw a little party of one here when Office 365 or Azure or AWS or whatever Google calls it's cloud products this week is down but all our staff are able to work without issue. =)

Re: Use one big server

#232

Post by z3t4 »

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…

The rule is: Keep related data together. Exceptions are: Different customers (usually don't require each others data) can be isolated. And if the database become the bottleneck you can separate unrelated services.

Re: Use one big server

#233

Post by EddySchauHai »

> But if I use Cloud Architecture, I Don’t Have to Hire Sysadmins

> Yes you do. They are just now called “Cloud Ops” and are under a different manager. Also, their ability to read the arcane documentation that comes from cloud companies and keep up with the corresponding torrents of updates and deprecations makes them 5x more expensive than system administrators.

I don't believe "Cloud Ops" is more complex than system administration, having studied for the CCNA so being on the Valley of Despair slope of the Dunning Kruger effect. If keeping up with cloud companies updates is that much of a challenge to warrant a 5x price over a SysAdmin then that's telling you something about their DX...

Re: Use one big server

#234

Post by londons_explore »

Hybrid!

If you are at all cost sensitive, you should have some of your own infrastructure, some rented, and some cloud.

You should design your stuff to be relatively easily moved and scaled between these. Build with docker and kubernetes and that's pretty easy to do.

As your company grows, the infrastructure team can schedule which jobs run where, and get more computation done for less money than just running everything in AWS, and without the scaling headaches of on-site stuff.

Re: Use one big server

#235

Post by rstephenson2 »

It seems like lots of companies start in the cloud due to low commitments, and then later when they have more stability and demand and want to save costs, making bigger cloud commitments (RIs, enterprise agreements etc) are a turnkey way to save money but always leave you on the lower-efficiency cloud track. Has anyone had good experiences selectively offloading workloads from the cloud to bare metal servers nearby?

Re: Use one big server

#236

Post by londons_explore »

Don't be scared of 'one big server' for reliability. I'd bet that if you hired a big server today in a datacenter, the hardware will have more uptime than something cloud-native with az-failover hosted on AWS.

Just make sure you have a tested 30 minute restoration plan in case of permanent hardware failure. You'll probably only use it once every 50 years on average, but it will be an expensive event when it happens.

Re: Use one big server

#237

Post by londons_explore »

One-big-VM is another approach...

A big benefit is some providers will let you resize the VM bigger as you grow. The behind-the-scenes implementation is they migrate your VM to another machine with near-zero downtime. Pretty cool tech, and takes away a big disadvantage of bare metal which is growth pains.

Re: Use one big server

#238

Post by mwcampbell »

MrStonedOne wrote: post #97

/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 th…

> $175/month for the rented server with 64gb of ram and a 10gbit uplink)

Wow, what provider is that?

Re: Use one big server

#239

Post by abrax3141 »

marcosdumay wrote: post #207
abrax3141 wrote: post #139

I may be misunderstanding, but it looks like the micro-services comparison here is based on very high usage. Another use for micro-services, like lambda, is exactly the opposite. If you have very low usage, you aren't paying for cycles you don't use the way you would be if you either owned the machine, or rented it from AWS or DO and left it on all the time (which you'd have to do in order to serve that randomly-arri…

Why open yourself to random $300k bills from Amazon when the alternative is wasting a $5/month server?

I don’t understand what these numbers are referring to.

Re: Use one big server

#240

Post by mochomocha »

> Why Should I Pay for Peak Load? [...] someone in that supply chain is charging you based on their peak load

Oh it's even worse than that: this someone oversubscribe your hardware a little during your peak and a lot during your trough, padding their great margins at the expense of extra cache misses/perf degradation of your software that most of the time you won't notice if they do their job well.

This is one of the reasons why large companies such as my employer (Netflix) are able to invest into their own compute platforms to reclaim some of these gains back, so that any oversubscription & collocation gains materialize into a lower cloud bill - instead of having your spare CPU cycles be funneled to a random co-tenant customer of your cloud provider, the latter capturing the extra value.

Post reply on HN