5 ms·

Microservices are an organizational pattern: "we have 500 programmers working on one application, how the hell do we do it." Solution: break up application int

Microservices are an organizational pattern: "we have 500 programmers working on one application, how the hell do we do it." Solution: break up application into independent projects, each team of developers works on one of them, have extra team that builds tooling to make everyone happy. Using microservices with a small teams is a terrible idea, usually, because you're switching to a distributed system when you don't need to. And distributed systems are hard to get right. And you're not even following the organizational pattern, because you have one team with N microservices.

BerislavLopac 8y ago
Essentially, microservices are Conway's Law in practice.
pjmlp 8y ago
And even then, those 500 programmers can be distributed across application modules, delivering libraries, no need for microservices.
- maxxxxx 8y ago
  Agreed. If you don’t have the discipline to maintain libraries and their interfaces then you won’t have the discipline to maintain micro services either. I am sure there are good use cases for micro services but using them to compensate for bad coordination won’t help.
- barrkel 8y ago
  Kind of. If you need to scale compute across multiple nodes, starting out as some kind of service abstraction over a method call will help. But most people don't need that scale.
  - pjmlp 8y ago
    We already learned back in the days of SUN RPC how scaling across method calls works in practice across the network.
    - barrkel 8y ago
      By over, I meant over and above, fwiw. I think RPC is a dreadful network programming abstraction. Anything that makes you think it has the same QoS as local calls is just a trap, stuff that works in development and fails horribly in production. Errors, latency, timeouts, retries etc are first class concerns once you bring in the network, far more so than local.
vp8989 8y ago
Actual solution: Don't have 500 programmers.
ebiester 8y ago
Yes, but I also think it isn't a bad idea to separate your applications. Just because each application is a monolith doesn't mean that all of your code has to be in one repository. Can your admin system be a separate system? Can they be three separate systems because three separate groups will use them? Even if you don't immediately split them into separate repositories, it may make sense to segment them as if they were, because if successful, you will start running into problems at around 40 programmers.
- pjmlp 8y ago
  That is why libraries exist.
0x445442 8y ago
That organizational pattern used to be addressed by proper design, engineering and project management. IMO, allowing the hell that is Agile dictate architecture design is the tail wagging the dog.
module0000 8y ago
You need a (good) programmer/architect for this to work in my experience. If you don't have someone who can accurately keep the entire 500-piece workflow in his/her head, success is much harder to achieve. If you have that person though, the 500 developers will feel very focused, and you end up getting where you intend to go. That architectural role is clutch from my experience.

BerislavLopac 8y ago

Essentially, microservices are Conway's Law in practice.

pjmlp 8y ago

And even then, those 500 programmers can be distributed across application modules, delivering libraries, no need for microservices.

maxxxxx 8y ago
Agreed. If you don’t have the discipline to maintain libraries and their interfaces then you won’t have the discipline to maintain micro services either. I am sure there are good use cases for micro services but using them to compensate for bad coordination won’t help.
barrkel 8y ago
Kind of. If you need to scale compute across multiple nodes, starting out as some kind of service abstraction over a method call will help. But most people don't need that scale.
- pjmlp 8y ago
  We already learned back in the days of SUN RPC how scaling across method calls works in practice across the network.
  - barrkel 8y ago
    By over, I meant over and above, fwiw. I think RPC is a dreadful network programming abstraction. Anything that makes you think it has the same QoS as local calls is just a trap, stuff that works in development and fails horribly in production. Errors, latency, timeouts, retries etc are first class concerns once you bring in the network, far more so than local.

vp8989 8y ago

Actual solution: Don't have 500 programmers.

ebiester 8y ago

Yes, but I also think it isn't a bad idea to separate your applications. Just because each application is a monolith doesn't mean that all of your code has to be in one repository. Can your admin system be a separate system? Can they be three separate systems because three separate groups will use them? Even if you don't immediately split them into separate repositories, it may make sense to segment them as if they were, because if successful, you will start running into problems at around 40 programmers.

pjmlp 8y ago
That is why libraries exist.

0x445442 8y ago

That organizational pattern used to be addressed by proper design, engineering and project management. IMO, allowing the hell that is Agile dictate architecture design is the tail wagging the dog.

module0000 8y ago

You need a (good) programmer/architect for this to work in my experience. If you don't have someone who can accurately keep the entire 500-piece workflow in his/her head, success is much harder to achieve. If you have that person though, the 500 developers will feel very focused, and you end up getting where you intend to go. That architectural role is clutch from my experience.