Blog
My notes about the "Microservices Design and Patterns" lesson
Introducing Common Concerns
A few recurring themes
Affinity - The more information you 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 that are far away from each other generate latency. When we build global systems, we have to keep this in mind and figure out how to deploy those systems in a global way and how to operate them in a global way.
Failure - Failure happens, we have to deal with it as an explicit thing.
Criminals and the Careless - Security and safety are the two aspects that are really about protecting your systems from unwanted interactions.
The "Pets vs Cattle" mindset
=> Single machine systems vs cloud systems
=> Individual management vs Mass management
The pets approach is the old-school way: you have a few environments, or maybe a single one, and you know all about them. You know the names of your servers and a lot of other information, and when one of them has a problem, you make the effort to repair it.
The cattle approach is another attitude. You're no longer running one computer but 100 or maybe more, and if there's anything wrong with one of them, or with one instance, you will not repair it but simply turn it off and replace it with 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 grows and this extra work could be useless; if you scale down, you will have to deal with resource constraints. So it's really important to anticipate your future needs and scale your system correctly.
A "scale ramp" is a good practice. Grow 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 resiliently 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, 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 within 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
- Services are autonomous entities:
- The 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: this is very important, because the only way a service can be autonomous is by adhering to the contract it gives to others as an assurance. It means that even if the service changes, it has to continue to respect its contract. For example, a service can change its inside data, the data it stores and is responsible for, but not the data it exports, its outside data.
- A service has its own database, which can be decoupled but not shared.
Enabling Clusters
Clustering is about the ability to have multiple services on a machine, or multiple services on multiple machines, or a service on multiple machines with a load balancer. The constraint is that 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