Microservices in a nutshell

 (or how to build a high performance distributed application / website that is easy to maintain)

Microservices at a high level is about splitting code horizontally based on context specific data models.  A single application could therefore consist of many services, each with its own business logic, data model and database.

There are drawbacks to creating Microservices.  The problem with popular patterns, is it's easy to consider them to be the right way to do things, but often the best approach is determined through experience, and considering what is really important for the specific context.  In many scenarios you will achieve better performance running code on a single computer, and you'll be able to develop it faster.  Nevertheless, for when it is a good approach, here are some advantages of splitting code into Microservices:

• All words in a model have a single meaning.  This avoids confusion and complexity which could come about from a large model.
• Less chance of code conflict: Development teams can focus on single services, without writing code that conflicts with teams working on other services.
• Services fail independently, rather than the entire system going down.
• Services can be written in different languages.
• A single service can be updated without affecting anything else.
• Enables continous delivery: services can be released independently when a feature is done, without waiting for a feature in another service.
• Easy to understand, as a small piece of functionality.  New developers do not need to understand the entire application.
• Scalability - easy to scale and integrate with 3rd parties.  Components can be spread across multiple servers.

Microservices can use event sourcing and CQRS to have optimized databases, so that any views which require extremely fast queries can have denormalized copies of the data, formatted specifically for their associated queries.

Event sourcing is done by placing messages in a queue.  Each queue is an action, like making a payment.  Services called consumers, will subscribe to the messages and perform the action, updating their associated database.  A well known example of event sourcing is most source control software, which record the changes, rather than the state.

Some benefits of event sourcing are:

• It provides a 100% reliable audit log of the changes made to a business entity.
• One can get the state of an entity at any point in time by replaying events.
• Communication between services without too much concern about a service being unavailable.

CQRS stands for Command Query Responsibility Segregation.  CQRS means that instead of CRUD, where the same entity is updated via the same interface, the command to update the entity can be applied to a different model to the query to retrieve the information.

Some benefits of CQRS include:

• One can create a view database (readonly) combining everything for a particular UI view.
• Supports multiple denormalized views that are scalable and performant.

Microservices can be deployed in containers.

Some benefits of containers:

• Platform independence: Build once, run anywhere.
• Much smaller than VMs.
• Effective isolation and resource sharing.
• Speed: Start, create, replicate or destroy containers in seconds.
• Smart scaling: where you only run the containers needed in real time.
• Simpler to update OS for all containers than multiple VMs.
• Free from issues associated to environmental inconsistencies.
• Roll-out & roll-back with zero downtime.