• Microservices are independently deployable services modeled around a business domain
  • Microservices are technology-agnostic
  • Microservices communicate with each other via networks – making them a form of distributed system. They also encapsulate data storage and retrieval, exposing data, via well-defined interfaces. So databases are hidden inside the service boundary
  • The GOAL of microservices is to have as small an interface as possible

Independent deployability

  • Independent deployability is the idea that we can make a change to a microservice and deploy it into a production environment without having to utilize any other services
  • Get into the habit of releasing changes to a single microservice into production without having to deploy anything else
  • To guarantee independent deployability, we need to ensure our services are loosely coupled – in other words, we need to be able to change one service without having to change anything else
  • This means we need explicit, well-defined, and stable contracts between services

Modeled around a business domain

  • We want to find ways of ensuring we make cross-service changes as infrequently as possible
  • If we want to make it easier to make changes, instead we need to change how we group code – we choose cohesion of business functionality, rather than technology

Owning their own data

  • Don’t share databases, unless you REALLY have to. And even then do everything you can to avoid it
  • We want to think of our services as end-to-end slices of business functionality, that where appropriate encapsulate the UI, application logic, and data storage. This is because we want to reduce the effort needed to change business-related functionality. The encapsulation of data and behavior in this way gives us HIGH cohesion of business functionality. By hiding the database that backs our service, we also ensure we reduce coupling

Microservices PROS

  • Independent nature of the deployments opens up new models for improving the scale and robustness of systems, and allows us to mix and match technology
  • As services can be worked on in parallel, we can bring on more devs to bear on a problem without them getting in each other’s way
  • Process isolation alao makes it possible for us to vary the technology choices we make, perhaps mixing different programming languages, programming styles, deployment platforms, databases, etc. to find the right mix
  • *Microservice architectures gives us FLEXIBILITY!

Microservices CONS

  • Communication between computers over networks is not instantaneous – this means we have to worry about latencies – and specifically, latencies that far outstrip the latencies we see with local, in-process operations
  • System behavior is unpredictable and networks sometimes fail
  • If your system grows in complexity, you will likely have to ditch transactions, and the safety they bring, in exchange for other sorts of techniques
  • You also need to work out how to get a consistent view of data across multiple machines
  • New tech that if used badly can help you make more mistakes much faster

User interfaces

  • If we want an architecture that makes it easier for us to more rapidly deploy new features, then leaving the UI as a monolithic blob can be a big mistake