Microservices: Outer Architecture

Webinar January 2016

FrankLeyman&SrinathPerera

Causes of Volatility of RPC (i.e. Synchronous Communication)

o TimeDependency≈Allingredientshavetobeavailableatsame8me

o FormatDependency≈Numberandtypesofparametersmustmatch

o ReferenceDependency≈Hard-codedaddresses

o PlaAormDependency≈Internalrepresenta8onsofdata(liDle/bigendian...)

Thisis8ghtcoupling!

Loose Coupling

Coreprinciple:Reducenumberofassump8onstwopar8esmakeabouteachotherwhentheyexchangeinforma8on

o ReferenceAutonomyo Producersandconsumersdon’tknoweachother

o TimeAutonomyo Producersandconsumersexecuteattheirownpace

o FormatAutonomyo Producersandconsumersmayusedifferentformatsofdataexchanged

o PlaAormAutonomyo Producersandconsumersmaybeindifferentenvironments,wriDenindifferentlanguages,…

Loose Coupling: Autonomy Dimensions

Loose Coupling in SOA

o  ReferenceAutonomyo  Clientinteractswithanendpoint(oRenaURI)notwithaconcreteprogram,i.e.clientdoesn’tknowtheactualservice

o  TimeAutonomyo  Asynchronousbindings(JMS,…)canbeusedo  Reply-toheader,Correla8onheader,…supportasynchronyevenoversynchronoustransports

o  FormatAutonomyo  Bindingspecifiesserializa8onformato  Transforma8oncanbedone“invisibly”along

thewire

o  PlaAormAutonomyo  Clientinteractswithservicewithouthavingtoknowprogramminglanguage,hos8ngenvironment,…ofservice

o Interac8onwithURIaddressableresourceso Fixedsetofgenericinterac8ons(mainlyHTTPGET,POST,PUT,andDELETE)

o Standarddataformat(HTML,XML,JSON,...-MIMEtypes)

o Statelesso Allcontextisfullyunderstandablefrommessage

Characteristics Of The Web Architecture: The Underpinnings Of REST

We Will See in What Follows...

RESTarchitecturalstylesupportsloosecoupling

Reference Autonomy in REST: URIs

Resource Implementation

Resource Implementation

Resource

Resource

URI Client

REST Server

o URIdecouplesfromknowingtheactualfunc8onimplementa8on

o HATEOASgoesbeyond(seelater)

o  Some8mesrequestsmaytaketoolongforaclienttowaitforresponseo  EspeciallyPOSTandDELETEmaytakesome8me

(theymightini8ateacompletebusinessprocesses)o  Serveracknowledgesrecep8onofrequest

o  ViaHTTPStatusCode202Acceptedo  Serverprovidesaresourcethatclientcanusetotrack

progressoflong-runningrequest(aka“task”)o  ViaContent-Loca:onheaderofthisresource,oro  ViaLinktothisresource

Time Autonomy in REST: Long Running Requests

o  ORen,requesteden8tyisavailableinmul8plevariantso  Differentlanguages(English,German,...)o  Differentencodings(GIF,JPEG,...)o  Differentquali8es(colored,black-and-white,...)to

accommodateo  differentline/connec8onspeedso  Differentformats(HTML,XML,RDF,JSON…)

o  HTTPdefinesprocedurestonego8atetheappropriate

varianttobetransferred

Format Autonomy in REST: Content Negotiation

o  ThepremiertransporttoimplementRESTisHTTP(S)o  HTTPclientsandHTTPserversareavailableinallmajor

environmentso  Programsinmostlanguagescanbeproducersand

consumersofHTTPmessages

Platform Autonomy in REST

o  HATEOAS=HypermediaAsTheEngineOfApplica8onState

o  InREST,clientscanevenbede-coupledfromthe

individualfunc8onsprovidedbyservicesandthestateofinterac8oninwhichfunc8onscanbeused

o  Theserverreturnslinks(“hypermedia”)thatdescribe

thefunc8onsvalidintheactual“state”ofthe“applica8on”

Increasing Reference Autonomy: HATEOAS

REST Maturity Model (aka Richardson Maturity Model)

■  SupportofHATEOAS■  UseofappropriateHTTPmethods

tomanipulateindividualresources■  UseofappropriateHTTPstatus

codes■  Individualresourcesareiden8fied■  Useofsinglemethod(typically

POST)■  Methodinvokedonindividual

resource■  Similarto“objects”■  HTTPisusedasatransportonly■  Singleentrypointonly■  Useofsinglemethod(typically

POST)■  Examples:SOAP,XML-RPC

SwampofPOX

Resources

HTTPVerbs

HypermediaControls

Level0

Level1

Level2

Level3

o  …microservicearchitecturalstyleisanapproachtoo  developingasingleapplica8onasasuiteofsmallservices,o  eachrunninginitsownprocessando  communica8ngwithlightweightmechanisms,oRenanHTTP

resourceAPI.o  Theseservicesarebuilt

o  aroundbusinesscapabili8esando  independentlydeployablebyfullyautomateddeployment

machinery.o  Thereisabareminimumofcentralizedmanagementof

theseservices,whicho  maybewriDenindifferentprogramminglanguagesando  usedifferentdatastoragetechnologies.

Definition: Quote(*)

(*)J.Lewis&M.Fowler:“Microservices”(2015),hDp://mar8nfowler.com/ar8cles/microservices.html

Microservice: Main Properties Microserviceis■  small■  runninginitsownprocess

(orcontainerthesedays)■  communica8ngoRen[via]HTTP■  builtaroundbusinesscapabili8es■  wriDenindifferentprogramming

languages■  usedifferentdatastorage

technologies■  independentlydeployablebyfully

automateddeploymentmachinery

16

…whateverthatmeans

Trueformany(!)service

Trueformany(!)service,andmostRESTservices

That’swhatservicesareallabout!

That’sinteres8ng

Microservice: The Essence?

Amicroserviceisaservicethatisindependentlydeployable

byfullyautomateddeploymentmachinery

…andthishasinteres8ngimplica8ons(seenext)

AProblem

■  Youhavea“bigapplica8on”(a.k.a.“monolith”)■  Ifyouwanttoreplicateit

■  …e.g.becauseofscale,availability,elas8city,…youpaypenal8es(e.g.licensesforallcomponents)althoughyouonlyneed“afewcomponents”replicated

Application

… Sca

le,

HA,…

Solution

■  Splityour“bigapplica8on”intosmallergranulesthatcanbedeployedindependently■  I.e.splititintomicro-services

■  Replica8oncanberestrictedtothosecomponentsthatturn

outtobeboDlenecks(⇒scale),cri8cal(⇒HA),…withoutpayingthepenal8esforallothercomponentsofthe“bigapplica8on”

19

Application

o  Micro-Servicesareallabout…o  …propergranularityofcomponentso  …independentdeployment

o  Theyarenotacounter-proposaltoSOAo  TheydonotprovethatSOAfailed

o  Intheopposite:theyrequireloosecoupling,…o  Theyrequireamethodologytodetermine“propergranules”for

componentso  …somethingliketheholygrailofsoRwareengineeringfor

decades!o  …so,don’texpectyourmiddlewarevendorstosolvethis

problemforyou!It’sallaboutYOUsolvinganverydifficultarchitecture/designproblem!!!

The Essence of Micro-Services

What does it mean?

Let’sexplorewhatthismeansforyourdesign

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

MicroService Security

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 SOA

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