4 ms·

The move to microservices is often more about scaling change management when an organization grows from tens to hundreds of engineers. Change management become

The move to microservices is often more about scaling change management when an organization grows from tens to hundreds of engineers. Change management becomes the bottleneck when organizations exceed Dunbar's Number, and a "reverse Conway maneuver" is needed to counter excessive cost of coordination. https://cloud.google.com/architecture/devops/devops-tech-architecture https://cloud.google.com/architecture/devops/devops-tech-arc...

Pamar 4y ago
"when an organization grows from tens to hundreds of engineers" - point taken. My question then is: is this type of growth the norm, or is it exceptional? If I am, say, Tesla... do I need 1 order of magnitude more sw engineers when I start selling 10 times the cars I was selling 2 years ago?
candiddevmike 4y ago
Linux kernel has a huge amount of contributors with their own goals and they seem to coordinate just fine. Monoliths can scale, but they can't be "owned"/leveraged by leaders/sociopaths into a bigger budget/team/etc, IMO.
- dralley 4y ago
  The linux kernel is more siloed than one might expect, a lot of code is architecture specific or in drivers, which facilitates having a wide group of maintainers.
  - mpweiher 4y ago
    EXACTLY. It shows that you can have a siloed monolith.
- surajrmal 4y ago
  Linux development is absolutely hampered by being a monolith. Getting involved in Linux development is notoriously difficult. The average developer won't consider it even though there are many parts of the kernel which very much should be approachable. It is also hard to get some patches upstream if the goals of said patches don't align with everyone else's interests. There are even people exploring userspace schedulers to get around these challenges. There are also huge maintenance burdens that come from the lack of stable interfaces for modules. There is a reason there is a lot of excitement around ebpf. It is providing the sort of scaling that people have been needing for a while.
- christophilus 4y ago
  Not true. Sociopaths always find a way.
bvrmn 4y ago
I don't agree. Almost every candidate during interview likes to talk how their team of 3-5 people manages multiple microservices. It's pretty much hype driven approach to develop a backend application.
marcosdumay 4y ago
Interestingly, open source has some change management processes that deal with orders of magnitude more people and pieces of software than you will find on a corporation, and mostly only imposes infrastructure policies when that's the development's goal. It tends to fail less often than corporations too. And my impression is that it's more efficient for developer time.
dagss 4y ago
When going from tens to hundreds, do the hundreds manage to produce anywhere near a many-fold increase in performance though? My impression is that microservices is a solution to keep a hundred people HAPPY (solving auxiliary problems you create for yourself) while producing about the output for the company that the "tens" would provide. If management INSISTS on scaling from tens to hundreds, you can't very well keep the tens occupied on irrelevant side project. So instead you can do microservices. Either way you get the speed for the company of "tens" though.

Pamar 4y ago

"when an organization grows from tens to hundreds of engineers" - point taken. My question then is: is this type of growth the norm, or is it exceptional? If I am, say, Tesla... do I need 1 order of magnitude more sw engineers when I start selling 10 times the cars I was selling 2 years ago?

candiddevmike 4y ago

Linux kernel has a huge amount of contributors with their own goals and they seem to coordinate just fine. Monoliths can scale, but they can't be "owned"/leveraged by leaders/sociopaths into a bigger budget/team/etc, IMO.

dralley 4y ago
The linux kernel is more siloed than one might expect, a lot of code is architecture specific or in drivers, which facilitates having a wide group of maintainers.
- mpweiher 4y ago
  EXACTLY. It shows that you can have a siloed monolith.
surajrmal 4y ago
Linux development is absolutely hampered by being a monolith. Getting involved in Linux development is notoriously difficult. The average developer won't consider it even though there are many parts of the kernel which very much should be approachable. It is also hard to get some patches upstream if the goals of said patches don't align with everyone else's interests. There are even people exploring userspace schedulers to get around these challenges. There are also huge maintenance burdens that come from the lack of stable interfaces for modules. There is a reason there is a lot of excitement around ebpf. It is providing the sort of scaling that people have been needing for a while.
christophilus 4y ago
Not true. Sociopaths always find a way.

bvrmn 4y ago

I don't agree. Almost every candidate during interview likes to talk how their team of 3-5 people manages multiple microservices. It's pretty much hype driven approach to develop a backend application.

marcosdumay 4y ago

Interestingly, open source has some change management processes that deal with orders of magnitude more people and pieces of software than you will find on a corporation, and mostly only imposes infrastructure policies when that's the development's goal. It tends to fail less often than corporations too. And my impression is that it's more efficient for developer time.

dagss 4y ago

When going from tens to hundreds, do the hundreds manage to produce anywhere near a many-fold increase in performance though? My impression is that microservices is a solution to keep a hundred people HAPPY (solving auxiliary problems you create for yourself) while producing about the output for the company that the "tens" would provide. If management INSISTS on scaling from tens to hundreds, you can't very well keep the tens occupied on irrelevant side project. So instead you can do microservices. Either way you get the speed for the company of "tens" though.