XX:YY

Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

For the best experience please use the latest Chrome, Safari or Firefox browser.

image/svg+xml

A Conversation about REST, Cloud Computing and Microservices

Cesare Pautasso
http://www.pautasso.info
[email protected]
@pautasso

University of Lugano (USI)

Faculty of Informatics

Architecture, Design and Web Information Systems Engineering

http://design.inf.usi.ch

A Conversation about REST, Cloud Computing and Microservices

Recent architectural trends in software engineering advocate a fine-grained decomposition of applications into loosely-coupled microservices that can be independently developed, continuously integrated and deployed in the Cloud. In this talk we look at how to recompose reusable microservices back into integrated systems using a variety of software connectors. To do so we will introduce the concept of RESTful conversation and propose RESTalk: a domain-specific, developer-friendly visual notation to model all possible correct interaction sequences (or patterns) that can be performed interacting with RESTful Web service APIs.

Abstractions

image/svg+xml Components Objects Services Resources

Microservices

Will this component
always terminate?

function f() {
     ...
     return 42;
}

Development

Will this service
run forever?

while (true) {
     on f { 
       return f() 
     };
}

Operations

Will this microservice continuously change?

while (true) {
     on f { 

-       return f()
+       //return f() 
+       return f2()
     };
}

DevOps

Microservices

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own container and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Martin Fowler and James Lewis

Microservices

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own container and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Martin Fowler and James Lewis

How small is a Microservice?

image/svg+xml

Monolith

Macro

Micro

Nano

How small is a Microservice?

One team has full control of the entire devops (code, build, test, release, deploy and operate) cycle

Iterate fast: Many small frequent releases better than few large releases

image/svg+xml Size Cost Small Large ReleaseDelay Speed RuntimeOverhead Efficiency
image/svg+xml Coupling Cost Loose Tight ReleaseDelay Speed RuntimeOverhead Efficiency

Loosely Coupled Microservices

Avoid dependencies: If you have to hold a release until some other team is ready you do not have two separate microservices

Avoid cascading failures: A failed microservice should not bring down the whole system

Decomposition

Recomposition

How to connect two microservices?

The Web as a Software Connector

image/svg+xml s→s' PUT GET PUT 200 GET 200

SOAP over HTTP

image/svg+xml s→s' POST 200 call()

grpc+proto over HTTP/2

The Web as a Tunnel

image/svg+xml s→s' POST 202Accepted send receive POST 200

HTTP-*

AsyncSync

Coupling (Time)

1:N1:1

Cardinality

Shared Web Resource

Multicast

REST/WWWMEST/ESB

ResourceQueue

Shared MemoryMessage Passing

One more difference

image/svg+xml PUT RESTful Conversation PUT GET GET GET GET DELETE

Conversations

Multiple interactions (message exchanges) between two or more participants
to achieve a goal

Gregor Hohpe

RESTful Conversations

  1. Client/Server: Clients always begin every request-response interaction
  2. Requests are addressed to URI
  3. A request message is always followed by a response message, unless the server
    is not responding (connection refused)
    or not responsive (client timeout)
  4. There may be different possible responses to the same request message. The choice is entirely up to the server.
  1. Statelessness: every request is self-contained and therefore independent of the previous ones
  2. Uniform Interface: there is a fixed set of request methods a resource can support.
    It is possible to distinguish safe (GET) or idempotent (PUT, DELETE) requests from unsafe ones (POST)
  3. Hypermedia: responses embed related URIs, which may be used to address subsequent requests

Servers control the conversation by embedding links into representations/responses

Clients drive the conversation by deciding which link to follow

Servers only reveal the immediate next steps

Clients need to understand the link relation semantics to choose which link to follow

How to Describe RESTful Conversations?

RESTalk

HTTP interaction

GET / HTTP/1.1
Host: restalk-patterns.org

HTTP/1.1 200 OK
Link: </patterns>; rel="list"
image/svg+xml GET / 200Link: /patterns Request Response

Sequential Conversation

image/svg+xml GET / 302Location: /blog GET /blog 200Link: /blog/add POST /blog/add 201Location: /blog/X 
GET / HTTP/1.1

HTTP/1.1 302 Found
Location: /blog

GET /blog HTTP/1.1

HTTP/1.1 200 OK
Link: </blog/add>; rel="add"

POST /blog/add HTTP/1.1
Slug: my post

HTTP/1.1 201 Created
Location: /blog/my-post/

Hyperlink Flow

image/svg+xml Request Response /URI Request /URI Response

Branches and Loops

image/svg+xml POST /job 202 AcceptedLocation: /job/42 GET /job/42 200 OK 303 See OtherLocation: /job/42/output GET /job/42/output 200 OK 
POST /job HTTP/1.1

HTTP/1.1 202 Accepted
Location: /job/42

GET /job/42 HTTP/1.1

HTTP/1.1 200 OK

GET /job/42 HTTP/1.1

HTTP/1.1 303 See Other
Location: /job/42/output

GET /job/42/output HTTP/1.1

HTTP/1.1 200 OK

RESTalk

RESTful Conversation Patterns

One more thing

Microservices

Microservices prefer letting each service manage its own database, either different instances of the same database technology, or entirely different database systems - an approach called Polyglot Persistence.

M. Fowler, J. Lewis https://www.martinfowler.com/articles/microservices.html

Eventual Inconsistency

Microservice architectures are doomed to become inconsistent after disaster strikes

Where to go next?

 RESTful Conversation Patterns The BAC Theorem (Microservices and Disaster Recovery)

Devops meets Disaster Recovery

image/svg+xml Backup Recover Code Build Test Release Plan Deploy Monitor Operate

How do you back up a monolith?

image/svg+xml Monolith Database Backup

How do you back up one microservice?

image/svg+xml microservice Database Backup

How do you back up
an entire microservice architecture?

image/svg+xml MySQL MongoDB Neo4J Redis

Are you sure?

Example

image/svg+xml Customer Product Shipment Order

Data relationships across microservices = Hypermedia

Independent Backup

image/svg+xml new C/1 C/1/name new C/2 C/2/name C/3/name new C/3 new O/3 O/3 → C/3 new O/1 O/1 → C/1 new O/2 O/2 → C/2 new O/3 O/3 → C/3 Customer Order new C/1 1 2 3 4 C/1/name new C/2 5 6 C/2/name new O/1 1 2 3 4 O/1 → C/1 new O/2 5 6 O/2 → C/2 1 2 3 4 5 6 1 2 3 4 5 6

Backups taken independently at different times

Disaster Strikes

Disaster Strikes

image/svg+xml new O/1 O/1 → C/1 new O/2 O/2 → C/2 new O/3 O/3 → C/3 new C/1 C/1/name new C/2 C/2/name Customer Order new C/1 1 2 3 4 C/1/name new C/2 5 6 C/3/name C/2/name new C/3 new O/1 1 2 3 4 O/1 → C/1 new O/2 5 6 new O/3 O/2 → C/2 O/3 → C/3 1 2 3 4 5 6 1 2 3 4 5 6

One microservice is lost

Recovery from Backup

image/svg+xml new O/1 O/1 → C/1 new O/2 O/2 → C/2 new O/3 O/3 → C/3 new C/1 C/1/name new C/2 C/2/name Customer Order 1 2 3 4 5 6 new O/1 1 2 3 4 O/1 → C/1 new O/2 5 6 new O/3 O/2 → C/2 O/3 → C/3 1 2 3 4 5 6 1 2 3 4 5 6 new C/1 C/1/name new C/2 C/2/name O/1 → C/1 O/2 → C/2

Broken link after recovery

Eventual Inconsistency

Synchronized Backups

image/svg+xml Customer Order new C/1 1 2 3 4 C/1/name new C/2 5 6 C/2/name new O/1 1 2 3 4 O/1 → C/1 new O/2 5 6 O/2 → C/2 new C/1 1 2 3 4 C/1/name new C/2 5 6 C/2/name new O/1 1 2 3 4 O/1 → C/1 new O/2 5 6 O/2 → C/2

Backups of all microservices taken at the same time.

Limited Availability

image/svg+xml Customer Order new C/1 1 2 3 4 C/1/name new C/2 5 6 C/2/name new O/1 1 2 3 4 O/1 → C/1 new O/2 5 6 O/2 → C/2 new C/1 1 2 3 4 C/1/name new C/2 5 6 C/2/name new O/1 1 2 3 4 O/1 → C/1 new O/2 5 6 O/2 → C/2

No updates allowed anywhere while backing up the microservices

The BAC theorem

When Backing up a microservice architecture,
it is not possible to have both
Consistency and Availability

Consistency

During normal operations, each microservice will eventually reach a consistent state

Referential integrity: links across microservice boundaries are guaranteed not to be broken

Availability

It is possible to both read and update the state of any microservice at any time

Backup

While backing up the system, is it possible to take a consistent snapshot of all microservices without affecting their availability?

No.

Backup + Availability

Backing up each microservice independently will eventually lead to inconsistency after recovering from backups taken at different times

Backup + Consistency

Taking a consistent backup requires to:

Shared Database

image/svg+xml Customer Product Shipment Order

A centralized, shared database would require only one backup

Is this still a microservice architecture?

Shared Database, Split Schema

image/svg+xml Customer Product Shipment Order C O S P

A centralized, shared database would require only one backup

Each microservice must use a logically separate schema

What happened to polyglot persistence?

Splitting the Monolith

image/svg+xml Customer Product Shipment Order

Keep data together for microservices that cannot tolerate eventual inconsistency

Unstoppable System

image/svg+xml Customer Product Shipment Order

An expensive, replicated database with high-availability for every microservice

Unstoppable System

How do you restart an unstoppable system?

Does it apply to you?

More than one stateful microservice

Polyglot persistence

Cross-microservice references

Disaster recovery based on backup/restore

Independent backups

Eventual inconsistency (after disaster recovery)

Does it apply to you?

More than one stateful microservice

Polyglot persistence

Cross-microservice references

Disaster recovery based on backup/restore

Synchronized backups (limited availability)

Consistent Disaster Recovery

Eventual Consistency

Retries are enough to deal with temporary failures of read operations, eventually the missing data will be found

Eventual Inconsistency

Retries are useless to deal with permanent failures of read operations, which used to work just fine before disaster recovery

The BAC Theorem

image/svg+xml Consistency Availability Backup CA CB AB Not Consistent Not Availablefor updates Not Backed Up .
Jump to Conclusion

Which RESTful conversation pattern would you like to discuss?

 POST New Collection Item POST Once Exactly POST-PUT Creation Long Running Operation with Polling Server-side Redirection with Status Codes Client-side Navigation following Hyperlinks Incremental Collection Traversal (Partial) Resource Editing Conditional Update for Large ResourcesBasic Authentication Cookie-based Authentication

How to discover how to create a resource within a collection?

POST New Collection Item

Ask the server

POST New Collection Item

POST New Collection Item

Client discovers form with new resource attributes

Server determines new resource URI

Client must understand media type schema

What if the POST fails?

How to avoid creating duplicate resources?

POST-PUT Creation

POST Once Exactly

POST-PUT Creation

True or False?

 The client can send POST requests multiple times The client knows the link to the created resource before the start of the conversation

POST-PUT Creation

POST Once Exactly

What if the client times out because the server is taking too long to reply?

Long Running Operation with Polling

Long Running Operation with Polling

Long Running Operation with Polling

Clients can share the URI with the results

Clients can cancel the long running operation

Polling: how frequently?

Garbage collection

True or False?

 The job output resource gets automatically deleted once the client has read it once The client can read the job output multiple times The client must delete the job output after reading it

Long Running Operation with Polling

How to decouple clients from evolving resource URIs?

Server-side Redirection with Status Codes

Server-side Redirection with Status Codes

Server-side Redirection with Status Codes

Avoid breaking clients

Refer to server "nearest" to the client

Redirect can be temporary or permanent

Can your client be redirected any time?

Latency may increase

How to avoid hard-coding resource URIs into clients?

Client-side Navigation following Hyperlinks

Client-side Navigation following Hyperlinks

Client-side Navigation following Hyperlinks

Loose Coupling

Standardize Link Relation Semantics

Latency may increase

How to let a client retrieve some items of large collections?

Incremental Collection Traversal

Hypermedia

Incremental Collection Traversal

Incremental Collection Traversal

Save bandwidth

Cannot guarantee consistency

How to discover how to edit a resource?

(Partial) Resource Editing

(Partial) Resource Editing

(Partial) Resource Editing

Client discovers form with editable resource attributes

Idempotent full updates with PUT

Client must understand media type schema

PATCH is not idempotent

How to efficiently check if updates are possible?

Conditional Update for Large Resources

Declare client expectations

Conditional Update for Large Resources

Conditional Update for Large Resources

Save bandwidth, avoid bad requests

HTTP/1.1 Support Required
(otherwise 417 Expectation Failed)

Look Before You Leap

How to authenticate and authorize clients?

Protected Resources

Basic Authentication

Cookie-based Authentication

Basic Authentication

RESTful Conversation Patterns

Conclusion

REST

image/svg+xml s→s' StateTransition State Transfer

Conclusion

The BAC Theorem

When Backing up a whole microservice architecture, it is not possible to have both Consistency and Availability

Corollaries

  1. Microservice architectures eventually become inconsistent after disaster strikes when recovering from independent backups
  2. Achieving consistent backups can be attempted by limiting the full availability of the system and synchronizing the backups

Outlook

  1. RESTalk with Multi-party Conversations
  2. RESTful Conversation Mining
  3. More RESTful Conversation Patterns
  4. Dealing with the consequences of the BAC theorem

References

Made with

http://asq.inf.usi.ch

Cloudware Engineering

IEEE Software - Special Issue

Call for Articles

Deadline: 1 April 2018

https://www.computer.org/software-magazine/2017/07/19/cloudware-engineering-call-for-papers/

Acknowledgements

Frank Leymann, Olaf Zimmermann, Florian Haupt, Silvia Schreier, Ana Ivanchikj, Guy Pardon, Mathias Weske, Adriatik Nikaj, Sankalita Mandal, Hagen Overdick, Jesus Bellido, Rosa Alarcón, Alessio Gambi, Daniele Bonetta, Achille Peternier, Erik Wilde, Mike Amundsen, Stefan Tilkov, James Lewis

image/svg+xml s→s' RepresentationalState Transfer PUT GET GET GET s→s' MessageBus(Multicast) send receive receive receive
image/svg+xml s→s' MessageBus send receive s→s' RepresentationalState Transfer PUT GET s→s' call() Remote ProcedureCall (Poll) s' s→s' callback(s') Remote ProcedureCallback (Push)

Use a spacebar or arrow keys to navigate

Powered by
asq