4 ms·

If you're going to complain about something you need to present some data that backs up your point, this is just a bunch or rambling opinions. A lot of softwar

If you're going to complain about something you need to present some data that backs up your point, this is just a bunch or rambling opinions. A lot of software engineering is about managing modularization, I've lived through structured programming, OOx, various distributed object schemes and now this. Basically all these mechanisms attempt to solve the problem of modularization and reuse. So, the fact that new solutions to the old problems appear just means that it's a hard problem worth working on. I'd say use every single technique when it's appropriate.

vlunkr 5y ago
From the article: """ If we think about the fastest way to execute some code, that is a function call, not a web request. If we think about the best way to make sure we detect problems at compile time, that is by using a library at a compiled language. If we think about the best way to understand why something failed, that is a full stack trace. If we think about resilient systems, the most resilient systems are the ones with the least number of moving parts. The same is true for the fastest systems. If we think about deployment and management and upgrades, the simplest systems to deploy and maintain also have the least number of moving parts. """ You don't really need any data to back this up, it's all self-evident.
- jjnoakes 5y ago
  I'm not for or against microservices, but that seems like quite the cherry-picked list. There are arguments on the other side too, such as... If we think about the easiest way to swap out pieces of functionality, that is by using well-defined interfaces, low coupling, and separation of concerns. If we think about the easiest way to scale parts of the whole independently, that is by similar mechanisms. If we think about the easiest way to build in fault-tolerance, that is by distributing work across failure points. And so on...
  - hackerfromthefu 5y ago
    But well-defined interfaces are not specific to microservices (ms). Low coupling, high cohesion, separation of concerns and well defined interfaces are simply system architecture. Which is easier to work with without the infrastructure overhead of loads of semi-independent ms. Ms is a net loss here because your complexity budget is consumed by the infrastructure instead of the system architecture. Fault tolerance again is largely orthagonal to ms. It's a matter or system architecture, see the point above. e.g. A common situation where service one depends on availability from service two, having them as seperate ms doesn't help, what helps is architectural design to keep service two useful somehow regardless, and this is orthagonal to if the services are in process or done as ms. Scaling is a whole other discussion, and microservices can have good impact here, but so can other techniques.
  - hu3 5y ago
    > If we think about the easiest way to swap out pieces of functionality, that is by using well-defined interfaces, low coupling, and separation of concerns. Microservices don't enforce good practices and monoliths don't prevent them either.
    - jjnoakes 5y ago
      Right, but some of those desirable system properties are much easier and lower friction in microservices. And others in monoliths. Each has its pros and cons.

vlunkr 5y ago

From the article: """ If we think about the fastest way to execute some code, that is a function call, not a web request. If we think about the best way to make sure we detect problems at compile time, that is by using a library at a compiled language. If we think about the best way to understand why something failed, that is a full stack trace. If we think about resilient systems, the most resilient systems are the ones with the least number of moving parts. The same is true for the fastest systems. If we think about deployment and management and upgrades, the simplest systems to deploy and maintain also have the least number of moving parts. """ You don't really need any data to back this up, it's all self-evident.

jjnoakes 5y ago
I'm not for or against microservices, but that seems like quite the cherry-picked list. There are arguments on the other side too, such as... If we think about the easiest way to swap out pieces of functionality, that is by using well-defined interfaces, low coupling, and separation of concerns. If we think about the easiest way to scale parts of the whole independently, that is by similar mechanisms. If we think about the easiest way to build in fault-tolerance, that is by distributing work across failure points. And so on...
- hackerfromthefu 5y ago
  But well-defined interfaces are not specific to microservices (ms). Low coupling, high cohesion, separation of concerns and well defined interfaces are simply system architecture. Which is easier to work with without the infrastructure overhead of loads of semi-independent ms. Ms is a net loss here because your complexity budget is consumed by the infrastructure instead of the system architecture. Fault tolerance again is largely orthagonal to ms. It's a matter or system architecture, see the point above. e.g. A common situation where service one depends on availability from service two, having them as seperate ms doesn't help, what helps is architectural design to keep service two useful somehow regardless, and this is orthagonal to if the services are in process or done as ms. Scaling is a whole other discussion, and microservices can have good impact here, but so can other techniques.
- hu3 5y ago
  > If we think about the easiest way to swap out pieces of functionality, that is by using well-defined interfaces, low coupling, and separation of concerns. Microservices don't enforce good practices and monoliths don't prevent them either.
  - jjnoakes 5y ago
    Right, but some of those desirable system properties are much easier and lower friction in microservices. And others in monoliths. Each has its pros and cons.