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

171–180 of 243 posts

Re: Monoliths are not dinosaurs

#171

Post by grumpyprole »

Jtsummers wrote: post #78
sublinear wrote: post #74

Earlier quoted context omitted.

> Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The net gain was composability of microservices, distribution of computing resources, and the ability to marshall off implementation details. Just because those requirements were routinely ignored in the era of monoliths doesn't mean the complexity wasn't essential or didn'…

Before "microservices" there are services, which are also composable. And in the realm of monoliths there are also modules. Which are the key to composability. What microservices give you is a hard boundary that you cannot cross (though you can weaken it, you cannot eliminate it) between modules. This means the internal state of a module now has to be explicitly and more deliberately exposed rather than merely bypass…

> The challenge in monoliths is that the boundary is so easily breached

The biggest challenge with monoliths is the limits of a single process and machine.

Re: Monoliths are not dinosaurs

#172

Post by viraptor »

tored wrote: post #167
viraptor wrote: post #93

Earlier quoted context omitted.

Sure you could, but it would take a much longer time and you'd miss lots of functionality. How long would it take you to build user registration / verification / password recovery / 2fa / sso / profile editing / spam registration prevention / etc. ? How long would it take instead to include some Laravel module which does all of that? If you're building a service with some purpose, do you really want to spend days wri…

How many hours spent on battling Laravel to do what you want? How many hours spent on upgrading Laravel versions? Framework solves a general problem, but we try to solve a specific problem, thus it will always be a mismatch, frameworks usually solves that with a combination of magic and opaque abstraction layers. Frameworks works best for short running projects, long running projects tend to outgrow the framework. Pr…

That works for some things better then others. For example user management is hard to do as a library, because now you need to hook up all those actions / pass the data to them manually. Then make sure you handle all the headers correctly. Then handle the sessions/invalidation yourself. Potentially implement your custom authz as well because that's also happening throughout your app. There's still a lot of glue code that would be involved here - it may be worth trading it for the occasional Laravel upgrade.

Re: Monoliths are not dinosaurs

#173

Post by byyyy »

justinclift wrote: post #138
byyyy wrote: post #99

Earlier quoted context omitted.

>Complexity can neither be created nor destroyed, only moved somewhere else. Not true. I blow.up a car. Complexity is destroyed. I rebuild the car from blown up parts. Complexity is created. There's no underlying generic philosophical point about microservices and monoliths. What we can say is that microservices are not necessarily less complex than monoliths, but this relationship has no bearing on the nature of com…

> I blow.up a car. Complexity is destroyed. Wouldn't the blown-up car be more complex than the non-blown-up car?

In that case complexity is created thereby proving my point anyway.

Typically I define complexity as a low probability macrostate meaning low entropy. So debris generated from the explosion has a high probability of randomly occuring, while a new car has a very low probability of randomly occuring.

Following this definition you arrive at a formal definition of complexity that is intuitive.

Imagine a tornado that randomly reconfigures everything in it's wake. The more complex something is the less likely the tornado is going to reconfigure everything into that thing. So it is very likely for a tornado to reconfigure things into debris and extremely extremely unlikely for the tornado to reconfigure everything into a brand new car. A tornado reconfiguring atoms into a car seems to be impossible but it is not, it is simply a low probability nearly impossible configuration.

Therefore the car is more complex then exploded debris.

Think about this definition because it also aligns intuitively with the effort required and technical complexity of any object. The more effort and technical complexity it has the lower chance it has of a tornado randomly reconfiguring atoms to form that object. Thus that object is more "complex".

Whatever your definition is, the quote saying complexity cannot be created or destroyed is fundamentally from any perspective usually not true. If you want to define it as simply microservices or monoliths it still doesn't make sense. Whose to say that when converting a monolith to microservices that complexity remains conserved? Likely the complexity rises or lowers a bit or a lot. Complexity doesn't remain the same even if you use informal and inexact fuzzy definitions of complexity.

Re: Monoliths are not dinosaurs

#174

Post by przemo_li »

fredrikholm wrote: post #115
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.

I think it's reference to a team that can be satisfied with a pizza in take out event.

Increasing number of pizzas you get bigger teams.

Increasing number of microservices you assign more of them to a single team.

Re: Monoliths are not dinosaurs

#175

Post by switch007 »

eternalban wrote: post #149
jeswin wrote: post #106

HN could be a little less pessimistic. People aren't choosing microservices merely because of the hype. Here's why I'd choose microservices for a large project: 1. People don't produce uniform code quality. With microservices, the damage is often contained. 2. Every monolith is riddled with exceptional cases in a few years. Only a few people know about corner cases after a few years, and the company becomes dependent…

tldr: Microservices trade design complexity with operational complexity , to address the shortcomings & patterns of the modern IT sector, at both worker and management levels. This was an excellent choice for consulting (companies like ThoughtWorks, who were pushing microservices) as it optimized their workflows and bottom line: the answer to every client's question of "what's the architecture?" was "Microservices".…

> Microservices trade design complexity with operational complexity

Yup!

And it annoys me so much how architects/consultants get away with just proposing 'microservices' without being held responsible for all the increased operational complexity. It's left as something for devops to figure out later.

Re: Monoliths are not dinosaurs

#176

Post by tored »

bovermyer wrote: post #11

You know, I'm pretty sure you could build a PHP monolith in 2023 without a framework and it would do what it needed to do.

Yes, I recently built a small PHP example project for educational purposes and I intentionally avoided all external dependencies for demonstrating how you would solve things without a framework or library. You can do almost everything you need with plain PHP without too much effort except a few exceptions that you shouldn't waste your time on, most of them are tooling however and not for the application itself, like unit testing, error tracking and logging, database migration, but for that you of course use libraries.

Re: Monoliths are not dinosaurs

#177

Post by mrg3_2013 »

eternalban wrote: post #149
jeswin wrote: post #106

HN could be a little less pessimistic. People aren't choosing microservices merely because of the hype. Here's why I'd choose microservices for a large project: 1. People don't produce uniform code quality. With microservices, the damage is often contained. 2. Every monolith is riddled with exceptional cases in a few years. Only a few people know about corner cases after a few years, and the company becomes dependent…

tldr: Microservices trade design complexity with operational complexity , to address the shortcomings & patterns of the modern IT sector, at both worker and management levels. This was an excellent choice for consulting (companies like ThoughtWorks, who were pushing microservices) as it optimized their workflows and bottom line: the answer to every client's question of "what's the architecture?" was "Microservices".…

I would argue Microservices trade 100% design complexity with 100% operational complexity and 20% design complexity. Everytime I saw a microserviced design, I always wondered how would they debug this easily and re-operationalize it. Sometimes it is better to let the entire system die and spawn it back instead of having something running to make it look like it's alive.

Re: Monoliths are not dinosaurs

#178

Post by osigurdson »

kqr wrote: post #111
viraptor wrote: post #89

Earlier quoted context omitted.

> "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.)

Decomposing the system into libraries is just as effective from this perspective as decomposing into services however. The thing that a typical http API gives you is stability (documentation, versioning and a deprecation policy). This can be done with a library as well. We know this works as 3rd party libraries work well and no communication with the authors of the library is needed.

This is why I suggest team size is not a valid reason to break a problem into microservices. The problem itself is the thing to analyze.

Re: Monoliths are not dinosaurs

#179

Post by mrg3_2013 »

Havoc wrote: post #148

The whole debate is rather silly. Just pick the right architecture for the given problem. Sometimes it's monolith, sometimes it is not. The end.

This really is the issue. When you have no informed opinion, it may be better to start with monolith. This Microservice culture was all about "let me reduce the design complexity by using MS"

Re: Monoliths are not dinosaurs

#180

Post by mrg3_2013 »

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…

>>Understand what is ESSENTIAL complexity and what is INCIDENTAL complexity

Succintly put!

Post reply on HN