Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monoliths are not dinosaurs

allthingsdistributed.com

Post reply on HN
Print view View original

111–120 of 243 posts

Re: Monoliths are not dinosaurs

#111

Post by kqr »

viraptor wrote: post #89
osigurdson wrote: post #67

I think the first step toward sanity is to stop factoring services by team sizes - “we have 100 people so require 20 microservices”. Instead, factor services along natural fault lines. These are areas in the solution that scale differently from other parts and can tolerate communicating over http or message queue. It is fine to have lots of people work on a single service. We compose things using 3rd party libraries…

> "we have 100 people so require 20 microservices" Is this something that actually happened? Not heard from some third party - actually has someone experienced this as a decision in a technical team? It seems... unlikely.

This is an application of Conway's law. If we want small five-person teams then there are 20 teams and it makes sense to simplify communication by decomposing the system into 20 parts.

(Not saying it's the right way to do things, just the natural way to optimise if you need to keep 20 teams busy working on one system. I think the incorrect assumption is that all 20 teams need to be busy doing the same thing.)

Re: Monoliths are not dinosaurs

#112

Post by byyyy »

ozim wrote: post #103
byyyy wrote: post #98

Earlier quoted context omitted.

Because we can't definitively prove which one is better. There is no formal theory around system design so you get people complaining about how monoliths are error prone and way too complex and you get people complaining about microservices with the exact same argument. The result is that with a period of about a decade the industry just oscillates between the two methodologies in an endless flat circle. Monoliths wi…

Fun part is there is no “better” in generic terms. Another fun part is that people on the internet complain but without merit. I cannot judge some project because I usually don’t know the project. So might as well be that monolith or not team was having high attrition or there might be many other things that would affect project.

>Fun part is there is no “better” in generic terms.

No. It goes further then this. We actually don't even know if one is better or not.

There is no formal theory that allows us to prove these designs. For example we have formal theory behind algorithm complexity that quantifies runtime cost but no such theory exists for engineering design patterns. We aren't even sure what to quantify.

But just because a formal theory doesn't yet exist doesn't mean one can be developed in the future. Until then these system designs will be like history... Always repeating itself.

Re: Monoliths are not dinosaurs

#113

Post by benjiweber »

viraptor wrote: post #89
osigurdson wrote: post #67

I think the first step toward sanity is to stop factoring services by team sizes - “we have 100 people so require 20 microservices”. Instead, factor services along natural fault lines. These are areas in the solution that scale differently from other parts and can tolerate communicating over http or message queue. It is fine to have lots of people work on a single service. We compose things using 3rd party libraries…

> "we have 100 people so require 20 microservices" Is this something that actually happened? Not heard from some third party - actually has someone experienced this as a decision in a technical team? It seems... unlikely.

It's usually a consequence of something like Bezos' API mandate https://api-university.com/blog/the-api-mandate/

Multi-team ownership of a single deployable has downsides to tradeoff against the complexity of more service and harder boundaries.

Re: Monoliths are not dinosaurs

#114

Post by jpalomaki »

"Since its launch in 2006 with just a few microservices, (AWS) S3 has grown to over 300," I would love if articles like this would give a bit more context on the size of codebase and team.

Like is it two pizzas per microservice or 10 microservices per one pizza.

Re: Monoliths are not dinosaurs

#115

Post by fredrikholm »

jpalomaki wrote: post #114

"Since its launch in 2006 with just a few microservices, (AWS) S3 has grown to over 300," I would love if articles like this would give a bit more context on the size of codebase and team. Like is it two pizzas per microservice or 10 microservices per one pizza.

> Like is it two pizzas per microservice or 10 microservices per one pizza.

Nearly spat out my coffee. Thank you for making my morning.

Re: Monoliths are not dinosaurs

#116

Post by kqr »

osigurdson wrote: post #67

I think the first step toward sanity is to stop factoring services by team sizes - “we have 100 people so require 20 microservices”. Instead, factor services along natural fault lines. These are areas in the solution that scale differently from other parts and can tolerate communicating over http or message queue. It is fine to have lots of people work on a single service. We compose things using 3rd party libraries…

Could you elaborate on what you mean by "natural fault lines"? The rest of that paragraph seems to refer to performance -- is that the criterion? Do the natural fault lines shift if you manage to optimise the performance of a component, so that it starts scaling at the same rates as its neighbours?

Re: Monoliths are not dinosaurs

#117

Post by deterministic »

paulddraper wrote: post #37

Software would be 50% better if every developer understood Tesler's Law: "Complexity can neither be created nor destroyed, only moved somewhere else." The drive to simplify is virtuous, but often people are blind to the complexity that it adds. Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The correct solution depends on…

Not true. You can make any system arbitrarily complex. And 95% of software developers IMHO are hell-bent on proving that true every single day. Micro-services is a GREAT example of this.

Re: Monoliths are not dinosaurs

#118

Post by ed_elliott_asc »

paulddraper wrote: post #37

Software would be 50% better if every developer understood Tesler's Law: "Complexity can neither be created nor destroyed, only moved somewhere else." The drive to simplify is virtuous, but often people are blind to the complexity that it adds. Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The correct solution depends on…

Does Tesler’s law apply to lines of code or architecture?

I have absolutely seen complex code that was created (often for perceived “best practices” like DRY) which could be removed by simplifying the code.

Re: Monoliths are not dinosaurs

#119

Post by marginalia_nu »

klabb3 wrote: post #65
Aeolun wrote: post #45

Earlier quoted context omitted.

If you can have a monolith for $500/month with a team of 2, or a distributed system for $50,000/month with a team of 50, what manager in their right mind would choose the former. Zero prestige in that.

Not just managers, but the senior engineers too. You can aggregate all the inter-service communication and say that you’re managing 1000 QPS service mesh rather than a meager backend with 10 QPS.

Not to mention the resume padding technology.

You can no longer claim to have expertise in OpenShift, Redis, Kafka and RabbitMQ and machine learning from having implemented a todo app :-(

Re: Monoliths are not dinosaurs

#120

Post by Zanfa »

A good rule of thumb is that if you’re starting a new project and immediately implement microservices, you’ve already failed.

Never seen it work, don’t think I ever will. The only way microservices can ever work is if they’re extracted over time as the monolith gets fleshed out, likely over the course of years. And even they’re probably a bad idea.

Post reply on HN