3 ms·

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 develo

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

KyeRussell 4y ago
The core question “what is this in service of?” is what separates good developers from mediocre ones.
andrewmutz 4y ago
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.
- mind-blight 4y ago
  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
- Lio 4y ago
  > 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 https://en.wikipedia.org/wiki/The_Mythical_Man-Month

KyeRussell 4y ago

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

andrewmutz 4y ago

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.

mind-blight 4y ago
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
Lio 4y ago
> 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 https://en.wikipedia.org/wiki/The_Mythical_Man-Month