Blog
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
-
Scalability
Scale to requirements => If you scale up, your workload growth and this add of work could be useless, if you scale down you will have to deal with resources constraints, so it's really important anticipate your future needs and scale correctly your system.
A "scale ramp", is a good practice. Growth your system with your audience. - Availability
Keep the system available as required for the solution
- Consistency
Provide a view of the information held by a system that is as consistent as needed to fulfill the solution requirements
- Reliability
Operate the system reliably and resilient against failures
- Predictability
Design to achieve predictable system performance
- Security
Identify and explicitly mitigate (or choose not to mitigate) security threats
- Agility
Design the system such that defects can be corrected and new capabilities introduced while meeting operational objectives
- Safety
Provide safety for data and systems by mitigating the risk of disasters impacting the existing environment(s)
- Supportability
Create systems to provide operational transparency for the needs of operations and support staff
- Cost
Do all of the above within a set budget and striving to continually reduce that cost
Defining Services and Microservices
- A "Service" is software that
- is responsible for holding, processing and/or distributing particular kinds of information withi the scope of a system
- can be built, deployed, and run independently, meeting defined operational objectives
- communicates with consumers and other services, presenting information using conventions and/or contract assurances
- protects itself against unwanted access, and its information against loss
- handles failure conditions such that failures cannot lead to information corruption
- A service consumer interacts with the service, it may be another service or a proxy to an entity in the physical world :
- User Interface
- Sensor
- Actor
- A system is a federation of services and systems, aiming to provide a composite solution for a well-defined scope
Designing Layers and Tiers
- Layers : Code Management
- Tiers : Runtime Management
- Services : Ownership Management
Creating Autonomous Layers
- Service are autonomous entities :
- Defining property of services is that they are autonomous
- Services shall have no shared state with others
- No sideline communications between services
- 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
- Autonomy enables operational agility
- Autonomy enables clustering
- Autonomy enables reusability and adaptability