4 ms·

In my experience, the biggest benefit of microservices is decoupling teams. Developer productivity is very hard to maintain in a monolithic app as the number o

In my experience, the biggest benefit of microservices is decoupling teams. Developer productivity is very hard to maintain in a monolithic app as the number of developers increases and the legacy code piles up. Breaking up services and giving each dev team control over their own codebases enables them to develop their own products at their own pace. If you only have one dev team, microservices are a lot less attractive. However, there are still some benefits, such as being able to refactor parts of your codebase in isolation (including perhaps rewriting them in different languages), and the ability to individually adjust the runtime scale of different parts of your codebase.

whatsmyusername 7y ago
This. The problem with decoupling services is usually there end up being a couple services that are critical but not sexy. No one wants to touch them so they sit around unmaintained until an unrelated change or unpatched security issue comes around. Suddenly you've got a big problem with a mystery codebase.
- viraptor 7y ago
  That sounds very familiar, but I'm not sure this is something that can be blamed on decoupling itself. An unpopular module is going to need as much attention as a micro service from code point of view. For upgrades / patching, there would be a company-wide process around it that doesn't care that much how the code is organised.
  - whatsmyusername 7y ago
    'company wide' process is either, 'squeaky wheel gets the grease,' or, 'no one even knows this exists,' 100% of the time in my experience. This is from going from 10k+ to 150 to 5k+ to 50 people.
    - viraptor 7y ago
      I wrote company-wide, but it's not the case everywhere. At some scale you'll want department, or even project-wide process. But the policy should be fairly common - who owns it, what's the response time, how to escalate urgent things, etc.
      - whatsmyusername 7y ago
        I mean, I can write policy documents all day. Most of them would have had a better life as toilet paper.
ako 7y ago
Indeed, microservices is mostly about scaling development.
- NicoJuicy 7y ago
  Microservices is changing dev complexity to ops. That's why most companies are promoting devs to do ops . So then you have devops
  - jordanbeiber 7y ago
    It think in ways this is true. Containerization, autoscaling, service discovery, tracing, metrics and monitoring et al - lot of it is required to do larger scale, distributed systems. Even if you do not call them microservices.
- pjmlp 7y ago
  Modular programming as well.
- IshKebab 7y ago
  This is nonsense. You can already do that via libraries. The choice of RPC vs local procedure calls has no effect on scaling development. IMO the only reason to use micro-services is the one they mentioned - you can have different parts of your system running on different machines so they can be spun up independently. But I think most people aren't "web scale" enough to need that anyway.
pjmlp 7y ago
I was already achieving that around 2008 by having each team responsible for their modules, delivered over Maven, or on the late 90's by having each team responsible for their COM modules. No need to over-engineering modularity with distributed systems algorithms into the mix.

whatsmyusername 7y ago

This. The problem with decoupling services is usually there end up being a couple services that are critical but not sexy. No one wants to touch them so they sit around unmaintained until an unrelated change or unpatched security issue comes around. Suddenly you've got a big problem with a mystery codebase.

viraptor 7y ago
That sounds very familiar, but I'm not sure this is something that can be blamed on decoupling itself. An unpopular module is going to need as much attention as a micro service from code point of view. For upgrades / patching, there would be a company-wide process around it that doesn't care that much how the code is organised.
- whatsmyusername 7y ago
  'company wide' process is either, 'squeaky wheel gets the grease,' or, 'no one even knows this exists,' 100% of the time in my experience. This is from going from 10k+ to 150 to 5k+ to 50 people.
  - viraptor 7y ago
    I wrote company-wide, but it's not the case everywhere. At some scale you'll want department, or even project-wide process. But the policy should be fairly common - who owns it, what's the response time, how to escalate urgent things, etc.
    - whatsmyusername 7y ago
      I mean, I can write policy documents all day. Most of them would have had a better life as toilet paper.

ako 7y ago

Indeed, microservices is mostly about scaling development.

NicoJuicy 7y ago
Microservices is changing dev complexity to ops. That's why most companies are promoting devs to do ops . So then you have devops
- jordanbeiber 7y ago
  It think in ways this is true. Containerization, autoscaling, service discovery, tracing, metrics and monitoring et al - lot of it is required to do larger scale, distributed systems. Even if you do not call them microservices.
pjmlp 7y ago
Modular programming as well.
IshKebab 7y ago
This is nonsense. You can already do that via libraries. The choice of RPC vs local procedure calls has no effect on scaling development. IMO the only reason to use micro-services is the one they mentioned - you can have different parts of your system running on different machines so they can be spun up independently. But I think most people aren't "web scale" enough to need that anyway.

pjmlp 7y ago

I was already achieving that around 2008 by having each team responsible for their modules, delivered over Maven, or on the late 90's by having each team responsible for their COM modules. No need to over-engineering modularity with distributed systems algorithms into the mix.