11–20 of 90 posts
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 .
If anyone wants to actually speak up for microservices, I feel like that's what needs a defense at this point!
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 simple design.
Earlier quoted context omitted.
That's what we're currently working on. Only 20% of the work now goes into actually improving the product.
That may be better than 100% of the work going into improving the product, taking 1/5 the speed it should.
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 releases against a monolithic relational database - a ‘modular monolith’.
But I’m not sure that’s the interesting part to break up, especially if you are not trying to solve the organizational problems microservices help with.
On the other hand, modularizing your build and deployment process could be helpful even if you are a solo developer - because it helps you reduce cycle times, and make smaller changes which means that you can trace bugs more quickly.
And modularizing data access is better for security and reducing blast radius of bugs or errors.
Modularizing the codebase seems much more like a problem you only need to tackle when your organizational complexity increases.
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!
If it's a small engineering team there is nothing more optimal than working on a big scappy vertical codebase in the early stages
In the fortunate situation you need to start scaling -- breaking that out into MS later is usually low effort and fun
If you break it up to early you often end up with logic ghettos forming in the wrong stack that become near impossible to relocate later
I was talking to a startup last year who were hiring several hundred engineers to build a handful of microservice stacks in anticipation of the traffic they may get at launch (success expected because of previous unrelated founder experience), and wanting to make it easier to deploy vast engineering resource on it -- they've still not launched anything
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…
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…
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 optimizing database queries and implementing a good catching layer
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 ?