1. Shaun Abram
Shaun Abram
An introduction to
Microservices and REST
November 15th, 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
The microservice architectural style is an approach to
developing a single 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)
A set of philosophical approaches to developing small
yet capable software
For example:
 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

7. Shaun Abram 7
Conway’s Law
Organizations which design systems are constrained to
produce designs which are copies of the communication
structures of these organizations
- M. Conway (1968)
In order for two software modules to interface correctly,
the developers of each must communicate. The
resulting interface will reflect the structure of the teams.
"If you have four groups working on a compiler, you'll
get a 4-pass compiler”

8. Shaun Abram 8
Why use Microservices?
 Focus on specific business functionality, not tech
 Think cross-functional, or ‘full stack’
So, what are the advantages of using microservices?

9. Shaun Abram 9
Advantages of microservices
 Small?
 Single, focused purpose
 Independently deployable
 Independently scalable, resilient

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

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

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

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

14. Shaun Abram 14
Microservice best practices
 Separate codebases
 Use monitoring
 Built in health checks
 Provide standard templates
 Support multiple versions

15. Shaun Abram 15
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"

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

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

18. Shaun Abram 18
Representational state transfer
REST is an architectural style (set of constraints)
For example:
 Relies on a stateless, client-server communications
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…

19. Shaun Abram 19
A brief History of the World Wide Web
 Tim Berners-Lee first proposed the www (1989)
 HTTP
– Formal set of rules for exchanging information over web
– Enables retrieval of linked resources
 HTML
– Ability to format docs and link to other docs/resources
 URI
– Kind of “address”, unique to each resource

20. Shaun Abram 20
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)
What version of HTTP are we on today?
Still 1.1, over 25 years later!

21. Shaun Abram 21
REST: Lessons learned
 Fielding involved since infancy of web
– HTTP, HTML, URIs, Apache HTTP Server
 Experienced first hand its rapid growth (as user+arch)
 Understood the reasons for its success
 Begin to write about lessons learned
 Web arch principles -> framework of constraints
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”.

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

23. Shaun Abram 23
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)

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

25. Shaun Abram 25
REST Constraints
1. Client Server
Separating UI concerns from data storage concerns
 Improves portability of UI across platforms
 Improves scalability by simplifying server
components
 Allows components to evolve independently
Http:
 A client server protocol
 E.g. browser <-> serving content (Apache, IIS,
Nginx)
 Or anything in the Internet of Things

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

27. Shaun Abram 27
REST Constraints
2. Stateless
 Communication must be stateless!
 Each request must contain all required info
 No state on server
Advs:
 Reliability – easier to recover from failures
 Scalability & simplification
HTTP:
 A stateless protocol
 Can circumvent by using cookies, sessions, but…

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

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

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

31. Shaun Abram 31
REST Constraints
4. Uniform Interface
 Central feature!
 Impls decoupled from the services they provide
 Encourages independent evolvability

32. Shaun Abram 32
REST Constraints
4. Uniform Interface
a) Identification of resources
b) Manipulation of resources through these
representations
c) Self-descriptive messages
d) Hypermedia as the engine of application state
(HATEOAS)

33. Shaun Abram 33
REST Constraints
4. Uniform Interface
In plain English…
 Common to use interfaces to decouple client from
impl
 Goal: Simple Interface, full functionality, hide
complexity e.g. GUI
 REST/HTTP achieves this!
myservice.com/customers/33245
 Combine with HTTP (methods, media types)
 Powerful, simple, widely understood

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
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.

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

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

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

39. Shaun Abram 39
HTTP Request
Example 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

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

41. Shaun Abram 41
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
 GET, HEAD, PUT and DELETE
 Also, OPTIONS and TRACE are inherently
idempotent

42. Shaun Abram 42
HTTP Methods
Which methods are safe AND idempotent?

43. Shaun Abram 43
Common HTTP Methods
 GET
 DELETE
 PUT
 POST

44. Shaun Abram 44
Common HTTP Methods
 GET
 Retrieve the resource identified by the URI
 DELETE
 Delete the resource identified by the URI

45. Shaun Abram 45
Common HTTP Methods
 PUT
 Store the supplied entity under the supplied URI
 If already exists, update
 If not create with that URI
 POST
 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
 In plain English, create a resource

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

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

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

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

50. Shaun Abram 50
HTTP response codes
You submit a request to the server;
At a minimum, the server will return a status code
The first digit of the status code specifies one of five
classes of response
The bare minimum for an HTTP client is that it
recognizes these five classes

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

52. Shaun Abram 52
Hypermedia as the engine of application state (HATEOAS)
Terminology:
 URI and URL
 Hypertext
 Multimedia
 Hypermedia

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

54. Shaun Abram 54
Why use REST?
 You have a need to inter process communication
 For example, client/server
 Options: RPC, SOAP/WebServices, Sockets?
 Or…

55. Shaun Abram 55
REST Summary
 An architectural style, or a set of constraints
 Captures the fundamental principles of the Web
 Tried & tested architectural approach
 Emphasizes simplicity, and existing web technologies
Key points:
 Uniform interfaces: All resources are identified by
URIs
 HTTP Methods: to manipulate all resources
 Stateless: There is no state on the server

56. Shaun Abram 56
Microservices & REST
Microservices:
 A small, focused, loosely coupled service
 Can be developed, deployed, upgraded
independently
How to communicate with and between
Microservices?
REST & HTTP!
 Uniform interfaces accessing stateless services
 Allows services to be independent of clients

57. Shaun Abram 57
How to build RESTful Microservices in Java?
 JAX-RS
 Java API for RESTful Web Services
 Java EE spec
 Implementations include:
– Jersey (reference implementation from Oracle)
– Apache CXF
– RESTeasy
 Spring MVC REST
 Not JAX-RS compliant, but…
 Still REST compliant
 Easy MVC integration

58. Shaun Abram 58
Use Embedded Servers?
 Service runs ‘out of the box’
 No need to deploy to separate server
 Deploy to a fresh server straight from VCS

59. Shaun Abram 59
Spring Boot
 “Starter Packs” of dependencies
 Convention-based configuration
 Production-ready services such as metrics, health,
app lifecycle.
 No code generation, just a pom dependency
 Spring 4 only
 Maven and Gradle plugins

60. Shaun Abram 60
DropWizard
 Packages together libraries from the Java ecosystem
 Jetty for HTTP
 Jersey for REST
 Jackson for JSON
 Lets you focus on getting things done
 Can be used with or instead of Spring Boot

61. Shaun Abram
Questions?

62. Shaun Abram 62