4 ms·

If you achieve this scale of teams suggested, it means you have a lot of implicit gains here as well, right? Such as higher quality, higher "velocity", separat

If you achieve this scale of teams suggested, it means you have a lot of implicit gains here as well, right? Such as higher quality, higher "velocity", separation of concern and hopefully a clear sense of ownership. These are some of the things in my opinion that allows you to scale.

lmm 8y ago
> If you achieve this scale of teams suggested, it means you have a lot of implicit gains here as well, right? > Such as higher quality, higher "velocity", separation of concern and hopefully a clear sense of ownership. No, it means you pay a huge overhead. Quality and velocity both drop as your day-to-day development requires a lot more setup and faff to do anything, and counterintuitively so does separation of concerns as your interfaces become more rigid. Small organisations should do things that don't scale, turn their size into an advantage. If you think of your overhead as ax + bx^2 where x is the number of developers, microservices are a way to reduce b, but at the cost of a big increase to a. It makes sense when x is huge but not before. My litmus test would be: do you need to do multiple (unrelated) deployments of different services at once? If your organisation is small enough that you can get away with only deploying one thing at a time, you'll probably have less overhead if you work without microservices.
- jordanbeiber 8y ago
  Which is why you’ll need the input and help from experienced sysadmins that like to do development, which actually is ”automation”. This done right reduces overhead and gives you an edge in repeatability and quality. Both are required to scale.
  - lmm 8y ago
    Automated deployment and the like is worthwhile whether your system is microservice or monolith. But no amount of automation can eliminate the overhead a network boundary brings to local development.
    - jordanbeiber 8y ago
      We view this a bit different, and that’s fine (not the automation part, here we agree). Automation in this context is for me more than just the deploy bit, it’s also about testing and service management which includes for example service relationships and discovery. If you could do local dev on that app as a monolith, it can most likely be done broken up in smaller services as well. There are no silver bullets to be had anywhere, right? Just use whatever processes and tools that work, until they don’t I guess.
      - lmm 8y ago
        > If you could do local dev on that app as a monolith, it can most likely be done broken up in smaller services as well. It's possible, but the overhead is a lot higher, and that weighs down everything you do. Your edit-test cycle gets longer, development gets slower. > There are no silver bullets to be had anywhere, right? Just use whatever processes and tools that work, until they don’t I guess. Nothing is perfect but often one choice is better than another. I've seen microservices go badly much more often than monoliths, and most successful microservice systems were built as a monolith first with services separated out only when it became necessary.
        jordanbeiber 8y ago
        Yes, there is bound to be overhead as you describe. For some it might be worth the effort, but no doubt effort is involved. Regarding monolith -> ms — I’m starting to think this is the way to do it — once you have the flow of data already estblished and the (working) system(s) somewhat defined it becomes easier to decouple bits and pieces.
      - jacques_chester 8y ago
        In think your interlocutor's point is that type checking by a compiler is a lot simpler, more reliable and more performant than any networked service discovery scheme so far conceived. I think microservice architectures can genuinely decouple teams to iterate faster and consolidate efforts. But it's not a free lunch.

lmm 8y ago

> If you achieve this scale of teams suggested, it means you have a lot of implicit gains here as well, right? > Such as higher quality, higher "velocity", separation of concern and hopefully a clear sense of ownership. No, it means you pay a huge overhead. Quality and velocity both drop as your day-to-day development requires a lot more setup and faff to do anything, and counterintuitively so does separation of concerns as your interfaces become more rigid. Small organisations should do things that don't scale, turn their size into an advantage. If you think of your overhead as ax + bx^2 where x is the number of developers, microservices are a way to reduce b, but at the cost of a big increase to a. It makes sense when x is huge but not before. My litmus test would be: do you need to do multiple (unrelated) deployments of different services at once? If your organisation is small enough that you can get away with only deploying one thing at a time, you'll probably have less overhead if you work without microservices.

jordanbeiber 8y ago
Which is why you’ll need the input and help from experienced sysadmins that like to do development, which actually is ”automation”. This done right reduces overhead and gives you an edge in repeatability and quality. Both are required to scale.
- lmm 8y ago
  Automated deployment and the like is worthwhile whether your system is microservice or monolith. But no amount of automation can eliminate the overhead a network boundary brings to local development.
  - jordanbeiber 8y ago
    We view this a bit different, and that’s fine (not the automation part, here we agree). Automation in this context is for me more than just the deploy bit, it’s also about testing and service management which includes for example service relationships and discovery. If you could do local dev on that app as a monolith, it can most likely be done broken up in smaller services as well. There are no silver bullets to be had anywhere, right? Just use whatever processes and tools that work, until they don’t I guess.
    - lmm 8y ago
      > If you could do local dev on that app as a monolith, it can most likely be done broken up in smaller services as well. It's possible, but the overhead is a lot higher, and that weighs down everything you do. Your edit-test cycle gets longer, development gets slower. > There are no silver bullets to be had anywhere, right? Just use whatever processes and tools that work, until they don’t I guess. Nothing is perfect but often one choice is better than another. I've seen microservices go badly much more often than monoliths, and most successful microservice systems were built as a monolith first with services separated out only when it became necessary.
      - jordanbeiber 8y ago
        Yes, there is bound to be overhead as you describe. For some it might be worth the effort, but no doubt effort is involved. Regarding monolith -> ms — I’m starting to think this is the way to do it — once you have the flow of data already estblished and the (working) system(s) somewhat defined it becomes easier to decouple bits and pieces.
    - jacques_chester 8y ago
      In think your interlocutor's point is that type checking by a compiler is a lot simpler, more reliable and more performant than any networked service discovery scheme so far conceived. I think microservice architectures can genuinely decouple teams to iterate faster and consolidate efforts. But it's not a free lunch.