7 ms·

The author never discusses the most important pieces of microservices. The biggest one in my mind being organizational scalability. He talks about scalability f

The author never discusses the most important pieces of microservices. The biggest one in my mind being organizational scalability. He talks about scalability from a performance viewpoint but not an org standpoint. Same with speed. Yes microservices add overhead and can be slower than a monolith, but they can give you autonomy and business speed. Business speed is so much more important than performance.

eej71 10y ago
I think the author criticizes that view point in the final paragraph of fallacy #4. No?
- nhumrich 10y ago
  Not really. That section is about "simplicity". Microservices can be more complicated, but they shorten the feedback loop and reduce hand-offs.
fdim 10y ago
Until performance becomes a critical issue and then you have to deal with increased costs (hardware), caching, complexity... And if you happen to pair service with its own database (trustpilot), aggregating data for statistical reason becomes even more 'fun'.
blauditore 10y ago
I think it's touched in #2 and #4. The author argues that it becomes more complicated because each service needs to be understood thoroughly and mentions the "not-my-problem syndrome". While these issues are definitely there, the problem of understanding a subsystem also exists on large monolithic applications. The not-my-problem syndrome seems like an indicator of bad devs and/or company culture (I've seen this happen once) and might be mitigated by making people work on multiple microservices instead of completely separating them. In my opinion, separating a big project into multiple services emerges from the fact that most languages don't have built-in features for modularization on a large scale. In Java, for instance, there are methods < classes < packages. Once there are dozens of packages and thousands of classes, a project becomes hard to navigate and understand, especially when code isn't well-written with hacks disregarding modularizations. Using microservices reduces scope and prohibits some of these no-gos.
- lmm 10y ago
  > In Java, for instance, there are methods < classes < packages. Once there are dozens of packages and thousands of classes, a project becomes hard to navigate and understand, especially when code isn't well-written with hacks disregarding modularizations. Using microservices reduces scope and prohibits some of these no-gos. At that point you step up to using multiple maven modules. Which can give much the same development experience as microservices, but without the extra network boundary.
  - blauditore 10y ago
    Yeah, that's one way to go, and also supports separate versioning and release cycles of different subsystems. However, since all code is compiled into one large application there are other problems arising. One I've seen often is sloppy dependency management: A explicitly depends on B, B on C. Now, a dev working in A starts using classes from C without declaring the dependency. Everything works because C is still included through B, but as soon as B gets removed, things start to break. There is mvn dependency:analyze to discover such issues, but it's not 100% exact, and people need to actively use it. I think such a system built into and enforced by a language would be another quantum leap.
    - lmm 10y ago
      It's very normal for methods in B to return types from C in that scenario though. And if you do remove the dependency on B, you get the error at compile time. So I don't see this as a major problem (it's maybe a problem if something's implicitly activated by reflection, but I see the reflection as the bigger problem there)
      - blauditore 10y ago
        When running into these runtime errors, it's sometimes not clear what module a missing class came from for complex setups, especially in a part of code you didn't recently work in. Then, the right version needs to be determined by following removed intermediate modules. It would just be cleaner and more reliable if the original dev had done this when writing the code in question. But yeah, at least it fails on compile time already.
djsumdog 10y ago
The author didn't discuss queues once. I work at a company that uses microservices and queues. Right now we use Rabbit, which is terrible for some reasons I won't get into, but the one good thing about it is that each message has to be acked. You take a message, you process it and then you make that you've processed it. Things don't get lost. You can requeue messages that end up being dead-lettered due to bugs. You can scale the number of services that read from that queue. You can have services up independently if they just read and write from a system that says, "here's a chunk of data to process." You can loose data with Rabbit, and if you're starting from the ground up you might want to look at something like Kafka instead. If you don't care about message loss and just need throughput (like if you're doing real time logs or sensor data), something like zeromq might be more appropriate. The idea behind microservices is that you gain stability at the expense of some redundancy.
- UK-AL 10y ago
  We use queues + microservices. It's a good combo. We also split the messages into different types, commands and events. A command is to perform a specific action and is normally aimed at a specific service. And event alerts any subscribed service that a action has happened. So you send a CreateOrder command. After processing it would fire off a CreatedOrder event which any subscribed service could pick up(Such as a EmailService sending a confirm email). Allows you to create workflows, and monitoring systems quite easily. I'm interested in your experience with RabbitMQ?
  - deleted 10y ago
    [deleted]
  - djsumdog 10y ago
    So you're using event sourcing then? We're doing the same thing using akka-persistence. I'm not directly on the team that maintains our RMQ instances so I'm not the best to comment on it. Our dev-ops team have a complicated set of shovels and federation to deal with/minimize data loss, but I haven't had to delve into those scripts too much yet.
- StabbyCutyou 10y ago

eej71 10y ago

I think the author criticizes that view point in the final paragraph of fallacy #4. No?

nhumrich 10y ago
Not really. That section is about "simplicity". Microservices can be more complicated, but they shorten the feedback loop and reduce hand-offs.

fdim 10y ago

Until performance becomes a critical issue and then you have to deal with increased costs (hardware), caching, complexity... And if you happen to pair service with its own database (trustpilot), aggregating data for statistical reason becomes even more 'fun'.

blauditore 10y ago

I think it's touched in #2 and #4. The author argues that it becomes more complicated because each service needs to be understood thoroughly and mentions the "not-my-problem syndrome". While these issues are definitely there, the problem of understanding a subsystem also exists on large monolithic applications. The not-my-problem syndrome seems like an indicator of bad devs and/or company culture (I've seen this happen once) and might be mitigated by making people work on multiple microservices instead of completely separating them. In my opinion, separating a big project into multiple services emerges from the fact that most languages don't have built-in features for modularization on a large scale. In Java, for instance, there are methods < classes < packages. Once there are dozens of packages and thousands of classes, a project becomes hard to navigate and understand, especially when code isn't well-written with hacks disregarding modularizations. Using microservices reduces scope and prohibits some of these no-gos.

lmm 10y ago
> In Java, for instance, there are methods < classes < packages. Once there are dozens of packages and thousands of classes, a project becomes hard to navigate and understand, especially when code isn't well-written with hacks disregarding modularizations. Using microservices reduces scope and prohibits some of these no-gos. At that point you step up to using multiple maven modules. Which can give much the same development experience as microservices, but without the extra network boundary.
- blauditore 10y ago
  Yeah, that's one way to go, and also supports separate versioning and release cycles of different subsystems. However, since all code is compiled into one large application there are other problems arising. One I've seen often is sloppy dependency management: A explicitly depends on B, B on C. Now, a dev working in A starts using classes from C without declaring the dependency. Everything works because C is still included through B, but as soon as B gets removed, things start to break. There is mvn dependency:analyze to discover such issues, but it's not 100% exact, and people need to actively use it. I think such a system built into and enforced by a language would be another quantum leap.
  - lmm 10y ago
    It's very normal for methods in B to return types from C in that scenario though. And if you do remove the dependency on B, you get the error at compile time. So I don't see this as a major problem (it's maybe a problem if something's implicitly activated by reflection, but I see the reflection as the bigger problem there)
    - blauditore 10y ago
      When running into these runtime errors, it's sometimes not clear what module a missing class came from for complex setups, especially in a part of code you didn't recently work in. Then, the right version needs to be determined by following removed intermediate modules. It would just be cleaner and more reliable if the original dev had done this when writing the code in question. But yeah, at least it fails on compile time already.

djsumdog 10y ago

The author didn't discuss queues once. I work at a company that uses microservices and queues. Right now we use Rabbit, which is terrible for some reasons I won't get into, but the one good thing about it is that each message has to be acked. You take a message, you process it and then you make that you've processed it. Things don't get lost. You can requeue messages that end up being dead-lettered due to bugs. You can scale the number of services that read from that queue. You can have services up independently if they just read and write from a system that says, "here's a chunk of data to process." You can loose data with Rabbit, and if you're starting from the ground up you might want to look at something like Kafka instead. If you don't care about message loss and just need throughput (like if you're doing real time logs or sensor data), something like zeromq might be more appropriate. The idea behind microservices is that you gain stability at the expense of some redundancy.

UK-AL 10y ago
We use queues + microservices. It's a good combo. We also split the messages into different types, commands and events. A command is to perform a specific action and is normally aimed at a specific service. And event alerts any subscribed service that a action has happened. So you send a CreateOrder command. After processing it would fire off a CreatedOrder event which any subscribed service could pick up(Such as a EmailService sending a confirm email). Allows you to create workflows, and monitoring systems quite easily. I'm interested in your experience with RabbitMQ?
- deleted 10y ago
  [deleted]
- djsumdog 10y ago
  So you're using event sourcing then? We're doing the same thing using akka-persistence. I'm not directly on the team that maintains our RMQ instances so I'm not the best to comment on it. Our dev-ops team have a complicated set of shovels and federation to deal with/minimize data loss, but I haven't had to delve into those scripts too much yet.
StabbyCutyou 10y ago