Micro Services: Java, the Unix Way

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.

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

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

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

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

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

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

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

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

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

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