There are two orthogonal concerns with microservices. First is the scaling aspect. A microservice architecture has many potential scale point as each independen

There are two orthogonal concerns with microservices. First is the scaling aspect. A microservice architecture has many potential scale point as each independent service can be horizontally scaled independently. Unfortunately, while achieving this is possible in a microservice architecture it's an enormous added layer of complexity today. The second aspect is, I think, more obviously compelling in that microservices force large scale modularity boundaries into your application. These are at some level entirely semantic boundaries, but the nature of microservice isolation forces them to be complete boundaries involving isolation, serialization, dirty checking, published APIs/interfaces, etc. This, I feel, is unambiguously fantastic. The trick is of course that this can be achieved in a "monolith" just the same. It's merely often not because people take advantage off too many features of monolithic development. Shared memory and shared effect space, guaranteed communication causing you to weaken interfaces, fast response time causing you to never be public about the interfaces to a particular submodule. These together lead toward spaghetti code and the interlocking danger of monolithic design. So, avoid them and make a monolith. Breaking it apart later will be easy if there are already logical cuts in your design. Don't rely on shared effects, shared state, or "hidden" API layers. You can use REST even within a single system.