Microservices

A single monolithic app does everything, some functions can be supplied by different apps that are loosely coupled through an integration pattern, like an enterprise service bus (ESB).

SOA began as an improvement to monolithic apps.
While SOA is, in most respects, simpler than a monolithic architecture, it carries a risk of cascading changes throughout the environment if component interactions are not clearly understood. This additional complexity reintroduces some of the problems SOA sought to remedy.

Microservices architectures are similar to SOA patterns in their use of specialized, loosely coupled services.
The services within the microservices architecture use a common messaging framework, like RESTful APIs. They use RESTful APIs to communicate with each other without difficult data conversion transactions or additional integration layers.
This lightweight architecture helps optimize distributed or cloud resources and supports dynamic scalability for individual services.

The following are some attributes that can describe a microservice.

Small size — smaller microservices are easier to work with.
Independence — each microservice should function independently from others.
Bounded context — each microservice is built around some business function and uses bounded context as a design pattern.
Network protocols — microservices interact with each other via network protocols such as HTTP and HTTPS.
Design-for-Failure principle — this provides the main advantage of microservices architecture: if one service fails, it doesn’t affect the entire system.
Automation — microservices should be deployed and updated automatically and independently from each other. Manual deployment and updating would be challenging because even the smallest project comprises from five to ten microservices, while large systems may comprise up to 500 microservices.