Microservices Architecture Handbook: Non-Programmer’s Guide for Building Microservices

by Stephen Fleming

Problems of Monoliths Large-size monoliths are hard to maintain and evolve due to their complexity. Finding bugs requires long perusals through their code base. Monoliths also suffer from the “dependency hell,” in which adding or updating libraries results in inconsistent systems that either do not compile/run or, worse, misbehave. Any change in one module of a monolith requires rebooting the whole application. For large projects, restarting usually entails considerable downtimes, hindering the development, testing, and maintenance of the project. Deployment of monolithic applications is usually suboptimal due to conflicting requirements on the constituent models’ resources: some can be memory-intensive, others computational-intensive and others require ad hoc components (e.g. SQL-based, rather than graph-based databases). When choosing a deployment environment, the developer must compromise with a one-size-fits-all configuration, which is either expensive or suboptimal with respect to the individual modules. Monoliths limit scalability. The usual strategy for handling increments of inbound requests is to create new instances of the same application and to split the load amongst said instances. Moreover, it could be the increased traffic stresses only a subset of the modules, making the allocation of the newer resources for the other components inconvenient. Monoliths also represent a technology lock-in for developers, which are bound to use the same language and framework...

Problems of monolithic

A microservice has a database per service pattern, meaning that it has an independent database for every dependent or independent service.

Microservice DB

Testing Pyramid To illustrate testing microservices, we use the testing pyramid. The Testing pyramid showcases how a well-designed test strategy is structured. Testing Pyramid: - System Tests (Top) - Service Tests (Middle) - Unit Tests (Bottom)

Testing pyramid

In 2012, Adam Wiggins developed a set of principles known as a 12-factor app, which can be used to deploy microservices.

12 rules for microservices

A circuit breaker is a fault monitor component which is configured to each service in the application. The fault monitor then observes service failures, and when they reach a certain threshold, the circuit breaker stops any further requests to the services. This is essential in avoiding unnecessary resource consumption by requesting delay timeouts. It is also important in monitoring the whole system.

Circuit Breaker