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

141–150 of 271 posts

Re: Simple Systems Have Less Downtime

#141

Post by btilly »

gk1 wrote: post #109
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…

Hey, author here. My point is that simple-to-understand systems--not simple as in primitive--have less downtime, not that we shouldn't ever have complex systems. A container ship like the one in my article can be drydocked ("in the shop") for repairs and back on the water in less than two weeks. A nuclear-powered aircraft carrier cannot. So be mindful when you're building an aircraft carrier when a container ship wou…

An interesting thing to contrast that with is the Boeing disaster. Where they decided to make the steering actually more complex, then hide it from the pilot with software to make it look like the old, simple thing.

The result was a system that worked fine until you encountered bugs in the software, at which point there was no helping that several hundred people were about to die.

Re: Simple Systems Have Less Downtime

#142

Post by sitkack »

nickbauman wrote: post #114
ignoramous wrote: post #106

Earlier quoted context omitted.

WhatsApp, similarly, had 30+ employees when they got acquired [0]. They built the fastest IM on the market with 450M+ users sending 1B+ messages everyday, and at one point surpassed Facebook in terms of number of images uploaded. The engs they had were world-class, so really, I think, saying microservices (or latest-fad) get in the way etc is disingenuous since you also require world-class talent to begin with (if yo…

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.

Re: Simple Systems Have Less Downtime

#143

Post by rsync »

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 across our entire network, our actual aggregate uptime is unimpressive - perhaps 99.99% ? Our SLA dictates 99.95.

But when they do fail they fail in very, very boring ways. There are usually zero decisions to make in response to a failure.

Re: Simple Systems Have Less Downtime

#144

Post by thesuperbigfrog »

jerf wrote: post #107
thesuperbigfrog wrote: post #104

Earlier quoted context omitted.

Fred Brooks called it "essential complexity" and "accidental complexity"[1]. Essential complexity is inherent to problem being solved and nothing can remove it. Accidental complexity is introduced by programmers as they build solutions to the problem. Lisp is nice because eliminates a lot of the accidental complexity through minimal syntax and lists as a near-universal data structure. 1: http://worrydream.com/refs/Br…

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, particularly as the language continues to evolve and grow.

There is also the problem where programmers try to be too clever and push the language to its limits or use too many language features when a simpler solution would do. All too often we are the creators of our own problems by over-thinking, over-designing, or misusing the tools at hand.

Re: Simple Systems Have Less Downtime

#145

Post by sgift »

nickbauman wrote: post #111
papito wrote: post #54

Instagram was what, 12 employees when they got sold for a gazillion dollars? They all could fit into a van. Because they kept their system simple. It was (and still is) a monolith. Now imagine that they decided to go the microservices way. Multiply that team size by 10 at least. Don't solve problems you don't have.

But microservices are an example of simpler systems. Each microservice does far less than the whole monolith does. You can read all the code in ~15 minutes. I've worked at companies that have monoliths that are 50x more difficult to work on because of the size. Some of them millions of lines of code. Nobody really knows how they work anymore.

> But microservices are an example of simpler systems. Each microservice does far less than the whole monolith does. You can read all the code in ~15 minutes.

Microservice usually means distributed system. A distributed system is more complex than a non-distributed system since it has to do everything the non-distributed system has to do and, additionally, handle all the distributed problems. Microservices just hide the complexity in places where people don't see them if they take a cursory look over the code, e.g. what is a function call in a monolith can be a call to a completely different machine in a microservice architecture. Often they look the same on the outside, but behave very differently.

The hierarchy of simplicity is: Monolith > multithreaded[1] monolith > distributed system. If you can get away with a simpler one it will save you from many headaches.

> I've worked at companies that have monoliths that are 50x more difficult to work on because of the size. Some of them millions of lines of code. Nobody really knows how they work anymore.

That is a bad architecture, not something inherent to a "monolith". There's probably also a wording problem here. A monolith can be build out of many components. Libraries were a thing long before microservices reared their ugly heads. What you describe sounds more like a spaghetti architecture where all millions of lines are in one big repository and every part can call every other part. Unfortunately, microservices are not immune from this problem.

[1] or whatever you want to call "uses more than one core/cpu"

Re: Simple Systems Have Less Downtime

#146

Post by nickbauman »

LargeWu wrote: post #132
nickbauman wrote: post #111

Earlier quoted context omitted.

But microservices are an example of simpler systems. Each microservice does far less than the whole monolith does. You can read all the code in ~15 minutes. I've worked at companies that have monoliths that are 50x more difficult to work on because of the size. Some of them millions of lines of code. Nobody really knows how they work anymore.

Microservices, often, is just another word for "distributed monolith". Sure you can read the code of a single service quickly, but often in practice it's not possible to just make changes to one service. There are usually both explicit and implicit dependencies that span many service layers. What you gain in readability I think you often lose more in maintenance overhead.

I worked on a microservices practice (with over 400 microservices by the time I left) where it definitely was not a "distributed monolith". I could change all kinds of individual services that did not require changes to other services.

Re: Simple Systems Have Less Downtime

#147

Post by serbrech »

papito wrote: post #54

Instagram was what, 12 employees when they got sold for a gazillion dollars? They all could fit into a van. Because they kept their system simple. It was (and still is) a monolith. Now imagine that they decided to go the microservices way. Multiply that team size by 10 at least. Don't solve problems you don't have.

The thinking is backwards, if you are only 10 people, there I no need to shape the system in a microservicr fashion. You just extract the pieces that need scaling. If you are 60 devs, you need to split the system so that everyone can work on it without walking on each other.

Re: Simple Systems Have Less Downtime

#148

Post by ansgri »

Minor49er wrote: post #102
jyounker wrote: post #69

Earlier quoted context omitted.

My favorite variants of this phenomena are "let's just add a column instead of creating a new table" and "let's add a boolean argument instead of creating a new function."

Or worse: "we built a table for arbitrary key-value pairings, but now the value needs to be an array or object, so we'll store it as a JSON string"

I usually do the inverse: who knows what additional data we'll want to store for each row, let's put there a jsonb column, store anything not clearly critical there, and add columns or tables as these jsons get populated and used.

Re: Simple Systems Have Less Downtime

#149

Post by terminaljunkid »

upofadown wrote: post #63
hyperion2010 wrote: post #25

The only language that I have worked with that realizes that in the real world simple is _always_ a lie, is common lisp. It is the only language that has actually embraced the fact that its designers/committee were not geniuses and provided the tools for dealing with the complexity of the system. When unix tools fail, hope that you are on a system where it is possible to get the symbols and/or the source code, and ev…

>Lisp All those complicated lists? Forth is even further down the path to ultimate minimalism. Really only one data structure, a stack with binary values on it...

Common lisp was never about minimalism. It was about lisp dialects like scheme.

Re: Simple Systems Have Less Downtime

#150

Post by mercer »

lincpa wrote: post #117
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…

Warehouse/Workshop Model is more simple, the large industrial assembly line is the mainstream production technology in the world. But simplicity does not mean easy. It is actually systematic engineering. It is difficult to design a complex system into a simple and smooth Warehouse(database, pool)/Workshop(pipeline) Model system. https://github.com/linpengcheng/PurefunctionPipelineDataflow

Is there any way I could convince you to stop clogging up the internet pipes with comments that seem to solely focus on 'pipes' and 'warehouses'? Surely there are other things that you care about and could contribute to HN?

At this point it's literally spam.

EDIT: Literally figuratively speaking, of course.

Post reply on HN