The microservice architectural style is an approach to developing an application as a suite of small services that each can be independently developed and deployed. In this talk, we will cover the pros and cons of microservices, including contrasting them with the more traditional 'monolithic' application. We will also dive into the most common mechanism used to expose the functionality of a microservice. REST is an architecture style for building scalable web services. You've at least heard of it, you may have contributed to or even created 'RESTful' applications, but are you familiar with the basic constraints that make up REST? We'll cover the theory behind REST before diving into pragmatic implementation styles and better practices.
3. Monolith
Deployed as a single artifact
Scaled by replicating monolith
on multiple servers
Single codebase
Adapted from http://martinfowler.com/articles/microservices.html
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
Scaled by replicating only as needed
Java
Scala
Groovy
v11 v3
v1
+ resilient
9. Shaun Abram 9
Microservices - Not a new concept!
Unix Philosophy
ï develop small, capable software
ï§ Do one thing well
ï§ Play well with other programs
ï§ Use standard interfaces
10. Shaun Abram 10
Disadvantages of microservices
Monolith Microservice
Operational complexity
ï§ Deployment, monitoring & problem detection
14. Shaun Abram 15
Microservices: better practices
ï§ Separate codebases
ï§ Use monitoring
ï§ Built in health checks
ï§ Provide standard templates
ï§ SecurityâŠ
ï§ VersioningâŠ
22. Shaun Abram 23
Microservice versioning: coexisting servers
- Duplicated code & fixes
- Directing to the right service
- Data versioning?
+ Blue Green Deployments
26. Shaun Abram 27
REST: Lessons learned
Roy Fielding
packaged the lessons learned
Architectural Styles and the Design of Network-based Software Architectures
REST
43. Shaun Abram 51
HTTP Methods
Common
ï§ GET
ï§ DELETE
ï§ PUT
ï§ POST
Uncommon
ï§ HEAD
ï§ OPTIONS
ï§ TRACE
ï§ CONNECT
ï§ PATCH
44. Shaun Abram 52
Rules of thumb
ï§ POST
ï§ Create with the server deciding on the URI
ï§ PUT
ï§ Update a resource
ï§ Store the supplied entity under the supplied URI
â If exists, update; else create with that URI
ï§ PATCH
ï§ Partial updates
Use you best judgment â or your corp standards!
45. Shaun Abram 53
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
46. Shaun Abram 54
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
47. Shaun Abram 55
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
48. Shaun Abram 56
Hypermedia as the engine of application state (HATEOAS)
What is Hypermedia?
ï§ URI and URL
ï§ Hypertext
ï§ Multimedia
ï§ Hypermedia
49. Shaun Abram 57
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
50. Shaun Abram 58
Hypermedia as the engine of application state (HATEOAS)
Example
Hypermedia controls used on an album listing
<album>
<name>Give Blood</name>
<link rel="/artist" href="/artist/theBrakes" />
<description>
Awesome, short, brutish, funny and loud. Must buy!
</description>
<link rel="/instantpurchase" href="/instantPurchase/1234" />
</album>
51. Shaun Abram 59
Wrapping up 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
52. Privileged and Confidential 60
Recommended reading
Domain Driven Design
Freeman & Pryce
Building Microservices
Sam Newman
REST in Practice
Webber, Parastatidis, Robinson
53. Privileged and Confidential 61
Recommended reading
Microservices: http://martinfowler.com/articles/microservices.html
Architectural Styles and the Design of Network-based Software
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Http API Design: https://github.com/interagent/http-api-design
ParallelChange (aka expand and contract):
http://martinfowler.com/bliki/ParallelChange.html
Blue-Green Deployment: http://docs.pivotal.io/pivotalcf/devguide/deploy-
apps/blue-green.html
Richardson Maturity Model:
http://martinfowler.com/articles/richardsonMaturityModel.html
You probably don't know what should be a Microservice until you've built a monolith.
Separating UI from the server and data storage
allows them to evolve independently
Http:
A client server protocol
e.g. browser<->server, IoT
Separating UI from the server and data storage
allows them to evolve independently
Http:
A client server protocol
e.g. browser<->server, IoT
No state on server
Each request must contain all required info
reliability (failure recovery), scalability
HTTP:
A stateless protocol
Can circumvent by using cookies, sessions, butâŠ
Reduce latency and network traffic
responses can be labeled as cacheable or not
Which Http supports
Resources
a thing that the service itself knows about
Server creates different representations e.g. JSON
External representations decoupled from internal
Uniform interfaces
A URI identifies exactly one resource
Standard methods
GET, POST etc