Shaun Abram
Shaun Abram
RESTful Microservices
October 3rd, 2015

Shaun Abram 2
Startup: widgets.com

Monolith
Deployed as a single artifact
Scaled by replicating monolith
on multiple servers
Single codebase
Adapted from http://martinfowler.com/articles/microservices.html

Shaun Abram 4
Monoliths
Great.
Until they’re not.

+Tangled Dependencies…

Shaun Abram 6
monoliths force everyone
into the same decisions

Shaun Abram 7
What is a microservice?
Small
Focused
Independent

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

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

Shaun Abram 10
Disadvantages of microservices
Monolith Microservice
Operational complexity
 Deployment, monitoring & problem detection

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

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

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

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

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

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

Shaun Abram 18
Microservice versioning: coexisting endpoints

Shaun Abram 19
Microservice versioning: coexisting endpoints

Shaun Abram 20
Microservice versioning: coexisting endpoints

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

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

Shaun Abram 23
Microservice versioning: coexisting servers
- Duplicated code & fixes
- Directing to the right service
- Data versioning?
+ Blue Green Deployments

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

Shaun Abram 25
REST
Representational State Transfer

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

Shaun Abram 27
REST: Lessons learned
Roy Fielding
packaged the lessons learned
Architectural Styles and the Design of Network-based Software Architectures
REST

Shaun Abram 28
REST
So, what is REST
Well…
Theoretical vs Practical

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

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

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

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

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

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

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

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

Shaun Abram 43
REST
Resources
Uniform interfaces
Standard methods

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>

Shaun Abram 45
myservice.com/customers/33245

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

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

Shaun Abram 48
Is it RESTful enough?

Shaun Abram 49
HTTP
Idempotent

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

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!

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

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

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

Shaun Abram 56
Hypermedia as the engine of application state (HATEOAS)
What is Hypermedia?
 URI and URL
 Hypertext
 Multimedia
 Hypermedia

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

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>

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

Privileged and Confidential 60
Recommended reading
Domain Driven Design
Freeman & Pryce
Building Microservices
Sam Newman
REST in Practice
Webber, Parastatidis, Robinson

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

Shaun Abram
RESTful Microservices
Questions?