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

31–40 of 90 posts

Re: Build the Modular Monolith First

#31

Post by vyrotek »

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 ?

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/

Re: Build the Modular Monolith First

#32

Post by jameshart »

rwoerz wrote: post #29

The whole monolith vs microservice discussion revolves around a false dichotomy and higly subjective and context-dependend definitions. For example, what if a monolith is integrated into a larger system landscape (e.g. due to an enterprise merger). Is it still a monolith?

Indeed. Most companies which are cited as 'running the whole system as a monolith' aren't really a monolith. They don't actually run their CMS, their online comment system, their payment processing, their payroll, their recruitment databases, their build pipelines, their bug tracker, and their hardware asset management system, all out of one codebase with a single RDBMS on the backend.

People will laugh at that concept, but go look at how mainframe systems work, and you might be surprised how close some old banking systems are to that level of monolithicness. There really are companies who run essentially all of those systems off a single ERP platform. Or worse, on Sharepoint.

Re: Build the Modular Monolith First

#33

Post by [deleted] »

rwoerz wrote: post #29

The whole monolith vs microservice discussion revolves around a false dichotomy and higly subjective and context-dependend definitions. For example, what if a monolith is integrated into a larger system landscape (e.g. due to an enterprise merger). Is it still a monolith?

[deleted]

Re: Build the Modular Monolith First

#35

Post by KyeRussell »

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…

The core question “what is this in service of?” is what separates good developers from mediocre ones.

Re: Build the Modular Monolith First

#36

Post by KyeRussell »

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…

I think a (but not the only) central conceit of a microservices architecture is that most development teams cannot be trusted to maintain proper separation of concerns, and enforcing at a technical level the inability to call Any Old Function is a big part of what you’re buying into.

Re: Build the Modular Monolith First

#37

Post by KyeRussell »

jameshart wrote: post #30
jrochkind1 wrote: post #12

This is written like it's a novel take bucking the trend, but I feel like most things I have seen on this topic for at least several years now have the same observations and conclusions? If anyone wants to actually speak up for microservices, I feel like that's what needs a defense at this point!

I think anyone who has taken a large monolith through a significant platform version upgrade or change, like .NET 2 to .NET 4, or Python2 to Python3, or Angular to React, would need a very persuasive argument to make them believe that starting a new project with a monolithic design was a good idea.

I’d tell anyone that thought that that it’s a very shortsighted view. If they had started with microservices there’s a good chance the project wouldn’t be around long enough to even go through that transition.

Re: Build the Modular Monolith First

#38

Post by mirekrusin »

theptip wrote: post #3

The assertion that monoliths are taboo is a bit odd; “monolith first” has been pragmatic best practice for years: https://martinfowler.com/bliki/MonolithFirst.html .

Exactly, Sam Newman says the same thing in "Building Microservices" book.

I don't know where people got this idea but I've noticed the less experienced, the more noise they make about it.

Re: Build the Modular Monolith First

#39

Post by basicallybones »

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). You can leverage common libraries without versioning hell/cross-repo coordination. If you have mediocre developers on the team and very aggressive development timelines, the monorepo structure helps enforce modular organization. If you are a good developer, your workflow gets very, very fast, and you can manage a lot of complexity.

Add: additionally, if you have ever-changing requirements and some are obviously bolt-on one-offs that aren't going anywhere, you can limit damage to the code quality by splitting those features into a separate microservices (making it much easier to safely deprecate/remove them in the future).

Re: Build the Modular Monolith First

#40

Post by twblalock »

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…

A monorepo of microservices is the best pattern, but only if you have a dedicated team that keeps the monorepo buildable, builds tooling for it, and enforces best practices and the right culture. If you don’t do that, you will end up with a huge mess — I’ve seen it happen.

For companies that can’t dedicate the resources to do a monorepo properly, a repo per team is the best approach. The true value of microservices is decoupling teams so they can move independently without blocking each other.

Also, needing to release the services together, or in a certain order, is a very bad and unscalable pattern. Teams need to be able to move independently. This requires a commitment to avoiding breaking API changes no matter what kind of repo structure you use — and for the love of God, never let more than one service access a database table! A table should only ever have one service that accesses it, and API boundaries need to be enforced as the only way other services get to the data. Do those things and you will be better off no matter what repo structure you use.

Post reply on HN