Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Build the Modular Monolith First

fearofoblivion.com

Post reply on HN
Print view View original

51–60 of 90 posts

Re: Build the Modular Monolith First

#51

Post by mbrodersen »

A colleague of mine is working on one of the worst software systems I have ever seen or heard of. It is a 20+ years old micro-services architecture. More than 50 services all interacting with each other in mysterious time dependent ways. It is almost impossible to debug or reason about. It took him most of a year to figure out how to reliably and automatically build and boot the system from scratch.

I have worked on systems with the same functionality but architectured as a single monolith + database. Maintaining that system was a walk in the park comparatively.

Re: Build the Modular Monolith First

#52

Post by jjtheblunt »

vyrotek wrote: post #31
jjtheblunt wrote: post #18

Earlier quoted context omitted.

BFF ?

Backends for Frontends. An alternative to making "one API to rule them all". Far less time spent trying to model an API in an abstract way that makes sense to many consumers. Instead, an API and the endpoints are designed for a specific client. (e.g. A Mobile App or SPA) For us, this also meant a more RPC based API where and reusability is managed after the network hop. https://samnewman.io/patterns/architectural/bff…

thanks

Re: Build the Modular Monolith First

#54

Post by whatwherewhy »

What's an interesting consequence of microservice architecture is the effect on release management - it's always necessary to fully [user] test every deployable => so let's reduce what's being deployed.

Microservices make post-release bugfixing a breeze.

Re: Build the Modular Monolith First

#55

Post by jjtheblunt »

janef0421 wrote: post #9

I think an important thing to keep in mind when discussing monoliths or Microservices is that you can build modular code without needing multiple binaries, processes, or server instances. If you follow best practices when creating a monolith, creating well-defined modules with clear input and output boundaries, then it should be relatively easy to split those modules into separate programs and create ways for those m…

But what defines "best practices", in this case?

Re: Build the Modular Monolith First

#56

Post by jjtheblunt »

anon23anon wrote: post #2

I 100% agree w/ this and play an enterprise architect type role at my employer but I would totally get lambasted if I proposed this. Honestly a lot of the ppl I work w/ aren't developers and never were. They just have big mouths and climbed the ranks. Sadly they're the ones who write my reviews and could get me canned so I have to play ball.

what about playing ball elsewhere, the voice your opinion with your feet motif, and leaving the posers to rot?

Re: Build the Modular Monolith First

#57

Post by hnzix »

jjtheblunt wrote: post #55
janef0421 wrote: post #9

I think an important thing to keep in mind when discussing monoliths or Microservices is that you can build modular code without needing multiple binaries, processes, or server instances. If you follow best practices when creating a monolith, creating well-defined modules with clear input and output boundaries, then it should be relatively easy to split those modules into separate programs and create ways for those m…

But what defines "best practices", in this case?

Law of Demeter, constraining responsibility in functions while avoiding tortellini code, clear variable names etc.

Re: Build the Modular Monolith First

#58

Post by benkitzelman »

I think theres an order to abstraction. Variables, functions, classes / modules, classlibs / pacckages, microservices etc... and with each bump up comes maintenance overhead, version management, integration testing, monitoring etc. so it has to be warranted. There are obviously very legitimate, and pragmatic cases for microservices, but just a monoliths are a magnet attracting all code to an ever growing codebase (i.e. its easier to just add it to the monolith), microservices tend to breed microservices.

Conways law is also a real thing. Sometimes, microservices are a practical choice given team structures and ownership, rather than product reasons.... likewise the monolith. Sometimes with a smaller team(s), the monolith is the most pragmatic option, as increasing product complexity due to all the above needs, reduces the capacity for other work.

Sometimes - its a good thing to embrace conways and run with it, as opposed to discovering it as a side affect.

Re: Build the Modular Monolith First

#59

Post by nixlim »

twblalock wrote: post #43

You can try to build a monolith that is modular enough to break up later. But I have never seen it happen, and I’ve been around for a while now. What actually happens, 100% of the time in my personal experience, is that you end up with both the old monolith and new microservices, the monolith never gets fully broken up, and now you need to support two development paradigms forever. Has anyone here ever seen a monolit…

I think that this is a very solid point, but perhaps the reasoning underlying this type of issue is somewhat more complex. For example, we run a what is now a v5 of our API as a bunch of microservices and have been running it as microservices since v4, about 4 years now. These are "children" of v3 - our monolith. The monolith is still alive and kicking in a much reduced state but the reason we cannot decom it has nothing to do with design or time or priorities - the monolith is sitting in a data centre and is the only regulatory permitted way (in our case) to access the mainframe. So, it sits there as a gatekeeper and will do so for the foreseeable future...

Re: Build the Modular Monolith First

#60

Post by nixlim »

miroz wrote: post #10

Ditto. You should start with a monolith with a vision of how to break it down into microservices (if ever needed). When my company got a contract for a new project, my colleague created a prototype, a bare-bone solution that had 9 web projects that communicated over REST, because microservices. I suggested starting with monolith. Guess whose design was accepted because it was more sexy. It never got to production for…

This. I am working on a personal project and definitely initial design and dev is easier in a monolith. Microservices, at the stage my project is at, will bring too much overhead to solve a problem I don't have (scale).
Post reply on HN