Andy is a Web Services Architect at IBM. He contributes to Open Liberty, CXF, RESTEasy, MicroProfile, Jakarta REST, etc. and has spoken at conferences around the world.
I think it's overly simplistic to say that "monolith != modern" - there is certainly a case for monoliths in the cloud. It sounds like you already favor the monolith model, so I'll describe what I like about microservices - please understand that with most (all?) design decisions there are tradeoffs, and I would not advocate a one-size-fits-all approach.
Some of the shortfalls of monolith is the sheer amount of code and coders involved. Dependency management can be difficult, and there is no separation of concerns. You run the order processing service in the same CPU and memory space as the catalog service - so a bunch of customers with credit card in hand might end up waiting because of a slowdown in the catalog database. If those services are split out, then the two services are not using the same resources, and the transactions can proceed. Likewise, you could spin up or shut down instances of one service or another depending on traffic - but that leads to "unreliability" - a client service might have to handle the fact that the server instance it was communicating with is shut down, and now it must start communicating with a different instance. Most monoliths have this same "instability" - it's just handled at the IP sprayer rather than "inside" the application.
There's no doubt that microservices add more complexity, so the real question an organization must ask is, is it worth it? If you're building a site like Amazon or Spotify or many online banking apps, there are a lot of moving parts, so complexity is part of the system. I think microservices work well in these environments. For more dedicated systems, monoliths will make more sense. There is also the middle ground of macroservices that might make more sense.
Going back to the book, while we discuss the microservice architecture and the 12 factor application, it is not entirely about microservices. The APIs discussed in the book work just as well in a monolith. It discusses the latest in Java-based RESTful services, dependency injection, cloud-native config, fault tolerance (both within an app and for handling downed remote services), etc. It also covers how to deploy, debug and monitor applications in the cloud. All of this is useful regardless of your application architecture.
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.
Hi Sergiy - whew! there's a lot to discuss here!
I think it's overly simplistic to say that "monolith != modern" - there is certainly a case for monoliths in the cloud. It sounds like you already favor the monolith model, so I'll describe what I like about microservices - please understand that with most (all?) design decisions there are tradeoffs, and I would not advocate a one-size-fits-all approach.
Some of the shortfalls of monolith is the sheer amount of code and coders involved. Dependency management can be difficult, and there is no separation of concerns. You run the order processing service in the same CPU and memory space as the catalog service - so a bunch of customers with credit card in hand might end up waiting because of a slowdown in the catalog database. If those services are split out, then the two services are not using the same resources, and the transactions can proceed. Likewise, you could spin up or shut down instances of one service or another depending on traffic - but that leads to "unreliability" - a client service might have to handle the fact that the server instance it was communicating with is shut down, and now it must start communicating with a different instance. Most monoliths have this same "instability" - it's just handled at the IP sprayer rather than "inside" the application.
There's no doubt that microservices add more complexity, so the real question an organization must ask is, is it worth it? If you're building a site like Amazon or Spotify or many online banking apps, there are a lot of moving parts, so complexity is part of the system. I think microservices work well in these environments. For more dedicated systems, monoliths will make more sense. There is also the middle ground of macroservices that might make more sense.
Going back to the book, while we discuss the microservice architecture and the 12 factor application, it is not entirely about microservices. The APIs discussed in the book work just as well in a monolith. It discusses the latest in Java-based RESTful services, dependency injection, cloud-native config, fault tolerance (both within an app and for handling downed remote services), etc. It also covers how to deploy, debug and monitor applications in the cloud. All of this is useful regardless of your application architecture.
Thanks for the comment!
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.