Modules or microservices?

Microservices offer advantages but also come with associated costs. Modularizing applications without going the full microservices route is a viable alternative that is often overlooked. Sander Mak helps you ask the right questions in order to make good decisions for the right reasons.

Microservices promise a scalable architecture, increased flexibility, and better performance. But then you find out what’s actually involved in designing, developing, and running a microservices-based architecture. It turns out it’s not that straightforward after all. Often the discussion around microservices is framed by a false dichotomy between the messy monolith and the lean and mean microservices architecture. Sander Mak explains that there’s a third way: the modularized application. Functional decomposition of your application doesn’t imply that every component has to become its own independent process. Modularization is about strong encapsulation, well-defined interfaces, and explicit dependencies. Many languages offer in-process modularization features (for example, Java 9 with its upcoming module system), and there’s a strong overlap between the microservices philosophy and development benefits—without incurring the penalty of operational complexity. Sander explores the right (and wrong) reasons for going with a microservices architecture, as well as what a modularized application entails. You’ll see that splitting up an existing service or application into microservices isn’t always the clear winner. You’ll leave able to choose between the alternatives for the right reasons. There’s a place for both independently deployed microservices and larger applications with a strong internal modular structure. Choose wisely.