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

191–200 of 356 posts

Re: Monolith First (2015)

#191

Post by bulleyashah »

marcosdumay wrote: post #185
bulleyashah wrote: post #134

Earlier quoted context omitted.

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…

> But distributed systems is a well understood thing in the industry. Wait, what? Distributed systems are one of the most active areas on CS currently. That's the opposite of "well understood". It's true that most systems people create are required to be distributed. But they are coordinated by a single database layer that satisfies approximately all the requirements. What remains is an atomic facade that developers…

Correct. That doesn't make monolithic systems "not distributed".

Secondly, I don't know why you say "distributed systems are an active area of research" and use this as some sort of retort.

If I say "Is a monolithic app running on two separate hosts a distributed system or not", if your answer is "We don't know, it's an active area of research" or "It's not. Only microservices are distributed"

Re: Monolith First (2015)

#192

Post by jimbokun »

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 would propose alternative is to fix your monolith first. If the team can't rewrite their ball of mud as a new monolith, then what are the chances of successfully rewriting and changing architecture?

Often, the problems with the monolith are

* different parts of the monolith's functionality need to scale independently, * requirements for different parts of the monolith change with different velocity, * the monolith team is too large and it's becoming difficult to build, test, and deploy everyone's potentially conflicting changes at a regular cadence, with bugs in one part of the code blocking deploying changes to other parts of the code.

If you don't have one of these problems, you probably don't need to break off microservices, and just fixing the monolith probably makes sense.

Re: Monolith First (2015)

#193

Post by bulleyashah »

danielheath wrote: post #148
bulleyashah wrote: post #131

Earlier quoted context omitted.

I mean, you can always deploy your microsevices on the same host, it would just be a service mesh. Adding network is not a limitation. And frankly, I don't understand why you say things like understanding network. Like reliability is taken care of, routing is taken care of. The remaining problems of unboundedness and causal ordering are taken care of (by various frameworks and protocols). For dlq management, you can…

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 partitions and failure happen almost every day where I work. But most people are not dealing with that level of problems, partly because of cloud providers.

Same kind of problems will be found on a single machine also. Like you'd need some sort of write ahead log, checkpointing, maybe optimize your kernel for faster boot up, heap size and gc rate.

All of these problems do happen, but most people don't need to think about it.

Re: Monolith First (2015)

#194

Post by stepbeek »

jimbokun wrote: post #192
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 would propose alternative is to fix your monolith first. If the team can't rewrite their ball of mud as a new monolith, then what are the chances of successfully rewriting and changing architecture? Often, the problems with the monolith are * different parts of the monolith's functionality need to scale independently, * requirements for different parts of the monolith change with different velocity, * the monolit…

> the monolith team is too large and it's becoming difficult to build, test, and deploy everyone's potentially conflicting changes at a regular cadence, with bugs in one part of the code blocking deploying changes to other parts of the code.

This is the only argument I'm ever really sold on for an SOA. I wonder if service:engineer is a ratio that could serve as a heuristic for a technical organization's health? I know that there are obvious counter-examples (shopify looks like they're doing just fine), but in other orgs having that ratio be too high or too low could be a warning sign that change is needed.

Re: Monolith First (2015)

#196

Post by NationalPark »

pjc50 wrote: post #167
bulleyashah wrote: post #134

Earlier quoted context omitted.

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…

> Monoliths are also distributed systems and will run on multiple hosts ... not necessarily. Although the big SPOF monolith has gone out of fashion, do not underestimate the throughput possible from one single very fast server.

Even in a contrived situation where you have a strict cache locality constraint for performance reasons or something, you'd still want to have at least a second host for failover. Now you have a distributed system and a service discovery problem!

Re: Monolith First (2015)

#197

Post by NationalPark »

marcosdumay wrote: post #185
bulleyashah wrote: post #134

Earlier quoted context omitted.

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…

> But distributed systems is a well understood thing in the industry. Wait, what? Distributed systems are one of the most active areas on CS currently. That's the opposite of "well understood". It's true that most systems people create are required to be distributed. But they are coordinated by a single database layer that satisfies approximately all the requirements. What remains is an atomic facade that developers…

Distributed systems are well understood though. We have a lot of really useful theoretical primitives, and a bunch of examples of why implementing them is hard. It doesn't make the problems easier, but it's an area that as you say, has a ton of active research. Most engineers writing web applications aren't breaking new ground in distributed systems - they're using their judgement to choose among tradeoffs.

Re: Monolith First (2015)

#198

Post by dimitrios1 »

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…

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

Re: Monolith First (2015)

#199

Post by bulleyashah »

TickleSteve wrote: post #158
bulleyashah wrote: post #131

Earlier quoted context omitted.

I mean, you can always deploy your microsevices on the same host, it would just be a service mesh. Adding network is not a limitation. And frankly, I don't understand why you say things like understanding network. Like reliability is taken care of, routing is taken care of. The remaining problems of unboundedness and causal ordering are taken care of (by various frameworks and protocols). For dlq management, you can…

Compare the overheads and failure modes of a request to that of a method call, thats the comparison. Requests can fail in a host of ways that a call simply cannot, the complexity is massively greater than a method call.

+1

I realized this one day when I was drawing some nice sequence diagrams and presenting it to a senior and he said "But who's ensuring the sequence?". You'll never ask this question in a single threaded system.

Having said that, these things are unavoidable. The expectations from a system are too great to not have distributed systems in picture.

Monoliths are so hard to deploy. It's even more problematic when you have code optimized for both sync cpu intensive stuff and async io in the same service. Figuring out the optimal fleet size is also harder.

I'd love to hear some ways to address this issue and also not to have microservice bloat.

Re: Monolith First (2015)

#200

Post by bulleyashah »

pjc50 wrote: post #167
bulleyashah wrote: post #134

Earlier quoted context omitted.

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…

> Monoliths are also distributed systems and will run on multiple hosts ... not necessarily. Although the big SPOF monolith has gone out of fashion, do not underestimate the throughput possible from one single very fast server.

Well, no matter how fast a single server is, it can't keep getting faster.

You might shoot yourself in the foot by optimizing only for single servers because eventually you'll need horizontal scaling and it's better to think about it in the beginning of your architecture.

Post reply on HN