Hacker News Reader

Comment by goncalo-r | Hacker News Reader

Aren't microservices nice because they allow you to have different teams own different parts of the code and minimize the communication overhead?

View on HN

That makes a lot of sense when you have real team (and most importantly) process boundaries. Isolate the code and deployment aligned with your team and process boundaries.

But if you're a company of 10-20 people all pretty much working on the same code? Microservices just adds complexity and overhead. Deployment, telemetry, documentation, version synchronization, tracing -- everything becomes more complex when you start creating boundaries between sub parts of your system.

For me, microservices are about boundaries. The question is what benefit that boundary provides for the team. For large companies where there are many discrete teams following different processes and release cadences, microservices might be worth the overhead. For small companies, it is wasted effort.

Sometimes boundaries are good.

Not all things should be easy.

The question is which things need to be easy, and which things need to be hard?

Often the answer is "we don't know" but there is still an optimal answer to the question.

Yea. IMO, microservices are usually more of an organizational solution than a technical solution

IMO software is usually more of an organisational solution than a technical solution.

Libraries can do the exact same thing. And it is a less complex solution.

This can be accomplished using a modular monorepo. Different teams simply manage different directories or modules of the same repo.

Breaking up an app into microservices is total overkill in this instance...

When do the deploys happen? Will they take longer because of the larger size? How do the IDEs work, do they need to load and index everything?

In an age of 64gb developer PCs, we can handle all but the absolute largest codebases on any random MacBook pretty much.

You're not Google, you don't have this problem.

Not Google, but up there. And I don't like my IDE indexing for 2 minutes every time I pull and recompile.

This doesn't cover independent deployments.

Microservices allow team A to deploy their component, while team B are just writing code. Then team B deploys their own component and while team A is at the bar.

I've never found deployments to be an issue. Any team can trigger an entire re-deploy of the app.

One could argue that this is inefficient w.r.t. compute costs, but I think its orders of magnitude cheaper than the cost of the cognitive overhead of orchestrating microservices.

Obviously there is a scale at which this doesn't work anymore - but I've worked on huge code bases with big teams and am yet to witness this...

Simple example.

You have an app and just 3 microservices web + recommendation engine + payment gatway

This means that the team that handles recommendation engine can deploy as fast as they want while the payment gateway (which is brittle and mission critical) stays put.

If you have just a monolith then everytime the recommendation engine is tuned, the payment gateway code is also redeployed with possible downtime (contrived example but just to give you the idea)

This reminds me a lot of Conway's law:

> Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

If we apply this law backwards, microservices reflect an organizational structure with many teams working on different things so they'd make more sense in that context rather than within a small team.

Strong agree. The need to transition to microservices will sneak up on an organization -- and that's okay. It's surprising how much life you can squeeze out of a monolith.

For the bulk of the smaller companies the monolith is an excellent choice. For a smaller number of them decomposition of that monolith into a few (< 10 and usually < 5) services makes good sense. Typically the kind of project you are working on will suggest nice 'cut here' lines and if it does not then you're going to have to be a bit more creative. You could try going by entities or by processes or by large chunks of the project accessed by different people.

And then there are projects that grow way beyond the point where even that will keep them manageable, in which case microservices may well make sense. But the number of companies faced with challenges at that level is quite small relative to the total and the chances that you find yourself in one of those if you don't have a few hundred co-workers as developer is very small.

Reply on news.ycombinator.com