"Microservices" is a bit of a buzzword - is it just a service that is micro/small? Should it always be used? The answer to both of these questions is no.

History of Microservices

The buzzword seems to have existed since the early 2000s, but Netflix seems to have pioneered the usage of microservices around 2008. They became popular due to their high scalability.

Definitions

Microservice

Wikipedia defines microservices as:

In software engineering, a microservice architecture is a variant of the service-oriented architecture structural style. It is an architectural pattern that arranges an application as a collection of loosely coupled, fine-grained services, communicating through lightweight protocols.

What's a bit odd is that there is almost no mention of consistency and messages- perhaps they wanted to keep implementations as abstract as possible. But I disagree with that. Some mention of them is required.

This talk is what I would consider as more accurate than the above definition. It's an hour long, but well worth watching.

A good definition from it, is that microservices:

  • are composed of small and loosely coupled services, which can be deployed independently
  • are services that communicate via messages on the back end
  • are owned by small and well contained teams.

Monolith

To put things in to perspective, the definition of a monolith is that it is built and deployed as one piece, eg changing one thing requires deployment of the whole piece.

Pros and Cons of Microservices vs a Monolith

Advantages of microservices

  • high availability
  • encourages writing loosely coupled code
  • encourages agile processes and teams that are experts in different parts of an application

Advantages of monoliths

  • typically has better data throughput (not necessarily performance) - eg time for an update from front end to back end
  • scalable eg via load balancing, adding more memory or cores, virtual/physical hardware changes, for databases could use data sharding
  • immediate consistency

Disadvantages of monolith

  • one piece is one tech stack - could be advantage too though
  • is not as agile a process as building a microservice
  • cannot have small teams focussed on one area

What Exactly is Monolithic? Either the Logic or Physical App

There are 4 combinations of the logic and the physical app, being either monolith is or distributed, and these are:

  • if code is modular, and app is physically distributed, it's a true microservice, which is good
  • if code is a monolith, and app is physically a monolith, it's a ball of mud monolith, which is bad
  • if code is modular, and app is physically a monolith, it's a modular monolith, which is good
  • if code is a monolith, and app is physically distributed, it's a distributed monolith

Note on the Distributed Monolith

  • always performs worse than monolith or microservices
  • more difficult to maintain
  • often has one database - which becomes a bottleneck with a lot of microservices hitting it

When You Should use Microservices

Only if you have a good reason, eg in the case when:

  • monoliths are bad or unscalable
  • microservices are hard to do well
  • Wrong reasons create distributed monoliths

Good reasons to create them:

  • more scalability
  • independent deployments
  • isolate surface area of failure

The trade off is that microservices have high availability, but low consistency. Monoliths have immediate consistency, but low availability.