Live data from Hacker News

Monolith First (2015)

martinfowler.com

231–240 of 356 posts

Re: Monolith First (2015)

#231
post #167

Earlier quoted context omitted.

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

Whatever happened to premature optimization being bad?

Re: Monolith First (2015)

#232
A lot of people are saying microservices are great if you do it right. What they miss is they require a whole bunch more people than a monolith to operate, they ignore the cost of adding those people. Really it's like comparing apples and oranges, sure if you have the resources and the headcount to have 37 and a half teams each owning only one piece of your app in a competent way go for that architecture, but if not then stop advocating for a unicorn that only large companies with big budgets can benefit from and preaching it to startups that are struggling to get off the ground as if that should be the industry norm.

Re: Monolith First (2015)

#233

Earlier quoted context omitted.

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.

> So in theory yes you could have a well modularized monolith. I've often wondered if this is a pattern sitting underneath our noses. I.e., Starting with a monolith with strong boundaries, and giving architects/developers a way to more gracefully break apart the monolith. Today it feels very manual, but it doesn't need to be. What if we had frameworks that more gracefully scaled from monoliths to distributed systems?…

If you develop with COM in mind, then it doesn't matter whether the object is in-process or somewhere on the network.

Re: Monolith First (2015)

#234
> But even experienced architects working in familiar domains have great difficulty getting boundaries right at the beginning. By building a monolith first, you can figure out what the right boundaries are, before a microservices design brushes a layer of treacle over them.

I think this is one of the most important points. Often it takes time to figure out what the right boundaries are. Very rarely do you get it right a priori.

Re: Monolith First (2015)

#235

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…

[deleted]

Re: Monolith First (2015)

#236
post #209

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.

Martin has been a character in "enterprise architecture" for a long long time. He has been the inspiration for many convoluted systems. Actually I think he coined the term with his patterns of ... books.

Re: Monolith First (2015)

#237
post #31
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.

I've been trying to get buy-in from colleagues to have stricter boundaries between modules but without much success, mainly because I don't fully understand how to do it myself.

Let's say we have 3 different modules, all domains: sales, work, and materials. A customer places an order, someone on the factory floor needs to process it, and they need materials to do it. Materials know what work they are for, and work knows what order it's for (there's probably a better way to do this. This is just an example).

On the frontend, users want to see all the materials for a specific order. You could have a single query in the materials module that joins tables across domains. Is that ok? I guess in this instance the materials module wouldn't be importing from other modules. It does have to know about sales though.

Here's another contrived example. We have a certain material and want to know all the orders that used this material. Since we want orders, it makes sense to me to add this in the sales module. Again, you can perform joins to get the answer, and again this doesn't necessarily involve importing from other modules. Conceptually, though, it just doesn't feel right.

Re: Monolith First (2015)

#238

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.

There’s too much funding in the industry. Hilarious to think that if interest rates rose we would have fewer micro service implementations.

Re: Monolith First (2015)

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

I think my biggest gripe with orgs that adopt microservices is they don't build out any of the testing, CI/CD, monitoring and debugging workflows to support it. It goes from shitty, slow monolithic application that super-pro can debug in a few minutes to.. Slow, shitty disparate services that are managed by different teams who don't share anything, suddenly you've got a Cuckoo's Egg situation where 1 guy needs to get…

So I actually find that microservices should actually help tremendously here? Service A starts throwing 500s. Service A has a bunch of well defined API calls it makes with known, and logged, requests and responses. These responses should be validated on the way in and produce 400s if they aren't well formed. Most 500s IMHO result from the validations not catching all corner cases, or not handling the downstream errors properly. But in general it should be relatively easy to track down why one, or a series of calls failed.

I also find that by having separate distinct services, it puts up a lot of friction to scope creep in that service and also avoids side effect problems- IE you made this call, and little did you know this updated state somewhere you completely didn't expect and now touching this area is considered off limits, or at least scary because it has tentacles in so many different places. Eventually this will absolutely happen IME. No of course not on your team, you are better than that, but eventually teams change, this is now handled by the offshore or other B/C team, or a tyrant manager takes over for a year or two before that is obsessed with hitting the date, hacks or not, etc...

But I guess an absolutely critical key to that is having a logging/monitoring/testing/tracing workflow built in. Frameworks can help, Hapi.js makes a lot of this stuff a core concept for example. This is table stakes to be doing "micro" services though and any team that doesn't realize that has no business going near them. Based on the comments here though ignorance around this for teams embracing microservices might be more common than I had imagined.

Re: Monolith First (2015)

#240

Earlier quoted context omitted.

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.

> So in theory yes you could have a well modularized monolith. I've often wondered if this is a pattern sitting underneath our noses. I.e., Starting with a monolith with strong boundaries, and giving architects/developers a way to more gracefully break apart the monolith. Today it feels very manual, but it doesn't need to be. What if we had frameworks that more gracefully scaled from monoliths to distributed systems?…

Well, we often use plain old HTTP for this purpose, hence the plethora of 3rd party API's one can make an HTTP call to...

(I side with the monolith, FWIW...I love Carl Hewitt's work and all, it just brings in a whole set of stuff a single actor doesn't need... I loved the comment on binding and RPC above, also the one in which an RPC call's failure modes were compared to the (smaller profile) method call's)

Post reply on HN