Live data from Hacker News

Ask HN: Do you find working on large distributed systems exhausting?

news.ycombinator.com

211–220 of 261 posts

Re: Ask HN: Do you find working on large distributed systems exhausting?

#211
post #208

Earlier quoted context omitted.

I would respectfully say that you are wrong. I speak from experience. At Netflix we tried to hire for around the clock coverage. But what ended up working much better was taking that same team and having each person on call for a week at a time, all based in Pacific Time. Yes, you would get calls at 2am, sometimes multiple days in a row. But you were only on call once every six to eight weeks, and we scheduled out we…

This is the same approach as night shifts for nurses. There’s a lot of evidence to suggest that the effects on this infrequent but consistent disturbance to their circadian rhythms causes all kinds of physiological damage. One example [1]. We have to do better. I think the original suggestion of finding specialised night workers or those in other timezones is more humane. [1] https://blogs.cdc.gov/niosh-science-blog/…

That article is about night shift work, not day shift work that occasionally makes you work an hour or two at night every six weeks.

Re: Ask HN: Do you find working on large distributed systems exhausting?

#212
If you're working on distributed systems scheduling and orchestration, then yeah it's exhausting. I did it for six years as a SRE-SE and am now back to being a SWE on a product team. If you like infrastructure stuff without having responsibility for the whole system the way that scheduling and orchestration makes you, then look at working on an infrastructure product.

Re: Ask HN: Do you find working on large distributed systems exhausting?

#213
post #207

Earlier quoted context omitted.

But you don't actually need that level of performance? You've made this system more complex and expensive to achieve a requirement that doesn't matter?

you seem to have a deeper knowledge of the business & organisational context that dictate the true requirements than someone working there. please share these details so we can all learn!

Sure: the network request time of a person making a request over the open internet is going to be an order of magnitude longer than a DB lookup (in the right style, with a reverse-index) on the scale of data this person is describing. So making the lookup 10x faster saves you...1% of the request latency.

And at the qps they've described, it's not a throughput issue either. So I'm pretty confident in saying that this is a case of premature optimization.

And at some point the increase in parallelization of scans dominates mmap speed, unless you're redundantly sharding your mmaped hash table across multiple machines. And there are cases where network bandwidth is the bottleneck before disk bandwidth, though probably not this case. But yeah basically, the answer is something like "if this is the optimal choice, it probably didnt matter that much".

Re: Ask HN: Do you find working on large distributed systems exhausting?

#214

Earlier quoted context omitted.

I don’t think this is a stable long term solution. The “on call” teams end up frustrated with the engineers who ship bugs and this results in added process that delays deploys, arbitrary demands for test coverage, capricious error budgets, etc. It’s much better to have the engineers who wrote the code be responsible for running it, and if their operational burden becomes too high, to staff up the dev team to empower…

I don't think the parent was implying you're never on call for your code, just only on call during working hours. One of the challenges for larger companies in trying to make teams on-call 24/7 is that your most senior engineers often have enough money that they don't have to take on-call. Some variation of the following conversation happens in Big Tech more than most people seem to anticipate: "hey, so I have 7 mil…

[deleted]

Re: Ask HN: Do you find working on large distributed systems exhausting?

#215
post #208

Earlier quoted context omitted.

This is the same approach as night shifts for nurses. There’s a lot of evidence to suggest that the effects on this infrequent but consistent disturbance to their circadian rhythms causes all kinds of physiological damage. One example [1]. We have to do better. I think the original suggestion of finding specialised night workers or those in other timezones is more humane. [1] https://blogs.cdc.gov/niosh-science-blog/…

That article is about night shift work, not day shift work that occasionally makes you work an hour or two at night every six weeks.

Here is a reference that is a bit more attributable to the on call experience. There is a tangible human cost to after hours responses during an on call rotation. I personally do not recommend on call roles to any technology professional who can avoid them due to these health consequences of an on call requirement.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5449130/

> Sleep plays a vital role in brain function and systemic physiology across many body systems. Problems with sleep are widely prevalent and include deficits in quantity and quality of sleep; sleep problems that impact the continuity of sleep are collectively referred to as sleep disruptions. Numerous factors contribute to sleep disruption, ranging from lifestyle and environmental factors to sleep disorders and other medical conditions. Sleep disruptions have substantial adverse short- and long-term health consequences. A literature search was conducted to provide a nonsystematic review of these health consequences (this review was designed to be nonsystematic to better focus on the topics of interest due to the myriad parameters affected by sleep). Sleep disruption is associated with increased activity of the sympathetic nervous system and hypothalamic–pituitary–adrenal axis, metabolic effects, changes in circadian rhythms, and proinflammatory responses. In otherwise healthy adults, short-term consequences of sleep disruption include increased stress responsivity, somatic pain, reduced quality of life, emotional distress and mood disorders, and cognitive, memory, and performance deficits. For adolescents, psychosocial health, school performance, and risk-taking behaviors are impacted by sleep disruption. Behavioral problems and cognitive functioning are associated with sleep disruption in children. Long-term consequences of sleep disruption in otherwise healthy individuals include hypertension, dyslipidemia, cardiovascular disease, weight-related issues, metabolic syndrome, type 2 diabetes mellitus, and colorectal cancer. All-cause mortality is also increased in men with sleep disturbances. For those with underlying medical conditions, sleep disruption may diminish the health-related quality of life of children and adolescents and may worsen the severity of common gastrointestinal disorders. As a result of the potential consequences of sleep disruption, health care professionals should be cognizant of how managing underlying medical conditions may help to optimize sleep continuity and consider prescribing interventions that minimize sleep disruption.

Re: Ask HN: Do you find working on large distributed systems exhausting?

#216
post #65

Earlier quoted context omitted.

I feel that your problems aren't even remotely related to my problems with large distributed systems. My problems are all about convincing the company that I need 200 engineers to work on extremely large software projects before we hit a scalability wall. That wall might be 2 years in the future so usually it is next to impossible to convince anyone to take engineers out of product development. Even more so because w…

My impression has always been that FAANG need lots of engineers because the 10xers refuse to work there. I've seen plenty of really scalable systems being built by a small core team of people who know what they are doing. FAANG instead seem to be more into chasing trends, inventing new frameworks, rewriting to another more hip language, etc. I would have no idea how to coordinate 200 engineers. But then again, I have…

> I've seen plenty of really scalable systems being built by a small core team of people who know what they are doing.

There is huge difference between building a system that could theoretically be scaled up and actually scaling it up efficiently.

At small scales, it's really easy to build on the work of others and take things for granted without even knowing where the scaling limits are. For example, if I suddenly find I need to double my data storage capacity, I can drive to a store and come back with a trunk full of hard drives the same day. I can only do that because someone already build the hard drives, and someone stocked the nearby stores with them. If a hyperscaler needs to double their capacity, they need to plan it well in advance, allocating a substantial fraction of global hard drive manufacturing capacity. They can't just assume someone would have already built the hardware, much less have it in stock near where it's needed.

Re: Ask HN: Do you find working on large distributed systems exhausting?

#217

Earlier quoted context omitted.

This is a religious debate among many. The IT/engineering nerd stuff doesn’t matter at all. Cloud migration decisions are always made by accounting and tax factors. I run two critical apps, one on-prem and one cloud. There is no difference in people cost, and the cloud service costs about 20% more on the infrastructure side. We went cloud because customer uptake was unknown and making capital investments didn’t make…

> These things are tools and it doesn’t pay to be dogmatic. I wish I would hear this line more often. So many things today are (pseudo-) religious now. The right frsmework/language, cloud or on prem, x vs not x. Especially bad imho when somebody tries to tell you how you could do better with 'not x' instead of x you are currently using without even trying to understand the context this decision resides in. [Edit] typ…

> So many things today are (pseudo-) religious now. The right frsmework/language, cloud or on prem, x vs not x.

Might have always been that way? We just have so many more tools to argue over now.

Re: Ask HN: Do you find working on large distributed systems exhausting?

#218
post #143

Earlier quoted context omitted.

"1 pb is only 56 large enterprise hdds". umm, what happens when one fails? With large cloud my startup had excellent support. We negotiated a contract. That's how it works.

Typically people use RAID or ZFS to prevent data loss when a few hdds fail.

This cracked me up. Thanks fxtentacle :D.

Re: Ask HN: Do you find working on large distributed systems exhausting?

#219
Humans GET simplicity from extreme hyper complexity.

Take a gas generator. Easy, add oil and gas and get electricity and these days they even come in a smoothed over plastic shell that makes it look like a toy. Inside, very complex, spark plugs, engine, coils, inverter. A hundred years of inventions packed into a 1.5' x 1.5' box.

It's the same thing for complicated systems. Front end to back. No matter how ugly or how much you wish it was refactored - some exec knows it as a box where you put something in and magical inference comes out. Maybe that box actually causes real change in the physical world - like billions of packages being sent out all over the world.

In the days of castles you would have similar systems managed by people. People that drag wooden carts of shit out of a castle. Carrying water around. Manually husking corn and wheat and what have you.

No matter how far into the future we go, we will continue to get simple out of monstrous complexity.

That's not the answer to your question - but it's just that the world will always lean towards going that way.

Re: Ask HN: Do you find working on large distributed systems exhausting?

#220

Earlier quoted context omitted.

> you were highly incentivized (and had the time) to build tools or submit patches to fix the problems that woke you at 2am. Ah, so you worked on a team where the SRE needs were prioritized over the feature requests? Because in most companies where I've worked, Product + Customer Service + Sales + Marketing + Executives don't really have time or patience for the engineers to get their diamond polishing cloths out. Th…

> Ah, so you worked on a team where the SRE needs were prioritized over the feature requests? Yes, it was an SRE team. All we do is write tools to make operations better, but more importantly we write tools to make it easier for the dev teams to operate their own systems better. But yes, we had products teams that would push back on our requests because they had product to deliver, and that was fine. We'd either figu…

> Step one, double the limit to alleviate immediate customer pain.

I've been oncall for systems where that would not work.

Doubling the memory means you need twice as many machines. Depending on the service, that could require significantly increased network bandwidth. Now the network is saturated and every node needs to queue more data. Now latency and throughput are even worse, and even more requests are being dropped, so you automatically double the limit again...

Post reply on HN