Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use One Big Server (2022)

specbranch.com

Post reply on HN
Print view View original

231–240 of 330 posts

Re: Use One Big Server (2022)

#231

Post by brazzy »

tgtweak wrote: post #216

I've been doing hybrid colo+public cloud for over a decade and it's always been the most cost effective route at a certain scale. That specific break even point is lowering over time with the density and cost effectiveness of hardware. Sure you need net/infra admins but the software and hardware these days are pretty management friendly and you'll find you still need (often more expensive "cloud") admins so you're no…

Colocation to me means you buy your own hardware and rent only the rack space (and power and connectivity) from the datacenter. Is that really what you're talking about? If so, why do you choose this over renting bare metal servers?

Re: Use One Big Server (2022)

#232

Post by icedchai »

eska wrote: post #149
themafia wrote: post #104

Earlier quoted context omitted.

> significantly more expensive per vCPU hour It's almost exactly the same price as EC2. What you don't get to control is the mix of vCPU and RAM. Lambda ties those two together. For equivalent EC2 instances the cost difference is astronomically small, on the order of pennies per month. > like transcoding long videos, [...] data analysis, and other compute-heavy tasks If you aren't breaking these up into multiple smal…

> If you aren't breaking these up into multiple smaller independent segments then I would suggest that you're doing this wrong in the first place. Care to elaborate?

You are expected to work around Lambda limitations because it's the "right way", not because the limitations make things overly complex. /s

Re: Use One Big Server (2022)

#233

Post by sahilagarwal »

shrubble wrote: post #91
bspammer wrote: post #84

Earlier quoted context omitted.

A fair comparison would include the cost of the DBA who will be responsible for backups, updates, monitoring, security and access control. That’s what RDS is actually competing with.

Paying someone $2000 to set that up once should result in the costs being recovered in what, 18 months? If you’re running Postgres locally you can turn off the TCP/IP part; nothing more to audit there. SSH based copying of backups to a remote server is simple. If not accessible via network, you can stay on whatever version of Postgres you want. I’ve heard these arguments since AWS launched, and all that time I’ve bee…

I guess my non-management / non-business side is show here, but how can it be that much?? I still remember I designed a fairly simple cron job that took database backups when I was a junior developer.

It gets even easier now that you have cheap s3 - just upload the dump to s3 every day and set the s3 deletion policy to whatever is feasible for you.

Re: Use One Big Server (2022)

#234

Post by fragmede »

brazzy wrote: post #231
tgtweak wrote: post #216

I've been doing hybrid colo+public cloud for over a decade and it's always been the most cost effective route at a certain scale. That specific break even point is lowering over time with the density and cost effectiveness of hardware. Sure you need net/infra admins but the software and hardware these days are pretty management friendly and you'll find you still need (often more expensive "cloud") admins so you're no…

Colocation to me means you buy your own hardware and rent only the rack space (and power and connectivity) from the datacenter. Is that really what you're talking about? If so, why do you choose this over renting bare metal servers?

Because it's your hardware in the colo, so if money becomes dire, you can extend the servers lifetime beyond the standard depreciation schedule. Your rented bare metal servers might be slightly cheaper than a respective EC2 instance, but you stop paying that bill, it's gonna go poof, same as the EC2 instance.

Re: Use One Big Server (2022)

#235

Post by sam_lowry_ »

marcosdumay wrote: post #71
sam_lowry_ wrote: post #45

Earlier quoted context omitted.

Connectivity is a problem, not the room. I ran the IT side of a media company once, and it all worked on a half-empty rack of hardware in a small closet... except for the servers that needed bandwidth. These were colocated. Until we realized that the hoster did not have enough bandwidth, at which point we migrated to two bare metal servers at Hetzner.

It's connectivity, reliable power, reliable cooling, and security. The actual space isn't a big deal, but the entire environment has large fixed costs.

In abstract yeah.

In practice, all that except connectivity is relatively easy to have on-site.

Connectivity is highly dependent on the business location, local providers, their business plans and their willingness to go out of their way to serve the clients.

And I am not talking only about bandwidth, but also reserve lines and latency.

Re: Use One Big Server (2022)

#236

Post by fragmede »

garganzol wrote: post #190
fragmede wrote: post #140

Earlier quoted context omitted.

Obviously. But you get duplicate hardware, set up HA, get vendor support contracts, use multiple colors in disparit location. Cloud providers have figured this out fairly well, as we all did in the aughts. (Well, some of us anyway.) You can definitely determine that's a bunch of really annoying work and just pay a cloud provider to deal with it, or not, and go your own way. But if you want to be credible when saying…

When you get duplicate hardware, it is not "One Big Server" anymore. "Two Big Servers" at least. In September 2015, the failure rate caused by capacitors was still around 30% [1]. [1] https://www.researchgate.net/figure/Failure-rates-of-differe...

Respectfully, 2015 was still a decade ago.

Re: Use One Big Server (2022)

#237

Post by Spooky23 »

eska wrote: post #147
throwaway7783 wrote: post #131

Earlier quoted context omitted.

Probably not for $200/mo EC2, but AWS/GCP in general * Centralized logging, log search, log based alerting * Secrets manager * Managed kubernetes * Object store * Managed load balancers * Database HA * Cache solutions ... Can I run all these by myself? Sure. But I'm not in this business. I just want to write software and run that. And yes, I have needed most of this from day 1 for my startup. For a personal toy proje…

Now imagine your solution is not on a distributed system and go through that list. Centralized logging? There is nothing to centralized. Secrets management? There are no secrets to be constantly distributed to various machines on a network. Load balancing? In practice most people for most work don’t use it because of actually outgrowing hardware, but because they have to provision to shared hardware without exclusivi…

It sounds like you make a living doing stuff that has an incredibly small, ninja-like team, has a very low change rate, or is something that nobody really cares about. Things like RPO/RTO, multi-tenancy, logging, etc don't matter.

That's amazing. I wish I could do the same.

Unfortunately, I cannot run my business on a single server in a cage somewhere for a multitude of reasons. So I use AWS, a couple of colos and SaaS providers to deliver reliable services to my customers. Note I'm not a dogmatic AWS advocate, I seek out the best value -- I can't do what I do in AWS without alot of capital spend on firewalls and storage appliances, as well as the network infrastructure and people required to make those work.

Re: Use One Big Server (2022)

#238

Post by p_l »

fock wrote: post #134
bob1029 wrote: post #10

This isn't even the end game for "one big server". AMD will give the most bang per rack, but there are other factors. An IBM z17 is effectively one big server too, but provides levels of reliability that are simply not available in most IT environments. It won't outperform the AMD rack, but it will definitely keep up for most practical workloads. If you sit down and really think honestly about the cost of engineering…

no. In the short time I work at a z/OS-shop, they had to IPL twice. And the IPL takes ages... Now, if you can live with the weird environment and your people know how to programm what is essentially a distributed system described in terms noone else uses: I guess it's still ok, given the competition is all executing IBMs playbook too.

Entire mainframe IPL, or just LPAR?

My understanding is that usually you subdivide into few LPARs and then reboot the production ones on schedule to prevent drift and ensure that yes, unplanned IPLs will work

Re: Use One Big Server (2022)

#239

Post by whstl »

lelanthran wrote: post #139
bspammer wrote: post #84

Earlier quoted context omitted.

A fair comparison would include the cost of the DBA who will be responsible for backups, updates, monitoring, security and access control. That’s what RDS is actually competing with.

The RDS solution doesn't need a technical person to set it up? It doesn't need someone who knows how to use the labrythine AWS services and console?

Agree.

These comments sound super absurd to me, because RDS is difficult as hell to setup, unless you do it very frequently or already have it in IoC format, since one needs setting up a VPC, subnets, security groups, internet gateway, etc.

It's not like creating a DynamoDB, Lambda or S3 where a non-technical person can learn it in a few hours.

Sure, one might find some random Terraform file online to do this or vibe-code some CloudFormation, but that's not really a fair comparison.

Re: Use One Big Server (2022)

#240

Post by [deleted] »

alkonaut wrote: post #136
const_cast wrote: post #81

Earlier quoted context omitted.

> You can't do the opposite though, make a monolith and spread it out on 10 servers. Yes you can. Its called having multiple applications servers. They all run the same application, just more of them. Maybe they connect to the same DB, maybe not, maybe you shard the DB.

That’s obviously not what I meant. I meant running different aspects of the monolith on different servers.

[deleted]
Post reply on HN