4 ms·

Your comment reads like you did not read beyond the title. In the article they provide analysis and contexts in which microservices are usable. Article does not

Your comment reads like you did not read beyond the title. In the article they provide analysis and contexts in which microservices are usable. Article does not fit in your description of "ignorant" or "completely convinced of one way".

lolinder 2y ago
> Let’s do a 1:1 comparison of microservices and modules. Spoiler alert: the argument favors modules, as there is little to be said in support of microservices when pitted against modules! This is the introduction to their argument and it definitely accurately captures the tone of the rest of the article. As for ignorance, you get frequent sections like this: > With a monolithic architecture, your system is either UP or DOWN, with no in-between. With microservices, you need to monitor every service. All the services need to be UP, and they need to be able to communicate with each other, all for you to be able to say the system is UP. If even one out of your 888 services is down, the system can no longer be called UP! The author manages to take one of the most compelling uses of microservices and turn it into a negative thing. Somehow in their mind switching from a model where you're either UP or DOWN to a model where you can be partially UP is worse, which suggests to me that they don't have very much experience operating either type of architecture. Managing an incident during a partial outage is infinitely less stressful than managing a complete outage. Whether you can officially label the entire system as UP is immaterial in a real ops context if the impact of the isolated service that is DOWN is minimal.
- solidasparagus 2y ago
  In smaller/earlier projects, there may not be such a thing as partially up or partially down. Every module/service can be on the critical path. And if that's the case, it's easier to not be dealing with a distributed system (or to have a minimally distributed one).
  - lolinder 2y ago
    I mean, yeah, don't use microservices if you're in a small or early project. That's a totally valid argument that I 100% agree with. Microservices solve a specific category of problems that you don't have until you reach a certain scale (either organizationally or operationally). But again, this is their thesis statement: > Let’s do a 1:1 comparison of microservices and modules. Spoiler alert: the argument favors modules, as there is little to be said in support of microservices when pitted against modules! Their essay leaves very little room for legitimate technical reasons for a service to be split out from the monolith. Even their section titled "When Should You Consider Using Microservices?" basically boils down to "if you already have microservices, if you absolutely must use a different language, or if you're an irresponsible idiot".
    - solidasparagus 2y ago
      Oh yeah I'm not gonna defend the article. I was only really responding to this line. > Somehow in their mind switching from a model where you're either UP or DOWN to a model where you can be partially UP is worse, which suggests to me that they don't have very much experience operating either type of architecture.
      - lolinder 2y ago
        Ah, got it. Yeah, I can imagine someone coming to their conclusion if the only system they've ever worked with doesn't have any major components that aren't on the critical path.

lolinder 2y ago

> Let’s do a 1:1 comparison of microservices and modules. Spoiler alert: the argument favors modules, as there is little to be said in support of microservices when pitted against modules! This is the introduction to their argument and it definitely accurately captures the tone of the rest of the article. As for ignorance, you get frequent sections like this: > With a monolithic architecture, your system is either UP or DOWN, with no in-between. With microservices, you need to monitor every service. All the services need to be UP, and they need to be able to communicate with each other, all for you to be able to say the system is UP. If even one out of your 888 services is down, the system can no longer be called UP! The author manages to take one of the most compelling uses of microservices and turn it into a negative thing. Somehow in their mind switching from a model where you're either UP or DOWN to a model where you can be partially UP is worse, which suggests to me that they don't have very much experience operating either type of architecture. Managing an incident during a partial outage is infinitely less stressful than managing a complete outage. Whether you can officially label the entire system as UP is immaterial in a real ops context if the impact of the isolated service that is DOWN is minimal.

solidasparagus 2y ago
In smaller/earlier projects, there may not be such a thing as partially up or partially down. Every module/service can be on the critical path. And if that's the case, it's easier to not be dealing with a distributed system (or to have a minimally distributed one).
- lolinder 2y ago
  I mean, yeah, don't use microservices if you're in a small or early project. That's a totally valid argument that I 100% agree with. Microservices solve a specific category of problems that you don't have until you reach a certain scale (either organizationally or operationally). But again, this is their thesis statement: > Let’s do a 1:1 comparison of microservices and modules. Spoiler alert: the argument favors modules, as there is little to be said in support of microservices when pitted against modules! Their essay leaves very little room for legitimate technical reasons for a service to be split out from the monolith. Even their section titled "When Should You Consider Using Microservices?" basically boils down to "if you already have microservices, if you absolutely must use a different language, or if you're an irresponsible idiot".
  - solidasparagus 2y ago
    Oh yeah I'm not gonna defend the article. I was only really responding to this line. > Somehow in their mind switching from a model where you're either UP or DOWN to a model where you can be partially UP is worse, which suggests to me that they don't have very much experience operating either type of architecture.
    - lolinder 2y ago
      Ah, got it. Yeah, I can imagine someone coming to their conclusion if the only system they've ever worked with doesn't have any major components that aren't on the critical path.