SlideShare a Scribd company logo
The “Why”, “What” and “How”
of Microservices
Jeppe Cramon - @jeppec
Chief Architect - INPAY
WHY WOULD WE WANT TO USE
MICROSERVICES?
And what are the alternatives?
Cost of Software Development
• The 60/60 rule*
• The cost of software maintenance consumes 40%-80%
(60 % in average)
• Of this, 60% is consumed by enhancements
• And only 17% is consumed by error corrections
* "Frequently Forgotten Fundamental Facts about Software Engineering" by Robert L. Glass, IEEE Software May/June 2001
What are the sources of enhancements?
• New business requirements
• Changed processes (e.g. direct booking)
• Changed calculations (new pricing models)
• New features (space yield)
• New corporate strategies
• Ability to sell individual “components” of our application
• Management decisions to purchase 3rd party applications
• Upgrades/replacement to existing 3rd party systems
• Replacing existing functionality in our application with new components/systems (e.g. best
of breed or golf course deals)
ARCHITECTURE IS ESSENTIAL
Because it influences how fast we can respond to changes
and what the cost of those changes are
ULTIMATELY WE WANT TO BE
ABLE TO ADAPT TO CHANGES IN
A CONSTANT AMOUNT OF TIME
E.G. IF YOUR PRICING MODEL WAS
WRONG – YOU SHOULD BE ABLE
TO CHANGE IT IN HOURS/DAYS
AND REDEPLOY
SOME ORGANIZATIONS
CALCULATE CHANGE TIMES IN
MONTHS OR YEARS
WE ALL WANT TO MOVE FAST
But can’t always move fast -
for various reasons…
WHAT IS THE MAIN TECHNICAL,
BUSINESS AND ARCHITECTURAL
IMPEDIMENT TO OBTAINING HIGH
VELOCITY?
High Coupling
• Coupling is a measure of dependencies:
• Efferent coupling – who do you depend on
• Afferent coupling – who depends on you
• 4 different aspects on coupling:
• Temporal coupling (processing time of Y affects X – if Y is down can X continue?)
• Platform coupling (e.g. using platform specific protocols)
• Spatial coupling (where on the network are the Y instances and how does X know?)
• Behavioral coupling (how much about Y’s behavior does X understand)
X Y
Coupling
Coupling is a challenge when you want to makes changes
The playing field
Zero coupling The Enterprise Canonical model
Coupling causes ripple effect –
much like circles in the water
• You want to change a little thing and all of a sudden you need to change 25
other seemingly unrelated things
• Zero coupling is impossible
• Question is what is the right level of coupling?
• This highly depends on how likely the component/system/service is it to change and
what parts that change together
It starts simple
“The” DB
UI
Logic
Data Access
Next step is spaghetti in layers
And often we end up with a
Big Ball Of Mud
ALTERNATIVE 1
A monolith
AS AN UMBRELLA NAME WE CALL
THESE SYSTEMS MONOLITHS
Which roughly translates to mean that they deployed as one
unit
Characteristics of a monolith?
• Often an indivisible unit
• Hard to adapt to new technology
• Low Reusability
• Functionality of a part cannot be reused alone
• Slow Delivery train
• Introducing a new feature often requires coordination with other features to
deliver all of them at the same time
• Higher and higher maintenance cost over time
• Change to control flow is often hard
• Starting the application often takes a long time
• Testing the application often takes a long time
• Forces high requirements on mental capacity to keep the entire
monolith in your head
• Tends to grow bigger and bigger and bigger
• Reliability
• When one thing fails => potentially everything fails (e.g. due to
OutOfMemoryException)
MONOLITHS ARE UNFAIRLY
CATEGORIZED AS BEING BAD
Many of the problems mentioned before can be solved using
design principles that we will investigate in this talk
Advantages of Monolith
• Can take advantage of locality:
• In memory calls and avoid distributed transactions
• Can perform Joins with other components SQL tables
• Can take advantage of development IDE’s
• Refactoring
• Code completion
• Code searching
• Less spinning wheels
• Less deployment and monitoring requirements
WHAT OTHER ALTERNATIVES
EXISTS?
SOA?
FIRST QUESTIONS IS
What is SOA?
To many this is SOA
Data
Storage
Data
Storage
Data
Storage
Data
Service
Data
Service
Data
Service
Activity
Service
Activity
Service
Process
Service
Process
Service
Client Client
Client
Data
Service
If one service is
down, you risk
everything is down
Classic Service reuse multiplies our direct
and especially indirect dependencies
which creates high coupling
My new
Service that
wants to reuse
other services
Service that is
going to be
reused
Another
Service that is
going to be
reused
Reusable
Service
Reusable
Service
Reusable
Service
Reusable
Service
Reusable
Service
DB
service
The cost/benefit of reuse
• Layered SOA has typically been recommended because it increases reuse
• Really, this is use and not reuse.
• Use results in more coupling
• The thesis is that the more we reuse, the faster we will be done
• But the thesis rest on the false assumption that writing code is the most expensive
part of a project
• Not all code takes the same amount of time to write. Some code is very trivial while other
code is very hard to write
• The real money and time consumers on any project are:
• Figuring out what the customer needs
• The time it takes for the customer to figure what they really needed and the resulting rework
• Meetings
• UI, Integration work, databases, webservices
• Fix bugs
• Debugging
• Deployment
• Test
• Ship
Yes
No
Failed
?
The more
dependencies we have,
the worse this is and
the more expensive it
becomes
Where to go?
• Monoliths easily result in:
• Tight coupling
• Slow release train - All or nothing deployment
• Low reusability
• Reliability issues
• SOA done traditionally easily result in:
• A hard coupled architecture due to reusability and integration
patterns
• Both runtime (temporally) and design time (contracts)
• Performance issues
• Reliability issues
• Slow release train – requires a lot of governance
• High latency (2 way remote communication)
• High accidental complexity
• Compensations due to lack of transactions
• ESB’s to try and hide the mess
ARE MICROSERVICES THE
SOLUTION?
Next question: What are Microservices?
SOME SAY A MICROSERVICE IS THE
SAME AS A SOA SERVICE – JUST
SMALLER
That of course requires us to answer what a Service is ;-)
THE FINE-GRAINED, STATELESS, SELF- CONTAINED
NATURE OF MICROSERVICES CREATES DECOUPLING
BETWEEN DIFFERENT PARTS OF A CODE BASE AND IS
WHAT MAKES THEM
EASY TO UPDATE, REPLACE, REMOVE, OR AUGMENT.
Microservices: The resurgence of SOA principles and an
alternative to the monolith
IT SEEMS THE ARGUMENT IS THAT
JUST BY MAKING THINGS FINE
GRAINED
We by magic achieve decoupling
Let’s transform our monolith to microservices
“The” DB
UI
Logic
Microservices
Data Access
Microservices
UI-3
MS-3
MS-C
UI-2
MS-D
UI-4
MS-4MS-2
MS-B MS-E
UI-1 UI-5
MS-5MS-1
MS-A
THERE IS VALUE IN MAKING
THINGS SMALLER
For one thing it is easier to reason about them in isolation
Going small has its advantages
Monolith
Microservice Microservice
Microservice MicroserviceMicroservice
Microservice
Microservice
HOW SMALL SHOULD A
MICROSERVICE BE?
BUT I’VE HEARD THAT A
“MICROSERVICE SHOULD BE NO
LARGER THAN 100 LINES OF CODE!?”
SIZE THIS AND SIZE THAT!
BE CAREFUL
If Microservices are good, then Nanoservices must be even
better?
Why not one-liner services?
AKA SERVERLESS
39
https://www.linkedin.com/pulse/how-i-decided-use-serverlessnanoservices-architecture-benefield
AKA SERVERLESS
40
https://www.linkedin.com/pulse/how-i-decided-use-serverlessnanoservices-architecture-benefield
Nano Services
Unless we have a very good reason for doing so,
we risk building services
that are so fine-grained
that their costs outweigh their utility*
*Read Arnon Rotem-Gal-Oz’s Nano Services Anti Pattern:http://arnon.me/wp-content/uploads/2010/10/Nanoservices.pdf
IS YOUR MICROSERVICE
VALUABLE?
The value of a microservice must
exceed the cost of building &
operating it.
Microservices entail costs for serializations, deserializations,
security, communication, maintenance, configuration,
deployment, monitoring, etc.
FOR NOW ON WE WILL USE
SERVICE AND MICROSERVICE
INTERCHANGEABLY
A Service CAN be broken into smaller parts, but let’s leave
that out of the discussion for now…
Too small services
With too small services there’s a big risk that what’s left of coherence goes
out the window and we get:
• Communication-related and Layered coupling
• E.g. Logic and persistence are not the same service
• Temporal coupling
• Our service can not operate if it is unable to communicate with the services it depends upon
• Behavioral coupling
• Our services assume behaviors with regards to what and who.
• The sender/client determines what to do and knows something about how the receiver/server
should satisfy the request
Service Dependencies
Source: https://www.infoq.com/presentations/netflix-ipc
Microservices == distributed objects?
Service star chart
Microservice characteristics
• Small
• Single Responsibility Principle (SRP)
• Own process
• Valuable
• Replaceable/Upgradeable
• Autonomous
• Independent
• Encapsulated
• Composable
• Testable
• Fast startup/shutdown
• Client friendly
SRP
This sounds really good but what about cross
Service relationships?
Customer Orders
Products
BEWARE…
When we break up big things into small
pieces we invariably push the complexity to
their interaction.
Michael Feathers
https://michaelfeathers.silvrback.com/microservices-until-macro-complexity
Let’s zoom in on the data tier
MS-A
“The” DB
MS-C
MS-D
MS-B
MS-E
IF OUR MONOLITHS CODE IS COUPLED AND MESSY
Chances are that the data(base) model is equally coupled
and messy
We start with a simple model
And as time goes by…
It gets more and more complicated
And finally we drown
AND WE END UP WITH
ONE DOMAIN MODEL TO RULE THEM ALL
THE MENTAL CAPACITY REQUIRED TO
UNDERSTAND THIS DOMAIN MODEL
IS HUGE
TO UNDERSTAND ANY PART IN
ISOLATION, REQUIRES YOU TO
UNDERSTAND THE ENTIRE MODEL AS
EVERYTHING IS COUPLED TO EACH
OTHER
Side effect: Our queries get messy
Let’s refactor the data tier
UI
Logic
Microservices
Data Access
Microservices
UI-3
MS-3
MS-C
UI-2
MS-D
UI-4
MS-4MS-2
MS-B MS-E
UI-1 UI-5
MS-5MS-1
MS-A
A’s
DB
B’s
DB
C’s
DB
D’s
DB
E’s
DB
MS-C
MS-D
MS-B
MS-E
MS-A A’s
DB
B’s
DB
C’s
DB
D’s
DB
E’s
DB
THIS IS ALSO KNOWN AS A
DISTRIBUTED MONOLITH
Things that are not Services
• A Service with only functionality (and no data) is a FUNCTION
• Like: check if order is valid
• A Service that only has data is a DATABASE
• Like: Entity CRUD
• A database already has a nice API - we don’t need to bubble wrap it with REST or Asynchronous messages
• Don’t split the atom – we need cohesion as well as decoupling!
• If we want datastore abstraction (so we can swap out Postgresql with Mongo or Redis) there this little
pattern called Respository.
This is typically seen in a lot of layered SOA usages where a function calls a
function that calls a function that calls a database
4 tenets of Service Orientation
1. Services share contract and schema, not class or type
• Encapsulation improved. We need not worry about how things are implemented
(languages or platform dependent information)
2. Service interaction is controlled by a policy
• Controls the rules/form of technical communication between services take place (e.g.
using encryption incl. algorithm and keys)
3. Services have explicit boundaries
• A Service is defined by its Boundary
• What is on the inside and which is on the outside ownership wise (data and logic)
• A boundary tells us what parts make up the service and how the service interacts with
the outside world (as defined by the service contract – see point 1 and 2).
• The internal implementation and platform of a Service (what’s inside the boundary) is
irrelevant
4. Services are autonomous
• Encapsulation & Cohesion at a bigger scale.
• A service is autonomous if it doesn’t rely on other services to complete its job
• A service can be rewritten, redeployed and replaced without interfering with other
services as long as schema/contracts are upheld
This is different from Functions & Components
• Functions are very intimately linked with code that uses them
• Components form a higher modularization level than functions
• But they’re still intimate with the application they’re added to
• Services are yet another modularization level than components.
• They’re standalone, own their own data and are loosely coupled to their surroundings
Let’s refactor the “microservices”
UI
Microservices
UI-3
MS-3
UI-2 UI-4
MS-4MS-2
UI-1 UI-5
MS-5MS-1
1’s
DB
2’s
DB
3’s
DB
4’s
DB
5’s
DB
Reality rears it’s ugly head out
WHAT’S WRONG WITH USING
RPC/REST/… BETWEEN
SERVICES?
Synchronous calls lower our tolerance for faults
• When you get an IO error
• When servers crash or restarts
• When databases are down
• When deadlocks occurs in our databases
• Do you retry?
With synchronous style Service interaction we can loose business data, there’s no automatic retry or we risk creating
data more than once because idempotence* often is an after though
68
Client Server
Duplicated
Response
Duplicated Request
Processing
Response
Request Processing
The same message can be
processed more than once
*Idempotence describes the quality of an
operation in which result and state does not
change if the operation is performed more
than 1 time
Also remember: REST isn’t magic!
SOA PRINCIPLE
SERVICES ARE AUTONOMOUS
Autonomy means that our service is independent and self-
contained and as far as possible doesn’t directly depend on
other services to be functional.
Service autonomy
Component
B
Component
C
Component
A
System X
Service
A
Component
B
Component
C
System X
Slow/unreliable network
Different SLA
Slow system
SERVICES ARE AUTONOMOUS
For a service to be autonomous is MUST own its data
Shipping
DB
SERVICES ARE AUTONOMOUS
For a service to be autonomous is must NOT share state
SERVICES ARE AUTONOMOUS
Autonomy is essential for
Scalability (scale out clustering)
Reliability (fail over clustering)
SERVICES ARE AUTONOMOUS
Autonomy is essential for
Reusability
Adaptability
Clarification of Autonomy vs. Authority
Definition of Autonomy
A service is autonomous if it doesn’t directly depend on another application to
complete its work. It can determine on its own what to do.
Definition of Authority
A service is the authority if other services needs to ask it for data or instruct it to
perform a task on their behalf for them to complete their job
Autonomy
Authority
IF WE KEEP UP THE SAME HABITS
THAT RESULTED IN MESSY
MONOLITHS
We will end up with microservice spaghetti!
Monolith A Monolith B
Monolith C Monolith D
Service
A.1
Service
A.2
Service
A.3
Service
A.4
Service
B.1
Service
B.2
Service
B.3
Service
B.4
Service
D.1
Service
D.4
Service
D.3
Service
D.2
Service
C.4
Service
C.3
Service
C.2
Service
C.1
DB DB
DB DB
Service transformation
Service
A.1
Service
A.2
Service
A.3
Service
A.4
Service
B.1
Service
B.2
Service
B.3
Service
B.4
Service
D.1
Service
D.4
Service
D.3
Service
D.2
Service
C.4
Service
C.3
Service
C.2
Service
C.1
DB
DB
DBDB
DB
DB DB DB
DBDBDB
DB
DB DB
DB
DB
DB DB
DB DB
Service transformation
IF WE CONTINUE DOWN
THIS PATH WE HAVE GONE
FROM BAD TO WORSE
THIS MEANS THAT WE NEED TO TAKE
CARE OF HOW WE DESIGN OUR DATA
MODELS & THEREBY OUR SERVICE
BOUNDARIES
GUIDANCE CAN BE FOUND IN
Pat Hellands
“Life Beyond Distributed Transactions? An Apostate ‘s Opinion”
Link: http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf
Life Beyond Distributed Transactions?
According to Pat Helland, we must find the solution to our problem by looking
at:
1. How do we split our data / services
2. How do we identify our data
3. How do we communicate between our services
1. How do we split our data / services
Data must be collected in pieces called aggregates. These aggregates should
be limited in size (but not smaller), so that, after a transaction they are
consistent.
Rule of thumb:
One transaction involves only one aggregate.
DOMAIN DRIVEN DESIGN
The term Aggregate comes from DDD
Aggregates
Invoice
InvoiceLine
*
Account *
What:
• Cluster coherent Entities and Value Objects,
with complex associations into Aggregates
with well defined boundaries.
• Choose one entity to be root and control
access to objects inside the boundary
through the root.
• External objects hold references to the root
• Aggregates only refer to other aggregates
by identity (their id)
Motivation:
Control invariants and consistency through the aggregate root.
Enables: Loading schemes, coarse grained locking and…
Ensuring consistency & transactional boundaries for Distributed
scenarios
Root
*
*
THE SMALLEST SERVICE
Would be responsible for all logic and data related to a single
Aggregate
WHY?
Because consistency can only be guaranteed with in an Aggregate
It cannot span aggregates due to lack of coordinating transactions
Example of bad aggregate boundaries
In this case we can fix it
All use cases shows that
LegalEntity and Address
are created, changed
and deleted together
Parent - Child
An improved aggregate design
Address
turned out to
NOT be an
Entity
LegalEntity is an Entity
and forms the Root of our
LegalEntity aggregate
THIS GIVES US THIS RULE OF
THUMB
1 use case = 1 transaction = 1 aggregate
With this improved design
“Client” that wants
to use our
LegalEntity
Service
LegalEntity Service
2. How do we identify our data
According to Pat Helland we need to be able to uniquely identify each
Aggregate using an ID.
• This ID will usually a UUID/GUID
• Aggregates refer to each other by their ID
• they NEVER use memory pointers, join tables or remote calls
{21EC2020-3AEA-4069-A2DD-08002B30309D}
2122 (approximately 5.3×1036) combinations
WE STILL HAVEN’T CONQUERED
THE TEMPORAL COUPLING
PROBLEM
3. How we communicate between our services
• What do we do when our use case involves more than one aggregate and
therefore likely more than one service?
WITH CROSS SERVICE INTEGRATION
WE’RE BOUND BY THE LAWS OF
DISTRIBUTED COMPUTING
The 8 Fallacies of Distributed Computing
These fallacies are assumptions architects, designers and developers of
distributed systems are likely to make. The fallacies will be proven
wrong in the long run - resulting in all sorts of troubles and pains for
the solution and architects who made the assumptions.
1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn't change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogeneous.
See http://www.rgoarchitects.com/Files/fallacies.pdf for a walkthrough of the fallacies and why they’re fallacies
A DISTRIBUTED SYSTEM IS ONE
WHERE A MACHINE I’VE NEVER
HEARD OF CAN CAUSE MY PROGRAM
TO FAIL.
— Leslie Lamport
2 WAY (SYNCHRONOUS) COMMUNICATION IS THE
ROOT OF MANY PROBLEMS BECAUSE IT CREATES A
STRONG TEMPORAL COUPLING
(AS WELL AS BEHAVIORAL COUPLING)
Substituting synchronous with synchronous-
over-asynchronous doesn’t solve the core
problem
Change Address Response
Consumer
Change Address Request
Provider
RPC or Request/Response - Synchronous 2 way communication
Remote Procedure Call
Request/Reply – Asynchronous 2 way communication
Consumer Provider
Change Address Request
Change Address
Request
Change Address
Reply
Change Address
Reply
Request
Channel
Reply
Channel
VS.
THE PROBLEM ISN’T SO MUCH SYNCHRONOUS VS
ASYNCHRONOUS
The question is it two-way or one-way communication and what’s the use
case (e.g. is there a user sitting and waiting)
Essential complexity of 2 way integration
Component
C
Compnent
B
Component
A
UI
Service Service
B:Service()
call C:Service()
call A:Service()
commit()
Service
Local transaction between
System A, B and C
Accidental complexity from 2 way style integration
Component
C
Component
B
System A
UI
Service Service Service
Local transaction
between System B and C
B:Service()
call C:Service()
call A:Service()
if (A:Call-Failed:Too-Busy?)
Wait-A-While()
call A:Service()
if (A:Call-Failed:Too-Busy?)
Wait-A-Little-While-Longer()
call A:Service()
if (A:Call-Failed:IO-Error?)
Save-We-Need-Check-If-Call-A-Succeded-After-All
AND We-Need-To-Retry call C:Service and call B:Service
AND Tell-Customer-That-This-Operation-Perhaps-Went-Well
if (A:Call-Went-Well?)
commit()
HOW CAN WE ENSURE CONSISTENCY
WHEN WE’RE GOING DISTRIBUTED?
Can’t we just use distributed transactions?
(XA / 2 phase commit)
Distributed Transactions…. Oh my
Sales system
Sales Delivery
system Deliveries
Customer/C
RM system Customer
SAP
Book-
keeping
Complete
Purchase
Transaction
Coordinator Transactional
Resource
Prepare
Phase
Commit
Phase
2 Phase Commit
What’s wrong with distributed transactions?
• Transactions lock resources while active
• Services are autonomous
• Can’t be expected to finish within a certain time interval
• Locking keeps other transactions from completing their job
• Locking doesn’t scale
• And what about timeouts?
• X Phase Commit is fragile by design
THIS IS
ACCIDENTAL COMPLEXITY
DUE TO DISTRIBUTION
We’re essential handling the problem the worst possible way
THIS FORM OF COORDINATED
INTEGRATION BETWEEN
MULTIPLE SERVICES IS KNOWN
AS ORCHESTRATION
Consequence: Availability goes down
(without additional instances of each service)
Service
A
Service
B
Service
C
Availability: 99% Availability: 99% Availability: 99%
Combined availability: 97%
Synchronous calls are the crystal meth of programming
At first you make good progress but then the sheer horror
becomes evident when you realise the scalability
limitations and how the brittleness holds back both
performance and development flexibility. By then it is too
late to save.
http://www.infoq.com/news/2014/10/thompson-reactive-manifesto-2
We need the reactive properties and then apply
protocols for the message interactions. Without
considering the protocols of interaction this world
of micro-services will become a coordination
nightmare.
Martin Thompson
DECIDE IF YOU CAN LIVE WITH THE
CONSEQUENCES OF COUPLING
SERVICES TO EACH OTHER USING
REQUEST/RESPONSE
Different situations – different tradeoffs
HOW TO GET LOOSE COUPLING
BETWEEN SERVICES?
It highly depends on how you integrate them
Degrees of coupling
UI
UI
Service
ServiceData
Data Events
Events
IF WE WANT TO DECOUPLE OUR SERVICES AS MUCH
AS POSSIBLE
THEN WE NEED TO LOOK TOWARDS
COMPOSITE UI’S
AND
EVENTS
WHAT’S A COMPOSITE UI
A Composite UI is a way to allow different services to
participate an applications UI without revealing their
internals and thereby removing the need for other
services to know the this services internal data
This helps us keep coupling low and encapsulation high
Applications
• Applications are tailored solutions for certain groups of users.
Example
• Departments will typically have UI’s tailed to the responsibility of a department (which
often cut across Service responsibilities)
• Managers which see different reports from all areas of a company
• Sales representatives which have solutions that sometimes can work in offline mode
• Customers using e.g. Android/iOS apps to access their portfolio / home-banking /
appointments / etc.
Applications and Services
iOS Homebanking Call center support portal
Bank Backoffice application
Customer information service
Legal and contract information service
Accounts service
Credit card service
Mortgage loans service
Who owns the UI?
• For a service to be fully autonomous
is must be self contained – which
means it must:
• Own its UI
• Own its Business Logic
• Own its Data model & storage
User interface
Business Logic
Data model &
storage
Service
A similar approach is available under the name Self Contained Systems http://scs-architecture.org/
If a Service doesn’t own its UI we often find the need for
a Gateway or Backend For a Frontend (BFF)
• Experience shows if you get
your Service API wrong the
first time around, it is really
expensive to fix it*
• The granularity of APIs
provided by microservices is
often different than what a
client needs*
* See http://thenewstack.io/microservices-calls-robust-api-management-tools/
Gateway or Backend For a Frontend (BFF)
• Unfortunately Gateways & BFF’s
introduce a lot of coupling
between the Gateway and the
underlying services
• If an underlying service changes
its contract in a non-backwards
compatible way the gateway
needs to change
• In these cases the clients of the
gateway may also need to change
since the changes can permeate
upwards (the gateway abstraction is
leaky)
* See http://thenewstack.io/microservices-calls-robust-api-management-tools/
Gateway/BFFGateway/BFF
GATEWAY OR
BACKEND FOR A FRONTEND
UI
Microservices
UI-3
MS-3
UI-2 UI-4
MS-4MS-2
UI-1 UI-5
MS-5MS-1
1’s
DB
2’s
DB
3’s
DB
4’s
DB
5’s
DB
Gateway/BFF
Application UI’s
• An applications is a composition of different services
• The composition can be:
• Resource Oriented Client Architecture (ROCA) style service
integration (http://roca-style.org/)
• Mashup of Service UI components in a dedicated Application –
aka. Composite UI
Both solutions involve
integration via Services
web interfaces to minimize
coupling to other services.
Image from http://scs-architecture.org/
ROCA style integration
Simple hyperlinks can be used to navigate between services
UI’s.
Image from http://scs-architecture.org/
ROCA style integration
A redirection can be used to ensure
navigation works in both directions.
Image from http://scs-architecture.org/
ROCA style integration
Hyperlinks can also support the
dynamic inclusion of content that is served by another
application into the web interface of a service.
Image from http://scs-architecture.org/
Composite UI - example Page Context:
{ type: Book, id: ISBN-10 0-321-83457-7 }
ImageService
BookService
ReviewService
PriceService
InventoryService
OthersAlsoBoughtService
PriceService
ReviewService
BookService
ImageService
BookService
A SERVICE OWNS IT UI IN ALL
CONTEXTS AND FOR ALL COMPOSITE
UI’S
Not just for HTML clients
Invoice Composite UI example
InvoiceHeader
Order:ShippingI
nfo
Invoice:
InvoiceNumber
Invoice:
Data and Due
date
Order:
RelationInformation
Order:Item-
Qty
Product:Ite
m
Product:
Description
Order:
Item-Unit-Price
Order:
Item-
Total-
Price
Order:Total
Billing:Balance
All Services
participate at
the UI level for
each individual
Item in the
Order
Coupling matrix*
* Modified version of Ian Robinson’s matrix: http://iansrobinson.com/2009/04/27/temporal-and-behavioural-coupling/
Behavioral
coupling
Temporal
coupling
Low High
Low
High
Event oriented Command oriented
Emergency services Distributed 3 layer
TO BREAK TEMPORAL COUPLING &
BEHAVIORAL COUPLING
SERVICES NEEDS TO COMMUNICATE
ASYNCHROUSLY USING BUSINESS EVENTS
MESSAGES
Services communicate facts without making
assumptions about what other services intend
to do with the events
Let’s make the implicit explicit!
Old wisdom seems to have been forgotten. Let’s introduce:
Domain Events
Which:
• Signal that something has happened
• Closely aligned to the Domain Model
• Are handled by a messaging system
• They are in the past tense:
• CustomerBilled
• ParcelShipped
• CustomerCreated
• ReviewCreated
• CommentAdded
• CommentDeleted
Event Message
An Event message is non-prescriptive of what should happen in other services. It leaves this open to
the recipients, so that they themselves determine what to do based on occurrence of the event.
Events always carry a name in its past-tense form: OrderWasAccepted, OrderHasShipped,
CustomerWasReimbursed
Other qualities
• Immutable, i.e. content cannot be changed
• Always carries the ID of the Aggregate it relates to
• An event can and will typically will be published to multiple consumers.
• The publisher of the event does not know who the recipients are
• And it doesn’t know what the recipients intend to do with the event
• The service issuing the Event is the owner of the Event contract
“An Event describes something that HAS
happened”
Business Event as XML Message
<OrderWasAccepted>
<CustomerId>50D1F244-ABBC-4EC7-BDCA-E4934C124A89</CustomerId>
<OrderId>C199322A-01F1-4E56-918E-7A63529F8FA3</OrderId>
<ShippingAddress> ... </ShippingAddress>
<BillingAddress> ... </BillingAddress>
<Items>
<Item ProductId="4CD22C4B-600C-4477-B5BF-48ABDEE4DA61" Amount="100"
AmountUnit="Pieces" UnitPrice="100,10" UnitCurrency="EUR"/>
<Item ProductId="56E6BD19-660C-464A-9120-100DAF579855" Amount="10"
AmountUnit="Litres" UnitPrice="56,95" UnitCurrency="CHF"/>
</Items>
</OrderWasAccepted>
Business Event as JSON Message
{
EventType: "OrderWasAccepted",
CustomerId: "50D1F244-ABBC-4EC7-BDCA-E4934C124A89",
OrderId: "C199322A-01F1-4E56-918E-7A63529F8FA3",
ShippingAddress: { ... }
BillingAddress: { ... }
Items: [
{
ProductId: "4CD22C4B-600C-4477-B5BF-48ABDEE4DA61",
Amount: "100",
AmountUnit: "Pieces",
UnitPrice: "100,10",
UnitCurrency: "EUR"
},
{
ProductId: "56E6BD19-660C-464A-9120-100DAF579855",
Amount: "10",
AmountUnit: "Litres",
UnitPrice: "56,95",
UnitCurrency: "CHF"
}
]
}
Events are often the side effect of Commands
A Command message is prescriptive of what should happen. This is a stronger form of coupling than Events.
A Command’s primary goal is to capture USER INTENT
A Command supports a single usecase and targets a single Aggregate
Commands always carry a name in its imperative form: CreateOrder, ShipOrder, CancelOrder, ReimburseCustomer, etc.
Other qualities
• Immutable, i.e. content cannot be changed
• Always carries the ID of the Business Object that it relates to
• A command can only be handled by ONE service
• The Operations that consume Commands don’t return values – but can throw exceptions
• Therefore Commands should be handled using 2 way communication, so the exception can be communicated back to the sender
“A command describes a Task that you want someone else to
carry out for you and the recipient can reject the Command”
Commands & Events
Commands mutate Aggregate/Business Object state which results in one or
more Events being published
Command Event(s)
AcceptOrder OrderAccepted
ShipOrder OrderShipped
AddComment CommentAdded
QuarantineReview ReviewQuarantined
UnquarantineReview ReviewUnquarantined
EVENT MESSAGES SHOULD BE
SEND USING
One way communication
One way Messaging
• One way messaging is asynchronous and breaks
temporal coupling
• Messages can be exchanged between services over a
message channel
• The Message channel is responsible for delivering the
message(s) to the relevant parties (consumers). If
something goes wrong, the message will be put back on
the Message channel (rollback) and will be resent later*
Sender
Address Changed
Event
Receiver
Address Changed Event
Channel
Asynchronous Communication – Aka Messaging
* This is smart pipes and “dumb” endpoints – An alternative is dumb pipes and smart endpoints
SPLITTING INTO SMALLER AND MORE
FOCUSED SERVICES HAS MANY
ADVANTAGES
But it leaves us with the challenge on what
to do when processes span multiple
services
THE CHANGE OF FOCUS FROM
TECHNICAL SHORT TRANSACTIONS
To long running business transactions
BUSINESS EVENTS MESSAGES
AND BUSINESS PROCESSES
By publishing Events messages from our Services
we can communicate with each other and also
drive Business Processes
143
This form of architecture is called an
Event Driven Architecture (EDA)
SOA AND EDA ARE TWO SIDES OF
THE SAME COIN
Using Business Events to drive Business Processes
Sales Service
Shipping
Billing
Sales
Customers
MessageChannel
Online Ordering System
Web Shop
(Composite UI)
Billing Service
Shipping Service
Order
Accepted
Event
AcceptOrder
Command
The sales
fulfillment
processing
can now
begin…
Business Events example
Sales Service
Order
Accepted
Billing Service
Online Ordering System
Order
Accepted
Customer
Billed
MessageChannel
We use the Order Accepted event message published from the Sales Service
to drive the Billing of the customer.
The billing part of the process also use Business Events, in this case Customer Billed
Event, to indicate that its part of the process is completed.
Because we use asynchronous messaging we can still accept orders in the sales service
even though the invoicing services is down. The Order Accepted event message will
remain in the Message Channel until the Billing Service is ready to process it.
What about race conditions?
• Usually they are a natural part of the business and needs to be considered as
a natural part of the process – technology and 2 Phase Commit wont solve
this*
• This challenges how we look at the process
• Based on the questions we ask ourselves
• And what we promise customers
• Example:
• Is it really not possible to purchase Taxfree even though the seating system doesn’t know
our booking or concrete seating?
• This is known as being causally consistent (a level of eventual consistent)
* See http://www.udidahan.com/2010/08/31/race-conditions-dont-exist/
Eventual consistency can be our friend
• Consistency is within each Service
• Eventual consistency is between Services
• Like in the real world
Sales Invoicing
Inventory Shipping
Order
Accepted
Invoice Customer
Checks Inventory for availability Books truck driver
Order
Packaged
Fetch Package from Inventory
Customer
Invoiced
IMPORTANT!
Figure out who owns the process
Choreographed Event Driven Processes
Online Ordering System
Sales Service
Order
Accepted
Invoicing Service
Order Fulfilment
(Saga/
Process-Manager)
Shipping Service
MessageChannel
Order
Accepted
Order
Accepted
Customer
Billed
Customer
Billed
Order
Approved
Order
Approved
Works as a Finite
State Machine
(WorkFlow)
handling the life
cycle of Shipping
and thereby forms a
very central new
Aggregate in the
System
Process Managers
• Process Managers are essential to the coordination and monitoring
of long running business processes/transactions
• They work as a Finite State Machines (WorkFlow) which handling the
life cycle of Process (e.g. Shipping an Order) and thereby forms a
very central new Aggregate in the System
• They can include manual steps/person intervention
• Sometimes these Process Managers belong naturally within a
specific Business capability and other times they are truly a thing by
themselves and therefore often form a new business capabilities
Many companies derive their competitive advantages from their Processes.
A Process Manager allows you coordinate Business Processes on the basis of
Events
Choreography is very different from the classical
orchestrated integration process
What should Events look like?
• Keep Events Small
• Only include relevant information (time, id’s unless you use events for
duplication)
• If possible, don’t include unnecessary id’s for aggregates in other services
• Think Inverse relationships based on what feels most natural
• Order doesn’t need to know the Shipping Id, but Shipping can know the Order Id
• Anchor Events to Time
• Include information about how long you can trust the Event’s change
• E.g. a price is valid until 8pm tomorrow night
• Reveal the intention and time anchoring as part of the Events
name
The INPAY approach to Microservices
SERVICES IN INPAY
Many perspectives on data
Online Retail System
Product
Unit Price
Promotional Price
Promotion End Date
Stock Keeping Unit (SKU)
Quantity On Hand (QOH)
Location Code
Price
Quantity Ordered
Name
The lifecycle of the data is VERY important!
Customer
Pricing
Inventory
Sales
Management Reporting
Different perspectives on entities
With in a given Domain, e.g. Retail, there will exist multiple bounded contexts/sub-domains/business
capabilities such as:
• Product management
• Purchase
• Sales
• Pricing
• Inventory
• Shipping
• Support
• Accounting
• Management
Each of these lines of business have very specific and unique needs which are relevant for them alone in order
to conduct their business. They might use the same name for the entities they’re interested in or they might use
different names for the same logical entity.
Smaller models & clear data ownership
Retail System
Pricing
Product
ProductID
Unit Price
Promotional
Price
…
Pricing
Inventory
Product
ProductID
SKU
QOH
Location Code
…
Inventory
Sales
Product
ProductID
Name
Description
Quantity
Ordered
…
Sales
Shared Entity identitySOA:
Service
Billing
Product
Catalogue
Shipping
Sales
Inventory
Pricing
Retail domain split into a Macro architecture
These splits should be fairly small (but not too small)
and share as little as possible with each other
Sales Pricing InventoryShipping
✕ ✕ ✕
What’s a macro architecture
• It’s the static/stable(r) parts of your architecture
• Which are very costly to refactor and change
• Business capabilities are stable
• Therefore we should strive to align services with business
capabilities / bounded contexts (DDD)
BOUNDED CONTEXT
The setting in which a word or a
statement appears that determines its
meaning
Ensures that our
is clear and precise
DDD DOESN’T ENFORCE
PROBLEM DOMAIN AND
SOLUTION DOMAIN
ALIGNMENT FOR BOUNDED
CONTEXTS
Which is why we prefer to use the term Business Capability
Service and Business Capability alignment
“The advantage of business capabilities is their remarkable level
of stability. If we take a typical insurance organisation, it will likely
have sales, marketing, policy administration, claims management,
risk assessment, billing, payments, customer service, human
resource management, rate management, document management,
channel management, commissions management, compliance, IT
support and human task management capabilities. In fact, any
insurance organisation will very likely have many of these
capabilities.”
See http://bill-poole.blogspot.dk/2008/07/business-
capabilities.html
A Service is
• The technical authority for a given business capability
• It is the owner of all the data and business rules that support this business
capability – everywhere (including the UI)
• It forms a single source of truth for that capability
• This form of business and IT alignment ensures that we can maintain service
Autonomy & Encapsulation
Services/Business-capabilities in INPAY
Currency
Service
Finance
Service
Banking
Service
Identity
Management
Service
Sales
Service
PSP
Service
3rd party
Providers
Service
Virtual
Banking
Service
IT
Operations
Applications in INPAY
Identity
Management
Application
Contract
Manager
Application
Treasury
Application
Compliance
Application
Operations
Application
CRM
PSP
Gateway
PSP
Merchant
Application
ERP
Services, Applications and code
• Each Service and Application is maintained within its own Git repository
• Common IT Operations libraries and infrastructure are maintained in separate
Git repositories
So what’s inside a Service source repository?
• Autonomous Components
• Libraries
• Adapters
• Front-end UI components
• API contracts (mostly Events)
• Schemas
• Build file(s)
Autonomous Components?
Service and deployment
• A Service represents a logical responsibility
boundary
• Logical responsibility and physical deployment of a Service DOES
NOT have to be 1-to-1
• It’s too constraining
• We need more degrees of freedom
• Philippe Krutchen 4+1 views of architecture: Logical and Physical designs
should be independent of each other
A service needs to be deployed everywhere its data is needed
Service deployment
• Many services can be deployed to the same physical server
• Many services can be deployed in the same application
• Application boundary is a Process boundary which is a physical boundary
• A Service is a logical boundary
• Service deployment is not restricted to tiers either
• Part of service A and B can be deployed to the Web tier
• Another part of Service A and B can be deployed to the backend/app-service
tier of the same application
• The same service can be deployed to multiple tiers / multiple applications
• ie. applications and services are not the same and does not share the
same boundaries
• Multiple services can be “deployed” to the same UI page (service mashup)
• Multiple services can cooperate to fulfill a use-case (e.g. a workflow or a
business process)
Service
Autonomous
Component
1..*
Is implemented by
A Service is the technical authority of
a specific Business Capability
e.g. Sales, Shipping, Billing
Services support business processes.
Business processes naturally span multiple services, but
there will always be a single service that is the actual
authority on the business process.
Service vs Autonomous Components
Also known as Microservices
Service
Autonomous
Component
1..*
Is implemented by
Service vs Autonomous Components
Autonomous-Components/Microservices are a division of Services along Transactional
boundaries (a transaction stays within the boundary of a Microservice)
Microservices are the individually logical deployable units of a Service with their own
Endpoints. Could e.g. be the split between Read and Write models (CQRS) - each would be
their own Microservice
Services are the corner stone
• We talk in terms of Services/business capabilities and the processes/use-
cases they support
• Autonomous-Components/Microservices are an implementation detail
• They are much less stable (which is a good thing – it means they’re easier to replace)
• With regards to other Services
• subscribe to events from
• send commands to (less common)
• call operations (in rare occasions)
Where does that leave Systems?
• Systems and Services are in my
opinion the same
• For a service to be autonomous is
must be self contained – which
means it must:
• Own its UI
• Own its Business Logic
• Own its Data model & storage
• Which is similar to how Self
Contained Systems are/were build
User interface
Business Logic
Data model &
storage
Service / System
Services/Bounded Contexts and Aggregates
Sales
Service
PSP
ServiceVirtual Banking
Service
Finance
Service
Customer
customerId
…
Contract
contractId
customerId
…
VBFeeSchedule
contractId
…
PSPFeeSchedule
contractId
…
BillingTemplate
contractId
…
INPAY Autonomous Component design principles
Commands and Events
Events
Identifiers
Commands
Commands and Events
public class RegisterBankCmd extends AbstractCommand {
@TargetAggregateIdentifier
public final BankId bankId;
public final String name;
public final Country countryOfOperation;
public RegisterBankCmd(BankId bankId, String name, Country countryOfOperation) {
Objects.requireNonNull(bankId, "bankId");
Objects.requireNonNull(name, "name");
Objects.requireNonNull(countryOfOperation, "countryOfOperation");
this.bankId = bankId;
this.name = name;
this.countryOfOperation = countryOfOperation;
}
}
Commands and Events
The generic business event interface includes the
name of the topic that subscribers must use
public class BankRegistered extends AbstractEvent implements BankEvent {
@AggregateIdentifier
public final BankId bankId;
public final String name;
public final Country countryOfOperation;
public BankCreated(BankId bankId, String name, Country countryOfOperation) {
this.bankId = bankId;
this.name = name;
this.countryOfOperation = countryOfOperation;
}
}
public interface BankEvent extends Serializable {
TopicName TOPIC_NAME = BankingServiceId.ID.topicName("bank-events");
}
CQRS
A single model cannot be
appropriate for reporting,
searching and transactional
behavior
Greg Young, 2008
Query/Read models
• To offload the Aggregate models, i.e. the transactional
write model, we introduce the concept of Read Models
• Query/Read Models are projections of one or more
Aggregate models which store and represent data in the
best possible way for the given Query use cases
UI Application Domain Write
model
Commands – Change data
UI Application Read
models
Queries – Ask for data (no side effects)
Commands, Events and Query Models
Read model
Read model
Events
UI
Domain modelQuery/Read model
”AcceptOrder”
command
”OrderAccepted”
event
”Find all
Accepted Orders”
Query
Commands are Imperative: DoStuff
Events are Past tense: StuffDone
CQRS Building blocks
Client
Commands
Command
Bus
Sends
Command
Handlers
Modify
Repositories
Read Write
Data
store
Event
Bus
Command
Autonomous Components
Event Handlers
Events
Read store
Query HandlersQuery Results
Queries
Query/Read Model
Autonomous Components
Events
Domain
Event Sourcing
Aggregates track their own Domain Events
and derive state from them
Time
07:39
Time
07:40
Time
07:41
Time
07:45
Time
07:46
Time
07:50
Relational Database EventStore example
Time
07:39
Time
07:40
Time
07:41
Time
07:45
Time
07:46
Time
07:50
Type Aggregate
Identifier
Sequence
Number
Timestamp Event
Identifier
EventType SerializedEvent
Order 14237 0 2014-01-06 7:39 {Guid-1} OrderCreated <serialized event>…
Order 14237 1 2014-01-06 7:40 {Guid-2} ProductAdded <serialized event>…
Order 14237 2 2014-01-06 7:41 {Guid-3} ProductAdded <serialized event>…
Order 14237 3 2014-01-06 7:45 {Guid-4} ProductRemoved <serialized event>…
Order 14237 4 2014-01-06 7:46 {Guid-5} ProductAdded <serialized event>…
Order 14237 5 2014-01-06 7:50 {Guid-6} OrderAccepted <serialized event>…
Order 14238 0 2014-01-07 9:10 {Guid-X} OrderCreated <serialized event>…
DomainEvents Table
Event Replaying
Type Aggregate
Identifier
Sequence
Number
Timestamp Event
Identifier
EventType SerializedEvent
Order 14237 0 2014-01-06 7:39 {Guid-1} OrderCreated <serialized event>…
Order 14237 1 2014-01-06 7:40 {Guid-2} ProductAdded <serialized event>…
Order 14237 2 2014-01-06 7:41 {Guid-3} ProductAdded <serialized event>…
Order 14237 3 2014-01-06 7:45 {Guid-4} ProductRemoved <serialized event>…
Order 14237 4 2014-01-06 7:46 {Guid-5} ProductAdded <serialized event>…
Order 14237 5 2014-01-06 7:50 {Guid-6} OrderAccepted <serialized event>…
Order
Accepted: false
Event Replaying
Type Aggregate
Identifier
Sequence
Number
Timestamp Event
Identifier
EventType SerializedEvent
Order 14237 0 2014-01-06 7:39 {Guid-1} OrderCreated <serialized event>…
Order 14237 1 2014-01-06 7:40 {Guid-2} ProductAdded <serialized event>…
Order 14237 2 2014-01-06 7:41 {Guid-3} ProductAdded <serialized event>…
Order 14237 3 2014-01-06 7:45 {Guid-4} ProductRemoved <serialized event>…
Order 14237 4 2014-01-06 7:46 {Guid-5} ProductAdded <serialized event>…
Order 14237 5 2014-01-06 7:50 {Guid-6} OrderAccepted <serialized event>…
Order
Orderline
Accepted: false
Event Replaying
Type Aggregate
Identifier
Sequence
Number
Timestamp Event
Identifier
EventType SerializedEvent
Order 14237 0 2014-01-06 7:39 {Guid-1} OrderCreated <serialized event>…
Order 14237 1 2014-01-06 7:40 {Guid-2} ProductAdded <serialized event>…
Order 14237 2 2014-01-06 7:41 {Guid-3} ProductAdded <serialized event>…
Order 14237 3 2014-01-06 7:45 {Guid-4} ProductRemoved <serialized event>…
Order 14237 4 2014-01-06 7:46 {Guid-5} ProductAdded <serialized event>…
Order 14237 5 2014-01-06 7:50 {Guid-6} OrderAccepted <serialized event>…
Order
Orderline
Orderline
Accepted: false
Event Replaying
Type Aggregate
Identifier
Sequence
Number
Timestamp Event
Identifier
EventType SerializedEvent
Order 14237 0 2014-01-06 7:39 {Guid-1} OrderCreated <serialized event>…
Order 14237 1 2014-01-06 7:40 {Guid-2} ProductAdded <serialized event>…
Order 14237 2 2014-01-06 7:41 {Guid-3} ProductAdded <serialized event>…
Order 14237 3 2014-01-06 7:45 {Guid-4} ProductRemoved <serialized event>…
Order 14237 4 2014-01-06 7:46 {Guid-5} ProductAdded <serialized event>…
Order 14237 5 2014-01-06 7:50 {Guid-6} OrderAccepted <serialized event>…
Order
Orderline
Accepted: false
Event Replaying
Type Aggregate
Identifier
Sequence
Number
Timestamp Event
Identifier
EventType SerializedEvent
Order 14237 0 2014-01-06 7:39 {Guid-1} OrderCreated <serialized event>…
Order 14237 1 2014-01-06 7:40 {Guid-2} ProductAdded <serialized event>…
Order 14237 2 2014-01-06 7:41 {Guid-3} ProductAdded <serialized event>…
Order 14237 3 2014-01-06 7:45 {Guid-4} ProductRemoved <serialized event>…
Order 14237 4 2014-01-06 7:46 {Guid-5} ProductAdded <serialized event>…
Order 14237 5 2014-01-06 7:50 {Guid-6} OrderAccepted <serialized event>…
Order
Orderline
Orderline
Accepted: false
Event Replaying
Type Aggregate
Identifier
Sequence
Number
Timestamp Event
Identifier
EventType SerializedEvent
Order 14237 0 2014-01-06 7:39 {Guid-1} OrderCreated <serialized event>…
Order 14237 1 2014-01-06 7:40 {Guid-2} ProductAdded <serialized event>…
Order 14237 2 2014-01-06 7:41 {Guid-3} ProductAdded <serialized event>…
Order 14237 3 2014-01-06 7:45 {Guid-4} ProductRemoved <serialized event>…
Order 14237 4 2014-01-06 7:46 {Guid-5} ProductAdded <serialized event>…
Order 14237 5 2014-01-06 7:50 {Guid-6} OrderAccepted <serialized event>…
Order
Orderline
Orderline
Accepted: true
Snapshotting
Type Aggregate
Identifier
Latest
Sequence
Number
Timestamp Serialized Aggregate
Order 14237 4 2014-01-06 7:46 <serialized aggregate>…
Product 15918 1 2014-01-07 7:40 <serialized aggregate>…
Type Aggregate
Identifier
Sequence
Number
Timestamp Event
Identifier
EventType SerializedEvent
Order 14237 0 2014-01-06 7:39 {Guid-1} OrderCreated <serialized event>…
Order 14237 1 2014-01-06 7:40 {Guid-2} ProductAdded <serialized event>…
Order 14237 2 2014-01-06 7:41 {Guid-3} ProductAdded <serialized event>…
Order 14237 3 2014-01-06 7:45 {Guid-4} ProductRemoved <serialized event>…
Order 14237 4 2014-01-06 7:46 {Guid-5} ProductAdded <serialized event>…
Order 14237 5 2014-01-06 7:50 {Guid-6} OrderAccepted <serialized event>…
Snapshot Table
Domain Events Table
Full CQRS
With EventSourcing
UI Domain
Event
Store
(can e.g. be a real
EventStore DB or
a Relational DB)
Commands – Change data
Commands Events
SQL DB Document DB Graph DB
UI Data
Queries – Ask for data
Events
Query Build
Our single
source of truth
Aggregate
public class Bank extends InPayEventSourcedAggregate {
@AggregateIdentifier
private BankId bankId;
@EventSourcedMember
private Map<BankAccountId, BankAccount> bankAccounts = new HashMap<>();
public Bank(BankId bankId, String name, Country countryOfOperation) {
apply(new BankRegistered(bankId, name, countryOfOperation));
}
public void addBankAccount(BankAccountId bankAccountId, …) {
if (!bankAccounts.containsKey(bankAccountId)) {
apply(new BankAccountAdded(bankId,
bankAccountId,
…));
}
}
@EventSourcingHandler
private void on(BankRegistered e) {
bankId = e.getBankId();
}
@EventSourcingHandler
private void on(BankAccountAdded e) {
BankAccount bankAccount =
bankAccounts.put(e.getBankAccountId(), new BankAccount(e.getBankId(), e.getBankAccountId(), …));
}
}
Service project structure sales_service
sales_api
sales_contract_ac
sales_customer_ac
frontend
sales_contract_manager_adapters
contract
adapters
sales/modules
customer
psp_service
psp_api
psp_fees_ac
…
frontend
psp_contract_manager_adapters
fees
adapters
psp/modules
fx
Legend:
Service/Business-Capability
External Event/Command Contracts
Autonomous Component
Autonomous Component Adapter
Angular.js Module
Builds into a Java JAR
Uses Spring MVC/REST
All Java 8 artifacts are built
using Gradle
Autonomous Component
• Can be deployed alone or co-located
• Usually deployed together with one or more adapters
• Works transparently in a clustered environment
• Completely Spring free 
• Only depends on our Core infrastructure library
• Common types and Id’s
• Bus infrastructure
• Service lookup
• CQRS building blocks (backed by Axon framework)
AC in code public class PSPAgreementAc extends HzBackedAutonomousComponent {
public static AutonomousComponentId SERVICE_AC_ID = PSP_SERVICE_ID.ac("psp_agreement_ac");
…
public PSPAgreementAc(CurrencyConverter currencyConverter) {
this.currencyConverter = currencyConverter;
}
@Override
public void onInitialize(IConfigureACEnvironment acSetup) {
acSetup.withAutonomousComponentId(SERVICE_AC_ID).usingServiceDataSource()
.withBusConfiguration(cfg -> {
cfg.getAxonContext()
.subscribeAnnotatedCommandHandler(new TemplateCmdHandler(
cfg.getAxonContext().eventSourcedRepository(PSPTemplate.class),
currencyConverter));
….
manageLifecycleFor(templateViewRepository = new TemplateViewRepository(cfg, currencyConverter));
})
.runOnBusStartup((bus, axonContext) -> {
bus.registerAxonReplayableTopicPublisher(InternalTemplateEvents.TOPIC_NAME,
replayFromAggregate(PSPTemplate.class)
.dispatchAggregateEventsOfType(InternalTemplateEvents.class));
bus.subscribeTopic(SERVICE_AC_ID.topicSubscriber("ContractEvents"),
ExternalContractEvents.TOPIC_NAME,
new SalesTopicSubscription(bus));
});
}
public TemplateViewRepository getTemplateViewRepository() { return templateViewRepository; }
}
Distributed in memory views
public class PSPFeeScheduleViewRepository extends HzBackedDataRepository<ContractId, PSPFeeScheduleView> implements Lifecycle {
private final Bus bus;
private Subscription subscription;
public PSPFeeScheduleViewRepository(HazelcastInstance hazelcastInstance, String serviceId, Bus bus) {
super(hazelcastInstance, serviceId);
this.bus = bus;
}
@Override
public void start() {
subscription = bus.subscribeTopic(TopicSubscription.FromBeginning(PSPFeeScheduleAc.SERVICE_AC_ID.subscriberId("-FeeScheduleView"),
PSPFeeScheduleRelated.TOPIC_NAME),
new BusMessageHandlerDelegator<>(this));
}
@Override
public void shutdown() {
if (subscription != null)subscription.cancel();
}
public PSPFeeScheduleView load(ContractId contractId) {
final PSPFeeScheduleView payOutFeeScheduleView = cache.get(contractId);
if (payOutFeeScheduleView == null)
throw new ValidationException(PSPFeeScheduleMessages.feeScheduleDoesNotExist.validationMsg(contractId));
return payOutFeeScheduleView;
}
@BusMessagePayloadHandler
private void on(PSPFeeScheduleCreated event) {
cache.put(event.contractId, new PSPFeeScheduleView(event));
}
@BusMessagePayloadHandler
private void on(PSPFeeScheduleDiscarded event) {
cache.remove(event.contractId);
}
...
}
Infrastructure
202
The core of the infrastructure
• It’s the core infrastructure that allows services/AC’s to communicate using
messages using our Federated Bus.
• This means we don’t need to deploy any Message Brokers (such as
RabbitMQ, ActiveMQ) – the Bus supports:
• Broadcast
• Notifications
• Non durable Queues
• Durable Queues
• Non-durable Topics
psp_fees_ac
(deployed on 10.25.26.102)
psp_fees_ac
(deployed on 10.25.26.101)
Bus Bus
Bus Bus
sales_contract_ac
(deployed on 10.25.26.104)
sales_contract_ac
(deployed on 10.25.26.103)
Federated Bus
Distributed
Bus
Topic
Queue
Topic
Publisher
side
Topic
Subscriber
side
Queue
Sender
side
Queue
Receiver
side
Local
Topic
Publisher
Local
Topic
Subscriber
Local
Queue
Sender
Local
Queue
Receiver
Distributed per Service
EventBus
Local
Topic
Subscriber
Local
Topic
Subscriber
Local
Queue
Sender
Distributed
Notifications
Distributed
Broadcast
Distributed
SingleInstance
Task
Non-durable Topics and Client handled subscriptions
• Highly resilient pattern for an Event Driven Architecture that’s backed by AC’s that
use EventSourcing.
• In this model the publisher of the Events is responsible for the durability of all its
Events, typically to an EventStore/EventLog.
• Each client (subscriber) maintains durable information of the last event it received
from each publisher.
• When ever the client starts up it makes a subscription to the publisher where it
states from which point in time it wants events published.
• This effectively means that publisher can remain simple and the client (subscriber)
can remain simple and we don’t need additional sophisticated broker infrastructure
such as Kafka+ZooKeeper.
Client handled subscriptions
Publisher
Subscriber
A
Local storage
EventStore
Subscriber
B
Local storage
Topic
Subscription
Topic
Subscription
TopicSubscriptionHandler
TopicSubscriptionHandler
EventEvent
Event Event
EventBus
Event
Event
Applications
AUTONOMOUS-COMPONENTS/
MICROSERVICES ARE LOGICAL
DEPLOYABLE UNITS
That doesn’t mean they HAVE to be deployed individually.
Design for Distribution
But take advantage of locality
Logical Architecture Building Blocks
Autonomous Components can be co-deployed together
with Application backends
contract_manager (Spring Boot fat–jar)
sales_contract_ac
sales_customer_ac
sales_contract_manager_adapters
psp_api
psp_fees_ac
psp_contract_manager_adapters
frontend
sales_api
app
libs
contract
customer
fees
Application in code
@Configuration
@ComponentScan(basePackages = { "com.inpay.contractmanager",
"com.inpay.adapters",
"com.inpay.itops.spring" })
public class Application extends InpaySpringBootApplication {
public Application() {
super();
}
@Override
protected String getApplicationName() {
return "ContractManager";
}
@Override
protected Collection<AutonomousComponent> getAutonomousComponentsHostedInThisApplication() {
CurrencyExchangeRateAc currencyExchangeRateAc = new CurrencyExchangeRateAc();
return list(
new IDMCoreAc(),
new PSPFeeScheduleAc(currencyExchangeRateAc.getCurrencyConverter()),
new VBFeeScheduleAc(currencyExchangeRateAc.getCurrencyConverter()),
new ContractAc(),
new CustomersAc(),
currencyExchangeRateAc
);
}
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
What about Security/Identity management (IDM)?
• That’s an AC as well, belonging to IT operations
• Technical security belongs with IDM
• May this caller call this endpoint
• Is this User authenticated
• Simple Authorization: Does this User have Privilege A, B and C
• Business related Authorization belongs in the designated Business ACs
• May this user approve a Contract with Fees below X, Y and Z
Security and Applications
@ComponentScan(basePackages = { "com.inpay.contractmanager", "com.inpay.adapters", "com.inpay.itops.spring" })
AC, autonomy and “shared” data
Service
DB
DB
Autonomous
Component
Autonomous
Component
Autonomous
Component
Autonomous
Component DB
50 shades of AC Autonomy*
Endpoint Process Database Storage
Shared Shared Shared Shared
Own Shared Shared Shared
Own Own Shared Shared
Own Shared Own Shared
Own Own Own Shared
Own Own Own Own
Lower Autonomy
Higher Autonomy
* No RPC in use!
Composite UI
Page
Controller
Page
Controller
Page
Controller
Page
Controller Page
Template
Page
Template
Page
Template
Page
Template
ServiceService
Scope
Back-
end
HTTP
Back-
end
Back-
end
Back-
end
Back-
end
• Coordinate back-end communication
• Avoid UI coupling
CommonAngular Application
Service A Service B Service C
IT-OPS
Application
App
Application
App logic
(Layered, CQRS,…)
lication
Storage
UI Components
Services & Composite UI’s
Widget Widget
Page
Widget
Service A Service B Service C
Widget
Widget
Widget
Service A
Service B
Service C
Widget
Service C
• Overall structure of the page
is “owned” by the application.
• Each widget and the view model
it binds to is delivered by the
underlying Service.
Page layout
AngularJS as Composite UI Framework
• Misko Hevery – Don’t fight HTML, extend it!
• For our purpose each widget maps naturally to a directive.
• AngularJS is modular in nature which aligns nicely with
our needs having multiple Services taking part
in an application.
Angular Controllers & Services (1 of 2)
• An angular service is normally responsible for gathering
and posting data to the back-end.
• There will be at least one angular service per Service
that participates in the application
• In angular a service is injected in a controller. Not vice
versa.
• Yet application in/output must be coordinated in some
way through the services
• In angular controllers are NOT singletons.
• Each directive get its own instance of a controller,
meaning there are numerous controller instances at
playWhat are the consequences of this with regards to a composite UI?
• An angular service is normally responsible for gathering and
posting data to the back-end.
• There will be at least one angular service per Service that participates in
the application
• In angular a service is injected in a controller. Not vice versa.
• Yet application in/output must be coordinated in some
way through the services
• In angular controllers are NOT singletons.
• Each directive get its own instance of a controller, meaning there are
numerous controller instances at play
Angular Controllers & Services (2 of 2)
• Gathering and posting data through angular services
needs to happen in a coordinated manner.
• Client side events
• The controllers instantiated through directives needs to be
kept in sync and caution must be made to avoid
numerous round-trips to the backend Services
• There is a need to have a controller that drives the overall
use-case for a single page. The application page
controller.
• The application page controller must not know the data
structure of any of the participating angular services.
• Gathering and posting data through angular services needs to
happen in a coordinated manner.
• Client side events
• The controllers instantiated through directives needs to be kept in
sync and caution must be made to avoid numerous round-trips to the
backend Services
• There is a need to have a controller that drives the overall use-case
for a single page. The application page controller.
• The application page controller must not know the data structure of
any of the participating angular services.
Application Startup
• Client-side event subscription
• Enrolling for client-side distributed post operations
Page Rendering Example
Page Ctrl
Sales
Service
UI Broker
Customer
Service
Pricing
Service
Product
Service
Page Widget
Ctrl
Widget
Ctrl
Widget
Ctrl
Widget
Ctrl
Widget
Ctrl
Widget
Ctrl
Widget
Ctrl
Widget
Ctrl
1.
Backend
API
Backend
API
Backend
API
Backend
API
2.
3.
4.
5.
5.
6.
7.
7.
7.
7.
5.
8.
8.
8.
8.
Thanks :)

More Related Content

What's hot

AWS builders industry edition : 고객으로부터 시작하는 데이터 기반 마케팅 접근 전략
AWS builders industry edition : 고객으로부터 시작하는 데이터 기반 마케팅 접근 전략AWS builders industry edition : 고객으로부터 시작하는 데이터 기반 마케팅 접근 전략
AWS builders industry edition : 고객으로부터 시작하는 데이터 기반 마케팅 접근 전략
Amazon Web Services Korea
 
있는 그대로 저장하고, 바로 분석 가능한, 새로운 관점의 데이터 애널리틱 플랫폼 - 정세웅 애널리틱 스페셜리스트, AWS
있는 그대로 저장하고, 바로 분석 가능한, 새로운 관점의 데이터 애널리틱 플랫폼 - 정세웅 애널리틱 스페셜리스트, AWS있는 그대로 저장하고, 바로 분석 가능한, 새로운 관점의 데이터 애널리틱 플랫폼 - 정세웅 애널리틱 스페셜리스트, AWS
있는 그대로 저장하고, 바로 분석 가능한, 새로운 관점의 데이터 애널리틱 플랫폼 - 정세웅 애널리틱 스페셜리스트, AWS
Amazon Web Services Korea
 
Telus의 AWS활용 사례: AWS 서버리스 기반 3GPP 코어 및 BSS 구축 – 조경준 AWS 솔루션즈 아키텍트:: AWS Cloud...
Telus의 AWS활용 사례: AWS 서버리스 기반 3GPP 코어 및 BSS 구축 – 조경준 AWS 솔루션즈 아키텍트:: AWS Cloud...Telus의 AWS활용 사례: AWS 서버리스 기반 3GPP 코어 및 BSS 구축 – 조경준 AWS 솔루션즈 아키텍트:: AWS Cloud...
Telus의 AWS활용 사례: AWS 서버리스 기반 3GPP 코어 및 BSS 구축 – 조경준 AWS 솔루션즈 아키텍트:: AWS Cloud...
Amazon Web Services Korea
 
AWS Summit Seoul 2023 | 금융 디지털 서비스 혁신을 리딩하는 교보정보통신의 클라우드 마이그레이션 사례 소개
AWS Summit Seoul 2023 | 금융 디지털 서비스 혁신을 리딩하는 교보정보통신의 클라우드 마이그레이션 사례 소개AWS Summit Seoul 2023 | 금융 디지털 서비스 혁신을 리딩하는 교보정보통신의 클라우드 마이그레이션 사례 소개
AWS Summit Seoul 2023 | 금융 디지털 서비스 혁신을 리딩하는 교보정보통신의 클라우드 마이그레이션 사례 소개
Amazon Web Services Korea
 
Serverless Architecture on AWS
Serverless Architecture on AWSServerless Architecture on AWS
Serverless Architecture on AWS
Rajind Ruparathna
 
IAM 정책을 잘 알아야 AWS 보안도 쉬워진다. 이것은 꼭 알고 가자! - 신은수 솔루션즈 아키텍트, AWS :: AWS Summit S...
IAM 정책을 잘 알아야 AWS 보안도 쉬워진다. 이것은 꼭 알고 가자! - 신은수 솔루션즈 아키텍트, AWS :: AWS Summit S...IAM 정책을 잘 알아야 AWS 보안도 쉬워진다. 이것은 꼭 알고 가자! - 신은수 솔루션즈 아키텍트, AWS :: AWS Summit S...
IAM 정책을 잘 알아야 AWS 보안도 쉬워진다. 이것은 꼭 알고 가자! - 신은수 솔루션즈 아키텍트, AWS :: AWS Summit S...
Amazon Web Services Korea
 
Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...
Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...
Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...
Amazon Web Services Korea
 
AWS Summit Seoul 2023 | Amazon Redshift Serverless를 활용한 LG 이노텍의 데이터 분석 플랫폼 혁신 과정
AWS Summit Seoul 2023 | Amazon Redshift Serverless를 활용한 LG 이노텍의 데이터 분석 플랫폼 혁신 과정AWS Summit Seoul 2023 | Amazon Redshift Serverless를 활용한 LG 이노텍의 데이터 분석 플랫폼 혁신 과정
AWS Summit Seoul 2023 | Amazon Redshift Serverless를 활용한 LG 이노텍의 데이터 분석 플랫폼 혁신 과정
Amazon Web Services Korea
 
Amazon DocumentDB vs MongoDB 의 내부 아키텍쳐 와 장단점 비교
Amazon DocumentDB vs MongoDB 의 내부 아키텍쳐 와 장단점 비교Amazon DocumentDB vs MongoDB 의 내부 아키텍쳐 와 장단점 비교
Amazon DocumentDB vs MongoDB 의 내부 아키텍쳐 와 장단점 비교
Amazon Web Services Korea
 
AWS Lake Formation을 통한 손쉬운 데이터 레이크 구성 및 관리 - 윤석찬 :: AWS Unboxing 온라인 세미나
AWS Lake Formation을 통한 손쉬운 데이터 레이크 구성 및 관리 - 윤석찬 :: AWS Unboxing 온라인 세미나AWS Lake Formation을 통한 손쉬운 데이터 레이크 구성 및 관리 - 윤석찬 :: AWS Unboxing 온라인 세미나
AWS Lake Formation을 통한 손쉬운 데이터 레이크 구성 및 관리 - 윤석찬 :: AWS Unboxing 온라인 세미나
Amazon Web Services Korea
 
Double Redundancy with AWS Direct Connect - Pop-up Loft Tel Aviv
Double Redundancy with AWS Direct Connect - Pop-up Loft Tel AvivDouble Redundancy with AWS Direct Connect - Pop-up Loft Tel Aviv
Double Redundancy with AWS Direct Connect - Pop-up Loft Tel Aviv
Amazon Web Services
 
Optimizing Network Performance for Amazon EC2 Instances (CMP308-R1) - AWS re:...
Optimizing Network Performance for Amazon EC2 Instances (CMP308-R1) - AWS re:...Optimizing Network Performance for Amazon EC2 Instances (CMP308-R1) - AWS re:...
Optimizing Network Performance for Amazon EC2 Instances (CMP308-R1) - AWS re:...
Amazon Web Services
 
Object Storage: Amazon S3 and Amazon Glacier
Object Storage: Amazon S3 and Amazon GlacierObject Storage: Amazon S3 and Amazon Glacier
Object Storage: Amazon S3 and Amazon Glacier
Amazon Web Services
 
Day 5 - Real-time Data Processing/Internet of Things (IoT) with Amazon Kinesis
Day 5 - Real-time Data Processing/Internet of Things (IoT) with Amazon KinesisDay 5 - Real-time Data Processing/Internet of Things (IoT) with Amazon Kinesis
Day 5 - Real-time Data Processing/Internet of Things (IoT) with Amazon Kinesis
Amazon Web Services
 
마이데이터 사업자 핀다에게 듣다! - 핀테크의 AWS 활용 전략 - 이지영 AWS 솔루션즈 아키텍트 / 박홍민 대표, 핀다 :: AWS S...
마이데이터 사업자 핀다에게 듣다! - 핀테크의 AWS 활용 전략 - 이지영 AWS 솔루션즈 아키텍트 / 박홍민 대표, 핀다 :: AWS S...마이데이터 사업자 핀다에게 듣다! - 핀테크의 AWS 활용 전략 - 이지영 AWS 솔루션즈 아키텍트 / 박홍민 대표, 핀다 :: AWS S...
마이데이터 사업자 핀다에게 듣다! - 핀테크의 AWS 활용 전략 - 이지영 AWS 솔루션즈 아키텍트 / 박홍민 대표, 핀다 :: AWS S...
Amazon Web Services Korea
 
BigQuery implementation
BigQuery implementationBigQuery implementation
BigQuery implementation
Simon Su
 
Bridge to Cloud: Using Apache Kafka to Migrate to GCP
Bridge to Cloud: Using Apache Kafka to Migrate to GCPBridge to Cloud: Using Apache Kafka to Migrate to GCP
Bridge to Cloud: Using Apache Kafka to Migrate to GCP
confluent
 
Airbnb Runs on Amazon Aurora - DAT331 - re:Invent 2017
Airbnb Runs on Amazon Aurora - DAT331 - re:Invent 2017Airbnb Runs on Amazon Aurora - DAT331 - re:Invent 2017
Airbnb Runs on Amazon Aurora - DAT331 - re:Invent 2017
Amazon Web Services
 
Deep Dive Amazon EC2
Deep Dive Amazon EC2Deep Dive Amazon EC2
Deep Dive Amazon EC2
Amazon Web Services
 
[AWS Builders] AWS 스토리지 서비스 소개 및 사용 방법
[AWS Builders] AWS 스토리지 서비스 소개 및 사용 방법[AWS Builders] AWS 스토리지 서비스 소개 및 사용 방법
[AWS Builders] AWS 스토리지 서비스 소개 및 사용 방법
Amazon Web Services Korea
 

What's hot (20)

AWS builders industry edition : 고객으로부터 시작하는 데이터 기반 마케팅 접근 전략
AWS builders industry edition : 고객으로부터 시작하는 데이터 기반 마케팅 접근 전략AWS builders industry edition : 고객으로부터 시작하는 데이터 기반 마케팅 접근 전략
AWS builders industry edition : 고객으로부터 시작하는 데이터 기반 마케팅 접근 전략
 
있는 그대로 저장하고, 바로 분석 가능한, 새로운 관점의 데이터 애널리틱 플랫폼 - 정세웅 애널리틱 스페셜리스트, AWS
있는 그대로 저장하고, 바로 분석 가능한, 새로운 관점의 데이터 애널리틱 플랫폼 - 정세웅 애널리틱 스페셜리스트, AWS있는 그대로 저장하고, 바로 분석 가능한, 새로운 관점의 데이터 애널리틱 플랫폼 - 정세웅 애널리틱 스페셜리스트, AWS
있는 그대로 저장하고, 바로 분석 가능한, 새로운 관점의 데이터 애널리틱 플랫폼 - 정세웅 애널리틱 스페셜리스트, AWS
 
Telus의 AWS활용 사례: AWS 서버리스 기반 3GPP 코어 및 BSS 구축 – 조경준 AWS 솔루션즈 아키텍트:: AWS Cloud...
Telus의 AWS활용 사례: AWS 서버리스 기반 3GPP 코어 및 BSS 구축 – 조경준 AWS 솔루션즈 아키텍트:: AWS Cloud...Telus의 AWS활용 사례: AWS 서버리스 기반 3GPP 코어 및 BSS 구축 – 조경준 AWS 솔루션즈 아키텍트:: AWS Cloud...
Telus의 AWS활용 사례: AWS 서버리스 기반 3GPP 코어 및 BSS 구축 – 조경준 AWS 솔루션즈 아키텍트:: AWS Cloud...
 
AWS Summit Seoul 2023 | 금융 디지털 서비스 혁신을 리딩하는 교보정보통신의 클라우드 마이그레이션 사례 소개
AWS Summit Seoul 2023 | 금융 디지털 서비스 혁신을 리딩하는 교보정보통신의 클라우드 마이그레이션 사례 소개AWS Summit Seoul 2023 | 금융 디지털 서비스 혁신을 리딩하는 교보정보통신의 클라우드 마이그레이션 사례 소개
AWS Summit Seoul 2023 | 금융 디지털 서비스 혁신을 리딩하는 교보정보통신의 클라우드 마이그레이션 사례 소개
 
Serverless Architecture on AWS
Serverless Architecture on AWSServerless Architecture on AWS
Serverless Architecture on AWS
 
IAM 정책을 잘 알아야 AWS 보안도 쉬워진다. 이것은 꼭 알고 가자! - 신은수 솔루션즈 아키텍트, AWS :: AWS Summit S...
IAM 정책을 잘 알아야 AWS 보안도 쉬워진다. 이것은 꼭 알고 가자! - 신은수 솔루션즈 아키텍트, AWS :: AWS Summit S...IAM 정책을 잘 알아야 AWS 보안도 쉬워진다. 이것은 꼭 알고 가자! - 신은수 솔루션즈 아키텍트, AWS :: AWS Summit S...
IAM 정책을 잘 알아야 AWS 보안도 쉬워진다. 이것은 꼭 알고 가자! - 신은수 솔루션즈 아키텍트, AWS :: AWS Summit S...
 
Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...
Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...
Amazon Redshift Deep Dive - Serverless, Streaming, ML, Auto Copy (New feature...
 
AWS Summit Seoul 2023 | Amazon Redshift Serverless를 활용한 LG 이노텍의 데이터 분석 플랫폼 혁신 과정
AWS Summit Seoul 2023 | Amazon Redshift Serverless를 활용한 LG 이노텍의 데이터 분석 플랫폼 혁신 과정AWS Summit Seoul 2023 | Amazon Redshift Serverless를 활용한 LG 이노텍의 데이터 분석 플랫폼 혁신 과정
AWS Summit Seoul 2023 | Amazon Redshift Serverless를 활용한 LG 이노텍의 데이터 분석 플랫폼 혁신 과정
 
Amazon DocumentDB vs MongoDB 의 내부 아키텍쳐 와 장단점 비교
Amazon DocumentDB vs MongoDB 의 내부 아키텍쳐 와 장단점 비교Amazon DocumentDB vs MongoDB 의 내부 아키텍쳐 와 장단점 비교
Amazon DocumentDB vs MongoDB 의 내부 아키텍쳐 와 장단점 비교
 
AWS Lake Formation을 통한 손쉬운 데이터 레이크 구성 및 관리 - 윤석찬 :: AWS Unboxing 온라인 세미나
AWS Lake Formation을 통한 손쉬운 데이터 레이크 구성 및 관리 - 윤석찬 :: AWS Unboxing 온라인 세미나AWS Lake Formation을 통한 손쉬운 데이터 레이크 구성 및 관리 - 윤석찬 :: AWS Unboxing 온라인 세미나
AWS Lake Formation을 통한 손쉬운 데이터 레이크 구성 및 관리 - 윤석찬 :: AWS Unboxing 온라인 세미나
 
Double Redundancy with AWS Direct Connect - Pop-up Loft Tel Aviv
Double Redundancy with AWS Direct Connect - Pop-up Loft Tel AvivDouble Redundancy with AWS Direct Connect - Pop-up Loft Tel Aviv
Double Redundancy with AWS Direct Connect - Pop-up Loft Tel Aviv
 
Optimizing Network Performance for Amazon EC2 Instances (CMP308-R1) - AWS re:...
Optimizing Network Performance for Amazon EC2 Instances (CMP308-R1) - AWS re:...Optimizing Network Performance for Amazon EC2 Instances (CMP308-R1) - AWS re:...
Optimizing Network Performance for Amazon EC2 Instances (CMP308-R1) - AWS re:...
 
Object Storage: Amazon S3 and Amazon Glacier
Object Storage: Amazon S3 and Amazon GlacierObject Storage: Amazon S3 and Amazon Glacier
Object Storage: Amazon S3 and Amazon Glacier
 
Day 5 - Real-time Data Processing/Internet of Things (IoT) with Amazon Kinesis
Day 5 - Real-time Data Processing/Internet of Things (IoT) with Amazon KinesisDay 5 - Real-time Data Processing/Internet of Things (IoT) with Amazon Kinesis
Day 5 - Real-time Data Processing/Internet of Things (IoT) with Amazon Kinesis
 
마이데이터 사업자 핀다에게 듣다! - 핀테크의 AWS 활용 전략 - 이지영 AWS 솔루션즈 아키텍트 / 박홍민 대표, 핀다 :: AWS S...
마이데이터 사업자 핀다에게 듣다! - 핀테크의 AWS 활용 전략 - 이지영 AWS 솔루션즈 아키텍트 / 박홍민 대표, 핀다 :: AWS S...마이데이터 사업자 핀다에게 듣다! - 핀테크의 AWS 활용 전략 - 이지영 AWS 솔루션즈 아키텍트 / 박홍민 대표, 핀다 :: AWS S...
마이데이터 사업자 핀다에게 듣다! - 핀테크의 AWS 활용 전략 - 이지영 AWS 솔루션즈 아키텍트 / 박홍민 대표, 핀다 :: AWS S...
 
BigQuery implementation
BigQuery implementationBigQuery implementation
BigQuery implementation
 
Bridge to Cloud: Using Apache Kafka to Migrate to GCP
Bridge to Cloud: Using Apache Kafka to Migrate to GCPBridge to Cloud: Using Apache Kafka to Migrate to GCP
Bridge to Cloud: Using Apache Kafka to Migrate to GCP
 
Airbnb Runs on Amazon Aurora - DAT331 - re:Invent 2017
Airbnb Runs on Amazon Aurora - DAT331 - re:Invent 2017Airbnb Runs on Amazon Aurora - DAT331 - re:Invent 2017
Airbnb Runs on Amazon Aurora - DAT331 - re:Invent 2017
 
Deep Dive Amazon EC2
Deep Dive Amazon EC2Deep Dive Amazon EC2
Deep Dive Amazon EC2
 
[AWS Builders] AWS 스토리지 서비스 소개 및 사용 방법
[AWS Builders] AWS 스토리지 서비스 소개 및 사용 방법[AWS Builders] AWS 스토리지 서비스 소개 및 사용 방법
[AWS Builders] AWS 스토리지 서비스 소개 및 사용 방법
 

Viewers also liked

The "Why", "What" & "How" of Microservices - short version
The "Why", "What" & "How" of Microservices - short versionThe "Why", "What" & "How" of Microservices - short version
The "Why", "What" & "How" of Microservices - short version
INPAY
 
Building a Docker v1.12 Swarm cluster on ARM
Building a Docker v1.12 Swarm cluster on ARMBuilding a Docker v1.12 Swarm cluster on ARM
Building a Docker v1.12 Swarm cluster on ARM
Team Hypriot
 
Down to Stack Traces, up from Heap Dumps
Down to Stack Traces, up from Heap DumpsDown to Stack Traces, up from Heap Dumps
Down to Stack Traces, up from Heap Dumps
Andrei Pangin
 
Understanding the mysteries of the CSS property value syntax
Understanding the mysteries of the CSS property value syntaxUnderstanding the mysteries of the CSS property value syntax
Understanding the mysteries of the CSS property value syntax
Russ Weakley
 
Developing rich multimedia applications with Kurento: a tutorial for Java Dev...
Developing rich multimedia applications with Kurento: a tutorial for Java Dev...Developing rich multimedia applications with Kurento: a tutorial for Java Dev...
Developing rich multimedia applications with Kurento: a tutorial for Java Dev...
Luis Lopez
 
AppSec And Microservices
AppSec And MicroservicesAppSec And Microservices
AppSec And Microservices
Sam Newman
 
elasticRTC -- how to have your own WebRTC cloud scaling to be billions in min...
elasticRTC -- how to have your own WebRTC cloud scaling to be billions in min...elasticRTC -- how to have your own WebRTC cloud scaling to be billions in min...
elasticRTC -- how to have your own WebRTC cloud scaling to be billions in min...
Luis Lopez
 
vJUG - The JavaFX Ecosystem
vJUG - The JavaFX EcosystemvJUG - The JavaFX Ecosystem
vJUG - The JavaFX Ecosystem
Andres Almiray
 
Token Authentication for Java Applications
Token Authentication for Java ApplicationsToken Authentication for Java Applications
Token Authentication for Java Applications
Stormpath
 
A pattern language for microservices (#gluecon #gluecon2016)
A pattern language for microservices (#gluecon #gluecon2016)A pattern language for microservices (#gluecon #gluecon2016)
A pattern language for microservices (#gluecon #gluecon2016)
Chris Richardson
 
Spring RabbitMQ
Spring RabbitMQSpring RabbitMQ
Spring RabbitMQ
Martin Toshev
 
Microservices + Events + Docker = A Perfect Trio (dockercon)
Microservices + Events + Docker = A Perfect Trio (dockercon)Microservices + Events + Docker = A Perfect Trio (dockercon)
Microservices + Events + Docker = A Perfect Trio (dockercon)
Chris Richardson
 
Developing microservices with aggregates (SpringOne platform, #s1p)
Developing microservices with aggregates (SpringOne platform, #s1p)Developing microservices with aggregates (SpringOne platform, #s1p)
Developing microservices with aggregates (SpringOne platform, #s1p)
Chris Richardson
 
Handling Eventual Consistency in JVM Microservices with Event Sourcing (javao...
Handling Eventual Consistency in JVM Microservices with Event Sourcing (javao...Handling Eventual Consistency in JVM Microservices with Event Sourcing (javao...
Handling Eventual Consistency in JVM Microservices with Event Sourcing (javao...
Chris Richardson
 
Configuration beyond Java EE 8
Configuration beyond Java EE 8Configuration beyond Java EE 8
Configuration beyond Java EE 8
Anatole Tresch
 
Building Netty Servers
Building Netty ServersBuilding Netty Servers
Building Netty Servers
Dani Solà Lagares
 
WebRTC with Java
WebRTC with JavaWebRTC with Java
WebRTC with Java
amithap07
 

Viewers also liked (17)

The "Why", "What" & "How" of Microservices - short version
The "Why", "What" & "How" of Microservices - short versionThe "Why", "What" & "How" of Microservices - short version
The "Why", "What" & "How" of Microservices - short version
 
Building a Docker v1.12 Swarm cluster on ARM
Building a Docker v1.12 Swarm cluster on ARMBuilding a Docker v1.12 Swarm cluster on ARM
Building a Docker v1.12 Swarm cluster on ARM
 
Down to Stack Traces, up from Heap Dumps
Down to Stack Traces, up from Heap DumpsDown to Stack Traces, up from Heap Dumps
Down to Stack Traces, up from Heap Dumps
 
Understanding the mysteries of the CSS property value syntax
Understanding the mysteries of the CSS property value syntaxUnderstanding the mysteries of the CSS property value syntax
Understanding the mysteries of the CSS property value syntax
 
Developing rich multimedia applications with Kurento: a tutorial for Java Dev...
Developing rich multimedia applications with Kurento: a tutorial for Java Dev...Developing rich multimedia applications with Kurento: a tutorial for Java Dev...
Developing rich multimedia applications with Kurento: a tutorial for Java Dev...
 
AppSec And Microservices
AppSec And MicroservicesAppSec And Microservices
AppSec And Microservices
 
elasticRTC -- how to have your own WebRTC cloud scaling to be billions in min...
elasticRTC -- how to have your own WebRTC cloud scaling to be billions in min...elasticRTC -- how to have your own WebRTC cloud scaling to be billions in min...
elasticRTC -- how to have your own WebRTC cloud scaling to be billions in min...
 
vJUG - The JavaFX Ecosystem
vJUG - The JavaFX EcosystemvJUG - The JavaFX Ecosystem
vJUG - The JavaFX Ecosystem
 
Token Authentication for Java Applications
Token Authentication for Java ApplicationsToken Authentication for Java Applications
Token Authentication for Java Applications
 
A pattern language for microservices (#gluecon #gluecon2016)
A pattern language for microservices (#gluecon #gluecon2016)A pattern language for microservices (#gluecon #gluecon2016)
A pattern language for microservices (#gluecon #gluecon2016)
 
Spring RabbitMQ
Spring RabbitMQSpring RabbitMQ
Spring RabbitMQ
 
Microservices + Events + Docker = A Perfect Trio (dockercon)
Microservices + Events + Docker = A Perfect Trio (dockercon)Microservices + Events + Docker = A Perfect Trio (dockercon)
Microservices + Events + Docker = A Perfect Trio (dockercon)
 
Developing microservices with aggregates (SpringOne platform, #s1p)
Developing microservices with aggregates (SpringOne platform, #s1p)Developing microservices with aggregates (SpringOne platform, #s1p)
Developing microservices with aggregates (SpringOne platform, #s1p)
 
Handling Eventual Consistency in JVM Microservices with Event Sourcing (javao...
Handling Eventual Consistency in JVM Microservices with Event Sourcing (javao...Handling Eventual Consistency in JVM Microservices with Event Sourcing (javao...
Handling Eventual Consistency in JVM Microservices with Event Sourcing (javao...
 
Configuration beyond Java EE 8
Configuration beyond Java EE 8Configuration beyond Java EE 8
Configuration beyond Java EE 8
 
Building Netty Servers
Building Netty ServersBuilding Netty Servers
Building Netty Servers
 
WebRTC with Java
WebRTC with JavaWebRTC with Java
WebRTC with Java
 

Similar to The "Why", "What" and "How" of Microservices

Microservices Architecture
Microservices ArchitectureMicroservices Architecture
Microservices Architecture
Srinivasan Nanduri
 
Introduction to Microservices
Introduction to MicroservicesIntroduction to Microservices
Introduction to Microservices
MahmoudZidan41
 
Concurrency at Scale: Evolution to Micro-Services
Concurrency at Scale:  Evolution to Micro-ServicesConcurrency at Scale:  Evolution to Micro-Services
Concurrency at Scale: Evolution to Micro-Services
Randy Shoup
 
What are microservices
What are microservicesWhat are microservices
What are microservices
Krunalkumar Rajdip
 
Introduction-to-Cloud-Computing.pdf
Introduction-to-Cloud-Computing.pdfIntroduction-to-Cloud-Computing.pdf
Introduction-to-Cloud-Computing.pdf
prajwalalaladinni
 
Microservices vs monolithics betabeers
Microservices vs monolithics   betabeersMicroservices vs monolithics   betabeers
Microservices vs monolithics betabeers
Jesús Mª Villar Vazquez
 
Software Architectures, Week 3 - Microservice-based Architectures
Software Architectures, Week 3 - Microservice-based ArchitecturesSoftware Architectures, Week 3 - Microservice-based Architectures
Software Architectures, Week 3 - Microservice-based Architectures
Angelos Kapsimanis
 
Microservices 101 - The Big Why?
Microservices 101 - The Big Why?Microservices 101 - The Big Why?
Microservices 101 - The Big Why?
Yamen Sader
 
Understanding Microservices
Understanding Microservices Understanding Microservices
Understanding Microservices
M A Hossain Tonu
 
Microservice intro
Microservice introMicroservice intro
Microservice intro
ramesh_sharma
 
Phil Green - We're migrating to the cloud - Who needs service management
Phil Green - We're migrating to the cloud - Who needs service managementPhil Green - We're migrating to the cloud - Who needs service management
Phil Green - We're migrating to the cloud - Who needs service management
itSMF UK
 
MuCon 2015 - Microservices in Integration Architecture
MuCon 2015 - Microservices in Integration ArchitectureMuCon 2015 - Microservices in Integration Architecture
MuCon 2015 - Microservices in Integration Architecture
Kim Clark
 
SOA vs Microservices vs SBA
SOA vs Microservices vs SBASOA vs Microservices vs SBA
SOA vs Microservices vs SBA
Michael Sukachev
 
Architecture - December 2013 - Avinash Ramineni, Shekhar Veumuri
Architecture   - December 2013 - Avinash Ramineni, Shekhar VeumuriArchitecture   - December 2013 - Avinash Ramineni, Shekhar Veumuri
Architecture - December 2013 - Avinash Ramineni, Shekhar Veumuri
clairvoyantllc
 
Software Architecture and Architectors: useless VS valuable
Software Architecture and Architectors: useless VS valuableSoftware Architecture and Architectors: useless VS valuable
Software Architecture and Architectors: useless VS valuable
Comsysto Reply GmbH
 
Iot cloud service v2.0
Iot cloud service v2.0Iot cloud service v2.0
Iot cloud service v2.0
Vinod Wilson
 
Lessions Learned - Service Oriented Architecture
Lessions Learned - Service Oriented Architecture Lessions Learned - Service Oriented Architecture
Lessions Learned - Service Oriented Architecture
Helge Olav Aarstein
 
170215 msa intro
170215 msa intro170215 msa intro
170215 msa intro
Sonic leigh
 
Service Architectures at Scale
Service Architectures at ScaleService Architectures at Scale
Service Architectures at Scale
Randy Shoup
 
Pros & Cons of Microservices Architecture
Pros & Cons of Microservices ArchitecturePros & Cons of Microservices Architecture
Pros & Cons of Microservices Architecture
Ashwini Kuntamukkala
 

Similar to The "Why", "What" and "How" of Microservices (20)

Microservices Architecture
Microservices ArchitectureMicroservices Architecture
Microservices Architecture
 
Introduction to Microservices
Introduction to MicroservicesIntroduction to Microservices
Introduction to Microservices
 
Concurrency at Scale: Evolution to Micro-Services
Concurrency at Scale:  Evolution to Micro-ServicesConcurrency at Scale:  Evolution to Micro-Services
Concurrency at Scale: Evolution to Micro-Services
 
What are microservices
What are microservicesWhat are microservices
What are microservices
 
Introduction-to-Cloud-Computing.pdf
Introduction-to-Cloud-Computing.pdfIntroduction-to-Cloud-Computing.pdf
Introduction-to-Cloud-Computing.pdf
 
Microservices vs monolithics betabeers
Microservices vs monolithics   betabeersMicroservices vs monolithics   betabeers
Microservices vs monolithics betabeers
 
Software Architectures, Week 3 - Microservice-based Architectures
Software Architectures, Week 3 - Microservice-based ArchitecturesSoftware Architectures, Week 3 - Microservice-based Architectures
Software Architectures, Week 3 - Microservice-based Architectures
 
Microservices 101 - The Big Why?
Microservices 101 - The Big Why?Microservices 101 - The Big Why?
Microservices 101 - The Big Why?
 
Understanding Microservices
Understanding Microservices Understanding Microservices
Understanding Microservices
 
Microservice intro
Microservice introMicroservice intro
Microservice intro
 
Phil Green - We're migrating to the cloud - Who needs service management
Phil Green - We're migrating to the cloud - Who needs service managementPhil Green - We're migrating to the cloud - Who needs service management
Phil Green - We're migrating to the cloud - Who needs service management
 
MuCon 2015 - Microservices in Integration Architecture
MuCon 2015 - Microservices in Integration ArchitectureMuCon 2015 - Microservices in Integration Architecture
MuCon 2015 - Microservices in Integration Architecture
 
SOA vs Microservices vs SBA
SOA vs Microservices vs SBASOA vs Microservices vs SBA
SOA vs Microservices vs SBA
 
Architecture - December 2013 - Avinash Ramineni, Shekhar Veumuri
Architecture   - December 2013 - Avinash Ramineni, Shekhar VeumuriArchitecture   - December 2013 - Avinash Ramineni, Shekhar Veumuri
Architecture - December 2013 - Avinash Ramineni, Shekhar Veumuri
 
Software Architecture and Architectors: useless VS valuable
Software Architecture and Architectors: useless VS valuableSoftware Architecture and Architectors: useless VS valuable
Software Architecture and Architectors: useless VS valuable
 
Iot cloud service v2.0
Iot cloud service v2.0Iot cloud service v2.0
Iot cloud service v2.0
 
Lessions Learned - Service Oriented Architecture
Lessions Learned - Service Oriented Architecture Lessions Learned - Service Oriented Architecture
Lessions Learned - Service Oriented Architecture
 
170215 msa intro
170215 msa intro170215 msa intro
170215 msa intro
 
Service Architectures at Scale
Service Architectures at ScaleService Architectures at Scale
Service Architectures at Scale
 
Pros & Cons of Microservices Architecture
Pros & Cons of Microservices ArchitecturePros & Cons of Microservices Architecture
Pros & Cons of Microservices Architecture
 

Recently uploaded

Astute Business Solutions | Oracle Cloud Partner |
Astute Business Solutions | Oracle Cloud Partner |Astute Business Solutions | Oracle Cloud Partner |
Astute Business Solutions | Oracle Cloud Partner |
AstuteBusiness
 
Lee Barnes - Path to Becoming an Effective Test Automation Engineer.pdf
Lee Barnes - Path to Becoming an Effective Test Automation Engineer.pdfLee Barnes - Path to Becoming an Effective Test Automation Engineer.pdf
Lee Barnes - Path to Becoming an Effective Test Automation Engineer.pdf
leebarnesutopia
 
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
Jason Yip
 
The Microsoft 365 Migration Tutorial For Beginner.pptx
The Microsoft 365 Migration Tutorial For Beginner.pptxThe Microsoft 365 Migration Tutorial For Beginner.pptx
The Microsoft 365 Migration Tutorial For Beginner.pptx
operationspcvita
 
Containers & AI - Beauty and the Beast!?!
Containers & AI - Beauty and the Beast!?!Containers & AI - Beauty and the Beast!?!
Containers & AI - Beauty and the Beast!?!
Tobias Schneck
 
Day 2 - Intro to UiPath Studio Fundamentals
Day 2 - Intro to UiPath Studio FundamentalsDay 2 - Intro to UiPath Studio Fundamentals
Day 2 - Intro to UiPath Studio Fundamentals
UiPathCommunity
 
inQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
inQuba Webinar Mastering Customer Journey Management with Dr Graham HillinQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
inQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
LizaNolte
 
JavaLand 2024: Application Development Green Masterplan
JavaLand 2024: Application Development Green MasterplanJavaLand 2024: Application Development Green Masterplan
JavaLand 2024: Application Development Green Masterplan
Miro Wengner
 
A Deep Dive into ScyllaDB's Architecture
A Deep Dive into ScyllaDB's ArchitectureA Deep Dive into ScyllaDB's Architecture
A Deep Dive into ScyllaDB's Architecture
ScyllaDB
 
Northern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving | Modern Metal Trim, Nameplates and Appliance PanelsNorthern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving
 
Getting the Most Out of ScyllaDB Monitoring: ShareChat's Tips
Getting the Most Out of ScyllaDB Monitoring: ShareChat's TipsGetting the Most Out of ScyllaDB Monitoring: ShareChat's Tips
Getting the Most Out of ScyllaDB Monitoring: ShareChat's Tips
ScyllaDB
 
Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving
 
AWS Certified Solutions Architect Associate (SAA-C03)
AWS Certified Solutions Architect Associate (SAA-C03)AWS Certified Solutions Architect Associate (SAA-C03)
AWS Certified Solutions Architect Associate (SAA-C03)
HarpalGohil4
 
QA or the Highway - Component Testing: Bridging the gap between frontend appl...
QA or the Highway - Component Testing: Bridging the gap between frontend appl...QA or the Highway - Component Testing: Bridging the gap between frontend appl...
QA or the Highway - Component Testing: Bridging the gap between frontend appl...
zjhamm304
 
QR Secure: A Hybrid Approach Using Machine Learning and Security Validation F...
QR Secure: A Hybrid Approach Using Machine Learning and Security Validation F...QR Secure: A Hybrid Approach Using Machine Learning and Security Validation F...
QR Secure: A Hybrid Approach Using Machine Learning and Security Validation F...
AlexanderRichford
 
Session 1 - Intro to Robotic Process Automation.pdf
Session 1 - Intro to Robotic Process Automation.pdfSession 1 - Intro to Robotic Process Automation.pdf
Session 1 - Intro to Robotic Process Automation.pdf
UiPathCommunity
 
Y-Combinator seed pitch deck template PP
Y-Combinator seed pitch deck template PPY-Combinator seed pitch deck template PP
Y-Combinator seed pitch deck template PP
c5vrf27qcz
 
Apps Break Data
Apps Break DataApps Break Data
Apps Break Data
Ivo Velitchkov
 
AppSec PNW: Android and iOS Application Security with MobSF
AppSec PNW: Android and iOS Application Security with MobSFAppSec PNW: Android and iOS Application Security with MobSF
AppSec PNW: Android and iOS Application Security with MobSF
Ajin Abraham
 
AI in the Workplace Reskilling, Upskilling, and Future Work.pptx
AI in the Workplace Reskilling, Upskilling, and Future Work.pptxAI in the Workplace Reskilling, Upskilling, and Future Work.pptx
AI in the Workplace Reskilling, Upskilling, and Future Work.pptx
Sunil Jagani
 

Recently uploaded (20)

Astute Business Solutions | Oracle Cloud Partner |
Astute Business Solutions | Oracle Cloud Partner |Astute Business Solutions | Oracle Cloud Partner |
Astute Business Solutions | Oracle Cloud Partner |
 
Lee Barnes - Path to Becoming an Effective Test Automation Engineer.pdf
Lee Barnes - Path to Becoming an Effective Test Automation Engineer.pdfLee Barnes - Path to Becoming an Effective Test Automation Engineer.pdf
Lee Barnes - Path to Becoming an Effective Test Automation Engineer.pdf
 
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
 
The Microsoft 365 Migration Tutorial For Beginner.pptx
The Microsoft 365 Migration Tutorial For Beginner.pptxThe Microsoft 365 Migration Tutorial For Beginner.pptx
The Microsoft 365 Migration Tutorial For Beginner.pptx
 
Containers & AI - Beauty and the Beast!?!
Containers & AI - Beauty and the Beast!?!Containers & AI - Beauty and the Beast!?!
Containers & AI - Beauty and the Beast!?!
 
Day 2 - Intro to UiPath Studio Fundamentals
Day 2 - Intro to UiPath Studio FundamentalsDay 2 - Intro to UiPath Studio Fundamentals
Day 2 - Intro to UiPath Studio Fundamentals
 
inQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
inQuba Webinar Mastering Customer Journey Management with Dr Graham HillinQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
inQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
 
JavaLand 2024: Application Development Green Masterplan
JavaLand 2024: Application Development Green MasterplanJavaLand 2024: Application Development Green Masterplan
JavaLand 2024: Application Development Green Masterplan
 
A Deep Dive into ScyllaDB's Architecture
A Deep Dive into ScyllaDB's ArchitectureA Deep Dive into ScyllaDB's Architecture
A Deep Dive into ScyllaDB's Architecture
 
Northern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving | Modern Metal Trim, Nameplates and Appliance PanelsNorthern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
 
Getting the Most Out of ScyllaDB Monitoring: ShareChat's Tips
Getting the Most Out of ScyllaDB Monitoring: ShareChat's TipsGetting the Most Out of ScyllaDB Monitoring: ShareChat's Tips
Getting the Most Out of ScyllaDB Monitoring: ShareChat's Tips
 
Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024
 
AWS Certified Solutions Architect Associate (SAA-C03)
AWS Certified Solutions Architect Associate (SAA-C03)AWS Certified Solutions Architect Associate (SAA-C03)
AWS Certified Solutions Architect Associate (SAA-C03)
 
QA or the Highway - Component Testing: Bridging the gap between frontend appl...
QA or the Highway - Component Testing: Bridging the gap between frontend appl...QA or the Highway - Component Testing: Bridging the gap between frontend appl...
QA or the Highway - Component Testing: Bridging the gap between frontend appl...
 
QR Secure: A Hybrid Approach Using Machine Learning and Security Validation F...
QR Secure: A Hybrid Approach Using Machine Learning and Security Validation F...QR Secure: A Hybrid Approach Using Machine Learning and Security Validation F...
QR Secure: A Hybrid Approach Using Machine Learning and Security Validation F...
 
Session 1 - Intro to Robotic Process Automation.pdf
Session 1 - Intro to Robotic Process Automation.pdfSession 1 - Intro to Robotic Process Automation.pdf
Session 1 - Intro to Robotic Process Automation.pdf
 
Y-Combinator seed pitch deck template PP
Y-Combinator seed pitch deck template PPY-Combinator seed pitch deck template PP
Y-Combinator seed pitch deck template PP
 
Apps Break Data
Apps Break DataApps Break Data
Apps Break Data
 
AppSec PNW: Android and iOS Application Security with MobSF
AppSec PNW: Android and iOS Application Security with MobSFAppSec PNW: Android and iOS Application Security with MobSF
AppSec PNW: Android and iOS Application Security with MobSF
 
AI in the Workplace Reskilling, Upskilling, and Future Work.pptx
AI in the Workplace Reskilling, Upskilling, and Future Work.pptxAI in the Workplace Reskilling, Upskilling, and Future Work.pptx
AI in the Workplace Reskilling, Upskilling, and Future Work.pptx
 

The "Why", "What" and "How" of Microservices

  • 1. The “Why”, “What” and “How” of Microservices Jeppe Cramon - @jeppec Chief Architect - INPAY
  • 2. WHY WOULD WE WANT TO USE MICROSERVICES? And what are the alternatives?
  • 3. Cost of Software Development • The 60/60 rule* • The cost of software maintenance consumes 40%-80% (60 % in average) • Of this, 60% is consumed by enhancements • And only 17% is consumed by error corrections * "Frequently Forgotten Fundamental Facts about Software Engineering" by Robert L. Glass, IEEE Software May/June 2001
  • 4. What are the sources of enhancements? • New business requirements • Changed processes (e.g. direct booking) • Changed calculations (new pricing models) • New features (space yield) • New corporate strategies • Ability to sell individual “components” of our application • Management decisions to purchase 3rd party applications • Upgrades/replacement to existing 3rd party systems • Replacing existing functionality in our application with new components/systems (e.g. best of breed or golf course deals)
  • 5. ARCHITECTURE IS ESSENTIAL Because it influences how fast we can respond to changes and what the cost of those changes are
  • 6. ULTIMATELY WE WANT TO BE ABLE TO ADAPT TO CHANGES IN A CONSTANT AMOUNT OF TIME
  • 7. E.G. IF YOUR PRICING MODEL WAS WRONG – YOU SHOULD BE ABLE TO CHANGE IT IN HOURS/DAYS AND REDEPLOY
  • 8. SOME ORGANIZATIONS CALCULATE CHANGE TIMES IN MONTHS OR YEARS
  • 9. WE ALL WANT TO MOVE FAST But can’t always move fast - for various reasons…
  • 10. WHAT IS THE MAIN TECHNICAL, BUSINESS AND ARCHITECTURAL IMPEDIMENT TO OBTAINING HIGH VELOCITY?
  • 11. High Coupling • Coupling is a measure of dependencies: • Efferent coupling – who do you depend on • Afferent coupling – who depends on you • 4 different aspects on coupling: • Temporal coupling (processing time of Y affects X – if Y is down can X continue?) • Platform coupling (e.g. using platform specific protocols) • Spatial coupling (where on the network are the Y instances and how does X know?) • Behavioral coupling (how much about Y’s behavior does X understand) X Y
  • 12. Coupling Coupling is a challenge when you want to makes changes
  • 13. The playing field Zero coupling The Enterprise Canonical model
  • 14. Coupling causes ripple effect – much like circles in the water • You want to change a little thing and all of a sudden you need to change 25 other seemingly unrelated things • Zero coupling is impossible • Question is what is the right level of coupling? • This highly depends on how likely the component/system/service is it to change and what parts that change together
  • 15. It starts simple “The” DB UI Logic Data Access
  • 16. Next step is spaghetti in layers
  • 17. And often we end up with a Big Ball Of Mud
  • 19. AS AN UMBRELLA NAME WE CALL THESE SYSTEMS MONOLITHS Which roughly translates to mean that they deployed as one unit
  • 20. Characteristics of a monolith? • Often an indivisible unit • Hard to adapt to new technology • Low Reusability • Functionality of a part cannot be reused alone • Slow Delivery train • Introducing a new feature often requires coordination with other features to deliver all of them at the same time • Higher and higher maintenance cost over time • Change to control flow is often hard • Starting the application often takes a long time • Testing the application often takes a long time • Forces high requirements on mental capacity to keep the entire monolith in your head • Tends to grow bigger and bigger and bigger • Reliability • When one thing fails => potentially everything fails (e.g. due to OutOfMemoryException)
  • 21. MONOLITHS ARE UNFAIRLY CATEGORIZED AS BEING BAD Many of the problems mentioned before can be solved using design principles that we will investigate in this talk
  • 22. Advantages of Monolith • Can take advantage of locality: • In memory calls and avoid distributed transactions • Can perform Joins with other components SQL tables • Can take advantage of development IDE’s • Refactoring • Code completion • Code searching • Less spinning wheels • Less deployment and monitoring requirements
  • 25. To many this is SOA Data Storage Data Storage Data Storage Data Service Data Service Data Service Activity Service Activity Service Process Service Process Service Client Client Client Data Service If one service is down, you risk everything is down
  • 26. Classic Service reuse multiplies our direct and especially indirect dependencies which creates high coupling My new Service that wants to reuse other services Service that is going to be reused Another Service that is going to be reused Reusable Service Reusable Service Reusable Service Reusable Service Reusable Service DB service
  • 27. The cost/benefit of reuse • Layered SOA has typically been recommended because it increases reuse • Really, this is use and not reuse. • Use results in more coupling • The thesis is that the more we reuse, the faster we will be done • But the thesis rest on the false assumption that writing code is the most expensive part of a project • Not all code takes the same amount of time to write. Some code is very trivial while other code is very hard to write • The real money and time consumers on any project are: • Figuring out what the customer needs • The time it takes for the customer to figure what they really needed and the resulting rework • Meetings • UI, Integration work, databases, webservices • Fix bugs • Debugging • Deployment • Test • Ship Yes No Failed ? The more dependencies we have, the worse this is and the more expensive it becomes
  • 28. Where to go? • Monoliths easily result in: • Tight coupling • Slow release train - All or nothing deployment • Low reusability • Reliability issues • SOA done traditionally easily result in: • A hard coupled architecture due to reusability and integration patterns • Both runtime (temporally) and design time (contracts) • Performance issues • Reliability issues • Slow release train – requires a lot of governance • High latency (2 way remote communication) • High accidental complexity • Compensations due to lack of transactions • ESB’s to try and hide the mess
  • 29. ARE MICROSERVICES THE SOLUTION? Next question: What are Microservices?
  • 30. SOME SAY A MICROSERVICE IS THE SAME AS A SOA SERVICE – JUST SMALLER That of course requires us to answer what a Service is ;-)
  • 31. THE FINE-GRAINED, STATELESS, SELF- CONTAINED NATURE OF MICROSERVICES CREATES DECOUPLING BETWEEN DIFFERENT PARTS OF A CODE BASE AND IS WHAT MAKES THEM EASY TO UPDATE, REPLACE, REMOVE, OR AUGMENT. Microservices: The resurgence of SOA principles and an alternative to the monolith
  • 32. IT SEEMS THE ARGUMENT IS THAT JUST BY MAKING THINGS FINE GRAINED We by magic achieve decoupling
  • 33. Let’s transform our monolith to microservices “The” DB UI Logic Microservices Data Access Microservices UI-3 MS-3 MS-C UI-2 MS-D UI-4 MS-4MS-2 MS-B MS-E UI-1 UI-5 MS-5MS-1 MS-A
  • 34. THERE IS VALUE IN MAKING THINGS SMALLER For one thing it is easier to reason about them in isolation
  • 35. Going small has its advantages Monolith Microservice Microservice Microservice MicroserviceMicroservice Microservice Microservice
  • 36. HOW SMALL SHOULD A MICROSERVICE BE?
  • 37. BUT I’VE HEARD THAT A “MICROSERVICE SHOULD BE NO LARGER THAN 100 LINES OF CODE!?”
  • 38. SIZE THIS AND SIZE THAT! BE CAREFUL If Microservices are good, then Nanoservices must be even better? Why not one-liner services?
  • 41. Nano Services Unless we have a very good reason for doing so, we risk building services that are so fine-grained that their costs outweigh their utility* *Read Arnon Rotem-Gal-Oz’s Nano Services Anti Pattern:http://arnon.me/wp-content/uploads/2010/10/Nanoservices.pdf
  • 42. IS YOUR MICROSERVICE VALUABLE? The value of a microservice must exceed the cost of building & operating it. Microservices entail costs for serializations, deserializations, security, communication, maintenance, configuration, deployment, monitoring, etc.
  • 43. FOR NOW ON WE WILL USE SERVICE AND MICROSERVICE INTERCHANGEABLY A Service CAN be broken into smaller parts, but let’s leave that out of the discussion for now…
  • 44. Too small services With too small services there’s a big risk that what’s left of coherence goes out the window and we get: • Communication-related and Layered coupling • E.g. Logic and persistence are not the same service • Temporal coupling • Our service can not operate if it is unable to communicate with the services it depends upon • Behavioral coupling • Our services assume behaviors with regards to what and who. • The sender/client determines what to do and knows something about how the receiver/server should satisfy the request
  • 46. Microservices == distributed objects? Service star chart
  • 47. Microservice characteristics • Small • Single Responsibility Principle (SRP) • Own process • Valuable • Replaceable/Upgradeable • Autonomous • Independent • Encapsulated • Composable • Testable • Fast startup/shutdown • Client friendly
  • 48. SRP This sounds really good but what about cross Service relationships? Customer Orders Products
  • 49. BEWARE… When we break up big things into small pieces we invariably push the complexity to their interaction. Michael Feathers https://michaelfeathers.silvrback.com/microservices-until-macro-complexity
  • 50. Let’s zoom in on the data tier MS-A “The” DB MS-C MS-D MS-B MS-E
  • 51. IF OUR MONOLITHS CODE IS COUPLED AND MESSY Chances are that the data(base) model is equally coupled and messy
  • 52. We start with a simple model
  • 53. And as time goes by…
  • 54. It gets more and more complicated
  • 55. And finally we drown
  • 56. AND WE END UP WITH ONE DOMAIN MODEL TO RULE THEM ALL
  • 57. THE MENTAL CAPACITY REQUIRED TO UNDERSTAND THIS DOMAIN MODEL IS HUGE
  • 58. TO UNDERSTAND ANY PART IN ISOLATION, REQUIRES YOU TO UNDERSTAND THE ENTIRE MODEL AS EVERYTHING IS COUPLED TO EACH OTHER
  • 59. Side effect: Our queries get messy
  • 60. Let’s refactor the data tier UI Logic Microservices Data Access Microservices UI-3 MS-3 MS-C UI-2 MS-D UI-4 MS-4MS-2 MS-B MS-E UI-1 UI-5 MS-5MS-1 MS-A A’s DB B’s DB C’s DB D’s DB E’s DB MS-C MS-D MS-B MS-E MS-A A’s DB B’s DB C’s DB D’s DB E’s DB
  • 61. THIS IS ALSO KNOWN AS A DISTRIBUTED MONOLITH
  • 62. Things that are not Services • A Service with only functionality (and no data) is a FUNCTION • Like: check if order is valid • A Service that only has data is a DATABASE • Like: Entity CRUD • A database already has a nice API - we don’t need to bubble wrap it with REST or Asynchronous messages • Don’t split the atom – we need cohesion as well as decoupling! • If we want datastore abstraction (so we can swap out Postgresql with Mongo or Redis) there this little pattern called Respository. This is typically seen in a lot of layered SOA usages where a function calls a function that calls a function that calls a database
  • 63. 4 tenets of Service Orientation 1. Services share contract and schema, not class or type • Encapsulation improved. We need not worry about how things are implemented (languages or platform dependent information) 2. Service interaction is controlled by a policy • Controls the rules/form of technical communication between services take place (e.g. using encryption incl. algorithm and keys) 3. Services have explicit boundaries • A Service is defined by its Boundary • What is on the inside and which is on the outside ownership wise (data and logic) • A boundary tells us what parts make up the service and how the service interacts with the outside world (as defined by the service contract – see point 1 and 2). • The internal implementation and platform of a Service (what’s inside the boundary) is irrelevant 4. Services are autonomous • Encapsulation & Cohesion at a bigger scale. • A service is autonomous if it doesn’t rely on other services to complete its job • A service can be rewritten, redeployed and replaced without interfering with other services as long as schema/contracts are upheld
  • 64. This is different from Functions & Components • Functions are very intimately linked with code that uses them • Components form a higher modularization level than functions • But they’re still intimate with the application they’re added to • Services are yet another modularization level than components. • They’re standalone, own their own data and are loosely coupled to their surroundings
  • 65. Let’s refactor the “microservices” UI Microservices UI-3 MS-3 UI-2 UI-4 MS-4MS-2 UI-1 UI-5 MS-5MS-1 1’s DB 2’s DB 3’s DB 4’s DB 5’s DB
  • 66. Reality rears it’s ugly head out
  • 67. WHAT’S WRONG WITH USING RPC/REST/… BETWEEN SERVICES?
  • 68. Synchronous calls lower our tolerance for faults • When you get an IO error • When servers crash or restarts • When databases are down • When deadlocks occurs in our databases • Do you retry? With synchronous style Service interaction we can loose business data, there’s no automatic retry or we risk creating data more than once because idempotence* often is an after though 68 Client Server Duplicated Response Duplicated Request Processing Response Request Processing The same message can be processed more than once *Idempotence describes the quality of an operation in which result and state does not change if the operation is performed more than 1 time
  • 69.
  • 70. Also remember: REST isn’t magic!
  • 71. SOA PRINCIPLE SERVICES ARE AUTONOMOUS Autonomy means that our service is independent and self- contained and as far as possible doesn’t directly depend on other services to be functional.
  • 73. SERVICES ARE AUTONOMOUS For a service to be autonomous is MUST own its data Shipping DB
  • 74. SERVICES ARE AUTONOMOUS For a service to be autonomous is must NOT share state
  • 75. SERVICES ARE AUTONOMOUS Autonomy is essential for Scalability (scale out clustering) Reliability (fail over clustering)
  • 76. SERVICES ARE AUTONOMOUS Autonomy is essential for Reusability Adaptability
  • 77. Clarification of Autonomy vs. Authority Definition of Autonomy A service is autonomous if it doesn’t directly depend on another application to complete its work. It can determine on its own what to do. Definition of Authority A service is the authority if other services needs to ask it for data or instruct it to perform a task on their behalf for them to complete their job Autonomy Authority
  • 78. IF WE KEEP UP THE SAME HABITS THAT RESULTED IN MESSY MONOLITHS We will end up with microservice spaghetti!
  • 79. Monolith A Monolith B Monolith C Monolith D Service A.1 Service A.2 Service A.3 Service A.4 Service B.1 Service B.2 Service B.3 Service B.4 Service D.1 Service D.4 Service D.3 Service D.2 Service C.4 Service C.3 Service C.2 Service C.1 DB DB DB DB Service transformation
  • 81. IF WE CONTINUE DOWN THIS PATH WE HAVE GONE FROM BAD TO WORSE
  • 82. THIS MEANS THAT WE NEED TO TAKE CARE OF HOW WE DESIGN OUR DATA MODELS & THEREBY OUR SERVICE BOUNDARIES
  • 83. GUIDANCE CAN BE FOUND IN Pat Hellands “Life Beyond Distributed Transactions? An Apostate ‘s Opinion” Link: http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf
  • 84. Life Beyond Distributed Transactions? According to Pat Helland, we must find the solution to our problem by looking at: 1. How do we split our data / services 2. How do we identify our data 3. How do we communicate between our services
  • 85. 1. How do we split our data / services Data must be collected in pieces called aggregates. These aggregates should be limited in size (but not smaller), so that, after a transaction they are consistent. Rule of thumb: One transaction involves only one aggregate.
  • 86. DOMAIN DRIVEN DESIGN The term Aggregate comes from DDD
  • 87. Aggregates Invoice InvoiceLine * Account * What: • Cluster coherent Entities and Value Objects, with complex associations into Aggregates with well defined boundaries. • Choose one entity to be root and control access to objects inside the boundary through the root. • External objects hold references to the root • Aggregates only refer to other aggregates by identity (their id) Motivation: Control invariants and consistency through the aggregate root. Enables: Loading schemes, coarse grained locking and… Ensuring consistency & transactional boundaries for Distributed scenarios Root * *
  • 88. THE SMALLEST SERVICE Would be responsible for all logic and data related to a single Aggregate
  • 89. WHY? Because consistency can only be guaranteed with in an Aggregate It cannot span aggregates due to lack of coordinating transactions
  • 90. Example of bad aggregate boundaries
  • 91. In this case we can fix it All use cases shows that LegalEntity and Address are created, changed and deleted together Parent - Child
  • 92. An improved aggregate design Address turned out to NOT be an Entity LegalEntity is an Entity and forms the Root of our LegalEntity aggregate
  • 93. THIS GIVES US THIS RULE OF THUMB 1 use case = 1 transaction = 1 aggregate
  • 94. With this improved design “Client” that wants to use our LegalEntity Service LegalEntity Service
  • 95. 2. How do we identify our data According to Pat Helland we need to be able to uniquely identify each Aggregate using an ID. • This ID will usually a UUID/GUID • Aggregates refer to each other by their ID • they NEVER use memory pointers, join tables or remote calls {21EC2020-3AEA-4069-A2DD-08002B30309D} 2122 (approximately 5.3×1036) combinations
  • 96. WE STILL HAVEN’T CONQUERED THE TEMPORAL COUPLING PROBLEM
  • 97. 3. How we communicate between our services • What do we do when our use case involves more than one aggregate and therefore likely more than one service?
  • 98. WITH CROSS SERVICE INTEGRATION WE’RE BOUND BY THE LAWS OF DISTRIBUTED COMPUTING
  • 99. The 8 Fallacies of Distributed Computing These fallacies are assumptions architects, designers and developers of distributed systems are likely to make. The fallacies will be proven wrong in the long run - resulting in all sorts of troubles and pains for the solution and architects who made the assumptions. 1. The network is reliable. 2. Latency is zero. 3. Bandwidth is infinite. 4. The network is secure. 5. Topology doesn't change. 6. There is one administrator. 7. Transport cost is zero. 8. The network is homogeneous. See http://www.rgoarchitects.com/Files/fallacies.pdf for a walkthrough of the fallacies and why they’re fallacies
  • 100. A DISTRIBUTED SYSTEM IS ONE WHERE A MACHINE I’VE NEVER HEARD OF CAN CAUSE MY PROGRAM TO FAIL. — Leslie Lamport
  • 101. 2 WAY (SYNCHRONOUS) COMMUNICATION IS THE ROOT OF MANY PROBLEMS BECAUSE IT CREATES A STRONG TEMPORAL COUPLING (AS WELL AS BEHAVIORAL COUPLING) Substituting synchronous with synchronous- over-asynchronous doesn’t solve the core problem
  • 102. Change Address Response Consumer Change Address Request Provider RPC or Request/Response - Synchronous 2 way communication Remote Procedure Call Request/Reply – Asynchronous 2 way communication Consumer Provider Change Address Request Change Address Request Change Address Reply Change Address Reply Request Channel Reply Channel VS.
  • 103. THE PROBLEM ISN’T SO MUCH SYNCHRONOUS VS ASYNCHRONOUS The question is it two-way or one-way communication and what’s the use case (e.g. is there a user sitting and waiting)
  • 104. Essential complexity of 2 way integration Component C Compnent B Component A UI Service Service B:Service() call C:Service() call A:Service() commit() Service Local transaction between System A, B and C
  • 105. Accidental complexity from 2 way style integration Component C Component B System A UI Service Service Service Local transaction between System B and C B:Service() call C:Service() call A:Service() if (A:Call-Failed:Too-Busy?) Wait-A-While() call A:Service() if (A:Call-Failed:Too-Busy?) Wait-A-Little-While-Longer() call A:Service() if (A:Call-Failed:IO-Error?) Save-We-Need-Check-If-Call-A-Succeded-After-All AND We-Need-To-Retry call C:Service and call B:Service AND Tell-Customer-That-This-Operation-Perhaps-Went-Well if (A:Call-Went-Well?) commit()
  • 106. HOW CAN WE ENSURE CONSISTENCY WHEN WE’RE GOING DISTRIBUTED? Can’t we just use distributed transactions? (XA / 2 phase commit)
  • 107. Distributed Transactions…. Oh my Sales system Sales Delivery system Deliveries Customer/C RM system Customer SAP Book- keeping Complete Purchase Transaction Coordinator Transactional Resource Prepare Phase Commit Phase 2 Phase Commit
  • 108. What’s wrong with distributed transactions? • Transactions lock resources while active • Services are autonomous • Can’t be expected to finish within a certain time interval • Locking keeps other transactions from completing their job • Locking doesn’t scale • And what about timeouts? • X Phase Commit is fragile by design
  • 109. THIS IS ACCIDENTAL COMPLEXITY DUE TO DISTRIBUTION We’re essential handling the problem the worst possible way
  • 110. THIS FORM OF COORDINATED INTEGRATION BETWEEN MULTIPLE SERVICES IS KNOWN AS ORCHESTRATION
  • 111. Consequence: Availability goes down (without additional instances of each service) Service A Service B Service C Availability: 99% Availability: 99% Availability: 99% Combined availability: 97%
  • 112. Synchronous calls are the crystal meth of programming At first you make good progress but then the sheer horror becomes evident when you realise the scalability limitations and how the brittleness holds back both performance and development flexibility. By then it is too late to save. http://www.infoq.com/news/2014/10/thompson-reactive-manifesto-2 We need the reactive properties and then apply protocols for the message interactions. Without considering the protocols of interaction this world of micro-services will become a coordination nightmare. Martin Thompson
  • 113. DECIDE IF YOU CAN LIVE WITH THE CONSEQUENCES OF COUPLING SERVICES TO EACH OTHER USING REQUEST/RESPONSE Different situations – different tradeoffs
  • 114. HOW TO GET LOOSE COUPLING BETWEEN SERVICES? It highly depends on how you integrate them
  • 116. IF WE WANT TO DECOUPLE OUR SERVICES AS MUCH AS POSSIBLE THEN WE NEED TO LOOK TOWARDS COMPOSITE UI’S AND EVENTS
  • 117. WHAT’S A COMPOSITE UI A Composite UI is a way to allow different services to participate an applications UI without revealing their internals and thereby removing the need for other services to know the this services internal data This helps us keep coupling low and encapsulation high
  • 118. Applications • Applications are tailored solutions for certain groups of users. Example • Departments will typically have UI’s tailed to the responsibility of a department (which often cut across Service responsibilities) • Managers which see different reports from all areas of a company • Sales representatives which have solutions that sometimes can work in offline mode • Customers using e.g. Android/iOS apps to access their portfolio / home-banking / appointments / etc.
  • 119. Applications and Services iOS Homebanking Call center support portal Bank Backoffice application Customer information service Legal and contract information service Accounts service Credit card service Mortgage loans service
  • 120. Who owns the UI? • For a service to be fully autonomous is must be self contained – which means it must: • Own its UI • Own its Business Logic • Own its Data model & storage User interface Business Logic Data model & storage Service A similar approach is available under the name Self Contained Systems http://scs-architecture.org/
  • 121. If a Service doesn’t own its UI we often find the need for a Gateway or Backend For a Frontend (BFF) • Experience shows if you get your Service API wrong the first time around, it is really expensive to fix it* • The granularity of APIs provided by microservices is often different than what a client needs* * See http://thenewstack.io/microservices-calls-robust-api-management-tools/
  • 122. Gateway or Backend For a Frontend (BFF) • Unfortunately Gateways & BFF’s introduce a lot of coupling between the Gateway and the underlying services • If an underlying service changes its contract in a non-backwards compatible way the gateway needs to change • In these cases the clients of the gateway may also need to change since the changes can permeate upwards (the gateway abstraction is leaky) * See http://thenewstack.io/microservices-calls-robust-api-management-tools/
  • 123. Gateway/BFFGateway/BFF GATEWAY OR BACKEND FOR A FRONTEND UI Microservices UI-3 MS-3 UI-2 UI-4 MS-4MS-2 UI-1 UI-5 MS-5MS-1 1’s DB 2’s DB 3’s DB 4’s DB 5’s DB Gateway/BFF
  • 124. Application UI’s • An applications is a composition of different services • The composition can be: • Resource Oriented Client Architecture (ROCA) style service integration (http://roca-style.org/) • Mashup of Service UI components in a dedicated Application – aka. Composite UI Both solutions involve integration via Services web interfaces to minimize coupling to other services. Image from http://scs-architecture.org/
  • 125. ROCA style integration Simple hyperlinks can be used to navigate between services UI’s. Image from http://scs-architecture.org/
  • 126. ROCA style integration A redirection can be used to ensure navigation works in both directions. Image from http://scs-architecture.org/
  • 127. ROCA style integration Hyperlinks can also support the dynamic inclusion of content that is served by another application into the web interface of a service. Image from http://scs-architecture.org/
  • 128. Composite UI - example Page Context: { type: Book, id: ISBN-10 0-321-83457-7 } ImageService BookService ReviewService PriceService InventoryService OthersAlsoBoughtService PriceService ReviewService BookService ImageService BookService
  • 129. A SERVICE OWNS IT UI IN ALL CONTEXTS AND FOR ALL COMPOSITE UI’S Not just for HTML clients
  • 130. Invoice Composite UI example InvoiceHeader Order:ShippingI nfo Invoice: InvoiceNumber Invoice: Data and Due date Order: RelationInformation Order:Item- Qty Product:Ite m Product: Description Order: Item-Unit-Price Order: Item- Total- Price Order:Total Billing:Balance All Services participate at the UI level for each individual Item in the Order
  • 131. Coupling matrix* * Modified version of Ian Robinson’s matrix: http://iansrobinson.com/2009/04/27/temporal-and-behavioural-coupling/ Behavioral coupling Temporal coupling Low High Low High Event oriented Command oriented Emergency services Distributed 3 layer
  • 132. TO BREAK TEMPORAL COUPLING & BEHAVIORAL COUPLING SERVICES NEEDS TO COMMUNICATE ASYNCHROUSLY USING BUSINESS EVENTS MESSAGES Services communicate facts without making assumptions about what other services intend to do with the events
  • 133. Let’s make the implicit explicit! Old wisdom seems to have been forgotten. Let’s introduce: Domain Events Which: • Signal that something has happened • Closely aligned to the Domain Model • Are handled by a messaging system • They are in the past tense: • CustomerBilled • ParcelShipped • CustomerCreated • ReviewCreated • CommentAdded • CommentDeleted
  • 134. Event Message An Event message is non-prescriptive of what should happen in other services. It leaves this open to the recipients, so that they themselves determine what to do based on occurrence of the event. Events always carry a name in its past-tense form: OrderWasAccepted, OrderHasShipped, CustomerWasReimbursed Other qualities • Immutable, i.e. content cannot be changed • Always carries the ID of the Aggregate it relates to • An event can and will typically will be published to multiple consumers. • The publisher of the event does not know who the recipients are • And it doesn’t know what the recipients intend to do with the event • The service issuing the Event is the owner of the Event contract “An Event describes something that HAS happened”
  • 135. Business Event as XML Message <OrderWasAccepted> <CustomerId>50D1F244-ABBC-4EC7-BDCA-E4934C124A89</CustomerId> <OrderId>C199322A-01F1-4E56-918E-7A63529F8FA3</OrderId> <ShippingAddress> ... </ShippingAddress> <BillingAddress> ... </BillingAddress> <Items> <Item ProductId="4CD22C4B-600C-4477-B5BF-48ABDEE4DA61" Amount="100" AmountUnit="Pieces" UnitPrice="100,10" UnitCurrency="EUR"/> <Item ProductId="56E6BD19-660C-464A-9120-100DAF579855" Amount="10" AmountUnit="Litres" UnitPrice="56,95" UnitCurrency="CHF"/> </Items> </OrderWasAccepted>
  • 136. Business Event as JSON Message { EventType: "OrderWasAccepted", CustomerId: "50D1F244-ABBC-4EC7-BDCA-E4934C124A89", OrderId: "C199322A-01F1-4E56-918E-7A63529F8FA3", ShippingAddress: { ... } BillingAddress: { ... } Items: [ { ProductId: "4CD22C4B-600C-4477-B5BF-48ABDEE4DA61", Amount: "100", AmountUnit: "Pieces", UnitPrice: "100,10", UnitCurrency: "EUR" }, { ProductId: "56E6BD19-660C-464A-9120-100DAF579855", Amount: "10", AmountUnit: "Litres", UnitPrice: "56,95", UnitCurrency: "CHF" } ] }
  • 137. Events are often the side effect of Commands A Command message is prescriptive of what should happen. This is a stronger form of coupling than Events. A Command’s primary goal is to capture USER INTENT A Command supports a single usecase and targets a single Aggregate Commands always carry a name in its imperative form: CreateOrder, ShipOrder, CancelOrder, ReimburseCustomer, etc. Other qualities • Immutable, i.e. content cannot be changed • Always carries the ID of the Business Object that it relates to • A command can only be handled by ONE service • The Operations that consume Commands don’t return values – but can throw exceptions • Therefore Commands should be handled using 2 way communication, so the exception can be communicated back to the sender “A command describes a Task that you want someone else to carry out for you and the recipient can reject the Command”
  • 138. Commands & Events Commands mutate Aggregate/Business Object state which results in one or more Events being published Command Event(s) AcceptOrder OrderAccepted ShipOrder OrderShipped AddComment CommentAdded QuarantineReview ReviewQuarantined UnquarantineReview ReviewUnquarantined
  • 139. EVENT MESSAGES SHOULD BE SEND USING One way communication
  • 140. One way Messaging • One way messaging is asynchronous and breaks temporal coupling • Messages can be exchanged between services over a message channel • The Message channel is responsible for delivering the message(s) to the relevant parties (consumers). If something goes wrong, the message will be put back on the Message channel (rollback) and will be resent later* Sender Address Changed Event Receiver Address Changed Event Channel Asynchronous Communication – Aka Messaging * This is smart pipes and “dumb” endpoints – An alternative is dumb pipes and smart endpoints
  • 141. SPLITTING INTO SMALLER AND MORE FOCUSED SERVICES HAS MANY ADVANTAGES But it leaves us with the challenge on what to do when processes span multiple services
  • 142. THE CHANGE OF FOCUS FROM TECHNICAL SHORT TRANSACTIONS To long running business transactions
  • 143. BUSINESS EVENTS MESSAGES AND BUSINESS PROCESSES By publishing Events messages from our Services we can communicate with each other and also drive Business Processes 143
  • 144. This form of architecture is called an Event Driven Architecture (EDA)
  • 145. SOA AND EDA ARE TWO SIDES OF THE SAME COIN
  • 146. Using Business Events to drive Business Processes Sales Service Shipping Billing Sales Customers MessageChannel Online Ordering System Web Shop (Composite UI) Billing Service Shipping Service Order Accepted Event AcceptOrder Command The sales fulfillment processing can now begin…
  • 147. Business Events example Sales Service Order Accepted Billing Service Online Ordering System Order Accepted Customer Billed MessageChannel We use the Order Accepted event message published from the Sales Service to drive the Billing of the customer. The billing part of the process also use Business Events, in this case Customer Billed Event, to indicate that its part of the process is completed. Because we use asynchronous messaging we can still accept orders in the sales service even though the invoicing services is down. The Order Accepted event message will remain in the Message Channel until the Billing Service is ready to process it.
  • 148. What about race conditions? • Usually they are a natural part of the business and needs to be considered as a natural part of the process – technology and 2 Phase Commit wont solve this* • This challenges how we look at the process • Based on the questions we ask ourselves • And what we promise customers • Example: • Is it really not possible to purchase Taxfree even though the seating system doesn’t know our booking or concrete seating? • This is known as being causally consistent (a level of eventual consistent) * See http://www.udidahan.com/2010/08/31/race-conditions-dont-exist/
  • 149. Eventual consistency can be our friend • Consistency is within each Service • Eventual consistency is between Services • Like in the real world Sales Invoicing Inventory Shipping Order Accepted Invoice Customer Checks Inventory for availability Books truck driver Order Packaged Fetch Package from Inventory Customer Invoiced
  • 150. IMPORTANT! Figure out who owns the process
  • 151. Choreographed Event Driven Processes Online Ordering System Sales Service Order Accepted Invoicing Service Order Fulfilment (Saga/ Process-Manager) Shipping Service MessageChannel Order Accepted Order Accepted Customer Billed Customer Billed Order Approved Order Approved Works as a Finite State Machine (WorkFlow) handling the life cycle of Shipping and thereby forms a very central new Aggregate in the System
  • 152. Process Managers • Process Managers are essential to the coordination and monitoring of long running business processes/transactions • They work as a Finite State Machines (WorkFlow) which handling the life cycle of Process (e.g. Shipping an Order) and thereby forms a very central new Aggregate in the System • They can include manual steps/person intervention • Sometimes these Process Managers belong naturally within a specific Business capability and other times they are truly a thing by themselves and therefore often form a new business capabilities Many companies derive their competitive advantages from their Processes. A Process Manager allows you coordinate Business Processes on the basis of Events
  • 153. Choreography is very different from the classical orchestrated integration process
  • 154. What should Events look like? • Keep Events Small • Only include relevant information (time, id’s unless you use events for duplication) • If possible, don’t include unnecessary id’s for aggregates in other services • Think Inverse relationships based on what feels most natural • Order doesn’t need to know the Shipping Id, but Shipping can know the Order Id • Anchor Events to Time • Include information about how long you can trust the Event’s change • E.g. a price is valid until 8pm tomorrow night • Reveal the intention and time anchoring as part of the Events name
  • 155. The INPAY approach to Microservices
  • 157. Many perspectives on data Online Retail System Product Unit Price Promotional Price Promotion End Date Stock Keeping Unit (SKU) Quantity On Hand (QOH) Location Code Price Quantity Ordered Name The lifecycle of the data is VERY important! Customer Pricing Inventory Sales Management Reporting
  • 158. Different perspectives on entities With in a given Domain, e.g. Retail, there will exist multiple bounded contexts/sub-domains/business capabilities such as: • Product management • Purchase • Sales • Pricing • Inventory • Shipping • Support • Accounting • Management Each of these lines of business have very specific and unique needs which are relevant for them alone in order to conduct their business. They might use the same name for the entities they’re interested in or they might use different names for the same logical entity.
  • 159. Smaller models & clear data ownership Retail System Pricing Product ProductID Unit Price Promotional Price … Pricing Inventory Product ProductID SKU QOH Location Code … Inventory Sales Product ProductID Name Description Quantity Ordered … Sales Shared Entity identitySOA: Service
  • 161. These splits should be fairly small (but not too small) and share as little as possible with each other Sales Pricing InventoryShipping ✕ ✕ ✕
  • 162. What’s a macro architecture • It’s the static/stable(r) parts of your architecture • Which are very costly to refactor and change • Business capabilities are stable • Therefore we should strive to align services with business capabilities / bounded contexts (DDD)
  • 163. BOUNDED CONTEXT The setting in which a word or a statement appears that determines its meaning Ensures that our is clear and precise
  • 164. DDD DOESN’T ENFORCE PROBLEM DOMAIN AND SOLUTION DOMAIN ALIGNMENT FOR BOUNDED CONTEXTS Which is why we prefer to use the term Business Capability
  • 165. Service and Business Capability alignment “The advantage of business capabilities is their remarkable level of stability. If we take a typical insurance organisation, it will likely have sales, marketing, policy administration, claims management, risk assessment, billing, payments, customer service, human resource management, rate management, document management, channel management, commissions management, compliance, IT support and human task management capabilities. In fact, any insurance organisation will very likely have many of these capabilities.” See http://bill-poole.blogspot.dk/2008/07/business- capabilities.html
  • 166. A Service is • The technical authority for a given business capability • It is the owner of all the data and business rules that support this business capability – everywhere (including the UI) • It forms a single source of truth for that capability • This form of business and IT alignment ensures that we can maintain service Autonomy & Encapsulation
  • 169. Services, Applications and code • Each Service and Application is maintained within its own Git repository • Common IT Operations libraries and infrastructure are maintained in separate Git repositories
  • 170. So what’s inside a Service source repository? • Autonomous Components • Libraries • Adapters • Front-end UI components • API contracts (mostly Events) • Schemas • Build file(s)
  • 172. Service and deployment • A Service represents a logical responsibility boundary • Logical responsibility and physical deployment of a Service DOES NOT have to be 1-to-1 • It’s too constraining • We need more degrees of freedom • Philippe Krutchen 4+1 views of architecture: Logical and Physical designs should be independent of each other A service needs to be deployed everywhere its data is needed
  • 173. Service deployment • Many services can be deployed to the same physical server • Many services can be deployed in the same application • Application boundary is a Process boundary which is a physical boundary • A Service is a logical boundary • Service deployment is not restricted to tiers either • Part of service A and B can be deployed to the Web tier • Another part of Service A and B can be deployed to the backend/app-service tier of the same application • The same service can be deployed to multiple tiers / multiple applications • ie. applications and services are not the same and does not share the same boundaries • Multiple services can be “deployed” to the same UI page (service mashup) • Multiple services can cooperate to fulfill a use-case (e.g. a workflow or a business process)
  • 174. Service Autonomous Component 1..* Is implemented by A Service is the technical authority of a specific Business Capability e.g. Sales, Shipping, Billing Services support business processes. Business processes naturally span multiple services, but there will always be a single service that is the actual authority on the business process. Service vs Autonomous Components
  • 175. Also known as Microservices Service Autonomous Component 1..* Is implemented by Service vs Autonomous Components Autonomous-Components/Microservices are a division of Services along Transactional boundaries (a transaction stays within the boundary of a Microservice) Microservices are the individually logical deployable units of a Service with their own Endpoints. Could e.g. be the split between Read and Write models (CQRS) - each would be their own Microservice
  • 176. Services are the corner stone • We talk in terms of Services/business capabilities and the processes/use- cases they support • Autonomous-Components/Microservices are an implementation detail • They are much less stable (which is a good thing – it means they’re easier to replace) • With regards to other Services • subscribe to events from • send commands to (less common) • call operations (in rare occasions)
  • 177. Where does that leave Systems? • Systems and Services are in my opinion the same • For a service to be autonomous is must be self contained – which means it must: • Own its UI • Own its Business Logic • Own its Data model & storage • Which is similar to how Self Contained Systems are/were build User interface Business Logic Data model & storage Service / System
  • 178. Services/Bounded Contexts and Aggregates Sales Service PSP ServiceVirtual Banking Service Finance Service Customer customerId … Contract contractId customerId … VBFeeSchedule contractId … PSPFeeSchedule contractId … BillingTemplate contractId …
  • 179. INPAY Autonomous Component design principles
  • 181. Commands and Events public class RegisterBankCmd extends AbstractCommand { @TargetAggregateIdentifier public final BankId bankId; public final String name; public final Country countryOfOperation; public RegisterBankCmd(BankId bankId, String name, Country countryOfOperation) { Objects.requireNonNull(bankId, "bankId"); Objects.requireNonNull(name, "name"); Objects.requireNonNull(countryOfOperation, "countryOfOperation"); this.bankId = bankId; this.name = name; this.countryOfOperation = countryOfOperation; } }
  • 182. Commands and Events The generic business event interface includes the name of the topic that subscribers must use public class BankRegistered extends AbstractEvent implements BankEvent { @AggregateIdentifier public final BankId bankId; public final String name; public final Country countryOfOperation; public BankCreated(BankId bankId, String name, Country countryOfOperation) { this.bankId = bankId; this.name = name; this.countryOfOperation = countryOfOperation; } } public interface BankEvent extends Serializable { TopicName TOPIC_NAME = BankingServiceId.ID.topicName("bank-events"); }
  • 183. CQRS A single model cannot be appropriate for reporting, searching and transactional behavior Greg Young, 2008
  • 184. Query/Read models • To offload the Aggregate models, i.e. the transactional write model, we introduce the concept of Read Models • Query/Read Models are projections of one or more Aggregate models which store and represent data in the best possible way for the given Query use cases UI Application Domain Write model Commands – Change data UI Application Read models Queries – Ask for data (no side effects)
  • 185. Commands, Events and Query Models Read model Read model Events UI Domain modelQuery/Read model ”AcceptOrder” command ”OrderAccepted” event ”Find all Accepted Orders” Query Commands are Imperative: DoStuff Events are Past tense: StuffDone
  • 186. CQRS Building blocks Client Commands Command Bus Sends Command Handlers Modify Repositories Read Write Data store Event Bus Command Autonomous Components Event Handlers Events Read store Query HandlersQuery Results Queries Query/Read Model Autonomous Components Events Domain
  • 187. Event Sourcing Aggregates track their own Domain Events and derive state from them Time 07:39 Time 07:40 Time 07:41 Time 07:45 Time 07:46 Time 07:50
  • 188. Relational Database EventStore example Time 07:39 Time 07:40 Time 07:41 Time 07:45 Time 07:46 Time 07:50 Type Aggregate Identifier Sequence Number Timestamp Event Identifier EventType SerializedEvent Order 14237 0 2014-01-06 7:39 {Guid-1} OrderCreated <serialized event>… Order 14237 1 2014-01-06 7:40 {Guid-2} ProductAdded <serialized event>… Order 14237 2 2014-01-06 7:41 {Guid-3} ProductAdded <serialized event>… Order 14237 3 2014-01-06 7:45 {Guid-4} ProductRemoved <serialized event>… Order 14237 4 2014-01-06 7:46 {Guid-5} ProductAdded <serialized event>… Order 14237 5 2014-01-06 7:50 {Guid-6} OrderAccepted <serialized event>… Order 14238 0 2014-01-07 9:10 {Guid-X} OrderCreated <serialized event>… DomainEvents Table
  • 189. Event Replaying Type Aggregate Identifier Sequence Number Timestamp Event Identifier EventType SerializedEvent Order 14237 0 2014-01-06 7:39 {Guid-1} OrderCreated <serialized event>… Order 14237 1 2014-01-06 7:40 {Guid-2} ProductAdded <serialized event>… Order 14237 2 2014-01-06 7:41 {Guid-3} ProductAdded <serialized event>… Order 14237 3 2014-01-06 7:45 {Guid-4} ProductRemoved <serialized event>… Order 14237 4 2014-01-06 7:46 {Guid-5} ProductAdded <serialized event>… Order 14237 5 2014-01-06 7:50 {Guid-6} OrderAccepted <serialized event>… Order Accepted: false
  • 190. Event Replaying Type Aggregate Identifier Sequence Number Timestamp Event Identifier EventType SerializedEvent Order 14237 0 2014-01-06 7:39 {Guid-1} OrderCreated <serialized event>… Order 14237 1 2014-01-06 7:40 {Guid-2} ProductAdded <serialized event>… Order 14237 2 2014-01-06 7:41 {Guid-3} ProductAdded <serialized event>… Order 14237 3 2014-01-06 7:45 {Guid-4} ProductRemoved <serialized event>… Order 14237 4 2014-01-06 7:46 {Guid-5} ProductAdded <serialized event>… Order 14237 5 2014-01-06 7:50 {Guid-6} OrderAccepted <serialized event>… Order Orderline Accepted: false
  • 191. Event Replaying Type Aggregate Identifier Sequence Number Timestamp Event Identifier EventType SerializedEvent Order 14237 0 2014-01-06 7:39 {Guid-1} OrderCreated <serialized event>… Order 14237 1 2014-01-06 7:40 {Guid-2} ProductAdded <serialized event>… Order 14237 2 2014-01-06 7:41 {Guid-3} ProductAdded <serialized event>… Order 14237 3 2014-01-06 7:45 {Guid-4} ProductRemoved <serialized event>… Order 14237 4 2014-01-06 7:46 {Guid-5} ProductAdded <serialized event>… Order 14237 5 2014-01-06 7:50 {Guid-6} OrderAccepted <serialized event>… Order Orderline Orderline Accepted: false
  • 192. Event Replaying Type Aggregate Identifier Sequence Number Timestamp Event Identifier EventType SerializedEvent Order 14237 0 2014-01-06 7:39 {Guid-1} OrderCreated <serialized event>… Order 14237 1 2014-01-06 7:40 {Guid-2} ProductAdded <serialized event>… Order 14237 2 2014-01-06 7:41 {Guid-3} ProductAdded <serialized event>… Order 14237 3 2014-01-06 7:45 {Guid-4} ProductRemoved <serialized event>… Order 14237 4 2014-01-06 7:46 {Guid-5} ProductAdded <serialized event>… Order 14237 5 2014-01-06 7:50 {Guid-6} OrderAccepted <serialized event>… Order Orderline Accepted: false
  • 193. Event Replaying Type Aggregate Identifier Sequence Number Timestamp Event Identifier EventType SerializedEvent Order 14237 0 2014-01-06 7:39 {Guid-1} OrderCreated <serialized event>… Order 14237 1 2014-01-06 7:40 {Guid-2} ProductAdded <serialized event>… Order 14237 2 2014-01-06 7:41 {Guid-3} ProductAdded <serialized event>… Order 14237 3 2014-01-06 7:45 {Guid-4} ProductRemoved <serialized event>… Order 14237 4 2014-01-06 7:46 {Guid-5} ProductAdded <serialized event>… Order 14237 5 2014-01-06 7:50 {Guid-6} OrderAccepted <serialized event>… Order Orderline Orderline Accepted: false
  • 194. Event Replaying Type Aggregate Identifier Sequence Number Timestamp Event Identifier EventType SerializedEvent Order 14237 0 2014-01-06 7:39 {Guid-1} OrderCreated <serialized event>… Order 14237 1 2014-01-06 7:40 {Guid-2} ProductAdded <serialized event>… Order 14237 2 2014-01-06 7:41 {Guid-3} ProductAdded <serialized event>… Order 14237 3 2014-01-06 7:45 {Guid-4} ProductRemoved <serialized event>… Order 14237 4 2014-01-06 7:46 {Guid-5} ProductAdded <serialized event>… Order 14237 5 2014-01-06 7:50 {Guid-6} OrderAccepted <serialized event>… Order Orderline Orderline Accepted: true
  • 195. Snapshotting Type Aggregate Identifier Latest Sequence Number Timestamp Serialized Aggregate Order 14237 4 2014-01-06 7:46 <serialized aggregate>… Product 15918 1 2014-01-07 7:40 <serialized aggregate>… Type Aggregate Identifier Sequence Number Timestamp Event Identifier EventType SerializedEvent Order 14237 0 2014-01-06 7:39 {Guid-1} OrderCreated <serialized event>… Order 14237 1 2014-01-06 7:40 {Guid-2} ProductAdded <serialized event>… Order 14237 2 2014-01-06 7:41 {Guid-3} ProductAdded <serialized event>… Order 14237 3 2014-01-06 7:45 {Guid-4} ProductRemoved <serialized event>… Order 14237 4 2014-01-06 7:46 {Guid-5} ProductAdded <serialized event>… Order 14237 5 2014-01-06 7:50 {Guid-6} OrderAccepted <serialized event>… Snapshot Table Domain Events Table
  • 196. Full CQRS With EventSourcing UI Domain Event Store (can e.g. be a real EventStore DB or a Relational DB) Commands – Change data Commands Events SQL DB Document DB Graph DB UI Data Queries – Ask for data Events Query Build Our single source of truth
  • 197. Aggregate public class Bank extends InPayEventSourcedAggregate { @AggregateIdentifier private BankId bankId; @EventSourcedMember private Map<BankAccountId, BankAccount> bankAccounts = new HashMap<>(); public Bank(BankId bankId, String name, Country countryOfOperation) { apply(new BankRegistered(bankId, name, countryOfOperation)); } public void addBankAccount(BankAccountId bankAccountId, …) { if (!bankAccounts.containsKey(bankAccountId)) { apply(new BankAccountAdded(bankId, bankAccountId, …)); } } @EventSourcingHandler private void on(BankRegistered e) { bankId = e.getBankId(); } @EventSourcingHandler private void on(BankAccountAdded e) { BankAccount bankAccount = bankAccounts.put(e.getBankAccountId(), new BankAccount(e.getBankId(), e.getBankAccountId(), …)); } }
  • 198. Service project structure sales_service sales_api sales_contract_ac sales_customer_ac frontend sales_contract_manager_adapters contract adapters sales/modules customer psp_service psp_api psp_fees_ac … frontend psp_contract_manager_adapters fees adapters psp/modules fx Legend: Service/Business-Capability External Event/Command Contracts Autonomous Component Autonomous Component Adapter Angular.js Module Builds into a Java JAR Uses Spring MVC/REST All Java 8 artifacts are built using Gradle
  • 199. Autonomous Component • Can be deployed alone or co-located • Usually deployed together with one or more adapters • Works transparently in a clustered environment • Completely Spring free  • Only depends on our Core infrastructure library • Common types and Id’s • Bus infrastructure • Service lookup • CQRS building blocks (backed by Axon framework)
  • 200. AC in code public class PSPAgreementAc extends HzBackedAutonomousComponent { public static AutonomousComponentId SERVICE_AC_ID = PSP_SERVICE_ID.ac("psp_agreement_ac"); … public PSPAgreementAc(CurrencyConverter currencyConverter) { this.currencyConverter = currencyConverter; } @Override public void onInitialize(IConfigureACEnvironment acSetup) { acSetup.withAutonomousComponentId(SERVICE_AC_ID).usingServiceDataSource() .withBusConfiguration(cfg -> { cfg.getAxonContext() .subscribeAnnotatedCommandHandler(new TemplateCmdHandler( cfg.getAxonContext().eventSourcedRepository(PSPTemplate.class), currencyConverter)); …. manageLifecycleFor(templateViewRepository = new TemplateViewRepository(cfg, currencyConverter)); }) .runOnBusStartup((bus, axonContext) -> { bus.registerAxonReplayableTopicPublisher(InternalTemplateEvents.TOPIC_NAME, replayFromAggregate(PSPTemplate.class) .dispatchAggregateEventsOfType(InternalTemplateEvents.class)); bus.subscribeTopic(SERVICE_AC_ID.topicSubscriber("ContractEvents"), ExternalContractEvents.TOPIC_NAME, new SalesTopicSubscription(bus)); }); } public TemplateViewRepository getTemplateViewRepository() { return templateViewRepository; } }
  • 201. Distributed in memory views public class PSPFeeScheduleViewRepository extends HzBackedDataRepository<ContractId, PSPFeeScheduleView> implements Lifecycle { private final Bus bus; private Subscription subscription; public PSPFeeScheduleViewRepository(HazelcastInstance hazelcastInstance, String serviceId, Bus bus) { super(hazelcastInstance, serviceId); this.bus = bus; } @Override public void start() { subscription = bus.subscribeTopic(TopicSubscription.FromBeginning(PSPFeeScheduleAc.SERVICE_AC_ID.subscriberId("-FeeScheduleView"), PSPFeeScheduleRelated.TOPIC_NAME), new BusMessageHandlerDelegator<>(this)); } @Override public void shutdown() { if (subscription != null)subscription.cancel(); } public PSPFeeScheduleView load(ContractId contractId) { final PSPFeeScheduleView payOutFeeScheduleView = cache.get(contractId); if (payOutFeeScheduleView == null) throw new ValidationException(PSPFeeScheduleMessages.feeScheduleDoesNotExist.validationMsg(contractId)); return payOutFeeScheduleView; } @BusMessagePayloadHandler private void on(PSPFeeScheduleCreated event) { cache.put(event.contractId, new PSPFeeScheduleView(event)); } @BusMessagePayloadHandler private void on(PSPFeeScheduleDiscarded event) { cache.remove(event.contractId); } ... }
  • 203. The core of the infrastructure • It’s the core infrastructure that allows services/AC’s to communicate using messages using our Federated Bus. • This means we don’t need to deploy any Message Brokers (such as RabbitMQ, ActiveMQ) – the Bus supports: • Broadcast • Notifications • Non durable Queues • Durable Queues • Non-durable Topics
  • 204. psp_fees_ac (deployed on 10.25.26.102) psp_fees_ac (deployed on 10.25.26.101) Bus Bus Bus Bus sales_contract_ac (deployed on 10.25.26.104) sales_contract_ac (deployed on 10.25.26.103) Federated Bus
  • 206. Non-durable Topics and Client handled subscriptions • Highly resilient pattern for an Event Driven Architecture that’s backed by AC’s that use EventSourcing. • In this model the publisher of the Events is responsible for the durability of all its Events, typically to an EventStore/EventLog. • Each client (subscriber) maintains durable information of the last event it received from each publisher. • When ever the client starts up it makes a subscription to the publisher where it states from which point in time it wants events published. • This effectively means that publisher can remain simple and the client (subscriber) can remain simple and we don’t need additional sophisticated broker infrastructure such as Kafka+ZooKeeper.
  • 207. Client handled subscriptions Publisher Subscriber A Local storage EventStore Subscriber B Local storage Topic Subscription Topic Subscription TopicSubscriptionHandler TopicSubscriptionHandler EventEvent Event Event EventBus Event Event
  • 209. AUTONOMOUS-COMPONENTS/ MICROSERVICES ARE LOGICAL DEPLOYABLE UNITS That doesn’t mean they HAVE to be deployed individually. Design for Distribution But take advantage of locality
  • 211. Autonomous Components can be co-deployed together with Application backends contract_manager (Spring Boot fat–jar) sales_contract_ac sales_customer_ac sales_contract_manager_adapters psp_api psp_fees_ac psp_contract_manager_adapters frontend sales_api app libs contract customer fees
  • 212. Application in code @Configuration @ComponentScan(basePackages = { "com.inpay.contractmanager", "com.inpay.adapters", "com.inpay.itops.spring" }) public class Application extends InpaySpringBootApplication { public Application() { super(); } @Override protected String getApplicationName() { return "ContractManager"; } @Override protected Collection<AutonomousComponent> getAutonomousComponentsHostedInThisApplication() { CurrencyExchangeRateAc currencyExchangeRateAc = new CurrencyExchangeRateAc(); return list( new IDMCoreAc(), new PSPFeeScheduleAc(currencyExchangeRateAc.getCurrencyConverter()), new VBFeeScheduleAc(currencyExchangeRateAc.getCurrencyConverter()), new ContractAc(), new CustomersAc(), currencyExchangeRateAc ); } public static void main(String[] args) { SpringApplication.run(Application.class, args); } }
  • 213. What about Security/Identity management (IDM)? • That’s an AC as well, belonging to IT operations • Technical security belongs with IDM • May this caller call this endpoint • Is this User authenticated • Simple Authorization: Does this User have Privilege A, B and C • Business related Authorization belongs in the designated Business ACs • May this user approve a Contract with Fees below X, Y and Z
  • 214. Security and Applications @ComponentScan(basePackages = { "com.inpay.contractmanager", "com.inpay.adapters", "com.inpay.itops.spring" })
  • 215. AC, autonomy and “shared” data Service DB DB Autonomous Component Autonomous Component Autonomous Component Autonomous Component DB
  • 216. 50 shades of AC Autonomy* Endpoint Process Database Storage Shared Shared Shared Shared Own Shared Shared Shared Own Own Shared Shared Own Shared Own Shared Own Own Own Shared Own Own Own Own Lower Autonomy Higher Autonomy * No RPC in use!
  • 219. Service A Service B Service C IT-OPS Application App Application App logic (Layered, CQRS,…) lication Storage UI Components Services & Composite UI’s
  • 220. Widget Widget Page Widget Service A Service B Service C Widget Widget Widget Service A Service B Service C Widget Service C • Overall structure of the page is “owned” by the application. • Each widget and the view model it binds to is delivered by the underlying Service. Page layout
  • 221. AngularJS as Composite UI Framework • Misko Hevery – Don’t fight HTML, extend it! • For our purpose each widget maps naturally to a directive. • AngularJS is modular in nature which aligns nicely with our needs having multiple Services taking part in an application.
  • 222. Angular Controllers & Services (1 of 2) • An angular service is normally responsible for gathering and posting data to the back-end. • There will be at least one angular service per Service that participates in the application • In angular a service is injected in a controller. Not vice versa. • Yet application in/output must be coordinated in some way through the services • In angular controllers are NOT singletons. • Each directive get its own instance of a controller, meaning there are numerous controller instances at playWhat are the consequences of this with regards to a composite UI? • An angular service is normally responsible for gathering and posting data to the back-end. • There will be at least one angular service per Service that participates in the application • In angular a service is injected in a controller. Not vice versa. • Yet application in/output must be coordinated in some way through the services • In angular controllers are NOT singletons. • Each directive get its own instance of a controller, meaning there are numerous controller instances at play
  • 223. Angular Controllers & Services (2 of 2) • Gathering and posting data through angular services needs to happen in a coordinated manner. • Client side events • The controllers instantiated through directives needs to be kept in sync and caution must be made to avoid numerous round-trips to the backend Services • There is a need to have a controller that drives the overall use-case for a single page. The application page controller. • The application page controller must not know the data structure of any of the participating angular services. • Gathering and posting data through angular services needs to happen in a coordinated manner. • Client side events • The controllers instantiated through directives needs to be kept in sync and caution must be made to avoid numerous round-trips to the backend Services • There is a need to have a controller that drives the overall use-case for a single page. The application page controller. • The application page controller must not know the data structure of any of the participating angular services.
  • 224. Application Startup • Client-side event subscription • Enrolling for client-side distributed post operations
  • 225. Page Rendering Example Page Ctrl Sales Service UI Broker Customer Service Pricing Service Product Service Page Widget Ctrl Widget Ctrl Widget Ctrl Widget Ctrl Widget Ctrl Widget Ctrl Widget Ctrl Widget Ctrl 1. Backend API Backend API Backend API Backend API 2. 3. 4. 5. 5. 6. 7. 7. 7. 7. 5. 8. 8. 8. 8.