Embed Size (px)
Citation preview
Let’s take the inspiration from biological cells before talking about Microservice:• They are small and single purpose• They are many of them but they work in
concert with one another• Each cell is able to respond to its
environment• They communicate with each other using
messages• They can replicate• They keep outside out• Death is natural and expected
Microservice architecture advocates creating a system
from a collection of small, isolated services, each of
which owns their data, and is independently isolated, scalable and resilient to
failure.
Divide and ConquerA divide and conquer algorithm works
by recursively breaking down a problem into two or more sub-problems of the same (or related) type (divide), until these become simple enough to be
solved directly (conquer). The solutions to the sub-problems are then combined
to give a solution to the original problem.
In Microservice Architecture we use
Divide and Conquer: the decomposition of the system
into discrete and isolated subsystems communicating over
well-defined protocols.
Microservice
Single Responsibility Replaceable Organized around business capabilities
Single Responsibility Principle
Single Responsibility Principle (SRP) states that a class or component should “only have one reason to
change.”
Do One Thing, and Do It Well
This is the Unix philosophy: Write programs that do one thing and do
it well. Write programs to work together.
—Doug McIlroy
“Micro” should refer to scope of responsibility.
A service has only one single reason to exist and should provide a single composable piece of functionality.
A service should do one thing and do it well.
Focus should be on business capability.
What about state?
Microservices are often stateful entities:
they encapsulate state and behavior.
ProductService
CustomerService
OrderService
PaymentService
SearchService
DB
This is still a monolith.
Oracle Couchbase Oracle
Customer Service
Customer Service
Customer Service
Customer Service
ProductService
ProductService
ProductService
ProductService
OrderService
OrderService
OrderService
Bounded Context Bounded Context Bounded Context
A microservice owns its data.
Business Capability Business Capability Business Capability
Decentralized Data Management
• Each microservice manages it’s own database: either different instances of same database technology or completely different database system (polyglot persistence)
• Eventual consistency
Microservices encapsulate state and behaviour.
Model each service as a Bounded Context.
Each service usually defines its own domain, each with its own Ubiquitous Language.
State(Data)
Behaviour(Business Rules) Business Capability
Search Service
Search Service
SearchCache Couchbas
e
ProductService
ProductService
ProductService
ProductService
Bounded Context
Bounded Context
Client
Business Capability Business Capability
IsolationIsolation is a prerequisite for resilience and elasticityEmbrace Share Nothing ArchitectureFailure Isolation (Bulkheading)Isolation between services makes it natural to adopt Continuous Delivery Isolation also makes it easier to scale each service, as well as allowing them to be monitored, debugged and tested independently Isolation is a prerequisite for autonomy
An autonomous service can only promise its own behaviour by publishing its protocol/API.
All information needed to resolve a conflict or to repair under failure scenarios are available within the service itself, removing the need for communication and coordination.
APIs need to be well-defined and composable.
Autonomous Service
Communicate through APIs
Service B
Couchbase
Service A
Oracle
APIinvoke expose
Contract
Shared understanding
API Client/Server Guidelines REST level-3 with HAL+json Use proper HTTP techniques Base design on application states and transitions
Forward compatibility over versioning Drive documentation from code Don’t write smart clients
Autonomy through Messaging
Service A(Pub)
Service B(Sub)
Service C(Sub)
Message Bus1 2 3
•Only publish business events and IDs – avoid mutable data• Implement proper error handling• Beware of added complexity
Message Publisher Guidelines
• Cater for duplicate message delivery through idempotency•Don’t rely on ordering• 1C late-commit pattern over 2PC• Implement proper error handling• Beware of added complexity
Message Receiver Guidelines
Microservice benefits
• Strong module boundaries• Independent
deployment• Technology diversity• Failure isolation• Improves time to market• Reduced cost of change
and costs
• Distribution• Eventual consistency• Operational complexity
General Microservice Architecture Principles
• Small and focused on a specific business capability• Eventual consistency • availability is more important than global and instant
consistency• Polyglot persistence• Pick most appropriate data and consistency model
• Async communication over sync• Failure resilient• Avoid SPOFs
Thank you
