Microservices FTW?

Microservices FTW?

A talk on Microservices as an architecture.

Presented at Codeaholics in Hong Kong
on Wednesday 11th March 2015.

E60b2dc57668b5662ce3f07781e41710?s=128

Matthew Rudy Jacobs

March 11, 2015
Tweet

Transcript

  1. Microservices FTW? Matthew Rudy Jacobs Wednesday March 11th 2015

  2. @matthewrudy

  3. THE NEW HOTNESS!

  4. TO THE MOON!

  5. MARTIN FOWLER March 2014

  6. AND ME? March 2014 March 2015

  7. GET THE BOOK!

  8. OFF TOPIC

  9. COINCIDENCE?

  10. THE CONCEPT

  11. “THE SINGLE RESPONSIBILITY PRINCIPLE, APPLIED TO SOA”

  12. TAKE YOUR MONOLITH

  13. AND BREAK IT APART

  14. IN PRACTICE

  15. Todos Users Todos Controller Users Controller Mailer SQL Todos Users

  16. Todos Controller Todos Users Controller Users Mailer Riak Todos SQL

    Users Gateway
  17. Gateway Todos Users Mailer Auth LOTS OF LITTLE PIECES

  18. Gateway Todos Users V2 Mailer Auth EASY TO UPDATE

  19. Gateway Todos Users V2 Mailer Auth EASY TO SCALE UP

  20. Gateway Todos Mailer Auth OR SCALE DOWN Users V2

  21. Gateway Todos Mailer Auth ADD NEW FEATURES Search Users V2

  22. Golang Clojure Ruby Perl Scala USING THE RIGHT TOOLS Java

  23. Gateway Todos Users Auth AND THE RIGHT DATASTORES Riak SQL

    Mailer Search ElasticSearch
  24. COMMUNICATION

  25. Users SYNCHRONOUS POST /users {id: 123, name: “Gary”}

  26. Mailer ASYNCHRONOUS POST /todos/123/notify/complete 200 OK

  27. ORCHESTRATION VS CHOREOGRAPHY

  28. Todos Mailer ORCHESTRATION Email Call API Todo Completed

  29. Todos Mailer CHOREOGRAPHY RabbitMQ Emits Event Subscribes to Events Email

    Todo Completed
  30. HTTP+JSON GET /users/123 { id: 123, name: “Suzy”, email: “a@b.com”

    }
  31. THRIFT struct User { 1: i32 id, 2: string name,

    3: string email } service Users { User show(1:i32 id) }
  32. PROTOCOL BUFFERS message User { required int32 id = 1;

    required string name = 2; optional string email = 3; } service UserService { rpc Show (ShowRequest) returns (ShowResponse); }
  33. HTTP+JSON?

  34. PROBLEMS

  35. SERVICE TESTING IS EASY INTEGRATION TESTING IS HARD

  36. POLYGLOT PROGRAMMING HIGHER BARRIER FOR DEVS

  37. ITS EASY TO SCALE MONITORING BECOMES HARD

  38. HTTP CACHING FOR FREE LATENCY AND NETWORK ERRORS

  39. SERVICES ARE LOOSELY COUPLED CHANGING ANY API IS DIFFICULT

  40. EACH PIECE IS SIMPLE PUTTING IT TOGETHER IS COMPLEX

  41. THE SAME COMPLEXITY JUST IN DIFFERENT PLACES

  42. The Death Star http://www.slideshare.net/adriancockcroft/dockercon- state-of-the-art-in-microservices

  43. IS IT NECESSARY?

  44. https://speakerdeck.com/a_matsuda/the-recipe-for-the- worlds-largest-rails-monolith

  45. A MASSIVE MONOLITH

  46. 50 DEVELOPERS 300 SERVERS 15,000 REQUESTS / SECOND 10 DEPLOYS

    / DAY
  47. BUT…

  48. CUSTOM DB SHARDING CUSTOM TESTING SCHEME CUSTOM MIGRATION CUSTOM DEPLOYMENT

  49. MAYBE THEY’D BE BETTER OFF MICRO-SERVICED UP!

  50. THE PRAGMATIC APPROACH

  51. Create Services When You Need Them Todos Users Todos Controller

    Users Controller Mailer SQL Todos Users
  52. Todos Users Todos Controller Users Controller Mailer SQL Todos Users

    Search ElasticSearch
  53. Todos Users Todos Controller Users Controller Mailer SQL Todos Users

    Auth Search ElasticSearch
  54. Todos Users Todos Controller Users Controller SQL Todos Users Auth

    Search ElasticSearch Mailer
  55. Todos Users Todos Controller Users Controller Auth Search ElasticSearch Mailer

    Riak Todos SQL Users
  56. Auth Search ElasticSearch Mailer Users SQL Todos Riak Gateway

  57. THANKS