Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Microservices 
SOA reminded of what it 
was supposed to deliver? 
Jeppe Cramon - @jeppec 
μService Conference London 
2014
SOA or Microservices? 
Higher reusability, significant reduction of 
development cost, increased reliability, 
improved ma...
For years no one talked about 
SOA 
Mostly because of the many failures… 
Example: 
I've used service-oriented architectur...
In my opinion SOA is not to 
blame for the dissapointment
I believe that Microservices is a 
welcome opportunity to brush off 
the dust, learn form the past and 
perhaps improve
Beware of 
sales pitches
The fine-grained, stateless, self-contained 
nature of 
microservices creates decoupling 
between different parts of a cod...
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 lasagna of software due to 
coupling 
Spaghetti in layers
So if we keep up the same 
habits that resulted in messy 
monoliths 
What’s makes us think that we 
won’t end up with
Microservice spaghetti?
Most “Services” today are built 
on top of Monoliths 
DB DB 
Service 
A.4 
Monolith A Monolith B 
Monolith C Monolith D 
S...
If we create naïve 
microservices 
DB DB 
Service 
A.4 
DB 
Monolith A Monolith B 
Monolith C Monolith D 
Service 
A.1 
Se...
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 
...
Single Responsibility Principle 
(SRP) 
Billing 
DB 
Order Fulfillment 
DB 
SMS Gateway 
Shipping 
DB 
Management 
Reporti...
Does a Microservice own its 
data? 
• Remember layered SOA? 
• IMO a service that only deals with data 
persistence is bes...
So how big/small should a 
microservice/responsibility be?
But I’ve heard that a 
“Microservice should be no larger 
than 100 Lines of Code!?”
Enough already! 
When did we get away from solving 
business problems and start 
talking technology, JSON over XML, 
REST,...
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. 
N...
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 ...
Should we replace joins with 
RPC?
Change Address Response 
Consumer 
Change Address Request 
Provider 
RPC or Request/Response - Synchronous 2 way communica...
Size this and Size that! 
Be Careful 
If Microservices are good, then 
Nanoservices must be even 
better? 
Why not one-lin...
Nano Services 
Unless we have a very reason for doing so, 
we risk building services 
that are so fine-grained 
that their...
Microservices are valuable 
The value of a microservice must 
exceed the cost of building & 
operating it. 
Microservices ...
Too small services 
With too small services there’s a big risk that what’s left 
of coherence goes out the window and we g...
Microservices == distributed 
objects? 
Service star chart
Service Dependencies 
Source: https://qconsf.com/system/files/presentation-slides/QConSF-MicroServices-IPC-Netflix-Sudhir-...
All these services needs to be 
integrated 
And often in the form of 
Request/Response calls 
(and often over the network ...
Synchronous Remote Calls 
can lower our Fault tolerance 
• When servers crashes 
• When databases are down 
• When deadloc...
Also remember: REST isn’t 
magic!
What’s less fat – XML or JSON? 
• They’re equally slim and fast! 
• http://balisage.net/Proceedings/vol10/html/ 
Lee01/Bal...
RPC and Distributed computing 
• As soon as a service request/response 
calls to another service across the 
network we mu...
Service autonomy 
Service 
B 
Service 
C 
Service 
A 
System X 
Service 
Service 
A 
System Y 
B 
Service 
C 
System X 
Sl...
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: ...
Decide if you can live with the 
consequences of coupling 
services to each other using 
Request/Response 
Different situa...
SOA was about business 
agility through IT/Business 
alignment
Which require maturity 
• Organizational maturity
Be aware of Conways Law 
“organizations which design systems ... are 
constrained to produce designs which are 
copies of ...
Which require maturity 
• Organizational maturity 
• Technical/operations maturity* – DevOps 
– Build 
– Test 
– Deploymen...
We need a strong foundation for development to 
achieve this 
Less aligned Alignment Highly aligned 
11% 
”Alignment Trap”...
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 troubl...
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...
Different perspectives on 
entities 
With in a given Domain, e.g. Retail, there will exist multiple bounded 
contexts/sub-...
Retail domain split into a 
Macro architecture 
Billing 
Bounded 
Context 
Product 
Catalogue 
Bounded 
Context 
Shipping ...
What’s a macro architecture 
• It’s the static/stable(r) parts of your 
architecture 
– Which are very costly to refactor ...
DDD doesn’t enforce 
problem domain and solution 
domain alignment for Bounded 
Contexts 
Which is why I prefer to use the...
Service and Business Capability 
alignment 
“The advantage of business capabilities is their 
remarkable level of stabilit...
Don’t split into services too 
early 
Cross boundary refactoring is 
costly
A Service is 
• The technical authority for a given business 
capability 
• It is the owner of all the data and business 
...
So where does that leave 
microservices?
Service and deployment 
A service needs to be deployed everywhere its data is needed 
• A Service represents a logical bou...
Service 
1..* 
A Service is the technical authority 
of a specific Business Capability 
e.g. Sales, Shipping, Billing 
Ser...
Service 
Also known as Autonomous 
Components 
1..* 
Service Microservice 
Is implemented by 
Microservices are a division...
Microservices are logical 
deployable units 
That doesn’t mean they HAVE to be deployed 
individually. 
Design for Distrib...
Services are the corner stone 
• We talk in terms of services, business 
capabilities and the processes/usecases they 
sup...
Coupling matrix* 
Emergency services Distributed 3 layer 
Event oriented Command oriented 
Behavioral 
coupling 
High 
Tem...
Using Business Events to drive 
Business Processes 
Online Ordering System 
Sales Service 
Billing 
Shipping 
Customers 
S...
Cascading events give rise to 
business processes
Event driven process 
Sales Service 
Online Ordering System 
Order 
Accepted 
Billing Service 
Orderfulfilment Service 
Pr...
This form of architecture is called 
an 
Event Driven Architecture (EDA)
SOA and EDA are two sides of 
the same coin
So are Microservices the 
future? 
Gartners Pace layered Application strategy: 
• Systems of Record — Established packaged...
Conclusions 
• In my opinion Microservices is one SOA delivery model 
• Focus should be on aligning Services to Business C...
Thank you  
Jeppe Cramon 
TigerTeam 
www.tigerteam.dk 
www.tigerteam.dk/category/soa/ 
www.tigerteam.dk/category/soa/micr...
Microservices  - SOA reminded of what it was supposed to deliver?
Upcoming SlideShare
Loading in …5
×

Microservices - SOA reminded of what it was supposed to deliver?

6,473 views

Published on

My slides from µCon 2014: The Microservices Conference - Video is available here: https://skillsmatter.com/skillscasts/5264-microservices-soa-reminded-of-what-it-was-supposed-to-deliver

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?

Published in: Technology

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 μService Conference London 2014
  2. 2. SOA or Microservices? Higher reusability, significant reduction of development cost, increased reliability, improved maintainability, enhanced quality… … 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. Better ROI, More Security, Fewer Defects, Reusable assets, Better Maintainability, More reuse, Better parallelism in development, Better scalability, Higher availability….
  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 … • 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 Source: http://www.techrepublic.com/blog/tech-decision-maker/the-unfulfilled-promise-of-soa/
  4. 4. In my opinion SOA is not to blame for the dissapointment
  5. 5. I believe that Microservices is a welcome opportunity to brush off the dust, learn form the past and perhaps improve
  6. 6. Beware of sales pitches
  7. 7. 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
  8. 8. Trying hard to pretend it’s not difficult to develop distributed systems
  9. 9. It seems the argument is that just by making things fine grained We by magic achieve decoupling
  10. 10. Decoupled? Source: https://qconsf.com/system/files/presentation-slides/QConSF-MicroServices-IPC-Netflix-Sudhir-2014.pptx
  11. 11. Monoliths are often blamed for being the lasagna of software due to coupling Spaghetti in layers
  12. 12. So if we keep up the same habits that resulted in messy monoliths What’s makes us think that we won’t end up with
  13. 13. Microservice spaghetti?
  14. 14. Most “Services” today are built on top of Monoliths DB DB Service A.4 Monolith A Monolith B Monolith C Monolith D Service A.1 Service A.2 Service A.3 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
  15. 15. If we create naïve microservices DB DB Service A.4 DB Monolith A Monolith B Monolith C Monolith D Service A.1 Service A.2 Service A.3 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 DB DB DB DB DB DB DB DB DB DB DB DB DB
  16. 16. Then we’ve IMO just gone from bad
  17. 17. To Worse
  18. 18. So does that mean that breaking things apart is a bad thing?
  19. 19. Definitely NOT! But we need some guidelines to avoid things becoming messy (once again)
  20. 20. So how do we get there? Let’s look at some of the characteristics of Microservices (that most seem to agree upon)
  21. 21. Microservice characteristics • Single Responsibility Principle (SRP) • Small • Own process • Valuable • Replaceable • Upgradeable • Independent • Encapsulated • Composable • Testable • Fast startup/shutdown • Client friendly
  22. 22. Single Responsibility Principle (SRP) Billing DB Order Fulfillment DB SMS Gateway Shipping DB Management Reporting DB A Service should have a single responsibility and this responsibility should be entirely encapsulated within the service
  23. 23. 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.
  24. 24. So how big/small should a microservice/responsibility be?
  25. 25. But I’ve heard that a “Microservice should be no larger than 100 Lines of Code!?”
  26. 26. Enough already! When did we get away from solving business problems and start talking technology, JSON over XML, REST, LoC’s, Frameworks again?
  27. 27. 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!
  28. 28. We kind of forgot that SOA was about business agility It was too much “Build it and they will come”
  29. 29. There is value in making things smaller For one thing it easier to reason about them in isolation
  30. 30. Going small has its advantages Source: @aviranm
  31. 31. SRP This sounds really good but what about cross Service relationships? Customer Orders Products
  32. 32. 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
  33. 33. Should we replace joins with RPC?
  34. 34. Change Address Response Consumer Change Address Request Provider RPC or Request/Response - Synchronous 2 way communication Remote Procedure Call Change Address Request Change Address Request VS. Request Channel Consumer Provider Change Address Reply Change Address Reply Reply Channel Request/Reply – Asynchronous 2 way communication
  35. 35. Size this and Size that! Be Careful If Microservices are good, then Nanoservices must be even better? Why not one-liner services?
  36. 36. 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
  37. 37. Microservices are 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.
  38. 38. 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
  39. 39. Microservices == distributed objects? Service star chart
  40. 40. Service Dependencies Source: https://qconsf.com/system/files/presentation-slides/QConSF-MicroServices-IPC-Netflix-Sudhir-2014.pptx
  41. 41. All these services needs to be integrated And often in the form of Request/Response calls (and often over the network – aka RPC)
  42. 42. 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.
  43. 43. Also remember: REST isn’t magic!
  44. 44. What’s less fat – XML or JSON? • They’re equally slim and fast! • http://balisage.net/Proceedings/vol10/html/ Lee01/BalisageVol10-Lee01.html
  45. 45. 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
  46. 46. Service autonomy Service B Service C Service A System X Service Service A System Y B Service C System X Slow/unreliable network Different SLA Slow system
  47. 47. A distributed system is one where a machine I’ve never heard of can cause my program to fail. — Leslie Lamport
  48. 48. Availability goes down (without additional instances of each service) Service A Service B Service C Availability: 99% Availability: 99% Availability: 99% Combined availability: 97%
  49. 49. Decide if you can live with the consequences of coupling services to each other using Request/Response Different situations – different tradeoffs
  50. 50. SOA was about business agility through IT/Business alignment
  51. 51. Which require maturity • Organizational maturity
  52. 52. 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
  53. 53. 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
  54. 54. We need a strong foundation for development to achieve this Less aligned Alignment Highly aligned 11% ”Alignment Trap” +13 74% 7% ”IT enabled Growth” -6 8% -14 +35 ”Maintenance Zone” ”Well-Oiled IT” -2 -15 +11 Less effective Effciency Highly effective % of the 504 respondents % difference compared to the overall averages IT spending Source: Bain Analysis Combined yearly growth-rate over a 3 year period +0
  55. 55. To break things up We need to understand our business and its processes - How is data flowing?
  56. 56. In order to build the right boundaries
  57. 57. 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!
  58. 58. The mental capacity required to understand big domain models is huge
  59. 59. 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
  60. 60. 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.
  61. 61. Retail domain split into a Macro architecture Billing Bounded Context Product Catalogue Bounded Context Shipping Bounded Context Sales Bounded Context Inventory Bounded Context Pricing Bounded Context
  62. 62. 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
  63. 63. DDD doesn’t enforce problem domain and solution domain alignment for Bounded Contexts Which is why I prefer to use the term Business Capability
  64. 64. 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
  65. 65. Don’t split into services too early Cross boundary refactoring is costly
  66. 66. 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
  67. 67. So where does that leave microservices?
  68. 68. Service and deployment A service needs to be deployed everywhere its data is needed • 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
  69. 69. Service 1..* A Service is the technical authority of a specific Business Capability e.g. Sales, Shipping, Billing Service Microservice Is implemented by 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.
  70. 70. Service Also known as Autonomous Components 1..* Service Microservice 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
  71. 71. Microservices are logical deployable units That doesn’t mean they HAVE to be deployed individually. Design for Distribution But take advantage of locality
  72. 72. 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)
  73. 73. Coupling matrix* Emergency services Distributed 3 layer Event oriented Command oriented Behavioral coupling High Temporal coupling Low High Low * Modified version of Ian Robinson’s matrix: http://iansrobinson.com/2009/04/27/temporal-and-behavioural-coupling/
  74. 74. Using Business Events to drive Business Processes Online Ordering System Sales Service Billing Shipping Customers Sales Bus Web Shop (Composite UI) Billing Service Shipping Service Order Accepted Event AcceptOrder Command The sales fulfillment processing can now begin…
  75. 75. Cascading events give rise to business processes
  76. 76. Event driven process Sales Service Online Ordering System Order Accepted Billing Service Orderfulfilment Service Process Manager/ Saga/ Orchestration-Engine Shipping Service Bus Order Accepted Customer Billed Order Accepted 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
  77. 77. This form of architecture is called an Event Driven Architecture (EDA)
  78. 78. SOA and EDA are two sides of the same coin
  79. 79. 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, different ideas, and new ideas,"
  80. 80. Conclusions • In my opinion Microservices is one 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 different factors rarely delivered
  81. 81. Thank you  Jeppe Cramon TigerTeam www.tigerteam.dk www.tigerteam.dk/category/soa/ www.tigerteam.dk/category/soa/microservices/ Twitter: @tigerteamdk and @jeppec

×