4 ms·

You use microservices when your project expands beyond the monkeysphere number where everyone knows everyone else. It allows teams to work in their own world w

by mahyarm 10y ago

You use microservices when your project expands beyond the monkeysphere number where everyone knows everyone else. It allows teams to work in their own world without having to coordinate as much with other teams or people. Microservices are good for large companies. If you're small you don't need them.

eternalban 10y ago
> You use microservices when your project expands beyond the monkeysphere number where everyone knows everyone else. A layered architecture can give you the same. Microservices, imo, address organizational/industry deficiencies in the design and evolution of domain models. You're basically trading analytical pain for operational pain. As the top comment in this thread (with the excellent list) concludes, you will need "engineers". > Microservices are good for large companies. And this has nothing to do with number of developers. It has to do with inherent complexity of a unified domain model for large organizations. As an analogy, consider microservices as scripting to layered architectures compiled language.
- mahyarm 10y ago
  Microservices also enforce boundaries significantly more strongly. A layered monolith can still easily have random people cut across boundaries without you knowing because there are hundreds of engineers all working in the same system. Large companies don't have problems throwing more engineers at a problem. But they will always have a problem in coordination costs. Microservices also allow you to use different tech stacks for different purposes more easily. Maybe use java for one involving hadoop or some GIS library. Use erlang for some message management service, use golang for some simple API service, use nodejs for some frontend web server, etc. Overall the advantages of microservices come for social reasons, not for a particular technical reason.
  - eternalban 10y ago
    Layered systems do not have to be 'monolithical'. Note that we're both at this moment using layered systems to have this conversation. > A layered monolith can still easily have random people cut across boundaries without you knowing because there are hundreds of engineers all working in the same system. I appreciated your final word regarding "social reasons" and I think we're in strong agreement in that regard. In the final analysis, it seems accurate to say that Microservices approach permits runtime operational [micro] payments towards organizational and analytical debt [1]. The hypothetical system(/straw man?:) you posit above is indicative of organizational, not architectural, failure/deficiency. [1]: in the 'technical debt' sense.
- regularfry 10y ago
  Microservices embody the idea that there might not be a unified domain model across the organisation.
  - eternalban 10y ago
    > there might not be a unified domain model I agree with this. See my reply to mahyarm c.f. "analytical debt". Keyword here is "might not". If there exists domain level solutions, incurring the (forever) micropayments (in context of operational complexities) of a rush to embrace microservices is a systemic fail of the technical leadership.

by mahyarm 10y ago

eternalban 10y ago

> You use microservices when your project expands beyond the monkeysphere number where everyone knows everyone else. A layered architecture can give you the same. Microservices, imo, address organizational/industry deficiencies in the design and evolution of domain models. You're basically trading analytical pain for operational pain. As the top comment in this thread (with the excellent list) concludes, you will need "engineers". > Microservices are good for large companies. And this has nothing to do with number of developers. It has to do with inherent complexity of a unified domain model for large organizations. As an analogy, consider microservices as scripting to layered architectures compiled language.

mahyarm 10y ago
Microservices also enforce boundaries significantly more strongly. A layered monolith can still easily have random people cut across boundaries without you knowing because there are hundreds of engineers all working in the same system. Large companies don't have problems throwing more engineers at a problem. But they will always have a problem in coordination costs. Microservices also allow you to use different tech stacks for different purposes more easily. Maybe use java for one involving hadoop or some GIS library. Use erlang for some message management service, use golang for some simple API service, use nodejs for some frontend web server, etc. Overall the advantages of microservices come for social reasons, not for a particular technical reason.
- eternalban 10y ago
  Layered systems do not have to be 'monolithical'. Note that we're both at this moment using layered systems to have this conversation. > A layered monolith can still easily have random people cut across boundaries without you knowing because there are hundreds of engineers all working in the same system. I appreciated your final word regarding "social reasons" and I think we're in strong agreement in that regard. In the final analysis, it seems accurate to say that Microservices approach permits runtime operational [micro] payments towards organizational and analytical debt [1]. The hypothetical system(/straw man?:) you posit above is indicative of organizational, not architectural, failure/deficiency. [1]: in the 'technical debt' sense.
regularfry 10y ago
Microservices embody the idea that there might not be a unified domain model across the organisation.
- eternalban 10y ago
  > there might not be a unified domain model I agree with this. See my reply to mahyarm c.f. "analytical debt". Keyword here is "might not". If there exists domain level solutions, incurring the (forever) micropayments (in context of operational complexities) of a rush to embrace microservices is a systemic fail of the technical leadership.