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

121–130 of 271 posts

Re: Simple Systems Have Less Downtime

#121

Post by gk1 »

_wldu wrote: post #52

This tactic is also used to criticize/de-legitimize existing, working solutions when a new manager wants his old, familiar environment. "What Bob's team built is far too complex. If we replace it with the system I used at my last company, it will be much simpler." If I had a dollar for every time I've seen this type of thing, I'd be rich. So be careful you are not just playing corporate politics and changing solution…

Totally. Funny enough, marketing platforms like those mentioned in the essay are usually the first things to get replaced when a new VP or CMO joins. Too often, unfortunately, that decision is made not because it's the best tool for the company but because it's the most familiar one.

Re: Simple Systems Have Less Downtime

#122

Post by gk1 »

stormdennis wrote: post #13

His website had this annoying message about subscribing for updates that has no obvious way of getting rid of it excepting by clicking the accept button. I guess that's simpler than having an additional "no thanks" button. The article was a formulaic retelling of well known wisdom too.

Hey, there is an X in the corner to close it. The subscription slider is made by Mailchimp so I don't have much control over the size of that X, unfortunately.

Re: Simple Systems Have Less Downtime

#123

Post by darkerside »

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.

Underrated point, although incomplete from my perspective. 2 simple systems > 1 complex system.

But 1 semi-complex system > 10 simple systems. Especially when you consider the points of integration between those systems increases geometrically with the number of systems.

Re: Simple Systems Have Less Downtime

#124

Post by dspillett »

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.

Microservices are simple components of what could be a simple or a complex system. If things are overly broken down then unnecessary complexity could easily be added.

Re: Simple Systems Have Less Downtime

#126

Post by mplanchard »

modo_mario wrote: post #74
monus wrote: post #7

Usually, being easy is confused with being simple. Easy to use systems usually tend to be very complex but they'd only hide it from the average user. Once you go one step ahead, do something outside of quick start, you find yourself helpless. In that sense, the article is on point. Not only the management of the ship is simple, machinery behind the scenes is simple as well. This applies to programming languages, too.…

>On the other hand, Go (and Rust supposedly, but I don't have experience) is simple. I was reading most if this yesterday which seems to disagree: https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild...

I really enjoyed this article. Thanks for linking it!

It’s interesting to see the relative naïveté in some of the implementations of what seem to be relatively key builtin libraries like file pathing. I also have never had to deal with cross platform support in Go, so I’d never seen the magic compilation comments/suffixes.

Re: Simple Systems Have Less Downtime

#127

Post by lincpa »

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.

Clojure is simpler than Common Lisp, but I still feel that the features are too many and too complicated, and continue to simplify, do not use some complex features, and insist on writing systems with pure pipeline structure.

As a result, the simplest system is obtained, but the design process is a systematic project.It is difficult to design a complex system into a simple and smooth pipeline system.

Re: Simple Systems Have Less Downtime

#128

Post by AnIdiotOnTheNet »

ailideex wrote: post #21
mhd wrote: post #15

Earlier quoted context omitted.

If Unix is your yardstick for simplicity, that just shows how far we've come…

Linux is incredibly simple compared to Windows once you actually your computer as a computer instead of as a really poorly made gaming console.

Bullshit. You're talking about an operating system where the common advice for someone who wants to install up to date software is to fucking compile it from source because the whole community never got their collective shit together enough to allow developers to directly distribute binaries without a gigantic fucking headache.

Christ, it's such a fucking mess that one of the most compatible ways to distribute software is to write it for Windows and rely on WINE.

Re: Simple Systems Have Less Downtime

#129

Post by hopia »

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.

Microservices make you architect your whole service differently. The communication is essentially asynchronous message passing which may or may not make things more difficult.

Re: Simple Systems Have Less Downtime

#130

Post by ignoramous »

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.

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/c12cYAUTXXs

[1] https://www.youtube-nocookie.com/embed/wDk6l3tPBuw

[2] https://www.youtube-nocookie.com/embed/93MA0VUWP9w

[3] https://www.youtube-nocookie.com/embed/TneLO5TdW_M

Post reply on HN