rest and microservices at the las vegas dot net group
TRANSCRIPT
Shaun Abram
Shaun Abram
An introduction to
Microservices and REST
March 26th, 2014
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
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
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…
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?
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?
Shaun Abram 7
Characteristics of microservices
Small?
Single, focused purpose
Independently deployable
Independent technology stack
Independently scalable, resilient
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
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
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
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
Shaun Abram 12
Microservice best practices
Separate codebases
Use monitoring
Built in health checks
Provide standard templates
Versioning?
Security
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
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"
Shaun Abram 15
An introduction to Microservices and REST
Microservices
REST
Shaun Abram 16
REST
A brief history of www
What was learned?
What is REST? Constraints!
HTTP
HATEOAS
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…
Shaun Abram 18
A brief History of the World Wide Web
Tim Berners-Lee first proposed the www (1989)
HTTP HTML URI
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
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”.
Shaun Abram 21
REST
So, what is REST
An architectural style
A set of constraints
Why constraints?
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)
Shaun Abram 23
REST Constraints
1. Client Server
2. Stateless
3. Cache
4. Uniform Interface
5. Layered System
6. Code-On-Demand
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
Shaun Abram 25
REST Constraints
1. Client Server
2. Stateless
3. Cache
4. Uniform Interface
5. Layered System
6. Code-On-Demand
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…
Shaun Abram 27
REST Constraints
1. Client Server
2. Stateless
3. Cache
4. Uniform Interface
5. Layered System
6. Code-On-Demand
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
Shaun Abram 29
REST Constraints
1. Client Server
2. Stateless
3. Cache
4. Uniform Interface
5. Layered System
6. Code-On-Demand
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…?
Shaun Abram 31
myservice.com/customers/33245
Shaun Abram 32
REST Constraints
1. Client Server
2. Stateless
3. Cache
4. Uniform Interface
5. Layered System
6. Code-On-Demand
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.
Shaun Abram 34
REST Constraints
1. Client Server
2. Stateless
3. Cache
4. Uniform Interface
5. Layered System
6. Code-On-Demand
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
Shaun Abram 36
HTTP
Requests & Responses
Methods
Status codes
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
Shaun Abram 38
HTTP Methods
Common methods
GET
DELETE
PUT
POST
Uncommon methods
HEAD
OPTIONS
TRACE
CONNECT
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
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!
Shaun Abram 41
Uncommon HTTP Methods
HEAD
OPTIONS
TRACE
CONNECT
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
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
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
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
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
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
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
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
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
Shaun Abram 51
Hypermedia as the engine of application state (HATEOAS)
What is Hypermedia?
URI and URL
Hypertext
Multimedia
Hypermedia
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
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
Stateless
Shaun Abram
Questions?
Shaun Abram 55