5 ms·

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

goodoldneon 4y ago
Yea. IMO, microservices are usually more of an organizational solution than a technical solution
- __alexs 4y ago
  IMO software is usually more of an organisational solution than a technical solution.
- jnash 4y ago
  Libraries can do the exact same thing. And it is a less complex solution.
CharlieDigital 4y ago
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.
- __alexs 4y ago
  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.
40acres 4y ago
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.
- jacquesm 4y ago
  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.
tlonny 4y ago
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...
- foobarian 4y ago
  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?
  - XorNot 4y ago
    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.
    - foobarian 4y ago
      Not Google, but up there. And I don't like my IDE indexing for 2 minutes every time I pull and recompile.
- kkapelon 4y ago
  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.
  - tlonny 4y ago
    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...
steinuil 4y ago
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.

goodoldneon 4y ago

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

__alexs 4y ago
IMO software is usually more of an organisational solution than a technical solution.
jnash 4y ago
Libraries can do the exact same thing. And it is a less complex solution.

CharlieDigital 4y ago

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.

__alexs 4y ago
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.

40acres 4y ago

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.

jacquesm 4y ago
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.

tlonny 4y ago

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

foobarian 4y ago
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?
- XorNot 4y ago
  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.
  - foobarian 4y ago
    Not Google, but up there. And I don't like my IDE indexing for 2 minutes every time I pull and recompile.
kkapelon 4y ago
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.
- tlonny 4y ago
  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...

steinuil 4y ago

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.