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

151–160 of 271 posts

Re: Simple Systems Have Less Downtime

#151

Post by therealdrag0 »

serbrech wrote: post #147
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.

Also you can have so few devs when your value is in your network. Most other businesses' value is in their features. We have customers constantly begging for features, so we have to have more engineers to produce more value to our customers.

Re: Simple Systems Have Less Downtime

#152

Post by scroot »

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…

> most programmers are in an abusive relationship with their runtime environment.

Just pulling this out because it's a good sentence.

Re: Simple Systems Have Less Downtime

#153

Post by SPBS »

nickbauman wrote: post #146
LargeWu wrote: post #132

Earlier quoted context omitted.

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.

I think monoliths can be written the same way such that you can change one module without changing the others. Microservices enforce that best practice.

Re: Simple Systems Have Less Downtime

#154

Post by dnautics »

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.

Not necessarily, you can design erlang systems with more coupling than you'd expect in traditional microservices. Microservices mean that your codebase is segmented along business concern lines.

Re: Simple Systems Have Less Downtime

#155

Post by dnautics »

ignoramous wrote: post #130
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.

I am not sure if WhatsApp engs chose ejabberd because it was written in Erlang or because ejabberd was the defacto implementation of XMPP. They stumbled upon and fixed bugs in BEAM/OTP at their scale [0][1][2]. They also ran FreeBSD (for its superior networking?) on bare-metal hosts running customised system-images [3] and employed networking experts at some point. [0] https://www.youtube-nocookie.com/embed/c12cYAUTX…

I could be wrong but I think freebsd allowed multiplexing connections per port before Linux? Please correct me I am mistaken about this.

Re: Simple Systems Have Less Downtime

#156

Post by scurvy »

ignoramous wrote: post #130
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.

I am not sure if WhatsApp engs chose ejabberd because it was written in Erlang or because ejabberd was the defacto implementation of XMPP. They stumbled upon and fixed bugs in BEAM/OTP at their scale [0][1][2]. They also ran FreeBSD (for its superior networking?) on bare-metal hosts running customised system-images [3] and employed networking experts at some point. [0] https://www.youtube-nocookie.com/embed/c12cYAUTX…

They ran FreeBSD because Jan came from Yahoo, and that's what Yahoo ran.

Re: Simple Systems Have Less Downtime

#157

Post by nradov »

krab wrote: post #112
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.

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.

Re: Simple Systems Have Less Downtime

#158

Post by 0xdeadbeefbabe »

jrochkind1 wrote: post #97
jdc wrote: post #42

Earlier quoted context omitted.

Sure lisp is a wonderful language, but let's not pretend there's no difference between incidental and accidental complexity.

Do you mean inherent vs accidental? I think "incidental" (non-essential, secondary, happenstance), and "accidental" (non-intentional, happenstance) are more or less synonyms here, not contrasts. I think there, uh, is basically no significant difference between "incidental complexity" and "accidental complexity".

Fred Brooks could have identified a third problem: accidental complexity is fun; inherent complexity is boring.

Re: Simple Systems Have Less Downtime

#159

Post by cristaloleg »

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.

> Microservices are a design philosophy that people confuse as a deployment strategy.

I'm going to print this and show everyone, great words, thank you.

Re: Simple Systems Have Less Downtime

#160

Post by thethethethe »

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…

sure nuclear carriers cannot be dry docked and serviced like a container ship but they can be deployed for long periods of time without refueling and other routine services.

My point here is that the way you measure reliability is subjective and there are likely trade offs associated with “simplicity”

For example, having a global signal point of failure, like keeping all of your api servers in one cloud region, or having a single database with no replicas is much simpler and easy to understand than a more distributed alternative. However, global resources make your system more likely to fail catastrophically when there are outages.

There are trade offs here and _oftentimes_ in complexity arises in distributed systems because of reliability issues, not the other way around

Post reply on HN