Simple Systems Have Less Downtime • Hacker News Board

Re: Simple Systems Have Less Downtime

#161

Post by goostavos » Tue, Mar 03, 2020, 5:04 PM UTC

SPBS wrote: post #153

nickbauman wrote: post #146

Earlier quoted context omitted.

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.

"Enforce" gets thrown around a lot, but that's approaching silver bullet expectation levels, in my opinion.

A core skill problems on a team that would prevent building a maintainable monolith do not go away because you've added more things for them to manage.

Re: Simple Systems Have Less Downtime

#162

Post by harrisreynolds » Tue, Mar 03, 2020, 5:05 PM UTC

This is a very important idea. I like the shipping container metaphor. I have often used the idea of a 2x4 (as in lumber) in building houses. The humble 2x4 is such a simple product, but when put together with nails and screws becomes the cornerstone of a complex structure.

It is simple and it just works for its intended purpose.

I am working hard to apply this to the design of Webase [1] which is a #nocode platform that is inherently complex. But I really believe that if we get the design right it will support a large number of sophisticated use-cases.

Thank you for sharing!

[1] https://www.webase.com

Re: Simple Systems Have Less Downtime

#163

Post by dilap » Tue, Mar 03, 2020, 5:06 PM UTC

I totally agree when designing man-made, synthetic systems. But it is interesting to consider that the most reliable, self-healing systems that exist -- animals! -- are incredibly complicated...

Re: Simple Systems Have Less Downtime

#164

Post by papito » Tue, Mar 03, 2020, 5:07 PM UTC

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.

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?

Re: Simple Systems Have Less Downtime

#165

Post by ska » Tue, Mar 03, 2020, 5:10 PM UTC

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.

This is a valid criticism, but it's not lisp specific.

We know somewhat how to control accidental complexity in systems that are highly constrained and don't let you deal well with essential complexity. And we know somewhat how to give you powerful tools to deal with essential complexity.

We haven't figured out in general how to make systems powerful enough to deal with the range of essential complexity, but constrained enough that this sort of accidental complexity isn't common.

Of course a lot of real world systems don't do a great job of either.

Re: Simple Systems Have Less Downtime

#166

Post by rantwasp » Tue, Mar 03, 2020, 5:11 PM UTC

dilap wrote: post #163

I totally agree when designing man-made, synthetic systems. But it is interesting to consider that the most reliable, self-healing systems that exist -- animals! -- are incredibly complicated...

there is a difference between complex and complicated. Also consider that systems where complexity serves a role are not complicated. Also: simple things that are aggregated into complex things through a hierarchy that is also simple can be reasoned about with failure happening subsystem level (and can be easily mitigated - think supervision trees in erlang)

Re: Simple Systems Have Less Downtime

#167

Post by rantwasp » Tue, Mar 03, 2020, 5:13 PM UTC

plug for my all time favorite paper in the subject https://web.mit.edu/2.75/resources/random/How%20Complex%20Sy...

5 pages of pure awesomeness

Re: Simple Systems Have Less Downtime

#168

Post by somurzakov » Tue, Mar 03, 2020, 5:17 PM UTC

speedgoose wrote: post #19

It's important to find a compromise. The simplest system at my work would be something like a php/mysql backend hosted on a old fashion shared server using ftp. Good luck attracting good developers with that. We use something over engineered but we have fun. The customers don't care but we do.

There are a lot of companies where Senior PHP devs are paid more than Senior Java devs, because it is so hard to find a brilliant PHP dev

Re: Simple Systems Have Less Downtime

#169

Post by awinter-py » Tue, Mar 03, 2020, 5:18 PM UTC

> features don't justify complexity

Such a good line. I've seen companies killed by hard-to-follow arguments advocating for technical complexity which serves feature goals which serve business goals.

'Good strategy is simple' from some strategy book is sometimes right; arguments that hold business goals hostage to technical complexity are trouble.

Re: Simple Systems Have Less Downtime

#170

Post by matchagaucho » Tue, Mar 03, 2020, 5:19 PM UTC

Declarative coding tools are to blame here.

This is a well written article, but the metaphor is a little stretched.

Marketo and Salesforce are the "ship builders". Marketers are the crew operating the ship.

The declarative tools in enterprise apps provide Marketers with conditional branch and execution capabilities without code structure, so the average Marketer just keeps adding layers of complexity. Whereas a Developer would continually refactor and make old code obsolete.

The crew operating actual ships do not have anywhere near this level of access to the ships configuration, hence more reliability in the system.