Deep-dive into Microservice Outer Architecture

Microservices:
Outer Architecture
Webinar January 2016

Frank Leyman & Srinath Perera

Causes of Volatility of RPC
(i.e. Synchronous Communication)
o Time Dependency
≈ All ingredients have to be available at same 8me
o Format Dependency
≈ Number and types of parameters must match
o Reference Dependency
≈ Hard-coded addresses
o PlaAorm Dependency
≈ Internal representa8ons of data (liDle/big endian...)

This is 8ght coupling!

Loose Coupling
Core principle:
Reduce number of assump8ons two par8es make
about each other when they exchange informa8on

o Reference Autonomy
o Producers and consumers don’t know each other
o Time Autonomy
o Producers and consumers execute at their own
pace
o Format Autonomy
o Producers and consumers may use different
formats of data exchanged
o PlaAorm Autonomy
o Producers and consumers may be in different
environments, wriDen in different languages,…
Loose Coupling:
Autonomy Dimensions

Loose Coupling in SOA
o  Reference Autonomy
o  Client interacts with an endpoint (oRen a URI) not with a concrete
program, i.e. client doesn’t know the actual service
o  Time Autonomy
o  Asynchronous bindings (JMS,…) can be used
o  Reply-to header, Correla8on header,… support
asynchrony even over synchronous transports
o  Format Autonomy
o  Binding speciﬁes serializa8on format
o  Transforma8on can be done “invisibly” along
the wire
o  PlaAorm Autonomy
o  Client interacts with service without having to
know programming language, hos8ng environment,… of service

o Interac8on with URI addressable resources
o Fixed set of generic interac8ons
(mainly HTTP GET, POST, PUT, and DELETE)
o Standard data format (HTML, XML,JSON,...
- MIME types)
o Stateless
o All context is fully understandable from
message
Characteristics Of The Web Architecture:
The Underpinnings Of REST

We Will See in What Follows...
REST architectural style supports loose coupling

Reference Autonomy in REST: URIs
Resource
Implementation
Resource
Implementation
Resource
Resource
URIClient
REST Server
o URI decouples from knowing the actual func8on
implementa8on
o HATEOAS goes beyond (see later)

o  Some8mes requests may take too long for a client to
wait for response
o  Especially POST and DELETE may take some 8me
(they might ini8ate a complete business processes)
o  Server acknowledges recep8on of request
o  Via HTTP Status Code 202 Accepted
o  Server provides a resource that client can use to track
progress of long-running request (aka “task”)
o  Via Content-Loca:on header of this resource, or
o  Via Link to this resource

Time Autonomy in REST:
Long Running Requests

o  ORen, requested en8ty is available in mul8ple variants
o  Different languages (English, German,...)
o  Different encodings (GIF, JPEG,...)
o  Different quali8es (colored, black-and-white,...) to
accommodate
o  different line/connec8on speeds
o  Different formats (HTML, XML, RDF, JSON…)

o  HTTP defines procedures to nego8ate the appropriate
variant to be transferred
Format Autonomy in REST:
Content Negotiation

o  The premier transport to implement REST is HTTP(S)

o  HTTP clients and HTTP servers are available in all major
environments

o  Programs in most languages can be producers and
consumers of HTTP messages
Platform Autonomy in REST

o  HATEOAS =
Hypermedia As The Engine Of Applica8on State

o  In REST, clients can even be de-coupled from the
individual func8ons provided by services and the state
of interac8on in which func8ons can be used

o  The server returns links (“hypermedia”) that describe
the func8ons valid in the actual “state” of the
“applica8on”

Increasing Reference Autonomy:
HATEOAS

REST Maturity Model
(aka Richardson Maturity Model)
■  Support of HATEOAS

■  Use of appropriate HTTP methods
to manipulate individual resources
■  Use of appropriate HTTP status
codes
■  Individual resources are iden8ﬁed
■  Use of single method (typically
POST)
■  Method invoked on individual
resource
■  Similar to “objects”

■  HTTP is used as a transport only
■  Single entry point only
■  Use of single method (typically
POST)
■  Examples: SOAP, XML-RPC
Swamp of POX
Resources
HTTP Verbs
Hypermedia Controls
Level 0
Level 1
Level 2
Level 3

o  …microservice architectural style is an approach to
o  developing a single applica8on as a suite of small services,
o  each running in its own process and
o  communica8ng with lightweight mechanisms, oRen an HTTP
resource API.
o  These services are built
o  around business capabili8es and
o  independently deployable by fully automated deployment
machinery.
o  There is a bare minimum of centralized management of
these services, which
o  may be wriDen in diﬀerent programming languages and
o  use diﬀerent data storage technologies.
Definition: Quote(*)
(*) J. Lewis & M. Fowler: “Microservices” (2015), hDp://mar8nfowler.com/ar8cles/
microservices.html

Microservice: Main Properties
Microservice is
■  small
■  running in its own process
(or container these days)
■  communica8ng oRen [via] HTTP
■  built around business capabili8es
■  wriDen in diﬀerent programming
languages
■  use diﬀerent data storage
technologies
■  independently deployable by fully
automated deployment machinery
16
…whatever that means
True for many (!) service
True for many (!) service,
and most REST services
That’s what services are
That’s interes8ng

Microservice: The Essence?
A microservice is a service
that is independently deployable
by fully automated deployment machinery
…and this has interes8ng implica8ons (see next)

A Problem
■  You have a “big applica8on” (a.k.a. “monolith”)
■  If you want to replicate it
■  …e.g. because of scale, availability, elas8city,…
you pay penal8es (e.g. licenses for all components)
although you only need “a few components” replicated
Application
…
Scale,HA,…

Solution
■  Split your “big applica8on” into smaller granules that can be
deployed independently
■  I.e. split it into micro-services

■  Replica8on can be restricted to those components that turn
out to be boDlenecks ( scale), cri8cal ( HA),… without
paying the penal8es for all other components of the “big
applica8on” 19
Application

o  Micro-Services are all about…
o  …proper granularity of components
o  …independent deployment
o  They are not a counter-proposal to SOA
o  They do not prove that SOA failed
o  In the opposite: they require loose coupling,…
o  They require a methodology to determine “proper granules” for
components
o  …something like the holy grail of soRware engineering for
decades!
o  …so, don’t expect your middleware vendors to solve this
problem for you! It’s all about YOU solving an very diﬃcult
architecture/design problem!!!

The Essence of Micro-Services

What does it mean?
Let’s explore what this means for your design

o  Each microservice should have it’s
own databases and Data MUST not
be shared via a database
o  This Remove tight coupling via
database schema
o  However, strong consistency ( if
needed) across data sources is hard in
that case.
o  You either have to do distributed
transactions (DON’T) or use
compensations.
No Shared DBs

o  If updates happens only in one microservice (e.g. loan
approval process check the balance), you can use a
asynchronous messaging (message queue).
o  If updates happen in both services, perhaps, you need to
consider merging the two services. ( for example see
https://www.tigerteam.dk/2014/micro-services-its-not-only-
the-size-that-matters-its-also-how-you-use-them-part-2/ )
o  If not see Next slide: Transaction
When data (DB) is shared?

o  When possible, avoid transactions crossing microservice boundaries
o  Depend lesser guarantees ( e.g. use timeouts, update via
persistent messaging): see
Starbucks Does Not Use Two-Phase Commit and
https://news.ycombinator.com/item?id=7995130
o  Use compensation
o  Read
Life Beyond Distributed Transactions: An Apostate’s Opinion
o  There are some use cases where you must do distributed
transactions ( that cross microservice boundaries)
o  Those MUST use transactions (e.g.
http://jbossts.blogspot.com/2015/04/microservices-and-
transactions-update.html)
Transactions

the commonly understood “contract” between microservices is that
their APIs are stable and forward compatible.
Forward compatibility is a design characteristic that allows a system to gracefully
accept input intended for a later version of itself
o  Idea is that microservice can switch to new versions, without all it’s
dependencies having to switch.
o  Idea is loose coupling letting each party evolve individually
o  Good idea to do explicit API versioning
o  Might be costly in same cases, also support for older versions have
to be dropped at some point
APIs are forward compatible

o  Old method is service call DB or Identity Server
o  Doing that from a Microservice is questionable
o  Common method is client talks to identity server, get a token and
present it to microservice which verify the token. SAML tokens can
be verified by microservice itself, while OAuth tokens usually needs
a call to Identity Server.
o  See following for more information
http://nordicapis.com/how-to-control-user-identity-within-
microservices/
MicroService Security (Contd.)

Composition with Microservices (Proposed)

o  Micro services are not allowed to talk to each other (e.g. as per
http://www.infoq.com/presentations/domain-service-aggregator,
aggregation is done at client browser)
o  MicroServices view is no central server like ESB or BPS and do
composition at client.
o  For this some has recommended using "backends for
frontends" (BFF) [1] and some even claims to be using it [2]. But
then, we are back at ESB, maybe little bit less logic at integration
layer but almost the same.
1.  https://www.safaribooksonline.com/library/view/Building
+Microservices/9781491950340/ch04.html
2.  http://www.slideshare.net/grandbora/microservices-
soundcloud slide 39
Composition of Microservices

o  Overhead driving it from client which might be behind
slow network,
o  Might add security concerns ( I can hack my app to give
me a loan)
o  MicroServices so far talk about websites, and most
complex compositions often come from other use cases.
So general applicability of composition at the client yet to
be demonstrated.
o  Where to keep the State? Can client be trusted to keep the
state of the workflow
Composition of Microservices:
Problems

o  OK to use pure client driven model, if above drawbacks are not a
Major concern.
o  If they are a concern, you need use centralized orchestrator ( use
SOA approach). For example
http://www.infoq.com/articles/microservices-intro propose to use
a API Gateway, which pretty much the SOA Approch.
Composition of Microservices:
Conclusion

o  Goal of Microservices is loose coupling
o  Reference, Time, Format, Platform Autonomy
o  Micro-Services are all about…
o  …proper granularity of components
o  …independent deployment
o  It is an further evolution of SOA ideas
o  It is still evolving concepts, and some ground truths are
being established.
Conclusion

Deep-dive into Microservice Outer Architecture

More Related Content

What's hot

Viewers also liked

Similar to Deep-dive into Microservice Outer Architecture

More from WSO2

Recently uploaded

Deep-dive into Microservice Outer Architecture