My notes about the "Microservices Design and Patterns" lesson

Introducing Common Concerns

A few recurring themes

Affinity - The more information your are managing within your system, the more your system will be dictated by the constraint of having so much data

Capacity - This is a constraint we have to deal with, even in a big system the capacity, the resources, are not limitless

Speed of light - Complex interactions between servers who are far away from each others generates latency. When we build global systems, we have to keep this in mind and gigure out how to go and deploy thoses systems in a global way and how to operate thoses systems in a global way

Failure - Failure happens, we have to deal with it has an explicit thing

Criminals and the Careless - The security and safety are the two aspects that are about really protecting your systems from unwanted interactions

the "Pets vs Cattle" mindset

=> Single machine systems vs cloud systems

=> Individual management vs Mass management

The pets is the old-school way : you have a few environments, or maybe a single-one, and you know all about them. You know the name of your servers, and a lots of others informations and when one of them has a problem, you do the effort to repair it.

The cattle is another attitude. You're no longer running one computer but you run 100 or maybe more and if there's anythinf wrong with one of them, or one instance, you will not repair it but simply turn it off and replace it by a new one. You will never care about the individual computer anymore.

Designing High-Scale systems

Distributed Systems Vocabulary

Operational Objectives

Defining Services and Microservices

- A "Service" is software that

- A service consumer interacts with the service, it may be another service or a proxy to an entity in the physical world :

- A system is a federation of services and systems, aiming to provide a composite solution for a well-defined scope

Designing Layers and Tiers

Creating Autonomous Layers

- Service are autonomous entities :

- An autonomous service owns its own uptime

- An autonomous service honors its contract : it's very important, because the only way how a service can be autonomous is by adhering to contract they given to others as an assurance. It means that even if the service change, he has to continue to respect his contract. For example, a service can change his inside data, the data he's store and he's responsible for, but not the data he exports, his outside data.

- A service has his own database, that can be decoupled but not shared

Enabling Clusters

Clustering is about the capacity of having multiple services on a machine, or multiple services on multiple machines, or a service on multiple machines with a load balancer. The constraint is the services can't have shared cross-service state, they have to be autonomous.

Azure Service Fabric can help.

Autonomous Services Benefits

May 31, 2017
  • Microservices Architecture
  • Software Architecture
  • Docker
  • Containerized Applications
  • Microsoft Virtual Academy (MVA)
  • Service Fabric
  • Azure Service Fabric
  • Clustering