Comment by jameshart | Hacker News Reader

Comment by jameshart | Hacker News Reader

Parent Full thread

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

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 optimizing database queries and implementing a good catching layer

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

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

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

I would add 4) documentation to that list. A wiki full of docs is the closest analog I've seen to a monolith ball of mud codebase.

Reply on news.ycombinator.com