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

221–230 of 356 posts

Re: Monolith First (2015)

#221

Post by lifeisstillgood »

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'…

Thats a distinction worth following up:

My take is there are 3 kinds of micro-service

* Service Ownership of data - if you want to change customer name, there is only one place to go.

* Worker services - they don't really own data, they process something - usually requesting from golden sources. Just worker bees but the thing they do (send out marketing emails to that persons name) is not done by anyone else

* Everything else is borked

Re: Monolith First (2015)

#222

Post by cowsandmilk »

ngngngng wrote: post #14

With this in mind, if I were to start a new project today (using Go, which is all I use anymore). I would segment my code inside of a monolith using interfaces. This would incur a very slight initial cost in the organization of the codebase prior to building. As your usage goes up and the need to scale parts of it increases, you could swap these interfaces out little by little by reimplementing the interface to conta…

My experience is that micro services are a method to enforce modularity. You don’t have any choice other than talking over interfaces (assuming you don’t cheat by sharing a database). Keeping things modular in a monolith requires discipline that is enforced by reviewing everyone else’s code.

Re: Monolith First (2015)

#223

Post by xxs »

notfed wrote: post #209
throwaway4good wrote: post #122

Martin. The archicture astronaut. Finally returning to earth. Landing the same spot where he took off. But wiser ...

Keep in mind this article was written in 2015.

As long as they are books to sell and conferences to present at, it's all cool and dandy.

Re: Monolith First (2015)

#224

Post by Shicholas »

Monoliths are even easier to manage in 2021 because of workspace dependency management (e.g. yarn workspaces, cargo workspaces) etc. You can have your cake (microservices built as separate packages) and eat it too (a monorepo workspace w/ all your code).

Re: Monolith First (2015)

#225

Post by galangalalgol »

pjmlp wrote: post #169
jameshart wrote: post #152

Earlier quoted context omitted.

If you think of microservices as a modularization tool - a way to put reusable code in one place and call it from other places - then you are missing the point. Microservices don’t help solve DRY code problems. Monoliths aren’t merely monolithic in terms of having a monolithic set of addressable functionality; they are also monolithic in terms of how they access resources, how they take dependencies, how they are bui…

Monoliths don't have to be deployed as single instance. In any case, too many rush for micro-services with the intent reason to use the network as a package boundary. Have you ever tried to debug spaghetti RPC calls across the network? I sadly have.

Adding to the theme of microservices overhead, I feel like the amount of almost-boilerplate code used to get and set the contents of serialized data in the service interfaces exceeds the code used to actually do useful work even in medium sized services, much less microservices.

Re: Monolith First (2015)

#226

Post by btilly »

pjmlp wrote: post #169
jameshart wrote: post #152

Earlier quoted context omitted.

If you think of microservices as a modularization tool - a way to put reusable code in one place and call it from other places - then you are missing the point. Microservices don’t help solve DRY code problems. Monoliths aren’t merely monolithic in terms of having a monolithic set of addressable functionality; they are also monolithic in terms of how they access resources, how they take dependencies, how they are bui…

Monoliths don't have to be deployed as single instance. In any case, too many rush for micro-services with the intent reason to use the network as a package boundary. Have you ever tried to debug spaghetti RPC calls across the network? I sadly have.

Why yes, I have.

It is essentially impossible without the (sadly rare) design pattern that I gave at https://news.ycombinator.com/item?id=26016854.

Re: Monolith First (2015)

#227

Post by delecti »

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…

A sister team at work (same manager, separate sprints) split a reasonable component into three microservices. One with business logic, one which talks to an external service, and one which presents an interface to outside clients. They then came to own the external service as well. So now they have 4 micro services when one or two would have been plenty. I don't hesitate to poke fun when that inevitably brings them frustration. Another team we work with has their infrastructure split across a half-dozen or more microservices, and then they use those names in design discussions as though we should have any idea which sub component they're talking about. Microservices are a tool that fits some situations, but they can be used so irresponsibly.

Re: Monolith First (2015)

#228

Post by LargeWu »

bulleyashah wrote: post #193
danielheath wrote: post #148

Earlier quoted context omitted.

That’s because those things are only simple when they’re working. Each of them introduces a new, rare failure mode; because there are now many rare failure modes, you have frequent-yet-inexplicable errors. Dead letter queues back up and run out of space; network splits still happen;

Sounds like you're saying "Don't do distributed work" if possible (considering tradeoffs of course, but I guess people just don't even consider this option is your contention). And secondly, if you do end up with q distributed systems, remember how many independently failing components there are because thag directly translates to complexity. On both these counts I agree. Microservices is no silver bullet. Network pa…

I'm not reading this as "Don't do distributed work". It's "distributed systems have nontrivial hidden costs". Sure, monoliths are often synonymous with single points of failure. In theory, distributed systems are built to mitigate this. But unfortunately, in reality, distributed systems often introduce many additional single points of failure, because building resilient systems takes extra effort, effort that oftentimes is a secondary priority to "just ship it".

Re: Monolith First (2015)

#229

Post by mooreds »

pjc50 wrote: post #174
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.

> 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…

Thanks, this was a great overview of the various ways to bind a function call to an implementation.

Re: Monolith First (2015)

#230

Post by geodel »

pjmlp wrote: post #214
jameshart wrote: post #190

Earlier quoted context omitted.

It is possible that there are architectures other than ‘monolith’ and ‘microservices’. Component architectures are also a thing. If it doesn’t all deploy in one go, I don’t think it’s a monolith.

Certainly, the microservices cargo cult has ensured that everything that isn't a microservices, is now a monolith.

LOL. This is excellent point. At my workplace one might just get fired if they talk anything other than microsevice for any new development.
Post reply on HN