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.

1. Shaun Abram
Shaun Abram
RESTful Microservices
October 3rd, 2015

2. Shaun Abram 2
Startup: widgets.com

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. Shaun Abram 4
Monoliths
Great.
Until they’re not.

5. +Tangled Dependencies…

6. Shaun Abram 6
monoliths force everyone
into the same decisions

7. Shaun Abram 7
What is a microservice?
Small
Focused
Independent

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. 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. Shaun Abram 10
Disadvantages of microservices
Monolith Microservice
Operational complexity
 Deployment, monitoring & problem detection

11. Shaun Abram 11
Disadvantages of microservices
Monolith Microservice
Refactoring across service boundaries

12. Shaun Abram 12
Disadvantages of microservices
Monolith Microservice
Interface changes are hard
May require versioning…

13. Shaun Abram 13
Disadvantages of microservices
Monolith Microservice
Distributed architectures are hard!

14. Shaun Abram 15
Microservices: better practices
 Separate codebases
 Use monitoring
 Built in health checks
 Provide standard templates
 Security…
 Versioning…

15. Shaun Abram 16
Microservice Security
 Secure Perimeter
 HTTP(S) Basic Authentication
 Client Certificates
 HMAC
 And beyond…

16. Shaun Abram 17
Microservices Versioning
Backwards compatibility
Tolerant Reader and Postel's Law
Consumer-driven contracts
Semantic Versioning
Co-existing endpoints…

17. Shaun Abram 18
Microservice versioning: coexisting endpoints

18. Shaun Abram 19
Microservice versioning: coexisting endpoints

19. Shaun Abram 20
Microservice versioning: coexisting endpoints

20. Shaun Abram 21
Microservice versioning: coexisting endpoints
An example of “expand and contract”

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. Shaun Abram 23
Microservice versioning: coexisting servers
- Duplicated code & fixes
- Directing to the right service
- Data versioning?
+ Blue Green Deployments

23. Shaun Abram 24
Microservices or Monoliths?
Start with monoliths; Migrate slowly

24. Shaun Abram 25
REST
Representational State Transfer

25. Shaun Abram 26
A brief History of the WWW
HTTP URI HTML

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. Shaun Abram 28
REST
So, what is REST
Well…
Theoretical vs Practical

28. Shaun Abram 29
REST Constraints
A set of constraints. Typically with Http.

29. Shaun Abram 30
REST Constraints
A set of constraints. Typically with Http.
1. Client Server

30. Shaun Abram 31
REST Constraints
1. Client Server
2. Stateless

31. Shaun Abram 32
REST Constraints
1. Client Server
2. Stateless
3. Cache

32. Shaun Abram 33
REST Constraints
1. Client Server
2. Stateless
3. Cache
4. Uniform Interface

33. Shaun Abram 34
REST Constraints
1. Client Server
2. Stateless
3. Cache
4. Uniform Interface
5. Code-On-Demand

34. Shaun Abram 35
REST Constraints
1. Client Server
2. Stateless
3. Cache
4. Uniform Interface
5. Code-On-Demand
6. Layered System

35. Shaun Abram 42
REST
So, what is REST, really?

36. Shaun Abram 43
REST
Resources
Uniform interfaces
Standard methods

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. Shaun Abram 45
myservice.com/customers/33245

39. Shaun Abram 46
HTTP Request
GET
myservice.com/customers/33245
HTTP/1.1
Host: www.example.com

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. Shaun Abram 48
Is it RESTful enough?

42. Shaun Abram 49
HTTP
Idempotent

43. Shaun Abram 51
HTTP Methods
Common
 GET
 DELETE
 PUT
 POST
Uncommon
 HEAD
 OPTIONS
 TRACE
 CONNECT
 PATCH

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. 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. 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. 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. Shaun Abram 56
Hypermedia as the engine of application state (HATEOAS)
What is Hypermedia?
 URI and URL
 Hypertext
 Multimedia
 Hypermedia

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. 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. 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. Privileged and Confidential 60
Recommended reading
Domain Driven Design
Freeman & Pryce
Building Microservices
Sam Newman
REST in Practice
Webber, Parastatidis, Robinson

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. Shaun Abram
RESTful Microservices
Questions?