4 ms·

I all comes back to Conway's Law (Your software will look like your organization). Microservices allow and require low coupling in the organization. If you wan

I all comes back to Conway's Law (Your software will look like your organization). Microservices allow and require low coupling in the organization. If you want to reduce coupling in your org, you'll be well served by microservices. If you want tight collaboration in your org, you'll be well served by a monolith. As orgs grow into multiple independently executing units, a monolith starts to limit the ability to independently execute.

lucisferre 9y ago
Modularly designed software, with appropriate boundaries can accomplish the same thing without the overhead of microservice deployments. During the early stages where there is maybe 1-2 people coding, microservices add a lot of unneeded overhead and orchestration.
- tyurok 9y ago
  It's also about the teams being independent of processes, stacks and tools. Usually monoliths have infrastructure, library and tools constraint that are hard o break. Yes, microservices adds overhead in tooling. You have to measure carefully the trade-offs. It only pays off in a way larger scale than most of the organizations.
  - deleted 9y ago
    [deleted]
mixedCase 9y ago
I believe a simpler explanation is that it's easier for some devs to cleanly separate concerns when they're forced to do so by the constraint of process separation, rather than language modules/packages, where it's too easy for a junior dev to break the architecture with a single import. Keeping a monolith's concerns cleanly segregated does require a small amount of discipline.
- XorNot 9y ago
  I would propose that an alternate explanation is that when the processes are actually separate in deployment, you filter out strong personalities (or management types who are overly involved in things outside their area) from dominating the development process as well. Stopping someone working in one area from deciding they just don't like the look of the other is a benefit or all its own.
- crdoconnor 9y ago
  >it's easier for some devs to cleanly separate concerns when they're forced to do so by the constraint of process separation This is a dangerous ideology. Process separation doesn't enforce loose coupling, it simply makes the pain of tight coupling between them that much worse. I worked on a "microservice" system once where I regularly had to debug a problem across four different service boundaries and two different languages. It felt like I was using boxing gloves to perform surgery on a rube goldberg toy.
- phamilton 9y ago
  Conway's law explains why that discipline is harder in practice. If everything about the business suggests that two things are tightly coupled, then naturally someone is going to make that import.
transitorykris 9y ago
"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." This is a statement about an existing organization and the system they design. It doesn't say you can design a system and then the organization of your choice forms around it. Bezos had to start with a management edict about how the organization is structured (by threat of firing) to get the SOA system he desired at Amazon. https://plus.google.com/+RipRowan/posts/eVeouesvaVX https://plus.google.com/+RipRowan/posts/eVeouesvaVX
- phamilton 9y ago
  > This is a statement about an existing organization and the system they design. It doesn't say you can design a system and then the organization of your choice forms around it. I think both systems and org structure are iterative and evolving. A mismatch between the two will cause friction. Change the org structure and the monolith starts looking like independent services except without the conveniences of microservices (deployment, isolation, independent scaling, etc). Try to change the monolith without changing the org structure and your microservices will eventually turn into tightly coupled RPC hell. Sometimes that friction prompts change in the org, sometimes it prompts change in the code.
watwut 9y ago
Proper collaboration in human organization is best served by clear responsibilities, roles and accountability. The monolith in big organization leads to turf wars, random dudes attempting to micromanage components they know nothing about, committees designing simple dunct I nality etc. So you split that in pieces with clear lines between then and voila, hours long bullshit meetings are no longer necessary.
crdoconnor 9y ago
>Microservices allow and require low coupling in the organization. If you want to reduce coupling in your org, you'll be well served by microservices. If you want tight collaboration in your org, you'll be well served by a monolith. As orgs grow into multiple independently executing units, a monolith starts to limit the ability to independently execute. Most individual computers combine seamlessly interoperating software that was, ultimately, written by tens if not hundreds of thousands of people, most of whom do not know one another - all the way from the kernel to the highest level scripting languages. I think you're right microservices are primarily about Conway's law. I just don't think it's about operational effectiveness (it actually makes operational effectiveness harder, IMO). I think it's primarily successful in large orgs because it minimizes finger pointing by establishing tighter loci of responsibility. My rule of thumb is "could this service be spun off as a separate business?". E.g. postcode->address service, sure, microservice that. Image manipulation service->maybe yes, maybe no, "user" service-> no, price calculation service->no
- ValentineC 9y ago
  > My rule of thumb is "could this service be spun off as a separate business?". E.g. postcode->address service, sure, microservice that. Image manipulation service->maybe yes, maybe no, "user" service-> no, price calculation service->no Curious: why would a "user" service not be viable as a separate business? There's always space for one more authentication option.

lucisferre 9y ago

Modularly designed software, with appropriate boundaries can accomplish the same thing without the overhead of microservice deployments. During the early stages where there is maybe 1-2 people coding, microservices add a lot of unneeded overhead and orchestration.

tyurok 9y ago
It's also about the teams being independent of processes, stacks and tools. Usually monoliths have infrastructure, library and tools constraint that are hard o break. Yes, microservices adds overhead in tooling. You have to measure carefully the trade-offs. It only pays off in a way larger scale than most of the organizations.
- deleted 9y ago
  [deleted]

mixedCase 9y ago

I believe a simpler explanation is that it's easier for some devs to cleanly separate concerns when they're forced to do so by the constraint of process separation, rather than language modules/packages, where it's too easy for a junior dev to break the architecture with a single import. Keeping a monolith's concerns cleanly segregated does require a small amount of discipline.

XorNot 9y ago
I would propose that an alternate explanation is that when the processes are actually separate in deployment, you filter out strong personalities (or management types who are overly involved in things outside their area) from dominating the development process as well. Stopping someone working in one area from deciding they just don't like the look of the other is a benefit or all its own.
crdoconnor 9y ago
>it's easier for some devs to cleanly separate concerns when they're forced to do so by the constraint of process separation This is a dangerous ideology. Process separation doesn't enforce loose coupling, it simply makes the pain of tight coupling between them that much worse. I worked on a "microservice" system once where I regularly had to debug a problem across four different service boundaries and two different languages. It felt like I was using boxing gloves to perform surgery on a rube goldberg toy.
phamilton 9y ago
Conway's law explains why that discipline is harder in practice. If everything about the business suggests that two things are tightly coupled, then naturally someone is going to make that import.

transitorykris 9y ago

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." This is a statement about an existing organization and the system they design. It doesn't say you can design a system and then the organization of your choice forms around it. Bezos had to start with a management edict about how the organization is structured (by threat of firing) to get the SOA system he desired at Amazon. https://plus.google.com/+RipRowan/posts/eVeouesvaVX https://plus.google.com/+RipRowan/posts/eVeouesvaVX

phamilton 9y ago
> This is a statement about an existing organization and the system they design. It doesn't say you can design a system and then the organization of your choice forms around it. I think both systems and org structure are iterative and evolving. A mismatch between the two will cause friction. Change the org structure and the monolith starts looking like independent services except without the conveniences of microservices (deployment, isolation, independent scaling, etc). Try to change the monolith without changing the org structure and your microservices will eventually turn into tightly coupled RPC hell. Sometimes that friction prompts change in the org, sometimes it prompts change in the code.

watwut 9y ago

Proper collaboration in human organization is best served by clear responsibilities, roles and accountability. The monolith in big organization leads to turf wars, random dudes attempting to micromanage components they know nothing about, committees designing simple dunct I nality etc. So you split that in pieces with clear lines between then and voila, hours long bullshit meetings are no longer necessary.

crdoconnor 9y ago

>Microservices allow and require low coupling in the organization. If you want to reduce coupling in your org, you'll be well served by microservices. If you want tight collaboration in your org, you'll be well served by a monolith. As orgs grow into multiple independently executing units, a monolith starts to limit the ability to independently execute. Most individual computers combine seamlessly interoperating software that was, ultimately, written by tens if not hundreds of thousands of people, most of whom do not know one another - all the way from the kernel to the highest level scripting languages. I think you're right microservices are primarily about Conway's law. I just don't think it's about operational effectiveness (it actually makes operational effectiveness harder, IMO). I think it's primarily successful in large orgs because it minimizes finger pointing by establishing tighter loci of responsibility. My rule of thumb is "could this service be spun off as a separate business?". E.g. postcode->address service, sure, microservice that. Image manipulation service->maybe yes, maybe no, "user" service-> no, price calculation service->no

ValentineC 9y ago
> My rule of thumb is "could this service be spun off as a separate business?". E.g. postcode->address service, sure, microservice that. Image manipulation service->maybe yes, maybe no, "user" service-> no, price calculation service->no Curious: why would a "user" service not be viable as a separate business? There's always space for one more authentication option.