Microservice Architecture – modularity isn’t an option

Since there is no dependencies between microservices, and applications are designed to tolerate failure of services, it minimizes the risk of a small issue snowballing into large failure as is often the case in complex systems with lots of interdepencies.

Share this:

Modularity has been known for decades to be a key aspect of systems that are complex yet are still stable, robust, scalable, and maintainable. The human body, a very complex yet robust system after all, is made up of similar components (cells), each self-contained and specializing in a specific function. Modularization has been one of the most important best practices when building robust and scalable complex information systems. In the late 90’s, modularization led to the software architecture design pattern known Service Oriented Architecture (SOA), where services are unassociated, loosely coupled units of functionality that are self-contained. In the last few years, an information architecture with modularity as its core tenet has been spreading rapidly and gaining wide acceptance at some of the biggest technology companies, such as Netflix. That architecture is referred to as “Microservices.” A microservice architecture has the following key characteristics:

Componentization via Services: similarly to SOA, the architecture is componentized into services, which are able to communicate via a mechanism such as web services or remote procedure calls. These services should be independently deployable.

Organized around business capability. Services should be split up around a very specific business capability.

A microservice is a product, not a project. A development team should own a product over its full lifetime, inspired by Amazon’s “you build it, you run it” philosophy. A microservice, as a product, is implemented to fulfill or support an evolving business capability on an on-going basis, rather than as a set of functionality to be completed.

The architecture emphasizes simple communication pipes (“dumb pipes”) and smart end points. The two most common protocols are lightweight messaging and HTTP request-response using APIs. This contrasts with Enterprise Service Bus (ESB) architecture which usually involves, complex, “smart” pipes to route and transform messages.

Decentralized governance of technology platforms. Since we are splitting a monoliths component into services, there is a choice of how each will be built, and each microservice can each be implemented using the best platform suited to it.

Decentralized Data Management. Each microservice can manage its own database, with its own data model suited to its domain.

Design for failure. Since there is no dependencies between microservices, and applications are designed to tolerate failure of services, it minimizes the risk of a small issue snowballing into large failure as is often the case in complex systems with lots of interdepencies.