2. Microservices rely heavily on REST. Therefore, the first half
of slides covers a review of basic REST concepts.
If you are familiar with REST feel free to jump to slide 24.
The content of this presentation is based on several external
articles, books and presentations. See the bibliography on
the last slide.
3. 3/44
Component software
Software components are binary units of independent production,
acquisition, and deployment that interact to form a functioning system.
Clemens Szyperski
A component is a unit of software that is independently replaceable and
upgradeable.
Martin Fowler
4. 4/44
Componentization via Libraries
● The most popular approach to component-based software
engineering
● There are technologies that enable independent deployment,
encapsulation and loose coupling between libraries (e.g. OSGi,
Project Jigsaw), but they are not very popular in the industry.
● In practice, even if an application is build of multiple components, it is
packaged and deployed as monolith, i.e. as a single archive (e.g.
WAR or EAR).
5. 5/44
Monolithic applications
● Client code has access to the whole component implementation
● Often it's only documentation and discipline that prevents clients breaking a
component's encapsulation, leading to overly-tight coupling between
components.
● Change cycles are tied together - a change made to a small part of the
application, requires the entire monolith to be rebuilt and deployed.
● Scaling requires scaling of the entire application rather than parts of it that
require greater resource.
6. 6/44
Componentization via Web Services
● Services are independently replaceable and upgradeable. Changes to a
single service, require only that service to be repackaged and redeployed.
● Remote calls make it easier to keep components loosely coupled.
● Remote calls are more expensive than in-process calls, and thus remote APIs
need to be coarser-grained.
● Each service provides a firm module boundary, in terms of responsibility and
in terms of technology
● There are many types of Web Services. Some of them support
componentization more than others.
7. 7/44
World Wide Web
● Created by Tim Berners-Lee in the early 1990s while he was a research fellow at CERN.
● Definition according to the Architecture of the World Wide Web document by W3C:
– The World Wide Web (WWW, or simply Web) is an information space in which the items of interest,
referred to as resources, are identified by global identifiers called Uniform Resource Identifiers
(URI)
●
The Architecture is relatively short document that describes some key principles of the Web:
– Web agents are acting on this information space. They can be peoples (user agents) or software (e.g.
servers, proxies, browsers or multimedia players).
– The agents communicate using standardized protocols that enable interaction through the
exchange of messages which adhere to a defined syntax and semantics.
– Agents exchange resource representations, a view of a resource's state at an instant in time. They
never access the underlaying resource directly. The same resource, with a single URI, can have
multiple different representations (e.g. plain-text, HTML and PDF).
– Hypertext – A defining characteristic of the Web is that it allows embedded references to other
resources via URIs.
● Popular Web's protocols: HTTP, FTP or SMTP
8. 8/44
The Hypertext Transfer Protocol
● RFC 2616 – Hypertext Transfer Protocol – HTTP/1.1
● Idempotent Methods – the side-effects of multiple identical requests is the same as for a
single request
● Safe methods – not taking an action other than retrieval
Method Idempotent Safe
OPTIONS yes yes
GET yes yes
HEAD yes yes
PUT yes no
POST no no
DELETE yes no
PATCH no no RFC 5789
9. 9/44
HTTP response codes
● 1xx: Informational – Request received, continuing process
● 2xx: Success – The action was successfully received, understood, and accepted
– 200 – OK
– 201 – Created
– 204 – No Content
●
3xx: Redirection – Further action must be taken in order to complete the request
● 4xx: Client Error – The request contains bad syntax or cannot be fulfilled
– 404 – Not found
– 405 – Method not allowed
– 409 – Conflict
● 5xx: Server Error – The server failed to fulfill an apparently valid request
– 503 – Service unavailable
10. 10/44
Richardson Maturity Model
[L. Richardson, Justice Will Take Us Millions Of Intricate Moves, Qcon, 2008]
Level Description
3 Hypermedia
2 Multiple URI, multiple HTTP methods
1 Multiple URI, single HTTP method
0 Single URI, single HTTP method
Leonard Richardson proposed a classification for services on the Web.
11. 11/44
Level 0 services
● All service operations are exposed via a single URI.
● Level zero services use the Web only as a tunneling technology or as a
transport layer.
● Technologies:
– SOAP-based services a.k.a. WS-* web services
– Plain Old XML (POX) – like SOAP but without the SOAP envelope or any of
the other baggage.
– XML-RPC
12. 12/44
WS-* stack
● SOAP-based Web Services
● Began to be popular around year 2000.
● Integration based on open standards.
● Most often, SOAP uses HTTP as transport protocol, but in general SOAP messages can
be routed through any transport protocols.
● SOAP do not leverage HTTP application protocol features. It uses single URL and only
one HTTP method (POST).
● WS-* can not use web caching (because of POST).
● WSDL describes a service. It can be generated automatically. The service stub can be
generated from WSDL.
● Mainstream WSDL tooling promotes poor design practices, like tight coupling
[Graphic taken from Wikipedia]
14. 14/44
Level 1 services
● Multiple URI, single HTTP method (often POST)
● Mapping business objects to resources
● URI tunneling – mapping URI template to the server side method or function
– URI templates
● http://service.com/get_order/{order_id}
● http://service.com/search/{year}/{month}/{day}
– URIs are used to encode operations rather then to represent resources itself
● Many services, that claim that they are RESTfull, are in fact just level one
services!
15. 15/44
Level 2 services
● Multiple URI, multiple HTTP methods
● Use of GET and DELETE methods is straightforward
● It is not obvious when to use PUT and when to use POST. In general:
– Use POST to create a resource identified by a service-generated URI
– Use PUT to create or overwrite a resource identified by a URI computed by the
client
● PUT expects the entire resource representation to be supplied to the server, rather than
just changes to the resource state.
● 200 vs 204 – aesthetic choice
● PATCH method (introduced in 2010)– “to apply partial modifications to an [existing]
resource”
● Level 2 services can be described using WADL
16. 16/44
REpresentational State Transfer – REST
● Through the years, the Web transitioned from the information publishing
platform to the distributed application platform.
● REST was defined by Roy T. Fielding in his PhD dissertation Architectural Styles
and the Design of Network-based Software Architectures in 2000.
● Roy Fielding is a co-founder of the Apache HTTP Server project.
● Generalization of the Web's architecture into distributed application platform
● Classic application is a state machine with finite set of states and transitions.
● REST application is a machine with unknown states and transitions!
● When machine reaches new state, new transitions are discovered.
● Hypermedia is a generalization of hypertext
17. 17/44
Level 3 - HATEOAS
● HATEOAS - Hypermedia As The Engine Of Application State
● Application state is inferred by the consumer based on the state of all the resources
– potentially distributed across many services – with witch the consumer is currently
interacting.
● Domain Application Protocol (DAP) specifies legal interactions between the
consumer and a set of resources involved in a business process.
● Services implement DAPs by adding hypermedia links to resource representations.
● There is no workflow or business logic for the DAP as such. Rather, the service
governs the life cycles of particular resources.
● Each service should have a single entry point.
● JAX-RS since version 2.0 supports HATEOAS!
18. 18/44
RESTfull service example - Neo4j API
● Service root: http://localhost:7474/db/data
● When invoke $wget --header='Accept: text/html' http://localhost:7474/db/data
then you get a simple introductory HTML web site
● When invoke $wget --header='Accept: application/json' http://localhost:7474/db/data
then you get a JSON document with available linked resources:
{
"extensions" : {},
"node" : "http://localhost:7474/db/data/node",
"node_index" : "http://localhost:7474/db/data/index/node",
"relationship_index" : "http://localhost:7474/db/data/index/relationship",
"extensions_info" : "http://localhost:7474/db/data/ext",
"relationship_types" : "http://localhost:7474/db/data/relationship/types",
"batch" : "http://localhost:7474/db/data/batch",
"cypher" : "http://localhost:7474/db/data/cypher",
"indexes" : "http://localhost:7474/db/data/schema/index",
"constraints" : "http://localhost:7474/db/data/schema/constraint",
"transaction" : "http://localhost:7474/db/data/transaction",
"node_labels" : "http://localhost:7474/db/data/labels",
"neo4j_version" : "2.1.1"
}
For details go to http://neo4j.com/
19. 19/44
Hypermedia formats
● Hypermedia formats:
– XHTML is mainly for humans
– Plain Old XML requires schema to provide meaning of tags
– JSON like XML does not have a meaning (e.g. does not define a hyperlink)
● The Atom Syndication Format (RFC 4287)
– XML-based format that allows software programs to check for updates published on a
website.
– Represents data as lists, called feeds.
– Feeds are made up of one or more timestamped entries, which associate document
metadata with web content
● Do not confuse the Atom Syndication Format with the Atom Publishing Protocol
(AtomPub or APP, defined in RFC 5023)
20. 20/44
Example of an Atom feed
<?xml version="1.0">
<feed xmlns="http://www.w3.org/2005/Atom">
<id>urn:uuid:60a76c80-d399-11d9-b91C-0003939e0af6</id>
<title>Order</title>
<updated>2003-12-13T18:30:02Z</updated>
<link href="http://example.org/order/123" rel="self" />
<entry>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<title>First product in the basket</title>
<updated>2003-12-13T18:30:02Z</updated>
<link href="http://example.org/order/123/item/456" />
<link rel="removeFromBasket" href="http://example.org/order/123/item/456"/>
<link rel="increasePriority" href="http://example.org/order/123/item/456/priority"/>
<content type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml">
<p>This is the entry content.</p>
</div>
</content>
</entry>
</feed>
On what basis the
consumer will know
how to interpret
these links?
21. 21/44
Semantics
● An application have to know how to interpret the hypermedia links
● The Resource Description Framework (RDF) is a framework for expressing
information about resources.
● The information is expressed in form of a triple. The triple is a subject-predicate-
object data structure, which expresses a relationship between two resources. e.g.
Customer buys order. Order consists of items.
● SPARQL Protocol and RDF Query Language (SPARQL) is a query language for RDF
● RDF is a building block of the Semantic Web movement.
● RDF define logical relationships. A number of different serialization formats exist for
writing down RDF graphs (e.g. Turtle, JSON-LD, RDFa, RDF/XML)
22. 22/44
Concurrency in Web Services
● When retrieving a resource with GET, server append ETag, which is a checksum of
a current state of the resource
● Client should use provided Etag in any subsequent requests it directs to the same
resource with If-Match tag, such request are called conditional requests
● If the resource was changed by some other client, then client would get 412
Precondition Failed. The correct thing to do is to retrieve (GET) the resource once
more.
● Alternatively client can use Last-Modified tag.
● Traditionally ETags were used for cache control purposes
● When use for cache control, client can use If-None-Match tag. The primary use of
it is to save computing resource, to retrieve a resource only if it has changed since
last read.
23. 23/44
RESTful API description languages
● API description languages enable code generation based on API contract and vice versa
● WADL (Web Application Description Language), W3C specification:
<application>
<resources base=”http://service.com”>
<resource path=”order”>
<method name=”POST”>
<request>
<representation mediaType=”application/xml” element=”ord:order”/>
</request>
<response>
<representation status=”201”/>
<fault mediatType=”application/xml” element=”ord:order” status=”400”/>
</response>
</method>
</resource>
</resources>
</application>
● Other popular API description languages: RAML (http://raml.org), Swagger (
http://swagger.io), API Blueprint (https://apiblueprint.org).
24. 24/44
The microservice architectural style
● To develop a single application as a suite of tiny services
● Each microservice is running in its own process, even if they run on the same
machine
● Microservices communicate with lightweight mechanisms, often a HTTP
resource API
● Microservices are independently deployable by a fully automated deployment
machinery
● There is a bare minimum of centralized management of these services
25. 25/44
Microservices highlights
● Microservices are really small (~ 100 LOC). They should be small enough to “fit in you
head”.
– It is better to have more smaller services than less fat services
● Systems built of microservices are inherently loosely coupled
● Different services can be written in different programming languages and can use
different data storage technologies
● Services should publish interesting information even if currently no one is interested in it
– When an entity is created in a database, then it should be exposed as a HTTP
resource
● You have to accept cost of massive serialization and deserialization of data
● It is possible to have multiple versions of the same service at the same time, but it should
be done only if necessary.
26. 26/44
Organization around Business Capabilities
● Often developer teams are separated along technology boundaries, e.g. divided into UI
team, server-side team and database team.
● Even small change in functionality requires work from each of those teams
● According to the microservice approach, teams should be organized around business
capability.
● Team reorganization as a way to obtain loose coupling between components.
Any organization that designs a system (defined broadly) will produce a design whose structure
is a copy of the organization's communication structure
Melvyn Conway
28. 28/44
Products not Projects
● Traditionally, after a production release of a system, responsibility for the system
was passed from development team to maintenance team
● To improve communication and collaboration between development and maintenance
teams many companies established DevOps teams.
● According to the microservice approach, it is important to have product teams, not
project teams.
● Amazon's notion of "you build, you run it", i.e. giving developers operational
responsibilities.
● Substantial DevOps skills are required in development team.
29. 29/44
Smart endpoints and dumb pipes
● In many SOA applications, integration of services is centralized and consists of a set
of complex rules (e.g. ESB, BPEL, WS-Choreography).
● Smart endpoints and dumb pipes approach assumes that integration is done via
simple RESTfull interfaces or lightweight messaging (RabbitMQ or ZeroMQ)
● Endpoints (services) should know what to do in any situation. They know, how to react
to a certain event.
● No need of God Classes or God Services.
● Intelligence should be distributed. There is no central point of orchestration
● Each µ-service subscribes to others µ-services.
● The knowledge about business process or workflow is inside the team
30. 30/44
Decentralized Data Management
● Traditionally, even if business logic is decentralized, persistent data are stored in a
single logical database
● According to the microservice approach, to ensure loose coupling, each
microservice has its own database (schema).
● The conceptual model of the environment differ between systems
● Polyglot Persistence - different services might use different types of database
● Microservice architectures emphasize transactionless coordination between
services
● Often businesses handle a degree of inconsistency in order to respond quickly to
demand
31. 31/44
Domain-Driven Design
● Domain-Driven Design (DDD) – is a set of design patterns which encourages designing software based on
models of the underlying domain, even if the domain is complex and evolving
● Bounded Context – the central pattern in DDD, way of dealing with large models and teams
– Traditionally, the effort was made to create a unified domain model of an organization.
– In practice, total unification of the domain model for a large system is not feasible or cost-effective
– Some concepts in a given bounded context are unrelated to other contexts. Others concepts are shared
among multiple bounded contexts.
– There is a variety of ways to describe relationships between bounded contexts
– Within a given context, team members are using Ubiquitous Language
– It is OK to have duplications. In short term, it can happen that in two context there will be similar
abstraction. In the long run, one of them can change.
● Context map – a model of relationships between multiple bounded contexts
32. 32/44
● Entity - an object that is not defined by its attributes, but rather by its identity.
Attributes of the entity can change with time, but it is still the same entity.
● Value Object - an object that contains attributes but has no conceptual identity.
They should be treated as immutable. From technical point of view it is often
Data transfer object (DTO).
● Aggregate - a collection of objects that are bound together. Often the aggregate
is implemented by one separate microservice.
● Aggregate root – a root entity for the aggregate. The only domain object that is
exposed to the external world. All other domain objects belonging to the
aggregate are hidden. It can be implemented as a public API of a microservice.
More DDD concepts
[Definitions based on https://en.wikipedia.org/wiki/Domain-driven_design]
33. 33/44
Infrastructure Automation
● The microservice architectural style assumes using continuous Integration and
continuous delivery development practices.
● Continuous Delivery is much easier when the system is build of microservices
● Automate IT system administration (e.g. release and deployment automation)
– Ansible http://www.ansible.com (simple yet powerful)
– Puppet https://puppetlabs.com
– Chef https://www.chef.io
● Cloud platforms have reduced the operational complexity of building, deploying and
operating services.
● Cloud platforms start offering autoscaling services.
34. 34/44
Design for failure
● In the monolith application, all or none components are working properly.
● In the microservice applications some component can work properly while others are in
failure state.
● As a consequence, applications need to be designed so that they can tolerate the
failure of services.
● Sometimes even whole data center can go down (e.g. The Christmas Eve 2012
Netflix/Amazon Outage)
● High quality infrastructure monitoring
– Splunk http://www.splunk.com
– Nagios https://www.nagios.org
35. 35/44
Evolutionary Design
● Microservices should be designed to support evolutionary design
● It should be possible to rewrite a microservice without affecting its collaborators
● Sometimes it is even better to replace a service with a new one then modify existing.
● Follow pattern of change, keep things that change at the same time in the same module.
● Use versioning only as a last resort. Design services to be as tolerant as possible to
changes in their suppliers.
● Replaceable Component Architecture – an application should be build of components that
can be independently upgraded or replaced without affecting its collaborators.
● With microservices, refactoring can be tough. If you implement two services using two
different programming languages, then moving some source code from one service to
another can be infeasible.
36. 36/44
Asynchronous calls
● An application based on asynchronous communication implements a loosely coupled design,
much better so than one based purely on synchronous method calls
● An event-driven approach can make efficient use of existing resources
● Example:
– When you need to create an order, just publish an event to the bus informing that you need
an order.
● Lightweight messaging technologies (as an alternative for JMS):
– Simple messaging via Atom feeds
– Apache Kafka (http://kafka.apache.org/) - a high-throughput distributed messaging system
● The event-driven approach is a key element of reactive programming
– In reactive programming, when you have a:=b+c assignment, and after that you change b or
c, a will change as well
37. 37/44
Reactive Programming
● Alternative to imperative programming
● According to The Reactive Manifesto (http://www.reactivemanifesto.org), RP allows
developers to build systems that are:
– Event-driven
– Scalable
– Resilient (to software, hardware or connection failures)
– Responsive (providing rich, real-time interaction with users)
● By reacting it is means to react to:
– Events
– Load
– Failures
– Users
38. 38/44
Actor Model
●
Traditionally, in multi-threading application we manage sharing mutable state with synchronization.
●
Drawbacks of synchronization:
– It can lead to dead-lock.
– It utilizes CPU inefficiently (some cores are waiting for another)
– Synchronous communication couples sander and receiver
●
There are solution to avoid dead-locks, but they make code much more complicated.
● It would be desired to have non-blocking objects → source code without synchronization
●
Actor Model was introduced in 1973 by C. Hewitt, P. Bishop and R. Steiger in their paper A Universal Modular
Actor Formalism for Artificial Intelligence
●
An Actor is an object that only interacts with other objects using asynchronous message passing
●
Actors are the most encapsulated form of objects
● In Actor Model blocking is replaced by queuing messages
39. 39/44
Akka
Simplified API:
trait Actor {
def receive: Receive
def sender: ActorRef
}
Usage:
class Counter extends Actor {
var count = 0
def receive = {
case “incr” => count += 1
case “get” => sender ! count
}
}
A reference to the sender
of the message that is
currently process by the
receive method
Receive is a partial function, the
function that is defined only for
a subset of the possible values
of its arguments.
operator for sending messages
For details go to http://akka.io/
40. 40/44
Microservices deployment
● Microservices should be containerless (shipped with embedded container)
● They should not be deployed to application servers (like JBoss, WebSphere or WebLogic)
but should be distributes as ready-to-be-run software packages
– Docker (https://www.docker.com) is an open platform that supports this approach
– Microservices can be standalone UNIX services (rc.d) which are distributed as RPM’s
– In case of Java apps, they can be packaged as single fat JAR (which includes all
dependencies)
● Each microservice should be a separate project inside SCM (different VCS root); not
submodule of multimodule project
– Keeping as separate projects enforces loose coupling.
– It is acceptable to have some common source code, but only infrastructure or
management code, not domain or business logic code.
41. 41/44
Analogy to UNIX pipes
● There is an analogy between the microservice architectural style and Unix
utilities.
● Write programs that do one thing and do it well
● Write programs that handle text streams, because text is a universal interface
● One can pipe multiple UNIX commands, e.g. $cat test.txt | grep
“come content”
42. 42/44
Microservices drawbacks
● When your application is build of many simple services then complexity is hidden
in connections between them.
● Implementing use cases that span multiple services without using distributed
transactions is difficult.
● Writing automated tests that involve multiple services is challenging.
● The microservice architecture also introduces significant operational
complexity.
43. 43/44
Bibliography
● R. Fielding, Architectural Styles and the Design of Network-based Software Architectures, Doctoral
dissertation, University of California, Irvine, 2000
● L. Richardson and S. Ruby, RESTful Web Services, O’Reilly Media, 2007
● J. Webber, S. Parastatidis, I. Robinson, REST in Practice: Hypermedia and Systems Architecture,
O'Reilly Media, 2010
● C. Hewitt, P. Bishop, R. Steiger, A Universal Modular Actor Formalism for Artificial Intelligence,
IJCAI, 1973
● Architecture of the World Wide Web, W3C, http://www.w3.org/TR/webarch
● J. Lewis, M. Fowler, Microservices, http://martinfowler.com/articles/microservices.html
● M. Fowler, Service Oriented Ambiguity http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html
●
Netflix OSS, http://netflix.github.io
● E. Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley,
2004
One resource can have multiple representations, e.g. XHTML, GIF, PDF and plain text.
Conway&apos;s law (1968) is a valid sociological observation
When you need to create an order, just publish an event to the bus, that you need an order.
Maybe, the asynchronous nature is the single biggest difference between traditional SOA and microservices
Being Scalable, Resilient and Responsive is a consequence of being Event-driven
Even if you have a reference to an actor, you can not invoke its methods
In fact, the Actor has a stack of behavior, receive pointer points to the top one
When it is separate repository, you will think twice before deciding that some code should go to one repository not to another.
