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

171–180 of 356 posts

Re: Monolith First (2015)

#171

Post by lllr_finger »

mlthoughts2018 wrote: post #154
caust1c wrote: post #151

I'm surprised that he doesn't mention the Monorepo + Microservice approach. I've found that most of the pain, confusion and bugs when dealing with microservice architectures has to do with the basic overhead of repo management, not the actual microservices themselves. If you have a monorepo, and you make a change to a schema (backwards compatible or not, intentional or not), it's a lot easier to catch that quickly wi…

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.

Re: Monolith First (2015)

#172

Post by dboreham »

100-xyz wrote: post #165

I work for a small company that uses microservices architecture. The product is simple where a user registers, enters preferences, selects from courses and submits a form. A monolith would be doable with 5 good engineers. Instead we have about 50 engineers+QA releasing bug filled code. The company's design philosophy is based more on what is fashionable that what is suitable.

> we have about 50 engineers

The plan worked.

Re: Monolith First (2015)

#173

Post by mumblemumble »

caust1c wrote: post #151

I'm surprised that he doesn't mention the Monorepo + Microservice approach. I've found that most of the pain, confusion and bugs when dealing with microservice architectures has to do with the basic overhead of repo management, not the actual microservices themselves. If you have a monorepo, and you make a change to a schema (backwards compatible or not, intentional or not), it's a lot easier to catch that quickly wi…

I've only had one experience with monorepo + microservice, and it wasn't to my taste. As the volume of code sharing increased, the whole thing became ever more monolithic and difficult to change.

Also, if you have a bunch of services all sharing the same schema, you aren't really doing microservices. Not because of some No True Scotsman, "Best practices or GTFO," sentiment, but because that design question, "Do services only communicate over formal interfaces, or do we allow back channels?", is the defining distinction between SOA and microservices. The whole point of the microservices idea was to try and minimize or eliminate those sorts of tight coupling traps.

Re: Monolith First (2015)

#174

Post by pjc50 »

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.

> there is no need to put a network in the middle to do the linker's job.

Absolutely. More people need to understand the binding hierarchy:

- "early binding": function A calls function B. A specific implementation is selected at compile+link time.

- "late binding": function A calls function B. The available implementations are linked in at build time, but the specific implementation is selected at runtime.

From this point on, code can select implementations that did not even exist at the time function A was written:

- early binding + dynamic linking: a specific function name is selected at compile+link time, and the runtime linker picks an implementation in a fairly deterministic manner

- late binding + dynamic linking: an implementation is selected at runtime in an extremely flexible way, but still within the same process

- (D)COM/CORBA: an implementation of an object is found .. somewhere. This may be in a different thread, process, or system. The system provides transparent marshalling.

- microservices: a function call involves marshalling an HTTP request to a piece of software potentially written by a different team and hosted in a datacenter somewhere on a different software lifecycle.

At each stage, your ability to predict and control what happens at the time of making a function call goes down. Beyond in-process functions, your ability to get proper backtraces and breakpoint code is impaired.

Re: Monolith First (2015)

#175

Post by marcosdumay »

wg0 wrote: post #136
bosswipe wrote: post #133

Earlier quoted context omitted.

If you're using microservice to enforce stronger interface boundaries what you're really relying on are separate git repos with separate access control to make it difficult to refactor across codebases. A much simpler way to achieve that same benefit is to create libraries developed in separate repos.

Wow. That's an interesting take on the problem of scaling a monolith without introducing the network between the system interactions.

Hum... People have been doing it since the 60's, when it became usual to mail tapes around.

If you take a look at dependency management at open source software, you'll see a mostly unified procedure, that scales to an "entirety of mankind" sized team without working too badly for single developers, so it can handle your team size too.

That problem that the "microservices bring better architectures" people are trying to solve isn't open by any measure. It was patently solved, decades ago, with stuff that work much better than microservices, in a way that is known to a large chunk of the developers and openly published all over the internet for anybody that wants to read about.

Microservices still have their use. It's just that "it makes people write better code" isn't true.

Re: Monolith First (2015)

#176

Post by dboreham »

iainmerrick wrote: post #52
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 com…

Conway/Gall duality.

Re: Monolith First (2015)

#177

Post by fragile_frogs »

measure2xcut1x wrote: post #120
lmilcin wrote: post #71

Hahaha. I have been saying the same for years but have either been punished by my managers or mercilessly downvoted on HN. Somehow mentioning that microservices might not be perfect solution in every case triggers a lot of people. I have actually helped save at least one project in a huge bank which got rolled from 140 services into one. The team got also scaled down to third of its size but was able to work on this…

> There are actually ways to manage huge monolithic application that don't require each team to have their own repository, ci/cd, binary, etc. Would be interested to hear about some of these.

A monorepo I guess. It looks like Microsoft is using a monorepo for their office applications (https://rushjs.io/) and you could do the same thing for node.js using yarn workspaces/lerna/rush.

Each "Microservice" could live in a separate package which you can import and bundle into single executable.

Elixir has "Umbrella Projects": https://elixirschool.com/en/lessons/advanced/umbrella-projec...

Rust/Cargo has workspaces: https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html

Re: Monolith First (2015)

#178

Post by lucideer »

100-xyz wrote: post #165

I work for a small company that uses microservices architecture. The product is simple where a user registers, enters preferences, selects from courses and submits a form. A monolith would be doable with 5 good engineers. Instead we have about 50 engineers+QA releasing bug filled code. The company's design philosophy is based more on what is fashionable that what is suitable.

Anec-contra-data:

I worked for a while at a small startup, initially as the sole developer and eventually growing to 3. We had an architecture I would describe as at least being "microservices-esque": a single large "monolithic" backend service, with a number of smaller consumer services, webapps, UIs.

The distinction between microservices and monoliths may be debatable but I believe monoliths as described by Martin Fowler typically involve your primary service logic and your UI coexisting. I've found that splitting these at least is usually fruitful.

I think this approach is sometimes called "fan-out", though I've seen that term used to describe other different things too; namely the opposite where there's a single monolithic UI layer fanning out to many micro upstreams.

TL;DR: Fowler's opening 2 bullet points seem likely to be a false dichotomy as he's force-classifying all architectures into two buckets.

Re: Monolith First (2015)

#179

Post by sublimefire »

lmilcin wrote: post #71

Hahaha. I have been saying the same for years but have either been punished by my managers or mercilessly downvoted on HN. Somehow mentioning that microservices might not be perfect solution in every case triggers a lot of people. I have actually helped save at least one project in a huge bank which got rolled from 140 services into one. The team got also scaled down to third of its size but was able to work on this…

LOL I'm in talks of migrating microservices into a monolith purely because there is so much overhead at managing it. You need at least a couple of people to keep it in place. And the latter means the company is prepared to kill the product even when there are actual customers plus new ones are coming.

Microservices make sense when you have millions of users and there is a need to quickly scale horizontally. Or when you have a zillion of developers which probably means that your product is huge. Or when you are building a global service from the get go and get funded by a VC.

Re: Monolith First (2015)

#180

Post by sk5t »

dboreham wrote: post #172
100-xyz wrote: post #165

I work for a small company that uses microservices architecture. The product is simple where a user registers, enters preferences, selects from courses and submits a form. A monolith would be doable with 5 good engineers. Instead we have about 50 engineers+QA releasing bug filled code. The company's design philosophy is based more on what is fashionable that what is suitable.

> we have about 50 engineers The plan worked.

Clearly something is working if you've got 50 engineers turning out bug-filled code and systems, and yet the business keeps on living.
Post reply on HN