What I wrote is not about monolith vs microservices. It's about how an application designed for distributed deployment differs from something which is not designed, but used in a distributed environment.
Yes, I know that the main consideration behind microservices is the team separation. I completely understand the reasoning behind such a separation. I just don't think that microservices is the solution for this issue. In fact, most of the issues you've mentioned (dependency management and separation of concerns) were solved many years ago by OSGi. With some (small) efforts it even allows splitting teams, exactly like this is done with microservices.
Also, I think my post was too short to explain enough details about clustered solution. Perhaps this article will provide further information. So, most of your considerations against monolith don't applicable to this approach. First, there is no sharing CPU or other resources across all services. Each service instance works only at some cluster nodes (how many and where exactly is up to service manager component). In other words, nodes deployed with the same single artifact, but this does not mean that they are all running the same code. Some services run at some nodes, others at other nodes. And there are no "unreliability" or "instability" issues mentioned above. Moreover, it's rather easy to implement things in a way when there will be no difference, which exactly node was used to communicate with the system. Whole system runs as a single, big and exceptionally reliable computer. If you ever played with Docker swarm, then you should understand what I mean.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What I wrote is not about monolith vs microservices. It's about how an application designed for distributed deployment differs from something which is not designed, but used in a distributed environment.
Yes, I know that the main consideration behind microservices is the team separation. I completely understand the reasoning behind such a separation. I just don't think that microservices is the solution for this issue. In fact, most of the issues you've mentioned (dependency management and separation of concerns) were solved many years ago by OSGi. With some (small) efforts it even allows splitting teams, exactly like this is done with microservices.
Also, I think my post was too short to explain enough details about clustered solution. Perhaps this article will provide further information. So, most of your considerations against monolith don't applicable to this approach. First, there is no sharing CPU or other resources across all services. Each service instance works only at some cluster nodes (how many and where exactly is up to service manager component). In other words, nodes deployed with the same single artifact, but this does not mean that they are all running the same code. Some services run at some nodes, others at other nodes. And there are no "unreliability" or "instability" issues mentioned above. Moreover, it's rather easy to implement things in a way when there will be no difference, which exactly node was used to communicate with the system. Whole system runs as a single, big and exceptionally reliable computer. If you ever played with Docker swarm, then you should understand what I mean.