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

Simple Systems Have Less Downtime

gkogan.co

Post reply on HN
Print view View original

211–220 of 271 posts

Re: Simple Systems Have Less Downtime

#211

Post by klysm »

rsync wrote: post #143

I gave a talk on this subject at CU last year and have, one way or another, spent my entire professional life thinking about this topic. I agree wholeheartedly that simple systems have less downtime. I would like to add a line from the talk that I give: Simple systems fail in boring ways. Complex systems fail in fascinating, unexpected ways. rsync.net storage arrays typically have multi-hundred day uptimes. But acros…

rsync.net is built on ZFS which is anything but simple. Having worked with multi-petabyte ZFS systems, you can run into some seriously hard to track down issues.

Re: Simple Systems Have Less Downtime

#212

Post by stygiansonic »

klysm wrote: post #210
throw0101a wrote: post #202

See Gall's Law: > A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.[9] * https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law

I find it mildly annoying when people state such nuggets of knowledge as “laws”. Sure, it’s generally true that you can’t go for the most sophisticated and powerful system at the first go, but sometimes the minimal working system is complex no? Anyway, it’s certainly not a “law” of the universe.

It’s a colloquialism, like Moore’s law.

Re: Simple Systems Have Less Downtime

#213

Post by hartzell »

csomar wrote: post #87

The author, probably, picked the worst example. Here is a pic: https://iro.nl/app/uploads/2018/12/P-67-onboard-the-BOKA-Van... No, the containership is not a simple system. It's very sophisticated one. It takes massive engineering effort (literally historical effort and knowledge) to build, massive resources for the material and outsourcing, very complex (like the pic) infrastructure in case of repair, satellites to…

I was curious about what was going on in that image, turns out that it's a "semi-submersible heavy lift ship" wrapped around another ship (an FPSO?)

https://en.wikipedia.org/wiki/BOKA_Vanguard

I think this story is about the same liftee:

https://www.projectcargojournal.com/shipping/2019/11/20/new-...

Re: Simple Systems Have Less Downtime

#214

Post by throw0101a »

klysm wrote: post #211
rsync wrote: post #143

I gave a talk on this subject at CU last year and have, one way or another, spent my entire professional life thinking about this topic. I agree wholeheartedly that simple systems have less downtime. I would like to add a line from the talk that I give: Simple systems fail in boring ways. Complex systems fail in fascinating, unexpected ways. rsync.net storage arrays typically have multi-hundred day uptimes. But acros…

rsync.net is built on ZFS which is anything but simple. Having worked with multi-petabyte ZFS systems, you can run into some seriously hard to track down issues.

Is ZFS more or less complicated than mdraid+LVM+ext4?

Re: Simple Systems Have Less Downtime

#215

Post by sev0 »

klysm wrote: post #210
throw0101a wrote: post #202

See Gall's Law: > A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.[9] * https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law

I find it mildly annoying when people state such nuggets of knowledge as “laws”. Sure, it’s generally true that you can’t go for the most sophisticated and powerful system at the first go, but sometimes the minimal working system is complex no? Anyway, it’s certainly not a “law” of the universe.

"Law" can also be used for pithy statements that don't have to be particularly rigorous. C.f. Murphy's Law.

Re: Simple Systems Have Less Downtime

#216

Post by vikiomega9 »

barrkel wrote: post #179
papito wrote: post #164

Earlier quoted context omitted.

As someone said, microservices is a technical solution to a people problem. Devs don't want to talk to each other so they wall off behind their own API. Boom, no need to talk to each other. Ever. Or is there?

Requiring everyone to talk to everyone so everyone has global context isn't just "devs don't want to talk to each other"; it is actually an information dissemination and coordination problem which scales non-linearly (at least n^2), and needs some kind of modularity to be tractable to normal humans. Microservices are like modules but for SaaS rather than shrinkwrap, and are where you end up when you follow SLAs, enca…

> scales non-linearly

Indeed, https://en.wikipedia.org/wiki/The_Nature_of_the_Firm

Re: Simple Systems Have Less Downtime

#217

Post by bcrosby95 »

sitkack wrote: post #142
nickbauman wrote: post #114

Earlier quoted context omitted.

They chose Erlang. A language built for communication and managing wire protocols at scale. Which describes WhatsApp itself. That was probably the biggest impact single decision for WhatsApp technically.

Erlang is like Bugman from the Nightmare Before Christmas. It is literally made out of microservices at every level. Microservices are a design philosophy that people confuse as a deployment strategy.

Kinda, yeah, except Erlang is microservices made easier. I've loved how the language makes building distributed systems so comparatively easy since I ran across it back in 2005.

Re: Simple Systems Have Less Downtime

#218

Post by krab »

nradov wrote: post #157
krab wrote: post #112

Earlier quoted context omitted.

I'm now working with a system where we add microservices. In my experience, they allow you to split a team that then owns its whole deployment cycle. This allows for easier hot-fixing and dealing with database schema changes. There are now almost fifty developers and we already have a third (micro-)service. ;-) I agree completely that starting with a monolith is a win for feature development, performance and operatio…

That has nothing to do with the release cycle. A large monolith can still do continuous delivery and release multiple times per day. What tends to slow down is the feature delivery cycle.

Would you care to explain your reasoning? This topic genuinely interests me.

My experience is quite the opposite. To deliver a feature, you still need to integrate changes in multiple services. To do it in a monolith is IMHO easier. You have a single artifact you can test, the probability you have the right automation is higher. Also, the devs will run bigger part of the system in the development version.

What I was talking about was the latency of smaller changes. Think of bug fixes. Somebody has to notice it, triage, fix, (wait for automated tests) and deploy. Often, a bug fix affects just one service. With smaller services, this chain is simpler.

Re: Simple Systems Have Less Downtime

#219

Post by bcrosby95 »

munchbunny wrote: post #175
nickbauman wrote: post #114

Earlier quoted context omitted.

They chose Erlang. A language built for communication and managing wire protocols at scale. Which describes WhatsApp itself. That was probably the biggest impact single decision for WhatsApp technically.

That was probably the biggest impact single decision for WhatsApp technically. As a rule of thumb based on my own experiences and the opinions of more experienced engineers I've had the good fortune to work with, language choice is far less important than the quality of the team using it. While I have no doubt that trying to build WhatsApp in a language that would be the wrong tool for the job (say... PHP) would have…

I don't know. Erlang is a "funny" language that can somewhat easily do certain things that would be much more time consuming to accomplish in a more mainstream programming language. The difference between building whatsapp in Erlang vs any other programming language is probably larger than building it in php vs any other mainstream language.

Re: Simple Systems Have Less Downtime

#220

Post by jcelerier »

thesuperbigfrog wrote: post #144
jerf wrote: post #107

Earlier quoted context omitted.

One of the traditional criticisms of Lisp, though, is that it lets programmers re-introduce a whole lot of accidental complexity in their Lisp code, and, worse, everyone introduces a completely different set of accidental complexities into their code.

That problem is not limited to Lisp. As a programming language, Common Lisp is large enough and multi-paradigm enough to allow for elegant solutions to problems. It does require some experience with the language and some wisdom and discipline to know what pieces to select and how to best use them. However, like all large, multi-paradigm programming languages that have been around for a while (I'm looking at you C++),…

> programmers tend to carve out their own subsets of the language which are not always as well understood by those who come after them

if the language is not powerful enough to allow for that people will inevitably add preprocessors, code generators, etc... to do the things they want.

Post reply on HN