4 ms·

So somehow you can't end up with the micro services version of spaghetti code? If an engineering organization can't handle managing a single codebase, why would

So somehow you can't end up with the micro services version of spaghetti code? If an engineering organization can't handle managing a single codebase, why would you assume they would be good stewards of multiple codebases?

tracker1 8y ago
Not only that, but who takes on the configuration and orchestration complexity of micro services? I'm not saying they cannot work, but often a restructured monolith is still a better idea... I prefer to break off bottlenecks into services where practical. Such as doing image resizing in a separate service. Breaking data structures apart often leads to it's own form of spaghetti.
- slowmovintarget 8y ago
  Microservices allow you to scale your organization, not your application. For that particular use, microservices are absolutely better than monoliths. I can say this based on four years working on a large multi-tenant service platform composed of several hundred microservices, held against a background of 24 years building software systems, including multi-million-line monoliths (good and bad). If you're a small company, should you start with a microservices architecture? No. It is much harder to operate. Should you factor your monolith so it is easy to transition to microservices later? Yes. Your monolith will be of higher quality for doing so.
  - tracker1 8y ago
    I'm not against smaller services... but I've seen people use them, "because" and break their data models into separate services where coordinating data then becomes weird to say the least. I'm not against micro-services, I'm against making everything a microservice because one can.
  - mbrodersen 8y ago
    Change "micro-service" to "library" and you have a technology that scales equally well without introducing the additional failure modes and complexities of micro-services. That's how pretty much all open source software works. Open source software consists of thousands of libraries that people reuse for all kinds of purposes.
jhall1468 8y ago
You can, and you will. But the mental overhead in "rewrite this 500 line service in a way that doesn't suck" isn't that high. That's not true of a 700,000 line monolith.
- TheCoelacanth 8y ago
  Instead you have the overhead of "rewrite these 50 services to have an architecture that doesn't suck".
  - mpweiher 8y ago
    And that architecture is written down nowhere, it is implicit in the different individual services. It's also an architecture that is now much more prone to failures, because while procedure calls essentially never fail, RPCs do. Or if they don't fail outright, have unpredictable latencies etc. (I turned a microservices/SOA code-base into monolith back in 2003/2004. It worked wonders.)
    - YawningAngel 8y ago
      Interestingly, RPCs failing is not really a problem at companies with heavy investment in microservice tooling. Everything is set up to retry transparently below the application layer. Obviously this costs in terms of infrastructure and latency but it's essentially transparent to the programmer.
      - mpweiher 8y ago
        > RPCs failing is not really a problem. Hmm... 1. Software applications are written with little error-handling on networking errors. During a network outage, such applications may stall or infinitely wait for an answer packet, permanently consuming memory or other resources. When the failed network becomes available, those applications may also fail to retry any stalled operations or require a (manual) restart. https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu... Infinite retries aren't "not really a problem". If the server isn't there or can't be reached, it isn't there or can't be reached. This is not a problem software/infrastructure can paper over transparently. You can try your best to mitigate, but that's hard, and often makes things worse. I remember a colleague trying out CouchDB. His takeaway was that all error-recovery attempts by distributed CouchDB servers made things worse. So you could use it as a semi-decent single-instance DB, but mercy on your soul should you be so brazen as to attempt to use the distribution features. > heavy investment in microservice tooling. And what percentage of microservices is that? > costs in terms of infrastructure and latency >> Or if they don't fail outright, have unpredictable latencies Hmm...

tracker1 8y ago

Not only that, but who takes on the configuration and orchestration complexity of micro services? I'm not saying they cannot work, but often a restructured monolith is still a better idea... I prefer to break off bottlenecks into services where practical. Such as doing image resizing in a separate service. Breaking data structures apart often leads to it's own form of spaghetti.

slowmovintarget 8y ago
Microservices allow you to scale your organization, not your application. For that particular use, microservices are absolutely better than monoliths. I can say this based on four years working on a large multi-tenant service platform composed of several hundred microservices, held against a background of 24 years building software systems, including multi-million-line monoliths (good and bad). If you're a small company, should you start with a microservices architecture? No. It is much harder to operate. Should you factor your monolith so it is easy to transition to microservices later? Yes. Your monolith will be of higher quality for doing so.
- tracker1 8y ago
  I'm not against smaller services... but I've seen people use them, "because" and break their data models into separate services where coordinating data then becomes weird to say the least. I'm not against micro-services, I'm against making everything a microservice because one can.
- mbrodersen 8y ago
  Change "micro-service" to "library" and you have a technology that scales equally well without introducing the additional failure modes and complexities of micro-services. That's how pretty much all open source software works. Open source software consists of thousands of libraries that people reuse for all kinds of purposes.

jhall1468 8y ago

You can, and you will. But the mental overhead in "rewrite this 500 line service in a way that doesn't suck" isn't that high. That's not true of a 700,000 line monolith.

TheCoelacanth 8y ago
Instead you have the overhead of "rewrite these 50 services to have an architecture that doesn't suck".
- mpweiher 8y ago
  And that architecture is written down nowhere, it is implicit in the different individual services. It's also an architecture that is now much more prone to failures, because while procedure calls essentially never fail, RPCs do. Or if they don't fail outright, have unpredictable latencies etc. (I turned a microservices/SOA code-base into monolith back in 2003/2004. It worked wonders.)
  - YawningAngel 8y ago
    Interestingly, RPCs failing is not really a problem at companies with heavy investment in microservice tooling. Everything is set up to retry transparently below the application layer. Obviously this costs in terms of infrastructure and latency but it's essentially transparent to the programmer.
    - mpweiher 8y ago
      > RPCs failing is not really a problem. Hmm... 1. Software applications are written with little error-handling on networking errors. During a network outage, such applications may stall or infinitely wait for an answer packet, permanently consuming memory or other resources. When the failed network becomes available, those applications may also fail to retry any stalled operations or require a (manual) restart. https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu... Infinite retries aren't "not really a problem". If the server isn't there or can't be reached, it isn't there or can't be reached. This is not a problem software/infrastructure can paper over transparently. You can try your best to mitigate, but that's hard, and often makes things worse. I remember a colleague trying out CouchDB. His takeaway was that all error-recovery attempts by distributed CouchDB servers made things worse. So you could use it as a semi-decent single-instance DB, but mercy on your soul should you be so brazen as to attempt to use the distribution features. > heavy investment in microservice tooling. And what percentage of microservices is that? > costs in terms of infrastructure and latency >> Or if they don't fail outright, have unpredictable latencies Hmm...