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

71–80 of 90 posts

Re: Build the Modular Monolith First

#71

Post by andrewmutz »

mind-blight wrote: post #19
jameshart wrote: post #15

There are more than two architectures. I agree if you don’t have organizational scale, microservices solve problems you don’t have. But there are at least three separate things that are ‘monolithic’ about a classical monolith. 1) the codebase, 2) the database, and 3) the build and release process. And you can certainly modularize your codebase into libraries or independent modules, but retain monolithic builds and re…

Similarly, I feel like microservices are implemented to help with "scale", but it's often fuzzy which metric is being scaled. You can scale 1. Number of developers in your org 2. Number of users on your platform 3 Amount of data or compute used Not all products need to scale all of these dimensions, and a microservice architecture may or may not help much. I'd argue that you probably get better results for #2 by opti…

Microservices are primarily good at scaling the human organization (#1).

Plenty of monoliths handle large numbers of users, large data sets and large amounts of computing resources.

Re: Build the Modular Monolith First

#72

Post by errantmind »

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…

Yes, and I've gone the other way too, i.e. taking a bunch of microservices and rewriting them as a monolith, saving the company over a million dollars a year in the process.

It isn't one or the other, the 'skill' is knowing which to apply when.

To make most of these types of projects work, the sponsor needs to demand an incremental approach that delivers real value, piece by piece, all the way up to retiring the original system(s). Tie-out is also necessary for many projects, and all the associated testing. It is a big grind, which is probably why so many of these projects fail.

Re: Build the Modular Monolith First

#73

Post by mind-blight »

andrewmutz wrote: post #71
mind-blight wrote: post #19

Earlier quoted context omitted.

Similarly, I feel like microservices are implemented to help with "scale", but it's often fuzzy which metric is being scaled. You can scale 1. Number of developers in your org 2. Number of users on your platform 3 Amount of data or compute used Not all products need to scale all of these dimensions, and a microservice architecture may or may not help much. I'd argue that you probably get better results for #2 by opti…

Microservices are primarily good at scaling the human organization (#1). Plenty of monoliths handle large numbers of users, large data sets and large amounts of computing resources.

Agreed. I've seen product say "we need to make sure it scales [to our dream number of users]", and have engineering respond "we'll use microservices to scale" seemingly without addressing what kind of scale they'll help with.

A lot of orgs end up using the same word to describe completely different needs and outcomes

Re: Build the Modular Monolith First

#74

Post by bvrmn »

jacurtis wrote: post #4

I think more startups need to consider building monoliths first. Micro-service architecture definitely has the advantage at scale, but the advantage of monoliths is the speed that you can build and improve them. Microservices require much more planning and architecture discussions compared to monoliths. Microservices also can have incredible performance improvements over monoliths (being able to scale or tailor each…

> Microservices also can have incredible performance improvements over monoliths

At this point it's like "Mongo is Web scale" meme.

It's so false on so many levels without a proper context. Not surprising inexperienced devs starting use microservices for "pet shops", because "microservises are fast" and failing miserably.

Re: Build the Modular Monolith First

#75

Post by mirekrusin »

basicallybones wrote: post #39

Microservices vs. monoliths is a false dichotomy in the present day. If you put microservices in a monorepo with a good build tool (like NX), put the common auth/logging/types/dtos/etc. functions in reusable libs, and version/release all the apps together, you get the best of both worlds. At a small scale, you can deploy your whole containerized stack on two big HA instances (monolithic infrastructure, so much easier…

Exactly. Now it just needs catchy name so vocal juniors have one word to refer to it - they currently know only 2 words for architecture - bad monolith and good micro services.

Re: Build the Modular Monolith First

#76

Post by gombosg »

jjtheblunt wrote: post #18
vyrotek wrote: post #13

Completely agree! We build our .NET projects in a similar way too. My current SaaS company has 8 web projects and 1 core project. Some of the web projects are SPAs using BFF and others are APIs for customers or our mobile app. They aren't tiny sites. We're up to ~500 controllers. All in a single repo and automatically deployed as a monolith. We have a super small but very productive team which we attribute to this si…

BFF ?

Backend for frontend! Specialized microservices that serve some frontend-consumable APIs e.g. when other internal APIs are too cumbersome to use or change too frequently.

Re: Build the Modular Monolith First

#77

Post by afhammad »

mberning wrote: post #61
afhammad wrote: post #27

Earlier quoted context omitted.

Curious to hear more. Are these personal projects or serving users? What are some examples of unrelated ideas you’ve tacked on to existing app servers?

It’s mostly enterprise stuff. I have a local rails app and local springboot app that I keep around and am constantly trying stuff out in. If it starts to look like it would be generally useful I will rip it out, put it in it’s own repo, set it up in a jenkins pipeline, and then have the jar/gem published to an internal artifactory instance. Then I can just include the jar or gem in other codebases as needed. Works gr…

Oh I see. So you avoid the boilerplate of setting up a new project and configuring it how you like just to try stuff out. That's smart as that part usually takes people down rabbit holes that distract from the main goal.

Re: Build the Modular Monolith First

#78

Post by TakkemTan »

simplotek wrote: post #65
basicallybones wrote: post #39

Microservices vs. monoliths is a false dichotomy in the present day. If you put microservices in a monorepo with a good build tool (like NX), put the common auth/logging/types/dtos/etc. functions in reusable libs, and version/release all the apps together, you get the best of both worlds. At a small scale, you can deploy your whole containerized stack on two big HA instances (monolithic infrastructure, so much easier…

> If you put microservices in a monorepo (...) What exactly do you gain with this approach, other than pinning versions of all microservices? Any competent team working on services does not suffer from "versioning hell" because APIs are stable and tracked with integration tests and smoke tests, and you version the API and not the code.

It vastly reduces the complexity of things like dependencies, testing, CI/CD, versioning.

Dependencies can be relative paths. Relative path dependencies will break the build on your machine, so you don't get devs pushing broken stuff. CI/CD servers don't get plugged up with billions of repos building because one changed. CI/CD servers don't need to wait for other builds to finish and push artifacts to do their job. Testers don't need to say "I used version 10.2 of x and 11.5 of y", they can have a single version number for the whole stack.

All these things are possible with microservices in different repos. But they require a lot more time to set up and require regular maintianance. If your company isn't large enough to need that, then it makes no sense to move away from a monorepo.

Arguably no company is big enough, Google has all it's code in a single 80 terabyte monorepo. But I can understand why that wouldn't scale well either...

Re: Build the Modular Monolith First

#79

Post by Lio »

andrewmutz wrote: post #71
mind-blight wrote: post #19

Earlier quoted context omitted.

Similarly, I feel like microservices are implemented to help with "scale", but it's often fuzzy which metric is being scaled. You can scale 1. Number of developers in your org 2. Number of users on your platform 3 Amount of data or compute used Not all products need to scale all of these dimensions, and a microservice architecture may or may not help much. I'd argue that you probably get better results for #2 by opti…

Microservices are primarily good at scaling the human organization (#1). Plenty of monoliths handle large numbers of users, large data sets and large amounts of computing resources.

> Microservices are primarily good at scaling the human organization (#1).

I agree but this is what worries me about them; micro-services encourage team scale up and that is really difficult to do well.

In theory you'd have separate services with well defined APIs. You'd know upfront what behaviour belongs where and could get the right people to deliver changes on schedule.

The reality is often a form of disguised waterfall development and it rarely works out well unless you are very careful.

Instead you've gained the problem of refactoring multiple services, in multiple languages, owned by multiple competing teams, each with their own management and agenda. Productivity takes a nosedive and more bodies get added in an attempt to make up for it. The result is the opposite[1].

You're much better off striving to keep a small team as productive as possible with adding team members a last resort. Project management at scale is such a difficult task that if you can delay doing it, you should.

Startups have no choice but to use small teams. As a consequence they have good productivity and low barriers to communication without really thinking about it. The problem in larger enterprises is that the highest status project manager is often the one with the biggest team and not the highest productivity.

Personally, I'd rather have a few guys with massive servers than a massive team with lots of small services.

-

1. This nothing new, it's what Fred Brooks was talking about in the Mythical Man Month back in the 1970s.

https://en.wikipedia.org/wiki/The_Mythical_Man-Month

Re: Build the Modular Monolith First

#80

Post by yehosef »

thunky wrote: post #67
simplotek wrote: post #63

Earlier quoted context omitted.

> This always seemed strange to me. If your team can't be trusted not to make spaghetti in a monolith, what stops them from making distributed spaghetti in microservices? It's far harder to update multiple services to handle requests they should not handle, let alone update a deployment to allow those requests to happen. Walls make great neighbors, just like multiple services make teams great at complying with an arc…

> Walls make great neighbors I think you're trying to solve a communication problem with a technical solution, which is a recipe for trouble. If multiple teams working on interdependent components can't communicate well enough to keep from stepping on each other's toes, imposing technical barriers probably isn't going to make things better. Especially once you inevitably realize that you put the walls in the wrong pl…

been there, done that.
Post reply on HN