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

Monolith First (2015)

martinfowler.com

Post reply on HN
Print view View original

271–280 of 356 posts

Re: Monolith First (2015)

#271

Post by mlthoughts2018 »

lllr_finger wrote: post #171
mlthoughts2018 wrote: post #154

Earlier quoted context omitted.

The article doesn’t have any connection to monorepo / polyrepo axis. You can use either repo structure for a monolith application, or use either repo structure for separated microservices. The article is just not related to repo structure in any way.

The article isn't related to repo structure, however repo structure can relate to the core issue of how to share code and maintain domain boundaries - search for the "umbrella" thread elsewhere in these comments.

Just because repo structure can relate doesn’t mean that such a relationship involves any properties of monorepo structure vs polyrepo structure.

Any messy code organization or dependency issue you can have in a monorepo, you can also have in polyrepos. Any automation or central controllership you can have in a monorepo, you can also have in polyrepos. Any scale-out chores or overhead work you can have with polyrepos, you can also have with monorepo.

The issues of monolith / poorly coupled dependency applications vs microservices has absolutely nothing to do with monorepo vs polyrepos. Neither option makes any class of tooling easier / harder to build or maintain. Neither makes conceptual organization easier / harder to get right, neither makes discoverability or cross-referencing easier or harder. That whole axis of concern is just fundamentally unrelated to the application monolith vs microservices question.

Re: Monolith First (2015)

#272

Post by ngc248 »

A monolith designed using Component Based architecture where each of the components has a well defined service boundary, can easily be split up into a microservices architecture. Each of the components from the monolith making up a subsequent microservice.

Re: Monolith First (2015)

#273

Post by pjmlp »

yeswecatan wrote: post #237
pjmlp wrote: post #31

Earlier quoted context omitted.

When the same practices used to sell microservices get applied to modules, packages and libraries, there is no need to put a network in the middle to do the linker's job. But too many are eager to jump into distributed computing without understanding what they are bring into their development workflow and debugging scenarios.

I've been trying to get buy-in from colleagues to have stricter boundaries between modules but without much success, mainly because I don't fully understand how to do it myself. Let's say we have 3 different modules, all domains: sales, work, and materials. A customer places an order, someone on the factory floor needs to process it, and they need materials to do it. Materials know what work they are for, and work kn…

It is a bit hard to just explain in a bunch of comments.

In your examples you need to add extra layers, just like you would do with the microservices.

There would be the DTOs that represent the actual data that gets across the models, the view models that package the data together as it makes sense for the views, the repository module that actually abstracts if the data is accessed via SQL, ORM, RPC or whatever.

You should look into something like:

"Domain-Driven Design: Tackling Complexity in the Heart of Software"

https://www.amazon.com/Eric-J-Evans/dp/0321125215

"Component Software: Beyond Object-Oriented Programming"

https://www.amazon.com/Component-Software-Beyond-Object-Orie...

Re: Monolith First (2015)

#274

Post by jlengrand »

I wonder what would the trend be without the push for the huge megacorps that couldn't do without microservices (MAGA mostly) that decided to start selling their cloud services.

Would they have kept them for themselves (including k8s), would microservices be just as fashionable? I'd really like to know the answer, while watching my friends startup of 4 people running they 14 microservices on a k8s cluster.

Re: Monolith First (2015)

#275

Post by k__ »

mlthoughts2018 wrote: post #270
k__ wrote: post #157

Earlier quoted context omitted.

I'd say, that's the problem with that article.

That wouldn’t make sense, given that repo structure truly is unrelated in any way to the distinctions between monolith applications vs microservices.

But it is.

If you have multiple services in one repo it's much easier to work on each of them.

Re: Monolith First (2015)

#276

Post by PragmaticPulp »

staticassertion wrote: post #252
dimitrios1 wrote: post #198

Earlier quoted context omitted.

"microservices turn function calls into distributed computing problems" -- tenderlove

This isn't really true though. It's not like you're suddenly adding consensus problems or something, you don't need to reinvent RAFT every time you add a new service. Microservices put function calls behind a network call. This adds uncertainty to the call - but you could argue this is a good thing. In the actor model, as implemented in Erlang, actors are implemented almost as isolated processes over a network. You c…

Distributed systems is more than just consensus protocols.

At minimum, you need to start dealing with things like service discovery and accounting for all of the edge cases where one part of your system is up while another part is down, or how to deal with all of the transitional states without losing work.

> Why? Because putting things behind a network can, counter intuitively, lead to more resilient systems

If you're creating resiliency to a set of problems that you've created by going to a distributed system, it's not necessarily a net win.

Re: Monolith First (2015)

#277

Post by a1369209993 »

disgruntledphd2 wrote: post #98
joana035 wrote: post #58

Earlier quoted context omitted.

Not to mention the operational overhead, which grows exponentially with the number of services, languages, frameworks and the sum of all their quirks.

Small nitpick, it's probably the product of their quirks rather than the sum.

It depends on whether you're measuring in the linear or logarithmic domain; eg 2 options * 2 options = 4 options, but 1 bit + 1 bit = 2 bits.

Re: Monolith First (2015)

#278

Post by staticassertion »

deckard1 wrote: post #263
staticassertion wrote: post #252

Earlier quoted context omitted.

This isn't really true though. It's not like you're suddenly adding consensus problems or something, you don't need to reinvent RAFT every time you add a new service. Microservices put function calls behind a network call. This adds uncertainty to the call - but you could argue this is a good thing. In the actor model, as implemented in Erlang, actors are implemented almost as isolated processes over a network. You c…

> putting things behind a network can, counter intuitively, lead to more resilient systems Erlang without a network and distribution is going to be more resilient than Erlang with a network. If you're talking about the challenges of distributed computing impacting the design of Erlang, then I agree. Erlang has a wonderful design for certain use cases. I'm not sure Erlang can replace all uses of microservices, however…

> Erlang without a network and distribution is going to be more resilient than Erlang with a network.

I doubt that this is supposed to be true. Erlang is based on the idea of isolated processes and transactions - it's fundamental to Armstrong's thesis, which means being on a network shouldn't change how your code is built or designed.

Maybe it ends up being true, because you add more actual failures (but not more failure cases). That's fine. In Erlang that's the case. I wouldn't call that resiliency though, the resiliency is the same - uptime, sure, could be lower.

What about in other languages that don't model systems this way? Where mutable state can be shared? Where exceptions can crop up, and you don't know how to roll back state because it's been mutated?

In a system where you have a network boundary, and if you follow Microservice architecture you're given patterns to deal with many others.

It's not a silver bullet. Just splitting code across a network boundary won't magically make it better. But isolating state is a powerful way to improve resiliency if you leverage it properly (, which is what Microservice architecture intends).

You could also use immutable values and all sorts of other things to help get that isolation of state. There's lots of ways to write resilient software.

Re: Monolith First (2015)

#279

Post by fulafel »

bulleyashah wrote: post #134
lmilcin wrote: post #93

Earlier quoted context omitted.

That is EXACTLY what I have observed, time and time again. If you have trouble managing ONE application what makes you think you will be better at managing multiple? Also, running distributed system is way more complicated than having all logic in a single application. Ideally you want to delay switching to distributed system until it is inevitable that you are not going to be able to fulfill the demand using monolit…

Monoliths are also distributed systems and will run on multiple hosts, most probably co-ordinating on some sort of state (and that state management will need to take care of concurrency, consistency). Some hosts will go down. Service traffic will increase. I understand your point. You are using distributed in the sense of "how is one big work distributed", you probably also hate overly "Object Oriented code" for simi…

Different kinds of distributed systems have wildly different complexity in possible fun that the distributed nature can cause. If you have a replicated set of monoliths, you typically have fewer exciting modes of behaviour and failures.

Consider how many unique communciation graph edges and multi hop causal chains of effects you have you have in a typical microservice system vs having replicated copies of the monolith running, not to mention the several reimplementations or slightly varying versions and behaviours of same.

Re: Monolith First (2015)

#280

Post by rantwasp »

mcny wrote: post #130
npteljes wrote: post #114

Earlier quoted context omitted.

I think this nails it. It's not the concept's fault if the implementation is half-assed.

> It's not the concept's fault if the implementation is half-assed. worse than that. Case in point: a major US national bank interview for a developer position. they talk about moving toward microservices. a simple question since they mention microservices: will someone be able to access and modify data data underneath my service without going through my service? the uneasy answer: yes, it does and will happen. that'…

sorry, that’s a distributed monolith. if everyone can mess with the data directly you might as well keep it in one service
Post reply on HN