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.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

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

  • Be the first to comment

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