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

51–60 of 356 posts

Re: Monolith First (2015)

#51

Post by pjmlp »

tutfbhuf wrote: post #40
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.

When I started programming, linking was the only way of packaging software in mainstream computing, if it was so superior we wouldn't have moved away from it.

Here is the thing, whatever you write doesn't work without linking, so no we never moved away from it.

Re: Monolith First (2015)

#52

Post by iainmerrick »

ser0 wrote: post #4

A more common scenario I see is that people start with a monolith that ends up inheriting all the conceptual debt that accumulates as a project evolves. All this debt builds up a great desire for change in the maintaining team. A champion will rise with a clean architecture and design in microservice form that addresses all high visibility pain points, attributing forecasted benefits to the perceived strengths of mic…

I think the key point of Fowler’s article, which is obscured a little by all the monolith discussions, is that try to start with microservices doesn’t work. He’s claiming this from an empirical point of view -- if you look at successful, working systems, they may use microservices now but they most often started as monoliths.

People are talking about Conway’s law, but the more important one here is Gall’s law: “A complex system that works is invariably found to have evolved from a simple system that worked.”

Re: Monolith First (2015)

#53

Post by radicalbyte »

andy_ppp wrote: post #26
Chyzwar wrote: post #16

Earlier quoted context omitted.

There is one approach Fowler suggested is SacrificialArchitecture. You build your monolith quickly, get to market fit and once you understand service boundaries you move to microservices. Personally I would like to try Umbrella Projects[1]. You can design it as microservices but deploy and build as monolith. Overhead is lower, and it is easier to figure out right services when in one codebase. It can be easy implemen…

This! Service boundaries are vital and almost intractable to design up front as you won’t be sure of your systems’ use cases. I’ve worked on numerous micro services systems and all of them were designed in such a way that data loss and unknown error states were mandatory. Micro services seem simpler, but are actually harder than my methodology “as few services as necessary” + bounded contexts within them. Using netwo…

This is why Domain Driven Design should be mandatory reading for all anyone making decisions on Software Architecture.

Re: Monolith First (2015)

#54

Post by diroussel »

pjmlp wrote: post #51
tutfbhuf wrote: post #40

Earlier quoted context omitted.

When I started programming, linking was the only way of packaging software in mainstream computing, if it was so superior we wouldn't have moved away from it.

Here is the thing, whatever you write doesn't work without linking, so no we never moved away from it.

But is linking the right way to couple business logic from two different organisational units?

That is the question being discussed.

Re: Monolith First (2015)

#55

Post by sublimefire »

The fact that we talk about it raises some questions. Surely it depends on the problem at hand. There are multiple companies solving various issues and those are either global or local, well defined or ambiguous. There is no one approach as it depends on where you stand at the moment as well. Another problem is developers themselves as they are incentivized to push for "over-engineering" as it'll make their CVs look better.

Re: Monolith First (2015)

#57

Post by radicalbyte »

Chyzwar wrote: post #16
ser0 wrote: post #4

A more common scenario I see is that people start with a monolith that ends up inheriting all the conceptual debt that accumulates as a project evolves. All this debt builds up a great desire for change in the maintaining team. A champion will rise with a clean architecture and design in microservice form that addresses all high visibility pain points, attributing forecasted benefits to the perceived strengths of mic…

There is one approach Fowler suggested is SacrificialArchitecture. You build your monolith quickly, get to market fit and once you understand service boundaries you move to microservices. Personally I would like to try Umbrella Projects[1]. You can design it as microservices but deploy and build as monolith. Overhead is lower, and it is easier to figure out right services when in one codebase. It can be easy implemen…

We have exactly the same construct in .Net: a solution file which can contain multiple projects. All of the code is in one place, so you're working with a monolith^. Services are separate and dependencies are checked by the compiler/toolchain - so you design as microservices. Finally deployment is up to you - you can deploy as Microservices, or as one big Monolith.

^ Compile times are fast so this isn't an issue like it can be in other languages.

Re: Monolith First (2015)

#58

Post by joana035 »

pjmlp wrote: post #31
ser0 wrote: post #4

A more common scenario I see is that people start with a monolith that ends up inheriting all the conceptual debt that accumulates as a project evolves. All this debt builds up a great desire for change in the maintaining team. A champion will rise with a clean architecture and design in microservice form that addresses all high visibility pain points, attributing forecasted benefits to the perceived strengths of mic…

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.

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

Re: Monolith First (2015)

#60

Post by fvdessen »

pjmlp wrote: post #31
ser0 wrote: post #4

A more common scenario I see is that people start with a monolith that ends up inheriting all the conceptual debt that accumulates as a project evolves. All this debt builds up a great desire for change in the maintaining team. A champion will rise with a clean architecture and design in microservice form that addresses all high visibility pain points, attributing forecasted benefits to the perceived strengths of mic…

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.

It is much harder to enforce the discipline of those practices across modules boundaries than around network boundaries. So in theory yes you could have a well modularized monolith. In practice it is seldom the case.

The other advantage of the network boundary is that you can use different languages / technologies for each of your modules / services.

Post reply on HN