Micro Services: Java, the Unix Way


Published on

Video and slides synchronized, mp3 and slide download available at http://bit.ly/ZlBMQY.

James Lewis tells the story of building a resource oriented, event driven system out of applications about 1000 lines long. Filmed at qconsf.com.

James Lewis is a Principle Consultant for ThoughtWorks based in the UK and a member of the ThoughtWorks Technical Advisory Board. Most recently he has been helping to introduce Agile at various blue chip companies: Investment Banks, Publishers and media organizations. Most recently, James has been spending his time helping ThoughtWorks' clients develop enterprise software as a coding architect.

Published in: Technology
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Micro Services: Java, the Unix Way

  1. 1. Micro Services Java, the Unix wayThursday, 8 November 12
  2. 2. Watch the video with slide synchronization on InfoQ.com! http://www.infoq.com/presentations /Micro-Services InfoQ.com: News & Community Site• 750,000 unique visitors/month• Published in 4 languages (English, Chinese, Japanese and Brazilian Portuguese)• Post content from our QCon conferences• News 15-20 / week• Articles 3-4 / week• Presentations (videos) 12-15 / week• Interviews 2-3 / week• Books 1 / month
  3. 3. Presented at QCon San Francisco www.qconsf.comPurpose of QCon- to empower software development by facilitating the spread ofknowledge and innovationStrategy - practitioner-driven conference designed for YOU: influencers ofchange and innovation in your teams- speakers and topics driving the evolution and innovation- connecting and catalyzing the influencers and innovatorsHighlights- attended by more than 12,000 delegates since 2007- held in 9 cities worldwide
  4. 4. Principal Consultant Senior Engineer story teller @boicy http://bovon.org jalewis@thoughtworks.comThursday, 8 November 12
  5. 5. WHAT I DID LAST SUMMER Or how we designed and built a Resource Oriented, Event Driven System out of applications about 1000 lines long…Thursday, 8 November 12
  6. 6. In the beginning… • There was a new product being developed by an organisation in London • The organisation had gathered their list of high level requirements • And they asked ThoughtWorks if we could help them design and build it…Thursday, 8 November 12
  7. 7. So we took a look at their requirements • Me and my mates at ThoughtWorks • Worked out to be about a lot of points worth of User StoriesThursday, 8 November 12
  8. 8. Complete Half way through 0 Heat opened End day Cows hell pigs fly death of the box 1 come freezes the home UniverseThursday, 8 November 12
  9. 9. Tip 1 Divide and conquer break  down  complex  problems  into   smaller  chunks  that  can  be  solved   individuallyThursday, 8 November 12
  10. 10. Thursday, 8 November 12
  11. 11. Thursday, 8 November 12
  12. 12. heavy industrialThursday, 8 November 12
  13. 13. commercialThursday, 8 November 12
  14. 14. light residentialThursday, 8 November 12
  15. 15. Each small box represents a capability, composed of one or more services 13Thursday, 8 November 12
  16. 16. And there were some, umm, interesting non-functional requirements tooThursday, 8 November 12
  17. 17. 1000TPS, 99th percentile latency of < 2 seconds 15Thursday, 8 November 12
  18. 18. Support a user base of 100 million active customers 16Thursday, 8 November 12
  19. 19. Support bulk loads of 30 – 90 million records nightly and keep them for six months (16,200,000,000 records) 17Thursday, 8 November 12
  20. 20. Did I mention PCI Level 1? 18Thursday, 8 November 12
  21. 21. Finally, this is a product build. So it needed to be modular / <cough> “infinitely configurable”Thursday, 8 November 12
  22. 22. The product need to to be… • Performant – fairly high throughput both transactional and batch • Fault tolerant – One thing about the cloud, you are designing for failure right? • Configurable – On a per install or SaaS basis • Portable – Fortunately not to Windows… • Maintainable – over multiple versions and years • Supporting big data sets – Billions of transactions available – Millions of customers availableThursday, 8 November 12
  23. 23. Plus ça change, plus cest la même chose. (The  more  things  change  the  more  they  stay  the  same)Thursday, 8 November 12
  24. 24. • The only way we could hit anything like the timescales required was to scale the programme quickly • And that meant multiple teams in multiple workstreamsThursday, 8 November 12
  25. 25. So, after five weeks we had broken the problem down into capabilties Now we had to start scaling the teams to deliver these capabilitiesThursday, 8 November 12
  26. 26. Tip 2 Use Conway’s Law to structure teams “…organiza>ons  which  design  systems  …  are  constrained  to  produce  designs which  are  copies  of  the  communica>on  structure  of  those  organiza>ons” Melvin  Conway,  1968Thursday, 8 November 12
  27. 27. The first business capability - Users • Responsible for creation and maintenance of users in the system – Up to 100 million of them per instance of the product • Used by many clients with many usage patterns – Call centre and website – CRUD – Inbound batch files – CRUD x hundreds of thousands per night • Many downstream consumers of the data – Fulfilment systems for exampleThursday, 8 November 12
  28. 28. Tip 3 The Last Responsible Moment Don’t decide everything at the point you know leastThursday, 8 November 12
  29. 29. We started with a business process… and noticed something funny…Thursday, 8 November 12
  30. 30. events... 28Thursday, 8 November 12
  31. 31. * Dan North coined the term Enterprise Night Bus… ESB* I know what you are thinking…Thursday, 8 November 12
  32. 32. Or you could use the webThursday, 8 November 12
  33. 33. Tip 4 Be of the web, not behind the webThursday, 8 November 12
  34. 34. RFC 5023 to be preciseThursday, 8 November 12
  35. 35. Our Users /user-requestCapability application/atom+json /user-request/1223 33Thursday, 8 November 12
  36. 36. Our Users /user-requestCapability application/atom+json /user-request/1223 Standard resource representations using well known web standards – atom+json 34Thursday, 8 November 12
  37. 37. Our Users /user-requestCapability application/atom+json /user-request/1223 Reified the request to create a user. Clients POST a request to create a user as an entry to an atom collection. 35Thursday, 8 November 12
  38. 38. Tip 5 If something is important, make it an explicit part of your design Reify to convert into or regard as a concrete thing: to reify a concept.Thursday, 8 November 12
  39. 39. Our Users /user-requestCapability application/atom+json /user-request/1223 Event queue has the single responsibility of managing state transitions for the request to create a user 37Thursday, 8 November 12
  40. 40. Our Users /user-requestCapability application/atom+json /user-request/1223 Queue Processing Engine implemented the Competing Consumer pattern using Conditional GET, PUT and Etags against the atom collection exposed by the event queue 38Thursday, 8 November 12
  41. 41. Our Users /user-requestCapability application/atom+json /user-request/1223 User Service and store is the system of record for users 39Thursday, 8 November 12
  42. 42. Our Users After creation, representations of Users are available /user-request at canonical locations in well defined formats andCapability creation events added to another atomapplication/atom+json /user-request/1223 collection /users/142 application/vnd.user+JSON /users 40Thursday, 8 November 12
  43. 43. Where they are available for consumption by other downstream systemsThursday, 8 November 12
  44. 44. Reporting capability polls for new user events Fulfilment capability polls for new user eventsThursday, 8 November 12
  45. 45. Our micro-services • User Request Queue –Forms the transactional boundary of the system • Request Queue Processor –Competing Consumer processes events on the queue and POSTs them to • User Service –System of record for Users in the system –Responsible for all state changes of those users –Exposes events on those users to other systemsThursday, 8 November 12
  46. 46. CHARACTERISTICS OF MICRO- SERVICESThursday, 8 November 12
  47. 47. Small with a single responsibility • Each application only does one thing • Small enough to fit in your head –James’ heuristic –“If a class is bigger than my head then it is too big” • Small enough that you can throw them away –Rewrite over MaintainThursday, 8 November 12
  48. 48. Containerless and installed as well behaved Unix services • Embedded web container – Jetty / SimpleWeb – This has a lot of benefits for testing (inproctester for example) and eases deployment • Packaged as a single executable jar – Along with their configuration – And unix standard rc.d scripts • Installed in the same way you would install httpd or any other application – Why recreate the wheel? Daemons seem to work ok for everything else. Unless you are *special*?Thursday, 8 November 12
  49. 49. Located in different VCS roots • Each application is completely separate • Software developers see similarities and abstractions – And before you know it you have One Domain To Rule Them All • Domain Driven Design / Conways Law – Domains in different bounded contexts should be distinct – and its ok to have duplication – Use physical separation to enforce this • There will be common code, but it should be library and infrastructure code – Treat it as you would any other open source library – Stick it in a nexus repo somewhere and treat it as a binary dependencyThursday, 8 November 12
  50. 50. Provisioned automatically • The way to manage the complexity of many small applications is declarative provisioning –UAT: • 2 * service A, Load Balanced, Auto-Scaled • 2 * service B, Load Balanced, Auto-Scaled • 1 * database clusterThursday, 8 November 12
  51. 51. Status aware and auto-scaling • What good is competing consumer if you only have one consumer? –We don’t want to wake Laura up at three in the morning any more to start a new process • Use watchdog processes to monitor in-app status pages –Each app exposes metrics about itself –In our case, queue-depth for example –This allows others services to auto-scale to meet throughput requirementsThursday, 8 November 12
  52. 52. A single capability composed of many small applications and exposing a uniform interface of Atom CollectionsThursday, 8 November 12
  53. 53. How the capabilities form a productThursday, 8 November 12
  54. 54. They interact via the web’s uniform interface • HTTP – Don’t fight the battles already won – Use no-brainer force multipliers like reverse proxies • HATEOAS – Link relations drive state changes – Its an anti-corruption layer that allows the capability to evolve independently of its clients • Standard media types – Can be used by many different clients – You can monitor it using a feed reader if you want – and it makes your QA’s lives a *lot* easierThursday, 8 November 12
  55. 55. Capabilities poll each other for events, forming an eventually consistent system of systems atom+json / HTTP (AJOH) Monitoring Reporting Capability Capability (AJOH) (AJOH) atom+XML / HTTP User Fulfilment Capability Capability (AJOH) (AJOH) (AJOH) Inbound Batch Call Centre External SuppliersThursday, 8 November 12
  56. 56. Tip 6 Favour  service  choreography  over  orchestra>onThursday, 8 November 12
  57. 57. Each is decoupled from it’s clients. scalable, testable and deployable individually atom+json / HTTP (AJOH) Monitoring Reporting Capability Capability (AJOH) (AJOH) atom+XML / HTTP User Fulfilment Capability Capability (AJOH) (AJOH) (AJOH) Inbound Batch Call Centre External SuppliersThursday, 8 November 12
  58. 58. Tip 7 Use hypermedia controls to decouple servicesThursday, 8 November 12
  59. 59. Each developed by a separate team, using whatever tech they choose atom+json / HTTP (AJOH) Monitoring Reporting Capability Capability (AJOH) (AJOH) atom+XML / HTTP User Fulfilment Capability Capability (AJOH) (AJOH) (AJOH) Inbound Batch Call Centre External SuppliersThursday, 8 November 12
  60. 60. Our stack • Embedded Jetty (current project uses SimpleWeb) • PicoContainer for DI • Hibernate (but wrote our own SQL) • Abdera for Atom • Smoothie charts • Metrics @codahale • GraphiteThursday, 8 November 12
  61. 61. Tip 8 Make it easy to do the right thing and hard to do the wrong thing use tooling and architectural tests to make complex tasks simpleThursday, 8 November 12
  62. 62. Infrastructure automation stack • Fabric with boto • AWS, but deployable to anything with SSH • Maven (boo) • Git • Puppet for provisioningThursday, 8 November 12
  63. 63. NO SILVER BULLETSThursday, 8 November 12
  64. 64. this was hard to do well • We haven’t even talked about – Versioning – Integration – Testing – Deployment • Eventual Consistency can be tricky for people to get there head around • Developers like using enterprisy software – No one got fired for choosing an ESB – Convincing people to use the web is hardThursday, 8 November 12
  65. 65. SUMMARYThursday, 8 November 12
  66. 66. The Unix Philosophy :s/pipes/hKp/   Lions commentary on Unix 2nd editionThursday, 8 November 12
  67. 67. Consistent and reinforcing practices Hexagonal Business capabilities composed of: Micro Services that you can Rewrite rather than maintain and which form A Distributed Bounded Context. Deployed as containerless OS services With standardised application protocols and message semantics Which are auto-scaling and designed for failureThursday, 8 November 12
  68. 68. Tip 9 Always have ten tipsThursday, 8 November 12
  69. 69. Thanks! @boicy http://bovon.org jalewis@thoughtworks.comThursday, 8 November 12