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 176 posts

Re: Monolith First (2015)

#51

Post by catern »

tunesmith wrote: post #47
Animats wrote: post #36

Earlier quoted context omitted.

Rule of thumb: if you have two "service" talking to the same set of data in the same general-purpose datastore (i.e., not pub-sub, not opposite ends of a job queue), they're the same service. Why? The whole point of a general-purpose database is to allow multiple applications to use the same data. Consider an online ordering system for merchandise. There's an service for checking product availability. There's a servi…

If that needs to be scaled out to many services, then you also want to scale out the data model. Meaning, events in a commit log, and services that subscribe to that commit log to create their own schemas that are tuned for their own needs. The more I think about commit logs, the more I think giant monolithic database schemas are just kind of weird - a strange compromise between history and state.

That's an interesting idea. If I understand correctly, you're suggesting that services simply broadcast the data mutations they are going to perform. Then, any other services that wish to use that data can filter those broadcasted mutations down to what is relevant to the other services, and store the data in a way that is efficient for what the other services want to do.

Are there any examples of things architected in that way?

Doesn't it also run into the problem of needing to version the events that you broadcast?

Re: Monolith First (2015)

#52

Post by morphemass »

Just about every one I've interviewed with recently has been breaking their monolith up into micro-services for some reason.

When I've done this in the past I had a key goal: reliability. The cost was about 10x the development effort of the monolith in order to add an extra 9 to the reliability. The monolith was wonderful for getting up and running quickly as a business solution but it actually crippled the business because they had failed to identify how essential reliability was. KYC.

Personally I've come to the conclusion that the main benefits of SOA/MSA are not necessarily technical but more organisational/sociological. Having distinct silos of activity/responsibility, separate teams and communications channels; all can make a large project more manageable than the monolith by allowing the lower level problems to be abstracted away (from a management perspective).

Re: Monolith First (2015)

#53

Post by tomnipotent »

catern wrote: post #51
tunesmith wrote: post #47

Earlier quoted context omitted.

If that needs to be scaled out to many services, then you also want to scale out the data model. Meaning, events in a commit log, and services that subscribe to that commit log to create their own schemas that are tuned for their own needs. The more I think about commit logs, the more I think giant monolithic database schemas are just kind of weird - a strange compromise between history and state.

That's an interesting idea. If I understand correctly, you're suggesting that services simply broadcast the data mutations they are going to perform. Then, any other services that wish to use that data can filter those broadcasted mutations down to what is relevant to the other services, and store the data in a way that is efficient for what the other services want to do. Are there any examples of things architected…

Event Sourcing [0] & CQRS [1] come to mind. I'm also a fan of Bottled Water [2] that turns Postgres ops into a stream of events that you can then push to other services.

[0] https://martinfowler.com/eaaDev/EventSourcing.html

[1] https://martinfowler.com/bliki/CQRS.html

[2] https://github.com/confluentinc/bottledwater-pg

Re: Monolith First (2015)

#54

Post by jamesblonde »

catern wrote: post #51
tunesmith wrote: post #47

Earlier quoted context omitted.

If that needs to be scaled out to many services, then you also want to scale out the data model. Meaning, events in a commit log, and services that subscribe to that commit log to create their own schemas that are tuned for their own needs. The more I think about commit logs, the more I think giant monolithic database schemas are just kind of weird - a strange compromise between history and state.

That's an interesting idea. If I understand correctly, you're suggesting that services simply broadcast the data mutations they are going to perform. Then, any other services that wish to use that data can filter those broadcasted mutations down to what is relevant to the other services, and store the data in a way that is efficient for what the other services want to do. Are there any examples of things architected…

It's the Kafka cool-aid being regurgitated. Kafka is the pipe that you need. Micro-services provide APIs to state that they manage that they get from Kafka. That all scales out and services have nice independent failure modes (as long as Kafka doesn't fail). What it doesn't consider, however, is if you have to perform atomic operations across micro-services (you can't easily do this with existing technology). And, yes, you would like exactly-once processing of events, which is non-trivial - even with the new exactly-once message reception feature in Kafka.

If your services are completely separable, this approach is great. Otherwise, monolith it.

Re: Monolith First (2015)

#55

Post by acdha »

eropple wrote: post #37
acdha wrote: post #30

Earlier quoted context omitted.

He's smart and experienced. That doesn't mean he's always right but I would consider what he says and reason through disagreements. Most commonly, I find the right/wrong arguments are actually reflecting the fact that the underlying environments aren't as similar as they might seem at first glance. Someone giving advice based on working on an F500 team with 200 developers will have seemingly-bizarre priorities to a 5…

I agree with this. I used to be a lot more down on his work, but it wasn't his fault so much as all the wannabes who bought it uncritically. (Much the same as stuff like Kubernetes--you aren't Google, they have Google problems, you don't have Google problems, stop automatically adopting Google solutions to problems that are a-web-server problems.)

I really strongly agree with your point about uncritical thinking. Our industry seems to be especially prone to dogma and so many arguments seem to be people not realizing that they're talking past each other.

Re: Monolith First (2015)

#57

Post by to3m »

eropple wrote: post #29
staofbur wrote: post #27

Earlier quoted context omitted.

I'd argue it's cheaper scaling out the monolith or introducing isolated functional silos and scaling them out than even bothering migrating everything to microservices. Also you certainly can't port a complex monolith to microservices; you have to start again. We're quite happily able to shift 15,000 requests/sec from over 2000 http endpoints with a monolith and our kit is at ~20% capacity. Need more? Slice up a silo…

> Also you certainly can't port a complex monolith to microservices Upvoted you, but I disagree with a little. "Microservices" tend to pathological cases, but you 100% can segment a monolithic apps into services . Each module in your application has an interface. Behind that interface, replace it with network calls that fulfill the interface's contracts. (If your monolith doesn't have sections that encapsulate work--…

> Behind that interface, replace it with network calls that fulfill the interface's contracts

Just like that?!

You can encapsulate work fine, without making microservices at all easy to retrofit. There's a big difference between calling a function that does something and returns a result, and calling a function that does nothing until you've gone back to the main loop to handle network input.

(You can confront many of these issues by implementing your services as threads from day 1. Decoupling request and response is a major issue, and this will force you to do that straight away. The other issues associated with moving from single process to multiple processes are fairly minor by comparison.)

Re: Monolith First (2015)

#58

Post by taurath »

tomnipotent wrote: post #53
catern wrote: post #51

Earlier quoted context omitted.

That's an interesting idea. If I understand correctly, you're suggesting that services simply broadcast the data mutations they are going to perform. Then, any other services that wish to use that data can filter those broadcasted mutations down to what is relevant to the other services, and store the data in a way that is efficient for what the other services want to do. Are there any examples of things architected…

Event Sourcing [0] & CQRS [1] come to mind. I'm also a fan of Bottled Water [2] that turns Postgres ops into a stream of events that you can then push to other services. [0] https://martinfowler.com/eaaDev/EventSourcing.html [1] https://martinfowler.com/bliki/CQRS.html [2] https://github.com/confluentinc/bottledwater-pg

It's hilarious to me that that came up, because that was a big part of the 6 month delay.

Re: Monolith First (2015)

#59

Post by Animats »

Ma8ee wrote: post #43
Animats wrote: post #36

Earlier quoted context omitted.

Rule of thumb: if you have two "service" talking to the same set of data in the same general-purpose datastore (i.e., not pub-sub, not opposite ends of a job queue), they're the same service. Why? The whole point of a general-purpose database is to allow multiple applications to use the same data. Consider an online ordering system for merchandise. There's an service for checking product availability. There's a servi…

And one day you realize you have to change your data model, and absolutely all your application are coupled to your whole database. Oups!

You can add a column to an SQL database without difficulty. If you're using one of those "turn database rows into objects" packages, you may have problems, but if you use SQL properly, it's fine. Components that are only data consumers will not even see the new column.

Re: Monolith First (2015)

#60

Post by phamilton »

I all comes back to Conway's Law (Your software will look like your organization).

Microservices allow and require low coupling in the organization. If you want to reduce coupling in your org, you'll be well served by microservices. If you want tight collaboration in your org, you'll be well served by a monolith. As orgs grow into multiple independently executing units, a monolith starts to limit the ability to independently execute.

Post reply on HN