Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

RESTful Microservices

988 views

Published on

The microservice architectural style is an approach to developing an application as a suite of small services that each can be independently developed and deployed. In this talk, we will cover the pros and cons of microservices, including contrasting them with the more traditional 'monolithic' application. We will also dive into the most common mechanism used to expose the functionality of a microservice. REST is an architecture style for building scalable web services. You've at least heard of it, you may have contributed to or even created 'RESTful' applications, but are you familiar with the basic constraints that make up REST? We'll cover the theory behind REST before diving into pragmatic implementation styles and better practices.

Published in: Software
  • Be the first to comment

RESTful Microservices

  1. 1. Shaun Abram Shaun Abram RESTful Microservices October 3rd, 2015
  2. 2. Shaun Abram 2 Startup: widgets.com
  3. 3. Monolith Deployed as a single artifact Scaled by replicating monolith on multiple servers Single codebase Adapted from http://martinfowler.com/articles/microservices.html
  4. 4. Shaun Abram 4 Monoliths Great. Until they’re not.
  5. 5. +Tangled Dependencies…
  6. 6. Shaun Abram 6 monoliths force everyone into the same decisions
  7. 7. Shaun Abram 7 What is a microservice? Small Focused Independent
  8. 8. Monolith Deployed as a single artifact Scaled by replicating monolith on multiple servers All functionality in a single process Microservices Deployed independentlyEach functional element as a separate service Scaled by replicating only as needed Java Scala Groovy v11 v3 v1 + resilient
  9. 9. Shaun Abram 9 Microservices - Not a new concept! Unix Philosophy  develop small, capable software  Do one thing well  Play well with other programs  Use standard interfaces
  10. 10. Shaun Abram 10 Disadvantages of microservices Monolith Microservice Operational complexity  Deployment, monitoring & problem detection
  11. 11. Shaun Abram 11 Disadvantages of microservices Monolith Microservice Refactoring across service boundaries
  12. 12. Shaun Abram 12 Disadvantages of microservices Monolith Microservice Interface changes are hard May require versioning…
  13. 13. Shaun Abram 13 Disadvantages of microservices Monolith Microservice Distributed architectures are hard!
  14. 14. Shaun Abram 15 Microservices: better practices  Separate codebases  Use monitoring  Built in health checks  Provide standard templates  Security…  Versioning…
  15. 15. Shaun Abram 16 Microservice Security  Secure Perimeter  HTTP(S) Basic Authentication  Client Certificates  HMAC  And beyond…
  16. 16. Shaun Abram 17 Microservices Versioning Backwards compatibility Tolerant Reader and Postel's Law Consumer-driven contracts Semantic Versioning Co-existing endpoints…
  17. 17. Shaun Abram 18 Microservice versioning: coexisting endpoints
  18. 18. Shaun Abram 19 Microservice versioning: coexisting endpoints
  19. 19. Shaun Abram 20 Microservice versioning: coexisting endpoints
  20. 20. Shaun Abram 21 Microservice versioning: coexisting endpoints An example of “expand and contract”
  21. 21. Shaun Abram 22 Microservices Versioning Backwards compatibility Tolerant Reader and Postel's Law Consumer-driven contracts Semantic Versioning Co-existing endpoints Co-existing servers…
  22. 22. Shaun Abram 23 Microservice versioning: coexisting servers - Duplicated code & fixes - Directing to the right service - Data versioning? + Blue Green Deployments
  23. 23. Shaun Abram 24 Microservices or Monoliths? Start with monoliths; Migrate slowly
  24. 24. Shaun Abram 25 REST Representational State Transfer
  25. 25. Shaun Abram 26 A brief History of the WWW HTTP URI HTML
  26. 26. Shaun Abram 27 REST: Lessons learned Roy Fielding packaged the lessons learned Architectural Styles and the Design of Network-based Software Architectures REST
  27. 27. Shaun Abram 28 REST So, what is REST Well… Theoretical vs Practical
  28. 28. Shaun Abram 29 REST Constraints A set of constraints. Typically with Http.
  29. 29. Shaun Abram 30 REST Constraints A set of constraints. Typically with Http. 1. Client Server
  30. 30. Shaun Abram 31 REST Constraints 1. Client Server 2. Stateless
  31. 31. Shaun Abram 32 REST Constraints 1. Client Server 2. Stateless 3. Cache
  32. 32. Shaun Abram 33 REST Constraints 1. Client Server 2. Stateless 3. Cache 4. Uniform Interface
  33. 33. Shaun Abram 34 REST Constraints 1. Client Server 2. Stateless 3. Cache 4. Uniform Interface 5. Code-On-Demand
  34. 34. Shaun Abram 35 REST Constraints 1. Client Server 2. Stateless 3. Cache 4. Uniform Interface 5. Code-On-Demand 6. Layered System
  35. 35. Shaun Abram 42 REST So, what is REST, really?
  36. 36. Shaun Abram 43 REST Resources Uniform interfaces Standard methods
  37. 37. Shaun Abram 44 <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap- envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap- encoding"> <soap:Header> <m:Trans xmlns:m="http://www.w3.com/transaction/" soap:mustUnderstand="1">234 </m:Trans> </soap:Header> <soap:Body xmlns:m="http://www.example.org/stock"> <m:GetStockPrice> <m:StockName>IBM</m:StockName> </m:GetStockPrice> </soap:Body> </soap:Envelope>
  38. 38. Shaun Abram 45 myservice.com/customers/33245
  39. 39. Shaun Abram 46 HTTP Request GET myservice.com/customers/33245 HTTP/1.1 Host: www.example.com
  40. 40. Shaun Abram 47 Is it “RESTful” enough? Richardson Maturity Model  Level 0 – Http tunnelling, POX, SOAP  e.g. all requests to myhospital.com  Level 1 – Resources  e.g. requests to hospital.com/drs/sabram  Level 2 - HTTP Verbs  GET hospital.com/drs/sabram/slots  Level 3 - Hypermedia Controls
  41. 41. Shaun Abram 48 Is it RESTful enough?
  42. 42. Shaun Abram 49 HTTP Idempotent
  43. 43. Shaun Abram 51 HTTP Methods Common  GET  DELETE  PUT  POST Uncommon  HEAD  OPTIONS  TRACE  CONNECT  PATCH
  44. 44. Shaun Abram 52 Rules of thumb  POST  Create with the server deciding on the URI  PUT  Update a resource  Store the supplied entity under the supplied URI – If exists, update; else create with that URI  PATCH  Partial updates Use you best judgment – or your corp standards!
  45. 45. Shaun Abram 53 Uncommon HTTP Methods  HEAD  Like GET but without the body  Used for obtaining meta-information about the entity  Useful for testing links, e.g. for validity, accessibility  OPTIONS  Request about the capabilities of a server  e.g. request a list of supported HTTP methods  Possible response: 200 OK; Allow: HEAD,GET,PUT,DELETE  Useful but not widely supported
  46. 46. Shaun Abram 54 Uncommon HTTP Methods  TRACE  Used to invoke a remote loop-back of the request  Plain English: Echoes back request to see what changes have been made by intermediate servers  Often disabled for security  CONNECT  For use with a proxy that can dynamically switch to being a tunnel  Typically for tunneling HTTPS through HTTP connection
  47. 47. Shaun Abram 55 HTTP response codes Code Meaning Plain English (From user perspective) 1xx Informational; indicates a provisional response, e.g. 100 OK so far and client should continue with the request 2xx Successful All good 3xx Redirection Something moved 4xx Client Error You messed up 5xx Server Error We messed up
  48. 48. Shaun Abram 56 Hypermedia as the engine of application state (HATEOAS) What is Hypermedia?  URI and URL  Hypertext  Multimedia  Hypermedia
  49. 49. Shaun Abram 57 Hypermedia as the engine of application state (HATEOAS) Clients know fixed entry points to the app Transition (states) by using those links + more If you think of Hypermedia as simply links, then HATEOAS is simply using the links you discover to navigate (or transition state) through the application. Applies to human or software users
  50. 50. Shaun Abram 58 Hypermedia as the engine of application state (HATEOAS) Example Hypermedia controls used on an album listing <album> <name>Give Blood</name> <link rel="/artist" href="/artist/theBrakes" /> <description> Awesome, short, brutish, funny and loud. Must buy! </description> <link rel="/instantpurchase" href="/instantPurchase/1234" /> </album>
  51. 51. Shaun Abram 59 Wrapping up Microservices & REST Microservices:  A small, focused, loosely coupled service  Can be developed, deployed, upgraded independently How to communicate with and between Microservices? REST & HTTP! REST:  Proven architectural style inspired by www  Resources accessed via uniform interfaces and HTTP
  52. 52. Privileged and Confidential 60 Recommended reading Domain Driven Design Freeman & Pryce Building Microservices Sam Newman REST in Practice Webber, Parastatidis, Robinson
  53. 53. Privileged and Confidential 61 Recommended reading Microservices: http://martinfowler.com/articles/microservices.html Architectural Styles and the Design of Network-based Software https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm Http API Design: https://github.com/interagent/http-api-design ParallelChange (aka expand and contract): http://martinfowler.com/bliki/ParallelChange.html Blue-Green Deployment: http://docs.pivotal.io/pivotalcf/devguide/deploy- apps/blue-green.html Richardson Maturity Model: http://martinfowler.com/articles/richardsonMaturityModel.html
  54. 54. Shaun Abram RESTful Microservices Questions?

×