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

111–120 of 271 posts

Re: Simple Systems Have Less Downtime

#111

Post by nickbauman »

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.

Re: Simple Systems Have Less Downtime

#112

Post by krab »

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 operations. But if your team grows, your release cycle will slow down unless you decentralize it.

Re: Simple Systems Have Less Downtime

#113

Post by gk1 »

taneq wrote: post #60
emerongi wrote: post #47

The author is not arguing for simplicity per se, but about being able to insert a human into a system that is normally automated. The example about the ship's steering system is perfect, actually. The system is not "simple" (if I were on a ship and the steering failed, I would be clueless), but it provides plenty of interjection points where a knowledgeable human can step in and either debug or fix the issue. It's th…

Agreed, the first bit of the article isn't about simplicity as much as it is about visibility and the ability to directly control each aspect. This is very much in line with how modern SCADA systems are designed (and indeed the ship example is one of these). Each component can run automatically based on sensors and the state of its peers, or it can be directly controlled by the operator if required. The latter part o…

I considered using other labels besides "simple," like "redundant" or "straightforward," but decided no matter what word I used some ambiguity would remain. So I stick with "simple" and hoped the context would help carry the point across. I'm glad that it did, as it seems.

Re: Simple Systems Have Less Downtime

#114

Post by nickbauman »

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

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.

Re: Simple Systems Have Less Downtime

#115

Post by wpietri »

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…

Did you actually read the article? He makes it quite clear why the lesson of simplicity applies to a container ship. Analogy is not homology. Just because container ships are part of a complex system does not mean that the steering system isn't valuably simple compared with other alternatives. And it definitely doesn't mean we can't learn a lesson from that.

Also, I think this is straight up wrong:

> If you are building software (a full SaaS solution), [...] That's a huge undertaking that requires massive engineering efforts. It's not a simple task.

If you believe it will require "massive" engineering efforts, you will certainly prove yourself right. But quite a lot of people do it differently. Look at Amazon's rule about two-pizza teams, for example. Or just this week I visited a ~30-person company that's been going 8 years with a successful SaaS business. They have a team of 4 developers, and it works just fine because they work to keep things simple.

Re: Simple Systems Have Less Downtime

#116

Post by gk1 »

ddevault wrote: post #96

This article misses one crucial point in suggesting Looker over "a patchwork of custom scripts and APIs". The complexity doesn't go away because you offload it to Looker. When Looker goes down, your application is still in trouble. It's still your responsibility when your system goes down, even if you can point the finger at some third party service. Your system is still down! That being said, don't use Looker in the…

Several people pointed out the fault in using Looker as an example. I very much welcome suggestions for a different product to plug there!

Re: Simple Systems Have Less Downtime

#117

Post by lincpa »

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

Re: Simple Systems Have Less Downtime

#119

Post by gk1 »

notyourday wrote: post #65
vezycash wrote: post #16

Using the company this author helped to migrate to hubspot as an example. I'm not sure if the simpler solution - hubspot existed when the company started hacking solutions together. Also, the move to hobspot was relatively easy because the business processes and workflows were already well known and defined. Starting from scratch, fighting the fires as they appear, a bit of patchwork seems unavoidable. Everything is…

> I'm not sure if the simpler solution - hubspot existed when the company started hacking solutions together. Author's value proposition is "I will help you outsource your complicated marketing tools". If you reject the gospel that your marketing tools are complicated, author's service would be not needed.

Not the intention at all. My job is to parachute into a startup facing some problem, fix the problem quickly, and get out. I have no business being at a startup that's running perfectly, or creating solutions that will require me to stick around.

Re: Simple Systems Have Less Downtime

#120

Post by krab »

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.

The complexity is still somewhere. You can structure your monolith in a way that you can read each module's code in ~15 minutes. Each module also can be developed and tested in isolation.

However, if the organization is not capable of structuring the monolith, why should it be successful with microservices?

Such organization may lead to sharing data stores and custom libraries between microservices and that's when the real fun begins. Maybe even trying to deploy all of the services atomically to not worry about API compatibility.

Post reply on HN