SlideShare a Scribd company logo
Microservices
Karol Grzegorczyk
June 23, 2014
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/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/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/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/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/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/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/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/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/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/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]
13/44
Service Oriented Architecture
Services interact
through a fixed
interface shared
through documentation
or an interface
description language
(IDL).
Distributed services
are orchestrated by
the centralized
business process
engine.
A service is build of
multiple service
components, but they
run on a single
machine
As we can see above, in SOA services are itself monoliths, build of multiple components!
SOA became integration technology of monolith applications!
[© The Open Group]
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/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/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/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/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/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/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/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/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/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/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/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/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
27/44
Organized around Business Capabilities
[© Martin Fowler]
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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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
44/44
Thank you!

More Related Content

What's hot

DEVNET-1184 Microservices Patterns
DEVNET-1184	Microservices PatternsDEVNET-1184	Microservices Patterns
DEVNET-1184 Microservices Patterns
Cisco DevNet
 
Microservices Architecture
Microservices ArchitectureMicroservices Architecture
Microservices Architecture
Srinivasan Nanduri
 
Nats meetup sf 20150826
Nats meetup sf   20150826Nats meetup sf   20150826
Nats meetup sf 20150826
Apcera
 
Microservices in Practice
Microservices in PracticeMicroservices in Practice
Microservices in Practice
Kasun Indrasiri
 
Evolution of integration and microservices patterns with service mesh
Evolution of integration and microservices patterns with service meshEvolution of integration and microservices patterns with service mesh
Evolution of integration and microservices patterns with service mesh
Christian Posta
 
From SOA to MSA
From SOA to MSAFrom SOA to MSA
From SOA to MSA
William Yang
 
Microservice architecture
Microservice architectureMicroservice architecture
Microservice architecture
Žilvinas Kuusas
 
Introduction To Microservices
Introduction To MicroservicesIntroduction To Microservices
Introduction To Microservices
Lalit Kale
 
Merging microservices architecture with SOA practices
Merging microservices architecture with SOA practicesMerging microservices architecture with SOA practices
Merging microservices architecture with SOA practices
Chris Haddad
 
Service-mesh options with Linkerd, Consul, Istio and AWS AppMesh
Service-mesh options with Linkerd, Consul, Istio and AWS AppMeshService-mesh options with Linkerd, Consul, Istio and AWS AppMesh
Service-mesh options with Linkerd, Consul, Istio and AWS AppMesh
Christian Posta
 
Full lifecycle of a microservice
Full lifecycle of a microserviceFull lifecycle of a microservice
Full lifecycle of a microservice
Luigi Bennardis
 
Microservices architecture
Microservices architectureMicroservices architecture
Microservices architecture
Mohammad Dameer
 
Microservices: an introduction
Microservices: an introductionMicroservices: an introduction
Microservices: an introduction
Daniel Baptista Dias
 
Microservices: Where do they fit within a rapidly evolving integration archit...
Microservices: Where do they fit within a rapidly evolving integration archit...Microservices: Where do they fit within a rapidly evolving integration archit...
Microservices: Where do they fit within a rapidly evolving integration archit...
Kim Clark
 
Deep-dive into Microservice Outer Architecture
Deep-dive into Microservice Outer ArchitectureDeep-dive into Microservice Outer Architecture
Deep-dive into Microservice Outer Architecture
WSO2
 
An eventful tour from enterprise integration to serverless and functions
An eventful tour from enterprise integration to serverless and functionsAn eventful tour from enterprise integration to serverless and functions
An eventful tour from enterprise integration to serverless and functions
Christian Posta
 
Microservices Journey Fall 2017
Microservices Journey Fall 2017Microservices Journey Fall 2017
Microservices Journey Fall 2017
Christian Posta
 
Microservices Architecture (MSA) - Presentation made at AEA-MN quarterly even...
Microservices Architecture (MSA) - Presentation made at AEA-MN quarterly even...Microservices Architecture (MSA) - Presentation made at AEA-MN quarterly even...
Microservices Architecture (MSA) - Presentation made at AEA-MN quarterly even...
Somasundram Balakrushnan
 
Closer Look at Cloud Centric Architectures
Closer Look at Cloud Centric ArchitecturesCloser Look at Cloud Centric Architectures
Closer Look at Cloud Centric Architectures
Todd Kaplinger
 
Microservice architecture-api-gateway-considerations
Microservice architecture-api-gateway-considerationsMicroservice architecture-api-gateway-considerations
Microservice architecture-api-gateway-considerations
Imam Uddin Ahamed - PRINCE2 ® , ITIL ®
 

What's hot (20)

DEVNET-1184 Microservices Patterns
DEVNET-1184	Microservices PatternsDEVNET-1184	Microservices Patterns
DEVNET-1184 Microservices Patterns
 
Microservices Architecture
Microservices ArchitectureMicroservices Architecture
Microservices Architecture
 
Nats meetup sf 20150826
Nats meetup sf   20150826Nats meetup sf   20150826
Nats meetup sf 20150826
 
Microservices in Practice
Microservices in PracticeMicroservices in Practice
Microservices in Practice
 
Evolution of integration and microservices patterns with service mesh
Evolution of integration and microservices patterns with service meshEvolution of integration and microservices patterns with service mesh
Evolution of integration and microservices patterns with service mesh
 
From SOA to MSA
From SOA to MSAFrom SOA to MSA
From SOA to MSA
 
Microservice architecture
Microservice architectureMicroservice architecture
Microservice architecture
 
Introduction To Microservices
Introduction To MicroservicesIntroduction To Microservices
Introduction To Microservices
 
Merging microservices architecture with SOA practices
Merging microservices architecture with SOA practicesMerging microservices architecture with SOA practices
Merging microservices architecture with SOA practices
 
Service-mesh options with Linkerd, Consul, Istio and AWS AppMesh
Service-mesh options with Linkerd, Consul, Istio and AWS AppMeshService-mesh options with Linkerd, Consul, Istio and AWS AppMesh
Service-mesh options with Linkerd, Consul, Istio and AWS AppMesh
 
Full lifecycle of a microservice
Full lifecycle of a microserviceFull lifecycle of a microservice
Full lifecycle of a microservice
 
Microservices architecture
Microservices architectureMicroservices architecture
Microservices architecture
 
Microservices: an introduction
Microservices: an introductionMicroservices: an introduction
Microservices: an introduction
 
Microservices: Where do they fit within a rapidly evolving integration archit...
Microservices: Where do they fit within a rapidly evolving integration archit...Microservices: Where do they fit within a rapidly evolving integration archit...
Microservices: Where do they fit within a rapidly evolving integration archit...
 
Deep-dive into Microservice Outer Architecture
Deep-dive into Microservice Outer ArchitectureDeep-dive into Microservice Outer Architecture
Deep-dive into Microservice Outer Architecture
 
An eventful tour from enterprise integration to serverless and functions
An eventful tour from enterprise integration to serverless and functionsAn eventful tour from enterprise integration to serverless and functions
An eventful tour from enterprise integration to serverless and functions
 
Microservices Journey Fall 2017
Microservices Journey Fall 2017Microservices Journey Fall 2017
Microservices Journey Fall 2017
 
Microservices Architecture (MSA) - Presentation made at AEA-MN quarterly even...
Microservices Architecture (MSA) - Presentation made at AEA-MN quarterly even...Microservices Architecture (MSA) - Presentation made at AEA-MN quarterly even...
Microservices Architecture (MSA) - Presentation made at AEA-MN quarterly even...
 
Closer Look at Cloud Centric Architectures
Closer Look at Cloud Centric ArchitecturesCloser Look at Cloud Centric Architectures
Closer Look at Cloud Centric Architectures
 
Microservice architecture-api-gateway-considerations
Microservice architecture-api-gateway-considerationsMicroservice architecture-api-gateway-considerations
Microservice architecture-api-gateway-considerations
 

Viewers also liked

Parallel Complex Event Processing
Parallel Complex Event ProcessingParallel Complex Event Processing
Parallel Complex Event Processing
Karol Grzegorczyk
 
Terms
TermsTerms
Terms
tyankee
 
Topic Modeling
Topic ModelingTopic Modeling
Topic Modeling
Karol Grzegorczyk
 
3 Keys To Successful Master Data Management - Final Presentation
3 Keys To Successful Master Data Management - Final Presentation3 Keys To Successful Master Data Management - Final Presentation
3 Keys To Successful Master Data Management - Final Presentation
James Chi
 
Service Oriented Architecture
Service Oriented ArchitectureService Oriented Architecture
Service Oriented Architecture
Robert Sim
 
Introduction to Microservices
Introduction to MicroservicesIntroduction to Microservices
Introduction to Microservices
Amazon Web Services
 

Viewers also liked (6)

Parallel Complex Event Processing
Parallel Complex Event ProcessingParallel Complex Event Processing
Parallel Complex Event Processing
 
Terms
TermsTerms
Terms
 
Topic Modeling
Topic ModelingTopic Modeling
Topic Modeling
 
3 Keys To Successful Master Data Management - Final Presentation
3 Keys To Successful Master Data Management - Final Presentation3 Keys To Successful Master Data Management - Final Presentation
3 Keys To Successful Master Data Management - Final Presentation
 
Service Oriented Architecture
Service Oriented ArchitectureService Oriented Architecture
Service Oriented Architecture
 
Introduction to Microservices
Introduction to MicroservicesIntroduction to Microservices
Introduction to Microservices
 

Similar to Microservices

The new (is it really ) api stack
The new (is it really ) api stackThe new (is it really ) api stack
The new (is it really ) api stack
Red Hat
 
Module notes artificial intelligence and
Module notes artificial intelligence andModule notes artificial intelligence and
Module notes artificial intelligence and
bhagyavantrajapur88
 
HTTP In-depth
HTTP In-depthHTTP In-depth
HTTP In-depth
Vinayak Hegde
 
Web technology-guide
Web technology-guideWeb technology-guide
Web technology-guide
Srihari
 
Building high performance microservices in finance with Apache Thrift
Building high performance microservices in finance with Apache ThriftBuilding high performance microservices in finance with Apache Thrift
Building high performance microservices in finance with Apache Thrift
RX-M Enterprises LLC
 
Building Modern Digital Services on Scalable Private Government Infrastructur...
Building Modern Digital Services on Scalable Private Government Infrastructur...Building Modern Digital Services on Scalable Private Government Infrastructur...
Building Modern Digital Services on Scalable Private Government Infrastructur...
Andrés Colón Pérez
 
Yotpo microservices
Yotpo microservicesYotpo microservices
Yotpo microservices
Ron Barabash
 
Restful webservices
Restful webservicesRestful webservices
Restful webservices
Luqman Shareef
 
Open shift and docker - october,2014
Open shift and docker - october,2014Open shift and docker - october,2014
Open shift and docker - october,2014
Hojoong Kim
 
Structure and Opinions - Software Deployments with Cloud Foundry
Structure and Opinions - Software Deployments with Cloud FoundryStructure and Opinions - Software Deployments with Cloud Foundry
Structure and Opinions - Software Deployments with Cloud Foundry
Andrew Ripka
 
WSO2CON 2024 - Navigating API Complexity: REST, GraphQL, gRPC, Websocket, Web...
WSO2CON 2024 - Navigating API Complexity: REST, GraphQL, gRPC, Websocket, Web...WSO2CON 2024 - Navigating API Complexity: REST, GraphQL, gRPC, Websocket, Web...
WSO2CON 2024 - Navigating API Complexity: REST, GraphQL, gRPC, Websocket, Web...
WSO2
 
Cs8591 Computer Networks - UNIT V
Cs8591 Computer Networks - UNIT VCs8591 Computer Networks - UNIT V
Cs8591 Computer Networks - UNIT V
pkaviya
 
Mini-Training: Let's have a rest
Mini-Training: Let's have a restMini-Training: Let's have a rest
Mini-Training: Let's have a rest
Betclic Everest Group Tech Team
 
Asynchronous Frameworks.pptx
Asynchronous Frameworks.pptxAsynchronous Frameworks.pptx
Asynchronous Frameworks.pptx
ganeshkarthy
 
200211 Fielding Apachecon
200211 Fielding Apachecon200211 Fielding Apachecon
200211 Fielding Apachecon
Daniel Parker
 
A Bit of REST
A Bit of RESTA Bit of REST
A Bit of REST
ColdFusionConference
 
Support formobility
Support formobilitySupport formobility
Support formobility
Rahul Hada
 
Chap 5 software as a service (saass)
Chap 5 software as a service (saass)Chap 5 software as a service (saass)
Chap 5 software as a service (saass)
Raj Sarode
 
MODULE-5_CCN.pptx
MODULE-5_CCN.pptxMODULE-5_CCN.pptx
MODULE-5_CCN.pptx
Dr. Shivashankar
 
Application_layer.pdf
Application_layer.pdfApplication_layer.pdf
Application_layer.pdf
BhoomikaPrajapath
 

Similar to Microservices (20)

The new (is it really ) api stack
The new (is it really ) api stackThe new (is it really ) api stack
The new (is it really ) api stack
 
Module notes artificial intelligence and
Module notes artificial intelligence andModule notes artificial intelligence and
Module notes artificial intelligence and
 
HTTP In-depth
HTTP In-depthHTTP In-depth
HTTP In-depth
 
Web technology-guide
Web technology-guideWeb technology-guide
Web technology-guide
 
Building high performance microservices in finance with Apache Thrift
Building high performance microservices in finance with Apache ThriftBuilding high performance microservices in finance with Apache Thrift
Building high performance microservices in finance with Apache Thrift
 
Building Modern Digital Services on Scalable Private Government Infrastructur...
Building Modern Digital Services on Scalable Private Government Infrastructur...Building Modern Digital Services on Scalable Private Government Infrastructur...
Building Modern Digital Services on Scalable Private Government Infrastructur...
 
Yotpo microservices
Yotpo microservicesYotpo microservices
Yotpo microservices
 
Restful webservices
Restful webservicesRestful webservices
Restful webservices
 
Open shift and docker - october,2014
Open shift and docker - october,2014Open shift and docker - october,2014
Open shift and docker - october,2014
 
Structure and Opinions - Software Deployments with Cloud Foundry
Structure and Opinions - Software Deployments with Cloud FoundryStructure and Opinions - Software Deployments with Cloud Foundry
Structure and Opinions - Software Deployments with Cloud Foundry
 
WSO2CON 2024 - Navigating API Complexity: REST, GraphQL, gRPC, Websocket, Web...
WSO2CON 2024 - Navigating API Complexity: REST, GraphQL, gRPC, Websocket, Web...WSO2CON 2024 - Navigating API Complexity: REST, GraphQL, gRPC, Websocket, Web...
WSO2CON 2024 - Navigating API Complexity: REST, GraphQL, gRPC, Websocket, Web...
 
Cs8591 Computer Networks - UNIT V
Cs8591 Computer Networks - UNIT VCs8591 Computer Networks - UNIT V
Cs8591 Computer Networks - UNIT V
 
Mini-Training: Let's have a rest
Mini-Training: Let's have a restMini-Training: Let's have a rest
Mini-Training: Let's have a rest
 
Asynchronous Frameworks.pptx
Asynchronous Frameworks.pptxAsynchronous Frameworks.pptx
Asynchronous Frameworks.pptx
 
200211 Fielding Apachecon
200211 Fielding Apachecon200211 Fielding Apachecon
200211 Fielding Apachecon
 
A Bit of REST
A Bit of RESTA Bit of REST
A Bit of REST
 
Support formobility
Support formobilitySupport formobility
Support formobility
 
Chap 5 software as a service (saass)
Chap 5 software as a service (saass)Chap 5 software as a service (saass)
Chap 5 software as a service (saass)
 
MODULE-5_CCN.pptx
MODULE-5_CCN.pptxMODULE-5_CCN.pptx
MODULE-5_CCN.pptx
 
Application_layer.pdf
Application_layer.pdfApplication_layer.pdf
Application_layer.pdf
 

Recently uploaded

Orion Context Broker introduction 20240604
Orion Context Broker introduction 20240604Orion Context Broker introduction 20240604
Orion Context Broker introduction 20240604
Fermin Galan
 
Need for Speed: Removing speed bumps from your Symfony projects ⚡️
Need for Speed: Removing speed bumps from your Symfony projects ⚡️Need for Speed: Removing speed bumps from your Symfony projects ⚡️
Need for Speed: Removing speed bumps from your Symfony projects ⚡️
Łukasz Chruściel
 
SWEBOK and Education at FUSE Okinawa 2024
SWEBOK and Education at FUSE Okinawa 2024SWEBOK and Education at FUSE Okinawa 2024
SWEBOK and Education at FUSE Okinawa 2024
Hironori Washizaki
 
socradar-q1-2024-aviation-industry-report.pdf
socradar-q1-2024-aviation-industry-report.pdfsocradar-q1-2024-aviation-industry-report.pdf
socradar-q1-2024-aviation-industry-report.pdf
SOCRadar
 
Transform Your Communication with Cloud-Based IVR Solutions
Transform Your Communication with Cloud-Based IVR SolutionsTransform Your Communication with Cloud-Based IVR Solutions
Transform Your Communication with Cloud-Based IVR Solutions
TheSMSPoint
 
GreenCode-A-VSCode-Plugin--Dario-Jurisic
GreenCode-A-VSCode-Plugin--Dario-JurisicGreenCode-A-VSCode-Plugin--Dario-Jurisic
GreenCode-A-VSCode-Plugin--Dario-Jurisic
Green Software Development
 
ALGIT - Assembly Line for Green IT - Numbers, Data, Facts
ALGIT - Assembly Line for Green IT - Numbers, Data, FactsALGIT - Assembly Line for Green IT - Numbers, Data, Facts
ALGIT - Assembly Line for Green IT - Numbers, Data, Facts
Green Software Development
 
E-commerce Application Development Company.pdf
E-commerce Application Development Company.pdfE-commerce Application Development Company.pdf
E-commerce Application Development Company.pdf
Hornet Dynamics
 
APIs for Browser Automation (MoT Meetup 2024)
APIs for Browser Automation (MoT Meetup 2024)APIs for Browser Automation (MoT Meetup 2024)
APIs for Browser Automation (MoT Meetup 2024)
Boni García
 
GraphSummit Paris - The art of the possible with Graph Technology
GraphSummit Paris - The art of the possible with Graph TechnologyGraphSummit Paris - The art of the possible with Graph Technology
GraphSummit Paris - The art of the possible with Graph Technology
Neo4j
 
Atelier - Innover avec l’IA Générative et les graphes de connaissances
Atelier - Innover avec l’IA Générative et les graphes de connaissancesAtelier - Innover avec l’IA Générative et les graphes de connaissances
Atelier - Innover avec l’IA Générative et les graphes de connaissances
Neo4j
 
Why Mobile App Regression Testing is Critical for Sustained Success_ A Detail...
Why Mobile App Regression Testing is Critical for Sustained Success_ A Detail...Why Mobile App Regression Testing is Critical for Sustained Success_ A Detail...
Why Mobile App Regression Testing is Critical for Sustained Success_ A Detail...
kalichargn70th171
 
Cracking the code review at SpringIO 2024
Cracking the code review at SpringIO 2024Cracking the code review at SpringIO 2024
Cracking the code review at SpringIO 2024
Paco van Beckhoven
 
A Sighting of filterA in Typelevel Rite of Passage
A Sighting of filterA in Typelevel Rite of PassageA Sighting of filterA in Typelevel Rite of Passage
A Sighting of filterA in Typelevel Rite of Passage
Philip Schwarz
 
openEuler Case Study - The Journey to Supply Chain Security
openEuler Case Study - The Journey to Supply Chain SecurityopenEuler Case Study - The Journey to Supply Chain Security
openEuler Case Study - The Journey to Supply Chain Security
Shane Coughlan
 
Artificia Intellicence and XPath Extension Functions
Artificia Intellicence and XPath Extension FunctionsArtificia Intellicence and XPath Extension Functions
Artificia Intellicence and XPath Extension Functions
Octavian Nadolu
 
2024 eCommerceDays Toulouse - Sylius 2.0.pdf
2024 eCommerceDays Toulouse - Sylius 2.0.pdf2024 eCommerceDays Toulouse - Sylius 2.0.pdf
2024 eCommerceDays Toulouse - Sylius 2.0.pdf
Łukasz Chruściel
 
Using Xen Hypervisor for Functional Safety
Using Xen Hypervisor for Functional SafetyUsing Xen Hypervisor for Functional Safety
Using Xen Hypervisor for Functional Safety
Ayan Halder
 
Empowering Growth with Best Software Development Company in Noida - Deuglo
Empowering Growth with Best Software  Development Company in Noida - DeugloEmpowering Growth with Best Software  Development Company in Noida - Deuglo
Empowering Growth with Best Software Development Company in Noida - Deuglo
Deuglo Infosystem Pvt Ltd
 
LORRAINE ANDREI_LEQUIGAN_HOW TO USE WHATSAPP.pptx
LORRAINE ANDREI_LEQUIGAN_HOW TO USE WHATSAPP.pptxLORRAINE ANDREI_LEQUIGAN_HOW TO USE WHATSAPP.pptx
LORRAINE ANDREI_LEQUIGAN_HOW TO USE WHATSAPP.pptx
lorraineandreiamcidl
 

Recently uploaded (20)

Orion Context Broker introduction 20240604
Orion Context Broker introduction 20240604Orion Context Broker introduction 20240604
Orion Context Broker introduction 20240604
 
Need for Speed: Removing speed bumps from your Symfony projects ⚡️
Need for Speed: Removing speed bumps from your Symfony projects ⚡️Need for Speed: Removing speed bumps from your Symfony projects ⚡️
Need for Speed: Removing speed bumps from your Symfony projects ⚡️
 
SWEBOK and Education at FUSE Okinawa 2024
SWEBOK and Education at FUSE Okinawa 2024SWEBOK and Education at FUSE Okinawa 2024
SWEBOK and Education at FUSE Okinawa 2024
 
socradar-q1-2024-aviation-industry-report.pdf
socradar-q1-2024-aviation-industry-report.pdfsocradar-q1-2024-aviation-industry-report.pdf
socradar-q1-2024-aviation-industry-report.pdf
 
Transform Your Communication with Cloud-Based IVR Solutions
Transform Your Communication with Cloud-Based IVR SolutionsTransform Your Communication with Cloud-Based IVR Solutions
Transform Your Communication with Cloud-Based IVR Solutions
 
GreenCode-A-VSCode-Plugin--Dario-Jurisic
GreenCode-A-VSCode-Plugin--Dario-JurisicGreenCode-A-VSCode-Plugin--Dario-Jurisic
GreenCode-A-VSCode-Plugin--Dario-Jurisic
 
ALGIT - Assembly Line for Green IT - Numbers, Data, Facts
ALGIT - Assembly Line for Green IT - Numbers, Data, FactsALGIT - Assembly Line for Green IT - Numbers, Data, Facts
ALGIT - Assembly Line for Green IT - Numbers, Data, Facts
 
E-commerce Application Development Company.pdf
E-commerce Application Development Company.pdfE-commerce Application Development Company.pdf
E-commerce Application Development Company.pdf
 
APIs for Browser Automation (MoT Meetup 2024)
APIs for Browser Automation (MoT Meetup 2024)APIs for Browser Automation (MoT Meetup 2024)
APIs for Browser Automation (MoT Meetup 2024)
 
GraphSummit Paris - The art of the possible with Graph Technology
GraphSummit Paris - The art of the possible with Graph TechnologyGraphSummit Paris - The art of the possible with Graph Technology
GraphSummit Paris - The art of the possible with Graph Technology
 
Atelier - Innover avec l’IA Générative et les graphes de connaissances
Atelier - Innover avec l’IA Générative et les graphes de connaissancesAtelier - Innover avec l’IA Générative et les graphes de connaissances
Atelier - Innover avec l’IA Générative et les graphes de connaissances
 
Why Mobile App Regression Testing is Critical for Sustained Success_ A Detail...
Why Mobile App Regression Testing is Critical for Sustained Success_ A Detail...Why Mobile App Regression Testing is Critical for Sustained Success_ A Detail...
Why Mobile App Regression Testing is Critical for Sustained Success_ A Detail...
 
Cracking the code review at SpringIO 2024
Cracking the code review at SpringIO 2024Cracking the code review at SpringIO 2024
Cracking the code review at SpringIO 2024
 
A Sighting of filterA in Typelevel Rite of Passage
A Sighting of filterA in Typelevel Rite of PassageA Sighting of filterA in Typelevel Rite of Passage
A Sighting of filterA in Typelevel Rite of Passage
 
openEuler Case Study - The Journey to Supply Chain Security
openEuler Case Study - The Journey to Supply Chain SecurityopenEuler Case Study - The Journey to Supply Chain Security
openEuler Case Study - The Journey to Supply Chain Security
 
Artificia Intellicence and XPath Extension Functions
Artificia Intellicence and XPath Extension FunctionsArtificia Intellicence and XPath Extension Functions
Artificia Intellicence and XPath Extension Functions
 
2024 eCommerceDays Toulouse - Sylius 2.0.pdf
2024 eCommerceDays Toulouse - Sylius 2.0.pdf2024 eCommerceDays Toulouse - Sylius 2.0.pdf
2024 eCommerceDays Toulouse - Sylius 2.0.pdf
 
Using Xen Hypervisor for Functional Safety
Using Xen Hypervisor for Functional SafetyUsing Xen Hypervisor for Functional Safety
Using Xen Hypervisor for Functional Safety
 
Empowering Growth with Best Software Development Company in Noida - Deuglo
Empowering Growth with Best Software  Development Company in Noida - DeugloEmpowering Growth with Best Software  Development Company in Noida - Deuglo
Empowering Growth with Best Software Development Company in Noida - Deuglo
 
LORRAINE ANDREI_LEQUIGAN_HOW TO USE WHATSAPP.pptx
LORRAINE ANDREI_LEQUIGAN_HOW TO USE WHATSAPP.pptxLORRAINE ANDREI_LEQUIGAN_HOW TO USE WHATSAPP.pptx
LORRAINE ANDREI_LEQUIGAN_HOW TO USE WHATSAPP.pptx
 

Microservices

  • 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]
  • 13. 13/44 Service Oriented Architecture Services interact through a fixed interface shared through documentation or an interface description language (IDL). Distributed services are orchestrated by the centralized business process engine. A service is build of multiple service components, but they run on a single machine As we can see above, in SOA services are itself monoliths, build of multiple components! SOA became integration technology of monolith applications! [© The Open Group]
  • 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
  • 27. 27/44 Organized around Business Capabilities [© Martin Fowler]
  • 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

Editor's Notes

  1. One resource can have multiple representations, e.g. XHTML, GIF, PDF and plain text.
  2. Conway&amp;apos;s law (1968) is a valid sociological observation
  3. 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
  4. Being Scalable, Resilient and Responsive is a consequence of being Event-driven
  5. Even if you have a reference to an actor, you can not invoke its methods
  6. In fact, the Actor has a stack of behavior, receive pointer points to the top one
  7. When it is separate repository, you will think twice before deciding that some code should go to one repository not to another.