MicroService Architecture

32,436 views
31,951 views

Published on

SOA, service-­oriented architectures, burst on the scene in the new millennium as the latest technology to support application growth. In concert with the Web, SOA ushered in new paradigms for structuring enterprise applications.

At the Forward Internet Group in London, we are implementing SOA in unusual ways. Rather than a few, business­related services being implemented per the original vision, we have developed systems made of myriads of very small, usually short­lived services.

In this workshop, we will start by exploring the evolution of SOA implementations by the speaker. In particular, lessons learned from each implementation will be discussed, and re­application of these lessons on the next implementation. Challenges (and even failures) will be explicitly identified.

We will arrive at a model of the current systems: An environment of very small services that are loosely coupled into a complex system. We explore the demise of acceptance tests in this complex environment, and the clever replacement of business metrics in their stead.

Finally, we will conclude with the surprising programmer development process impacts of this architecture. Indeed, bedrock principles of Agile have been rendered unnecessary, something that equally surprised us. (Presented at Agile India 2013)

1 Comment
84 Likes
Statistics
Notes
No Downloads
Views
Total views
32,436
On SlideShare
0
From Embeds
0
Number of Embeds
1,547
Actions
Shares
0
Downloads
1,098
Comments
1
Likes
84
Embeds 0
No embeds

No notes for slide

MicroService Architecture

  1. 1. µService Architecture:A Personal Journey of DiscoveryFred Georgefredgeorge@acm.org@fgeorge52Copyright © 2012 by Fred George. All rights reserved. 1
  2. 2. In the Beginning...Copyright © 2012 by Fred George. All rights reserved. 2
  3. 3. 2004:1M loc - Largest CertifiedJ2EE ApplicationCopyright © 2012 by Fred George. All rights reserved. 3
  4. 4. It StartedWell...Martin Fowlerconsulted, thenjoined ThoughtWorksCopyright © 2009 by Fred George 4
  5. 5. What I Found in 2004✦ 1M locs✦ 2,000 tests✦ 70% success rate on Acceptance Test was Acceptable✦ Bug database with over 1000 entries✦ Still being changed✦ New tests almost non-existentCopyright © 2012 by Fred George. All rights reserved. 5
  6. 6. Unit Test CountsCopyright © 2012 by Fred George. All rights reserved. 6
  7. 7. assertNotNull (new Loan(50)); ✦ Easy (reasonably) unit test ✦ On Saturday without interruptions 5 hours later, it passed!Copyright © 2012 by Fred George. All rights reserved. 7
  8. 8. 2004:1M loc - Largest CertifiedJ2EE Application“100K loc trying to get out” Jeff BayCopyright © 2012 by Fred George. All rights reserved. 8
  9. 9. Why? What Happened? Sloppy Lazy? Technical Debt No power to refuse!Inexperienced!Copyright © 2012 by Fred George. All rights reserved. 9
  10. 10. Evolution...Copyright © 2012 by Fred George. All rights reserved. 10
  11. 11. 2005: SOA in Chinese Bank Cash, Loans Mortgage Insurance BalancesCopyright © 2012 by Fred George. All rights reserved. 11
  12. 12. Solution: Pub/Sub e d ✦ Events “published” c t ✦ ✦ Interested applications “subscribe” j e Applications then “publish” interaction requests ✦ R e UI elements render appropriate interactionsCopyright © 2012 by Fred George. All rights reserved. 12
  13. 13. 2004: 20051M loc - Largest CertifiedJ2EE Application“20 5K loc trying to getout”“100K loc trying to get out”Copyright © 2012 by Fred George. All rights reserved. 13
  14. 14. 2005: Medical Systems Information “Nuggets”Copyright © 2012 by Fred George. All rights reserved. 14
  15. 15. From: CAT Scan About: Jane Doe e d Urgency: Time: 23 Apr 2012 20:13:45 Concern c t Summary Validity: 26 Apr 2012 20:13:45 j e Only relevant until... R e Information “Nuggets”Copyright © 2012 by Fred George. All rights reserved. 15
  16. 16. 2005: Services forInvestment Management p e✦ Prototyping new system architecture t y o✦ Baysian Service Principles (Jeff Bay) t ✦ It’s okay to run more than one version at the same time✦ ✦ r o You can only deploy one service at a time Decoupling result: Deploying 3 times a day! PCopyright © 2012 by Fred George. All rights reserved. 16
  17. 17. 2006: Batch ProcessingReplacement Orders✦ Client needed to replace parts on cars ✦ Many variations based on car, location of car✦ Vendor estimated 15- months 18✦ Unacceptable to businessCopyright © 2012 by Fred George. All rights reserved. 17
  18. 18. 2006: Batch ProcessingReplacement OrdersCopyright © 2012 by Fred George. All rights reserved. 18
  19. 19. Refined Packet Design ? Addr ? ? ? ? ? ? ? VIN ? ? Date ? ? ? Name ?Copyright © 2012 by Fred George. All rights reserved. 19
  20. 20. ? Addr ? ? ? ? d Join Table e •Need VIN •Need zzz •Inject aaa r ks e e v e i w •Need Addr •Inject Name l e 9 D •Need Name •Need rrr •Inject VIN i nCopyright © 2012 by Fred George. All rights reserved. 20
  21. 21. New Observations andRevelations✦ Services are like Classes ✦ Small, crisp conceptualization ✦ Services got very tiny (100 loc)✦ Smalltalk message passing perfect for services✦ Encapsulation ✦ Database segregated among services w/o sharing ✦ Service publishes conclusions, not raw dataCopyright © 2012 by Fred George. All rights reserved. 21
  22. 22. New Problems andChallenges d ?✦ “WTF is going on ?” r e ✦ ✦ Cycles, lost packets Needed to redefine tracking, logging v e✦ Inexperienced team in defining services ✦ l Approach compromised in Release 2 i✦ D e Won award at TW Tech Day... for being a bad idea!Copyright © 2012 by Fred George. All rights reserved. 22
  23. 23. 2004: 2005 20061M loc - Largest CertifiedJ2EE Application 200 500 loc“20 5K loc trying to getout”Copyright © 2012 by Fred George. All rights reserved. 23
  24. 24. Experiences at...Copyright © 2012 by Fred George. All rights reserved. 24
  25. 25. 2007: Forward Needs toMonitor AdWords Accounts e d t✦ Pub/sub model based on Linda Spaces (tuples) Segregate databases to services c ✦ Define agent services for each user e ✦ Start to automate activities and recommendations j ✦✦ Off-shore for implementation✦ ✦ solution R e CTO killed it (former Oracle executive) Replaced with a more traditional, SQL DB-drivenCopyright © 2012 by Fred George. All rights reserved. 25
  26. 26. 2008: CardWall e d✦ Front-end automated Card Wall in Agile e r✦ Back-end emerged as a set of services analyzing data i v l ✦ One service, one role✦ ✦ D Migrated to Hadoop Cluster as it grew e Post alerts (with recommendations) to usersCopyright © 2012 by Fred George. All rights reserved. 26
  27. 27. New Observations andRevelations✦ Services became disposable✦ Loosely coupled via RESTful Json packets or DB ✦ Albeit still knowledgeable about flow✦ Self-monitoring services replaces Unit Tests✦ Business monitoring replaces Acceptance Tests✦ Services language-agnosticCopyright © 2012 by Fred George. All rights reserved. 27
  28. 28. Current State...Copyright © 2012 by Fred George. All rights reserved. 28
  29. 29. Copyright © 2012 by Fred George. All rights reserved. 29
  30. 30. Copyright © 2012 by Fred George. All rights reserved. 30
  31. 31. Design: Events, not EntitiesCopyright © 2012 by Fred George. All rights reserved. 31
  32. 32. Design: History, not CurrentCopyright © 2012 by Fred George. All rights reserved. 32
  33. 33. Legacy System Web Web Services Services ETL/ Biz Biz Data Muddling Data Data ReportingCopyright © 2012 by Fred George. All rights reserved. 33
  34. 34. Cloud of Signals Email Read Postcode Email Address Name Postal Address Server Load URL RequestCopyright © 2012 by Fred George. All rights reserved. 34
  35. 35. Data Ecosystem Producers Kafka Consumers Postal AddressApp R App HiveService Email Address Monitoring Web Server URL Request Apps/3rd Party Services NameWeb HooksCopyright © 2012 by Fred George. All rights reserved. 35
  36. 36. Cross-sell TrackingCopyright © 2012 by Fred George. All rights reserved. 36
  37. 37. User Paths Through SiteCopyright © 2012 by Fred George. All rights reserved. 37
  38. 38. Agile Best Practices Not Used Trust w✦ Stand ups collocation ✦ Unit tests✦ Story narratives ✦ Acceptance tests Small,✦ Retrospectives ✦ Refactoring short-lived✦ Estimates ✦ Patterns apps Results,✦ Iterations not blame ✦ Continuous integration✦ Mandatory pairing Continuous deploymentCopyright © 2012 by Fred George. All rights reserved. 38
  39. 39. What About Technical Debt? Sloppy Lazy? Technical Debt No power to refuse!Inexperienced!Copyright © 2012 by Fred George. All rights reserved. 39
  40. 40. Conclusions (so far)...Copyright © 2012 by Fred George. All rights reserved. 40
  41. 41. Summary Principles ofµServices✦ Very, very small✦ Loosely coupled (including flow)✦ Multiple versions acceptable (encouraged?)✦ Self-execution monitoring of each service✦ Publish interesting “stuff” (w/o requirement)✦ “Application” seems to be poor conceptualizationCopyright © 2012 by Fred George. All rights reserved. 41
  42. 42. “Living Software” System✦ Long-lived system; short-lived services (human body)✦ Extremely dynamic with continuous deployments ✦ 5- minutes between deployments typical 10✦ Accept it is complex (especially for testing) ✦ Acceptance test on business outcomes instead✦ Radical impact to processes (Anarchy)✦ There will be a learning curve for developers!Copyright © 2012 by Fred George. All rights reserved. 42
  43. 43. µService Architecture:A Personal Journey of DiscoveryFred Georgefredgeorge@acm.org@fgeorge52Copyright © 2012 by Fred George. All rights reserved. 43

×