Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Microservices
SOA reminded of what it
was supposed to deliver?
Jeppe Cramon - @jeppec
L&B Faglig Fredag - May 2015
SOA or Microservices?
Better ROI, More Security, Fewer Defects,
Reusable assets, Better Maintainability, More
reuse, Bette...
For years no one talked about
SOA
Mostly because of the many failures…
Example:
I've used service-oriented architecture fo...
In my opinion SOA is not to
blame for the disappointment
Perhaps
you’re holding it wrong?
Actually what is SOA?
Is this SOA?
Webshop Order Management
CRM ERP
Customer data
Product data
Or is this SOA?
ERP
Webshop Order Management
CRM
ESB
What is an architecture?
It’s the
• Overall macroscopic system structure
– How responsibilities are assigned and divided
–...
Architecture is essential
Because it influences how fast
we can respond to changes and
what the cost of these changes
are
Spaghetti SOA?
Webshop Order Management
CRM ERP
Customer data
Product data
Spaghetti integration can
result in a lot of accidental
complexity
Because we’re bound by the
rules of distributed computing
Essential complexity of local component
integration
CBA
UI
Service Service
B:Service()
call C:Service()
call A:Service()
...
B:Service()
call C:Service()
call A:Service()
if (A:Call-Failed?)
call A:Service()
if (A:Call-Failed?)
Wait-A-While()
cal...
If we can, we should fight to
avoid this complexity
Why?
Cost of Software Development
• The 60/60 rule*
• The cost of software maintenance
consumes 40%-80% (60 % in average)
– Of ...
There’s a big risk that
enhancements permeate into
multiple systems
(because systems often overlap
with regards to respons...
What are the sources of
enhancements?
• New business requirements
– Changed processes
– Changed calculations
– New feature...
So what does this have to do
with Microservices?
I believe that Microservices is a
welcome opportunity to brush off
the dust from SOA, (re)learn form
the past and perhaps ...
Beware of
sales pitches
The fine-grained, stateless, self-
contained nature of
microservices creates decoupling
between different parts of a code
...
Trying hard to pretend
it’s not difficult to develop distributed systems
It seems the argument is that just
by making things fine grained
We by magic achieve decoupling
Decoupled?
Source: https://qconsf.com/system/files/presentation-slides/QConSF-MicroServices-IPC-Netflix-Sudhir-2014.pptx
Monoliths are often blamed for being
the the cause of all our problems due
to hidden coupling
And microservices are claime...
Monoliths start simple
“The” DB
UI
Logic
Data Access
Next step is spaghetti in layers
And finally we drown
Characteristics of a monolith
• Hard to adapt to new technology
• Low Reusability
– Functionality of a part cannot be reus...
If we keep up the same habits
that resulted in messy
monoliths
What’s makes us think that we
won’t end up with
Question
Microservice spaghetti?
Most “Services” today are built
on top of Monoliths
Monolith A Monolith B
Monolith C Monolith D
Service
A.1
Service
A.2
Se...
Monolith A Monolith B
Monolith C Monolith D
So if we create naïve
microservices
Service
A.1
Service
A.2
Service
A.3
Servic...
Then we’ve IMO just gone from
bad
To Worse
So does that mean that breaking
things apart is a bad thing?
Definitely NOT!
But we need some guidelines to
avoid things becoming messy
(once again)
So how do we get there?
Let’s look at some of the
characteristics of Microservices
(that most seem to agree upon)
Microservice characteristics
• Single Responsibility Principle (SRP)
• Small
• Own process
• Valuable
• Replaceable
• Upgr...
Single Responsibility Principle
(SRP)
Billing
DB
Order Fulfillment
DB
SMS Gateway
Shipping
DB
Management
Reporting
DB
A Mi...
So how big/small should a
microservice/responsibility be?
Does a Microservice own its
data?
• Remember layered SOA?
Layered SOA
Data
Storage
Data
Storage
Data
Storage
Data
Service
Data
Service
Data
Service
Activity
Service
Activity
Servic...
Does a Microservice own its
data?
• Remember layered SOA?
• IMO a service that only deals with data
persistence is best ca...
What’s the right size?
I’ve heard that a
“Microservice should be no larger
than 100 Lines of Code!?”
Bad programmers worry about the code.
Good programmers worry about data structures and their relationships
Linus Thorvald
Bad programmers worry about microservices code size. Good
programmers worry about their data ownership and relationships
J...
Enough with the size!
When did we get away from solving
business problems and start
talking technology, JSON over XML,
RES...
It reminds me of the early SOA
days
All that was talked about then was which ESB
to purchase, to how set it up, etc.
No bo...
We kind of forgot that
SOA was about business
agility
It was too much
“Build it and they will come”
There is value in making
things smaller
For one thing it easier to reason
about them in isolation
Going small has its advantages
Source: @aviranm
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 Feat...
Should we replace joins with
RPC?
Synchronous calls
are the crystal meth of
programmingAt first you make good progress but then the sheer
horror becomes evi...
Size this and Size that!
Be Careful
If Microservices are good, then
Nanoservices must be even
better?
Why not one-liner se...
Nano Services
Unless we have a very reason for doing so,
we risk building services
that are so fine-grained
that their cos...
Microservices are valuable
The value of a microservice must
exceed the cost of building &
operating it.
Microservices enta...
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...
Microservices == distributed
objects?
Service star chart
Service Dependencies
Source: https://qconsf.com/system/files/presentation-slides/QConSF-MicroServices-IPC-Netflix-Sudhir-2...
All of this means that we need to
take care of how we design our
service boundaries
Guidance can e.g. be found in
Pat Hellands
“Life Beyond Distributed
Transactions? An Apostate ‘s
Opinion”
Link: http://www...
Life Beyond Distributed
Transactions?
According to Pat Helland, we must find the
solution to our problem by looking at:
1....
1. How do we split our data /
services
Data must be collected in pieces called
entities. These entities should be limited ...
What can we learn from DDD
DDD has a similar concept called
Aggregate
Aggregates
Invoice
InvoiceLine
*
Account *
What:
• Cluster coherent Entities and Value Objects, with
complex associations ...
Aggregate is another name
for an Entity
Pat Hellands “Entity” is the same as
DDD’s “Aggregate” concept
By adopting DDD’s t...
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...
Example of bad aggregate
boundaries
In this case we can fix it
All use cases shows that
LegalEntity and Address are
created and delete 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
Leg...
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...
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
therefor...
What about using
RPC/REST/…?
We can just make it async or?
Change Address Response
Consumer
Change Address Request
Provider
RPC or Request/Response - Synchronous 2 way communica
Rem...
Synchronous Remote Calls
can lower our Fault tolerance
• When servers crashes
• When databases are down
• When deadlocks o...
Also remember: REST isn’t
magic!
Also, what’s less fat – XML or
JSON?
• They’re equally slim and fast!
• http://balisage.net/Proceedings/vol10/html/
Lee01/...
RPC and Distributed computing
• As soon as a service request/response
calls to another service across the
network we must ...
Service autonomy
Service
B
Service
C
Service
A
System X
Service
A
System Y
Service
B
Service
C
System X
Slow/unreliable ne...
A distributed system is one where
a machine I’ve never heard of
can cause my program to fail.
— Leslie Lamport
Availability goes down
(without additional instances of each service)
Service
A
Service
B
Service
C
Availability: 99% Avai...
Decide if you can live with the
consequences of coupling
services to each other using
Request/Response
Different situation...
To break things up
We need to understand our business
and its processes
-
How is data flowing?
In order to build the right
boundaries
Claim
Most of us are trained to think in Entities and
Structural models and this is where we get our selves
into trouble.
...
The mental capacity required to
understand big domain models
is huge
Many perspectives on data
Online Retail System
Product
Unit Price
Promotional Price
Promotion End Date
Stock Keeping Unit ...
Different perspectives on
entities
With in a given Domain, e.g. Retail, there will exist multiple bounded
contexts/sub-dom...
Billing
Bounded
Context
Product
Catalogue
Bounded
Context
Shipping
Bounded
Context
Sales
Bounded
Context
Inventory
Bounded...
These splits should be fairly small
(but not too small)
and share as little as possible with each other
Sales Pricing Inve...
What’s a macro architecture
• It’s the static/stable(r) parts of your
architecture
– Which are very costly to refactor and...
DDD doesn’t enforce
problem domain and solution
domain alignment for Bounded
Contexts
Which is why I prefer to use the
ter...
Service and Business Capability
alignment
“The advantage of business capabilities is their
remarkable level of stability. ...
Don’t split into services too
early
Cross boundary refactoring is
costly
So what is a Service?
A Service is
• The technical authority for a given business
capability
• It is the owner of all the data and business
rule...
Does a Service own its UI?
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 in the UI without revealing their...
Composite UI’s require that
the Service owns its UI
A Service contains all parts related to it
in order to minimize coupling to other
services
DB
Schema
Domain
Services
Appli...
Composite UI’s
Retail System
Sales Pricing Inventory
Web/Application
tier
Background server
tier
Storage tier
Composite UI...
Composite UI - example
Context:
Book
ISBN-10 0-321-83457-7
Composite UI - example
Page Context:
{ type: Book, id: ISBN-10 0-321-83457-7 }
ImageService
BookService
ReviewService
Pric...
Composite UI - HTML
#DIV – Book:Reviews
#DIV – Book:Image
#DIV – Book:TitleAndAuthor
#DIV – Book:Pricing
#DIV – Book:Avail...
Conceptual View
The Service owns it UI in all
Contexts and for all Composite
UI’s
Not just for HTML clients
Why?
Because of System/Application
boundaries cross Business
Capabilities
Physical service view
Application X Application Y
UI
Service A
UI
Service B
UI
Service B
UI
Service C
UI
Service C
Data
Ca...
Service deployment
• Many services can be deployed in the same system/application/process
– Process boundary is a physical...
Invoice Composite UI example
InvoiceHeader
Order:ShippingIn
fo
Invoice:
InvoiceNo
Invoice:
Data and Due
date
Order:
Relati...
So where does that leave
microservices?
Service implementation
• A Service represents a logical boundary
• Logical responsibility and physical
deployment of a ser...
Service
Service Microservice
1..*
Is implemented by
A Service is the technical authority
of a specific Business Capability...
Service
Service Microservice
1..*
Is implemented by
Microservices are a division of Services along Transactional boundarie...
Microservices are logical
deployable units
That doesn’t mean they HAVE to be deployed
individually.
Design for Distributio...
Services are the corner stone
• We talk in terms of services, business
capabilities and the processes/usecases they
suppor...
Coupling matrix*
* Modified version of Ian Robinson’s matrix: http://iansrobinson.com/2009/04/27/temporal-and-behavioural-...
Using Business Events to drive
Business Processes
Sales Service
Shipping
Billing
Sales
Customers
Bus
Online Ordering Syste...
Cascading events give rise to
business processes
Event driven process
Sales Service
Order
Accepted
Billing Service
Orderfulfilment Service
Process Manager/
Saga/
Orchestra...
This form of architecture is called
an
Event Driven Architecture (EDA)
SOA and EDA are two sides of
the same coin
SOA Analysis Patterns
How do we determine service
boundaries?
Recommendation: Divide and
concour
• Start from the outside and model business
capabilities
• Design your Macro Architectu...
How do I model?
For example: Event Storming
• Event Storming is a fun way of driving
your analysis from the outside and quickly
explore co...
SOA was about business
agility through IT/Business
alignment
Final thoughts
Doing SOA require maturity
• Organizational maturity
Be aware of Conways Law
“organizations which design systems ... are
constrained to produce designs which are
copies of the...
Which require maturity
• Organizational maturity
• Technical/operations maturity* – DevOps
– Build
– Test
– Deployment
– M...
We need a strong foundation for development to
achieve this
AlignmentHighlyalignedLessaligned
EffciencyLess effective High...
So are Microservices the
future?
Gartners Pace layered Application strategy:
• Systems of Record — Established packaged ap...
Conclusions
• In my opinion Microservices is a SOA delivery model
• Focus should be on aligning Services to Business Capab...
Thank you 
Jeppe Cramon – jeppe@tigerteam.dk
www.tigerteam.dk
www.tigerteam.dk/category/soa/
www.tigerteam.dk/category/so...
(Long version) Microservices - SOA reminded of what it was supposed to deliver
(Long version) Microservices - SOA reminded of what it was supposed to deliver
Nächste SlideShare
Wird geladen in …5
×

(Long version) Microservices - SOA reminded of what it was supposed to deliver

1.676 Aufrufe

Veröffentlicht am

Are Microservices really something new and different, or is just SOA as it was intended or are they just distributed objects revived?

What are the qualities of microservices, how can we determine the right size for a service, what are the consequences of our service integration patterns, what's the difference between the logical and physical views of a service, what's the risks and potential benefits?

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

(Long version) Microservices - SOA reminded of what it was supposed to deliver

  1. 1. Microservices SOA reminded of what it was supposed to deliver? Jeppe Cramon - @jeppec L&B Faglig Fredag - May 2015
  2. 2. SOA or Microservices? Better ROI, More Security, Fewer Defects, Reusable assets, Better Maintainability, More reuse, Better parallelism in development, Better scalability, Higher availability…. … building blocks that can be reused and tweaked as needed. There’s also a redundancy benefit: Should one … fail the other ones will work in the app. Higher reusability, significant reduction of development cost, increased reliability, improved maintainability, enhanced quality…
  3. 3. For years no one talked about SOA Mostly because of the many failures… Example: I've used service-oriented architecture for the better part of a decade, and I can honestly report the following … Source: http://www.techrepublic.com/blog/tech-decision-maker/the-unfulfilled-promise-of-soa/ • I have never seen the "contract" feature of any service I've written or designed be leveraged to enable its re-use • I have never seen a service from one system be recoupled to another • I have never seen encapsulated logic used in multiple applications
  4. 4. In my opinion SOA is not to blame for the disappointment
  5. 5. Perhaps you’re holding it wrong?
  6. 6. Actually what is SOA?
  7. 7. Is this SOA? Webshop Order Management CRM ERP Customer data Product data
  8. 8. Or is this SOA? ERP Webshop Order Management CRM ESB
  9. 9. What is an architecture? It’s the • Overall macroscopic system structure – How responsibilities are assigned and divided – How connectors can be placed between systems – Principles for connectors
  10. 10. Architecture is essential Because it influences how fast we can respond to changes and what the cost of these changes are
  11. 11. Spaghetti SOA? Webshop Order Management CRM ERP Customer data Product data
  12. 12. Spaghetti integration can result in a lot of accidental complexity
  13. 13. Because we’re bound by the rules of distributed computing
  14. 14. Essential complexity of local component integration CBA UI Service Service B:Service() call C:Service() call A:Service() commit() Service Local transaction between A, B and C
  15. 15. B:Service() call C:Service() call A:Service() if (A:Call-Failed?) call A:Service() if (A:Call-Failed?) Wait-A-While() call A:Service() if (A:Call-Failed-Due-To-IO?) 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() Accidental complexity from distributed integrations CBA UI Service Service Service Local transaction between B and C
  16. 16. If we can, we should fight to avoid this complexity Why?
  17. 17. 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
  18. 18. There’s a big risk that enhancements permeate into multiple systems (because systems often overlap with regards to responsibilities)
  19. 19. What are the sources of enhancements? • New business requirements – Changed processes – Changed calculations – New features – New corporate strategies – Ability to sell individual “components” of our systems • 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) • Mergers • Golf course deals • …
  20. 20. So what does this have to do with Microservices?
  21. 21. I believe that Microservices is a welcome opportunity to brush off the dust from SOA, (re)learn form the past and perhaps improve going forward
  22. 22. Beware of sales pitches
  23. 23. 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
  24. 24. Trying hard to pretend it’s not difficult to develop distributed systems
  25. 25. It seems the argument is that just by making things fine grained We by magic achieve decoupling
  26. 26. Decoupled? Source: https://qconsf.com/system/files/presentation-slides/QConSF-MicroServices-IPC-Netflix-Sudhir-2014.pptx
  27. 27. Monoliths are often blamed for being the the cause of all our problems due to hidden coupling And microservices are claimed to be the solution
  28. 28. Monoliths start simple “The” DB UI Logic Data Access
  29. 29. Next step is spaghetti in layers
  30. 30. And finally we drown
  31. 31. Characteristics of a monolith • 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 • Low Reliability – When one thing fails => potentially everything fails (e.g. due to OutOfMemoryException)
  32. 32. If we keep up the same habits that resulted in messy monoliths What’s makes us think that we won’t end up with Question
  33. 33. Microservice spaghetti?
  34. 34. Most “Services” today are built on top of Monoliths 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
  35. 35. Monolith A Monolith B Monolith C Monolith D So if we create naïve microservices 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
  36. 36. Then we’ve IMO just gone from bad
  37. 37. To Worse
  38. 38. So does that mean that breaking things apart is a bad thing?
  39. 39. Definitely NOT! But we need some guidelines to avoid things becoming messy (once again)
  40. 40. So how do we get there? Let’s look at some of the characteristics of Microservices (that most seem to agree upon)
  41. 41. Microservice characteristics • Single Responsibility Principle (SRP) • Small • Own process • Valuable • Replaceable • Upgradeable • Independent • Encapsulated • Composable • Testable • Fast startup/shutdown • Client friendly
  42. 42. Single Responsibility Principle (SRP) Billing DB Order Fulfillment DB SMS Gateway Shipping DB Management Reporting DB A MicroService should have a single responsibility and s responsibility should be entirely encapsulated within the serv
  43. 43. So how big/small should a microservice/responsibility be?
  44. 44. Does a Microservice own its data? • Remember layered SOA?
  45. 45. Layered 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
  46. 46. Does a Microservice own its data? • Remember layered SOA? • IMO a service that only deals with data persistence is best called a database/datastore • It already has a nice API – We don’t need to bubble wrap it with REST or Async 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.
  47. 47. What’s the right size?
  48. 48. I’ve heard that a “Microservice should be no larger than 100 Lines of Code!?”
  49. 49. Bad programmers worry about the code. Good programmers worry about data structures and their relationships Linus Thorvald
  50. 50. Bad programmers worry about microservices code size. Good programmers worry about their data ownership and relationships Jeppe Cramon
  51. 51. Enough with the size! When did we get away from solving business problems and start talking technology, JSON over XML, REST, LoC’s, Frameworks again?
  52. 52. It reminds me of the early SOA days All that was talked about then was which ESB to purchase, to how set it up, etc. No body discussed the problems that the ESB was supposed to solve (or when it was appropriate) or what services to build. We were caught in technology silver bullet again!
  53. 53. We kind of forgot that SOA was about business agility It was too much “Build it and they will come”
  54. 54. There is value in making things smaller For one thing it easier to reason about them in isolation
  55. 55. Going small has its advantages Source: @aviranm
  56. 56. SRP This sounds really good but what about cross Service relationships? Customer Orders Products
  57. 57. 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
  58. 58. Should we replace joins with RPC?
  59. 59. Synchronous calls are the crystal meth of programmingAt 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
  60. 60. Size this and Size that! Be Careful If Microservices are good, then Nanoservices must be even better? Why not one-liner services?
  61. 61. Nano Services Unless we have a very 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
  62. 62. Microservices are valuable The value of a microservice must exceed the cost of building & operating it. Microservices entails costs for serialization, deserialization, security, communication, maintenance, configuration, deployment, monitoring, etc.
  63. 63. 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
  64. 64. Microservices == distributed objects? Service star chart
  65. 65. Service Dependencies Source: https://qconsf.com/system/files/presentation-slides/QConSF-MicroServices-IPC-Netflix-Sudhir-2014.pptx
  66. 66. All of this means that we need to take care of how we design our service boundaries
  67. 67. Guidance can e.g. 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
  68. 68. 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
  69. 69. 1. How do we split our data / services Data must be collected in pieces called entities. These entities should be limited in size (but not smaller), so that, after a transaction they are consistent. Rule of thumb: One transaction involves only one entity.
  70. 70. What can we learn from DDD DDD has a similar concept called Aggregate
  71. 71. 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
  72. 72. Aggregate is another name for an Entity Pat Hellands “Entity” is the same as DDD’s “Aggregate” concept By adopting DDD’s terminology we gain a richer vocabulary: • Entity • Value Object • Aggregate
  73. 73. The smallest service Would be responsible for all logic and data related to a single Aggregate
  74. 74. Why? Because consistency can only be guaranteed with in an Aggregate It cannot span aggregates due to lack of coordinating transactions
  75. 75. Example of bad aggregate boundaries
  76. 76. In this case we can fix it All use cases shows that LegalEntity and Address are created and delete together Parent - Child
  77. 77. An improved aggregate design Address turned out to NOT be an Entity LegalEntity is an Entity and forms the Root of our LegalEntity aggregate
  78. 78. This gives us this rule of thumb 1 use case = 1 transaction = 1 aggregate
  79. 79. With this improved design Client that wants to use our LegalEntity Service LegalEntity Service
  80. 80. 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
  81. 81. We still haven’t conquered the temporal coupling problem
  82. 82. 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?
  83. 83. What about using RPC/REST/…? We can just make it async or?
  84. 84. Change Address Response Consumer Change Address Request Provider RPC or Request/Response - Synchronous 2 way communica 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.
  85. 85. Synchronous Remote Calls can lower our Fault tolerance • When servers crashes • When databases are down • When deadlocks occurs in the database – Do you retry? With synchronous RPC style Services interaction we can easily loose business data unless we use an Orchestration engine or find another way to achieve call/retry semantics, combined with compensations and lifecycle handling. Note: Automatic retry of calls only works if our Service operations are idempotent.
  86. 86. Also remember: REST isn’t magic!
  87. 87. Also, what’s less fat – XML or JSON? • They’re equally slim and fast! • http://balisage.net/Proceedings/vol10/html/ Lee01/BalisageVol10-Lee01.html
  88. 88. RPC and Distributed computing • As soon as a service request/response calls to another service across the network we must adhere to the laws of distributed computing*. – Reliability, Latency, Bandwidth, Transportation costs, Security • If the other services is not available then my service cannot conduct its business, which minimizes my services autonomy * See http://www.rgoarchitects.com/Files/fallacies.pdf for a walkthrough of the 8 fallacies of distributed computing
  89. 89. Service autonomy Service B Service C Service A System X Service A System Y Service B Service C System X Slow/unreliable network Different SLA Slow system
  90. 90. A distributed system is one where a machine I’ve never heard of can cause my program to fail. — Leslie Lamport
  91. 91. Availability goes down (without additional instances of each service) Service A Service B Service C Availability: 99% Availability: 99% Availability: 99% Combined availability: 97%
  92. 92. Decide if you can live with the consequences of coupling services to each other using Request/Response Different situations – different tradeoffs
  93. 93. To break things up We need to understand our business and its processes - How is data flowing?
  94. 94. In order to build the right boundaries
  95. 95. Claim Most of us are trained to think in Entities and Structural models and this is where we get our selves into trouble. We create big entangled models and forget about model boundaries and different consistency level requirements!
  96. 96. The mental capacity required to understand big domain models is huge
  97. 97. 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 importan Customer Pricing Inventory Sales Management Reporting
  98. 98. 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.
  99. 99. Billing Bounded Context Product Catalogue Bounded Context Shipping Bounded Context Sales Bounded Context Inventory Bounded Context Pricing Bounded Context Retail domain split into a Macro architecture
  100. 100. These splits should be fairly small (but not too small) and share as little as possible with each other Sales Pricing InventoryShipping ✕ ✕ ✕
  101. 101. What’s a macro architecture • It’s the static/stable(r) parts of your architecture – Which are very costly to refactor and change • Closely aligns business capabilities / bounded contexts with services
  102. 102. DDD doesn’t enforce problem domain and solution domain alignment for Bounded Contexts Which is why I prefer to use the term Business Capability
  103. 103. 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
  104. 104. Don’t split into services too early Cross boundary refactoring is costly
  105. 105. So what is a Service?
  106. 106. 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 • 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
  107. 107. Does a Service own its UI?
  108. 108. Degrees of coupling UI UI Service ServiceData Data Events Events
  109. 109. If we want to decouple our services as much as possible then we need to look towards Composite UI’s and Events
  110. 110. What’s a Composite UI A Composite UI is a way to allow different services to participate in the 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
  111. 111. Composite UI’s require that the Service owns its UI
  112. 112. A Service contains all parts related to it in order to minimize coupling to other services DB Schema Domain Services Application Services (Message Handlers) Aggregates , Entities, Value Objects, Events Integration Endpoints (REST, SOAP, Pub/Sub) User Interface Business-capability/Bounded-Context/Service
  113. 113. Composite UI’s Retail System Sales Pricing Inventory Web/Application tier Background server tier Storage tier Composite UI UI Layered ApplicationData Access Layer Readmodel Writemodel ✕ ✕ No synchronous communication between sub domains – ONLY asynchronous Events
  114. 114. Composite UI - example Context: Book ISBN-10 0-321-83457-7
  115. 115. 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
  116. 116. Composite UI - HTML #DIV – Book:Reviews #DIV – Book:Image #DIV – Book:TitleAndAuthor #DIV – Book:Pricing #DIV – Book:Availability #DIV - Header #DIV - Body
  117. 117. Conceptual View
  118. 118. The Service owns it UI in all Contexts and for all Composite UI’s Not just for HTML clients
  119. 119. Why? Because of System/Application boundaries cross Business Capabilities
  120. 120. Physical service view Application X Application Y UI Service A UI Service B UI Service B UI Service C UI Service C Data Cach e Service A App Service Service C Proces s Handle r Service B Domai n Logic Data Access Service B Domai n Data Acces Service C Data Cach e Service B Data Cach e Service C
  121. 121. Service deployment • Many services can be deployed in the same system/application/process – Process boundary is a physical boundary – A Service is a logical boundary • Service deployment is not restricted to tiers – Part of service A and B can be deployed to the Web tier – And 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 systems – i.e. Systems and services are not the same and does not share the same boundaries • Many services can be deployed to the same server • Multiple services can be deployed to the same page (service mashup) • Multiple services can cooperate to fulfill a service (e.g. a workflow or a business process) A service needs to be deployed everywhere its data is needed
  122. 122. Invoice Composite UI example InvoiceHeader Order:ShippingIn fo Invoice: InvoiceNo 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
  123. 123. So where does that leave microservices?
  124. 124. Service implementation • A Service represents a logical 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
  125. 125. Service Service Microservice 1..* Is implemented by A Service is the technical authority of a specific Business Capability e.g. Sales, Shipping, Billing Services are the implementation of business processes. Business processes can span multiple services, but there will always be a single service that is the actual authority on the business process.
  126. 126. Service Service Microservice 1..* Is implemented by 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 Also known as Autonomous Components
  127. 127. Microservices are logical deployable units That doesn’t mean they HAVE to be deployed individually. Design for Distribution But take advantage of locality
  128. 128. Services are the corner stone • We talk in terms of services, business capabilities and the processes/usecases they support • Microservices are an implementation detail • Microservices are much less stable (which is a good thing – it means they’re easier to replace) • A microservice in one service can subscribe to events from another Service or call operations on another Service (which again is implemented/supported by an internal microservice)
  129. 129. 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
  130. 130. Using Business Events to drive Business Processes Sales Service Shipping Billing Sales Customers Bus Online Ordering System Web Shop (Composite UI) Billing Service Shipping Service Order Accepted Event AcceptOrder Command The sales fulfillment processing can now begin…
  131. 131. Cascading events give rise to business processes
  132. 132. Event driven process Sales Service Order Accepted Billing Service Orderfulfilment Service Process Manager/ Saga/ Orchestration-Engine Shipping Service Online Ordering System Bus Order Accepted Order Accepted Customer Billed Customer Billed Order Authorize d Order Authorize d Works as a Finite State Machine (WorkFlow) handling the life cycle of Shipping and thereby forms a very central new Aggregate in the System
  133. 133. This form of architecture is called an Event Driven Architecture (EDA)
  134. 134. SOA and EDA are two sides of the same coin
  135. 135. SOA Analysis Patterns
  136. 136. How do we determine service boundaries?
  137. 137. Recommendation: Divide and concour • Start from the outside and model business capabilities • Design your Macro Architecture around this • Determine communication and interaction principles • Ensure common monitoring and logging facilities
  138. 138. How do I model?
  139. 139. For example: Event Storming • Event Storming is a fun way of driving your analysis from the outside and quickly explore complex business domains (in hours instead of days/weeks).
  140. 140. SOA was about business agility through IT/Business alignment Final thoughts
  141. 141. Doing SOA require maturity • Organizational maturity
  142. 142. Be aware of Conways Law “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” Teams are typically aligned with Systems/Projects and NOT with Services as I believe they should
  143. 143. Which require maturity • Organizational maturity • Technical/operations maturity* – DevOps – Build – Test – Deployment – Monitoring – Etc. * See: http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
  144. 144. We need a strong foundation for development to achieve this AlignmentHighlyalignedLessaligned EffciencyLess effective Highly effective ”Maintenance Zone” ”Well-Oiled IT” ”Alignment Trap” 11% 74% 7% 8% +13 -14 -2 -15 +11 -6 +35 ”IT enabled Growth” % of the 504 respondents % difference compared to the overall averages IT spending Combined yearly growth- rate over a 3 year period Source:BainAnalysis +0
  145. 145. So are Microservices the future? Gartners Pace layered Application strategy: • Systems of Record — Established packaged applications or legacy home-grown systems that support core transaction processing and manage the organization's critical master data. The rate of change is low, because the processes are well- established, common to most organizations, and often are subject to regulatory requirements. • Systems of Differentiation — Applications that enable unique company processes or industry-specific capabilities. They have a medium lifecycle (one to three years), but need to be reconfigured frequently to accommodate changing business practices or customer requirements. • Systems of Innovation — New applications that are built on an ad hoc basis to address new business requirements or opportunities. These are typically short lifecycle projects (zero to 12 months) using departmental or outside resources and consumer-grade technologies. • "These layers correspond to the notion of business leaders having common ideas,
  146. 146. Conclusions • In my opinion Microservices is a SOA delivery model • Focus should be on aligning Services to Business Capabilities – Make service as small as possible and as big as necessary • Beware of the coupling matrix – avoid synchronous communication between services unless you’re ready to pay the price • Implement Services as a set of Microservices that are logically deployable and divide them along transactional boundaries • Be aware of the requirements for organizational, business and technical maturity • If we can get there then I believe Microservices will be able to help us achieve a some of what SOA promised, but due to
  147. 147. Thank you  Jeppe Cramon – jeppe@tigerteam.dk www.tigerteam.dk www.tigerteam.dk/category/soa/ www.tigerteam.dk/category/soa/microservices/ Twitter: @tigerteamdk and @jeppec Want to learn more? Contact me for training and mentoring

×