The microservice architectural style is an approach to developing an application as a suite of small services. Each can be independently developed and deployed. This presentation covers the pros and cons of microservices, including contrasting with the more traditional 'monolithic' application. We also dive into the most common mechanism used to expose their functionality: RESTful APIs, including a discussion of HTTP and its components.

1. Shaun Abram
Shaun Abram
An introduction to
Microservices and REST
March 26th, 2014

2. Shaun Abram 2
Microservices
What is a microservice?
 A small, focused piece of software
 Independently developed, deployed, upgraded
 Commonly exposes it functionality via HTTP/REST

3. Shaun Abram 3
Microservices - definition
Small, autonomous services that work together
- “Building Microservices” by Sam Newman
An approach to developing an application as a suite of
small services, each running in its own process and
communicating with lightweight mechanisms, often an
HTTP resource API
- “Microservices” by Martin Fowler and James Lewis

4. Shaun Abram 4
Microservices - Not a new concept!
Unix Philosophy (1984)
 develop small, capable software
 Do one thing well
 Play well with other programs
 Use standard interfaces
Contrasts with Monoliths…

5. Shaun Abram 5
The Monolithic Architecture
An application built & deployed as a single artifact
 Easy to setup - single project in an IDE
 Easy to deploy - a single war file
 Scaled horizontally (load balanced servers)
Keep things simple! YAGNI?

6. Shaun Abram 6
Problems with Monoliths
 Slow to build
 Too big to easily understand
 Forced team dependencies
 How do you split up teams?
 Obstacle to frequent deployments
 Long-term commitment to a technology stack
Time for a different approach?

7. Shaun Abram 7
Characteristics of microservices
 Small?
 Single, focused purpose
 Independently deployable
 Independent technology stack
 Independently scalable, resilient

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
Deployed across servers and
replicated as needed
Source: http://martinfowler.com/articles/microservices.html

9. Shaun Abram 9
Disadvantages of microservices
 Distributed architectures are hard!
 Refactoring across service boundaries
 Interface changes are hard
 Use flexible, forgiving, broad interfaces
 Be as tolerant as possible
 “Be conservative in what you do, liberal in what you
accept”— Jon Postel
 Operational complexity
e.g. monitoring and problem detection

10. Shaun Abram 10
Microservices vs SOA
Both architectural design patterns;
Collections of services
Microservices are:
 SOA done right?
 SOA but with a bounded context?
SOA Microservices
Integrates multiple applications Multiple microservices = one app
ESB smart endpoints, dumb pipes
SOAP, XML, WSDL etc REST, JSON etc

11. Shaun Abram 11
Who is using Microservices?
Many large scale web sites have evolved from
monolith to microservices
 Amazon
 100-150 services per page
 Netflix
 Extensive users and contributors
 Chaos Monkey, Janitor Monkey, see netflix.github.io.
 TicketMaster
 Boardroom agility -> quickly react to the marketplace

12. Shaun Abram 12
Microservice best practices
 Separate codebases
 Use monitoring
 Built in health checks
 Provide standard templates
 Versioning?
 Security

13. Shaun Abram 13
Microservice Security
 Single Sign On (SSO)
 SAML or OpenID Connect
 SSO Gateway
 API Keys
 Secure Perimeter
 HTTP(S) Basic Authentication
 Client Certificates
 HMAC

14. Shaun Abram 14
Microservices Summary
+ Attractive alternative to monoliths
+ Independently built and deployed stacks
+ Allows 'deploy early, deploy often'
- No silver Bullet!
- Coordination of dozens of services is difficult
- Integration, deployment, monitoring all more complex
- Need cross functional teams skilled in Devops
Start with monoliths; Migrate slowly
"With cautious optimism, we think microservices can be a worthwhile road to tread"

15. Shaun Abram 15
An introduction to Microservices and REST
 Microservices
 REST

16. Shaun Abram 16
REST
 A brief history of www
 What was learned?
 What is REST? Constraints!
 HTTP
 HATEOAS

17. Shaun Abram 17
Representational state transfer
REST is an architectural style (set of constraints)
 Relies on a stateless, client-server comm protocol
think: HTTP
 Uniform interfaces
think: URIs, or links
 Interaction with resources via standard methods
think: HTTP verbs
Pretty URLs? Alternative to RPC or SOAP?
Yes, but so much more…

18. Shaun Abram 18
A brief History of the World Wide Web
Tim Berners-Lee first proposed the www (1989)
HTTP HTML URI

19. Shaun Abram 19
A brief History of the World Wide Web
 HTTP 0.9 (1991)
 only one method: GET
 HTTP 1.0 (1996)
 From trivial request/response true msging protocol
 HTTP 1.1 (1996)
Today?
 HTTP 2 (draft, 2015)
 1.1 compatibility with methods, codes, URIs, (most)
header fields

20. Shaun Abram 20
REST: Lessons learned
 Fielding involved since infancy of web
– HTTP, HTML, URIs, Apache HTTP Server
 Experienced first hand its rapid growth (as user+arch)
Architectural Styles and the Design of Network-based
Software Architectures (2000)
“REST has been used to guide the design and development of the
architecture for the modern Web”.

21. Shaun Abram 21
REST
So, what is REST
An architectural style
A set of constraints
Why constraints?

22. Shaun Abram 22
REST Constraints
1. Client Server
2. Stateless
3. Cache
4. Uniform Interface
5. Layered System
6. Code-On-Demand
REST doesn't have to use HTTP, but…
(alternatives? Gopher, waka, SPDY)

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

24. Shaun Abram 24
REST Constraints
1. Client Server
Separating UI from data storage
 portability, scalability, evolve independently
Http:
 A client server protocol
 e.g. browser<->server, IoT

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

26. Shaun Abram 26
REST Constraints
2. Stateless
 Communication must be stateless!
 Each request must contain all required info
 No state on server
reliability (failure recovery), scalability
HTTP:
 A stateless protocol
 Can circumvent by using cookies, sessions, but…

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

28. Shaun Abram 28
REST Constraints
3. Cache
 Response can be labeled as cacheable or not
 If cacheable, client cache can reuse response
HTTP:
 Supports caching via three basic mechanisms:
 freshness
 validation
 invalidation

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

30. Shaun Abram 30
REST Constraints
4. Uniform Interface
to identify and manipulate resources
In plain English…
 Common to use interfaces to decouple client from
impl
 Goal: Simple Interface, full functionality, hide
complexity e.g. GUI
 How does REST achieve this…?

31. Shaun Abram 31
myservice.com/customers/33245

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

33. Shaun Abram 33
REST Constraints
5. Layered System
 Allows an architecture to be composed of layers
 Constraining component behavior
 Each component cannot “see” beyond immediate
layer
 Client unaware if connected to the end or
intermediary improve scalability (e.g. load-balancing),
security
 HTTP supports layering via proxy servers and
caching.

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

35. Shaun Abram 35
REST Constraints
6. Code-On-Demand (optional)
 Client functionality can be extended (scripts/applets)
 Allows server to decide how some things will be done
 For example
 client requests a resource,
 server returns resource with some JavaScript

36. Shaun Abram 36
HTTP
 Requests & Responses
 Methods
 Status codes

37. Shaun Abram 37
HTTP Request
GET /index.html HTTP/1.1
Host: www.example.com
This is made up of the following components:
 Method: GET
 URI: /index.html
 Version: HTTP/1.1
 Headers: Host: www.example.com
 Body: empty in this example

38. Shaun Abram 38
HTTP Methods
Common methods
 GET
 DELETE
 PUT
 POST
Uncommon methods
 HEAD
 OPTIONS
 TRACE
 CONNECT

39. Shaun Abram 39
Common HTTP Methods
 POST
 In plain English, create a resource
 Request to accept the entity as a new subordinate of
the resource identified by the URI
 For example
– Submit data from a form to a data-handling process;
– Post a message to a mailing list or blog
 PUT
 In plain English, update a resource
 Store the supplied entity under the supplied URI
– If already exists, update
– If not create with that URI

40. Shaun Abram 40
PUT vs POST: What is the difference?!
Some rules of thumb:
 PUT is for update; POST is for create
 PUT idempotent; POST is not;
 Who creates the URL of the resource?
 PUT when you know the URL to be created
 POST when server decides the URL for you
 Don’t use PUT, always POST (post events instead)?
Short answer? Use you best judgment!

41. Shaun Abram 41
Uncommon HTTP Methods
 HEAD
 OPTIONS
 TRACE
 CONNECT

42. Shaun Abram 42
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

43. Shaun Abram 43
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

44. Shaun Abram 44
HTTP Methods
Safe and Idempotent methods
Safe methods
 Do not modify resources – retrieval only
 HEAD, GET, OPTIONS and TRACE
Idempotent methods
 Can be called many times, same outcome
 All the safe methods
 Plus PUT and DELETE

45. Shaun Abram 45
HTTP Response
Example HTTP response:
HTTP/1.1 200 OK Version/Status code; Reason
phrase
Date: Mon, 23 May 2005 22:38:34 GMT Headers
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
ETag: "3f80f-1b6-3e1cb03b”
Content-Type: text/html; charset=UTF-8
Content-Length: 131
Accept-Ranges: bytes
Connection: close
<html> … </html> Body

46. Shaun Abram 46
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

47. Shaun Abram 47
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

48. Shaun Abram 48
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

49. Shaun Abram 49
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

50. Shaun Abram 50
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

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

52. Shaun Abram 52
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

53. Shaun Abram 53
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

54. Shaun Abram
Questions?

55. Shaun Abram 55