Your SlideShare is downloading. ×
Micro Services: Java, the Unix Way
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Micro Services: Java, the Unix Way


Published on

Video and slides synchronized, mp3 and slide download available at …

Video and slides synchronized, mp3 and slide download available at

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

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
  • Pg 56... Choreography over Orchestration... YES!!!
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Micro Services Java, the Unix wayThursday, 8 November 12
  • 2. Watch the video with slide synchronization on! /Micro-Services 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. 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. Principal Consultant Senior Engineer story teller @boicy jalewis@thoughtworks.comThursday, 8 November 12
  • 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. 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. 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. 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. Tip 1 Divide and conquer break  down  complex  problems  into   smaller  chunks  that  can  be  solved   individuallyThursday, 8 November 12
  • 10. Thursday, 8 November 12
  • 11. Thursday, 8 November 12
  • 12. heavy industrialThursday, 8 November 12
  • 13. commercialThursday, 8 November 12
  • 14. light residentialThursday, 8 November 12
  • 15. Each small box represents a capability, composed of one or more services 13Thursday, 8 November 12
  • 16. And there were some, umm, interesting non-functional requirements tooThursday, 8 November 12
  • 17. 1000TPS, 99th percentile latency of < 2 seconds 15Thursday, 8 November 12
  • 18. Support a user base of 100 million active customers 16Thursday, 8 November 12
  • 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. Did I mention PCI Level 1? 18Thursday, 8 November 12
  • 21. Finally, this is a product build. So it needed to be modular / <cough> “infinitely configurable”Thursday, 8 November 12
  • 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. Plus ça change, plus cest la même chose. (The  more  things  change  the  more  they  stay  the  same)Thursday, 8 November 12
  • 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. 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. 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. 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. Tip 3 The Last Responsible Moment Don’t decide everything at the point you know leastThursday, 8 November 12
  • 29. We started with a business process… and noticed something funny…Thursday, 8 November 12
  • 30. events... 28Thursday, 8 November 12
  • 31. * Dan North coined the term Enterprise Night Bus… ESB* I know what you are thinking…Thursday, 8 November 12
  • 32. Or you could use the webThursday, 8 November 12
  • 33. Tip 4 Be of the web, not behind the webThursday, 8 November 12
  • 34. RFC 5023 to be preciseThursday, 8 November 12
  • 35. Our Users /user-requestCapability application/atom+json /user-request/1223 33Thursday, 8 November 12
  • 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. 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. 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. 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. 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. 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. 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. Where they are available for consumption by other downstream systemsThursday, 8 November 12
  • 44. Reporting capability polls for new user events Fulfilment capability polls for new user eventsThursday, 8 November 12
  • 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. CHARACTERISTICS OF MICRO- SERVICESThursday, 8 November 12
  • 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. 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. 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. 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. 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. A single capability composed of many small applications and exposing a uniform interface of Atom CollectionsThursday, 8 November 12
  • 53. How the capabilities form a productThursday, 8 November 12
  • 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. 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. Tip 6 Favour  service  choreography  over  orchestra>onThursday, 8 November 12
  • 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. Tip 7 Use hypermedia controls to decouple servicesThursday, 8 November 12
  • 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. 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. 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. Infrastructure automation stack • Fabric with boto • AWS, but deployable to anything with SSH • Maven (boo) • Git • Puppet for provisioningThursday, 8 November 12
  • 63. NO SILVER BULLETSThursday, 8 November 12
  • 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. SUMMARYThursday, 8 November 12
  • 66. The Unix Philosophy :s/pipes/hKp/   Lions commentary on Unix 2nd editionThursday, 8 November 12
  • 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. Tip 9 Always have ten tipsThursday, 8 November 12
  • 69. Thanks! @boicy jalewis@thoughtworks.comThursday, 8 November 12