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