To view recording of this webinar please use the below URL:
http://wso2.com/library/webinars/2016/02/deep-dive-into-microservice-outer-architecture/
Microservices architecture (MSA) promotes loosely coupled services as building blocks for software system architecture. It was first adopted by large internet companies like Netflix and now is popular with enterprise architects everywhere.
You may find yourself asking what the main premises of MSA are and whether it replaces SOA. In this webinar Frank and Srinath will
Compare and contrast MSA with SOA and discuss both their pros and cons
Examine what MSA looks like in practice
Answer questions such as where to use databases, how to use security and how to perform service orchestration and integration
Discuss practical challenges
2. 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!
5. 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 specifies 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
7. We Will See in What Follows...
REST architectural style supports loose coupling
8. 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)
13. 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 iden8fied
■ 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
14.
15. 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 different programming languages and
o use different data storage technologies.
Definition: Quote(*)
(*) J. Lewis & M. Fowler: “Microservices” (2015), hDp://mar8nfowler.com/ar8cles/
microservices.html
16. 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 different programming
languages
■ use different 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
20. 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 difficult
architecture/design problem!!!
The Essence of Micro-Services
21. What does it mean?
Let’s explore what this means for your design
22. 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
23. 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?
24. 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
25. 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
27. 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.)
30. 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
31. 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
32. 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
33. 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