10 ms·

I think that the problem here was that they were fighting against Conway's Law: https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conwa

by nickcw 6y ago

I think that the problem here was that they were fighting against Conway's Law: https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law > Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. I think microservices work well in organizations that are big enough to have a team per microservice. However if you've just split your monolith up and have the same team managing lots of microservices you've made a lot more work for the team without the organisational decoupling which are the real win of microservices. In my experience it is really difficult to fight Conway's law, you have to work with it and arrange your business accordingly.

FpUser 6y ago
So you are saying something in line of: let's increase our development staff X-fold and then we can finally do the same thing that way fewer people doing just fine right now?
- Tomis02 6y ago
  With microservices there's no way around it, as there's additional overhead when splitting a for loop between multiple services. Won't stop people from jumping on the bandwagon though.
- detaro 6y ago
  They're clearly not saying that. If your team is too large to effectively work on a monolith, splitting it up can make sense, but you also need to split the team into smaller groups responsible for different parts. And if you don't end up with teams responsible for individual services, you likely split to small. And quite possibly, your staff isn't large enough to warrant it.
- dmix 6y ago
  Just because monoliths may have diminishing returns at certain team/project scale doesn't mean the scale itself is the problem...
  - FpUser 6y ago
    The problem is with people trying to do "cool" things when completely unwarranted
he0001 6y ago
But does conway’s law require microservices? It doesn’t say anything about microservices.
- camillovisini 6y ago
  > Melvin Conway, who introduced the idea in 1967.
  - he0001 6y ago
    Yes, I don’t think that you need microservices to be able to tackle Conway's law. At least it doesn’t have anything to do with each other. You could still do microservices and still fail to deal with Conway’s law.
    - detaro 6y ago
      > You could still do microservices and still fail to deal with Conway’s law. That's what the poster suggests happened. Nowhere do they suggest that microservices are overall required.
    - corpMaverick 6y ago
      You don't tackle Conway's law. You can't. You use it on your favor by creating organizational structures that reflect the design that you want in your software.
kitd 6y ago
As with a lot of things, it comes down to communication. Between teams, and between the services they write. Which is just another expression of Conway's Law. IIRC Fred Brooks pointed out that the # of bugs in a system correlates closely with the # of lines of communication within and between the teams. Joshua Bloch recommends in "Effective Java" that, if possible, 3 potential clients should participate in the design of an API, for the same reason. So a well-designed interface or OpenAPI spec is worth its weight in gold. Ofc, "microservices" here means separate running instances available on a network. But monoliths can be "service"-oriented as well. OSGi was good for this in Java, but any system able to load shared objects or plugins dynamically can follow the same pattern. And the benefit is that, if your app hits the jackpot and needs to scale outwards, the service interfaces, ie the lines of communication, are already well-defined. So, service-oriented monolith first, then microservices if needed.
- organsnyder 6y ago
  > So a well-designed interface or OpenAPI spec is worth its weight in gold. When I worked on a SOA team, I tried to begin any new effort (whether a new API or modification to existing API) solely discussing the API contract. It was (ideally) high-level enough that business analysts and project managers would understand it, and it helped to guide us away from getting mired in implementation discussions too early. At that organization, we rarely had the opportunity to involve multiple customers at the same time during design discussions (we were typically engaged to help a specific consumer implement a specific feature), but the institutional memory in the SOA team helped us to keep in mind existing/potential other users of each particular webservice.
  - hinkley 6y ago
    The last place I worked that split the devs into UI and backend teams was in a sort of slapstick comedy situation. Nothing ever shipped on time because the front end and backend could never quite talk to each other or needed elaborate conversations to do the simplest of things. This was our new flagship project, I got consolidated in from another team and ended up as a lead not long after. We had been doing some UML modeling, sequence diagrams during planning, and still having this problem, so rather than repeating the same action and expecting a different outcome I started trying to flip the script. What ended up working was not code diagrams but data flow diagrams and sequences. To get X you need Y, and to derive Z you need A, B, and X. To publish you need all five. After that, the APIs mostly wrote themselves, we reordered a few different forms, but most importantly variance dropped like a rock.
andy_ppp 6y ago
Yeah, the problem with microservices is because the organisation structure is wrong. I’ve literally heard every excuse about microservices at this point. My architecture is better but it doesn’t have a snappy name; it’s called the smallest possible number of services that can be reasoned about and network partitions are NOT necessary to create bounded contexts in a codebase, often just a directory is FINE.
- yowlingcat 6y ago
  I agree. I hate the term microservice for the same reason I hate superlative infected clickbait titles. There's no need for half of the word to exist. Service. What's wrong with service?
  - lllr_finger 6y ago
    I agree with you, but I find some value in people using that term - it signals to me that I should consider the the architecture was prematurely split-up and could suffer from the various pitfalls associated with microservices.
  - cturner 6y ago
    Microservice implies systems that are decoupled for deployment purposes. For example, Microservice A could restart to a new version while Microservice B keeps running. This is a more complicated interaction contract than services where their deployment is coordinated in concert.
    - xorcist 6y ago
      But this was true in the middleware type of products too, and you can't get more monolithic than that.
    - brown9-2 6y ago
      I don’t think this is accurate. I’ve worked at companies that did “service-oriented architecture” long before the rise of the term “microservice” and it was clearly recognized that different “services” shouldn’t be so coupled together you can’t redeploy them separately.
strictfp 6y ago
Noo! Building teams around software components cements your architecture and prevents most cross-cutting improvements. I'll claim that splitting a well-structured monolith into microservices will always make it less maintanable, but it might be worth it if you need to for some reason like elasticity or failure tolerance. But for the love of god, keep the design open. Don't tie the existence of internal software components to peoples livelihoods.
- mjburgess 6y ago
  > Don't tie the existence of internal software components to peoples livelihoods. The claim is that such ties, at the macro-structure level, are inevitable and exist regardless. The point is then to determine the best way either to restructure the organisation, or, the code base, to cope.
  - strictfp 6y ago
    I think the ties arise because people are actively seeking areas of responsibility. Software components are an obvious grab if your eyes are on the software specifically. But there are other ways of dividing your teams; based on for instance customers, use-cases, aspects of the code (performance, security). The problem is that the software usually keeps expanding until programmers find it hard to cope. If you split teams up so that some people are only concerned with a certain part of the codebase, chances are you are going to grow the size of the codebase by a quite large factor. I think there should be an incentive in place to keep the codebase small and understandable by most.
- jhrmnn 6y ago
  It's pretty hard to keep the design open once the whole architecture is bigger than what a single programmer can keep track of. Say, the Linux kernel. The overall architecture is fixed, there's no way around it. At that point, splitting into components that are maintained separately does no harm. AFAIK the Linux kernel is maintained like that already in practice, even if it's a single repo.
  - 6y ago
axegon_ 6y ago
Mmmmyes and no. Depending on the size of your project, that may not be the case. I've had to work with two titans of monoliths, maintained by relatively small teams(anywhere between 2 and 6-7 people for several million lines of code). At some point managing a codebase this big within a single project becomes a huge burden, for both developers and even more so for those who develop and do code-reviews(first hand experience right here). At times I've spent 3 weeks straight doing code reviews with 2 notebooks filled with notes and diagrams of the different components inside the code. And at that point, the easiest and most sensible thing to do is chunk out large parts of the project and put them aside as a microservice with the adequate amounts of tests. For small projects, microservices make little absolutely no sense. But in the case of something the size of AdWords(which my two such experiences can be compared to), you are playing with a raging lion if you decide to go monolith. My argument here is that it's not so much the size of your team but rather the size and scale of your project that needs to be taken into consideration.
- BareNakedCoder 6y ago
  Good monoliths are highly modularized. But it's a whole different thing to package up a module as a separately deployable unit for external "public" use (external to your app, that is, not your company). I'm just curious to know, when you said "the easiest and most sensible thing to do is chunk out large parts of the project and put them aside as a microservice" ... were these chunks separately deployable units for external "public" use.
  - joshdick 6y ago
    You're right, and I think you've highlighted what makes a good monolith so hard to build and maintain. You need to be disciplined to keep a monolith highly modularized. For microservices, in contrast, their architecture encourages modularization.
    - tinkertamper 6y ago
      I don’t know that you need to be much more disciplined to write a large application in a module way vs writing any application in a modular way. A monolith could definitely get messy though if you write them how I see people write microservices.
abraxas 6y ago
There is nothing wrong with most developers working on and communicating about the entire code base. Having teams work in silos is not a benefit. You're touting as a benefit what is one of microservices' gravest issues - teams stop communicating beyond the surface level of their respective APIs.
- marcosdumay 6y ago
  Have you tried coordinating entire teams to work on a shared codebase? Honestly, I have never been in an organization so large that this became a necessity (if you solve tens of different problems, that would require almost thousands of developers). But coordinating single developers without an API is hard enough already, I can only assume for teams its nearly impossible.
  - jacobr 6y ago
    Define “codebase”? You can have multiple services, user facing apps or modules inside a single repository, but if there are no boundaries coordination will be difficult of course.
    - marcosdumay 6y ago
      The definition implied by the GGP is: shared codebase = everybody will change the same lines; separated codebase = people will work on different sides of an API. At least, that's what I understand from his comment.
lubesGordi 6y ago
Maybe its conways law, or maybe it's just that designing a distributed service is difficult, and when you break a monolith down, you're having to deal with distributing that monolith N times, and solving those CAP issues N times, which usually is not trivial. Not to mention tuning the network.
deleted 6y ago
[deleted]
tomc1985 6y ago
A team per microservice? That sounds really wasteful. How many microservices need constant evolution?
ljm 6y ago
In all honesty, I think the monolith/microservice distinction misses the point a little bit. It's inevitable that the longer the codebase exists, the more difficult it is to maintain. It's a battle that you can't necessarily win and it's turtles all the way down as your dependencies, and their dependencies, tackle the same issues. All it takes is one or two roughly defined APIs and you've already created the nucleation point for ever-more tech debt, and while you'll be able to tame some of it you won't manage all of it due to business requirements, or other teams depending on private APIs to save time, or whatever else you can imagine. Switch the architecture and you'll either have all your problems bunched in one codebase, or you'll have distributed your problems all over the place. I'd go as far as saying that a perfect monolith and a perfect distributed architecture are theoretical ideals that require perfect communication to build them.
nickbauman 6y ago
I cannot agree more: I worked at a company where we went from a monolith deployed on IaaS with a couple handful of engineers to Docker containers deployed on ECS with over 200 engineers. The main reason we did it was because Docker+ECS was cheaper than a bunch of EC2 instances and you can't effectively use 200+ engineers with a single monolith. After 2 years we had over 450 microservices while keeping our AWS bill flat or slightly decreasing.
- wgjordan 6y ago
  On the other hand, over 200 engineers on payroll is way more expensive than a couple handful! Presumably you're getting significant value out of the additional engineering work in which case the architecture shift probably makes sense (to stay aligned with the expanded organizational structure), but there are also cases where a small and flexible team maintaining a simple monolith would be much more nimble and cost-effective.
dahfizz 6y ago
I don't agree with your premise that development structure == deployment structure. There are plenty of good ways of splitting up development of a monolith without the huge devops headache of deploying microservices.
darkr 6y ago
> I think microservices work well in organizations that are big enough to have a team per microservice. Presumably by definition we’re talking about a few hundred lines of code, or a couple of weeks development time here at most. What does this team do all day otherwise?

by nickcw 6y ago

FpUser 6y ago

So you are saying something in line of: let's increase our development staff X-fold and then we can finally do the same thing that way fewer people doing just fine right now?

Tomis02 6y ago
With microservices there's no way around it, as there's additional overhead when splitting a for loop between multiple services. Won't stop people from jumping on the bandwagon though.
detaro 6y ago
They're clearly not saying that. If your team is too large to effectively work on a monolith, splitting it up can make sense, but you also need to split the team into smaller groups responsible for different parts. And if you don't end up with teams responsible for individual services, you likely split to small. And quite possibly, your staff isn't large enough to warrant it.
dmix 6y ago
Just because monoliths may have diminishing returns at certain team/project scale doesn't mean the scale itself is the problem...
- FpUser 6y ago
  The problem is with people trying to do "cool" things when completely unwarranted

he0001 6y ago

But does conway’s law require microservices? It doesn’t say anything about microservices.

camillovisini 6y ago
> Melvin Conway, who introduced the idea in 1967.
- he0001 6y ago
  Yes, I don’t think that you need microservices to be able to tackle Conway's law. At least it doesn’t have anything to do with each other. You could still do microservices and still fail to deal with Conway’s law.
  - detaro 6y ago
    > You could still do microservices and still fail to deal with Conway’s law. That's what the poster suggests happened. Nowhere do they suggest that microservices are overall required.
  - corpMaverick 6y ago
    You don't tackle Conway's law. You can't. You use it on your favor by creating organizational structures that reflect the design that you want in your software.

kitd 6y ago

As with a lot of things, it comes down to communication. Between teams, and between the services they write. Which is just another expression of Conway's Law. IIRC Fred Brooks pointed out that the # of bugs in a system correlates closely with the # of lines of communication within and between the teams. Joshua Bloch recommends in "Effective Java" that, if possible, 3 potential clients should participate in the design of an API, for the same reason. So a well-designed interface or OpenAPI spec is worth its weight in gold. Ofc, "microservices" here means separate running instances available on a network. But monoliths can be "service"-oriented as well. OSGi was good for this in Java, but any system able to load shared objects or plugins dynamically can follow the same pattern. And the benefit is that, if your app hits the jackpot and needs to scale outwards, the service interfaces, ie the lines of communication, are already well-defined. So, service-oriented monolith first, then microservices if needed.

organsnyder 6y ago
> So a well-designed interface or OpenAPI spec is worth its weight in gold. When I worked on a SOA team, I tried to begin any new effort (whether a new API or modification to existing API) solely discussing the API contract. It was (ideally) high-level enough that business analysts and project managers would understand it, and it helped to guide us away from getting mired in implementation discussions too early. At that organization, we rarely had the opportunity to involve multiple customers at the same time during design discussions (we were typically engaged to help a specific consumer implement a specific feature), but the institutional memory in the SOA team helped us to keep in mind existing/potential other users of each particular webservice.
- hinkley 6y ago
  The last place I worked that split the devs into UI and backend teams was in a sort of slapstick comedy situation. Nothing ever shipped on time because the front end and backend could never quite talk to each other or needed elaborate conversations to do the simplest of things. This was our new flagship project, I got consolidated in from another team and ended up as a lead not long after. We had been doing some UML modeling, sequence diagrams during planning, and still having this problem, so rather than repeating the same action and expecting a different outcome I started trying to flip the script. What ended up working was not code diagrams but data flow diagrams and sequences. To get X you need Y, and to derive Z you need A, B, and X. To publish you need all five. After that, the APIs mostly wrote themselves, we reordered a few different forms, but most importantly variance dropped like a rock.

andy_ppp 6y ago

Yeah, the problem with microservices is because the organisation structure is wrong. I’ve literally heard every excuse about microservices at this point. My architecture is better but it doesn’t have a snappy name; it’s called the smallest possible number of services that can be reasoned about and network partitions are NOT necessary to create bounded contexts in a codebase, often just a directory is FINE.

yowlingcat 6y ago
I agree. I hate the term microservice for the same reason I hate superlative infected clickbait titles. There's no need for half of the word to exist. Service. What's wrong with service?
- lllr_finger 6y ago
  I agree with you, but I find some value in people using that term - it signals to me that I should consider the the architecture was prematurely split-up and could suffer from the various pitfalls associated with microservices.
- cturner 6y ago
  Microservice implies systems that are decoupled for deployment purposes. For example, Microservice A could restart to a new version while Microservice B keeps running. This is a more complicated interaction contract than services where their deployment is coordinated in concert.
  - xorcist 6y ago
    But this was true in the middleware type of products too, and you can't get more monolithic than that.
  - brown9-2 6y ago
    I don’t think this is accurate. I’ve worked at companies that did “service-oriented architecture” long before the rise of the term “microservice” and it was clearly recognized that different “services” shouldn’t be so coupled together you can’t redeploy them separately.

strictfp 6y ago

Noo! Building teams around software components cements your architecture and prevents most cross-cutting improvements. I'll claim that splitting a well-structured monolith into microservices will always make it less maintanable, but it might be worth it if you need to for some reason like elasticity or failure tolerance. But for the love of god, keep the design open. Don't tie the existence of internal software components to peoples livelihoods.

mjburgess 6y ago
> Don't tie the existence of internal software components to peoples livelihoods. The claim is that such ties, at the macro-structure level, are inevitable and exist regardless. The point is then to determine the best way either to restructure the organisation, or, the code base, to cope.
- strictfp 6y ago
  I think the ties arise because people are actively seeking areas of responsibility. Software components are an obvious grab if your eyes are on the software specifically. But there are other ways of dividing your teams; based on for instance customers, use-cases, aspects of the code (performance, security). The problem is that the software usually keeps expanding until programmers find it hard to cope. If you split teams up so that some people are only concerned with a certain part of the codebase, chances are you are going to grow the size of the codebase by a quite large factor. I think there should be an incentive in place to keep the codebase small and understandable by most.
jhrmnn 6y ago
It's pretty hard to keep the design open once the whole architecture is bigger than what a single programmer can keep track of. Say, the Linux kernel. The overall architecture is fixed, there's no way around it. At that point, splitting into components that are maintained separately does no harm. AFAIK the Linux kernel is maintained like that already in practice, even if it's a single repo.
- 6y ago

axegon_ 6y ago

Mmmmyes and no. Depending on the size of your project, that may not be the case. I've had to work with two titans of monoliths, maintained by relatively small teams(anywhere between 2 and 6-7 people for several million lines of code). At some point managing a codebase this big within a single project becomes a huge burden, for both developers and even more so for those who develop and do code-reviews(first hand experience right here). At times I've spent 3 weeks straight doing code reviews with 2 notebooks filled with notes and diagrams of the different components inside the code. And at that point, the easiest and most sensible thing to do is chunk out large parts of the project and put them aside as a microservice with the adequate amounts of tests. For small projects, microservices make little absolutely no sense. But in the case of something the size of AdWords(which my two such experiences can be compared to), you are playing with a raging lion if you decide to go monolith. My argument here is that it's not so much the size of your team but rather the size and scale of your project that needs to be taken into consideration.

BareNakedCoder 6y ago
Good monoliths are highly modularized. But it's a whole different thing to package up a module as a separately deployable unit for external "public" use (external to your app, that is, not your company). I'm just curious to know, when you said "the easiest and most sensible thing to do is chunk out large parts of the project and put them aside as a microservice" ... were these chunks separately deployable units for external "public" use.
- joshdick 6y ago
  You're right, and I think you've highlighted what makes a good monolith so hard to build and maintain. You need to be disciplined to keep a monolith highly modularized. For microservices, in contrast, their architecture encourages modularization.
  - tinkertamper 6y ago
    I don’t know that you need to be much more disciplined to write a large application in a module way vs writing any application in a modular way. A monolith could definitely get messy though if you write them how I see people write microservices.

abraxas 6y ago

There is nothing wrong with most developers working on and communicating about the entire code base. Having teams work in silos is not a benefit. You're touting as a benefit what is one of microservices' gravest issues - teams stop communicating beyond the surface level of their respective APIs.

marcosdumay 6y ago
Have you tried coordinating entire teams to work on a shared codebase? Honestly, I have never been in an organization so large that this became a necessity (if you solve tens of different problems, that would require almost thousands of developers). But coordinating single developers without an API is hard enough already, I can only assume for teams its nearly impossible.
- jacobr 6y ago
  Define “codebase”? You can have multiple services, user facing apps or modules inside a single repository, but if there are no boundaries coordination will be difficult of course.
  - marcosdumay 6y ago
    The definition implied by the GGP is: shared codebase = everybody will change the same lines; separated codebase = people will work on different sides of an API. At least, that's what I understand from his comment.

lubesGordi 6y ago

Maybe its conways law, or maybe it's just that designing a distributed service is difficult, and when you break a monolith down, you're having to deal with distributing that monolith N times, and solving those CAP issues N times, which usually is not trivial. Not to mention tuning the network.

deleted 6y ago

[deleted]

tomc1985 6y ago

A team per microservice? That sounds really wasteful. How many microservices need constant evolution?

ljm 6y ago

In all honesty, I think the monolith/microservice distinction misses the point a little bit. It's inevitable that the longer the codebase exists, the more difficult it is to maintain. It's a battle that you can't necessarily win and it's turtles all the way down as your dependencies, and their dependencies, tackle the same issues. All it takes is one or two roughly defined APIs and you've already created the nucleation point for ever-more tech debt, and while you'll be able to tame some of it you won't manage all of it due to business requirements, or other teams depending on private APIs to save time, or whatever else you can imagine. Switch the architecture and you'll either have all your problems bunched in one codebase, or you'll have distributed your problems all over the place. I'd go as far as saying that a perfect monolith and a perfect distributed architecture are theoretical ideals that require perfect communication to build them.

nickbauman 6y ago

I cannot agree more: I worked at a company where we went from a monolith deployed on IaaS with a couple handful of engineers to Docker containers deployed on ECS with over 200 engineers. The main reason we did it was because Docker+ECS was cheaper than a bunch of EC2 instances and you can't effectively use 200+ engineers with a single monolith. After 2 years we had over 450 microservices while keeping our AWS bill flat or slightly decreasing.

wgjordan 6y ago
On the other hand, over 200 engineers on payroll is way more expensive than a couple handful! Presumably you're getting significant value out of the additional engineering work in which case the architecture shift probably makes sense (to stay aligned with the expanded organizational structure), but there are also cases where a small and flexible team maintaining a simple monolith would be much more nimble and cost-effective.

dahfizz 6y ago

I don't agree with your premise that development structure == deployment structure. There are plenty of good ways of splitting up development of a monolith without the huge devops headache of deploying microservices.

darkr 6y ago

> I think microservices work well in organizations that are big enough to have a team per microservice. Presumably by definition we’re talking about a few hundred lines of code, or a couple of weeks development time here at most. What does this team do all day otherwise?