Microservices

FlexibleSoftwareArchitectures

EberhardWolff

Thisbookisforsaleathttp://leanpub.com/microservices-book

Thisversionwaspublishedon2016-01-10

*****

ThisisaLeanpubbook.LeanpubempowersauthorsandpublisherswiththeLeanPublishingprocess.LeanPublishingistheactofpublishinganin-progressebookusinglightweighttoolsandmanyiterationstogetreaderfeedback,pivotuntilyouhavetherightbookandbuildtractiononceyoudo.

*****

©2015-2016EberhardWolff

TableofContents

1Preface1.1OverviewofMicroservice1.2WhyMicroservices

PartI:MotivationandBasics

2Introduction2.1OverviewoftheBook2.2ForWhomistheBookMeant?2.3ChapterOverview2.4Essays2.5PathsThroughtheBook2.6Acknowledgement

3MicroserviceScenarios3.1ModernizinganE-CommerceLegacyApplication3.2DevelopingaNewSignalingSystem3.3Conclusion

PartII:Microservices:What,WhyandWhyNot?

4WhatareMicroservices?4.1SizeofaMicroservice4.2Conway’sLaw4.3Domain-DrivenDesignandBoundedContextWhyYouShouldAvoidaCanonicalDataModel(StefanTilkov)4.4MicroserviceswithUI?4.5Conclusion

5ReasonsforMicroservices5.1TechnicalBenefits5.2OrganizationalBenefits5.3BenefitsfromaBusinessPerspective5.4Conclusion

6Challenges

6.1TechnicalChallenges6.2Architecture6.3InfrastructureandOperations6.4Conclusion

7MicroservicesandSOA7.1WhatisSOA?7.2DifferencesBetweenSOAandMicroservices7.3Conclusion

PartIII:ImplementingMicroservices

8ArchitectureofMicroservice-basedSystems8.1DomainArchitecture8.2ArchitectureManagement8.3TechniquestoAdjusttheArchitecture8.4GrowingMicroservice-basedSystemsDon’tMisstheExitPointorHowtoAvoidtheErosionofaMicroservice(LarsGentsch)8.5MicroservicesandLegacyApplicationsHiddenDependencies(OliverWehrens)8.6Event-drivenArchitecture8.7TechnicalArchitecture8.8ConfigurationandCoordination8.9ServiceDiscovery8.10LoadBalancing8.11Scalability8.12Security8.13DocumentationandMetadata8.14Conclusion

9IntegrationandCommunication9.1WebandUI9.2REST9.3SOAPandRPC9.4Messaging9.5DataReplication9.6Interfaces:InternalandExternal9.7Conclusion

10ArchitectureofIndividualMicroservices10.1DomainArchitecture10.2CQRS10.3EventSourcing10.4HexagonalArchitecture10.5ResilienceandStability10.6TechnicalArchitecture10.7Conclusion

11TestingMicroservicesandMicroservice-basedSystems11.1WhyTests?11.2HowtoTest?11.3MitigateRisksatDeployment11.4TestingtheOverallSystem11.5TestingLegacyApplicationsandMicroservices11.6TestingIndividualMicroservices11.7Consumer-drivenContractTests11.8TestingTechnicalStandards11.9Conclusion

12OperationsandContinuousDeliveryofMicroservices12.1ChallengesAssociatedwiththeOperationofMicroservices12.2Logging12.3Monitoring12.4DeploymentCombinedorSeparateDeployment?(JörgMüller)12.5Control12.6Infrastructure12.7Conclusion

13OrganizationalEffectsofaMicroservices-basedArchitecture13.1OrganizationalBenefitsofMicroservices13.2AnAlternativeApproachtoConway’sLaw13.3MicroandMacroArchitecture13.4TechnicalLeadership13.5DevOpsWhenMicroservicesMeetClassicalITOrganizations(AlexanderHeusingfeld)

13.6InterfacetotheCustomer13.7ReusableCode13.8MicroservicesWithoutChangingtheOrganization?13.9Conclusion

PartIV:Technologies

14ExampleforaMicroservices-basedArchitecture14.1DomainArchitecture14.2BasicTechnologies14.3Build14.4DeploymentUsingDocker14.5Vagrant14.6DockerMachine14.7DockerCompose14.8ServiceDiscovery14.9Communication14.10Resilience14.11LoadBalancing14.12IntegratingOtherTechnologies14.13TestsExperienceswithJVM-basedMicroservicesintheAmazonCloud(SaschaMöllering)14.14Conclusion

15TechnologiesforNanoservices15.1WhyNanoservices?15.2Nanoservices:Definition15.3AmazonLambda15.4OSGi15.5JavaEE15.6Vert.x15.7Erlang15.8Seneca15.9Conclusion

16HowtoStartwithMicroservices16.1WhyMicroservices?16.2RoadstowardsMicroservices

16.3Microservice:HypeorReality?16.4Conclusion

1Preface

EventhoughMicroservicesareanewterm,theyhavehauntedmealreadyforalongtime.In2006WernerVogels(CTO,Amazon)gaveatalkattheJAOOconferencepresentingtheAmazonCloudandAmazon’spartnermodel.InhistalkhementionedtheCAPtheorem,todaythebasisforNoSQL.Inadditionhewastalkingaboutsmallteams,whichdevelopandrunserviceswiththeirowndatabases.ThistypeoforganizationisnowadayscalledDevOps,andthearchitectureisknownasMicroservices.

LaterIwasaskedtodevelopastrategyforaclientallowinghimtointegratemoderntechnologiesintohisexistingapplication.AfterafewattemptstointegratethenewtechnologiesdirectlyintotheLegacycode,wefinallybuiltanewapplicationwithacompletelydifferentmoderntechnologystackalongsidetheoldone.TheoldandthenewapplicationwereonlycoupledviaHTMLlinksandviaashareddatabase.ExceptfortheshareddatabasethisisinessenceaMicroservicesapproach.Thathappenedin2008.

Alreadyin2009anotherclienthaddividedhiscompleteinfrastructureintoRESTservices,whichwereeachdevelopedbyindividualteams.ThisisalsocalledMicroservicestoday.Manyothercompanieswithaweb-basedbusinessmodelhadalreadyimplementedsimilararchitecturesatthetime.LatelyIrealizedinadditionthatContinuousDeliveryinfluencesthesoftwarearchitecture.AlsothereMicroservicesoffermanyadvantages.

Thisisthereasonforwritingthisbook:Microservicesconstituteanapproachanumberofpeoplehavealreadybeenpursuingforalongtime,amongthemmanyveryexperiencedarchitects.LikeeveryotherapproachtoarchitectureMicroservicesforsurecannotsolveeveryproblem,howeverthisconceptrepresentsaninterestingalternativetoexistingapproaches.

1.1OverviewofMicroserviceMicroservice:PreliminaryDefinition

ThefocusofthisbookareMicroservices–anapproachforthemodularizationofsoftware.Modularizationinitselfisnothingnew.Forquitesometimelarge

systemshavebeendividedintosmallmodulestofacilitatetheimplementation,understandingandfurtherdevelopmentofsoftware.

ThenewaspectisthatMicroservicesusemodules,whichrunasdistinctprocesses.ThisapproachisbasedonthephilosophyofUNIX,whichcanbereducedtothreeaspects:

Oneprogramshouldonlyfulfillonetask,butthisitshoulddoreallywell.Programsshouldbeabletoworktogether.Auniversalinterfaceshouldbeused.InUNIXthisisprovidedbytextstreams.

ThetermMicroserviceisnotfirmlydefined.Chapter4providesamoredetaileddefinition.However,thefollowingcriteriacanserveasfirstapproximation:

Microservicesareamodularizationconcept.Theirpurposeistodividelargesoftwaresystemsintosmallerparts.Thustheyinfluencetheorganizationanddevelopmentofsoftwaresystems.Microservicescanbedeployedindependentlyofeachother.ChangestooneMicroservicecanbetakenintoproductionindependentlyofchangestootherMicroservices.Microservicescanbeimplementedindifferenttechnologies.ThereisnorestrictionontheprogramminglanguageortheplatformforeachMicroservice.Microservicespossesstheirowndatastorage:aprivatedatabase–oracompletelyseparateschemainashareddatabase.Microservicescanbringtheirownsupportservicesalong,forexampleasearchengineoraspecificdatabase.Ofcourse,thereisacommonplatformforallMicroservices–forexamplevirtualmachines.Microservicesareself-containedprocesses–orvirtualmachinese.g.tobringthesupportingservicesalong.Accordingly,Microserviceshavetocommunicateviathenetwork.TodosoMicroservicesuseprotocols,whichsupportloosecouplingsuchasRESTormessaging.

DeploymentMonoliths

MicroservicesaretheoppositeofDeploymentMonoliths.ADeploymentMonolithisalargesoftwaresystem,whichcanonlybedeployedinonepiece.IthastogetinitsentiretythroughallphasesoftheContinuousDeliverypipeline

suchasdeployment,theteststagesandrelease.DuetothesizeofDeploymentMonolithstheseprocessestakelongerthanforsmallersystems.Thisreducesflexibilityandincreasesprocesscosts.DeploymentMonolithcanhaveamodularstructureinternally–still,allmoduleshavetobebroughtintoproductionsimultaneously.

1.2WhyMicroservicesMicroservicesallowtodividesoftwareintomodulesandtherebyimprovethesoftwarechangeability.

Fig.1:AdvantagesofMicroservices

Microservicesofferanumberofimportantadvantages:

StrongModularization

Microservicesareastrongmodularizationconcept.WheneverasystemisbuiltfromdifferentsoftwarecomponentssuchasRubyGEMs,JavaJARs,.NETAssembliesorNode.jsNPMs,unwishedfordependenciescaneasilycreepin.Somebodyreferencesaclassorfunctioninaplacewhereitisnotsupposedtobeused.Afterashortwhilesomanydependencieswillhaveaccumulatedthatthesystemcannolongerbeservicedorfurtherdeveloped.

Microservices,incontrast,communicateviaexplicitinterfaces,whicharerealizedusingmechanismslikemessagesorREST.Accordingly,thetechnicalhurdlesfortheuseofMicroservicesarehigher.Thusunwanteddependenciescanhardlyarise.InprincipleitshouldbepossibletoachievealsoahighlevelofmodularizationinDeploymentMonoliths.However,practicalexperienceteachesthatthearchitectureofDeploymentMonolithsprogressivelydeterioratesovertime.

EasyReplaceability

Microservicescanmoreeasilybereplaced.OthercomponentsutilizeaMicroserviceviaanexplicitinterface.Wheneveraserviceoffersthesameinterface,itcanreplacetheMicroservice.ThenewMicroservicedoesneitherneedtouseapartofthecodebasisnorthetechnologiesoftheoldMicroservice.Suchlikerestrictionsoftenpreventthemodularizationoflegacysystems.

SmallMicroservicesfurtherfacilitatereplacements.Suchreplacementsareoftenneglectedduringthedevelopmentofsoftwaresystems.Wholikestotakeintoconsiderationhowthejustbuiltsystemcanbereplacedinthefuture?TheeasyreplaceabilityofMicroservicesreducesinadditionthecostsofincorrectdecisions.WhenthedecisionforatechnologyorapproachislimitedtoaMicroservice,thisMicroservicecanbecompletelyrewrittenifneedarises.

SustainableDevelopment

Thestrongmodularizationandtheeasyreplaceabilityallowforsustainablesoftwaredevelopment.Mostofthetimeworkingonanewprojectisquitesimple.Uponlongerprojectruntimeproductivitydecreases.Oneofthereasonsistheerosionofarchitecture.Microservicescounteractthiserosionduetothestrongmodularization.Beingboundtooutdatedtechnologiesandthedifficultiesassociatedwiththeremovalofoldsystemmodulesconstituteadditionalproblems.Microservices,whicharenotlinkedtoaspecifictechnologyandcanbyreplacedonebyone,overcometheseproblems.

FurtherDevelopmentofLegacyApplications

StartingwithaMicroservicesarchitectureiseasyandprovidesimmediateadvantageswhenworkingwitholdsystems:InsteadofhavingtoaddtotheoldandhardtounderstandcodebasethesystemcanbeenhancedwithaMicroservice.TheMicroservicecanactonspecificrequestswhileleavingallotherstothelegacysystem.Itcanmodifyrequestspriortotheirprocessingbythelegacysystem.Inthismannerreplacingthecompletefunctionalityofthelegacysystemcanbecircumvented.Inaddition,theMicroserviceisnotboundtothetechnologystackofthelegacysystem,butcanbedevelopedusingmodernapproaches.

Time-to-Market

Microservicesallowforabettertime-to-market.Asmentionedbefore,Microservicescanbebroughtintoproductiononaone-by-onebasis.Ifteams

workingonalargesystemareresponsibleforoneorseveralMicroservicesandiffeaturesrequireonlychangestotheseMicroservices,eachteamcandevelopandbringfeaturesintoproductionwithouttimeconsumingcoordinationwithotherteams.InthismannermanyteamscanworkonnumerousfeaturesinparallelandbringmorefeaturesintoproductionwithinacertaintimethanwouldhavebeenpossiblewithaDeploymentMonolith.MicroserviceshelpscalingagileprocessestolargeteamsbydividingthelargeteamintosmallteamseachdealingwiththeirownMicroservices.

IndependentScaling

EachMicroservicecanbescaledindependentlyofotherservices.Thisobliteratestheneedtoscalethewholesystemwhenitisonlyafewfunctionalitiesthatareusedintensely.Thiswilloftenbeadecisivesimplification.

FreeChoiceofTechnologies

WhendevelopingMicroservicestherearenorestrictionsinregardstotheusageoftechnologies.ThisallowstotestanewtechnologywithinasingleMicroservicewithoutaffectingotherservices.Therebytheriskassociatedwiththeintroductionofnewtechnologiesandnewversionsofalreadyusedtechnologiesisdecreasedasthesenewtechnologiesareintroducedandtestedinaconfinedenvironmentkeepingpotentialcostslow.Inadditionitispossibletousespecifictechnologiesforspecificfunctionalities,forexampleaspecificdatabase.TheriskissmallastheMicroservicecaneasilybereplacedorremoved.ThenewtechnologyisconfinedtooneorfewMicroservices.ThisreducesthepotentialriskandenablesindependenttechnologydecisionsfordifferentMicroservices.Moreover,itfacilitatesthedecisiontotryoutandevaluatenew,highlyinnovativetechnologies.Thisincreasestheproductivityofdevelopersandpreventsthatthetechnologyplatformbecomesoutdated.Inaddition,theuseofmoderntechnologieswillattractqualifieddevelopers.

ContinuousDelivery

MicroservicesareadvantageousforContinuousDelivery.Theyaresmallandcanbedeployedindependentlyofeachother.RealizingaContinuousDeliverypipelineissimpleduetothesizeofaMicroservice.ThedeploymentofasingleMicroserviceisassociatedwithlessriskthanthedeploymentofalargemonolith.ItisalsoeasiertoassurethesafedeploymentofaMicroservice,forinstancebyrunningdifferentversionsinparallel.FormanyMicroserviceusersContinuousDeliveryisthemainreasonfortheintroductionofMicroservices.

AllthesereasonsarguefortheintroductionofMicroservices.Whichofthesereasonsarethemostimportantwilldependonthecontext.ScalingagileprocessesandContinuousDeliveryareoftencrucialfromabusinessperspective.Chapter5describestheadvantagesofMicroservicesindetailanddealsalsowithprioritization.

Challenges

However,thereisnolightwithoutshadow.AccordinglyChapter6willdiscussthechallengesposedbytheintroductionofMicroservicesandhowtodealwiththem.Inshort,themainchallengesarethefollowing:

RelationshipsareHidden.

Thearchitectureofthesystemconsistsoftherelationshipsbetweentheservices.However,itisnotevidentwhichMicroservicecallswhichotherMicroservice.Thismakesworkingonthearchitecturechallenging.

RefactoringisDifficult.

Thestrongmodularizationleadsalsotodisadvantages:Refactorings,whichmovefunctionalitiesbetweenMicroservices,aredifficulttoperform.And,onceintroduced,itishardtochangetheMicroservices-basedmodularizationofasystem.However,theseproblemscanbelessenedbysmartapproaches.

DomainArchitectureisImportant.

ThemodularizationintoMicroservicesforthedifferentdomainsisimportantasitdetermineshowteamsaredivided.Problemsatthislevelinfluencealsotheorganization.OnlyasoliddomainarchitecturecanensuretheindependentdevelopmentofaMicroservice.Asitisdifficulttochangetheonceestablishedmodularization,mistakescanbehardtocorrectlateron.

RunningMicroservicesisComplex.

AsystemcomprisedofMicroserviceshasmanycomponents,whichhavetobedeployed,controlledandrun.Thisincreasesthecomplexityforoperationsandthenumberofruntimeinfrastructuresusedbythesystem.Microservicesnecessitatetheautomatizationofoperationsasoperatingtheplatformisotherwisetoolaborious.

DistributedSystemsareComplex.

Thecomplexitythedevelopersarefacingincreases:AMicroservice-basedsystemisadistributedsystem.CallsbetweenMicroservicescanfailduetonetworkproblems.Callsviathenetworkareslowerandhaveasmallerbandwidththancallswithinaprocess.

PartI:MotivationandBasics

ThispartofthebookconveyswhatMicroservicesare,whytheyareinterestingandwheretheyareofuse.PracticalexamplesdemonstratetheeffectsofMicroservicesindifferentscenarios.Chapter2explainsthestructureofthebook.ToillustratetheimportanceofMicroserviceschapter3containsdetailedscenarioswhereMicroservicescanbeused.

2Introduction

Thischapterfocusesonthebookitself:Section2.1explainsbrieflythebookconcept.Section2.2describestheaudienceforwhichthebookwaswritten.Section2.3providesanoverviewofthedifferentchaptersandthestructureofthebook.Section2.5describespathsthroughthebookfordifferentaudiences.Section2.6finallycontainstheacknowledgements.Errata,linkstoexamplesandadditionalinformationcanbefoundathttp://microservices-book.com/.Theexamplecodeisavailableathttps://github.com/ewolff/microservice/.

2.1OverviewoftheBookThisbookprovidesadetailedintroductiontoMicroservices.Architectureandorganizationarethemaintopics.However,technicalimplementationstrategieswillnotbeneglected.AcompleteexampleofaMicroservice-basedsystemdemonstratesaconcretetechnicalimplementation.TechnologiesforNanoservicesillustratesthatmodularizationdoesnotstopwithMicroservices.ThebookprovidesallnecessaryinformationinordertoenablereaderstostartusingMicroservices.

2.2ForWhomistheBookMeant?Thebookaddressesmanagers,architectsanddeveloperswhowanttointroduceMicroservicesasanarchitecturalapproach.

Managers

MicroservicescanprofitfromthemutualsupportofarchitectureandorganizationMicroservicesoffer.IntheintroductionmanagersgettoknowthebasicideasbehindMicroservices.AfterwardstheycanfocusontheorganizationaleffectsofutilizingMicroservices.

Developers

DevelopersareprovidedwithacomprehensiveintroductiontothetechnicalaspectsandcanacquirethenecessaryskillstouseMicroservices.AdetailedexampleofatechnicalimplementationofMicroservicesaswellasnumerous

additionaltechnologies,forexampleforNanoservices,facilitategraspingthebasicconcepts.

Architects

ArchitectsgettoknowMicroservicesfromanarchitectureperspectiveandcanatthesametimedeepentheirunderstandingoftheassociatedtechnicalandorganizationalissues.

Thebookhighlightspossibilitiesforexperimentsandadditionalinformationsources.Sotheinterestedreadercantesther/hisnewknowledgepracticallyanddelvedeeperintosubjectsthatareofrelevancetoher/him.

2.3ChapterOverviewPartI

ThefirstpartofthebookexplainsthemotivationforusingMicroservicesandthefoundationoftheMicroservicesarchitecture.Thepreface(chapter1)alreadypresentedthebasicpropertiesaswellasadvantagesanddisadvantagesofMicroservices.Chapter3presentstwoscenariosfortheuseofMicroservices:anE-Commerceapplicationandasystemforsignalprocessing.ThispartconveysfirstinsightsintoMicroservicesandalreadypointsoutcontextsforapplications.

PartII

PartIIdoesnotonlyexplainMicroservicesindetail,butalsodealswiththeiradvantagesanddisadvantages:

Chapter4investigatesthedefinitionofthetermMicroservices”fromthreeperspectives:thesizeofaMicroservice,Conway’sLaw,whichstatesthatorganizationscanonlycreatespecificsoftwarearchitectures,andfinallyfromatechnicalperspectivebasedonDomain-DrivenDesignandBoundedContext.ThereasonsforusingMicroservicesaredetailedinchapter5.Microservicesdonotonlyhavetechnical,butalsoorganizationaladvantages,andalsofromabusinessperspectivetherearegoodreasonsforturningtoMicroservices.TheuniquechallengesposedbyMicroservicesarediscussedinchapter6.Amongthesearetechnicalchallengesaswellasproblemsrelatedtoarchitecture,infrastructureandoperation.

Chapter7aimsatdefiningthedifferencesbetweenMicroservicesandSOA(Service-OrientedArchitecture).Atfirstsightbothconceptsseemtobecloselyrelated.However,acloserlookrevealsaplethoraofdifferences.

PartIII

PartIIIdealswiththeapplicationofMicroservicesanddemonstrateshowtheadvantagesthatweredescribedinpartIIcanbeobtainedandhowtheassociatedchallengescanbesolved.

Chapter8describesthearchitectureofMicroservice-basedsystems.Inadditiontodomainarchitecturecomprehensivetechnicalchallengesarediscussed.Chapter9presentsthedifferentpossibilitiesfortheintegrationofandthecommunicationbetweenMicroservices.ThisincludesnotonlyacommunicationviaRESTormessaging,butalsoanintegrationofUIsandthereplicationofdata.Chapter10showspossiblearchitecturesforMicroservicessuchasCQRS,EventSourcingorhexagonalarchitecture.Finallysuitabletechnologiesfortypicalchallengesareaddressed.Testingisthemainfocusofchapter11.TestshavetobeasindependentaspossibletoallowfortheindependentdeploymentofthedifferentMicroservices.NeverthelessthetestshavenotonlytochecktheindividualMicroservices,butalsothesysteminitsentirety.OperationandContinuousDeliveryareaddressedinchapter12.Microservicesgenerateahugenumberofdeployableartefactsandthusincreasethedemandsontheinfrastructure.ThisisasubstantialchallengewhenintroducingMicroservices.Chapter13illustrateshowMicroservicesalsoinfluencetheorganization.Afterall,Microservicesareanarchitecture,whichissupposedtoinfluenceandimprovetheorganization.

PartIV

ThelastpartofthebookshowsindetailandatthecodelevelhowMicroservicescanbetechnicallyimplemented:

Chapter14containsanexhaustiveexampleforaMicroservicesarchitecturebasedonJava,SpringBoot,DockerandSpringCloud.Thischapteraimsatprovidinganapplication,whichcanbeeasilyrun,illustratestheconcepts

behindMicroservicesinpracticaltermsandoffersastartingpointfortheimplementationofaMicroservicessystemandexperiments.EvensmallerthanMicroservicesaretheNanoservices,whicharepresentedinchapter15.Nanoservicesexactspecifictechnologiesandanumberofcompromises.Thechapterdiscussesdifferenttechnologiesinthecontextoftheiradvantagesanddisadvantages.Chapter16demonstratesintheendhowMicroservicescanbeadopted.

2.4EssaysThebookcontainsassays,whichwerewrittenbyMicroservicesexperts.TheexpertswereaskedtorecordtheirmainfindingsregardingMicroservicesonapproximatelytwopages.Sometimestheseassayscomplementbookchapters,sometimestheyfocusonothertopics,andsometimestheycontradictpassagesinthebook.Thisillustratesthatthereisingeneralnosinglerightanswerwhenitcomestosoftwarearchitectures,butratheracollectionofdifferentopinionsandpossibilities.Theessaysoffertheuniqueopportunitytogettoknowdifferentviewpointsinordertosubsequentlydevelopanopinion.

2.5PathsThroughtheBookThebookofferssuitablecontent(Tab.1)foreachtypeofaudience.Ofcourse,everybodycanandshouldreadalsochaptersthatareprimarilymeantforpeoplewithadifferenttypeofjob.Neverthelessthechaptersarefocussingontopicsthataremostrelevantforacertainaudienceasindicatedbelow.

Tab.1:PathsthroughthebookChapter Developer Architect Manager3-MicroserviceScenarios X X X4-WhatareMicroservices? X X X5-ReasonsforUsingMicroservices X X X6-ChallengesRegardingMicroservices X X X7-MicroservicesandSOA X X8-ArchitectureofMicroservice-basedSystems X

9-IntegrationandCommunication X X 10-ArchitectureofIndividualMicroservices X X 11-TestingMicroservicesandMicroservice-basedSystems X X

12-OperationsandContinuousDeliveryofMicroservices X X

13-OrganizationalEffectsofaMicroservices-basedArchitecture X

14-ExampleforaMicroservice-basedArchitecture X

15-TechnologiesforNanoservices X X 16-HowtostartwithMicroservices? X X X

Readerswhoonlywanttoobtainanoverviewareadvisedtoconcentrateonthesummarysectionattheendofeachchapter.Peoplewhowanttogainfirstofallpracticalknowledgeshouldcommencewithchapters14and15,whichdealwithconcretetechnologiesandcode.

Theinstructionsforexperiments,whicharegiveninthesections“TryandExperiment”,helptodeepentheunderstandingbydoingpracticalexercises.Wheneverachapterisofparticularinterestforthereader,he/sheisencouragedtocompletetherelatedexercisestogetabettergrasponthetopicspresentedintherespectivechapter.

2.6AcknowledgementIwouldliketothankeverybodywithwhomIhavediscussedMicroservicesandallthepeoplewhoaskedquestionsorworkedwithme-waytoomanytolistthemall.Theinteractionsanddiscussionswereveryfruitfulandfun!

IwouldliketomentionespeciallyJochenBinder,MatthiasBohlen,MertenDriemeyer,MartinEigenbrodt,OliverB.Fischer,LarsGentsch,OliverGierke,BorisGloger,AlexanderHeusingfeld,ChristineKoppelt,AndreasKrüger,TammovanLessen,SaschaMöllering,AndréNeubauer,TillSchulte-Coerne,StefanTilkov,KaiTödter,OliverWolfandStefanZörner.

MyemployerinnoQhasalsoplayedanimportantrolethroughoutthewritingprocess.ManydiscussionsandsuggestionsofmyinnoQcolleaguesarereflectedinthebook.

FinallyIwouldliketothankmyfriendsandfamilyandespeciallymywifewhomIhaveoftenneglectedwhileworkingonthebook.InadditionIwouldliketothank

herfortheEnglishtranslationofthebook.

Ofcourse,mythanksgoalsotoallthepeoplewhohavebeenworkingonthetechnologiesthatarementionedinthebookandthushavelaidthefoundationforthedevelopmentofMicroservices.SpecialthanksalsototheexpertswhosharedtheirknowledgeofandexperiencewithMicroservicesintheessays.

Leanpubhasprovidedmewiththetechnicalinfrastructuretocreatethetranslation.IthasbeenapleasuretoworkwithitanditisquitelikelythatthetranslationwouldnotexistwithoutLeanpub.

LastbutnotleastIwouldliketothankdpunkt.verlagandRenéSchönfeldtwhosupportedmeveryprofessionallyduringthegenesisoftheoriginalGermanversion.

3MicroserviceScenarios

ThischapterwillpresentanumberofscenariosinwhichMicroservicescanbeuseful.Section3.1focusesonthemodernizationofalegacywebapplication.ThisscenarioisthemostcommoncontextforMicroservices.Averydifferentscenarioisdiscussedinsection3.2.InthiscaseasignalingsystemissupposedtobedevelopedasdistributedsystembasedonMicroservices.Section3.3formulatesaconclusionandinvitesthereaderstojudgeforthemselvesontheusefulnessofMicroservicesinthepresentedscenarios.

3.1ModernizinganE-CommerceLegacyApplicationScenario

TheBigMoneyOnlineCommerceinc.runsanE-commerceshop,whichisthemainsourceofthecompanyrevenue.Itisawebapplicationofferingmanydifferentfunctionalitiessuchasuserregistrationandadministration,productsearch,anoverviewofordersandtheorderingprocess–thecentralfeatureofanE-commerceapplication.

ThisapplicationisaDeploymentMonolith:Itcanonlybedeployedinitsentirety.Wheneverafeatureischanged,theentireapplicationneedstobedeployedanew.TheE-Commerceshopworkstogetherwithothersystems–forinstancewithaccountingandlogistics.

ReasonstoUseMicroservices

TheDeploymentMonolithoncestartedoutasawell-structuredapplication.However,overtheyearsmoreandmoredependenciesbetweentheindividualmodulescreepedin.Forthisreasontheapplicationisnowadayshardlymaintainableandchangeable.Inadditiontheoriginalarchitectureisnotsuitedanymoreforthecurrentrequirements.ProductsearchforinstancehasbeengreatlymodifiedastheBigMoneyOnlineCommerceinc.attemptstooutperformitscompetitorsespeciallyinthisarea.Likewisemoreandmorepossibilitieshavebeengeneratedforclientstosolveproblemsbythemselveswithouttheassistanceofaclientservice.Thishelpedthecompanytoreducecosts.Accordingly,these

twomodulesbecameverylargewithaverycomplexinternalstructureandmanydependenciesonothermodulesthathadnotbeenplannedfororiginally.

SlowContinuousDeliveryPipeline

BigMoneyhasdecidedtouseContinuousDeliveryandhasestablishedaContinuousDeliverypipeline.ThispipelineiscomplicatedandslowasthecompleteDeploymentMonolithneedstobetestedandbroughtintoproduction.Someofthetestsrunforhours.Afasterpipelinewouldbehighlydesirable.

ParallelWorkComplicated

Thereareteamsworkingondifferentnewfeatures.However,theparallelworkiscomplicated:Thesoftwarestructurejustdoesn’treallysupportit.Theindividualmodulesarenotwellenoughseparatedandhavetoomanyinterdependencies.Aseverythingcanonlybedeployedtogether,theentireDeploymentMonolithhastobetested.Deploymentandtestingphaseconstituteabottleneck.Wheneverateamishavingareleaseinthedeploymentpipeline,whichiscreatingaproblem,allotherteamshavetowaituntiltheproblemhasbeenfixedandthechangehasbeensuccessfullydeployed.Moreover,theaccesstotheContinuousDeliverypipelinehastobecoordinated.Onlyoneteamatatimecanbedoingtestinganddeployment.Thusithastoberegulatedwhichteamcanbringwhichchangeintoproductionatwhichtime.

BottleneckDuringTesting

Inadditiontodeploymentalsothetestshavetobecoordinated.WhentheDeploymentMonolithrunsinanintegrationtest,onlythechangesmadebyoneteamareallowedtobecontainedinthetest.Therewereattemptstotestseveralchangesatonce.However,inthatcaseitwasveryhardtodiscerntheoriginoferrorssothaterroranalyseswerelongandcomplex.

Oneintegrationtestrequiresapproximatelyonehour.Thusaboutsixintegrationtestsarefeasibleperworkingdayaserrorshavetobefixedandtheenvironmenthastobesetupagainforthenexttest.Inthecaseoftenteamsoneteamcanbringonechangeintoproductioneverytwodaysonaverage.However,oftenateamalsohastodoerroranalysis,whichlengthensintegration.Forthatreasonsometeamsusefeaturebranchesinordertoseparatethemselvesfromintegration:Theyperformtheirchangesonaseparatebranchintheversioncontrolsystem.Integratingthesechangesintothemainbranchlateronoftencausesproblems:Changesareerroneouslyremovedagainuponmergingorthesoftwaresuddenlycontainserrors,whicharecausedbytheseparateddevelopmentprocessandonly

showupafterintegration.Theseerrorscanonlybeeliminatedinlengthyprocessesafterintegration.

Consequently,theteamssloweachotherdownduetothetesting.Althougheachteamdevelopsitsownmodules,theyallworkonthesamecodebasissothattheyimpedeeachother.AsaconsequenceofthesharedContinuousDeliverypipelineandtheensuingneedforcoordinationtheteamsareneitherabletoworkindependentlyofeachothernorinparallel.

Fig.2:TeamssloweachotherdownduetotheDeploymentMonoliths.

Approach

BecauseofthemanyproblemsBigMoneyOnlineCommerceinc.decidedtosplitoffsmallMicroservicesfromtheDeploymentMonolith.TheMicroserviceseachimplementonefeaturesuchastheproductsearchandaredevelopedbyindividualteams.EachteamhasthecompleteresponsibilityforanindividualMicroservicestartingfromrequirementsengineeringuptorunningtheapplicationinproduction.TheMicroservicescommunicatewiththeMonolithandotherMicroservicesviaREST.TheclientGUIisalsodividedbetweentheindividualMicroservicesbasedonusecases.EachMicroservicedeliverstheHTMLpagesforitsusecases.LinksareallowedbetweentheHTMLpagesoftheMicroservices.However,itisnotallowedtoaccessthedatabasetablesoftheotherMicroservicesortheDeploymentMonolith.IntegrationofservicesisexclusivelydoneviaRESTorvialinksbetweentheHTMLpages.

TheMicroservicescanbedeployedindependentlyofeachother.ThisallowstodeliverchangesinaMicroservicewithouttheneedtocoordinatewithotherMicroservicesorteams.Thisgreatlyfacilitatesparallelworkonfeatureswhilereducingcoordinationefforts.

TheDeploymentMonolithissubjecttofarfewerchangesduetotheadditionofMicroservices.FormanyfeatureschangestotheMonolitharenotnecessaryanymore.Thus,theDeploymentMonolithismoreseldomdeployedandchanged.Originally,itwasplannedtocompletelyreplacetheDeploymentMonolithatsomepoint.However,meanwhileitseemsmorelikelythattheDeploymentMonolithwilljustbedeployedlessandlessfrequentlyasmostchangestakeplacewithintheMicroservices.ThustheDeploymentMonolithdoesnotdisturbworkanymore.Toreplaceitentirelyisintheendnotnecessaryandalsodoesnotappearsensibleineconomictermsanymore.

Challenges

ImplementingMicroservicescreatesadditionalcomplexityinthebeginning:AlltheMicroservicesneedtheirowninfrastructure.InparalleltheMonolithhasstilltobesupported.

TheMicroservicescomprisealotmoreserversandthusposeverydifferentchallenges.Monitoringandlogfileprocessinghavetodealwiththefactthatthedataoriginatefromdifferentservers.Thusinformationhastobecentrallyconsolidated.Besidesasubstantiallylargernumberofservershastobehandled–notonlyinproduction,butalsointhedifferentteststagesandteamenvironments.Thisisonlypossiblewithgoodinfrastructureautomatization.ItisnotonlynecessarytosupportdifferenttypesofinfrastructurefortheMonolithandtheMicroservices,butalsotoprovidesubstantiallymoreserversintheend.

EntireMigrationLengthy

TheaddedcomplexityduetothetwodifferentsoftwaretypeswillpersistforalongtimeasitisaverylengthyprocesstocompletelymigrateawayfromtheMonolith.IftheMonolithisneverentirelyreplaced,theadditionalinfrastructurecostswillremainaswell.

TestingRemainsaChallenge.

Testingisanadditionalchallenge:PreviouslytheentireDeploymentMonolithwastestedinthedeploymentpipeline.ThesetestsarecomplexandtakealongtimeasallfunctionalitiesoftheDeploymentMonolithhavetobetested.IfeachchangetoeachMicroserviceissentthroughthesetests,itwilltakealongtimeforeachchangetoreachproduction.Moreover,thechangeshavetobecoordinatedaseachchangeshouldbetestedinisolationsothatitiseasilydiscernibleincaseoferrorswhichchangecausedthem.InthatscenarioaMicroservices-basedarchitecturedoesnotseemtohavemajoradvantagesoveraDeployment

Monolith:WhileMicroservicescaninprinciplebedeployedindependentlyofeachother,theteststagesprecedingdeploymentstillhavetobecoordinatedandeachchangestillhastopassthroughthemsingly.

CurrentStatusofMigration

Fig.3presentsthecurrentstatus:ProductsearchworksonanindependentMicroserviceandiscompletelyindependentoftheDeploymentMonolith.Coordinationwithotherteamsishardlynecessary.OnlyinthelaststageofthedeploymenttheDeploymentMonolithandtheMicroserviceshavetobetestedtogether.EachchangetotheMonolithoranyMicroservicehastorunthroughthisstep.Thiscausesabottleneck.Theteam“Customer”workstogetherwiththeteam“OrderProcess”ontheDeploymentMonolith.InspiteofMicroservicestheseteamsstillhavetocloselycoordinatetheirwork.Forthatreasontheteam“OrderProcess”hasimplementeditsownMicroservice,whichcomprisespartoftheorderprocess.InthispartofthesystemchangescanbeintroducedfasterthanintheDeploymentMonolith-notonlyduetotheyoungercodebasis,butalsobecauseitisnolongernecessarytocoordinatewiththeotherteams.

Fig.3:IndependentworkthroughMicroservices

CreatingTeams

Fortheteamstobeabletoworkindependentlyonfeaturesitisimportanttocreateteamsaccordingtofunctionalitiessuchasproductsearch,customerororderprocess.IfteamsareinsteadcreatedalongtechnicallayerssuchasUI,MiddleTierordatabase,eachfeaturerequirestheinvolvementofalltheteamsasafeaturenormallycompriseschangestoUI,MiddleTieranddatabase.Thustominimizecoordinationeffortsbetweentheteams,thebestapproachistocreateteamsaroundfeatureslikeproductsearch.Microservicessupporttheindependenceoftheteamsbytheirowntechnicalindependencefromeachother.Consequently,teamsneedtocoordinatelessinrespecttobasictechnologiesandtechnicaldesigns.

Thetestshavealsotobemodularized.EachtestshouldideallydealwithasingleMicroservice.InthatcaseitissufficienttoperformthetestuponchangesintherespectiveMicroservice.Inadditionitmightbepossibletoimplementthetestratherasunittestthanasintegrationtest.ThisprogressivelyshortensthetestphaseinwhichallMicroservicesandtheMonolithhavetobetestedtogether.Thisreducesthecoordinationproblemsforthefinaltestphase.

MigratingtoaMicroservices-basedarchitecturecreatedanumberofperformanceproblemsandalsosomeproblemsuponnetworkfailures.However,theseproblemscouldbesolvedaftersometime.

Advantages

Thankstothenewarchitecturechangescanbedeployedmuchfaster.Ateamcanbringachangeintoproductionwithin30minutes.TheDeploymentMonolithontheotherhandisdeployedonlyweeklyduetothenotyetfullyautomatedtests.

DeployingtheMicroservicesisnotonlymuchfaster,butalsoinotherrespectsmuchmorecomfortable:Lesscoordinationisrequired.Errorsaremoreeasilyfoundandfixedbecausedevelopersstillknowverywellwhattheyhavebeenworkingonasitwasonly30minutesago.

Insummarythegoalwasattained:ThedeveloperscanintroducemorechangestotheE-Commerceshop.ThisispossiblebecausetheteamsneedtocoordinatetheirworklessandbecausethedeploymentofaMicroservicecantakeplaceindependentlyoftheotherservices.

Thepossibilitytousedifferenttechnologieswassparinglyusedbytheteams:Thepreviouslyusedtechnologystackprovedsufficient,andtheteamswantedtoavoidtheadditionalcomplexitycausedbytheuseofdifferenttechnologies.However,thelongneededsearchenginefortheproductsearchwasintroduced.Theteamresponsibleforproductsearchwasabletoimplementthischangeonitsown.Previouslytheintroductionofthisnewtechnologyhadbeenprohibitedbecausetheassociatedriskhadbeenconsideredtoogreat.Inadditionsometeamsmeanwhilehavenewversionsofthelibrariesofthetechnologystackinproductionastheyneededthebugfixesofthemorerecentversion.Thisdidnotrequireanycoordinationwiththeotherteams.

Conclusion

ReplacingaMonolithviatheimplementationofMicroservicesisnearlyaclassicalscenariofortheintroductionofMicroservices.ItrequiresalotofefforttokeepdevelopingaMonolithandtoaddnewfeaturestoit.ThecomplexityoftheMonolithandconsequentlytheproblemscausedbyitprogressivelyincreaseovertime.Itscompletereplacementbyanewlywrittensystemisverydifficult.Thesoftwarehastobereplacedinonegowhichisveryrisky.

RapidandIndependentDevelopmentofnewFeatures

EspeciallyinthecaseofcompanieslikeBigMoneyOnlineCommerceinc.therapiddevelopmentofnewfeaturesandtheparallelworkonseveralfeaturesarevitalforeconomicsuccess.Onlybyprovidingstateoftheartfeaturescustomers

canbewonandkeptfromchangingtoothercompanies.ThepromisetodevelopmorefeaturesfasterrendersMicroserviceshighlyattractiveformanyusecases.

InfluenceontheOrganization

ThepresentedexampleillustratesalsotheinfluenceofMicroservicesontheorganization.TheteamsworkontheirownMicroservices.AstheMicroservicescanbedevelopedanddeployedindependentlyofeachother,theworkofthedifferentteamsisnolongerlinked.InordertokeepitthatwayaMicroservicemaynotbechangedbyseveralteamsinparallel.TheMicroservicesarchitecturerequiresateamorganizationcorrespondingtothedifferentMicroservices:EachteamisresponsibleforoneorseveralMicroservices,whichimplementanisolatedfunctionality.ThisrelationshipbetweenorganizationandarchitectureisespeciallyimportantinthecaseofMicroservices-basedarchitectures.Eachteamtakescareofallissuesrevolvingaround“its”Microservicesfromrequirementsengineeringuptooperationmonitoring.Ofcourse,especiallyforoperationtheteamscanusecommoninfrastructureservicesforloggingandmonitoring.

Andfinally:Ifthegoalistoachieveasimpleandfastdeploymentinproduction,justincludingMicroservicesintothearchitecturewillnotbesufficient.TheentireContinuousDeliverypipelinehastobecheckedforpotentialobstaclesandthesehavetoberemoved.Thisisillustratedbythetestsinthepresentedexample:TestingallMicroservicestogethershouldbereducedtotheessentialminimum.EachchangehastorunthroughanintegrationtesttogetherwiththeotherMicroservices,butthistestmustnotrequirealotoftimetoavoidabottleneckinintegrationtests.

AmazonHasBeenDoingItforaLongTime

ThescenariopresentedhereisverysimilartowhatAmazonhasbeendoingalreadyforaverylongtime–andforthediscussedreasons:Amazonwantstobeabletorapidlyandeasilyimplementnewfeaturesonitswebsite.In2006AmazondidnotonlypresentitsCloudplatform,butalsodiscussedhowitdevelopssoftware.Essentialfeaturesare:

Theapplicationisdividedintodifferentservices.Eachservicesprovidesapartofthewebsite.Forinstancethereisaserviceforsearchingandanotheroneforrecommendations.IntheendtheindividualservicesarepresentedtogetherintheUI.Thereisalwaysoneteamresponsibleforoneservice.Theteamtakescareofdevelopingnewfeaturesaswellasofoperatingtheservice.Theideais:

“Youbuildit–yourunit!”TheCloudplatformi.e.virtualmachinesconstitutethecommonfoundationofallservices.Apartfromthattherearenofurtherstandards.Thustheteamsareveryfreeintheirchoiceoftechnologies.

ByintroducingthistypeofarchitectureAmazonimplementedfundamentalcharacteristicsofMicroservicesalreadyin2006.MoreoverAmazonintroducedDevOpsbyhavingteamsconsistingofoperationexpertsanddevelopers.ThisapproachnecessitatesthatthedeploymentsoccurlargelyinanautomatedfashionasthemanualconstructionofserversisnotfeasibleinCloudenvironments–thusAmazonalsoimplementedatleastoneaspectofContinuousDelivery.

Conclusion:Microserviceshavebeenusedbysomecompaniesforquitesometimealready–especiallybycompanieshavinganinternet-basedbusinessmodel.Thustheapproachhasalreadyprovenitspracticaladvantagesinreallife.InadditionMicroservicesdisplaysynergyeffectswithothermodernapproachessuchasContinuousDelivery,CloudorDevOps.

3.2DevelopingaNewSignalingSystemScenario

Searchingairplanesandshipswhichhavegonemissingisacomplextask.Rapidactioncansavelives.Thereforedifferentsystemsarerequired.Someprovidesignalssuchasradioorradarsignals.Thesesignalshavetoberecordedandprocessed.Radiosignalsforexamplecanbeusedtoobtainabearing,whichsubsequentlyhastobecheckedagainstradar-basedpictures.Finallyhumanshavetofurtherevaluatetheinformation.Thedataanalysesaswellastherawdatahavetobeprovidedtothedifferentrescueteams.Signalinc.buildssystemsforexactlytheseusecases.Thesystemsareindividuallyassembled,configuredandadaptedtothespecificneedsoftherespectiveclient.

Fig.4:OverviewoftheSignalingSystem

ReasonstoUseMicroservices

Thesystemiscomposedofdifferentcomponents,whichrunondifferentcomputers.Thesensorsaredistributedallovertheareatobemonitoredandareprovidedwiththeirownservers.However,thesecomputersarenotsupposedtohandlethemoredetaileddataprocessingortostorethedata.Theirhardwareisnotsufficientlypowerfulforthat.Besidesdataprivacyconsiderationsrendersuchanapproachveryundesirableaswell.

DistributedSystem

Forthesereasonsthesystemhastobeadistributedsystem.Thedifferentfunctionalitiesaredistributedwithinthenetwork.Thesystemisunreliableasindividualcomponentsandthecommunicationbetweencomponentscanfail.

ItwouldbepossibletoimplementalargepartofthesystemwithinaDeploymentMonolith.However,uponcloserconsiderationthedifferentpartsofthesystemhavetofulfillverydifferentdemands.DataprocessingrequiresratheralotofCPUandanapproachthatallowsnumerousalgorithmstoprocessthedata.Forsuchpurposestherearesolutions,whichreadeventsoutofadataoreventstreamandprocessthem.Datastoragerequiresaverydifferentfocus:Basically,thedatahavetobemaintainedwithinadatastructure,whichissuitablefordifferentdata

analyses.ModernNoSQLdatabasesarewellsuitedforthis.Recentdataaremoreimportantthanolddata.Theyhavetobeaccessiblefasterwhileolddatacanevenbedeletedatsomepoint.Tobefinallyanalyzedbyexpertsthedatahavetobereadfromthedatabaseandprocessed.

TechnologyStackperTeam

Eachofthediscussedtasksposesdifferentchallenges.Consequently,eachrequiresnotonlyawelladaptedtechnologystackbutalsoadedicatedteamconsistingoftechnicalexpertsfortherespectivetask.InadditionpeopleareneededwhodecidewhichfeaturesSignalinc.willbringtothemarketandinlinewiththatdefinenewrequirementsforthesystems.Systemsforprocessingandsensorsareindividualproducts,whichcanbepositionedonthemarketindependentlyofeachother.

IntegrationofOtherSystems

AnadditionalreasonfortheuseofMicroservicesisthepossibilitytoeasilyintegrateothersystems.Sensorsandcomputingunitsarealsoprovidedbyothercompanies.Theabilitytointegratesuchsolutionsisafrequentrequirementinclientprojects.MicroservicesallowtheeasyintegrationofothersystemsastheintegrationofdifferentdistributedcomponentsisanyhowacorefeatureofaMicroservices-basedarchitecture.

ForthesereasonsthearchitectsofSignalinc.decidedtoindeedimplementtheirsystemasadistributedsystem.EachteammustimplementitsrespectivedomaininseveralsmallMicroservices.InthiswaytheexchangeabilityoftheMicroserviceswillbefurtherimproved,andtheintegrationofothersystemswillbeevenmorefacilitated.

Onlythecommunicationinfrastructuretobeusedbyallservicesfortheircommunicationwitheachotherispredetermined.Thecommunicationtechnologysupportsmanyprogramminglanguagesandplatformssothattherearenolimitationsastowhichconcretetechnologyisused.ToallowforaflawlesscommunicationtheinterfacesbetweentheMicroserviceshavetobeclearlydefined.

Challenges

AfailureofcommunicationbetweenthedifferentMicroservicespresentsanimportantchallenge.Thesystemhastostayuseableevenifnetworkfailuresoccur.Thisnecessitatestheuseoftechnologies,whichcanhandlesuchfailures.

However,technologiesalonewillnotsolvethisproblem.Ithastobedecidedaspartoftheuserrequirementswhatshouldhappenifasystemfails.Ifforinstanceolddataaresufficient,cachescanbehelpful.Inadditionitcanbepossibletouseasimpleralgorithm,whichdoesnotrequirecallstoothersystems.

HighTechnologicalComplexity

Thetechnologicalcomplexityoftheentiresystemisveryhigh.Differenttechnologiesareemployedtofulfillthedemandsofthedifferentcomponents.Theteamsworkingontheindividualsystemscanmakelargelyindependenttechnologydecisions.Thisallowsthemtoalwaysimplementthemostsuitablesolution.

Unfortunately,thismeansaswellthatdeveloperscannolongerchangeeasilybetweenteams.Forexamplewhentherewasalotofworkforthedatastorageteam,developersfromotherteamscouldhardlyhelpoutastheywerenotevenproficientintheprogramminglanguagesthedatastorageteamwasusinganddidnotknowthespecifictechnologiessuchastheuseddatabase.

Itcertainlyisachallengetorunasystemcomprisingsuchaplethoraoftechnologies.Forthisreasonthereisonestandardizationinthisarea:AllMicroservicesmustbeabletoberuninalargelyidenticalmanner.Theyarevirtualmachinessothattheirinstallationisfairlysimple.Furthermore,themonitoringisstandardized,whichdeterminesdataformatsandtechnologies.Thisallowsforthecentralmonitoringoftheapplications.Inadditiontothetypicaloperationalmonitoringthereisalsomonitoringofapplication-specificvaluesandfinallyananalysisoflogfiles.

Advantages

InthiscontextthemainadvantageofferedbyMicroservicesisthegoodsupportforthedistributednatureofthesystem.Thesensorsareatdifferentlocationssothatacentralizedsystemisanyhownotsensible.ThearchitecturehasadaptedtothisfactbyfurtherdividingthesystemintosmallMicroservices,whicharedistributedwithinthenetwork.ThisenhancedtheexchangeabilityoftheMicroservices.BesidestheMicroservicesapproachsupportsthetechnologydiversity,whichcharacterizesthissystem.

Inthisscenariotime-to-marketisbyfarnotasimportantasintheotherscenario.Itwouldalsobehardtoimplementasthesystemsareinstalledatdifferentclientsandcannotbeeasilyreinstalled.However,someideasfromtheContinuous

Deliveryfieldareused:Forinstancethelargelyuniforminstallationandthecentralmonitoring.

Verdict

Microservicesareaverysuitablearchitecturedesignforthepresentedscenario.ThesystemcanprofitfromthefactthattypicalproblemscanbesolvedduringimplementationbyestablishedapproachesfromtheMicroservicesfield–forexampletechnologycomplexityandplatformoperation.

Stillthisscenariowouldhardlybeimmediatelyassociatedwiththeterm“Microservice”.Thisleadstothefollowingconclusions:

Microserviceshaveawiderapplicationthanisapparentatfirstglance.Alsooutsideofweb-basedbusinessmodelsMicroservicescansolvemanyproblems–evenifthoseissuesareverydifferentfromtheonesfoundinwebcompanies.IndeedmanyprojectsfromdifferentfieldshavebeenusingMicroservice-basedapproachesforquitesometime,eveniftheydonotcallthembythisnameorimplementthemonlypartially.WiththehelpofMicroservicestheseprojectscanusetechnologies,whicharecurrentlycreatedintheMicroservicefield.Inadditiontheycanprofitfromtheexperiencesmadeinthisfield,forinstanceinregardstoarchitecture.

3.3ConclusionThischapterpresentedtwoverydifferentscenariosfromtwocompletelydistinctbusinessareas:awebsystemwithastrongfocusonrapidtime-to-marketandasystemforsignalprocessing,whichisinherentlydistributed.Thearchitectureprinciplesareverysimilarforthetwosystemsalthoughoriginatingfromdifferentreasons.

Inadditionthereareanumberofcommonapproaches,amongthosethecreationofteamsaccordingtoMicroservices,thedemandsinregardstoinfrastructureautomatizationaswellasotherorganizationaltopics.However,inotherareastherearealsodifferences.Forthesignaxslingsystemitisessentialtohavethepossibilitytousedifferenttechnologiesasthissystemanyhowhastoemployanumberofdifferenttechnologies.Forthewebsystemthisaspectisnotas

important.Here,theindependentdevelopment,thefastandeasydeploymentandfinallythebettertime-to-marketarethedecisivefactors.

EssentialPoints

Microservicesofferaplethoraofadvantages.Inthecaseofweb-basedapplicationsContinuousDeliveryandshorttime-to-marketcanconstituteanimportantmotivationfortheuseofMicroservices.However,therearealsoverydifferentusecasesforwhichMicroservicesasdistributedsystemsareextremelywellsuited.

PartII:Microservices:What,WhyandWhyNot?

ThispartofthebookdiscussesthedifferentfacettesofMicroservice-basedarchitecturestopresentthediversepossibilitiesofferedbyMicroservices.AdvantagesaswellasdisadvantagesareaddressedsothatthereadercanevaluatewhatcanbegainedbyusingMicroservicesandwhichpointsrequirespecialattentionandcareduringtheimplementationofMicroservice-basedarchitectures.

Chapter4explainstheterm“Microservice”indetail.Thetermisdissectedfromdifferentperspectives,whichisessentialforanindepthunderstandingoftheMicroserviceapproach.ImportantaspectsarethesizeofaMicroservice,Conway’sLawasorganizationalinfluenceandDomain-DrivenDesignresp.BoundedContextfromadomainperspective.Furthermore,thechapteraddressesthequestionwhetheraMicroserviceshouldcontainaUI.Chapter5focusesontheadvantagesofMicroservicestakingalternatinglyatechnical,organizationalandbusinessperspective.Chapter6dealswiththeassociatedchallengesintheareasoftechnology,architecture,infrastructureandoperation.Chapter7distinguishesMicroservicesfromSOA(Service-OrientedArchitecture).BymakingthisdistinctionMicroservicesareviewedfromanewperspectivewhichhelpstofurtherclarifytheMicroservicesapproach.BesidesMicroserviceshavebeenfrequentlycomparedtoSOAs.

AfterwardsthethirdpartofthebookwillintroducehowMicroservicescanbeimplementedinpractice.

4WhatareMicroservices?

Section1.1providedaninitialdefinitionoftheterm“Microservice”.However,therearealsodifferentpossibilitiestodefineMicroservices.ThedifferentdefinitionsillustratethedifferentcharacteristicsofMicroservicesandtherebyexplainforwhichreasonstheuseofMicroservicesisadvantageous.Attheendofthechapterthereadershouldhavehis/herowndefinitionoftheterm“Microservice”–dependingontheindividualprojectscenario.

Thechapterdiscussestheterm“Microservice”fromdifferentperspectives:

Section4.1focusesonthesizeofMicroservices.Section4.2setsMicroservices,architectureandorganizationintorelationbyusingthelawofConway.Finallysection4.3presentsafachlichedivisionofMicroservicesbasedonDomain-drivenDesign(DDD)andBoundedContext.Section4.4explainswhyMicroservicesshouldcontainaUI.

4.1SizeofaMicroserviceThename“Microservices”betraysalreadythatthesizeoftheservicematters,obviouslyMicroservicesaresupposedtobesmall.

OnepossibilitytodefinethesizeofaMicroserviceistocounttheLinesofCode(LoC).However,suchanapproachentailsanumberofproblems:

Itdependsontheprogramminglanguageused.Somelanguagesrequiremorecodethanotherstoexpressthesamecontent–andMicroservicesareexplicitlynotsupposedtopredeterminethetechnologystack.Accordingly,definingMicroservicesbasedonthismetricisnotveryuseful.FinallyMicroservicesrepresentanarchitectureapproach.Architectures,however,shouldfollowtheconditionsinthedomainratherthanadheringtotechnicalmetricssuchasLoC.Alsoforthisreasonattemptstodeterminesizebasedoncodelinesshouldbeviewedcritically.

InspiteofthevoicedcriticismLoCcanbeanindicatorforaMicroservice.Still,thequestionastotheidealsizeofaMicroserviceremains.HowmanyLoCmayaMicroservicehave?Eveniftherearenoabsolutestandardvalues,thereareneverthelessinfluencingfactors,whichargueforlargerorsmallerMicroservices.

Modularization

Onefactoristhemodularization.Teamsdevelopsoftwareinmodulestobebetterabletodealwithitscomplexity:Insteadofhavingtounderstandtheentiresoftwareadeveloperonlyneedstounderstandthemoduleheisworkingonaswellastheinterplaybetweenthedifferentmodules.Thisistheonlywayforateamtoworkproductivelyinspiteoftheenormouscomplexityofatypicalsoftwaresystem.Indailylifethereareoftenproblemsasmodulesgetlargerthanoriginallyplanned.Thismakesthemhardtounderstandandhardtomaintainaschangesrequireanunderstandingofthesoftware.ThusitisverysensibletokeepMicroservicesassmallaspossible.OntheotherhandMicroservicesincontrasttomanyotherapproachestomodularizationhaveanoverhead:

DistributedCommunication

Microservicesrunwithinindependentprocesses.ThereforecommunicationbetweenMicroservicesisdistributedcommunicationviathenetwork.Tothistypeofsystemthe“FirstRuleofDistributedObjectDesign”applies.Thisrulestatesthatsystemsshouldnotbedistributedifitcanbeavoided.Thereasonbehindthisisthatacallonanothersystemviathenetworkisordersofmagnitudeslowerthanadirectcallwithinthesameprocess.Inadditiontothepurelatencytimeserializationanddeserializationofparametersandresultsaretime-consuming.Theseprocessesdonotonlytakealongtime,butalsocostCPUcapacity.

Moreover,distributedcallsmightfailbecausethenetworkistemporarilyunavailableorthecalledservercannotbereached–forinstanceduetoacrash.Thisincreasescomplexitywhenimplementingdistributedsystemsasthecallerhastodealwiththeseerrorsinasensiblemanner.

ExperienceteachesthatMicroservice-basedarchitecturesworkinspiteoftheseproblems.WhenMicroservicesaredesignedtobeespeciallysmall,theamountofdistributedcommunicationincreasesandtheoverallsystemgetsslower.ThisarguesforlargerMicroservics.WhenaMicroservicecontainsaUIandfullyimplementsaspecificpartofthedomain,itcandowithoutcallingonotherMicroservicesinmostcasesbecauseallcomponentsofthispartofthedomainare

implementedwithinoneMicroservice.Thewishtopreventdistributedcommunicationisanotherreasontobuildsystemsaccordingtothedomain.

SustainableArchitecture

MicroservicesusedistributionalsotodesignarchitectureinasustainablemannerthroughdistributionintoindividualMicroservices:ItismuchmoredifficulttouseaMicroservicethanaclass.ThedeveloperhastodealwiththedistributiontechnologyandhastousetheMicroserviceinterface.InadditionhemighthavetomakepreparationsforteststoincludethecalledMicroserviceorreplaceitwithastub.Finally,hehastocontacttheteamresponsiblefortherespectiveMicroservice.

TouseaclasswithinaDeploymentMonolithismuchsimpler–eveniftheclassbelongstoacompletelydifferentpartoftheMonolithandfallswithintheresponsibilityofanotherteam.However,asitissosimpletoimplementadependencybetweentwoclasses,unintendeddependenciestendtoaccumulatewithinDeploymentMonoliths.InthecaseofMicroservicesdependenciesarehardertoimplement,whichpreventsthecreationofunintendeddependencies.

Refactoring

However,theboundariesbetweenMicroservicescreatealsochallenges,forinstanceduringrefactoring.WhenitbecomesapparentthatacertainfunctionalityisnotfittingwellwithinitspresentMicroservice,ithastobemovedtoanotherMicroservice.IfthetargetMicroserviceiswritteninadifferentprogramminglanguage,thistransfercorrespondsultimatelytoanewimplementation.SuchproblemsdonotarisewhenfunctionalitiesaremovedwithinaMicroservice.ThisfactorarguesalsoratherforlargerMicroservices.ThistopicisthefocusofSection8.3.

TeamSize

TheindependentdeploymentofMicroservicesandthedivisionintoteamsresultinanupperlimitforthesizeofanindividualMicroservice.AteamshouldbeabletoimplementfeatureswithinaMicroserviceindependentlyofotherteamsandtobringthemalsoindependentlyintoproduction.Inthiswaythearchitectureenablesthescalingofdevelopmentwithoutrequiringtoomuchcoordinationeffortfromtheteams.

Ateamhastobeabletoimplementfeaturesindependentlyoftheotherteams.ThereforeatfirstglanceitseemsliketheMicroserviceshouldbelargeenoughto

allowfortheimplementationofdifferentfeatures.WhenMicroservicesaresmaller,ateamcanberesponsibleforseveralMicroservices,whichtogetherallowtheimplementationofadomain.AlowerlimitfortheMicroservicesizedoesnotresultfromtheindependentdeploymentandthedivisionintoteams.

However,anupperlimitdoesresultfromit:WhenaMicroservicehasreachedasizethatpreventsitsfurtherdevelopmentbyasingleteam,itistoolarge.Forthatmatterateamshouldhaveasizethatisespeciallywellsuitedforagileprocesses,i.e.typicallythreetoninepeople.ThusaMicroserviceshouldinnocasegrowsolargethatthreetoninepeoplecannotdevelopitfurtherbythemselves.InadditiontosheersizethenumberoffeaturestobeimplementedinanindividualMicroserviceplaysanimportantrole.Wheneveralargeamountofchangesisnecessarywithinashorttime,ateamcanberapidlyoverloaded.Section13.2highlightsalternativestoallowseveralteamstoworkonthesameMicroservice.However,ingeneralaMicroserviceshouldnevergrowsolargethatseveralteamsarenecessarytoworkonit.

Infrastructure

AnotherimportantfactorinfluencingthesizeofaMicroserviceistheinfrastructure.EachMicroservicehastobeabletobedeployedindependently.ItmusthaveaContinuousDeliverypipelineandaninfrastructureforrunningtheMicroservice,whichhastobepresentnotonlyinproduction,butalsoduringthedifferentteststages.Alsodatabasesandapplicationserversmightbelongtoinfrastructure.Moreover,therehastobeabuildsystemfortheMicroservice.TheMicroservicecodehastobeversionedindependentlyofotherMicroservices.ThusaprojectwithinversioncontrolhastoexistfortheMicroservice.

DependingontheeffortthatisnecessarytoprovidetherequiredinfrastructureforaMicroservice,thesensiblesizeforaMicroservicecanvary.WhenasmallMicroservicesizeischosen,thesystemisdistributedintomanyMicroservicesthusrequiringmoreinfrastructures.InthecaseoflargerMicroservicesthesystemcontainsoverallfewerMicroservicesandconsequentlyrequiresfewerinfrastructures.

BuildanddeploymentofMicroservicesshouldanyhowbeautomated.NeverthelessitcanbelaborioustoprovideallnecessaryinfrastructurecomponentsforaMicroservice.OncesettinguptheinfrastructurefornewMicroservicesisautomated,theexpenditureforprovidinginfrastructuresforadditionalMicroservicesdecreases.Thisallowstofurtherreducethe

Microservicesize.Companies,whichhavebeenworkingwithMicroservicesforsometime,usuallysimplifythecreationofnewMicroservicesbyprovidingthenecessaryinfrastructureinanautomatedmanner.

Besidestherearetechnologies,whichallowtoreducetheinfrastructureoverheadtosuchanextentthatsubstantiallysmallerMicroservicesarepossible–inthatcase,however,withanumberoflimitations.SuchNanoservicesarediscussedinchapter15.

Replaceability

AMicroserviceshouldbeaseasytoreplaceaspossible.ReplacingaMicroservicecanbesensiblewhenitstechnologyisoutdatedortheMicroservicecodeisofsuchabadqualitythatitcannotbedevelopedanyfurther.ThereplaceabilityofMicroservicesisanadvantageascomparedtomonolithicapplications,whichhardlycanbereplacedatall.WhenaMonolithcannotbemaintainedanymore,itsdevelopmenthaseithertobecontinuedinspiteoftheassociatedhighcostsoralikewisecost-intensivemigrationhastotakeplacenevertheless.ThesmalleraMicroserviceis,theeasieritistoreplaceitbyanewimplementation.AboveacertainsizeaMicroservicecanhardlybereplacedanymorebecausereplacingitthenposesthesamechallengesasforaMonolith.ReplaceabilitythuslimitsthesizeofaMicroservice.

TransactionsandConsistency

Transactionspossesstheso-calledACIDcharacteristics:

Atomicityindicatesthatagiventransactioniseitherexecutedcompletelyornotatall.Incaseofanerrorallchangesarereversedagain.Consistencymeansthatdataareconsistentbeforeandaftertheexecutionofatransaction–validationsforinstancearenotviolated.Isolationindicatesthattheoperationsoftransactionsareseparatedfromeachother.Durabilityindicatespermanence:Changestothetransactionarestoredandarestillavailableafteracrash.

WithinaMicroservicechangestoatransactioncantakeplace.Moreover,theconsistencyofdatainaMicroservicecanbeguaranteedveryeasily.BeyondanindividualMicroservicethisgetsdifficult.Inthatcaseanoverallcoordinationisnecessary.UpontherollbackofatransactionallchangestoallMicroserviceswouldhavetobereversed.Thisislaboriousandhardtoimplementastherehas

tobeaguaranteethatthedecisionwhetherchangeshavetobereversedisdelivered.However,communicationwithinnetworksisunreliable.Untilitisdecidedwhetherachangemaytakeplace,furtherchangestothedataarebarred.Foronceadditionalchangeshavetakenplace,itmightnotbepossibleanymoretoreverseacertainchange.However,whenMicroservicesarekeptfromintroducingdatachangesforsometime,thesystemthroughputisreduced.

However,whencommunicatingviamessagingsystems,transactionsarepossible(compareSection9.4).WithsuchanapproachtransactionsarealsopossiblewithoutacloselinkbetweentheMicroservices.

Consistency

Inadditiontotransactionsdataconsistencyisimportant.Anorderforinstancehasfinallytoberecordedasrevenue.Onlythenwillrevenueandorderdatabeconsistent.Dataconsistencycanonlybeachievedthroughclosecoordination.DataconsistencycanhardlybeguaranteedacrossMicroservices.Thisdoesnotmeanthattherevenueforanorderwillnotberecordedatall.However,itwilllikelynothappenattheexactsametimepointandmaybenotevenwithinoneminuteoforderprocessingasthecommunicationoccursviathenetwork-andisconsequentlyslowandunreliable.

DatachangeswithinatransactionanddataconsistencyareonlypossiblewhenallconcerneddataispartofthesameMicroservice.ThereforetheydeterminethelowersizelimitforaMicroservice:WhentransactionsaresupposedtoencompassseveralMicroservicesanddataconsistencyisrequiredacrossseveralMicroservices,theMicroserviceshavebeendesignedtoosmall.

CompensationTransactionsAcrossMicroservices

Atleastinthecaseoftransactionsthereisanalternative:Ifadatachangehastoberolledbackintheend,compensationtransactionscanbeusedforthat.

Aclassicalexampleforadistributedtransactionisatravelbooking,whichconsistsofahotel,arentalcarandaflight.Eithereverythinghastobebookedtogetherornothingatall.WithinrealsystemsandalsowithinMicroservicesthisfunctionalityisdividedintothreeMicroservicesbecausethethreetasksareverydifferent.Inquiriesaresenttothedifferentsystemswhetherthedesiredhotelroom,thedesiredrentalcarandthedesiredflightareavailable.Ifthatisthecase,everythingisreserved.Ifnow,forinstance,thehotelroomsuddenlybecomesunavailable,thereservationfortheflightandtherentalcarhastobecancelled.

However,intherealworldtheconcernedcompanieswilllikelydemandafeeforthebookingcancellation.Duetothatthecancellationisnotonlyatechnicaleventhappeninginthebackgroundlikeatransactionrollback,butabusinessprocess.Thisismucheasiertorepresentwithacompensationtransaction.WiththisapproachtransactionsacrossseveralelementsinMicroserviceenvironmentscanalsobeimplementedwithoutthepresenceofaclosetechnicallink.Acompensationtransactionisjustanormalservicecall.TechnicalaswellasbusinessreasonscanarguefortheuseofmechanismslikecompensationtransactionsforMicroservices.

Summary

InconclusionthefollowingfactorsinfluencethesizeofaMicroservice(compareFig.5):

Theteamsizesetsanupperlimit:AMicroserviceshouldneverbethatlargethatseveralteamsarerequiredtoworkonit.Eventually,theteamsaresupposedtoworkandbringsoftwareintoproductionindependentlyofeachother.Thiscanonlybeachievedwheneachteamworksonaseparatedeploymentunit–i.e.aseparateMicroservice.However,oneteamcanworkonseveralMicroservices.ModularizationfurtherlimitsthesizeofaMicroservice:TheMicroserviceshouldpreferablybeofasizethatallowsadevelopertounderstandandfurtherdevelopit.Evensmallerisofcoursebetter.Thislimitisbelowtheteamsize:Whateveronedevelopercanstillunderstand,ateamshouldstillbeabletodevelopfurther.ReplaceabilitydeclineswiththesizeoftheMicroservice.ThereforereplaceabilitycaninfluencetheuppersizelimitforaMicroservice.Thislimitliesbelowtheonesetbymodularization:WhensomebodyisabletoreplaceaMicroservice,thispersonhasfirstofalltobeabletounderstandtheMicroservice.Alowerlimitissetbyinfrastructure:IfitistoolaborioustoprovidethenecessaryinfrastructureforaMicroservice,thenumberofMicroservicesshouldbekeptrathersmall–consequentlythesingleMicroservicesarethenratherlarger.Similarly,distributedcommunicationincreaseswiththenumberofMicroservices.AlsoforthisreasonthesizeofMicroservicesshouldnotbesettoosmall.ConsistencyofdataandtransactionscanonlybeensuredwithinaMicroservice.ThereforeMicroservicesmaynotbethatsmallthat

consistencyandtransactionscompriseseveralMicroservices.

Fig.5:FactorsInfluencingtheSizeofaMicroservice

ThesefactorsdonotonlyinfluencethesizeofMicroservices,buttheyalsoreflectacertainideaofMicroservices.AccordingtothisideathemainadvantagesofMicroservicesareindependentdeploymentandtheindependentworkofthedifferentteams,andinadditionthereplaceabilityofMicroservices.TheoptimalsizeofaMicroservicecanbededucedfromthesedesiredfeatures.

However,therearealsootherreasonsforMicroservices.WhenMicroservicesare,forinstance,introducedbecauseoftheirindependentscaling,aMicroservice

sizehastobechosenthatensuresthateachMicroserviceisaunit,whichhastoscaleindependently.

HowsmallorlargeaMicroservicecanbe,cannotbededucedsolelyfromthislineup.Thisalsodependsonthetechnology.EspeciallytheeffortnecessaryforprovidinginfrastructureforaMicroserviceandforthedistributedcommunicationdependsontheutilizedtechnology.Chapter15looksattechnologies,whichmakethedevelopmentofverysmallservicespossible–denotedasNanoservices.TheseNanoserviceshavedifferentadvantagesanddisadvantagesasMicroservices,which,forinstance,areimplementedusingtechnologiespresentedinChapter14.

Thus,thereisnoidealsize.TheactualMicroservicesizewilldependonthetechnologyandtheusecaseofanindividualMicroservice.

TryandExperiment

HowlargeistheeffortforthedeploymentofaMicroserviceinyourlanguage,platformandinfrastructure?

Isitjustasimpleprocess?Oracomplexinfrastructurecontainingapplicationserversorotherinfrastructureelements?HowcantheeffortforthedeploymentbereducedsothatsmallerMicroservicesbecomepossible?

BasedonthisinformationyoucandefinealowerlimitforthesizeofaMicroservice.Upperlimitsdependonteamsizeandmodularization–alsointhosetermsyoushouldthinkofappropriatelimits.

4.2Conway’sLawConway’sLawwascoinedbytheAmericancomputerscientistMelvinEdwardConwayandindicates:

Anyorganization,thatdesignsasystem(definedbroadly),willproduceadesignwhosestructureisacopyoftheorganization’scommunicationstructure.

Itisimportanttoknowthatthislawisnotonlymeanttoapplytosoftware,buttoanykindofdesign.Thecommunicationstructures,whichConwaymentions,donot

havetobeidenticalwiththeorganizationchart.Oftenthereareinformalcommunicationstructures,whichalsohavetobeconsideredinthiscontext.Inadditionthegeographicaldistributionofteamscaninfluencecommunication.Afterallitismuchsimplertotalktoacolleaguewhoworksinthesameroomoratleastinthesameofficethanwithoneworkinginadifferentcityoreveninadifferenttimezone.

ReasonsfortheLaw

ThereasonsbehindtheLawofConwayderivefromthefactthateachorganizationalunitdesignsaspecificpartofthearchitecture.Iftwoarchitecturepartshaveaninterface,coordinationinregardstothisinterfaceisrequired–and,consequently,acommunicationrelationshipbetweentheorganizationalunits,whichareresponsiblefortherespectivearchitectureparts.

FromtheLawofConwayitcanalsobededucedthatdesignmodularizationissensible.Viasuchadesignitisensuredthatnoteveryteammemberhastoconstantlycoordinatewitheveryotherteammember.Insteadthedevelopersworkingonthesamemodulecancloselycoordinatetheirefforts,whileteammembersworkingondifferentmodulesonlyhavetocoordinatewhentheydevelopaninterface–andeventhenonlyinregardstothespecificdesignofthisinterface.

However,thecommunicationrelationshipsextendbeyondthat.Itismucheasiertocollaboratewithateamwithinthesamebuildingthanwithateamlocatedinanothercity,anothercountryorevenwithinadifferenttimezone.Thereforearchitecturepartshavingnumerouscommunicationrelationshipsarebetterimplementedbyteams,whicharegeographicallyclosetoeachother,asitiseasierforthemtocommunicatewitheachother.IntheendtheLawofConwaydoesnotfocusontheorganizationchart,butontherealcommunicationrelationships.

Bytheway,Conwaypostulatedthatalargeorganizationhasnumerouscommunicationrelationships.Thuscommunicationbecomesmoredifficultorevenimpossibleintheend.Asaconsequencethearchitecturecanbemoreandmoreaffectedandfinallybreakdown.Intheendhavingtoomanycommunicationrelationshipsisarealriskforaproject.

TheLawasLimitation

NormallytheLawofConwayisviewedasalimitation,especiallyfromtheperspectiveofsoftwaredevelopment.Letusassumethataprojectismodularizedaccordingtotechnicalaspects(Fig.6).AlldeveloperswithUIfocusaregroupedintooneteam,thedeveloperswithbackendfocusareputintoasecondteam,anddatabankexpertsmakeupthethirdteam.Thisdistributionhastheadvantagethatallthreeteamsconsistofexpertsfortherespectivetechnology.Thismakesiteasyandtransparenttorealizethistypeoforganization.Moreover,thisdistributionappearsalsological.Teammemberscaneasilysupporteachother,andthetechnicalexchangeisalsofacilitated.

Fig.6:TechnicalProjectDistribution

AccordingtotheLawofConwayitfollowsfromsuchadistributionthatthethreeteamswillimplementthreetechnicallayers:aUI,abackendandadatabase.Thechosendistributioncorrespondstotheorganization,whichisinfactsensiblybuilt.However,ithasadecisivedisadvantage:AtypicalfeaturerequireschangestoUI,backendanddatabase.TheUIhastorenderthenewfeaturesuseablefortheclients,thebackendhastoimplementthelogic,andthedatabasehastocreate

structuresforthestorageoftherespectivedata.Thisresultsinthefollowingdisadvantages:

Thepersonwishingtohavethefeatureimplementedhastotalktoallthreeteams.Theteamshavetocoordinatetheirworkandcreatenewinterfaces.Theworkofthedifferentteamshastobecoordinatedinamannerthatensuresthattheireffortstemporallyfittogether.Thebackend,forinstance,cannotreallyworkwithoutgettinginputfromthedatabase–andtheUIcannotworkwithoutinputfromthebackend.Whentheteamsworkinsprints,thesedependenciescausetimedelays:Thedatabaseteamgeneratesinitsfirstsprintthenecessarychanges,withinthesecondsprintthebackendteamimplementsthelogic,andinthethirdsprinttheUIisdealtwith.Inthiswayittakesthreesprintstoimplementasinglefeature.

Intheendthisapproachcreatesalargeamountofdependenciesaswellasahighcommunicationandcoordinationdemand.Thusthistypeoforganizationdoesnotmakemuchsenseifthemaingoalistoimplementnewfeaturesasrapidlyaspossible.

Manyteamsfollowingthisapproachdonotrealizeitsimpactonarchitectureanddonotconsiderthisaspectfurther.Thistypeoforganizationfocusesratherontheaspectthatdeveloperswithsimilarskillsshouldbesimilarlypositionedwithintheorganization.InthiswaytheorganizationturnsintoanobstacleforadesigndrivenbythedomainlikeMicroserviceswhosedevelopmentisopposedbythedivisionofteamsintotechnicallayers.

TheLawasEnabler

However,thelawofConwaycanalsobeusedtosupportapproacheslikeMicroservices.Ifthegoalistodevelopindividualcomponentsasindependentlyofeachotheraspossible,thesystemcanbedistributedintodomaincomponents.Basedonthesedomaincomponentsteamscanbecreated.Fig.7illustratesthisprinciple:Thereareindividualteamsforproductsearch,clientsandorderprocess.Theseteamsworkontherespectivecomponents,whichcanbetechnicallydividedintoUI,backendanddatabase.Bytheway,thedomaincomponentsarenotexplicitlynamedinthefigureastheyareidenticalwiththeteamnames.Componentsandteamsaresynonymous.Thisapproachcorrespondstotheideaofso-calledcrossfunctionalteams,asproposedbymethodswith

Scrum.Theseteamsshouldencompassdifferentrolessothattheycancoveralargetaskspectrum.Onlyateamdesignedalongsuchprinciplescanbeinchargeofacomponent–fromengineeringrequirementsviaimplementationuptooperation.

Thedivisionintotechnicalartifactsandtheinterfacebetweentheartifactscanthenbesettledwithintheteams.Intheeasiestcaseadeveloperhasonlytotalktothedevelopersittingnexttohimtodoso.Betweenteamscoordinationismorecomplex.However,inter-teamcoordinationisnotrequiredveryoftensincefeaturesareideallyimplementedbyindependentteams.Moreover,thisapproachcreatesthininterfacesbetweenthecomponents.Thisavoidslaboriouscoordinationacrossteamstodefinetheinterface.

Fig.7:Projectbydomains

Eventually,thecentralpointtobederivedfromConway’sLawisthatarchitectureandorganizationarejusttwosidesofthesamecoin.Whenthisinsightiscleverlyputtouse,thesystemwillhaveaclearandusefularchitecturefortheproject.Architectureandorganizationhavethecommongoaltoensurethatteamscanworkinanunobstructedmannerandwithaslittlecoordinationeffortaspossible.

Thecleandistributionoffunctionalitiesintocomponentsalsofacilitatesmaintenance.Sinceanindividualteamisresponsibleforanindividualfunctionalityandcomponent,thisdistributionwillhavelongtermstability,andconsequentlythesystemwillremainmaintainable.

Theteamsneedrequirementstoworkupon.Thismeansthattheteamsneedcontactpersonswhichdefinetherequirements.Thisaffectstheorganizationbeyondtheprojectsastherequirementscomefromthedepartmentsoftheenterprise,andalsotheseaccordingtoConway’sLawhavetocorrespondtothe

teamstructureswithintheprojectandthedomainarchitecture.Conway’sLawcanbeexpandedbeyondsoftwaredevelopmenttothecommunicationstructuresoftheentireorganizationincludingtheusers.Toputittheotherwayround:TheteamstructurewithintheprojectandconsequentlythearchitectureofaMicroservicesystemcanfollowfromtheorganizationofthedepartmentsoftheenterprise.

TheLawandMicroservices

Thepreviousdiscussionhighlightedtherelationshipbetweenarchitectureandorganizationofaprojectonlyinageneralmanner.Itwouldbeperfectlyconceivabletoalignthearchitecturealongfunctionalitiesanddeviseteams,whicheachareinchargeforaseparatefunctionalitywithoutusingMicroservices.InthiscasetheprojectwoulddevelopaDeploymentMonolithwithinwhichallfunctionalitiesareimplemented.However,Microservicessupportthisapproach.Section3.1alreadydiscussedthatMicroservicesoffertechnicalindependence.Inconjunctionwiththedivisionbydomainstheteamsbecomeevenmoreindependentofeachotherandhaveevenlessneedtocoordinatetheirwork.Thetechnicalcoordinationaswellasthecoordinationconcerningthedomainscanbereducedtotheabsoluteminimum.Thismakesitfareasiertoworkinparallelonnumerousfeaturesandtobringthefeaturesalsoinproduction.

MicroservicesastechnicalarchitectureareespeciallywellsuitedtosupporttheapproachtodeviseaConway’sLaw-baseddistributionoffunctionalities.Infact,exactlythisaspectisanessentialcharacteristicofaMicroservices-basedarchitecture.

However,orientingthearchitectureaccordingtothecommunicationstructuresentailsthatachangetotheonealsorequiresachangeoftheother.ThisrendersarchitecturechangesbetweenMicroservicesmoredifficultandmakestheoverallprocesslessflexible.WheneveronefunctionalityismovedfromoneMicroservicetoanother,thismighthavetheconsequencethatanotherteamhastotakecareofthisfunctionalityfromthatpointon.Thistypeoforganizationalchangesrendersoftwarechangesmorecomplex.

Asanextstepthischapterwilladdresshowthedistributionbydomaincanbestbeimplemented.Domain-drivenDesign(DDD)ishelpfulforthat.

TryandExperiment

Havealookataprojectyouknow:

Whatdoestheteamstructurelooklike?Isittechnicallymotivatedorbydomain?WouldthestructurehavetobechangedtoimplementaMicroservices-basedapproach?Howwouldithavetobechanged?

Isthereasensiblewaytodistributethearchitectureontodifferentteams?Eventuallyeachteamshouldbeinchargeofindependentdomaincomponentsandbeabletoimplementfeaturesrelatingtothem.

Whicharchitecturalchangeswouldbenecessary?Howlaboriouswouldthechangesbe?

4.3Domain-DrivenDesignandBoundedContextInhisbookofthesametitleEricEvansformulatedDomain-DrivenDesign(DDD)1aspatternlanguage.Itisacollectionofconnecteddesignpatternsandsupposedtosupportsoftwaredevelopmentespeciallyincomplexdomains.Inthefollowingtextthenamesofdesignpatternsarewritteninitalics.

Domain-DrivenDesignisimportantforunderstandingMicroservicesasitsupportsthestructuringoflargersystemsaccordingtodomains.ExactlysuchamodelisnecessaryforthedivisionofasystemintoMicroservices.EachMicroserviceismeanttoconstituteadomain,whichisdesignedinsuchawaythatonlyoneMicroservicehastobechangedinordertoimplementchangesortointroducenewfeatures.Onlythenisthebenefittobederivedfromtheindependentdevelopmentindifferentteamsmaximalasseveralfeaturescanbeimplementedinparallelwithouttheneedforextendedcoordination.

UbiquitousLanguage

DDDdefinesasbasishowamodelforadomaincanbedesigned.AnessentialfoundationofDDDisUbiquitousLanguage.Thisexpressiondenotesthatthesoftwareshoulduseexactlythesametermsasthedomainexperts.Thisappliesonalllevels:inregardstocodeandvariablenamesaswellasfordatabaseschemas.Thispracticeensuresthatthesoftwarereallyencompassesandimplementsthecriticaldomainelements.LetusassumeforinstancethatthereareexpressordersinanE-commercesystem.Onepossibilitywouldbetogenerateabooleanvaluewiththename“fast”intheordertable.Thiscreatesthefollowingproblem:domainexpertshavetotranslatetheterm“expressorder”,whichtheyuseona

dailybasis,into“orderwithaspecificbooleanvalue”.Theymightnotevenknowwhatbooleanvaluesare.Thisrendersanydiscussionofthemodelmoredifficultastermshavetobeconstantlyexplainedandrelatedtoeachother.Thebetterapproachistocallthetablewithinthedatabasescheme“expressorder”.Inthatcaseitiscompletelytransparenthowthedomaintermsareimplementedinthesystem.

BuildingBlocks

TodesignadomainmodelDDDidentifiesbasicpatterns:

Entityisanobjectwithanindividualidentity.InanE-commerceapplicationthecustomerortheitemscouldbeexamplesforEntities.Entitiesaretypicallystoredindatabases.However,thisisonlythetechnicalimplementationoftheconceptEntity.AnEntitybelongsinessencetothedomainmodelingliketheotherDDDconcepts.ValueObjectsdonothavetheirownidentity.AnaddresscanbeanexampleforaValueObjectasitmakesonlysenseinthecontextofaspecificcustomerandthereforedoesnothaveanindependentidentity.Aggregatesarecompositedomainobjects.Theyfacilitatethehandlingofinvariantsandotherconditions.AnorderforinstancecanbeanAggregateoforderlines.Thiscanbeusedtoensurethatanorderfromanewcustomerdoesnotexceedacertainvalue.Thisisacondition,whichhastobefulfilledbycalculatingvaluesfromtheorderlinessothattheorderasAggregatecancontroltheseconditions.Servicescontainbusinesslogic.DDDfocusesonmodelingbusinesslogicasEntities,ValueObjectsandAggregates.However,logicaccessingseveralsuchobjectscannotbesensiblymodeledusingtheseobjects.ForthesecasesthereareServices.TheorderprocesscouldbesuchaServiceasitneedsaccesstoitemsandcustomersandrequirestheEntityorder.RepositoriesservetoaccessallEntitiesofatype.TypicallythereisapersistencytechnologylikeadatabasebehindaRepository.Factoriesaremostlyusefultogeneratecomplexdomainobjects.Thisisespeciallythecasewhenthesecontainforinstancemanyassociations.

AggregatesareofspecialimportanceinthecontextofMicroservices:WithinanAggregateconsistencycanbeenforced.BecauseofthenecessaryconsistencyparallelchangeshavetobecoordinatedinanAggregate.Otherwisetwoparallelchangesmightendangerconsistency.Forinstance,whentwoorderpositionsareincludedinparallelintoanorder,consistencycanbeendangered.Theorderhas

alreadyavalueof€900andismaximallyallowedtoreach€1000.Whentwoorderpositionsof€60eachareaddedinparallel,bothmightcalculateastillacceptabletotalvalueof€960basedontheinitialvalueof€900.Therefore,changeshavetobeserializedsothatthefinalresultof€1020canbecontrolled.Accordingly,changestoAggregateshavetobeserialized.ForthisreasonanAggregatecannotbedistributedacrosstwoMicroservices.Insuchascenarioconsistencycannotbeensured.Consequently,AggregatescannotbedividedbetweenMicroservices.

BoundedContext

BuildingBlockssuchasAggregaterepresentformanypeoplethecoreofDDD.DDDdescribesinadditionwithStrategicDesignhowdifferentdomainmodelsinteractandhowmorecomplexsystemscanbebuiltupthisway.ThisaspectofDDDisprobablyevenmoreimportantthantheBuildingBlocks.InanycaseitistheconceptofDDD,whichinfluencesMicroservices.

ThecentralelementofStrategicDesignsistheBoundedContext.Theunderlyingreasoningisthateachdomainmodelisonlysensibleincertainlimitswithinasystem.InE-commerceforinstancenumber,sizeandweightoftheordereditemsareofinterestinregardstodelivery,astheyinfluencedeliveryroutesandcosts.Foraccountingontheotherhandpricesandtaxratesarerelevant.AcomplexsystemconsistsofseveralBoundedContexts.Inthisitresemblesthewaycomplexbiologicalorganismsarebuiltoutofindividualcells,whicharelikewiseseparateentitieswiththeirowninnerlife.

Fig.8:Projectbydomains

BoundedContext:Anexample

ThecustomerfromtheE-commercesystemshallserveasexampleforaBoundedContext(Fig.8).ThedifferentBoundedContextsareOrder,DeliveryandBilling.ThecomponentOrderisresponsiblefortheorderprocess.ThecomponentDeliveryimplementsthedeliveryprocess.ThecomponentBillinggeneratesthebills.

EachoftheseBoundedContextsrequirescertaincustomerdata:

Uponorderingthecustomerissupposedtoberewardedwithpointsinabonusprogram.InthisBoundedContextthenumberofthecustomerhastobeknowntothebonusprogram.ForDeliverythedeliveryaddressandthepreferreddeliveryserviceofthecustomerarerelevant.Finally,forgeneratingthebillthebillingaddressandthetaxrateofthecustomerhavetobeknown.

InthismannereachBoundedContexthasitsownmodelofthecustomer.ThisrendersitpossibletoindependentlychangeMicroservices.Ifforinstancemoreinformationregardingthecustomerisnecessaryforgeneratingbills,onlychangestotheBoundedContextbillingarenecessary.

ItmightbesensibletostorebasicinformationconcerningthecustomerinaseparateBoundedContext.SuchfundamentaldataisprobablysensibleinmanyBoundedContexts.TothispurposetheBoundedContextscancooperate(comparebelow).

Auniversalmodelofthecustomer,however,ishardlysensible.Itwouldbeverycomplexsinceitwouldhavetocontainallinformationregardingthecustomer.Moreover,eachchangetocustomerinformation,whichisnecessaryinacertaincontext,wouldconcerntheuniversalmodel.Thiswouldrendersuchchangesverycomplicatedandwouldprobablyresultinpermanentchangestothemodel.

ToillustratethesystemsetupinthedifferentBoundedContextsaContextMapcanbeused(seesection8.2).EachoftheBoundedContextsthencanbeimplementedwithinoneorseveralMicroservices.

CollaborationbetweenBoundedContexts

HowaretheindividualBoundedContextsconnected?Therearedifferentpossibilities:

IncaseofaSharedKernelthedomainmodelssharesomecommonelements,however,inotherareastheydiffer.Customer/Suppliermeansthatasubsystemoffersadomainmodelforthecaller.Thecallerinthiscaseistheclientwhodeterminestheexactsetupofthemodel.ThisisverydifferentincaseofConformist:Thecallerusesthesamemodelasthesubsystem,andtheothermodelistherebyforceduponhim.Thisapproachisrelativelyeasy–thereisnoneedfortranslation.Oneexampleis

astandardsoftwareforacertaindomain.Thedevelopersofthissoftwarelikelyknowalotaboutthedomainsincetheyhaveseenmanydifferentusecases.Thecallercanusethismodeltoprofitfromtheknowledgefromthemodeling.TheAnti-corruptionLayertranslatesadomainmodelintoanotheronesothatbotharecompletelydecoupled.Thisallowstheintegrationoflegacysystemswithouthavingtotakeoverthedomainmodels.Oftendatamodelingisnotverymeaningfulinlegacysystems.SeparateWaysmeansthatthetwosystemsarenotintegrated,butstayindependentofeachother.InthecaseofOpenHostServicetheBoundedContextoffersspecialserviceseverybodycanuse.Inthiswayeverybodycanassembletheirownintegration.Thisisespeciallyusefulwhenanintegrationwithnumerousothersystemsisnecessaryandwhentheimplementationoftheseintegrationsistoolaborious.PublishedLanguageachievessimilarthings.ItoffersacertaindomainmodelingascommonlanguagebetweentheBoundedContexts.Sinceitiswidelyused,thislanguagecanhardlybechangedanymoreafterwards.

BoundedContextandMicroservices

EachMicroserviceismeanttomodelonedomainsothatnewfeaturesorchangeshaveonlytobeimplementedwithinoneMicroservice.SuchamodelcanbedesignedbasedonBoundedContext.

OneteamcanworkononeorseveralBoundedContexts,whicheachserveasfoundationforoneorseveralMicroservices.ChangesandnewfeaturesaresupposedtoconcerntypicallyonlyoneBoundedContext–andthusonlyoneteam.Thisensuresthatteamscanworklargelyindependentlyofeachother.ABoundedContextcanbedividedintomultipleMicroservicesifthatseemssensible.Therecanbetechnicalreasonsforthat.ForexampleacertainpartofaBoundedContextmighthavetobescaleduptoalargerextentthantheothers.ThisissimplerifthispartisseparatedintoitsownMicroservice.However,itshouldbeavoidedtodesignMicroservices,whichcontainmultipleBoundedContexts,asthisentailsthatseveralnewfeaturesmighthavetobeimplementedinoneMicroservice.Thisinterfereswiththegoaltodevelopfeaturesindependently.

Nevertheless,itispossiblethataspecialrequirementcomprisesmanyBoundedContexts–inthatcaseadditionalcoordinationandcommunicationwillberequired.

Thecoordinationbetweenteamscanberegulatedviadifferentcollaborationpossibilities.Theseinfluencetheindependenceoftheteamsaswell:SeparateWays,Anti-corruptionLayerorOpenHostServiceofferalotofindependence.ConformistorCustomer/Supplierontheotherhandtiethedomainmodelsverycloselytogether.ForCustomer/Suppliertheteamshavetocloselycoordinatetheirefforts:Thesupplierneedstounderstandtherequirementsofthecustomer.ForConformist,however,theteamsdonotneedtocoordinate:Oneteamdefinesthemodelthattheotherteamjustusesunchanged.(compareFig.9).

Fig.9:Communicationeffortofdifferentcollaborations

LikeinthecaseofConway’sLawfromsection4.2itbecomesveryapparentthatorganizationandarchitectureareverycloselylinked.Whenthearchitectureenablesadistributionofthedomainsinwhichtheimplementationofnewfeatures

onlyrequireschangestoadefinedarchitecturepart,thesepartscanbedistributedtodifferentteamsinsuchawaythattheseteamscanworklargelyindependentlyofeachother.DDDandespeciallyBoundedContextdemonstratewhatsuchadistributioncanlooklike-andhowthepartscanworktogetherandhowtheyhavetocoordinate.

Large-ScaleStructure

WithLarge-ScaleStructureDDDalsoaddressesthequestionhowthesysteminitsentiretycanbeviewedfromthedifferentBoundedContextsrespectivelyMicroservices.

ASystemMetaphorcanservetodefinethefundamentalstructureoftheentiresystem.Forexample,anE-commercesystemcanorientitselfaccordingtotheshoppingprocess:Thecustomerstartsoutlookingforproducts,thenhe/shewillcompareitems,selectoneitemandorderit.ThiscangiverisetothreeMicroservices:search,comparisonandorder.ResponsibilityLayerdividesthesystemintolayerswithdifferentresponsibilities.Layerscanonlycallotherlayersifthosearelocatedbelowthem.Thisdoesnotrefertoatechnicaldivisionintodatabase,UIandlogic.InanE-commercesystemdomainlayersmightbeforexamplethecatalog,theorderprocessandbilling.Thecatalogcancallontheorderprocessandtheorderprocesscancallonthegenerationofthebill.However,callsintotheotherdirectionarenotpermitted.EvolvingOrdersuggestsnottodeterminetheoverallstructuretoorigidly.Itshouldarisefromtheindividualcomponentsinastepwisemanner.

Theseapproachescanprovideanideahowthearchitectureofasystem,whichconsistsofdifferentMicroservices,canbeorganized(comparealsoChapter8).

TryandExperiment

Lookataprojectyouknow:

WhichBoundedContextscanyouidentify?GenerateanoverviewoftheBoundedContextsinaContextMap.Comparesection8.2.HowdotheBoundedContextscooperate?(Anti-corruptionLayer,Customer/Supplieretc.).AddthisinformationtotheContextMap.Wouldothermechanismshavebeenbetteratcertainplaces?Why?HowcouldtheBoundedContextsbesensiblydistributedtoteamssothatfeaturesareimplementedbyindependentteams?

Thesequestionsmightbehardtoanswerasyouneedtogetanewperspectiveonthesystemandhowthedomainsaremodeledinthesystem.

WhyYouShouldAvoidaCanonicalDataModel(StefanTilkov)byStefanTilkov,innoQ

Inrecenttimes,I’vebeeninvolvedinafewarchitectureprojectsontheenterpriselevelagain.Ifyou’veneverbeeninthatworld,i.e.ifyou’vebeenfocusingonindividualsystemssofar,letmegiveyouthebasicgistofwhatthiskindofenvironmentislike:Therearelotsofmeetings,moremeetings,andevenmoremeetings;there’sanabundanceofslidedecks,packedwithtextanddiagrams–noneofthatPresentationZennonsense,please.Thereareconceptualarchitectureframeworks,showingdifferentperspectives,thereareguidelinesandreferencearchitectures,enterprise-widelayeringapproaches,alittlebitofSOAundEAIandESBandPortalsand(lately)APItalkthrowninforgoodmeasure.Vendorsandsystemintegratorsand(ofcourse)consultantsallseetheirchancetoexertinfluenceonstrategicdecisions,makingtheirproductsorthemselvesanintegralpartofthecompany’sfuturestrategy.Itcanbeaveryfrustrating,but(atleastsometimes)alsoveryrewardingexperience:Thosewheelsareverybigandreallyhardtoturn,butifyoumanagetoturnthem,theeffectissignificant.

It’salsoamazingtoseehowmanyofthethingsthatcauseproblemswhenbuildinglargesystemsarerepeatedontheenterpriselevel.(Wedon’toftenmakemistakes…butifwedo,wemakethembig!)Myfavoriteoneistheideaofestablishingcanonicaldatamodel(CDM)forallofyourinterfaces.

Ifyouhaven’theardofthisideabefore,aquicksummaryis:Whateverkindoftechnologyyou’reusing(anESB,aBPMplatform,orjustsomeassemblyofservicesofsomekind),youstandardizethedatamodelsofthebusinessobjectsyouexchange.Initsextreme(andverycommon)form,youendupwithhavingjustonekindofPerson,Customer,Order,Product,etc.,withasetofIDs,attributes,andassociationseveryonecanagreeon.Itisn’thardtounderstandhowthatmightseemaverycompellingthingtoattempt:Afterall,evenanon-technicalmanagerwillunderstandthattheconversionfromonedatamodeltoanotherwheneversystemsneedtotalktoeachotherisacompletewasteoftime.It’sobviouslyagoodideatostandardize.Then,anyonewhohappenstohaveamodelthatdiffersfromthecanonicalonewillhavetoimplementaconversiontoaandfromitjustonce,newsystemscanjustusetheCDMdirectly,andeveryonewillbeabletocommunicatewithoutfurtherado!

Infact,it’sahorrible,horribleidea.Don’tdoit.

InhisbookonDomain-drivenDesign,EricEvansgaveanametoaconceptthatisobvioustoanyonewhohasactuallysuccessfullybuiltalargersystem:TheBoundedContext.Thisisastructuringmechanismthatavoidshavingasinglehugemodelforallofyourapplication,simplybecausethat(a)becomesunmanageableand(b)makesnosensetobeginwith.ItrecognizesthataPersonoraContractaredifferentthingsindifferentcontextsonaconceptuallevel.Thisisnotanimplementationproblem–it’sreality.

Ifthisistrueforalargesystem–andtrustme,itis–it’sinfinitelymoretrueforanenterprise-widearchitecture.OfcourseyoucanarguethatwithaCDM,you’reonlystandardizingtheinterfacelayer,butthatdoesn’tchangeathing:You’restilltryingtomakeeveryoneagreewhataconceptmeans,andmypointisthatyoushouldrecognizethatnoteverysinglesystemhasthesameneeds.

Butisn’tthisalljustpuretheory?Whocaresaboutthis,anyway?Theamazingthingisthatorganizationsareexcellentingeneratingahugeamountofworkbasedonbadassumptions.TheCDM(intheformI’vedescribedithere)requirescoordinationbetweenallthepartiesthatuseaparticularobjectintheirinterfaces(unlessyoutrustthatsomeonewillbeabletojustdesigntherightthingfromscratchontheirown,whichyoushouldneverdo).You’llhavemeetingswithsomeenterprisearchitectandafewrepresentativesforspecificsystems,tryingtoagreewhatacustomeris.You’llendupwithsomethingthathastonsofoptionalattributesbecauseeveryoneinsistedtheirsneedtobethere,andwithlotsofthings

thatarekindofweirdbecausetheyreflectsomesystem’sinternalrestrictions.Despitethefactthatit’lltakeyouagestoagreeonit,you’llendupwithazombieinterfacemodelwillbeuniversallyhatedbyeveryonewhohastoworkwithit.

SoisaCDMauniversallybadidea?Yes,unlessyouapproachitdifferently.Inmanycases,IdoubtaCDM’svalueinthefirstplace,andthinkyouarebetteroffwithadifferentandlessintrusivekindofspecification.ButifyouwantaCDM,hereareanumberofthingsyoucandotoaddresstheproblemsyou’llruninto:

Allowforindependentpartstobespecifiedindependently.Ifonlyonesystemisresponsibleforaparticularpartofyourdatamodel,leaveittothepeopletospecifywhatitlookslikecanonically.Don’tmakethemparticipateinmeetings.Ifyou’reunsurewhetherthedatamodeltheycreatehasasignificantoverlapwithanothergroup’s,itprobablyhasn’t.Standardizeonformatsandpossiblyfragmentsofdatamodels.Don’ttrytocomeupwithaconsistentmodeloftheworld.Instead,createsmallbuildingsblocks.WhatI’mthinkingofaree.g.smallXMLorJSONfragments,akintomicroformats,thatstandardizesmallgroupsofattributes(Iwouldn’tcallthembusinessobjects).Mostimportantly,don’tpushyourmodelfromacentralteamdownwardsoroutwardstotheindividualteams.Instead,itshouldbetheteamswhodecideto“pull”themintotheirowncontextwhentheybelievetheyprovidevalue.It’snotyouwho’sdoingthereallyimportantstuff(eventhoughthat’sacommondelusionthat’sattachedtothemightyEnterpriseArchitecttitle).Collectthedatamodelstheindividualteamsprovideinacentrallocation,ifyoumust,andmakethemeasilybrowsableandsearchable.(ThinkofprovidingabigelasticsearchindexasopposedtoacentralUMLmodel).

Whatyouactuallyneedtoasanenterprisearchitectistogetoutofpeople’sway.Inmanycases,acrucialingredienttoachievethisistocreateaslittlecentralizationaspossible.Itshouldn’tbeyourgoaltomakeeveryonedothesamething.Itshouldbeyourgoaltoestablishaminimalsetofrulesthatallowspeopletoworkasindependentlyaspossible.ACDMofthekindI’vedescribedaboveistheexactopposite.

4.4MicroserviceswithUI?ThisbookrecommendstoequipMicroserviceswithaUI.TheUIshouldofferthefunctionalityoftheMicroservicetotheuser.Inthiswayallchangesinregardsto

onefunctionalitycanbeimplementedinoneMicroservice–regardlessofwhethertheyconcerntheUI,thelogicorthedatabase.However,MicroserviceexpertssofarhavedifferentopinionsinregardstothequestionwhethertheintegrationofUIintoMicroservicesisreallyrequired.Ultimately,Microservicesshouldnotbetoolarge.Andwhenlogicisanyhowsupposedtobeusedbymultiplefrontends,aMicroserviceconsistingofpurelogicwithoutUImightbesensible.Inaddition,itispossibletoimplementthelogicandtheUIintwodifferentMicroservices,buttohavethemimplementedbyoneteam.Thisallowstoimplementfeatureswithoutcoordinationacrossteams.

FocusingonMicroserviceswithUIputsthemainemphasisonthedistributionofthedomainlogicinsteadofadistributionbytechnicalaspects.Manyarchitectsarenotfamiliarwiththedomainarchitecture,whichisespeciallyimportantforMicroservices-basedarchitectures.Therefore,adesignwheretheMicroservicescontaintheUIishelpfulasafirstapproachinordertofocusthearchitectureonthedomains.

TechnicalAlternatives

TechnicallytheUIcanbeimplementedasWebUI.WhentheMicroserviceshaveaRESTful-HTTPinterface,theWeb-UIandtheRESTful-HTTPinterfaceareverysimilar–bothuseHTTPasprotocol.TheRESTful-HTTPinterfacedeliversJSONorXML,theWebUIHTML.IftheUIisaSingle-Page-App,theJavaScriptcodeislikewisedeliveredviaHTTPandcommunicateswiththelogicviaRESTfulHTTP.Incaseofmobileclientsthetechnicalimplementationismorecomplicated.Section9.1explainsthisindetail.TechnicallyadeployableartifactcandeliverviaanHTTPinterfaceJSON/XMLandHTML.InthiswayitimplementstheUIandallowsotherMicroservicestoaccessthelogic.

Self-ContainedSystem

Insteadofcallingthisapproach“MicroservicewithUI”youcanalsocallit“Self-ContainedSystem”(SCS).SCSdefineMicroservicesashavingabout100linesofcode,ofwhichtheremightbemorethanonehundredinacompleteproject.

AnSCSconsistsofmanyofthoseMicroservicesandcontainsaUI.ItshouldcommunicatewithotherSCSasynchronouslyifatall.IdeallyeachfunctionalityshouldbeimplementedinjustoneSCSandthereshouldbenoneedforSCSstocommunicatewitheachother.AnalternativeapproachmightbetointegratetheSCSsattheUI-level.

Inanentiresystemtherearethenonlyfiveto25oftheseSCS.AnSCSissomethingoneteamcaneasilydealwith.InternallytheSCScanbedividedintomultipleMicroservices.

Thefollowingdefinitionsresultfromthisreasoning:

SCS(Self-ContainedSystem)issomethingateamworksonandwhichrepresentsaunitinthedomainarchitecture.Thiscanbeanorderprocessoranregistration.Itimplementsasensiblefunctionality,andtheteamcansupplementtheSCSwithnewfeatures.AnalternativenameforaSCSisavertical.TheSCSdistributesthearchitecturebydomain.Thisisaverticaldesignincontrasttoahorizontaldesign.Ahorizontaldesignwoulddividethesystemintolayers,whicharetechnicallymotivated–forinstanceUI,logicorpersistence.AMicroserviceisapartofaSCS.Itisatechnicalunitandcanbeindependentlydeployed.ThisconformsnearlywiththeMicroservicedefinitionputforwardinthisbook.OnlythesizegivenintheSCSworldrathercorrespondtowhatthisbookdenotesasNanoservicesseechapter15.ThisbookreferstoNanoservicesasunits,whicharestillindividuallydeployable,butwhichmaketechnicaltrade-offsinsomeareastofurtherreducethesizeofthedeploymentunits.Forthatreason,NanoservicesdonotsharealltechnicalcharacteristicsofMicroservices.

SCSinspiredthedefinitionofMicroservicesasputforwardinthisbook.StillthereisnoreasonnottoseparatetheUIintoadifferentartifactincasetheMicroservicegetsotherwisetoolarge.Ofcourse,itismoreimportantthattheMicroserviceissmallandthusmaintainablethantointegratetheUI.ButUIandlogicshouldatleastbeimplementedbythesameteam.

4.5ConclusionMicroservicesareamodularizationapproach.ForadeeperunderstandingofMicroservicesthedifferentperspectivesdiscussedinthischapterareveryhelpful:

Section4.1focusedonthesizeofMicroservices.ButacloserlookrevealedthatthesizeofMicroservicesitselfisnotthatimportant,eventhoughthereareinfluencingfactors.However,thisperspectiveprovidedafirstimpressiononwhataMicroserviceshouldbe.Teamsize,modularizationandreplaceabilityofMicroserviceseachdetermineanuppersizelimit.The

lowerlimitisdeterminedbytransactions,consistency,infrastructureanddistributedcommunication.Conway’sLaw(section4.2)showsthatarchitectureandorganizationofaprojectarecloselylinked–theyarenearlysynonymous.Microservicescanfurtherimprovetheindependenceofteamsandthusideallysupportarchitecturaldesigns,whichaimattheindependentdevelopmentoffunctionalities.EachteamisresponsibleforaMicroserviceandthereforeforacertainpartofadomainsothattheteamsarelargelyindependentconcerningtheimplementationofnewfunctionalities.Thus,inregardstodomainlogicthereishardlyanyneedforcoordinationacrossteams.Therequirementfortechnicalcoordinationcanlikewisebereducedtoaminimumduetothepossibletechnicalindependence.Insection4.3Domain-drivenDesignprovidesaverygoodimpressionastowhatthedistributionofdomainsinaprojectcanlooklikeandhowtheindividualpartscanbecoordinated.EachMicroservicecanrepresentaBoundedContext.Thisisaself-containedpieceofdomainlogicwithanindependentdomainmodel.BetweentheBoundedContextstherearedifferentpossibilitiesforcollaboration.Finallysection4.4demonstratedthatMicroservicesshouldcontainaUItobeabletoimplementthechangesforafunctionalityreallywithinanindividualMicroservice.Thisdoesnotnecessarilyhavetobeadeploymentunit,however,UIandMicroserviceshouldbeintheresponsibilityofoneteam.

TogetherthesedifferentperspectivesprovideabalancedpictureofwhatconstitutesMicroservicesandhowtheycanfunction.

EssentialPoints

Toputitdifferently:Asuccessfulprojectrequiresthreecomponents:

1. Anorganization:ThisissupportedbyConway’sLaw.2. Atechnicalapproach:ThiscanbeMicroservices.3. AdomaindesignasofferedbyDDDandBoundedContext.

Thedomaindesignisespeciallyimportantforthelong-termmaintainabilityofthesystem.

TryandExperiment

LookatthethreeapproachesfordefiningMicroservices:size,Conway’sLawandDomain-drivenDesign.

Section1.2showedthemostimportantadvantagesofMicroservices.WhichofthegoalstobeachievedbyMicroservicesarebestsupportedbythethreedefinitions?DDDandConway’sLawleadforinstancetoabettertime-to-market.

Whichofthethreeaspectsisinyouropinionthemostimportant?Why?

1. EricEvans:Domain-DrivenDesign:TacklingComplexityintheHeartofSoftware,Addison-Wesley,2003,ISBN978-0-32112-521-7↩

5ReasonsforMicroservices

Microservicesoffermanyadvantages.Thesearepresentedinthischapter.AdetailedunderstandingoftheadvantagesallowsabetterevaluationwhetherMicroservicesrepresentasensibleapproachinagivenusecase.Thechaptercontinuesthediscussionofsection1.2andexplainstheadvantagesinmoredetail.

Section5.1depictsthetechnicaladvantagesofMicroservices.However,Microservicesalsoinfluencetheorganization,asdescribedinsection5.2.Finally,section5.3addressestheadvantagesfromabusinessperspective.

5.1TechnicalBenefitsMicroservicesareaneffectivemodularizationconcept.OnlywithdistributedcommunicationitispossibletocallanotherMicroservice.Thisdoesnothappenbyaccident,butadeveloperhastocreatetherespectivepossibilitiesforitwithinthecommunicationinfrastructure.Consequently,dependenciesbetweenMicroservicesdonotjustcreepinunintendedly,butadeveloperhastogeneratethemexplicitly.WithoutMicroservicesiteasilyhappensthatadeveloperjustusessomeclassandtherebycreatesadependency,whichhadnotbeenarchitecturallyintended.

LetusassumeforinstancethatinanE-commerceapplicationtheproductsearchshouldbeabletocalltheorderprocess,butnottheotherwayround.Thisensuresthattheproductsearchcanbechangedwithoutinfluencingtheorderprocess,astheproductsearchdoesnotusetheorderprocess.Nowadependencyoftheproductsearchtotheorderprocessisintroduced,forinstance,becauseadeveloperfoundfunctionalitiesthere,whichwereusefulforhim.Consequently,productsearchandorderprocessnowdependoneachotherandcanonlybechangedtogether.

Onceundesireddependencieshavestartedtocreepintothesystem,additionaldependenciesrapidlyaccrue.Theapplicationarchitectureerodes.Thisdevelopmentcannormallyonlybepreventedbyarchitecturemanagementtools.Suchtoolshaveamodelofthedesiredarchitectureanddiscoverwhenadeveloperhasintroducedanundesireddependency.Thedeveloperthencan

immediatelyremovethedependencyagainbeforeharmisdoneandthearchitecturesuffers.Appropriatetoolsarepresentedinsection8.2.

InaMicroservices-basedarchitectureproductsearchandorderprocesswouldbeseparateMicroservices.Tocreateadependencythedeveloperwouldhavetoimplementitwithinthecommunicationmechanisms.Thisislaboriousandthusnormallydoesnothappenunnoticed,evenwithoutarchitecturemanagementtools.ThustheprobabilityislowerthatthearchitectureerodesonthelevelofdependenciesbetweenMicroservices.TheMicroserviceboundariesactlikefirewalls,whichpreventanarchitectureerosion.Microservicesofferastrongmodularizationasitisdifficulttooversteptheboundariesbetweenmodules.

ReplacingMicroservices

Workingwitholdsoftwaresystemsposesabigchallenge:Afurtherdevelopmentofthesoftwareisdifficultduetobadcodequality.Toreplacethesoftwareisrisky.Oftenitisunclearhowexactlythesoftwareisworking,andthesystemisverylarge.Thelargerthesoftwaresystemthemorelaboriousisitsreplacement.Whenthesoftwareisinadditionsupportingimportantbusinessprocesses,itisnearlyimpossibletochangeit.Thefailureofsuchbusinessprocessescanhavetremendousconsequences,andeachsoftwarechangeentailsthedangerofsuchafailure.

Althoughthisisacentralproblem,asoftwarearchitectureisneverreallyaimedatreplacingasoftware.However,Microservicessupportthisgoal:Theycanbereplacedindividuallysincetheyareseparateandsmalldeploymentunits.Therefore,thetechnicalprerequisitesforareplacementarebetter.Eventuallyitisnotnecessarytoreplacealargesoftwaresystem,butonlyasmallMicroservice.Whenevernecessary,additionalMicroservicescanbereplaced.

IncaseofthenewMicroservicesthedevelopersarenottiedtotheoldtechnologystack,butfreetouseothertechnologiesatwill.WhentheMicroserviceadditionallyisindependentinadomainsense,thelogiciseasiertounderstand.Thedeveloperdoesnotneedtounderstandtheentiresystem,butjustthefunctionalitiesofanindividualMicroservice.KnowledgeregardingthedomainisaprerequisiteforthesuccessfulreplacementofaMicroservice.

Moreover,MicroserviceskeepfunctioningwhenanotherMicroservicefails.EvenifthereplacementofaMicroserviceleadstothetemporaryfailureofone

Microservice,thesystemassuchcankeepoperating.Thisadditionallydecreasestheriskassociatedwithareplacement.

SustainableSoftwareDevelopment

Thestartinanewsoftwareprojectissimple:Thereisnotmuchcodeyet,thecodestructureisclean,andthedevelopersmakefastprogress.Duetoarchitectureerosionandanincreasingcomplexitydevelopmentcangetmoredifficultovertime.Atsomepoint,thesoftwareturnsintoalegacysystem.Asalreadydiscussed,Microservicespreventarchitectureerosion.WhenaMicroservicehasturnedintoalegacysystem,itcanbereplaced.ForthesetworeasonsMicroservicesmakeasustainablesoftwaredevelopmentpossible.Thismeansthatahighproductivitycanbereachedalsoonthelong-term.However,alsoinaMicroservice-basedsystemitcanhappenthatalotofcodehastobenewlywritten.Thiswillofcoursedecreaseproductivity.

HandlingLegacy

ReplacingMicroservicesisonlypossibleifthesystemisalreadyimplementedinaMicroservice-basedmanner.However,alsothereplacementandamendingofexistinglegacyapplicationsiseasierwithMicroservices.Thelegacyapplicationsonlyhavetoprovideaninterface,whichenablestheMicroservicetocommunicatewiththelegacyapplication.Comprehensivecodechangesortheintegrationofnewcodecomponentsintothelegacysystemarenotnecessary.Thecodelevelintegrationisabigchallengeinthecaseoflegacysystems,whichcanbeavoidedinthismanner.AmendingthesystemisespeciallyeasywhenaMicroservicecanintercepttheprocessingofallcallsandprocessthemitself.SuchcallscanbeHTTPrequestsforthebuilt-upofwebsitesorRESTcalls.

Intheseinstances,theMicroservicecancomplementthelegacysystem.Therearedifferentpossibilitiesforthis:

TheMicroservicecanprocesscertainrequestsbyitselfwhileleavingtheotherstothelegacysystem.Alternatively,theMicroservicecanchangetherequestsandafterwardstransferthemtotheactualapplication.

ThisapproachissimilartotheSOAapproach(compareChapter7),whichdealswiththecomprehensiveintegrationofdifferentapplications.Whentheapplicationsaredistributedintoservices,theseservicescannotonlybe

orchestratedanew,likewiseitispossibletoreplaceindividualservicesforinstancebyMicroservices.

AnExampleforMicroservicesandLegacyInaprojectthegoalwastoundertakeamodernizationinanexistingJava-E-commerceapplication.Forthispurpose,newtechnologies,forexamplenewframeworks,weretobeintroducedtoenhancefuturesoftwaredevelopmentproductivity.Aftersometime,itturnedoutthattheeffortfortheintegrationofthenewandoldtechnologieswouldbetremendous.Thenewcodehadtobeabletocalltheoldone–andviceversa.Thisrequirestechnologyintegrationinbothdirections.Transactionsanddatabaseconnectionshavetobeusedjointly.Likewise,thesecuritymechanismshavetobeintegrated.Thisintegrationwouldalsorenderthedevelopmentofthenewsoftwaremorecomplicatedandthusendangerthegoaloftheundertaking.

Fig.10showsthesolution:Thenewsystemwasdevelopedcompletelyindependentoftheoldsystem.Theonlyintegrationwasprovidedbylinks,whichcallcertainbehaviorsintheoldsoftware–forinstancetheadditionofitemstotheshoppingcart.Thenewsystemalsohadaccesstothesamedatabaseliketheoldsystem.Inhindsight,ashareddatabaseisnotagoodideaasthedatabaseisaninternalrepresentationofthedataoftheoldsystem.Whenthisrepresentationisplacedatthedisposalofanotherapplication,theprincipleofencapsulationisviolated(comparesection10.1).Thedatastructurescanhardlybechangedanymoreasnowinadditiontotheoldsystemalsothenewsystemdependsonthem.

Theapproachtodevelopthesystemseparatelysolvedtheintegration-relatedproblemstoalargeextent.Firstofall,developerstherebycouldusenewtechnologicalapproacheswithouthavingtoconsidertheoldcodeandtheoldapproaches.Thisenabledmuchmoreelegantsolutions.

Fig.10:Exampleforlegacyintegration

ContinuousDelivery

ContinuousDeliverybringssoftwareregularlyintoproductionthankstoasimple,reproducibleprocess.ThisisachievedbyaContinuousDeliverypipeline(compareFig.11):

Inthecommitphasethesoftwareiscompiled,theunittestsarerun,andstaticcodeanalysismightbeperformed.Theautomatedacceptancetestsofthenextphaseensurethatthesoftwareiscorrectconcerningthebusinessrequirementssothatitwouldbeacceptedbythecustomer.Capacitytestscheckwhetherthesoftwareissufficientlyperformanttosupporttheexpectednumberofusers.Thesetestsareautomatedaswell.Explorativetestsontheotherhandareperformedmanuallyandservetotestcertainareasofthesystemsuchasnewfeaturesorcertainaspectslikesoftwaresecurity.

Finally,thesoftwareisbroughtintoproduction.Thisprocessisideallyalsoautomated.

Softwareispromotedthroughtheindividualphases:Ittraversestheindividualphasesconsecutively.Forexample,areleasecansuccessfullypasstheacceptancetests.However,thecapacitancetestsrevealthatthesoftwaredoesnotmeettherequirementregardingtheexpectedload.Inthiscasethesoftwareisnevergoingtobepromotedtotheremainingphasessuchasexplorativetestsorevenproduction.

Fig.11:ContinuousDeliverypipeline

AContinuousDeliverypipelinewithafullautomationistheoptimum.However,somehowallsoftwaregetsintoproduction.Accordingly,thecurrentprocesscanbeoptimizedinastepwisemanner.

ContinuousDeliveryisespeciallyeasytorealizewithMicroservices.Microservicesareindependentdeploymentunits.Consequently,theycanbebroughtintoproductionindependentlyofotherservices.ThishastremendouseffectsontotheContinuousDeliverypipeline:

ThepipelineisfasterasonlyasmallMicroservicehastobetestedandbroughtintoproductionatonetime.Thisacceleratesfeedback.RapidfeedbackisanessentialgoalofContinuousDelivery.Whenittakesweeksforadevelopertogettoknowthathis/hercodehascausedaprobleminproduction,itwillbedifficulttobecomeacquaintedwiththecodeagainandtoanalyzetheproblem.Theriskofdeploymentdecreases.Thedeployedunitsaresmaller,besidesMicroservice-basedsystemscanevenstillbeusedifanumberofMicroservicesfail.Andthedeploymentcanmoreeasilyberolledback.Measurestofurtherdecreasetheriskarealsoeasiertoimplementwithsmallerdeploymentunits.IncaseofBlue/GreenDeploymentforinstanceanewenvironmentisbuiltupwiththenewrelease.ThisissimilarforCanaryReleasing:Inthecaseofthisapproachatfirstonlyoneserverisprovidedwiththenewsoftwareversion.Onlywhenthisserverrunssuccessfullyinproduction,thenewversionisrolledouttotheotherservers.ForaDeploymentMonoliththisapproachcanbehardornearlyimpossibletoimplementasitrequiresalotofresourcesforthelargenumberof

environments.IncaseofMicroservicestherequiredenvironmentsaremuchsmallerandtheprocedurethuseasier.Testenvironmentsposeadditionalchallenges.Whenforinstanceathirdpartysystemisused,theenvironmenthastocontainalsoatestversionofthisthirdsystem.Incaseofsmallerdeploymentunits,thedemandstotheenvironmentsarelower.TheenvironmentsforMicroservicesonlyhavetointegratethethirdsystems,whicharenecessaryfortheindividualMicroservice.Itislikewisepossibletotestthesystemsusingmocksofthethirdsystems.ThisfacilitatesthetestsandrepresentsalsoaninterestingmethodinordertotestMicroservicesindependentlyofeachother.

ContinuousDeliveryisoneofthemostimportantargumentsforMicroservices.ManyprojectsinvestinmigratingtoMicroservicesinordertofacilitatethecreationofaContinuousDeliverypipeline.

However,ContinuousDeliveryisalsoaprerequisiteforMicroservices.WithoutContinuousDeliverypipelinesthemanyMicroservicescanhardlybebroughtintoproductionsinceitisnotfeasibletobringsomanyMicroservicesintoproductionmanually.ThusMicroservicesprofitfromContinuousDeliveryandviceversa.

Scaling

Microservicesofferviathenetworkreachableinterfaces,whichcanbeaccessedforinstanceviaHTTPorviaamessagesolution.EachMicroservicecanrunononeserver–oronseveral.Whentheservicerunsonseveralservers,theloadcanbedistributedontothedifferentservers.Likewise,itispossibletoinstallandrunMicroservicesoncomputershavingdifferentperformance.EachMicroservicecanimplementitsownscaling.

Inaddition,cachescanbeplacedinfrontofMicroservices.ForREST-basedMicroservicesitcanbesufficienttouseagenericHTTPcache.Thisreducestheeffortforsuchacachesignificantly.TheHTTPprotocolcontainsacomprehensivesupportforcaching,whichisveryhelpfulinthiscontext.

Furthermore,itmightbepossibletoinstalltheMicroservicesatdifferentlocationswithinthenetworkinordertobringthemclosertothecaller.Incaseofworld-widedistributedCloudenvironments,itdoesnotmatteranymoreinwhichcomputingcentertheMicroservicesarerunning.WhentheMicroserviceinfrastructureusesseveralcomputingcentersandprocessescallsalwaysinthenearestcomputingcenter,thearchitecturecansignificantlyreducetheresponse

times.Besides,staticcontentcanbedeliveredbyaCDN(ContentDeliveryNetwork),whoseserversarelocatedevenclosertotheusers.

However,thebetterscalingandthesupportforcachingcannotworkmiracles:Microservicesresultinadistributedarchitecture.Callsviathenetworkarealotslowerthanlocalcalls.FromapureperformanceperspectiveitmightbebettertocombineseveralMicroservicesortousetechnologieswhichfocusonlocalcalls(comparechapter15).

Robustness

Actually,Microservicesshouldbelessreliablethanotherarchitectureapproaches.Afterall,Microservicesareadistributedsystem.Thuspossiblenetworkfailuresaddtotheusualsourcesoferrors.Moreover,Microservicesrunonseveralserverssothatthereisalsoalargerprobabilityforhardwarefailure.

Toensureahighavailability,theMicroservices-basedarchitecturehastobeappropriatelydesigned.ThecommunicationbetweentheMicroserviceshastoformakindoffirewall:ThefailureofaMicroservicemaynotpropagate.ThispreventsthataproblemarisinginanindividualMicroservicecausesafailureofthecompletesystem.

Accordingly,theMicroservice,whichiscalling,hastosomehowkeepworkinguponafailure.Onepossibilityistoassumedefaultvalues.Alternatively,thefailuremightleadtoagracefuldegradationi.e.asomehowreducedservice.

Itcanalreadybedecisivehowafailureisdealtwithtechnically:TheoperationsystemleveltimeoutforTCP/IPconnectionsisoftensettofiveminutes,forexample.IfduetothefailureofaMicroservicerequestsrunintothistimeout,thethreadisblockedforfiveminutes.Atsomepointallthreadswillbeblocked.Ifthathappens,thecallingsystemmightfailasitcannotdoanythingelseanymorethanwaitfortimeouts.Thiscanbeavoidedbysupplyingthecallswithshortertimeouts.SuchideasarearoundmuchlongerthantheconceptofMicroservices.Thebook“ReleaseIt”1indetailpresentssuchchallengesandapproachesforsolvingthem.Whentheseapproachesareimplemented,Microservice-basedsystemscantoleratethefailureofentireMicroservicesandthusbecomemorerobustthanaDeploymentMonolith.

IncomparisontoDeploymentMonolithsMicroserviceshavetheadditionaladvantagethattheydistributethesystemintomultipleprocesses.Theseprocesses

arebetterisolatedfromeachother.InaDeploymentMonolith,whichonlystartsoneprocess,memoryleaksorafunctionalityusingupalotofcomputingresourcescanmakethewholesystemfail.Sucherrorsareveryoftensimpleprogrammingmistakesorslips.ThedistributionintoMicroservicespreventssuchsituationsasonlyasingleMicroservicewouldbefailinginsuchascenario.

FreeTechnologyChoice

Microservicesoffertechnologicalfreedom.SinceMicroservicescommunicateonlyviathenetwork,theycanbeimplementedinanylanguageandplatformaslongascommunicationwithotherMicroservicesispossible.Thisfreetechnologychoicecanbeusedtotestnewtechnologieswithoutrunningbigrisks.AsatestonecanusethenewtechnologyinasingleMicroservice.Ifthetechnologydoesnotperformaccordingtoexpectations,onlythisoneMicroservicehastoberewritten.Inaddition,troublesarisingincaseoffailurewillbelimited.Thefreetechnologychoiceoffersforinstancetheadvantagethatdeveloperscanreallyusenewtechnologiesinproduction.Thisincreasesmotivationandhaspositiveeffectsonpersonnelrecruitmentasdevelopersnormallyenjoytousenewtechnologies.

Moreover,inthiswaythemostappropriatetechnologycanbeusedforeachproblem.Adifferentprogramminglanguageoracertainframeworkcanbeusedtoimplementspecificsystemparts.ItisevenpossibleforanindividualMicroservicetouseaspecificdatabaseorpersistencetechnology.However,backupanddisasterrecoverymechanismshavetobeimplementedforthat.

Freetechnologyisanoption–itdoesnothavetobemadeuseof.TechnologiescanalsobedefinedforallMicroservicesinaprojectsoeachMicroserviceisboundtoaspecifictechnologystack.However,DeploymentMonolithinherentlynarrowthechoicesdevelopershave:Forexample,inJavaapplicationseachlibrarycanonlybeusedinoneversion.Accordingly,notonlythelibrariestobeused,buteventheversionshavetobesetinaDeploymentMonolith.Microservicesdonotimposesuchtechnicallimitations.

Independence

DecisionsregardingtechnologyandputtingnewversionsintoproductionconcernonlyindividualMicroservices.ThismakesMicroservicesveryindependentofeachother.Ofcourse,therehastobeacommontechnicalbasis.TheinstallationofMicroservicesshouldbeautomated,thereshouldbeaContinuousDeliverypipelineforeachMicroservices,andMicroservicesshouldadheretothemonitoringspecifications.However,withintheseparametersMicroservicescan

implementapracticallyunlimitedchoiceoftechnicalapproaches.DuetothegreatertechnologicalfreedomthereislesscoordinationnecessarybetweenMicroservices.

5.2OrganizationalBenefitsMicroservicesareanarchitecturalapproachandthusshouldhaveonlyadvantagesforsoftwaredevelopmentandstructure.However,duetoConway’sLaw(comparesection4.2)architectureaffectsalsoteamcommunicationandthusorganization.

FirstofallMicroservicesreachahighleveloftechnicalindependenceasthelastsection(5.1)discussed.WhenwithintheorganizationateamisinfullchargeofaMicroservice,theteamcanmakefulluseofthetechnicalindependence.However,theteamhasalsothefullresponsibilityifaMicroservicemalfunctionsorfailsinproduction.

InthismannerMicroservicessupportteamindependence.ThetechnicalbasisallowsteamstoworkonthedifferentMicroserviceswithlittlecoordination.Thisprovidesthefundamentfortheindependentworkoftheteams.

Inotherprojects,technologyorarchitecturehavetobedecidedcentrallysincetheindividualteamsandmodulesareboundtothesedecisionsduetothetechnicalframeconditions.ItmightjustbeimpossibletousetwodifferentlibrariesoreventwodifferentversionsofonelibrarywithinoneDeploymentMonolith.Thus,centralcoordinationismandatory.ForMicroservices,thesituationisdifferent.Thisallowsforselforganization.However,aglobalcoordinationmightstillbesensible,forinstancetobeabletoperformanupdateincludingallcomponentsincaseofasecurityproblemwithalibrary.

Teamshavemoreresponsibilities:TheydecidethearchitectureoftheirMicroservices.Theycannothandoverthisresponsibilitytoacentralarchitecture.Thus,theyalsohavetocarrytheconsequencessincetheyhavetheresponsibilityfortheMicroservice.

TheScalaDecisionInaprojectemployingaMicroservice-basedapproachthecentralarchitecturegroupwassupposedtodecidewhetherScalacouldbeusedasprogramminglanguagebyoneteam.Thisdecisionwouldhavetransferredtheresponsibilityforthedecisiontothecentralarchitecturegroup.Thegroupwouldhavehadtodecidewhethertheteammightsolveitsproblemsmore

efficientlybyusingScalaorwhethertheuseofScalamightcreateadditionalproblemsintheend.Eventually,thedecisionwasdelegatedtotheteamsincetheteamhastotakeresponsibilityforitsMicroservice.Theyhavetodealwiththeconsequences,ifScalaintheenddoesnotfulfillthedemandsofproductionordoesnotsupportanefficientsoftwaredevelopment.TheyhavetheinvestmentofgettingfamiliarwithScalafirstandhavetoestimatewhetherthiseffortwillpayoffintheend.Likewise,theyhaveaproblemifsuddenlyallScaladevelopersleavetheprojectorchangetoanotherteam.Todelegatetheresponsibilitytothecentralarchitecturegroupisstrictlyspeakingnotevenpossiblesincethecentralarchitecturegroupisnotdirectlyaffectedbytheconsequences.Therefore,theteamjusthastodecidebyitself.Theteamhastoincludeallteammembersintothedecision–alsotheProductOwner,whowouldforinstancesufferintheendincaseofalowproductivity.

Thislineofactionrepresentsaradicalrenunciationofoldformsoforganization,wherethecentralarchitecturegroupprescribesthetechnologystacktobeusedforeverybody.Inthistypeoforganizationtheindividualteamsarenotresponsiblefordecisionsandnonfunctionalrequirementslikeavailability,performanceorscalability.Inaclassicalarchitecture,thenonfunctionalpropertiescanonlybeprovidedforcentrallysincetheycanonlybewarrantedbythecommonbasisoftheentiresystem.WhenMicroservicesdonotforceacommonbasisanymore,thesedecisionscanbedistributedtotheteamsthusenablingagreaterself-relianceandindependence.

Smallerprojects

Finally,MicroservicesallowforthedistributionoflargeprojectsintonumeroussmallprojectsastheindividualMicroservicesaresoindependentthatacentralcoordinationlosesimportance.Therefore,acomprehensiveprojectorganizationisnotnecessaryanymore.Largeorganizationsareproblematicastheyhavearelativelylargecommunicationoverhead.WhenMicroservicesenablethefragmentationofalargeorganizationintoseveralsmallerones,theneedforcommunicationdecreases.Thisallowsteamstofocusmoreontheimplementationofrequirements.

Largeprojectswillalsofailmorefrequently.Alsofromthisperspectiveitisbetterwhenalargeprojectcanbedividedintomultiplesmallerprojects.Thesmallerextentoftheindividualprojectsenablesmorepreciseestimations.Betterestimationsimproveplanninganddecreaserisk.Andeveniftheestimationiswrong,theimpactoftheincorrectdecisionsislower.Inconjunctionwiththegreaterflexibilitythiscanspeedupandfacilitatetheprocessofdecisionmaking–especiallyastheassociatedriskissomuchsmaller.

5.3BenefitsfromaBusinessPerspectiveThealreadydiscussedadvantagesfromanorganizationalperspectiveleadalsotobusinessadvantages:Theprojectshavealowerrisk,andcoordinationbetweenteamsneedstobelessintensesothattheteamscanworkmoreefficiently.

ParallelWorkonStories

ThedistributionintoMicroservicesenablestheparallelworkondifferentstories(compareFig.12).Eachteamworksonastory,whichonlyconcernstheirownMicroservice.Consequently,theteamscanworkindependently,andthesystemassuchcanbesimultaneouslyexpandedatdifferentspots.Thiseventuallyscalestheagileprocess.However,scalingdoesnottakeplaceatthelevelofdevelopmentprocesses,butisfacilitatedbythearchitectureandtheindependenceoftheteams.ChangesanddeploymentsofindividualMicroservicesarepossiblewithoutcomplexcoordination.Therefore,teamscanworkindependently.Whenateamisslowerorencountersobstacles,thisdoeshardlyinfluencetheotherteams.Thustheriskassociatedwiththeprojectisfurtherreduced.

Anunambiguousdomain-baseddesignandtheassignmentofonedeveloperteamperMicroservicecanscalethedevelopmentorprojectorganizationwiththenumberofteams.

Fig.12:Exampleforlegacyintegration

ItispossiblethatchangesconcernseveralMicroservicesandthusseveralteams.Anexample:Onlycertaincustomersareallowedtoordersomeproducts–forinstancebecauseofyouthprotection.IncaseofthearchitecturedepictedinFig.12changestoallMicroserviceswouldbenecessarytoimplementthisfeature.TheCustomerMicroservicewouldhavetostorethedatawhetheracustomerisoflegalage.Productsearchshouldhideorlabeltheproductsprohibitedforunderagecustomers.Finally,theorderprocesshastopreventtheorderingofprohibitedproductsbyunderagecustomers.Thesechangeshavetobecoordinated.CoordinationisespeciallyrequiredwhenoneMicroservicecallsanother.InthatcasethecalleduponMicroservicehastobechangedfirstsothatthecallercanafterwardsusethenewfeatures.

Thisproblemcancertainlybesolved.Onecanreasonthattheoutlinedarchitectureisnotoptimal.Ifthearchitectureisgearedtothebusinessprocesses,thechangescanbelimitedtotheorderprocess.Eventually,onlytheorderingistobeprohibited,notsearching.Theinformationwhetheracertainclientisallowedtoorderornotshouldalsobewithintheresponsibilityoftheorderprocess.Whicharchitectureandconsequentlywhichteamdistributionistherightone,dependsontherequirementsandtheconcernedMicroservicesandteams.

Ifthearchitecturehasbeenselectedappropriately,Microservicescanwellsupportagility.ThisisforsureagoodreasonfromabusinessperspectivetouseaMicroservice-basedarchitecture.

5.4ConclusionInsummaryMicroservicesleadtothefollowingtechnicaladvantages(section5.1):

Strongmodularization:DependenciesbetweenMicroservicescannoteasilycreepin.Microservicescanbeeasilyreplaced.ThestrongmodularizationandthereplaceabilityofMicroservicesleadstoasustainedspeedofdevelopment:TheArchitectureremainsstable,andMicroservices,whichcannotbemaintainedanymore,canbereplaced.Thus,thequalityofthesystemremainshighalsoonthelongrunsothatthesystemsstaysmaintainable.LegacysystemscanbesupplementedwithMicroserviceswithouttheneedtocarryaroundalltheballast,whichhasaccumulatedinthelegacysystem.Therefore,Microservicesareagoodapproachwhendealingwithlegacysystems.SinceMicroservicesaresmalldeploymentunits,aContinuousDeliverypipelineismucheasiertosetup.Microservicescanbescaledindependently.IfMicroservicesareimplementedinlinewithestablishedapproaches,thesystemwillbemorerobustintheend.EachMicroservicecanbeimplementedinadifferentprogramminglanguageandwithadifferenttechnology.Therefore,Microservicesarelargelyindependentfromeachotheronatechnicallevel.

Thetechnicalindependenceaffectstheorganization(section5.2):Theteamscanworkindependentlyandontheirownauthority.Thereislessneedforcentralcoordination.Largeprojectsarereplacedbyacollectionofsmallprojects,whichpositivelyaffectsriskandcoordination.

Fromabusinessperspectivejusttheeffectsonriskarealreadypositive(section5.3).However,isisevenmoreattractivethattheMicroservice-basedarchitecture

enablesthescalingofagileprocesseswithoutrequiringanexcessiveamountofcoordinationandcommunication.

EssentialPoints

Therearenumeroustechnicaladvantages–rangingfromscalabilityandrobustnesstosustainabledevelopment.Thetechnicalindependenceresultsinadvantagesontheorganizationallevel.Teamsbecomeindependent.Thetechnicalandorganizationaladvantagestakentogetherresultinadvantagesatthelevelofbusiness:alowerriskandafasterimplementationofmorefeatures.

TryandExperiment

Lookataprojectyouknow:

WhyareMicroservicesusefulinthisscenario?Evaluateeachadvantagebyassigningpoints(1=norealadvantage;10=verylargeadvantage).Thepossibleadvantagesarelistedintheconclusionofthischapter.

WhatwouldtheprojectlooklikewithorwithouttheuseofMicroservices?

DevelopadiscussionoftheadvantagesofMicroservicesfromtheperspectiveofanarchitect,adeveloper,aprojectleaderandthecustomerfortheproject.Thetechnicaladvantageswillbemoreofinterestforthedevelopersandarchitects,whiletheorganizationalandbusinessadvantagesmattermoreforprojectleadersandcustomers.Whichadvantagesdoyouputmostemphasisonforthedifferentgroups?

Visualizethecurrentdomaindesigninyourprojectorproduct.

Whichteamsareresponsibleforwhichpartsoftheproject?Wheredoyouseeoverlap?Whatshouldthedistributionofteamstoproductpartsandserviceslookliketoachievealargelyindependentmodeofoperation?

1. MichaelT.Nygard:ReleaseIt!:DesignandDeployProduction-ReadySoftware,PragmaticProgrammers,2007,ISBN978-0-97873-921-8↩

6Challenges

ThedistributionofasystemintoMicroservicesentailsahighercomplexity.Thisleadstochallengesatthetechnicallevel(comparesection6.1)–forinstancehighlatencytimesinthenetworkorthefailureofindividualservices.However,alsoatthelevelofsoftwarearchitecturethereareanumberofthingstoconsider–forinstancebecauseofthebadarchitecturechangeability(section6.2).Andfinally,therearemanymorecomponentstobeindependentlydeliveredsothatoperationandinfrastructurebecomemorecomplex(section6.3).ThesechallengeshavetobedealtwithwhenintroducingMicroservices.Measuresdescribedinthefollowingchaptersshowhowtoappropriatelyhandlethesechallenges.

6.1TechnicalChallengesMicroservicesaredistributedsystems.CallsbetweenMicroservicesgoviathenetwork.ThisaffectsthelatencyandthustheresponsetimesofMicroservicesnegatively.Thealreadymentionedfirstrulefordistributedobjectsstatesthatobjects,ifpossible,shouldnotbedistributed(comparesection4.1).

ThereasonforthatisillustratedinFig.13Acallhastogoviathenetworktoreachtheserver,isprocessedthereandhastoreturntothecaller.Thelatencyjustfornetworkcommunicationcanbearound0.5msinacomputingcenter(comparehere).Withinthistimeaprocessorrunningat3Ghzcanprocessabout1.5millioninstructions.Whenacomputationisredistributedtoanothernode,itshouldbecheckedwhetherlocalprocessingoftherequestmightnotbefaster.Thelatencycanevenincreasefurtherbyparametermarshalingandunmarshalingforacallandtheresultofacall.Ontheotherhand,networkoptimizationsorconnectingnodestothesamenetworkswitchcanimprovethesituation.

Fig.13:Latencyforacallviathenetwork

ThefirstrulefordistributedobjectsandthewarningtobeawareofthelatencywithinthenetworkdatesbacktothetimewhenCORBAandEJBwereused.ThesetechnologieswereoftenusedfordistributedThreeTierArchitectures(compareFig.14).ForeveryclientrequestthewebtierimplementsonlythedatarenderingasHTMLpage.Thelogicresidesonanotherserver,whichiscalledviathenetwork.Thedataaredepositedinthedatabaseandthusonanagainotherserver.Whenonlydataaretobeshown,thereislittlehappeningintheMiddleTier.Thedataarenotprocessed,justforwarded.Forperformanceandlatency,itwouldbemuchbettertokeepthelogiconthesameserverasthewebtier.Though

thedistributionallowstoscaletheMiddleTierindependently,thesystemdoesnotgetfasterthiswaywhenitanyhowdoesnothavemuchtodo.

Fig.14:ThreeTierArchitecture

ForMicroservicesthesituationisdifferentastheUIiscontainedintheMicroservice.CallsbetweenMicroservicesonlytakeplacewhenMicroservicesneedfunctionalitiesofotherMicroservices.Ifthatisoftenthecase,thismightbeahintthattherearearchitecturalproblemsastheMicroservicesshouldbelargelyindependentofeachother.

Practically,Microservice-basedarchitecturesfunctioninspiteofthechallengesrelatedtodistribution.StillMicroservicesshouldnotcommunicatetoomuchwitheachotherinordertoimproveperformanceandreducelatency.

CodeDependencies

ThegreatadvantageofMicroservice-basedarchitecturesistheoptiontoindependentlydeploytheindividualservices.However,thisoptioncanbeundonebycodedependencies.IfalibraryisusedbyseveralMicroservicesandanewversionofthislibraryissupposedtoberolledout,acoordinateddeploymentofseveralMicroservicesmightberequired–preciselythescenariothatshouldbeprevented.Somethinglikethatcanforinstanceeasilyoccurduetobinarydependencieswheresometimesdifferentversionsarenotcompatibleanymore.ThedeploymenthastobetemporallycoordinatedinawaythatallMicroservicesarerolledoutinacertaintimeintervalandinadefinedorder.BesidesthecodedependencyhastobechangedinallMicroservices,aprocessthathaslikewisetobeprioritizedandcoordinatedacrossallinvolvedteams.Abinaryleveldependencyisaverytighttechnicalcoupling,whichentailsaverytightorganizationalcoupling.

ThereforeMicroservicespropagateaSharedNothingApproachwheretheMicroservicesdonotpossesssharedcode.Microservicesratheracceptcoderedundancyandresisttheurgetoreusecodeinordertoavoidacloseorganizationallink.

Codedependenciescanbetolerableincertainsituations.WhenaMicroserviceoffersforinstanceaclientlibrary,whichsupportscallerswhileusingthisMicroservice,thisdoesnotnecessarilyhavenegativeconsequences.ThelibrarydependsontheinterfaceoftheMicroservice.Iftheinterfaceischangedinabackwardcompatiblemanner,alsoacallerhavinganoldversionoftheclientlibrarycanstillusetheMicroservice.Thedeploymentremainsuncoupled.However,theclientlibrarycanbethestartingpointtoacodedependency.Ifthe

clientlibrarycontainsforinstancedomainobjects,thiscanbeaproblem.Infact,iftheclientlibrarycontainsthesamecodeforthedomainobjects,whichisalsointernallyused,changestotheinternalmodelwillaffecttheclients.Theymighthavetobedeployedagainifneedbe.Ifthedomainobjectcontainslogic,thislogiccanonlybemodifiedwhenallclientsarelikewisedeployedanew.ThisalsoviolatestheideaofindependentlydeployableMicroservices.

ConsequencesofCodeDependenciesHereisanexamplefortheeffectsofcodedependencies:Userauthenticationisacentralfunction,whichallservicesuse.Aprojecthasdevelopedaserviceimplementingtheauthentication.Nowadaysthereareopensourceprojects,whichimplementsuchthings,(section8.12)sothatanimplementationofahome-grownsolutionisrarelysensibleanymore.InthatprojecteachMicroservicecouldusealibraryforfacilitatingthehandlingoftheauthenticationservice.Accordingly,allMicroserviceshaveacodedependencytowardstheauthenticationservice.Changestotheauthenticationservicemightrequirethatthelibraryhastobenewlyrolledout.ThisinturnmeansthatallMicroserviceshavetobemodifiedandnewlyrolledoutaswell.Inaddition,thedeploymentsoftheMicroservicesandtheauthenticationservicehavetobecoordinated.Thiscaneasilycostatwo-digitnumberofmandays.Thusauthenticationcanhardlybechangedanymoreduetothecodedependency.Iftheauthenticationservicecouldbedeployedjustlikethatandiftherewerenocodedependencies,whichcouplethedeploymentoftheMicroservicesandtheauthenticationservice,theproblemwouldbesolved.

UnreliableCommunication

CommunicationbetweenMicroservicesoccursviathenetworkandisthereforeunreliable.Inaddition,Microservicescanfail.Topreventthatafailureoftheentiresystemensues,theremainingMicroservicesinsuchacasehavetocompensateforthefailureofthemalfunctioningMicroserviceandkeepbeingavailable.However,toachievethisgoalthequalityoftheserviceshastobedegradedi.e.byusingdefaultvaluesorlimitingtheuseablefunctionality(section10.5).

Thisproblemcannotbecompletelysolvedonatechnicallevel:TheMicroserviceavailabilitycanforinstancebeoptimizedbyhighlyavailablehardware.Butthisincreasescosts.Besides,itisnocompletesolution:Insomerespects,itevenincreasesrisk.IftheMicroservicefailsdespitehighlyavailablehardwareandthefailurepropagatesacrosstheentiresystem,acompletefailureoftheentiresystemoccurs.Thus,theMicroservicesshouldrathercompensatethefailureofanotherMicroservice.

Inaddition,thethresholdbetweenatechnicalandadomainproblemiscrossed.AnATMmightserveasexample:WhentheATMcannotretrievetheaccountbalanceofthecustomer,therearetwopossibilities.TheATMcanrefusethewithdrawal.Althoughthisisasafeoption,itwillangerthecustomeranddecreaserevenue.Alternatively,theATMcanhandoutthemoney–maybeuptoacertainupperlimit.Whichalternativeshouldbeimplemented,isabusinessdecision.Eventually,somebodyhastodecidewhetheritispreferabletobeonthesafeside,evenifitmeanstoforegosomerevenueandangercustomers,ortorunacertainrisktopayouttoomuchmoney.

TechnologyPluralism

ThetechnologyfreedomofMicroservicescanresultinaprojectusingmanydifferenttechnologies.TheMicroservicesdonotneedtohaveasharedtechnologybasis.Accordingly,thecomplexityofthewholesystemincreases.Eachteammastersthetechnologies,whichareusedinitsownMicroservice.However,thelargenumberofusedtechnologiesandapproachescancausethesystemassuchtoreachalevelofcomplexitynoindividualdeveloperorteamcanunderstandanymore.ButoftensuchageneralunderstandingisnotnecessarysinceeachteamonlyneedstounderstanditsownMicroservice.Wheneveritbecomesnecessarytohavealookattheentiresystem-beitevenonlyfromacertainlimitedperspectiveasforinstanceoperations–,thecomplexitymightposeaproblem.Insuchcases,unificationcanbeasensiblecountermeasure.Thisdoesnotmeanthatthetechnologystackhastobecompletelyuniform,butthatcertainpartsshouldbeuniformorthattheindividualMicroservicesshouldbehaveinauniformmanner.Forinstance,auniformloggingframeworkmightbedefinedorauniformformatforlogging,whichdifferentloggingframeworksmightimplementdifferently.Alternatively,acommontechnicalbasisliketheJVM(JavaVirtualMachine)canbedecideduponforoperationalreasonswithoutsettingtheprogramminglanguages.

6.2ArchitectureThearchitectureofaMicroservice-basedsystemdistributesthedomain-basedfunctionalitiesamongtheMicroservices.TounderstandthearchitectureatthisleveldependenciesandcommunicationrelationshipsbetweentheMicroserviceshavetobeknown.Analyzingcommunicationrelationshipsisdifficult.ForlargeDeploymentMonolithstherearetools,whichreadsourcecodeorevenonlytheexecutablesystem.Basedonthisthetoolscangenerategraphsvisualizingmodulesandrelationships.Thismakesitpossibletoverifytheimplemented

architecture,adjustitinregardstotheplannedarchitectureandtofollowthearchitectureevolutionovertime.Suchoverviewsarecentralforarchitecturalwork,however,difficulttogenerateinthecaseofMicroservicesastherespectivetoolsarelacking–buttherearesolutions.Section8.2discussestheseindetail.

Architecture=Organization

Microservicesarebasedontheideathatorganizationandarchitecturearethesame.Microservicesexploitthiscircumstancetoimplementthearchitecture.Theorganizationisstructuredinaway,whichrendersthearchitectureimplementationespeciallyeasy.However,thismeansthatanarchitecturerefactoringcanentailchangestotheorganization.Thisrendersarchitecturalchangesmoredifficult.ThisisnotonlyaproblemofMicroservices:Conway’sLaw(section4.2)appliestoallprojects.However,otherprojectsoftenarenotawareofthelawanditsimplications.Therefore,theydonotusethelawproductivelyandcannotestimatetheorganizationalproblemscausedbyarchitecturalchanges.

ArchitectureandRequirements

ThearchitectureinfluencesalsotheindependentdevelopmentofindividualMicroservicesandtheindependentstreamsofstories.Whenthedomain-baseddistributionofMicroservicesisnotoptimal,requirementsmightnotonlyinfluenceoneteamandoneMicroservice,butseveral.InsuchcasesalargeramountofcoordinationisnecessarybetweenthedifferentteamsandMicroservices.ThisinfluencestheproductivitynegativelyandthusundoesoneoftheessentialreasonsfortheintroductionofMicroservices.

IncaseofMicroservicesthearchitectureinfluencesnotonlythesoftwarequality,butalsotheorganizationandtheindependentworkoftheteamsandtherebytheproductivity.Designinganoptimalarchitecturegetsevenmoreimportantsincemistakeshavefarreachingconsequences.

Manyprojectsdonotpaysufficientattentiontodomainarchitecture,oftenmuchlessthantotechnicalarchitecture.Besides,mostarchitectsarenotasexperiencedwithdomainarchitectureaswithtechnicalarchitecture.ThesecircumstancescancausetremendousproblemsinthecaseofMicroservice-basedapproaches.ThedistributionintoMicroservicesandthereforeintofieldsofresponsibilityforthedifferentteamshastobeperformedaccordingtodomaincriteria.

Refactoring

InasingleMicroservicerefactoringissimplesincetheMicroserviceissmall.Itcanalsobeeasilyreplacedandnewlyimplemented.

BetweenMicroservicesthesituationdiffers:TransferringfunctionalitiesfromoneMicroservicetoanotherisdifficult.Thefunctionalityhastobemovedintoadifferentdeploymentunit.Thisisforsuremoredifficultthanmovingafunctionalitywithinthesameunit.BetweenMicroservicestechnologiesarenotnecessarilyuniform.Microservicescanusedifferentlibrariesorevendifferentprogramminglanguages.InsuchcasesthefunctionalityhastobemovedintoanewMicroservice.InsomecasesthefunctionalitymustbenewlyimplementedinthetechnologyoftheotherMicroserviceandsubsequentlytransferredintothisMicroservice.However,thisisfarmorecomplexthanmovingcodewithinaMicroservice.

AgileArchitecture

Microservicesmakeiteasiertobringasmanychangesaspossibleintoproductionintheshortestpossibletimeandtoreachasustainabledevelopmentspeed.Thisisespeciallyadvantageouswhentherearenumerousandhardtopredictrequirements.ThisisexactlytheenvironmentwhereMicroservicesareathome.ChangestoaMicroservicearealsoverysimple.However,adjustingthearchitectureofthesystemassuch,forinstancebymovingaroundfunctionalities,isnotsosimple.

Inaddition,thearchitectureofasystemisfrequentlynotyetoptimalatthefirstattempt.Duringimplementationtheteamlearnsalotaboutthedomain.Inasecondattempt,itwillbemuchmorecapableofdesigninganappropriatearchitecture.Mostprojectssufferingfrombadarchitecturehadagoodarchitectureattheoutsetbasedonthestateofknowledgeatthattime.However,whentheprojectprogressed,itbecameclearthatrequirementsweremeantdifferentlyandnewrequirementsarosesothattheinitialarchitecturestoppedfitting.Problemsarisewhenthisdoesnotleadtoconsequences.Iftheprojectjustcontinueswithamoreandmoreinappropriatearchitecture,thearchitecturewillnotfitatallanymoreatsomepoint.Thiscanbeavoidedbyadjustingthearchitecturestepbysteptothechangedrequirementsbasedontherespectivestateofknowledge.Architecturechangeabilityandarchitectureadjustmentinlinewithnewrequirementsarecentralforthis.However,architecturechangeabilityattheleveloftheentiresystemisaweaknessofMicroserviceswhilechangeswithinMicroservicesareverysimple.

Summary

WhenusingMicroservices,architectureisevenmoreimportantthaninothersystemsasitinfluencesalsotheorganizationandtheindependentworkonrequirements.Atthesametime,Microservicesoffermanyadvantagesincaseswhererequirementsareunclearandarchitecturethereforehastobechangeable.Unfortunately,theinterplaybetweenMicroservicesishardtomodifysincethedistributionintoMicroservicesisquiterigidduetothedistributedcommunicationbetweenthem.Besides,asMicroservicescanbeimplementedbytheuseofdifferenttechnologies,itgetsdifficulttomovefunctionalitiesaround.Ontheotherhand,changestoindividualMicroservicesortheirreplacementareverysimple.

6.3InfrastructureandOperationsMicroservicesaresupposedtobebroughtintoproductionindependentlyofeachotherandtobeabletouseindividualtechnologystacks.Therefore,eachMicroserviceusuallyresidesonitsownserver.Thisistheonlywaytoensurecompletetechnologicalindependence.Itisnotpossibletocopewiththerequiredmultitudeofsystemsusinghardwareservers.Evenwithvirtualizationthemanagementofsuchanenvironmentremainsdifficult.ThenumberofrequiredvirtualmachinescanbehigherthanotherwiseusedbyanentirebusinessIT.WhentherearehundredsofMicroservices,therearealsohundredsofvirtualmachinesneededandforsomeofthemseveralinstancese.g.forloadbalancing.Thisrequiresautomationandappropriateinfrastructures,whichareabletogeneratealargenumberofvirtualmachines.

ContinuousDeliveryPipelines

BeyondoperationeachMicroservicerequiresadditionalinfrastructure:ItneedsitsownContinuousDeliverypipelinesothatitcanbebroughtintoproductionindependentlyoftheotherMicroservices.Thismeansthatappropriatetestenvironmentsandautomationscriptsarenecessary.Thelargenumberofpipelinescausesadditionalchallenges:Thepipelineshavetobebuiltupandmaintained.Furthermore,toreduceexpensestheyneedtobelargelystandardized.

Monitoring

EachMicroservicerequiresinadditionmonitoring.Thisistheonlywaytorecognizeproblemswiththeserviceatruntime.IncaseofaDeploymentMonolith,itisstillquiteeasytomonitorthesystem.Whenproblemsarise,theadministratorcanlogintothesystemandusespecifictoolstoanalyzeerrors.Microservice-basedsystemscontainsomanysystemsthatthisapproachisnot

feasibleanymore.Consequently,therehastobeamonitoring,whichcomprisesallsystems.Thereby,notonlythetypicalinformationfromtheoperatingsystemandtheI/Ototheharddiscandtothenetworkshouldbeanalyzed,alsoaviewintotheapplicationshouldbepossiblebasedonapplicationmetrics.Thisistheonlywayfordeveloperstofindoutwheretheapplicationhastobeoptimizedandwhereproblemsexistatthemoment.

Versioncontrol

Finally,everyMicroservicehastobestoredunderversioncontrolindependentoftheotherones.Onlysoftware,whichisseparatelyversioned,canbebroughtintoproductionindividually.Whentwosoftwaremodulesareversionedtogether,theyshouldalwaysbebroughtintoproductiontogether.Otherwiseachangemighthaveinfluencedbothmodulessothatinfactbothservicesshouldbenewlydelivered.Moreover,ifanoldversionofoneoftheservicesisinproduction,itisnotclearwhetheranupdateisnecessaryorwhetherthenewversiondoesnotcontainchanges–afterallthenewversionmightonlyhavecontainedchangesintheotherMicroservice.

ForDeploymentMonolithsalowernumberofservers,environmentsandprojectsinversioncontrolwouldbenecessary.Thisdecreasescomplexity.TherequirementsinregardstooperationandinfrastructurearemuchhigherinaMicroservicesenvironment.TodealwiththiscomplexityisthebiggestchallengewhenintroducingMicroservices.

6.4ConclusionThischapterdiscussedthedifferentchallengesassociatedwithMicroservices-basedapproaches.Atthetechnicallevel(section6.1)thechallengesaremostlyaconsequenceofthefactthatMicroservicesaredistributedsystems:Duetothat,systemperformanceandreliabilityaremoredifficulttoensure.Inaddition,technicalcomplexityincreasesbecauseofthegreatervarietyofusedtechnologies.Furthermore,codedependenciescanrendertheindependentdeploymentofMicroservicesimpossible.

ThearchitectureofaMicroservice-basedsystem(section6.2)isextremelyimportantduetoitsimpactontheorganizationandtheparallelimplementationofmultiplestories.Atthesametime,changestotheinterplayofMicroservicesarehard.FunctionalitiescannotbeeasilytransferredfromoneMicroservicetoanother.Classeswithinaprojectcanoftenevenbemovedautomatically.Between

Microservicesmanualworkisnecessary.TheinterfacetothecodechangesfromlocalcallstocommunicationbetweenMicroservices.Thisincreasesthenecessaryefforts.Finally,Microservicescanbewrittenindifferentprogramminglanguages–insuchcasestomovecodeentailsthatithastoberewritten.

However,changestosystemarchitectureareoftennecessarybecauseofunclearrequirements.Besides,theteampermanentlyimprovesitsknowledgeaboutthesystemanditsdomain.EspeciallyincircumstanceswheretheuseofMicroservicesisparticularlyadvantageousbecauseofrapidandindependentdeployments,architectureshouldbepeculiarlyeasytochange.WithinMicroserviceschangesareindeedeasytoimplement,howeverbetweenMicroservicestheyareverylaborious.

Finallyinfrastructurecomplexityrisesduetothelargernumberofservices(section6.3)sincemoreservers,moreprojectsinversioncontrolandmoreContinuousDeliverypipelinesarenecessary.ThisisacentralchallengeencounteredbyMicroservice-basedarchitectures.

PartIIIofthebookisgoingtoshowsolutionsforthesechallenges.

EssentialPoints

Microservicesaredistributedsystems.Thismakesthemtechnicallymorecomplex.Agoodarchitectureisveryimportantduetoitsimpactontheorganization.WhilethearchitectureiseasytomodifywithinMicroservices,theinterplaybetweenMicroservicesishardtochange.DuetothenumberofMicroservicesmoreinfrastructureisnecessarye.g.intermsofserverenvironments,ContinuousDeliverypipelinesorprojectsinversioncontrol.

TryandExperiment

Chooseoneofthescenariosfromchapter3oraprojectyouknow:

Whicharethechallengestobeanticipated?Evaluatethesechallenges.Theconclusionofthischapterhighlightsthedifferentchallengesonceagaininacompressedmanner.Whichofthechallengesposesthebiggestrisk?Why?AretherepossibilitiestouseMicroservicesinawaywhichmaximizesadvantagesandavoidsdisadvantages?Forexample,heterogeneoustechnologystackscouldbeavoided.

7MicroservicesandSOA

AtfirstglanceMicroservicesandSOAseemtohavealotincommon:Bothapproachesfocusonthemodularizationoflargesystemsintoservices.AreSOAandMicroservicesindeedthesameoraretheredifferences?DissectingthisquestioncontributestoanindepthunderstandingofMicroservices.Besides,someideasfromtheSOAfieldareinterestingforMicroservice-basedarchitectures.ASOAapproachcanbeadvantageouswhenmigratingtoMicroservices.Itseparatesthefunctionalitiesoftheoldapplicationsintoservices,whichcanbereplacedorsupplementedbyMicroservices.

Section7.1definestheterm“SOA”aswellastheterm“service”withintheSOAcontext.Section7.2extendsthistopicbyhighlightingthedifferencesbetweenSOAandMicroservices.

7.1WhatisSOA?SOA(Service-OrientedArchitecture)andMicroservicesshareonesimilarity:Theylackanunambiguousdefinition.Therefore,thissectionprovidesonlyoneofthepossibledefinitions.AccordingtootherdefinitionsMicroservicesandSOAareindeedidenticalapproaches.Eventually,bothapproachesarebasedonservicesandthedistributionofapplicationsintoservices.

Theterm“service”iscentralforSOA.

ASOAserviceshouldhavethefollowingcharacteristics:

Aserviceshouldcompriseadomainfunctionality.Aservicecanbeusedindependently.Itisavailableinthenetwork.Eachservicehasaninterface.Knowledgeabouttheinterfaceissufficienttousetheservice.Theservicecanbeusedviadifferentprogramminglanguagesandplatforms.Tomakeiteasytousetheserviceisregisteredinadirectory.Viathisdirectoryclientssearchtheserviceatruntimeanduseit.

Theserviceshouldbecoarse-grainedinordertoreducedependencies.Smallservicescanonlyimplementsensiblefunctionalitiestogetherwithotherservices.Therefore,SOAfocusesratheronlargerservices.

SOAservicesdonotneedtobenewlyimplemented,butarealreadypresentinthecompanyapplications.IntroducingSOAmeanstomaketheseservicesavailableoutsideofthoseapplications.Becauseofthedistributionofapplicationsintoservicestheiruseindifferentcontextsisfacilitated.ThisissupposedtoimprovetheflexibilityoftheoverallIT–thatisthegoalofSOA.Duetothedistributionintoindividualservicesitispossibletorecycleservicesduringtheimplementationofbusinessprocesses.Thisrequiresonlytoorchestratetheindividualservices.

Fig.15:OverviewofaSOAlandscape

Fig.15depictsapossibleSOAlandscape.LikethepreviousexamplesthisexampleisderivedfromtheE-commercefield.TherearedifferentsystemsintheSOAlandscape:

TheCRM(CustomerRelationshipManagement)isanapplication,whichstoresessentialinformationaboutthecustomers.Thisinformationcomprisesnotonlycontactdetails,butalsothehistoryofalltransactionswiththecustomer–telephonecallsaswellasemailsororders.TheCRMexposesservices,whichforinstancesupportthecreationofanewcustomer,provideinformationaboutacustomerorgeneratereportsforallcustomers.TheOrderSystemisinchargeoforderprocessing.Itcanreceiveneworders,provideinformationabouttheorderstatusorcancelanorder.Alsothissystemprovidesaccesstothedifferentfunctionalitiesviaindividualservices.Theseservicesmighthavebeenaddedasadditionalinterfacetothesystemafterthefirstversionwasputintoproduction.IntheschemeCRMandtheordersystemaretheonlysystems.Inrealitytherewouldbecertainlyadditionalsystems,forinstancetoprovidetheproductcatalog.However,toillustrateaSOAlandscapethesetwosystemssuffice.Forthesystemstobeabletocalleachotherthereisanintegrationplatform.Thisplatformallowsforthecommunicationbetweentheservices.Itcannewlycomposetheservicesbyorchestration.Orchestrationcanbemediated

byatechnology,whichmodelsbusinessprocessesandcallstheindividualservicestoexecutethedifferentprocesses.Therefore,orchestrationisresponsibleforcoordinatingthedifferentservices.Theinfrastructureisintelligentandcanreactappropriatelytothedifferentmessages.Itcontainsthemodelofthebusinessprocessesandthusanimportantpartofthebusinesslogic.SOAcanbeusedviaaportal.Theportalisresponsibleforprovidingtheuserswithaninterfaceforusingtheservices.Therecanbedifferentportals:forinstanceoneforthecustomers,oneforthesupportandoneforinternalemployees.Likewise,thesystemcanbecalledviarichclientapplicationsormobileApps.Fromanarchitecturalperspectivethisdoesnotmakeadifference:Allsuchsystemsusethedifferentservicestomakethemuseableforauser.Eventually,allthesesystemsareauniversalUItobeabletouseallservicesintheSOA.

Eachofthesesystemscanbeoperatedundfurtherdevelopedbyanindividualteam.IntheexampletherecouldbeoneteameachfortheCRMandtheordersystem,andoneadditionalteameachforeachportalandfinallyoneteamtakingcareofintegrationandorchestration.

Fig16showshowcommunicationisstructuredinSOAarchitecture.UserstypicallyworkwithSOAviatheportal.Therebybusinessprocessescanbeinitiated,whichthenareimplementedintheorchestrationlayer.Theseprocessesusetheservices.EspeciallywhenmigratingfromaMonolithtoSOAusersmightstilluseaMonolithviaitsownuserinterface.However,SOAusuallyaimsforhavingaportalascentraluserinterfaceandanorchestrationforimplementingprocesses.

Fig.16:CommunicationinaSOAarchitecture

IntroducingSOA

IntroducingSOAisastrategicinitiativeinvolvingdifferentteams.IntheendtheaimistodistributetheentirecompanyITintoseparateservices.Thedistributionsupportsthecompositionofservicesintonewfunctionalitiesinabettermanner.However,thisisonlypossiblewhenallsystemsintheentireorganizationhavebeenadjusted.Andonlywhensomanyservicesareavailablethatbusinessprocessescanbeimplementedbysimpleorchestration,SOA’sadvantagesarereallyevident.Therefore,theintegrationandorchestrationtechnologyhastobeusedintheentireITtoenableservicecommunicationandintegration.ThisentailshighinvestmentcostsastheentireITlandscapehastobechanged.ThisisoneofthemainpointsofcriticisminregardstoSOA.

Theservicescanalsobeofferedtoothercompaniesandusersviainternetorprivatenetworks.ThusSOAiswellsuitedtosupportbusinessconcepts,whicharebasedontheoutsourcingofservicesortheinclusionofexternalservices.In

anE-commerceapplicationanexternalprovidercouldforinstanceoffersimpleserviceslikeaddressvalidationorcomplexserviceslikeacreditcheck.

ServicesinaSOA

AtleastwhenintroducingSOAbasedonoldsystemstheSOAservicesareonlyinterfacesoflargeDeploymentMonolith.OneMonolithoffersseveralservices.Theservicesarebuiltupontheexistingapplications.Oftenitisnotevennecessarytoadjusttheinternalsofasysteminordertooffertheservices.SuchaservicetypicallydoesnothaveaUI,insteaditoffersonlyaninterfaceforotherapplications.AUIexistsonlyforallsystems.Itisalsonotpartofaservice,butindependent-forinstanceintheportal.

Inaddition,itispossibletoimplementsmallerdeploymentunitsinaSOA.ThedefinitionofSOAservicesdoesnotlimitthesizeofthedeploymentunits–quitecontrarytoMicroserviceswherethesizeofthedeploymentunitsisadefiningfeature.

InterfacesandVersioning

ServiceversioninginSOAisaspecialchallenge.Servicechangeshavetobecoordinatedwiththeusersoftherespectiveservice.Becauseofthiscoordinationrequirement,changestotheinterfaceoftheservicesarelaborious.Serviceusersareunlikelytoadjusttheirownsoftwareiftheydonotprofitfromthenewinterface.Therefore,oldinterfaceversionsfrequentlyhavetobesupportedaswell.Thismeansthatnumerousinterfaceversionshaveprobablytobesupportedifaserviceisusedbymanyclients.Thisincreasessoftwarecomplexityandrenderschangesmoredifficult.Afterall,thecorrectfunctioningoftheoldinterfaceshastobeensureduponeachnewsoftwarerelease.Ifdataaresupplemented,challengesarisebecausetheoldinterfacesdonotsupportthesedata.Thisisnoproblemduringreading.However,whenwritingitcanbedifficulttocreatenewdatasetswithouttheadditionaldata.

ExternalInterfaces

Ifthereareexternalusersoutsidethecompanyusingtheservice,interfacechangesgetevenmoredifficult.IntheworstcasetheserviceproviderdoesnotevenknowexactlywhoisusingtheservicesinceitisavailabletoanonymoususersintheInternet.Inthatcaseitisnearlyimpossibletocoordinatechanges.Consequently,switchingoffanoldserviceversionthengetsnearlyunfeasible.Thisleadstoagrowingnumberofinterfaceversions,andservicechangesgetmoreandmoredifficult.ThisproblemconcernsMicroservicesaswell(comparesection9.6).

Theinterfaceusersarealsofacingchallenges:Iftheyneedaninterfacemodification,theyhavetocoordinatethiswiththeteamofferingtheservice.Thenthechangeshavetobeprioritizedinrelationtoallotherchangesandwishesofotherteams.Asdiscussedalready,aninterfacechangeisnoeasytask.Therefore,itcantakequitealongtimetillchangesareinfactimplemented.Thishampersthefurtherdevelopmentofthesystem.

InterfacesEnforceaCoordinationofDeployments

Afterachangetotheinterfacethedeploymentoftheserviceshastobecoordinated.Firsttheservicehastobedeployed,whichoffersthenewinterfaceversions.Onlythentheservice,whichusesthenewinterface,canbedeployed.SinceapplicationsaremostlyDeploymentMonolithsinthecaseofSOA,severalservicescanalwaysonlybedeployedtogether.Thisrendersthecoordinationofservicesmoredifficult.Inaddition,theriskincreasesasthedeploymentofaMonolithtakesalongtimeandishardtoundo–justbecausethechangesaresoextensive.

CoordinationandOrchestration

CoordinatingSOAviaanorchestrationintheintegrationlayerposesanumberofchallenges.InawayaMonolithisgenerated:Allbusinessprocessesareechoedinthisorchestration.ThisMonolithisoftenevenworsethantheusualMonolithsasitisusingallsystemswithintheenterpriseIT.Inextremecasesitcanhappenthattheservicesonlyundertakethedataadministrationwhilealllogicisfoundintheorchestration.InsuchcasestheentireSOAisintheendnothingelsethanaMonolith,whichishavingitsentirelogicintheorchestration.

However,eveninothersettingschangestoSOAarenotreallyeasy:Domainsaredividedintoservicesinthedifferentsystemsandintobusinessprocessesinorchestration.Whenachangetoafunctionalityalsoconcernsservicesortheuserinterface,thingsgetdifficult:Changingthebusinessprocessesisrelativelysimple,butchangingtheserviceisonlypossiblebywritingcodeandbydeployinganewversionoftheapplicationprovidingtheservice.Thenecessarycodechangesandthedeploymentcanbeverylaborious.Thus,theflexibilityofSOAislost,whichwasmeanttoarisefromasimpleorchestrationofservices.Modificationsoftheuserinterfacecausechangestotheportalortotheotheruserinterfacesystemsandrequirelikewiseanewdeployment.

Technologies

SOAisanarchitectureapproachandindependentofaconcretetechnology.However,aSOAhastodefineacommontechnologyforthecommunicationbetweentheservices,likeMicroservicesdo.Inaddition,aconcretetechnologyneedstobesetfortheorchestrationoftheservices.OftenintroducingaSOAleadstotheintroductionofcomplextechnologiestoallowfortheintegrationandorchestrationoftheservices.Therearespecialproducts,whichsupportallaspectsofSOA.However,theyarecorrespondinglycomplex,andtheirfeaturesarehardlyeverusedtofullcapacity.

Thistechnologycanrapidlyturnintoabottleneck.ManyproblemswiththesetechnologiesareattributedtoSOAalthoughSOAcouldbeimplementedwithothertechnologiesaswell.Oneoftheproblemsisthecomplexityofthewebservicesprotocols.SOAonitsownisstillquitesimple,however,inconjunctionwiththeextensionsfromtheWS-*environmentacomplexprotocolstackarises.WS-*isnecessaryfortransactions,securityorotherextensions.Complexprotocolsexacerbatetheinteroperability–however,interoperabilityisaprerequisiteforaSOA.

Anactionontheuserinterfacehastobeprocessedbytheorchestrationandthedifferentservices.Thesearedistributedcallswithinthenetworkwithassociatedoverheadandlatency.Moreover,thiscommunicationrunsviathecentralintegrationandorchestrationtechnology,whichaccordinglyhastocopewithnumerouscalls.

7.2DifferencesBetweenSOAandMicroservicesSOAandMicroservicesarerelated:Bothaimatsplittingapplicationsintoservices.ItisalsonoteasytodistinguishbetweenSOAandMicroservicesjustbecauseofwhatishappeninginthenetwork.Afterall,inbotharchitectureapproachesmanyservicesexchangeinformationviathenetwork.

Communication

LikeMicroservicesSOAcanbebasedonasynchronouscommunicationorsynchronouscommunication.SOAscanbeuncoupledbysendingmerelyeventslike“neworder”.InsuchcaseseverySOAservicecanreacttotheeventwithdifferentlogic.Oneservicecanwriteabillandanothercaninitiatethedelivery.Theservicesarestronglyuncoupledsincetheyonlyreacttoeventswithoutknowingthetriggerfortheevents.Newservicescaneasilybeintegratedintothesystembylikewisereactingtosuchevents.

Orchestration

However,alreadyatthelevelofintegrationdifferencesbetweenSOAandMicroservicesappear:InSOAtheintegrationsolutionisalsoresponsiblefororchestratingtheservices.Abusinessprocessisbuiltupfromservices.InaMicroservice-basedarchitecturetheintegrationsolutiondoesnotpossessanyintelligence.TheMicroservicesareresponsibleforcommunicatingwiththeotherservices.SOAattemptstouseorchestrationtogainadditionalflexibilityfortheimplementationofbusinessprocesses.Thiswillonlyworkoutwhenservicesanduserinterfacearestableanddonotfrequentlyhavetobemodified.

Flexibility

ForachievingthenecessaryflexibilityMicroservicesontheotherhandexploitthefactthateachMicroservicecanbeeasilychangedandbroughtintoproduction.WhentheflexiblebusinessprocessesofSOAarenotsufficient,SOAforcesthechangeofservicesintoDeploymentMonolithoruserinterfacesinanadditionalDeploymentMonolith.

Microservicesplaceemphasisonisolation:IdeallyauserinteractioniscompletelyprocessedwithinoneMicroservicewithouttheneedtocallanotherMicroservice.Therefore,changesrequiredfornewfeaturesarelimitedtoindividualMicroservices.SOAdistributesthelogictotheportal,theorchestrationandtheindividualservices.

Microservices:ProjectLevel

However,themostimportantdifferencebetweenSOAandMicroservicesisthelevelatwhichthearchitectureaims.SOAconsiderstheentireenterprise.ItdefineshowamultitudeofsystemswithintheenterpriseITinteracts.Microservicesontheotherhandrepresentanarchitectureforanindividualsystem.Theyareanalternativetoothermodularizationtechnologies.ItwouldbeconceivabletoimplementaMicroservice-basedsystemwithanothermodularizationtechnologyandthentobringthesystemintoproductionasaDeploymentMonolithwithoutdistributedservices.AnentireSOAspanstheentireenterpriseIT.Ithastolookatdifferentsystems.Analternativetoadistributedapproachisnotconceivable.Accordingly,thedecisionforaMicroservice-basedarchitecturecanconcernandbelimitedtoanindividualprojectwhiletheintroductionandimplementationofSOApertainstotheentireenterprise.

TheSOAscenariodepictedinFig.15resultsinafundamentallydifferentarchitecture(compareFig.17)ifimplementedusingMicroservices:

Fig.17:CRMasCollectionofMicroservices

SinceMicroservicesrefertoasinglesystem,thearchitecturedoesnotneedtocomprisetheentireITwithitsdifferentsystems,butcanbelimitedtoanindividualsystem.InFig.17thissystemistheCRM.Thus,implementingMicroservicesisrelativelyeasyandnotverycostlyasitissufficienttoimplementoneindividualprojectratherthantochangetheentireITlandscapeoftheenterprise.Accordingly,aMicroservice-basedarchitecturedoesnotrequireanintegrationtechnologytobeintroducedandusedthroughoutthecompany.TheuseofaspecificintegrationandcommunicationtechnologyislimitedtotheMicroservicesystem-itisevenpossibletouseseveralapproaches.Forinstance,ahigh-performanceaccessalsotolargedatasetscanbeimplementedbyreplicatingthedatainthedatabase.Foraccesstoothersystemsagainothertechnologiescanbeused.IncaseofSOAallservicesintheentirecompanyneedtobeaccessibleviaauniformtechnology.Thisrequiresauniformtechnologystack.Microservicesfocusonsimpler

technologies,whichdonothavetofulfillascomplexrequirementsasSOAsuites.Inaddition,communicationbetweenMicroservicesisdifferent:Microservicesemploysimplecommunicationsystemswithoutanyintelligence.Microservicescalleachotherorsendmessages.Theintegrationtechnologydoesnotimplementanorchestration.AMicroservicecancallseveralotherMicroservicesandimplementanorchestrationonitsown.Inthatcase,thelogicfortheorchestrationresidesintheMicroserviceandnotinanintegrationlayer.InthecaseofMicroservicestheintegrationsolutioncontainsnologic,becauseitwouldoriginatefromdifferentdomains.Thisconflictswiththedistributionaccordingtodomains,whichMicroservice-basedarchitecturesaimat.Theuseoftheintegrationisalsoentirelydifferent.MicroservicesavoidcommunicationwithotherMicroservicesbyhavingtheUIintegratedintotheMicroserviceandduetotheirdomain-baseddistribution.SOAfocusesoncommunication.SOAobtainsitsflexibilitybyorchestration-thisisaccompaniedbycommunicationbetweenservices.AndinthecaseofMicroservicesthecommunicationdoesnotnecessarilyhavetobeimplementedviamessagingorREST:AnintegrationattheUIlevelorviadatareplicationispossibleaswell.CRMascompletesystemisnotreallypresentanymoreinaMicroservice-basedarchitecture.InsteadthereisacollectionofMicroservices,whicheachcoverspecificfunctionalitieslikereportsorforecastingtransactionvolume.WhileinSOAallfunctionalitiesoftheCRMsystemarecollectedinasingledeploymentunit,eachserviceisanindependentdeploymentunitandcanbebroughtintoproductionindependentlyoftheotherservicesinthecaseofMicroservice-basedapproaches.DependingontheconcretetechnicalinfrastructuretheservicescanbeevensmallerthantheonesdepictedinFig.17.Finally,thehandlingofUIisdifferent:ForMicroservicestheUIispartoftheMicroservice,whileSOAtypicallyoffersonlyservices,whichthencanbeusedbyaportal.ThedivisionintoUIandserviceinSOAhasfarreachingconsequences:ToimplementanewfunctionalityincludingtheUIinSOA,atleasttheservicehastobechangedandtheUIadjusted.Thismeansthatatleasttwoteamshavetobecoordinated.Whenotherservicesinotherapplicationsareused,evenmoreteamsareinvolvedrequiringconsequentlyanevengreatercoordinationeffort.Inadditiontherearealsoorchestrationchanges,which

areimplementedlikewisebyaseparateteam.Microservicesontheotherhandattemptthatanindividualteamcanbringanewfunctionalityintoproductionwithaslittleneedforcoordinationwithotherteamsaspossible.DuetotheMicroservice-basedarchitecture,interfacesbetweenlayers,whichnormallyarebetweenteams,arenowwithinateam.Thisfacilitatestheimplementationofchanges.Thechangescanbeprocessedinoneteam.Ifanotherteamwereinvolved,thechangeshadtobeprioritizedinrelationtootherrequirements.EachMicroservicecanbedevelopedandoperatedbyoneindividualteam.Thisteamisresponsibleforaspecificdomainandcanimplementnewrequirementsorchangestothedomaincompletelyindependentlyofotherteams.Moreover,theapproachisdifferentbetweenSOAandMicroservices:SOAintroducesonlyonenewlayerabovetheexistingservicesinordertocombineapplicationsinnewways.Itaimsataflexibleintegrationoftheexistingapplications.Microservicesservetochangethestructureoftheapplicationsthemselves–inpursuitofthegoaltomakechangestoapplicationseasier.

ThecommunicationrelationshipsincaseofMicroservicesaredepictedinFig.18:TheuserinteractswiththeUI,whichisimplementedbythedifferentMicroservices.Inaddition,theMicroservicescommunicatewitheachother.ThereisnocentralUIororchestration.

Fig.18:CommunicationinthecaseofMicroservices

Synergies

TherearedefinitelyareaswhereMicroservicesandSOAhavesynergies.Intheendbothapproachespursuethegoaltoresolveapplicationsintoservices.SuchastepcanbehelpfulwhenmigratinganapplicationtoMicroservices:WhentheapplicationissplitintoSOAservices,individualservicescanbereplacedorsupplementedbyMicroservices.CertaincallscanbeprocessedbyaMicroservicewhileothercallsarestillprocessedbytheapplication.Thisallows

tomigrateapplicationsinastepwisemannerandtoimplementtheMicroservicesstepbystep.

Fig.19showsanexample:TheuppermostserviceofCRMissupplementedbyaMicroservice.ThisMicroservicenowtakesallcallsandcan,ifnecessary,calltheCRM.ThesecondCRMserviceiscompletelyreplacedbyaMicroservice.TherebytheCRMcanbecomplementedbynewfunctionalities.Atthesametime,itisnotnecessarytonewlyimplementtheentireCRM,insteadMicroservicescancomplementitatselectedplaces.Section8.5presentsadditionalapproacheshowlegacyapplicationscanbereplacedbyMicroservices.

Fig.19:SOAformigratingtoMicroservices

7.3ConclusionTab.2:DifferencesbetweenSOAandMicroservices

SOA MicroservicesScope Enterprise-widearchitecture ArchitectureforoneprojectFlexibility Flexibilitybyorchestration Flexibilitybyfastdeployment andrapid,independentdevelopment ofMicroservicesOrganization Servicesareimplemented Servicesareimplemented bydifferentorganizational byteamsinthesame

units projectDeployment Monolithicdeploymentof EachMicroservicecan severalservices bedeployedindividuallyUI PortalasuniversalUIfor ServicecontainsUI allservices

Attheorganizationalleveltheapproachesareverydifferent:SOAsplaceemphasisonthestructureoftheentireenterpriseIT,Microservicescanbeutilizedinanindividualproject.SOAsfocusonanorganizationwheresometeamsdevelopbackendservices,whileadifferentteamimplementstheUI.InaMicroservice-basedapproachoneteamshouldimplementeverythingtofacilitatecommunicationandtherebyspeeduptheimplementationoffeatures.ThatisnotagoalofSOA.InSOAanewfeaturecanentailchangestonumerousservicesandthusrequirecommunicationbetweenalargenumberofteams.Microservicestrytoavoidthis.

Atthetechnicalleveltherearecommonalities:Bothconceptsarebasedonservices.Theservicegranularitycanevenbesimilar.BecauseofthesetechnicalsimilaritiesitdoesnotseemtobesoeasytodistinguishSOAfromMicroservices.However,fromconceptual,architecturalandorganizationalviewpointsbothapproacheshaveverydifferenteffects.

EssentialPoints

SOAandMicroservicessplitapplicationsintoservices,whichareavailableinthenetwork.Similartechnologiescanbeemployedtothisend.SOAaimsatflexibilityattheleveloftheenterpriseITbyorchestratingtheservices.Thisisacomplexundertakingandonlyworkswhentheservicesdonotneedtobemodified.Microservicesfocusonindividualprojectsandaimatfacilitatingdeploymentandenablingparallelworkondifferentservices.

TryandExperiment

AnewfunctionalityissupposedtobeincorporatedintotheSOAlandscapedepictedinFig.15.TheCRMdoesnothavesupportforemailcampaigns.Therefore,asystemforemailcampaignshastobeimplemented.Itissupposedtocontainaserviceforthecreationandexecutionofcampaignsandaserviceforevaluatingtheresultsofacampaign.

Anarchitecthastoanswerthefollowingquestions:

IstheSOAinfrastructureneededforintegratingthetwoservices?Theserviceforcampaignevaluationneedsalargeamountofdata.

Woulditbebettertousedatareplication,UI-levelintegrationorservicecallsforaccessingthelargeamountofdata?WhichoftheseintegrationoptionsistypicallyofferedbySOA?

Shouldtheserviceintegrateintotheexistingportalorratherhaveitsownuserinterface?Whichargumentsfavortheoneortheotheroption?ShouldthenewfunctionalitybeimplementedbytheCRMteam?

PartIII:ImplementingMicroservices

ThispartofthebookdemonstrateshowMicroservicescanbeimplemented.AfterstudyingthispartthereadercannotonlydesignMicroservice-basedarchitectures,butalsoimplementthemandevaluatetheorganizationaleffects.

Chapter8:ArchitectureofMicroservice-basedSystems

Chapter8describesthearchitectureofMicroservice-basedsystems.ItfocusesontheinterplaybetweenindividualMicroservices.

ThedomainarchitecturedealswithDomain-DrivenDesignasbasisofMicroservice-basedarchitecturesandshowsmetricswhichallowtomeasurethequalityofthearchitecture.Architecturemanagementisachallenge:ItcanbedifficulttokeeptheoverviewofthenumerousMicroservices.However,oftenitissufficienttounderstandhowacertainusecaseisimplementedandwhichMicroservicesinteractinaspecificscenario.

PracticallyallITsystemsaresubjecttomoreorlessprofoundchange.ThereforethearchitectureofaMicroservicesystemhastoevolveandthesystemhastoundergocontinueddevelopment.Toachievethisseveralchallengeshavetobesolved,whichdonotariseinthisforminthecaseofDeploymentMonoliths–forinstancetheoveralldistributionintoMicroservicesisdifficulttochange.However,changestoindividualMicroservicesaresimple.

Inaddition,Microservicesystemsneedtointegratelegacysystems.ThisisquitesimpleasMicroservicescantreatlegacysystemsasblackbox.AreplacementofaDeploymentMonolithbyMicroservicescanprogressivelytransfermorefunctionalitiesintoMicroserviceswithouthavingtoadjusttheinnerstructureofthelegacysystemorhavingtounderstandthecodeindetail.

ThetechnicalarchitecturecomprisestypicalchallengesfortheimplementationofMicroservices.InmostcasesthereisacentralconfigurationandcoordinationforallMicroservices.Furthermore,aloadbalancerdistributestheloadbetweentheindividualinstancesoftheMicroservices.ThesecurityarchitecturehastoleaveeachMicroservicethefreedomtoimplementitsownauthorizationsinthesystem,butalsoensurethatauserneedstologinonlyonce.Finally,Microservices

shouldreturninformationconcerningthemselvesasdocumentationandasmetadata.

Chapter9:IntegrationandCommunication

Chapter9showsthedifferentpossibilitiesfortheintegrationandcommunicationbetweenMicroservices.Therearethreepossiblelevelsforintegration:

Microservicescanintegrateattheweblevel.InthatcaseeachMicroservicedeliversapartofthewebUI.AtthelogiclevelMicroservicescancommunicateviaRESTormessaging.Datareplicationisalsopossible.

ViathesetechnologiestheMicroserviceshaveinternalinterfacesforotherMicroservices.Thecompletesystemcanhaveoneinterfacetotheoutside.Changestothedifferentinterfacescreatedifferentchallenges.Accordingly,thischapteralsodealswithversioningofinterfacesandtheeffectsthereof.

Chapter10:ArchitectureofIndividualMicroservices

Chapter10describespossibilitiesforthearchitectureofanindividualMicroservice.TherearedifferentapproachesforanindividualMicroservice:

CQRSdividesreadandwriteaccessintotwoseparateservices.Thisallowsforsmallerservicesandanindependentscalingofbothparts.EventSourcingadministratesthestateofaMicroserviceviaastreamofeventsfromwhichthecurrentstatecanbededuced.InahexagonalarchitecturetheMicroservicepossessesacore,whichcanbeaccessedviadifferentadaptorsandwhichcommunicatesalsoviasuchadaptorswithotherMicroservicesortheinfrastructure.

EachMicroservicecanfollowanindependentarchitecture.

IntheendallMicroserviceshavetohandletechnicalchallengeslikeresilienceandstability–theseissueshavetobesolvedbytheirtechnicalarchitecture.

Chapter11:TestingMicroservicesandMicroservice-basedSystems

Testingisthefocusofchapter11.AlsotestshavetotakethespecialchallengesassociatedwithMicroservicesintoconsideration.

Thechapterstartsoffwithexplainingwhytestsarenecessaryatallandhowasystemcanbetestedinprinciple.

Microservicesaresmalldeploymentunits.Thisdecreasestheriskassociatedwithdeployments.Accordingly,besidestestsalsooptimizationofdeploymentcanhelptodecreasetherisk.

TestingtheentiresystemrepresentsaspecialproblemincaseofMicroservicessinceonlyoneMicroserviceatatimecanpassthroughthisphase.Ifthetestslastonehour,onlyeightdeploymentswillbefeasibleperworkingday.Inthecaseof50Microservicesthatisbyfartoofew.Therefore,itisnecessarytolimitthesetestsasmuchaspossible.

OftenMicroservicesreplacelegacysystems.TheMicroservicesandthelegacysystembothhavetobetested–andalsotheirinterplay.TestsfortheindividualMicroservicesdifferinsomerespectsgreatlyfromtestsforothersoftwaresystems.

Consumer-drivencontracttestsareanessentialcomponentofMicroservicetests:TheytesttheexpectationsofaMicroserviceinregardstoaninterface.TherebythecorrectinterplayofMicroservicescanbeensuredwithouthavingtotesttheMicroservicestogetherinanintegrationtest.InsteadaMicroservicedefinesitsrequirementsfortheinterfaceinatest,whichtheusedMicroservicecanexecute.

Microserviceshavetoadheretocertainstandardsinregardstomonitoringorlogging.Theadherencetothesestandardscanalsobecheckedbytests.

Chapter12:OperationandContinuousDeliveryofMicroservices

OperationandContinuousDeliveryarethefocusofchapter12.EspeciallytheinfrastructureisanessentialchallengewhenintroducingMicroservices.LoggingandmonitoringhavetobeuniformlyimplementedacrossallMicroservices,otherwisetheassociatedexpendituregetstoolarge.Inaddition,thereshouldbeauniformdeployment.Finally,startingandstoppingofMicroservicesshouldbepossibleinauniformmanner–i.e.viaasimplecontrol.Fortheseareasthechapterintroducesconcretetechnologiesandapproaches.Additionally,thechapterpresentsinfrastructureswhichespeciallyfacilitatetheoperationofaMicroservicesenvironment.

Chapter13:OrganizationalEffectsofaMicroservice-basedArchitecture

Finallychapter13discusseshowMicroservicesinfluencetheorganization.Microservicesallowforasimplerdistributionoftaskstoindependentteamsandthusforparallelworkondifferentfeatures.Tothatendthetaskshavetobedistributedtotheteams,whichsubsequentlyintroducetheappropriatechangesintotheirMicroservices.However,newfeaturescanalsocompriseseveralMicroservices.Inthatcaseoneteamhastoputrequirementstoanotherteam–thisrequiresalotofcoordinationanddelaystheimplementationofnewfeatures.Therefore,itcanbebetterthatteamsalsochangeMicroservicesofotherteams.

Microservicesdividethearchitectureintomicroandmacroarchitecture:InregardstomicroarchitecturetheteamscanmaketheirowndecisionswhilethemacroarchitecturehastobedefinedforandcoordinatedacrossallMicroservices.Inareaslikeoperation,architectureandtestingindividualaspectscanbeassignedtomicroormacroarchitecture.

DevOpsasorganizationalformfitswelltoMicroservicessinceclosecooperationbetweenoperationanddevelopmentisveryuseful,especiallyfortheinfrastructureintensiveMicroservices.

Theindependentteamseachneedtheirownindependentrequirements,whichintheendhavetobederivedfromthedomain.Consequently,Microserviceshavealsoeffectsintheseareas.

Coderecyclingislikewiseanorganizationalproblem:Howdotheteamscoordinatethedifferentrequirementsforsharedcomponents?Amodelwhichisinspiredbyopensourceprojectscanhelp.

However,thereisofcoursethequestionwhetherMicroservicesarepossibleatallwithoutorganizationalchanges–afterall,theindependentteamsconstituteoneoftheessentialreasonsforintroducingMicroservices.

8ArchitectureofMicroservice-basedSystems

ThischapterdiscusseshowMicroservicesshouldbehavefromtheoutsideandhowtheentireMicroservicesystemcanbedeveloped.Chapter9willshowpossiblecommunicationtechnologies,whichareanotherimportanttechnologycomponent.Chapter10focusesonthearchitectureofindividualMicroservices.

Section8.1describeswhatthedomainarchitectureofaMicroservicesystemshouldlooklike.Section8.2presentsappropriatetoolstovisualizeandmanagethearchitecture.Section8.3showshowthearchitecturecanbeadaptedinastepwisemanner.Onlytheconstantadaptationofthesoftwarearchitectureensuresthatthesystemremainsmaintainableinthelongrunandcanbedevelopedfurther.Section8.4depictswhichgoalsandwhichapproachesareimportanttoenablefurtherdevelopment.

Subsequently,anumberofapproachesforthearchitectureofaMicroservice-basedsystemareexplained.Section8.6introducesEvent-drivenArchitecture.Thisapproachallowsforarchitecturesthatareverylooselycoupled.Section8.5discussesthespecialchallengeswhicharisewhenalegacyapplicationissupposedtobesupplementedorreplacedbyMicroservices.

Finally8.7dealswiththetopicwhichtechnicalaspectsarerelevantforthearchitectureofaMicroservice-basedsystem.Someoftheseaspectsarepresentedindepthinthefollowingsections:mechanismsforcoordinationandconfiguration(section8.8),forServiceDiscovery(section8.9),LoadBalancing(section8.10),scalability(section8.11),security(section8.12)andfinallydocumentationandmetadata(section8.13).

8.1DomainArchitectureThedomainarchitectureofaMicroservice-basedsystemdetermineswhichMicroserviceswithinthesystemshouldimplementwhichdomain.Itdefineshowtheentiredomainissplitintodifferentareas,whichareeachimplementedbyoneMicroserviceandthusoneteam.TodevisesuchanarchitecturepresentsacentralchallengewhenintroducingMicroservices.Afterall,itisanimportantmotivationfortheuseofMicroservicesthatchangestothedomaincanideallybe

implementedbyjustoneteambychangingonlyoneMicroservice–sothatlittlecoordinationandcommunicationacrossteamsisrequired.Inthisway,Microservicessupportthescalingofthesoftwaredevelopmentsinceevenlargeteamsneedlittlecommunicationandthuscanstillworkproductively.

Toreallyachievethis,acentralpointisthedesignofadomainarchitecturefortheMicroservices,inwhichchangesarereallylimitedtosingleMicroservicesandthusindividualteams.WhenthedistributionintoMicroservicesdoesnotsupportthis,changeswillrequireadditionalcoordinationandcommunication.InsuchacasetheMicroservice-basedapproachcannotbringitsadvantagesfullytobear.

StrategicDesignandDomain-DrivenDesign

Section4.3discussedalreadythedistributionofMicroservicesbasedonStrategicDesigns,whicharetakenfromDomain-drivenDesign.AcentralelementisherethattheMicroservicesaredistributedintocontexts–i.e.areaswhichpresenteachaseparatefunctionality.

OftenarchitectsdevelopaMicroservicearchitecturebasedonentitiesfromadomainmodel.AcertainMicroserviceimplementsthelogicforacertaintypeofentity.InsuchacasethereisforinstanceoneMicroserviceforcustomers,oneforitemsandonefordeliveries.ThisapproachconflictswiththeideaofBoundedContext,accordingtowhichauniformmodelingofdataisimpossible.Moreover,thisapproachisolateschangesverybadly.Whenaprocessissupposedtobemodifiedandforthisreasonentitieshavelikewisetobeadapted,thechangeisdistributedacrossdifferentMicroservices.Thus,changingtheorderprocesswillconcernalsotheentitymodelingforcustomers,itemsanddeliveries.Whenthatisthecase,thethreeMicroservicesforthedifferententitieshavetobechangedinadditiontotheMicroservicefortheorderprocess.Toavoidthis,itcanbesensibletokeepcertainpartsofthedataforcustomers,itemsanddeliveriesintheMicroservicefortheorderprocess.ThislimitschangestotheorderprocesseveninthatcasetoonlyoneMicroservicewhenthedatamodelinghastobemodified.

However,therecanstillbeservicesdedicatedtotheadministrationofcertainentities.Forinstance,itcanbenecessarytoadministrateatleastthemostfundamentaldataofacertainbusinessentityinaservice.Thus,aservicecandefinitelyadministratetheclientdata,butleavespecificclientdatasuchasabonusprogramnumbertootherMicroservices–forexampletotheMicroservicefortheorderprocess,whichlikelyhastoknowthisnumber.

ExampleOttoShop

Anexample–i.e.thearchitectureoftheOttoshop–illustratesthisconcept.Thereareontheonehandserviceslikeuser,orderorproduct,whichareratherorientedtowardsdata,andontheotherhandareasliketracking,search&navigationandpersonalization,whicharenotgearedtodata,buttofunctionalities.ExactlysuchadomaindesignshouldbeaimedatinaMicroservice-basedsystem.

Adomainarchitecturerequiresapreciseunderstandingofthedomain.ThedomainarchitecturecomprisesnotonlythedivisionofthesystemintoMicroservices,butalsothedependencies.AdependencyariseswhenadependentMicroserviceusesanotherone–forinstancebycallingtheMicroservice,byusingelementsfromtheUIoftheMicroserviceorbyreplicatingitsdata.SuchadependencymeansthatchangestoaMicroservicecaninfluencealsotheMicroservicethatisdependentonit.IftheMicroservicemodifiesforinstanceitsinterface,thedependentMicroservicehastobeadaptedtothesechanges.AlsonewrequirementsconcerningthedependentMicroservicemightnecessitatethattheotherMicroservicemodifiesitsinterface.IfthedependentMicroserviceneedsmoredatatoimplementtherequirements,theotherMicroservicehastoofferthesedataandtoadjustitsinterfaceaccordingly.

ForMicroservicessuchdependenciescausedisadvantagesbeyondsoftwarearchitecture:Afterall,Microservicescanbeimplementedbydifferentteams.Inthatcaseachangetoaninterfacenecessitatesalsocollaborationbetweenteams–this,however,islaboriousandtime-consuming.

ManagingDependencies

ManagingdependenciesbetweenMicroservicesiscentralforthearchitectureofthesystem.HavingtoomanydependencieswillprecludethatMicroservicescanbechangedinisolation–whichdisagreeswiththeaimtodevelopMicroservicesindependentlyofeachother.Here,thetwofundamentalrulesforgoodarchitectureapply:

ThereshouldbealoosecouplingbetweencomponentssuchasMicroservices.ThismeansthattheyshouldhaveonlyfewdependenciesonotherMicroservices.ThismakesiteasiertomodifythemsincechangeswillonlyaffectanindividualMicroservice.WithinacomponentsuchasaMicroservicetheconstituentpartsshouldworkcloselytogether.Thisisreferredtoashavinghighcohesion.ThisensuresthatallconstituentpartswithinaMicroservicereallybelongtogether.

Whenthesetwoprerequisitesarenotgiven,itwillbehardlypossibletochangeanindividualMicroserviceinanisolatedmanner,andchangeswillhavetobecoordinatedacrossmultipleteamsandMicroservices–thisisjustwhatMicroservice-basedarchitecturesaresupposedtoavoid.However,thisisactuallyratherasymptom:Thefundamentalproblemishowthedomain-basedsplitofthefunctionalitiesbetweentheMicroserviceswasdone–obviouslyfunctionalities,whichwouldhavebelongedtogetherinoneMicroservice,havebeendistributedacrossdifferentMicroservices.Anorderprocess,forinstance,hasalsotogenerateabill.ThesetwofunctionalitiesaresodifferentthattheyhavetobedistributedintoatleasttwoMicroservices.However,wheneachmodificationoftheorderprocessaffectsalsotheMicroservice,whichcreatesthebills,thedomain-basedmodelingisnotoptimalandshouldbeadjusted.ThefunctionalitieshavetobedistributeddifferentlytotheMicroservices,aswewillsee.

UnintendedDomain-BasedDependencies

Notonlyahighnumberofdependenciesposesaproblem.Certaindomain-baseddependenciescansimplybenonsensical.ItisforinstancesurprisingwheninanE-commercesystemtheteamresponsibleforproductsearchsuddenlyhasaninterfacewiththeMicroserviceforbilling-becausethatshouldnotbethecasefromadomain-basedpointofview.However,especiallyconcerningthedomainstherearecontinuouslysurprisesforlaypersons.Whenadependencyisnotmeaningfulfromadomain-basedpointofview,somethingregardingthefunctionalityoftheMicroserviceshastobewrong.MaybetheMicroserviceimplementsfeatureswhichbelongintootherMicroservicesfromadomain-basedperspective.Perhapsinthecontextofproductsearchascoringofthecustomerisrequired,whichisimplementedaspartofbilling.InthatcaseoneshouldconsiderwhetherthisfunctionalityisreallyimplementedintherightMicroservice.Tokeepthesystemmaintainableinthelongrun,suchdependencieshavetobequestionedand,ifnecessary,removedfromthesystem.Forinstance,thescoringcanbemovedintoannewindependentMicroserviceortransferredintoanotherexistingMicroservice.

CyclicDependencies

Cyclicdependenciescanpresentadditionalproblemsforacomprehensivearchitecture.LetusassumethattheMicroservicefortheorderprocesscallstheMicroserviceforbilling(seeFig.20).TheMicroserviceforbillingfetchesdatafromtheorderprocessMicroservice.WhentheMicroservicefortheorderprocessischanged,modificationstotheMicroserviceforbillingmightbe

necessarysincethisMicroservicefetchesdatafromtheMicroservicefortheorderprocess.Conversely,changestothebillingMicroserviceentailchangestotheorderMicroserviceasthisMicroservicecallsthebillingMicroservice.Forthisreason,cyclicdependenciesareproblematic:Thecomponentscannotbechangedanymoreinisolation,contrarytotheunderlyingaimforasplitintoseparatecomponents.IncaseofMicroservicesespeciallymuchemphasisislaidontheindependence,whichisviolatedinthiscase.Inadditiontothenecessarycoordinationofchangesitcanhappenthatthedeploymenthastobecoordinated.WhenanewversionoftheoneMicroserviceisrolledout,anewversionoftheotherMicroservicemighthavetoberolledoutaswell,iftheyhaveacyclicdependency.

Fig.20:Cyclicdependency

TheremainderofthechaptershowsapproacheswhichallowtobuildMicroservice-basedarchitecturesinsuchawaythattheyhaveasoundstructurefromadomain-basedperspective.Metricslikecohesionandloosecouplingcanconfirmthatthearchitectureisreallyfitting.InthecontextofapproacheslikeEvent-drivenArchitecture(section8.6)Microserviceshavehardlyanydirecttechnicaldependenciessincetheysendonlymessages.Whoissendingthemessagesandwhoisprocessingthem,canhardlybedeterminedfromthecodesothatthemetricslookverygood.However,fromadomain-basedperspectivethesystemcanstillbemuchtoocomplicated,sincethedomain-baseddependenciesarenotexaminedbythemetrics.Domain-baseddependenciesarisewhentwoMicroservicesexchangemessages.However,thisishardlyascertainablebycodeanalysissothatthemetricswillalwayslookquitegood.Thusmetricscanonlyhintatproblems.Byjustoptimizingthemetrics,thesymptomsareoptimized,buttheunderlyingproblemsremainunsolved.Evenworse:Evensystemswithgoodmetricscanhavearchitecturalweaknesses.Thereforethemetricloosesitvaluetodeterminethequalityofasoftwaresystem.

AspecialprobleminthecaseofMicroservicesisthatdependenciesbetweenMicroservicescanalsoinfluencetheindependentdeployment.IfaMicroservicerequiresanewversionofanotherMicroservicebecauseituses,forinstance,anewversionofaninterface,thedeploymentwillalsobedependent:TheMicroservicehastobedeployedbeforethedependentMicroservicecanbedeployed.InextremecasesthiscanresultinalargenumberofMicroservicesthathavetobecoordinatelydeployed–thisisjustwhatissupposedtobeavoided.Microservicesshouldbedeployedindependentlyofeachother.Therefore,dependenciesbetweenMicroservicescanpresentanevengreaterproblemthanwouldbethecaseformoduleswithinaDeploymentMonolith.

8.2ArchitectureManagementForadomainarchitectureitiscriticalwhichMicroservicesthereareandwhatthecommunicationrelationshipsbetweentheMicroserviceslooklike.Alsoinothersystemstherelationshipsbetweenthecomponentsareveryimportant.Whendomain-basedcomponentsaremappedonmodules,classes,Javapackages,JARfilesorDLLs,specifictoolscandeterminetherelationshipsbetweenthecomponentsandcontroltheadherencetocertainrules.Thisisachievedbyastaticcodeanalysis.

ToolsforArchitectureManagement

Ifnosucharchitecturemanagementhappens,unintendeddependencieswillrapidlycreepin.Thearchitecturewillgetmoreandmorecomplexandhardtounderstand.Onlywiththehelpofarchitecturemanagementtoolsdevelopersandarchitectswillbeabletokeeptrackofthesystem.Withinadevelopmentenvironmentdevelopersviewonlyindividualclasses.Thedependenciesbetweenclassescanonlybefoundinthesourcecodeandarenotreadilydiscernible.

Fig.21:ScreenshotoftheArchitectureManagementToolStructure101

Fig.21depictstheanalysisofaJavaprojectbythearchitecturemanagementtoolStructure101.TheimageshowsclassesandJavapackages,whichcontainclasses.ALevelizedStructureMap(LSM)presentsanoverviewofthem.ClassesandpackageswhicharefurtheratthetopoftheLSMuseclassesandpackageswhicharedepictedfurthertothebottomoftheLSM.Tosimplifythediagram,theserelationshipsarenotindicatedthere.

Cycle-FreeSoftware

Architecturesshouldbefreeofcycles.Cyclicdependenciesmeanthattwoartifactsareusingeachotherreciprocally.Inthescreenshotsuchcyclesarepresentedbydashedlines.Theyalwaysrunfrombottomtotop.Thereciprocal

relationshipinthecyclewouldberunningfromtoptobottomandisthusnotdepicted.

Apartfromcyclesalsopackageswhicharelocatedatawrongpositionarerelevant.Thereis,forinstance,apackageutilthataccordingtoitsnameissupposedtocontainhelperclasses.However,itisnotlocatedattheverybottomofthediagram.Thus,ithastohavedependenciestopackagesorclasseswhicharefurtherdown–whichshouldnotbethecase.HelperclassesshouldbeindependentfromothersystemcomponentsandthusbedepictedattheverybottomofanLSM.

ArchitecturemanagementtoolslikeStructure101cannotonlyanalyzearchitectures,butwiththistoolarchitectscanalsodefineprohibitedrelationshipsbetweenpackagesandclasses.Ifadeveloperviolatestheserules,he/shewillobtainanerrormessageandcanmodifythecode.

WiththehelpoftoolslikeStructure101thearchitectureofasystemcaneasilybevisualized.Thecompiledcodehasonlytobeloadedintothetoolforanalysis.Inthatwaythevisualizationofthearchitectureiseasilyensured.

MicroservicesandArchitectureManagement

ForMicroservicestheproblemismuchlarger:RelationshipsbetweenMicroservicesarenotaseasytodetermineastherelationshipsbetweencodecomponents.Afterall,theMicroservicescanevenbeimplementedindifferenttechnologies.Theycommunicateonlyviathenetwork.Theirrelationshipseludeanymanagementatcodelevelsincetheyappearonlyindirectlyinthecode.However,iftherelationshipsbetweenMicroservicesareunknown,architecturemanagementbecomesimpossible.

Therearedifferentpossibilitiestovisualizeandmanagethearchitecture:

EachMicroservicecanbringadocumentationalong(comparesection8.13),whichlistsallusedMicroservices.Thisdocumentationhastoadheretoapredeterminedformat,whichenablesvisualization.Thecommunicationinfrastructurecandeliverthenecessarydata.IfaServiceDiscovery(section8.9)isused,itwillbeawareofallMicroservicesandwillknowwhichMicroserviceshaveaccesstowhichotherMicroservices.ThesedatacanthenbeusedforthevisualizationoftherelationshipsbetweentheMicroservices.

IftheaccessbetweenMicroservicesissafeguardedbyafirewall,therulesofthefirewallwillatleasttellwhichMicroservicecancommunicatewithwhichotherMicroservice.Thiscanalsobeusedasbasisforavisualizationofrelationships.TrafficwithinthenetworkalsorevealswhichMicroservicescommunicatewithwhichotherMicroservices.ToolslikePacketbeat(comparesection12.3)canbeveryhelpfulhere.TheyvisualizetherelationshipsbetweenMicroservicesbasedontherecordednetworktraffic.ThedistributionintoMicroservicesshouldcorrespondtothedistributionintoteams.Iftwoteamscanhardlyworkindependentlyofeachotheranymore,thisislikelyduetoaprobleminthearchitecture:TheMicroservicesofthetwoteamsdependsostronglyoneachotherthattheycannowonlybemodifiedtogether.TheinvolvedteamsprobablyknowalreadyduetotheincreasedcommunicationrequirementwhichMicroservicesareproblematic.Toverifytheproblem,anarchitecturemanagementtooloravisualizationcanbeused.However,manuallycollectedinformationmightevenbesufficient.

Tools

Differenttoolsareusefultoevaluatedataaboutdependencies:

ThereareversionsofStructure101whichcanusecustomdatastructuresasinput.Onestillhastowriteanappropriateimporter.Structure101willthenrecognizecyclicdependenciesandcandepictthedependenciesgraphically.Gephicangeneratecomplexgraphs,whicharehelpfulforvisualizingthedependenciesbetweenMicroservices.AlsohereacustomimporterhastobewrittenforimportingthedependenciesbetweentheMicroservicesfromanappropriatesourceintoGephi.jQAssistantisbasedonthegraphdatabaseneo4j.Itcanbeextendedbyacustomimporter.Thenthedatamodelcanbecheckedaccordingtorules.

Forallthesetoolscustomdevelopmentisnecessary.ItisnotpossibletoanalyzeaMicroservice-basedarchitecturejustlikethat,thereisalwayssomeextraeffortrequired.SincecommunicationbetweenMicroservicescannotbestandardized,itwilllikelyalsointhefuturenotbepossibletoavoidcustomdevelopments.

IsArchitectureManagementImportant?

ThearchitecturemanagementofMicroservicesisimportantasitistheonlywaytopreventchaosintherelationshipsbetweentheMicroservices.Microservicesareaspecialchallengeinthisrespect:WithmoderntoolsaDeploymentMonolith

canbequiteeasilyandrapidlyanalyzed.ForMicroservice-basedarchitecturestherearenoteventoolswhichcananalyzetheentirestructureinasimplemanner.Theteamsfirsthavetocreatethenecessaryprerequisitesforananalysis.ChangingtherelationshipsbetweenMicroservicesisdifficult–asthenextsectionwillshow.Therefore,itisevenmoreimportanttoconstantlyreviewthearchitectureoftheMicroservicesinordertobeabletocorrectarisingproblemsasearlyaspossible.ItisinfavorofMicroservice-basedarchitecturesthatthearchitectureisalsoreflectedintheorganization.Problemswithcommunicationthuswillpointoutarchitecturalproblems.Evenwithoutaformalarchitecturemanagementarchitecturalproblemsoftenbecomeobvious.

Ontheotherhand,experienceswithcomplexMicroservice-basedsystemsteachthatinsuchsystemsnobodyunderstandstheentirearchitecture.However,thisisalsonotnecessarysincemostchangesarelimitedtoindividualMicroservices.Ifacertainusecaseissupposedtobechanged,whichinvolvesmultipleMicroservices,itissufficienttounderstandthisinteractionandtheinvolvedMicroservices.Aglobalunderstandingisnotabsolutelynecessary.ThisisaconsequenceoftheindependenceoftheindividualMicroservices.

ContextMap

ContextMapspresentapossibilitytogetanoverviewofthearchitectureofaMicroservice-basedsystem1.TheyillustratewhichdomainmodelsareusedbywhichMicroservicesandvisualizethusthedifferentBoundedContexts(comparesection4.3).TheBoundedContextsdonotonlyinfluencetheinternaldatapresentationintheMicroservices.AlsointhecaseofcallsbetweenMicroservicesdataareexchanged.Theyhavetobeinlinewithsometypeofmodel.However,thedatamodelsunderlyingcommunicationcanbedistinctfromtheinternalrepresentations.IfaMicroserviceforinstanceissupposedtoidentifyrecommendationsforcustomersofanE-commerceshop,complexmodelscanbeemployedinternallyforthis,whichcontainalotofinformationaboutcustomers,productsandordersandcorrelatethemincomplexways.Totheoutsidethesemodelsarepresumablymuchsimpler.

Fig.22:AnexampleforaContextMap

Fig.22showsanexampleforaContextMap:

Theregistrationregistersthebasicdataofeachcustomer.Theorderprocessalsousesthisdataformattocommunicatewithregistration.Intheorderprocessthecustomer’sbasicdataissupplementedbydatasuchasbillinganddeliveryaddresstoobtainthecustomerorderdata.ThiscorrespondstoaSharedKernel(comparesection4.3).Theorderprocesssharesthekernelofthecustomerdatawiththeregistrationprocess.ThedeliveryandthebillingMicroserviceusecustomerorderdataforcommunication,thedeliveryMicroserviceusesitevenfortheinternalrepresentationofthecustomer.Thusthismodelisakindofstandardmodelforthecommunicationofcustomerdata.Billingusesanoldmainframedatamodel.Therefore,customerorderdatafortheoutsidecommunicationaredecoupledfrominternalrepresentationbyanAnti-corruptionLayer.Thedatamodelrepresentsnamelyaverybadabstraction,whichshouldbynomeansaffectotherMicroservices.

Inthismodelitstandsoutthattheinternaldatarepresentationinregistrationpropagatestotheorderprocess.Thereitservesasbasisforthecustomerorderdata.Thismodelisusedindeliveryasinternaldatamodelaswellasinthecommunicationwithbillinganddelivery.Accordingly,themodelishardtochangesinceitisusedbysomanyservices.Ifthismodelwastobechanged,alltheseserviceswouldhavetobemodified.

However,therearealsoadvantagesassociatedwiththis.Ifalltheseserviceshadtoimplementthesamechangetothedatamodel,onlyasinglechangewouldbenecessarytoupdateallMicroservicesatonce.Nevertheless,thisdisagreeswiththeideathatchangesshouldalwaysconcernonlyasingleMicroservice.Ifthechangeremainslimitedtothemodel,thesharedmodelisadvantageoussinceallautomaticallyusethecurrentmodeling.However,whenthechangeentailschangesintheMicroservices,nowmultipleMicroserviceshavetobemodified–andcoordinatelybroughtintoproduction.ThisconflictswithanindependentdeploymentofMicroservices.

TryandExperiment

Downloadatoolfortheanalysisofarchitectures.CandidatesareStructure101,GephiorjQAssistant.Usethistooltogetanoverviewofanexistingcodebasis.Whichpossibilitiesaretheretoinsertyourowndependencygraphsintothetool?ThiswouldallowtoalsoanalyzethedependencieswithinaMicroservice-basedarchitecturewiththistool.

spigoisasimulationforthecommunicationbetweenMicroservices.ItcanbeusedtogetanimpressionofmorecomplexMicroservice-basedarchitectures.

8.3TechniquestoAdjusttheArchitectureMicroservicesarefirstofallinterestingforsoftwarewhichissubjecttomanychanges.DuetothedistributionintoMicroservicesthesystemdisaggregatesintodeploymentunits,whichcanbefurtherdevelopedindependentlyofeachother.ThiswayeachMicroservicecanimplementitsownstreamofstoriesorrequirements.Consequently,multiplechangescanbeworkedoninparallelwithoutmuchneedforcoordination.

Experienceteachesthatthearchitectureofasystemissubjecttochanges.Acertaindistributionintodomain-basedcomponentsmightseemsensibleatfirst.However,oncethearchitectgetstoknowthedomainbetter,he/shemightcometotheconclusionthatanotherdistributionwouldbebetter.Newrequirementsarehardtoimplementwiththeoldarchitecturesinceitwasdevisedbasedondifferentpremises.Thisisespeciallyfrequentforagileprocesses,whichentaillessplanningandmoreflexibility.

WhereDoesBadArchitectureComefrom?

Asystemwithabadarchitecturedoesnormallynotcomeintobeingbecausethewrongarchitecturehasbeenchosenattheoutset.Basedontheinformationavailableatthestartoftheprojectthearchitectureisoftengoodandconsistent.Theproblemisfrequentlythatthearchitectureisnotmodifiedwhentherearenewinsights,whichsuggestchangestothearchitecture.Thesymptomwasalreadymentionedinthelastsection:Newrequirementscannotberapidlyandeasilyimplementedanymore.Tothatendthearchitecturewouldhavetobechanged.Whenthispressuretointroducechangesisignoredfortoolong,thearchitecturewillnotfitatallanymoreatsomepoint.Thepermanentadjustmentandmodificationofthearchitectureareessentialprerequisitesforkeepingthearchitectureinareallysustainablestate.

ThissectionshowswhichtechniquesallowtochangetheinterplaybetweenMicroservicesinordertoadaptthearchitecturetotheentiresystem.

ChangesinMicroservices

WithinaMicroserviceadjustmentsareeasy.TheMicroservicesaresmallandmanageable.Itisnobigdealtoadjuststructures.AndifthearchitectureofanindividualMicroserviceiscompletelyinsufficient,itcanberewrittensinceitisnotverylarge.WithinaMicroserviceitisalsoeasytomovecomponentsortorestructurethecodeinanothermanner.ThetermRefactoring2denotestechniqueswhichservetoimprovethecodestructure.Manyofthemevenautomatedevelopmenttools.ThisallowsforaneasyadjustmentofthecodeofanindividualMicroservice.

ChangestotheOverallArchitecture

However,whenthesplitofthefunctionalitiesbetweentheMicroservicesisnotinlineanymorewiththerequirements,changingjustoneMicroservicewillnotbesufficient.Toachievethenecessaryadjustmentofthecompletearchitecture,

functionalitieshavetobemovedbetweenMicroservices.Therecanbedifferentreasonsforthis:

TheMicroserviceistoolargeandhastobedivided.IndicationsforthiscanbethattheMicroserviceishardlyintelligibleanymoreoreventhatlargethatasingleteamisnotsufficienttodevelopitfurther.AnotherindicationcanbethattheMicroservicecomprisesmorethanoneBoundedContext.AfunctionalitybelongsreallyintoanotherMicroservice.AnindicationforthatcanbethatcertainpartsofaMicroservicecommunicatealotwithanotherMicroservice.InthatcasetheMicroservicesdonothavealoosecouplinganymore.SuchintensecommunicationcanimplythatthecomponentbelongsintoanotherMicroservice.Likewise,alowcohesioninaMicroservicecansuggestthattheMicroserviceshouldbedivided.InthatcasethereareareasinaMicroservicewhichdependlittleoneachother.Consequently,theydonotreallyhavetobeinoneMicroservice.FunctionalitiesshouldbeusedbymultipleMicroservices.ThiscanforinstancebecomenecessarywhenaMicroservicehastouselogicfromanotherMicroserviceduetoanewfunctionality.

Therearethreemainchallenges:Microserviceshavetobesplit,codehastobemovedfromoneMicroserviceintoanother,andmultipleMicroservicesaresupposedtousethesamecode.

SharedLibraries

IftwoMicroservicesaresupposedtousecodetogether,thecodecanbetransferredintoasharedlibrary(compareFig.23).ThecodeisremovedfromtheMicroserviceandpackagedinawaythatallowsittobeusedbytheotherMicroservices.AprerequisiteforthisisthattheMicroservicesarewrittenintechnologiesthatenabletheuseofasharedlibrary.Thisisthecasewhentheyarewritteninthesamelanguageoratleastusethesameplatform–e.g.JVM(JavaVirtualMachine)or.NETCommonLanguageRuntime(CLR).

Fig.23:Sharedlibrary

AsharedlibrarymeansthattheMicroservicesbecomedependentoneachother.Workonthelibraryhastobecoordinated.FeaturesforbothMicroserviceshavetobeimplementedinthelibrary.ViathebackdooreachMicroservicenoticeschangeswhicharereallymeantfortheotherMicroservice.Thiscanresultinerrors.Therefore,theteamshavetocoordinatethedevelopmentofthelibraryandthechangestothelibrary.UndercertainconditionschangestoalibrarycannecessitatethataMicroservicehastobenewlydeployed–forinstancebecauseasecuritygaphasbeenclosedinthelibrary.

Moreover,viathelibrarytheMicroservicesmightobtainadditionalcodedependenciesto3rdpartylibraries.InaJavaJVM,3rdpartylibrariescanonlybepresentinoneversion.Whenthesharedlibraryrequiresacertainversionofa3rdpartylibrary,alsotheMicroservicehastousethisspecificversionandcannotuseadifferentone.Besides,librariesoftenhaveacertainprogrammingmodel.Inthatwaylibrariescanprovidecode,whichcanbecalled,oraframework,inwhichcustomcodecanbeintegrated,whichisthencalledbytheframework.Thelibrarymightpursueanasynchronousmodelorasynchronousmodel.SuchapproachescanfitmoreorlesswelltoarespectiveMicroservice.

MicroservicesdonotfocusonthereuseofcodesincethisleadstonewdependenciesbetweentheMicroservices.AnimportantaimofMicroservicesisindependencesothatcodereuseoftencausesmoredisadvantagesthanadvantages.

Thisisarenunciationoftheidealofcoderecycling.Developersintheninetiesstillpinnedtheirhopesoncodereuseinordertoincreaseproductivity.Movingcodeintoalibraryalsohasadvantages.Errorsandsecuritygapshavetobecorrectedonlyonce.TheMicroservicesusealwaysthecurrentlibraryversionandthusautomaticallygetthesolutionsfortheerrors.

Anotherproblemassociatedwithcodereuseisthatitrequiresadetailedunderstandingofthecode–especiallyinthecaseofframeworks,intowhichthecustomcodehastoembeditself.Thiskindofreuseisknownaswhiteboxreuse:Theinternalcodestructureshavetobeknown–notonlytheinterface.Thistypeofreuserequiresadetailedunderstandingofthecodewhichistobereusedwhichsetsahighhurdleforthereuse.

Anexamplecanbealibrarywhichfacilitatesthegenerationofmetricsforthesystemmonitoring.ItwillbeusedinthebillingMicroservice.Otherteamsalsowanttousethecode.Therefore,thecodeisextractedintoalibrary.Sinceitistechnicalcode,itisnotmodifiedincaseofdomain-basedchanges.Therefore,thelibrarydoesnotinfluencetheindependentdeploymentandtheindependentdevelopmentofdomain-basedfeatures.Thelibrarywassupposedtobeturnedintoaninternalopensourceproject(comparesection13.7).

However,totransferdomaincodeintoasharedlibraryisproblematic,asitmightintroducedeploymentdependenciesintoMicroservices.When,forinstance,themodelingofacustomerisimplementedinalibrary,theneachchangetothedatastructurehastobepassedontoallMicroservices,andtheyallhavetobenewlydeployed.Besides,auniformmodelingofadatastructurelikecustomerisanyhowhardlypossibleduetoBoundedContext.

TransferCode

AnotheroptionforchangingthearchitectureistotransfercodefromoneMicroservicetoanother.Thisissensiblewhentherebyaloosecouplingandahighcohesionoftheentiresystemcanbeensured.WhentwoMicroservicescommunicatealot,theloosecouplingisnotensured.WhenthepartoftheMicroserviceistransferredwhichcommunicatesalotwiththeotherMicroservice,thisproblemcanbesolved.

Thisapproachissimilartotheremovalintoasharedlibrary.However,thecodeisnocommondependency,whichsolvestheproblemofcouplingbetweentheMicroservices.However,itispossiblethattheMicroserviceshavetohavea

commoninterfaceinordertostillbeabletousethefunctionalitiesafterthecodetransfer.Thisisablackboxdependency:Onlytheinterfacehastobeknown,butnottheinternalcodestructures.

Inaddition,itispossibletotransferthecodeintoanotherMicroservice,whilekeepingitintheoriginalMicroservice.Thiscausesredundancies.Errorswillthenhavetobecorrectedinbothversions.Andthetwoversionscandevelopintodifferentdirections.However,ontheotherhandtheMicroservicesareindependent,especiallyinregardstodeployment.

Thetechnologicallimitationsarestillthesameasforasharedlibrary–thetwoMicroserviceshavetousesimilartechnologiesbecauseotherwisethecodecannotbetransferred.However,inapinchthecodecanalsoberewritteninanewprogramminglanguageorwithadifferentprogrammingmodel.Microservicesarenotverylarge.ThecodewhichhastoberewrittenisonlyapartofaMicroservice.Consequently,therequiredeffortismanageable.

However,thereistheproblemthatthesizeofthatMicroserviceintowhichthecodeistransferredincreases.ThusthedangerincreasesthattheMicroserviceturnsintoamonolithovertime.

Oneexample:TheMicroservicefortheorderprocessfrequentlycallsthebillingMicroserviceinordertocalculatethepriceforthedelivery.Bothservicesarewritteninthesameprogramminglanguage.ThecodeistransferredfromtheoneMicroserviceintotheother.FromadomainperspectiveitturnsoutthatthecalculationofdeliverycostsratherbelongsintotheorderprocessMicroservice.Thecodetransferisonlypossiblewhenbothservicesusethesameplatformandprogramminglanguage.Moreover,thecommunicationacrossMicroserviceshastobereplacedbylocalcommunication.

Fig.24:TransferCode

ReuseorRedundancy?

InsteadofattributingsharedcodetooneortheotherMicroservice,thecodecanalsobemaintainedinbothMicroservices.Atfirstthissoundsdangerous–afterall,thecodewillthenberedundantintwoplaces,andbugfixeshaveaccordinglytobeperformedinbothplaces.Mostofthetimedeveloperstrytoavoidsuchsituations.Anestablishedbestpracticeis“Don’tRepeatYourself”(DRY).Eachdecisionandconsequentlyallcodeshouldonlybestoredatexactlyoneplaceinthesystem.InMicroservice-basedarchitecturesredundancyhasadecisiveadvantage:ThetwoMicroservicesstayindependentofeachotherandcanbeindependentlydeployedandindependentlydevelopedfurther.InthiswaythecentralcharacteristicofMicroservicesispreserved.

Moreover,itisquestionablewhetherasystemcanbebuiltwithoutanyredundanciesatall.Especiallyinthebeginningofobject-orientationmanyprojectsinvestedalotofefforttotransfersharedcodeintosharedframeworksandlibraries.Thiswasmeanttodecreasetheexpenditureassociatedwiththecreationoftheindividualprojects.Inrealitythecodetobereusedwasoftendifficulttounderstandandthushardtouse.Aredundantimplementationinthedifferentprojectsmighthavebeenthebetteralternative.Itcanbelesslaborioustoimplementcodeseveraltimesthantodesignitinareusablemannerandtoactuallyreuseit.

Thereareofcoursesuccessfulreusesofcode:Hardlyanyprojectcangetalongnowadayswithoutopensourcelibraries.Atthislevelcodereuseistakingplaceallthetime.ThisapproachcanbeagoodtemplateforthereuseofcodebetweenMicroservices.However,thishaseffectsontheorganization.Section13.7discussesorganizationandtherebyalsocodereuseaccordingtoanopensourcemodel.

SharedService

Insteadoftransferringthecodeintoalibrary,itcanalsobemovedintoanewMicroservice(compareFig.25).TherebythetypicaladvantagesofaMicroservice-basedarchitectureensue:ThetechnologyofthenewMicroservicedoesnotmatter.AslongasitusestheuniversallydefinedcommunicationtechnologiesandcanbeoperatedliketheotherMicroservices,itsinternalstructurecanbearbitrary–tothepointofprogramminglanguage.

Fig.25:SharedMicroservice

TheuseofaMicroserviceissimplerthantheuseofalibrary.OnlytheinterfaceoftheMicroservicehastobeknown–theinternalstructuredoesnotmatter.MovingcodeintoanewservicedecreasestheaveragesizeofaMicroservice–andthereforetheintelligibilityandreplaceabilityoftheMicroservices.However,thetransferreplaceslocalcallswithcallsviathenetwork.ChangesfornewfeaturesmightnotbelimitedtooneMicroserviceanymore.

Insoftwaredevelopmentbigmodulesareoftenaproblem.SotransferringcodeintonewMicroservicescanbeagoodoptionforkeepingthemodulessmall.Besides,thenewMicroservicecanbefurtherdevelopedbytheteamwhichwasalreadyresponsiblefortheoriginalMicroservice.ThiswillfacilitatetheclosecoordinationofnewandoldMicroservicessincetherequiredcommunicationhappenswithinonlyoneteam.

ThesplitintotwoMicroserviceshasalsotheconsequencethatacalltotheMicroservice-basedsystemisnotprocessedbyjustonesingleMicroservice,butbyseveralMicroservices.TheseMicroservicescalleachother.SomeofthoseMicroserviceswillnothaveaUI,butarepurebackendservices.

Toillustratethis,letusturnagaintotheorderprocess,whichfrequentlycallsthebillingMicroserviceforcalculatingthedeliverycosts.ThecalculationofdeliverycostscanalsobeseparatedintoanMicroservicebyitself.Thisiseven

possiblewhenthebillingserviceandtheorderprocessMicroserviceusedifferentplatformsandtechnologies.However,anewinterfacewillhavetobeestablished,whichenablesthenewdeliverycostMicroservicetocommunicatewiththeremainderofthebillingservice.

SpawnaNewMicroservice

Inaddition,itisalsopossibletousepartofthecodeofacertainMicroservicetogenerateanewMicroservice(compareFig.26).TheadvantagesanddisadvantagesareidenticaltothescenarioinwhichcodeistransferredintoasharedMicroservice.However,themotivationisdifferentinthiscase:ThesizeoftheMicroservicesismeanttobereducedtoincreasetheirmaintainabilityormaybetotransfertheresponsibilityforacertainfunctionalitytoanotherteam.Here,thenewMicroserviceisnotsupposedtobesharedbymultipleotherMicroservices.

Fig.26:SpawninganewMicroservice

Forinstance,theservicefortheregistrationmighthavebecometoocomplexinthemeantime.Therefore,itisdistributedintomultipleservices,whicheachhandlecertainusergroups.Atechnicaldistributionwouldalsobepossible–forinstanceaccordingtoCQRS(comparesection10.2),EventSourcing(section10.3)orHexagonalArchitecture(section10.4).

Rewriting

Finally,anadditionalpossibilitytohandleMicroservices,whosestructuredoesnotfitanymore,istorewritethem.DuetothesmallsizeofMicroservicesandbecauseoftheiruseviadefinedinterfacesthispossibilityismuchmorefeasiblewithMicroservicesthaninthecaseofotherarchitecturalapproaches.Intheend,nottheentiresystemhastoberewritten,butjustapart.ItisalsopossibletoimplementthenewMicroserviceinadifferentprogramminglanguage,whichismaybebettersuitedforthispurpose.RewritingMicroservicescanalsobeadvantageoussincenewinsightsaboutthedomaincanleavetheirmarkonthenewimplementationinthismanner.

AGrowingNumberofMicroservices

TheexperiencewithMicroservice-basedsystemsteachesthatduringthetimeaprojectisrunningnewMicroserviceswillpermanentlybegenerated.Thisentailsahighereffortfortheinfrastructureandtheoperationofthesystem.Thenumberofdeployedserviceswillincreaseallthetime.Forclassicalprojectssuchadevelopmentisunusualandappearsthereforeproblematic.However,asthissectiondemonstrated,thegenerationofnewMicroservicesisthebestalternativefortheshareduseoflogicandfortheongoingdevelopmentofasystem.BesidesthegrowingnumberofMicroservicesensuresthattheaveragesizeofindividualMicroservicesstaysconstant.Consequently,thepositivecharacteristicsofMicroservicesarepreserved.

GeneratingnewMicroservicesshouldbeaseasyaspossibleasthisallowstopreservethepropertiesoftheMicroservicesystem.PotentialforoptimizationismainlypresentwhenitcomestoestablishingContinuousDeliverypipelines,abuildinfrastructureandtherequiredserverforthenewMicroservice.Oncethesethingsareautomated,newMicroservicescanbegeneratedcomparablyeasily.

Microservice-basedSystemsAreHardtoModify

ThissectionhasshownthatitisdifficulttoadjusttheoverallarchitectureofaMicroservice-basedsystem.NewMicroserviceshavetobegenerated.This

entailschangestotheinfrastructureandtheneedforadditionalContinuousDeliverypipelines.Sharedcodeinlibrariesisrarelyasensibleoption.

InaDeploymentMonolithsuchchangeswouldbeeasytointroduce:Oftentheintegrateddevelopmentenvironmentsevenautomatizethetransferofcodeorotherstructuralchanges.Duetoautomationthechangesarelesslaboriousandlesspronetoerrors.Besides,therearenoeffectswhatsoeverontheinfrastructureorContinuousDeliverypipelinesinthecaseofDeploymentMonoliths.

Thus,changesaredifficultattheleveloftheentiresystem–becauseitishardtotransferfunctionalitiesbetweendifferentMicroservices.Intheend,thisisexactlytheeffect,whichwastermed“strongmodularization”andlistedasadvantageinsection1.2:TocrosstheboundariesbetweenMicroservicesisdifficultsothatthearchitectureatthelevelbetweentheMicroserviceswillalsoremainintactinthelong-run.However,thisentailsaswellthatthearchitectureishardtoadjustatthislevel.

TryandExperiment

Adeveloperhaswrittenahelperclass,whichfacilitatestheinteractionwithaloggingframework,whichisalsousedbyotherteams.Itisnotverylargeandcomplex.

Shoulditbeusedbyotherteams?ShouldthehelperclassbeturnedintoalibraryoranindependentMicroserviceorshouldthecodesimplybecopied?

8.4GrowingMicroservice-basedSystemsMicroservicesprimarilyhaveadvantagesinverydynamicalenvironments.DuetotheindependentdeploymentofindividualMicroservices,teamscanworkinparallelondifferentfeatureswithoutmuchneedforcoordination.Thisisespeciallyadvantageouswhenitisunclearwhichfeaturesarereallymeaningfulandexperimentsonthemarketarenecessarytoidentifythepromisingapproaches.

PlanningArchitecture?

EspeciallyinsuchanenvironmentitishardlypossibletoplanagoodsplitofthedomainlogicintoMicroservicesrightfromthestart.Thearchitecturehastoadjusttothefacts.

ThesplitaccordingtodomainaspectsisevenmoreimportantforMicroservicesthaninthecontextofaclassicalarchitectureapproach.Thisisduetothefactthatthedomain-baseddistributioninfluencesalsothedistributionintoteamsandthereforetheindependentworkingoftheteams–thecentraladvantageofMicroservices(section8.1).Section8.2demonstratedthattoolsforarchitecturemanagementcannotreadilybeusedinMicroservice-basedarchitectures.Assection8.3discussed,itisdifficulttomodifythearchitectureofMicroservices–especiallyincomparisontoDeploymentMonoliths.Microservicesareespeciallyadvantageousindynamicenvironments–whereitisevenmoredifficulttodetermineameaningfularchitecturerightfromthestart.

Thearchitecturehastobechangeable,however,thisisdifficultduetothetechnicalfacts.ThissectionshowshowthearchitectureofaMicroservice-basedsystemcanneverthelessbemodifiedanddevelopedfurtherinastepwisemanner.

StartBig

Onepossibilitytohandlethisinherentproblemistostartoutwithseveralbigsystems,whicharesubsequentlystepbystepfragmentedintoMicroservices.Section4.1definedasupperlimitforthesizeofaMicroservicetheamountofcodewhichanindividualteamcanstillhandle.Atleastattheoutsetofaprojectitishardtoviolatethisupperlimit.Thesameistruefortheotherupperlimits:modularizationandreplaceability.

WhentheentireprojectconsistsonlyofoneorfewMicroservices,functionalitiesarestilleasytomovesincethetransferwillmostlyoccurwithinoneserviceratherthanbetweenservices.Stepbystepmorepeoplecanbemovedintotheprojectsothatadditionalteamscanbeassembled.InparallelthesystemcanbedistributedintoprogressivelymoreMicroservicestoallowtheteamstoworkindependentlyofeachother.Sucharamp-upisalsofororganizationalreasonsagoodapproachsincetheteamscanbeassembledinastepwisemanner.

Ofcourse,itwouldalsobepossibletostartoffwithaDeploymentMonolith.However,startingwithamonolithhasadecisivedisadvantage:Thereisthedangerthatdependenciesandproblemscreepintothearchitecture,whichprecludealaterdistributionintoMicroservices.Besides,inthatcasetherewillbeonlyoneContinuousDeliverypipeline.WhenthemonolithgetsdistributedintoMicroservices,theteamswillhavetogeneratenewContinuousDelivery

pipelines.Thiscanbeverylaborious,especiallywhentheContinuousDeliverypipelinefortheDeploymentMonolithhadbeengeneratedmanually.InthatcasealltheadditionalContinuousDeliverypipelineswouldlikewisehavetobemanuallygeneratedinalaboriousmanner.

WhentheprojectsstartfromthebeginningwithmultipleMicroservices,thisproblemisavoided.Thereisnomonolithwhichlaterwouldhavetobedistributed,andthereanyhowhastobeanapproachforthegenerationofnewContinuousDeliverypipelines.ThustheteamscanfromthestartworkindependentlyontheirownMicroservices.OverthecourseoftheprojecttheinitialMicroservicesaredistributedintoadditionalsmallerMicroservices.

StartBigcorrespondstotheobservationthatthenumberofMicroserviceswillincreaseoverthecourseoftheproject.InlinewiththisitissensibletostartwithfewbigMicroservicesandtospawnnewMicroservicesinastepwisemanner.TherebythemostcurrentinsightscanalwaysbeintegratedintothedistributionintoMicroservices.Itisjustnotpossibletodefinetheperfectarchitecturerightfromthestart.Insteadtheteamsshouldadaptthearchitecturestepbysteptothenewcircumstancesandinsightsandhavethecouragetoimplementthenecessarychanges.

Fig.27:StartBig:FromfewMicroservicesoriginateprogressivelymoreMicroservices.

Thisapproachresultsinauniformtechnologystack–thiswillfacilitateoperationanddeployment.FordevelopersitisalsoeasiertoworkonotherMicroservices.

StartSmall?

ItisalsoimaginabletostartwithadistributionintoalargenumberofMicroservicesandtousethisdistributionasbasisforfurtherdevelopment.However,thedistributionoftheservicesisverydifficult.“BuildingMicroservices”3providesanexamplewhereateamwassupposedtodevelopatoolforthesupportofContinuousDeliveryasaMicroservice-basedsystem.Theteamwasveryfamiliarwiththedomain,hadalreadycreatedproductsinthisareaandthuschoseanarchitecture,whichdistributedthesystemearlyonintonumerousMicroservices.However,asthenewproductwassupposedtobeofferedinthecloud,thearchitecturewas,forsubtlereasons,notsuitableinsomerespects.ToimplementchangesgotdifficultbecausemodificationsforfeatureshadtobeintroducedinmultipleMicroservices.Tosolvethisproblemandmakeiteasiertochangethesoftware,theMicroserviceswereunitedagainintoamonolith.OneyearlatertheteamdistributedthemonolithagainintoMicroservicesandtherebydecidedthefinalarchitecture.ThisexampledemonstratesthatatooearlydistributionintoMicroservicescanbeproblematic–evenifateamknowsthedomainverywell.

LimitsofTechnology

However,thisisintheendalimitationofthetechnology.IfitwereeasiertomovefunctionalitiesbetweenMicroservices(comparesection8.4),thesplitintoMicroservicescouldbecorrected.InthatcaseitwouldbemuchlessriskytostartoffwithasplitintosmallMicroservices.WhenallMicroservicesusethesametechnology,itiseasiertotransferfunctionalitiesbetweenthem.Chapter15discussestechnologiesforNanoservices,whicharebasedonanumberofcompromises,butinexchangeallowforsmallerservicesandaneasiertransferoffunctionalities.

ReplaceabilityasaQualityCriterion

AnadvantageoftheMicroserviceapproachisthereplaceabilityoftheMicroservices.ThisisonlypossiblewhentheMicroservicesdonotgrowbeyondacertainsizeandinternalcomplexity.OneaimduringthecontinueddevelopmentofMicroservicesistomaintainthereplaceabilityofMicroservices.ThenaMicroservicecanbereplacedbyadifferentimplementation–forinstanceinthecasethatitsfurtherdevelopmentisnotfeasibleanymoreduetoitsbadstructure.Inaddition,replaceabilityisameaningfulaimtopreservetheintelligibilityandmaintainabilityoftheMicroservice.IftheMicroserviceisnotreplaceable

anymore,itisprobablyalsonotintelligibleanymoreandthereforehardtodevelopanyfurther.

TheGravityofMonoliths

OneproblemisthatlargeMicroservicesattractmodificationsandnewfeatures.Theycoveralreadyseveralfeatures;therefore,itseemsagoodideatoimplementnewfeaturesalsointhisservice.ThisistrueinthecaseoftoolargeMicroservices,butevenmoresoforDeploymentMonoliths.AMicroservices-basedarchitecturecanbeaimedatreplacingamonolith.However,inthatcasethemonolithcontainssomanyfunctionalities,thatcareisneedednottointroducetoomanychangesintothemonolith.Forthispurpose,Microservicescanbecreated,eveniftheycontainhardlyanyfunctionalitiesatthebeginning.TointroducechangesandextensionstothemonolithisexactlythecourseofactionthathasrenderedthemaintenanceoftheDeploymentMonolithimpossibleandledtoitsreplacementbyMicroservices.

KeepSplitting

Asmentioned,mostarchitecturesdonothavetheproblemthattheywereoriginallyplannedinawaythatdidnotfitthetask.Inmostcasestheproblemisratherthatthearchitecturedidnotkeepupwiththechangesintheenvironment.AMicroservice-basedarchitecturealsohastobeconstantlyadjusted,otherwiseitwillatsomepointnotbeableanymoretosupporttherequirements.Totheseadjustmentsbelongamanagementofthedomain-basedsplitaswellasofthesizeoftheindividualMicroservices.ThisistheonlywaytoensurethattheadvantagesoftheMicroservice-basedarchitecturearemaintainedovertime.Sincethecodeamountofasystemusuallyincreases,thenumberofMicroserviceswillgrowaswellinordertokeeptheaveragesizeconstant.ThusanelevationofthenumberofMicroservicesisnotaproblem,butratheragoodsign.

GlobalArchitecture?

However,notonlythesizeofMicroservicescanbeaproblem.ThedependenciesoftheMicroservicescanalsocauseproblems(comparesection8.1).SuchproblemscanbesolvedmostofthetimebyadjustinganumberofMicroservices–i.e.thosewhichhaveproblematicdependencies.Thisrequiresonlycontributionsfromtheteams,whichworkontheseMicroservices.Theseteamsarealsotheonestospottheproblems,becausetheywillbeaffectedbythebadarchitectureandthegreaterneedforcoordination.Bymodifyingthearchitecture,theyareabletosolvetheseissues.Inthatcasethereisnoneedforaglobalmanagementofdependencies.Metricslikeahighnumberofdependenciesor

cyclicdependenciescanonlybeanindicationforaproblem.Whethersuchmetricsindeedindicateaproblemcanonlybesolvedbyevaluatingthemtogetherwiththeinvolvedteams.Iftheproblematiccomponentsare,forinstance,notgoingtobedevelopedanyfurtherinthefuture,itdoesnotmatterwhetherthemetricsindicateaproblem.Maybetherehaveforotherreasonsneverbeenproblemsduringdevelopment.Evenifthereisaglobalarchitecturemanagement,itcanonlyworkeffectivelyinclosecooperationwiththedifferentteams.

Don’tMisstheExitPointorHowtoAvoidtheErosionofaMicroservice(LarsGentsch)byLarsGentsch,E-PostDevelopmentGmbH

Practically,itisnottoodifficulttodevelopaMicroservice.ButhowcanyouensurethattheMicroserviceremainsaMicroserviceanddoesnotsecretlybecomeamonolith?AnexampleshallillustrateatwhichpointaservicestartstodevelopintothewrongdirectionandwhichmeasuresarenecessarytoensurethattheMicroserviceremainsaMicroservice.

Let’senvisionasmallwebapplicationforcustomerregistration.Thisscenariocanbefoundinnearlyeverywebapplication.AcustomerwantstobuyaproductinanInternetshop(Amazon,Ottoetc.)ortoregisterforavideo-on-demandportal(AmazonPrime,Netflixetc.).Asafirststepthecustomerisledthroughasmallregistrationworkflow.He/sheisaskedforhis/herusername,apassword,theemailaddressandthestreetaddress.Thisisasmallself-containedfunctionality,whichisverywellsuitedforaMicroservice.

Technologicallythisservicehasprobablyaverysimplestructure.ItconsistsoftwoorthreeHTMLpagesoranAngularJS-SinglePageApp,abitofCSS,someSpringBootandaMySQLdatabase.Mavenisusedtobuildtheapplication.

Whendataareentered,theyareconcomitantlyvalidated,transferredintothedomainmodelandputintothedatabaseforpersistence.HowcantheMicroservicegrowstep-by-stepintoamonolith?

IncorporationofNewFunctionality

Viatheshoporthevideo-on-demandportalitemsandcontentaresupposedtobedelivered,whichareonlyallowedtobeaccessedbypeoplewhoareofage.Forthispurposetheageofthecustomerhastobeverified.Onepossibilitytodothis

istostorethebirthdateoftheclienttogetherwithotherdataandtoincorporateanexternalservicefortheageverification.

Thus,thedatamodelofourservicehastobeextendedbythebirthdate.Moreinterestingistheincorporationoftheexternalservice.Toachievethis,aclientforanexternalAPIhastobewritten,whichshouldalsobeabletohandleerrorsituationslikethenon-availabilityoftheprovider.

Itishighlyprobablethattheinitiationoftheageverificationisanasynchronousprocesssothatourservicemightbeforcedtoimplementacallbackinterface.SotheMicroservicemuststoredataaboutthestateoftheprocess.Whenwastheageverificationprocessinitiated?Isitnecessarytoremindthecustomerviaemail?Wastheverificationprocesssuccessfullycompleted?

WhatisHappeningtotheMicroservicehere?

1. Thecustomerdataareextendedbythebirthdate.Thatisnotproblematic.2. Inadditiontocustomerdatatherearenowprocessdata.Attention:Here

processdataaremixedwithdomaindata.3. InadditiontotheoriginalCRUDfunctionalityoftheservice,somekindof

workflowisnowrequired.Synchronousprocessingismixedwithasynchronousprocessing.

4. Anexternalsystemisincorporated.ThetestingeffortfortheregistrationMicroserviceincreases.Anadditionalsystemanditsbehaviorhavetobesimulatedduringtest.

5. Theasynchronouscommunicationwiththeexternalsystemhasotherdemandsinregardstoscaling.WhiletheregistrationMicroservicerequiresestimatedteninstancesduetoloadandfailover,theincorporationoftheageverificationcanbeoperatedinafail-safeandstablemannerwithjusttwoinstances.Thus,differentruntimerequirementsaremixedhere.

Astheexampledemonstrates,apersesmallrequirementliketheincorporationofanageverificationcanhavetremendousconsequencesforthesizeoftheMicroservice.

CriteriaArguingforanewMicroserviceInsteadofExtendinganExistingOne:

1. Introductionofdifferentdatamodelsanddata(domainvs.processdata)2. Intermixtureofsynchronousandasynchronousdataprocessing3. Incorporationofadditionalservices

4. Differentloadscenariosfordifferentaspectswithinoneservice

Theexampleoftheregistrationservicecouldbefurtherextended:Alsotheverificationofthecustomer’sstreetaddresscouldbeperformedbyanexternalprovider.Thisiscommoninordertoensuretheexistenceofthedenotedaddress.Anotherscenarioisthemanualclearanceofacustomerincaseofdoubleregistration.Theincorporationofasolvencycheckorcustomerscoringuponregistrationislikewiseafrequentscenario.

Allthesedomain-basedaspectsbelonginprincipletothecustomerregistrationandtemptdevelopersandarchitectstointegratethecorrespondingrequirementsintotheexistingMicroservice.TherebytheMicroservicegrowsintomorethanjustoneMicroservice.

HowtoRecognizeWhethertheInitiationofanewMicroserviceShouldHaveOccurredAlready?

1. TheservicecanonlybesensiblydevelopedfurtherasMavenmultimodulprojectorGradlemultimoduleproject.

2. Testshavetobedividedintotestgroupsandhavetobeparallelizedforexecutionsincetheruntimeofthetestssurpassesfiveminutes(violationofthe“fastfeedback”principle).

3. Theconfigurationoftheserviceisgroupedbydomainwithintheconfigurationfileorthefileisdividedintosingleconfigurationfilestoimprovetheoverview.

4. Acompletebuildoftheservicetakeslongenoughtomakeacoffeebreak.Fastfeedbackcyclesarenotpossibleanymore(violationofthe“fastfeedback”principle).

Conclusion

AstheexampleoftheregistrationMicroserviceillustrates,itisabigchallengetoletaMicroserviceremainaMicroserviceandnotgiveintothetemptationtointegratenewfunctionalitiesintoanexistingMicroserviceduetotimepressure.Thisholdseventruewhenthefunctionalitiesclearlybelong,likeintheexample,tothesamedomain.

WhatcanprophylacticallybedonetopreventtheerosionofaMicroservice?Inprinciple,ithastobeassimpleaspossibletocreatenewservicesincludingtheirowndatastorage.FrameworkslikeSpringBoot,GrailsandPlaymakearelevantcontributiontothis.TheallocationofprojecttemplateslikeMavenarchetypesand

theuseofcontainerdeploymentswithDockerareadditionalmeasurestosimplifythegenerationandconfigurationofnewMicroservicesaswellastheirwayintotheproductionenvironmentasmuchaspossible.Byreducingthe“expenditure”forthesettingupofanewservicetheinhibitionthresholdfortheintroductionofanewMicroservicedecreasesclearlyandthusthetemptationtoimplementnewfunctionalitiesintoexistingservices.

8.5MicroservicesandLegacyApplicationsThetransformationofalegacyapplicationintoaMicroservice-basedarchitectureisascenariowhichisfrequentlymetwithinpractice.Completelynewdevelopmentsareratherrare,andMicroservicesfirstofallpromiseadvantagesforlongtermmaintenance.Thisisespeciallyinterestingforapplicationswhicharealreadyonthebrinkofnotbeingmaintainableanymore.BesidesthedistributionintoMicroservicesallowsforaneasierhandlingofContinuousDelivery:InsteadofdeployingandtestingamonolithinanautomatedfashionsmallMicroservicescanbedeployedandtested.Theexpenditureforthisisbyfarlower.AContinuousDeliverypipelineforaMicroserviceisnotverycomplex–however,foraDeploymentMonoliththeexpenditurecanbeverylarge.ThisadvantageissufficientformanycompaniestojustifytheeffortofmigratingtoMicroservices.

IncomparisontobuildingupcompletelynewsystemstherearesomeimportantdifferenceswhenmigratingfromaDeploymentMonolithtoMicroservices:

Foralegacysystemthefunctionalityisclearfromthedomainperspective.ThiscanbeagoodbasisforgeneratingacleandomainarchitecturefortheMicroservices.Especiallysuchacleandomain-baseddivisionisveryimportantforMicroservices.However,thereisalreadyalargeamountofcodeinexistence.Thecodeisoftenofbadquality.Therearefewtests,anddeploymenttimesareoftenmuchtoolong.Microservicesshouldremovetheseproblems.Accordingly,thechallengesinthisareaareoftensignificant.LikewiseitiswellpossiblethatthemoduleboundariesinthelegacyapplicationdonotanswertotheBoundedContextidea(comparesection4.3).InthatcasemigratingtoaMicroservice-basedarchitectureisachallengebecausethedomain-baseddesignoftheapplicationhastobechanged.

BreakingupCode?

InasimpleapproachthecodeofthelegacyapplicationcanbesplitintoseveralMicroservices.Thiscanbeproblematicwhenthelegacyapplicationdoesnothaveagooddomainarchitecture,whichisoftenthecase.ThecodecanbeespeciallyeasilysplitintoMicroserviceswhentheMicroservicesaregearedtotheexistingmodulesofthelegacyapplication.However,whenthosehaveabaddomain-basedsplit,thisbaddivisionwillbepassedontotheMicroservice-basedarchitecture.Andtheconsequencesofabaddomain-baseddesignareevenmoreprofoundinaMicroservice-basedarchitecture:Thedesigninfluencesalsothecommunicationbetweenteams.Besides,theinitialdesignishardtochangelateroninaMicroservice-basedarchitecture.

SupplementingLegacyApplications

However,itisalsopossibletogetbywithoutadivisionofthelegacyapplication.AnessentialadvantageofMicroservicesisthatthemodulesaredistributedsystems.Duetothatthemoduleboundariesareatthesametimetheboundariesofprocesseswhichcommunicateviathenetwork.Thishasadvantagesforthedistributionofalegacyapplication:Itisnotatallnecessarytoknowtheinternalstructuresofthelegacyapplicationor,basedonthat,toperformasplitintoMicroservices.InsteadMicroservicescansupplementormodifythelegacyapplicationattheinterface.ForthisitisveryhelpfulwhenthesystemtobereplacedisalreadybuiltinaSOA(section7.2).Ifthereareindividualservices,theycanbesupplementedbyMicroservices.

EnterpriseIntegrationPatterns

EnterpriseIntegrationPatterns4offeraninspirationforpossibleintegrationsoflegacyapplicationsandMicroservices:

Designing,Building,andDeployingMessagingSolutions,Addison-WesleyLongman,2003,ISBN978-0-32120-068-6

MessageRouterdescribesthatcertainmessagesgotoanotherservice.AMicroservicecanselectsomemessageswhichareprocessedthenbytheMicroserviceinsteadofbythelegacyapplication.TherebytheMicroservice-basedarchitecturedoesnothavetonewlyimplementtheentirelogicatonce,butcanatfirstselectsomeparts.AspecialrouteristheContentBasedRouter.Itdeterminesbasedonthecontentofamessagewherethemessageissupposedtobesent.ThisallowstosendspecificmessagestoaspecificMicroservice–evenifthemessagediffersonlyinonefield.

TheMessageFilteravoidsthataMicroservicereceivesuninterestingmessages.ForthatitjustfiltersallmessagesouttheMicroserviceisnotsupposedtoget.AMessageTranslatortranslatesamessageintoanotherformat.TherebytheMicroservicesarchitecturecanuseotherdataformatsanddoesnotnecessarilyhavetoemploytheformatsusedbythelegacyapplication.TheContentEnrichercansupplementdatainthemessages.IfaMicroservicerequiressupplementaryinformationinadditiontothedataofthelegacyapplication,theContentEnrichercanaddthisinformationwithoutthelegacyapplicationortheMicroservicenoticinganything.TheContentFilterachievestheopposite:CertaindataareremovedfromthemessagessothattheMicroserviceobtainsonlytheinformationwhichisrelevantforit.

Fig.28:SupplementinglegacyapplicationsbyaMessageRouter

Fig.28showsasimpleexample:AMessageRoutertakescallsandsendsthemtoaMicroserviceorthelegacysystem.ThisallowstoimplementcertainfunctionalitiesinMicroservices.Thesefunctionalitiesarealsostillpresentinthelegacysystem–butarenotusedthereanymore.InthiswaytheMicroservicesarelargelyindependentofthestructureswithinthelegacysystem.Forinstance,Microservicescanstartoffwithprocessingordersforcertaincustomersorcertainitems.Therebytheydonothavetoimplementallspecialcases.

ThepatternscanserveasinspirationhowalegacyapplicationcanbesupplementedbyMicroservices.Therearenumerousadditionalpatterns–thelistprovidesonlyaglimpseoftheentirecatalog.Likeinothercasesthepatternscanbeimplementedindifferentways:Actually,theyfocusonmessagingsystems.Butitispossibletoimplementthemwithsynchronouscommunicationmechanisms–eventhoughlesselegant.Forinstance,aRESTservicecantakeaPOSTmessage,supplementitwithadditionaldataandfinallysendittoanotherMicroservice.ThatwouldthenbeaContentEnricher.

Toimplementsuchpatterns,thesenderhastobeuncoupledfromtherecipient.Thisenablestheintegrationofadditionalstepsintotheprocessingofrequestswithoutthesendernoticinganything.Incaseofamessagingapproachthisiseasilypossibleasthesenderknowsonlyonequeueinwhichhe/sheplacesthemessages.Thesenderdoesnotknowwhofetchesthemessages.However,inthecaseofsynchronouscommunicationviaRESTorSOAPthemessageissentdirectlytotherecipient.OnlybyServiceDiscovery(comparesection8.9)thesendergetsuncoupledfromtherecipient.Thenoneservicecanbereplacedbyanotherservicewithoutneedtochangethesenders.Thisallowsforaneasierimplementationofthepatterns.WhenthelegacyapplicationissupplementedbyaContentEnricher,thisContentEnricherinsteadofthelegacyapplicationisregisteredintheServiceDiscovery,butnosenderhastobemodified.TointroduceServiceDiscoverycanthereforebeafirststeptowardsaMicroservicesarchitecture,sinceitallowstosupplementorreplaceindividualservicesofthelegacyapplicationwithouthavingtomodifytheusersofthelegacyapplication.

LimitingIntegration

EspeciallyforlegacyapplicationsitisimportantthattheMicroservicesarenottoodependentonthelegacyapplication.Oftenitisespeciallythebadstructureoftheoldapplicationwhichisthereasonwhytheapplicationissupposedtobereplacedinthefirstplace.Therefore,certaindependenciesshouldnotbeallowedatall.WhenMicroservicesdirectlyaccessthedatabaseofthelegacyapplication,theMicroservicesaredependentontheinternaldatarepresentationofthelegacyapplication.BesidesneitherthelegacyapplicationnortheMicroservicescanstillchangetheschemasincesuchchangeshavetobeimplementedinMicroservicesandlegacyapplication.TheshareduseofadatabaseinlegacyapplicationandMicroserviceshastobeavoidedonallaccounts.However,toreplicatethedataofthelegacyapplicationintoanseparatedatabaseschemaisofcoursestillanoption.

Advantages

ItisanessentialadvantageofsuchanapproachthattheMicroservicesarelargelyindependentofthearchitectureofthelegacyapplication.Andthereplacementofalegacyapplicationismostlyinitiatedbecauseitsarchitectureisnotsustainableanymore.Besides,thisallowstosupplementsystemsbyMicroservices,whichareactuallynotatallmeanttobeextended.Though,forinstance,standardsolutionsintheareaofCRM,E-commerceorERPareinternallyextensible,theirextensionbyexternalinterfacescanbeawelcomealternativesincesuchasupplementisofteneasier.Moreover,suchsystemsoftenattractfunctionalities,whichdonotreallybelongthere.AdistributionintoadifferentdeploymentunitviaaMicroserviceensuresapermanentandcleardelimitation.

IntegrationviaUIandDataReplication

However,thisapproachonlytacklestheproblemontheleveloflogicintegration.Chapter9describesanotherlevelofintegration,namelydatareplication.ThisallowsaMicroservicetoaccessalsocomprehensivedatasetsofalegacyapplicationwithgoodperformance.Itisimportantthatthereplicationdoesnothappenbasedonthedatamodelofthelegacyapplication.InthatcasethedatamodelofthelegacyapplicationwouldpracticallynotbechangeableanymoresinceitisalsousedbytheMicroservice.Anintegrationbasedontheuseofthesamedatabasewouldbeevenworse.AlsoatthelevelofUIintegrationsarepossible.Especiallylinksinwebapplicationsareattractivesincetheycauseonlyfewchangesinthelegacyapplication.

ContentManagementSystems

InthismannerContentManagementSystems(CMS),forinstance,whichoftencontainmanyfunctionalities,canbesupplementedbyMicroservices.CMScontainthedataofawebsiteandadministratethecontentsothateditorscanmodifyit.TheMicroservicestakeoverthehandlingofcertainURLs.SimilartoaMessageRouteranHTTPrequestcanbesenttoaMicroserviceinsteadoftotheCMS.OrtheMicroservicechangeselementsoftheCMSlikeinthecaseofaContentEnricherormodifiestherequestlikeinthecaseofaMessageTranslator.Lastly,theMicroservicescouldstoredataintheCMSandtherebyuseitasakindofdatabase.BesidesJavaScriptrepresentingtheUIofaMicroservicecanbedeliveredintotheCMS.InthatcasetheCMSturnsintoatoolforthedeliveryofcodeinabrowser.

Someexamplescouldbe:

AMicroservicecanimportcontentfromcertainsources.EachsourcecanhaveitsownMicroservice.Thefunctionalitywhichallowsavisitorofthewebpagee.g.tofollowanauthorcanbeimplementedinaseparateMicroservice.TheMicroservicecaneitherhaveitsownURLandbeintegratedvialinksoritmodifiesthepages,whichtheCMSdelivers.WhileanauthorisstillknownintheCMS,thereisotherlogicwhichiscompletelyseparatefromtheCMS.ThiscouldbevouchersorE-commercefunctionalities.AlsointhiscaseaMicroservicecanappropriatelysupplementthesystem.

EspeciallyinthecaseofCMSsystems,whichcreatestaticHTML,Microservices-basedapproachescanbeusefulfordynamiccontent.TheCMSmovesintothebackgroundandisonlynecessaryforcertaincontent.ThereisamonolithicdeploymentoftheCMScontentwhiletheMicroservicescanbedeployedmuchmorerapidlyandinanindependentmanner.InthiscontexttheCMSislikealegacyapplication.

Conclusion

TheintegrationsallhavetheadvantagethattheMicroservicesarenotboundtothearchitectureorthetechnologydecisionsofthelegacyapplication.ThisprovidestheMicroserviceswithadecisiveadvantagecomparedtoamodificationsofthelegacyapplication.However,themigrationawayfromthelegacyapplicationusingthisapproachposesachallengeatthelevelofarchitecture:Ineffect,Microservice-basedsystemshavetohaveawellstructureddomain-baseddesigntoenabletheimplementationoffeatureswithinoneMicroserviceandbyanindividualteam.Incaseofamigration,whichfollowstheoutlinedapproach,thiscannotalwaysbeputintoeffectsincethemigrationisinfluencedbytheinterfacesofthelegacyapplication.Therefore,thedesigncannotalwaysbeasclear-cutasdesirable.Besides,domain-basedfeatureswillstillbealsoimplementedinthelegacyapplicationuntilalargepartofthemigrationhasbeencompleted.Duringthistimethelegacyapplicationcannotbefinallyremoved.WhentheMicroservicesconfinethemselvestotransformingthemessages,themigrationcantakeaverylongtime.

NoBigBang

TheoutlinedapproachessuggestthattheexistinglegacyapplicationissupplementedinastepwisemannerbyMicroservicesorthatindividualpartsofthelegacyapplicationarereplacedbyMicroservices.Thistypeofapproachhas

theadvantagethattheriskisminimized.Replacingtheentirelegacyapplicationinonesinglestepentailsahighriskduetothesizeofthelegacyapplication.Intheend,allfunctionalitieshavetoberepresentedintheMicroservices.Inthisprocessnumerousmistakescancreepin.Inaddition,thedeploymentofMicroservicesiscomplexastheyallhavetobebroughtintoproductioninaconcertedmannerinordertoreplacethelegacyapplicationinonestep.AstepwisereplacementnearlyimposesitselfinthecaseofMicroservicessincetheycanbedeployedindependentlyandsupplementthelegacyapplication.TherebythelegacyapplicationcanbereplacedbyMicroservicesinastepwisemanner.

Legacy=Infrastructure

PartofalegacyapplicationcanalsosimplybecontinuedtobeusedasinfrastructurefortheMicroservices.Forexample,thedatabaseofthelegacyapplicationcanalsobeusedfortheMicroservices.ItisimportantthattheschemasoftheMicroservicesareseparatefromeachotherandalsofromthelegacyapplication.Afterall,theMicroservicesshouldnotbecloselycoupled.

TheuseofthedatabaseofthelegacyapplicationdoesnothavetobemandatoryfortheMicroservices.Microservicescandefinitelyalsouseothersolutions.However,theexistingdatabaseisestablishedinregardstooperationorbackup.UsingthisdatabasecanalsofortheMicroservicespresentanadvantage.Thesameistrueforotherinfrastructurecomponents.ACMSforinstancecanlikewiseserveascommoninfrastructure,towhichfunctionalitiesareaddedfromthedifferentMicroservicesandintowhichtheMicroservicescanalsodelivercontent.

OtherQualities

Thesofarintroducedmigrationapproachesfocusonenablingthedomain-baseddivisionintoMicroservicesinordertofacilitatethelong-termmaintenanceandcontinueddevelopmentofthesystem.However,Microserviceshavemanyadditionaladvantages.WhenmigratingitisimportanttounderstandwhichadvantagemotivatesthemigrationtoMicroservicesbecausedependingonthismotivationanentirelydifferentstrategymightbeadopted.Microservicesofferforinstancealsoincreasedrobustnessandresiliencesincethecommunicationwithotherservicesistakencareofaccordingly(comparesection10.5).Ifthelegacyapplicationcurrentlyhasadeficitinthisareaoradistributedarchitecturealreadyexists,whichhastobeoptimizedinrespecttothesepoints,appropriate

technologyandarchitectureapproachescanbedefinedwithoutnecessarilyrequiringthattheapplicationhastodividedintoMicroservices.

TryandExperiment

DoresearchontheremainingPatternsofEnterpriseIntegration:

CantheybemeaningfullyemployedwhendealingwithMicroservices?Inwhichcontext?Cantheyreallyonlybeimplementedwithmessagingsystems?

HiddenDependencies(OliverWehrens)byOliverWehrens,E-PostDevelopmentGmbH

Inthebeginningthereisthemonolith.Oftenitissensibleandhappensnaturallythatsoftwareiscreatedasamonolith.Thecodeisclearlyarranged,andthebusinessdomainisjustcomingintobeing.Inthatcaseitisbetterwheneverythinghasacommonbase.ThereisaUI,businesslogicandadatabase.Refactoringissimple,deploymentiseasy,andeverybodycanstillunderstandtheentirecode.

Overtimetheamountofcodegrows,anditgetshardtoseethrough.Noteverybodyknowsallpartsofthecodeanymore.Thecompilingtakeslonger,andtheunitandintegrationtestsinvitedeveloperstotakeacoffeebreak.IncaseofarelativelystablebusinessdomainandaverylargecodebasismanyprojectswillconsideratthispointtheoptiontodistributethefunctionalityintomultipleMicroservices.

Dependingonthestatusofthebusinessandtheunderstandingofthebusiness/productownersthenecessarytaskswillbecompleted.Sourcecodeisdistributed,ContinuousDeliverypipelinesarecreatedandserverprovisioned.Duringthisstepnonewfeaturesaredeveloped.Thenotnegligibleeffortisjustifiedjustbythehopethatinfuturefeatureswillbefasterandmoreindependentlycreatedbyotherteams.Developersaregoingtobeveryassuredofthis,otherstakeholdersoftenhavetobeconvincedfirst.

Inprincipleeverythinghasbeendonetoreachabetterarchitecture.Therearedifferentteamswhichhaveindependentsourcecode.Theycanbringtheirsoftwareatanytimeintoproductionandindependentofotherteams.

Almost.

TheDatabase

Everydeveloperhasamoreorlesspronouncedaffinitytothedatabase.Inmyexperiencemanydevelopersviewthedatabaseasnecessaryevil,whichissomewhatcumbersometorefactor.Oftentoolsarebeingusedwhichgeneratethedatabasestructureforthedevelopers(e.g.LiquibaseorFlywayintheJVMarea).Toolsandlibraries(ObjectRelationMapper)renderitveryeasytopersistobjects.Afewannotationslaterandthedomainissavedinthedatabase.

Allthesetoolsremovethedatabasefromthetypicaldevelopers,who“only”wanttowritetheircode.Thishassometimestheconsequencethatthereisnotmuchattentiongiventothedatabaseduringthedevelopmentprocess.Forinstance,indiceswhichwerenotcreatedwillslowdownsearchesonthedatabase.Thiswillnotshowupinatypicaltest,whichdoesnotworkwithlargedataamounts,andthusgolikethatintoproduction.

Let’stakethefictionalcaseofanonlineshoeshop.Thecompanyrequiresaservicewhichallowsuserstologin.AuserserviceiscreatedcontainingthetypicalfieldslikeID,firstname,familyname,addressandpassword.Tonowofferfittingshoestotheusers,onlyaselectionofshoesintheiractualsizeissupposedtobedisplayed.Thesizeisregisteredinthewelcomemask.Whatcouldbemoresensiblethantostorethisdatainthealreadyexistinguserservice?Everybodyissure:Theseareuser-associateddata,andthisistherightlocation.

Nowtheshoeshopexpandsandstartstoselladditionaltypesofclothing.Dresssize,collarsizeandallotherrelateddataarenowalsostoredintheuserservice.

Severalteamsareemployedinthecompany.Thecodegetsprogressivelymorecomplex.Itisthepointintime,wherethemonolithissplitintodomain-basedservices.Therefactoringinthesourcecodeworkswell,andasoonthemonolithissplitapartintomanyMicroservices.

Unfortunately,itturnsoutthatitisstillnoteasytointroducechanges.Theteaminchargeofshoeswantstoacceptdifferentcurrenciesbecauseofinternationalexpansionandhastomodifythestructureofthebillingdataincludingtheaddressformat.Duringtheupgradethedatabaseisblocked.Meanwhilenodresssizeorfavoritecolorcanbechanged.Moreover,theaddressdataareusedindifferent

standardformsofotherservicesandthuscannotbechangedwithoutcoordinationandeffort.Thereforethefeaturecannotbeimplementedpromptly.

Eventhoughthecodeiswellseparated,theteamsareindirectlycoupledviathedatabase.Torenamecolumnsintheuserservicedatabaseisnearlyimpossiblebecausenobodyknowsanymoreindetailwhoisusingwhichcolumns.Consequently,theteamsdoworkarounds.Eitherfieldswiththename‘Userattribute1’arecreated,whichthenaremappedontotherightdescriptioninthecode,orseparationsareintroducedintothedatalike‘#Color:Blue#Size:10’.Nobodyexcepttheinvolvedteamknowswhatismeantby‘Userattribute1’,anditisdifficulttogenerateanindexon‘#Color:#Size.Databasestructureandcodeareprogressivelyhardertoreadandtomaintain.

Ithastobeessentialforeverysoftwaredevelopertothinkabouthowtopersistthedata.Thismeans:notonlyaboutthedatabasestructures,butalsoaboutwherewhichdataisstored.Isthetablerespectivelydatabasetheplacewherethesedatashouldbelocated?Fromabusinessdomainperspectivedothesedatahaveconnectionstootherdata?Inordertoremainflexibleinthelongterm,itisworthwhiletocarefullyconsiderthesequestionseverytime.Typically,databasesandtablesarenotcreatedveryoften.However,theyareacomponentwhichisveryhardtomodifylater.Besides,databasesandtablesareoftentheoriginofahiddeninterdependencebetweenservices.Ingeneral,ithastoapplythatdatacanonlybeusedbyexactlyoneserviceviadirectdatabaseaccess.Allotherservices,whichwanttousethedata,mayonlyaccessitviathepublicinterfacesoftheservice.

8.6Event-drivenArchitectureMicroservicescancalleachotherinordertoimplementsharedlogic.Forexample,attheendoftheorderprocesstheMicroserviceforbillingaswellastheMicroservicefortheorderexecutioncanbecalledtocreatethebillandmakesurethattheordereditemsareindeeddelivered.

Fig.29:CallsbetweenMicroservices

Thisrequiresthattheorderprocessknowstheserviceforthebillingandforthedelivery.Ifacompletedordersnecessitatesadditionalsteps,theorderservicealsohastocalltheservicesresponsibleforthesesteps.

Event-drivenArchitecture(EDA)enablesadifferentmodeling:Whentheorderprocessinghasbeensuccessfullyfinished,theorderprocesswillsendanevent.Itisaneventemitter.ThiseventsignalstoallinterestedMicroservices(eventconsumers)thatthereisanewsuccessfulorder.Thus,oneMicroservicecannowprintabill,andanotherMicroservicecaninitiateadelivery.

Fig.30:Event-drivenArchitecture

Thisprocedurehasanumberofadvantages:

WhenotherMicroservicesarealsointerestedinorders,theycaneasilyregister.Modifyingtheorderprocessisnotnecessaryanymore.Likewise,itisimaginablethatalsootherMicroservicestriggeridenticalevents–againwithoutchangestotheorderprocess.Theprocessingofeventsistemporallyunlinked.Itcanhappenlateron.

AtthearchitecturallevelEvent-drivenArchitectureshavetheadvantagethattheyallowforaveryloosecouplingandthusfacilitatechanges.TheMicroservicesneedtoknowonlyverylittleabouteachother.However,thecouplingrequiresthatlogicisintegratedandthereforeimplementedindifferentMicroservices.TherebyasplitintoMicroservicewithUIandMicroserviceswithlogiccanarise.Thatisnotdesirable.ChangestothebusinesslogicentailoftenchangestologicandUI.ThesearethenseparateMicroservices.ThechangecannotreadilytakeplaceinonlyoneMicroserviceanymoreandthusgetsmorecomplex.

Technically,sucharchitecturescanbeimplementedwithoutalotofeffortviamessaging(comparesection9.4).MicroserviceswithinsuchanarchitecturecanveryeasilyimplementCQRS(section10.2)orEventSourcing(section10.3).

8.7TechnicalArchitectureTodefineatechnologystack,withwhichthesystemcanbebuilt,isoneofthemainpartsofanarchitecture.ForindividualMicroservicesthisislikewiseaveryimportanttask.However,thefocusofthischapteristheMicroservice-basedsysteminitsentirety.Ofcourse,acertaintechnologycanbebindinglydefinedforallMicroservices.Thishasadvantages:Inthatcasetheteamscanexchangeknowledgeaboutthetechnology.Refactoringsaresimplerbecausemembersofoneteamcaneasilyhelpoutinotherteams.

However,definingstandardtechnologiesisnotmandatory:Iftheyarenotdefined,therewillbeaplethoraofdifferenttechnologiesandframeworks.However,sincetypicallyonlyoneteamisincontactwitheachtechnology,suchanapproachcanbeacceptable.Generally,Microservice-basedarchitecturesaimforthelargestpossibleindependence.Inrespecttothetechnologystackthisindependencetranslatesintotheabilitytousedifferenttechnologystacksandtoindependentlymaketechnologydecisions.However,thisfreedomcanalsoberestricted.

TechnicalDecisionsfortheEntireSystem

Nevertheless,attheleveloftheentiresystemtherearesometechnicaldecisionstomake.However,otheraspectsaremoreimportantforthetechnicalarchitectureoftheMicroservice-basedsystemthanthetechnologystackfortheimplementation:

Asdiscussedinthelastsection,theremightbetechnologieswhichcanbeusedbyallMicroservices-forinstancesdatabasesfordatastorage.Usingthesetechnologiesdoesnotnecessarilyhavetobemandatory.However,especiallyinthecaseofpersistencetechnologies,likeforexampledatabases,backupsanddisasterrecoveryconceptshavetoexistsothatatleastthesetechnicalsolutionshavetobeobligatory.ThesameistrueforotherbasicsystemssuchasCMSforinstance,whichlikewisehavetobeusedbyallMicroservices.TheMicroserviceshavetoadheretocertainstandardsinrespecttomonitoring,logginganddeployment.Thereby,itcanbeensuredthattheplethoraofMicroservicescanstillbeoperatedinauniformmanner.WithoutsuchstandardsthisishardlypossibleanymoreincaseofalargernumberofMicroservices.Additionalaspectsrelatetoconfiguration(section8.8),ServiceDiscovery(section8.9)andsecurity(section8.12).Resilience(section10.5)andLoadBalancing(section8.10)areconceptswhichhavetobeimplementedinaMicroservice.StilltheoverallarchitecturecandemandthateachMicroservicetakesprecautionsinthisarea.AnadditionalaspectisthecommunicationoftheMicroserviceswitheachother(comparechapter9).ForthesysteminitsentiretyacommunicationinfrastructurehastobedefinedtowhichalsotheMicroservicesadhere.

Theoverallarchitecturedoesnotnecessarilyrestrictthechoiceoftechnologies.Forlogging,monitoringanddeploymentaninterfacecouldbedefined.SotherecanbeastandardaccordingtowhichallMicroserviceslogmessagesinthesamemannerandhandthemovertoacommonloginfrastructure.However,theMicroservicesdonotnecessarilyhavetousethesametechnologiesforthis.Similarly,itcanbedefinedhowdatacanbehandedtothemonitoringsystemandwhichdataarerelevantforthemonitoring.AMicroservicehastohandoverthedatatothemonitoring,butatechnologydoesnotnecessarilyhavetobeprescribed.FordeploymentacompletelyautomatedContinuousDeliverypipelinecanbedemanded,whichdeployssoftwareordepositsitintoarepositoryinacertainmanner.Whichspecifictechnologyisused,isagainaquestionforthe

developersoftherespectiveMicroservicetodecide.Practically,thereareadvantageswhenallMicroservicesemploythesametechnology.Thisreducescomplexity,andtherewillalsobemoreexperiencehowtodealwiththeemployedtechnology.However,incaseofspecificrequirements,itisstillpossibletouseadifferenttechnicalsolutionwhenforthisspecialcasetheadvantagesofsuchasolutionpredominate.ThisisanessentialadvantageofthetechnologyfreedomofMicroservice-basedarchitectures.

Sidecar

EvenifcertaintechnologiesforimplementingthedemandsonMicroservicesarerigidlydefined,itwillstillbepossibletointegrateothertechnologies.Therefore,theconceptofaSidecarcanbeveryuseful.ThisisaprocesswhichintegratesintotheMicroservices-basedarchitectureviastandardtechnologiesandoffersaninterfacewhichenablesanotherprocesstousethesefeatures.Thisprocesscanbeimplementedinanentirelydifferenttechnologysothatthetechnologyfreedomispreserved.FIg.31illustratesthisconcept:TheSidecarusesstandardtechnologiesandrendersthemaccessibleforanotherMicroserviceinanoptionaltechnology.TheSidecarisanindependentprocess,andthereforecanbecalledforinstanceviaRESTsothatMicroservicesinarbitrarytechnologiescanusetheSidecar.Section14.12showsaconcreteexampleforaSidecar.

Fig.31:ASidecarrendersallstandardtechnologiesaccessibleviaasimpleinterface.

WiththisapproachalsosuchMicroservicescanbeintegratedintothearchitecturewhosetechnologicalapproachotherwisewouldexcludetheuseofthegeneraltechnicalbasisforconfiguration,ServiceDiscoveryandsecurityastheclientcomponentisnotavailablefortheentiretechnology.

Insomeregardsthedefinitionofthetechnologystackalsoaffectsotherfields.ThedefinitionoftechnologiesacrossallMicroservicesalsoaffectstheorganizationorcanbetheproductofacertainorganization(comparechapter13).

TryandExperiment

AMicroservices-basedarchitectureissupposedtobedefined.

Whichtechnicalaspectscoulditcomprise?Whichaspectswouldyouprescribetotheteams?Why?Whichaspectsshouldtheteamsdecideontheirown?Why?

Intheend,thequestionishowmuchfreedomoneallowstheteamstohave.Therearenumerouspossibilities–rangingfromcompletefreedomuptotheprescriptionofpracticallyallaspects.However,someareascanonlybecentrallydefined–thecommunicationprotocolsforexample.Section13.3discussesinmoredetailwhoshouldmakewhichdecisionsinaMicroservice-basedproject.

8.8ConfigurationandCoordinationConfiguringMicroservice-basedsystemsislaborious.TheycompriseaplethoraofMicroservices,whichallhavetobeprovidedwiththeappropriateconfigurationparameters.

SometoolscanstoretheconfigurationvaluesandmakethemavailabletoallMicroservices.Ultimately,thesearesolutionsinkey/valuestores,whichsaveacertainvalueunderacertainkey:

Zookeeperisasimplehierarchicalsystem,whichcanbereplicatedontomultipleserversinacluster.Updatesarriveinanorderlyfashionattheclients.Thiscanalsobeusedinadistributedenvironment,forinstanceforsynchronization.Zookeeperhasaconsistentdatamodel:Allnodeshavealwaysthesamedata.TheprojectisimplementedinJavaandisunderApachelicense.etcdoriginatesfromtheDocker/CoreOSenvironment.ItoffersanHTTPinterfacewithJSONasdataformat.etcdisimplementedinGoandalsounderApachelicense.SimilartoZookeeper,etcdalsohasaconsistentdatamodelandcanbeusedfordistributedcoordination.Forinstance,etcdallowstoimplementalockinginadistributedsystem.SpringCloudConfiglikewisehasaREST-API.TheconfigurationdatacanbeprovidedbyaGitbackend.TherebySpringCloudConfigdirectlysupportsdataversioning.Thedatacanalsobeencryptedtoprotectpasswords.ThesystemiswellintegratedintotheJavaframeworkSpringandcanbeusedwithoutadditionaleffortinSpringsystemssinceSpringitselfprovidesalreadyconfigurationmechanisms.SpringCloudConfigis

writteninJavaandisunderApachelicense.SpringCloudConfigdoesnotoffersupportforsynchronizingdifferentdistributedcomponents.

ConsistencyasProblem

Someoftheconfigurationsolutionsofferconsistentdata.Thismeansthatallnodesreturnthesamedataincaseofacall.Thisisinasenseanadvantage.However,accordingtotheCAPtheoremanodecanonlyreturnaninconsistentresponseincaseofanetworkfailure–ornoneatall.Intheend,withoutanetworkconnectionthenodecannotknowwhetherothernodeshavealreadyreceivedothervalues.Ifthesystemallowsonlyconsistentresponses,therecanbenoresponseatallinthissituation.Forcertainscenariosthisishighlysensible.

Forinstance,onlyoneclientshouldexecuteacertaincodeatagiventime–forexampleinordertoinitiateapaymentexactlyonce.Thethereforenecessarylockingcanbedonebytheconfigurationsystem:Withintheconfigurationsystemthereisavariable,whichuponenteringthiscodehastobeset.Onlyinthatcasethecodemaybeexecuted.Intheend,itisbetterwhentheconfigurationsystemdoesnotreturnaresponsesothatnotbychancetwoclientsexecutethecodeinparallel.

However,forconfigurationssuchstrictrequirementsregardingconsistencyareoftennotnecessary.Maybeitisbetterwhenasystemgetsanoldvalueratherthanthatisdoesnotgetanyvalueatall.However,inthecaseofCAPdifferentcompromisesarepossible.etcdforinstancereturnsundercertainconditionsratheranincorrectresponsethannoresponseatall.

ImmutableServer

AnotherproblemassociatedwiththecentralizedstorageofconfigurationdataisthattheMicroservicesdonotonlydependonthestateoftheirownfilesystemandthecontainedfiles,butalsoonthestateoftheconfigurationserver.Therefore,aMicroservicenowcannotbeexactlyreplicatedanymore–forthisalsothestateoftheconfigurationserverisrelevant.Thismakesthereproductionoferrorsandthesearchforerrorsingeneralmoredifficult.

Inaddition,theconfigurationserverisinoppositiontotheconceptofImmutableServer.Inthisapproacheverysoftwarechangeleadstoanewinstallationofthesoftware.Ultimately,theoldserveristerminateduponanupdate,andanewserverwithanentirelynewinstallationofthesoftwareisstarted.However,incaseofanexternalconfigurationserverapartoftheconfigurationwillnotbe

presentontheserver,andthereforetheserverisafterallchangeableintheendbyadjustingtheconfiguration.However,exactlythisisnotsupposedtohappen.Topreventit,aconfigurationcanbemadeintheserveritselfinsteadoftheconfigurationserver.Inthatcaseconfigurationchangescanonlybeimplementedbyrollingoutanewserver.

Alternative:Installationtools

Theinstallationtools(discussedinsection12.4)representacompletelydifferentapproachfortheconfigurationofindividualMicroservices.Thesetoolssupportnotonlytheinstallationofsoftware,butalsotheconfiguration.Fortheconfigurationconfigurationfilescanforinstancebegenerated,whichcansubsequentlybereadbyMicroservices.TheMicroserviceitselfdoesnotnoticethecentralconfigurationsinceitreadsonlyaconfigurationfile.Still,theseapproachessupportallscenarios,whichtypicallyoccurinaMicroservices-basedarchitecture.Thus,thisapproachallowsacentralconfigurationandisnotinoppositiontoImmutableServerastheconfigurationiscompletelytransferredtotheserver.

8.9ServiceDiscoveryServiceDiscoveryensuresthatMicroservicescanfindeachother.Thisisinasenseaverysimpletask:Forinstance,aconfigurationfiledetailingtheIPaddressandtheportoftheMicroservicecanbedeliveredonallcomputers.Typicalconfigurationmanagementsystemsenabletherolloutofsuchfiles.However,thisapproachisnotsufficient:

Microservicescancomeandgo.Thisdoesnotonlyhappenduetoserverfailures,butalsobecauseofnewdeploymentsorthescalingoftheenvironmentbythestartofnewservers.ServiceDiscoveryhastobedynamic.Afixedconfigurationisnotsufficient.DuetoServiceDiscoverythecallingMicroservicesarenotsocloselycoupledanymoretothecalledMicroservice.Thishaspositiveeffectsforscaling:Aclientisnotboundtoaconcreteserverinstanceanymore,butcancontactdifferentinstances–dependingonthecurrentloadofthedifferentservers.WhenallMicroserviceshaveacommonapproachforServiceDiscovery,acentralregistryofallMicroservicesarises.Thiscanbehelpfulforanarchitectureoverview(comparesection8.2).Ormonitoringinformationcanberetrievedbyallsystems.

Insystems,whichemploymessaging,ServiceDiscoverycanbedispensable.Messagingsystemsalreadydecouplesenderandrecipient.Bothknowonlythesharedchannelviawhichtheycommunicate.However,theydonotknowtheidentityoftheircommunicationpartner.Theflexibility,whichServiceDiscoveryoffers,isthenprovidedbythedecouplingviathechannels.

ServiceDiscovery=Configuration?

InprincipleitisconceivabletoimplementServiceDiscoverybyconfigurationsolutions(comparesection8.8).Intheend,onlytheinformationwhichserviceisreachableatwhichlocationissupposedtobetransferred.However,configurationmechanismsareineffectthewrongtoolsforthis.ForaServiceDiscoveryahighavailabilityismoreimportantthanforaconfigurationserver.IntheworstcaseafailureofServiceDiscoverycanhavetheconsequencethatcommunicationbetweenMicroservicesgetsimpossible.Consequently,thetrade-offbetweenconsistencyandavailabilityisdifferentcomparedtoconfigurationsystems.Therefore,configurationsystemsshouldonlybeusedforServiceDiscoverywhentheyofferanappropriateavailability.ThiscanhaveconsequencesforthenecessaryarchitectureoftheServiceDiscoverysystem.

Technologies

TherearemanydifferenttechnologiesforServiceDiscovery:

OneexampleisDNS(DomainNameSystem).Thisprotocolensuresthatahostnamelikewww.ewolff.comcanberesolvedtoanIPaddress.DNSisanessentialcomponentoftheInternetandhasclearlyprovenitsscalabilityandavailability.DNSishierarchicallyorganized:ThereisaDNSserverwhichadministratesthe.comdomain.ThisDNS-ServerknowswhichDNSserveradministratesthesubdomainewolff.com,andtheDNSserverofthissubdomainfinallyknowstheIPaddressofwww.ewolff.com.Inthiswayanamespacecanbehierarchicallyorganized,anddifferentorganizationscanadministratedifferentpartsofthenamespace.Ifaservernamedserver.ewolff.comissupposedtobecreated,thiscanbeeasilydonebyachangeintheDNSserverofthedomainewolff.com.ThisindependencefitswelltotheconceptofMicroservices,whichespeciallyfocusonindependenceinregardstotheirarchitecture.Toensurereliabilitytherearealwaysseveralservers,whichadministrateadomain.InordertoreachscalabilityDNSsupportscachingsothatcallsdonothavetoimplementtheentireresolutionofanameviamultipleDNSservers,butcanbeservedbyacache.Thisdoesnotonlypromoteperformance,butalsoreliability.

ForServiceDiscoveryitisnotsufficienttoresolvethenameofaserverintoanIPaddress.Inaddition,therehastobeanetworkportforeachservice.Therefore,theDNShasSRVrecords.Thesecontaintheinformationonwhichcomputerandporttheserviceisreachable.Inaddition,apriorityandaweightcanbesetforacertainserver.Thesevaluescanbeusedtoselectoneoftheserversandtherebytopreferpowerfulservers.Viathisapproach,DNSoffersreliabilityandLoadBalancingontomultipleservers.AdvantagesofDNSareapartfromscalabilityalsotheavailabilityofmanydifferentimplementationsandthebroadsupportindifferentprogramminglanguages.

AfrequentlyusedimplementationforaDNSserverisBIND.BINDrunsondifferentoperatingsystems(Linux,BSD,Windows,MacOSX),iswrittenintheprogramminglanguageCandisunderanopensourcelicense.EurekaispartoftheNetflixstack.ItiswritteninJavaandisunderApachelicense.TheexampleapplicationinthisbookusesEurekaforServiceDiscovery(comparesection14.8).ForeveryserviceEurekastoresundertheservicenameahostandaport,underwhichtheserviceisavailable.EurekacanreplicatetheinformationabouttheservicesontomultipleEurekaserversinordertoincreasetheavailability.EurekaisaRESTservice.AJavalibraryfortheclientsbelongstoEureka.ViatheSidecarconcept(section8.7)thislibrarycanalsobeusedbysystems,whicharenotwritteninJava.TheSidecartakesoverthecommunicationwiththeEurekaserver,whichthenoffersServiceDiscoverytotheMicroservice.Ontheclientstheinformationfromtheservercanbeheldinacachesothatcallsarepossiblewithoutcommunicationwiththeserver.Theserverregularlycontactstheregisteredservicestodeterminewhichservicesfailed.EurekacanbeusedasbasisforLoadBalancingsinceseveralinstancescanberegisteredforoneservice.Theloadcanthenbedistributedontotheseinstances.EurekawasoriginallydesignedfortheAmazonCloud.Consulisakey/valuestoreandfitsthereforealsointotheareaofconfigurationservers(section8.8).Apartfromconsistencyitcanalsooptimizeinregardstoavailability.Clientscanregisterwiththeserverandreacttocertainevents.InadditiontoaDNSinterfaceitalsohasaHTTP/JSONinterface.Itcancheckwhetherservicesarestillavailablebyexecutinghealthchecks.ConsuliswritteninGoandisundertheMozillaopensourcelicense.Besides,Consulcancreateconfigurationfilesfromtemplates.TherebyasystemexpectingservicesinaconfigurationfilecanlikewisebeconfiguredbyConsul.

EveryMicroservice-basedarchitectureshoulduseaServiceDiscoverysystem.ItformsthebasisfortheadministrationofalargenumberofMicroservicesandforadditionalfeatureslikeLoadBalancing.IfthereisonlyasmallnumberofMicroservices,itisstillimaginabletogetalongwithoutServiceDiscovery.However,foralargesystemServiceDiscoveryisindispensable.SincethenumberofMicroservicesincreasesovertime,ServiceDiscoveryshouldbeintegratedintothearchitecturerightfromthestart.Besides,practicallyeachsystemusesatleastthenameresolutionofhosts,whichisalreadyasimpleServiceDiscovery.

8.10LoadBalancingItisoneoftheadvantagesofMicroservicesthateachindividualservicecanbeindependentlyscaled.Todistributetheloadbetweentheinstances,multipleinstances,whichsharetheload,cansimplyberegisteredinamessagingsolution(compare9.4).Theactualdistributionoftheindividualmessagesisthenperformedbythemessagingsolution.Messagescaneitherbedistributedtooneofthereceivers(Point-to-Point)ortoallreceivers(Publish/Subscribe).

REST/HTTP

IncaseofRESTandHTTPaloadbalancerhastobeused.Theloadbalancerhasthefunctiontobehavetotheoutsidelikeasingleinstance,buttodistributerequeststomultipleinstances.Besides,aloadbalancercanbeusefulduringdeployment:InstancesofthenewversionoftheMicroservicecaninitiallystartwithoutgettingload.AfterwardstheloadbalancercanbereconfiguredinawaythatthenewMicroservicesareputintooperation.Indoingsotheloadcanalsobeincreasedinastepwisemanner.Thisdecreasestheriskofasystemfailure.

Fig.32illustratestheprincipleofaproxy-basedloadbalancer:Theclientsendsitsrequeststoaloadbalancerrunningonanotherserver.Thisloadbalancerisresponsibleforsendingeachrequesttooneoftheknowninstances.Theretherequestisprocessed.

Fig.32:Proxy-basedLoadBalancer

Thisapproachiscommonforwebsitesandrelativelyeasytoimplement.Theloadbalancerretrievesinformationfromtheserviceinstancestodeterminetheloadofthedifferentinstances.Inaddition,theloadbalancercanremoveaserverfromtheLoadBalancingwhenthenodedoesnotreacttorequestsanymore.

Ontheotherhand,thisapproachhasthedisadvantagethattheentiretrafficforonekindofservicehastobedirectedviaaloadbalancer.Therebytheloadbalancercanturnintoabottleneck.Besides,afailureoftheloadbalancerresultsinthefailureofaMicroservice.

CentralLoadBalancer

AcentralloadbalancerforallMicroservicesisnotonlynottoberecommendedforthesereasonsbutalsobecauseoftheconfiguration.TheconfigurationoftheloadbalancergetsverycomplexwhenonlyoneloadbalancerisresponsibleformanyMicroservices.Besides,theconfigurationhastobecoordinatedbetweenallMicroservices.EspeciallywhendeployinganewversionofaMicroserviceamodificationoftheloadbalancercanbesensibleinordertoputthenewMicroserviceonlyafteracomprehensivetestunderload.TheneedforcoordinationbetweenMicroservicesshouldespeciallybeavoidedinregardstodeploymenttoensuretheindependentdeploymentofMicroservices.Incaseofsuchareconfigurationonehastomakesurethattheloadbalancersupportsadynamicreconfigurationandforinstancedoesnotloseinformationregarding

sessionsiftheMicroserviceusessessions.AlsoforthisreasonitcannotberecommendedtoimplementstatefulMicroservices.

ALoadBalancerproMicroservice

ThereshouldbeoneloadbalancerperMicroservice,whichdistributestheloadbetweentheinstancesoftheMicroservice.ThisallowstheindividualMicroservicestoindependentlydistributeload,anddifferentconfigurationsperMicroservicearepossible.Likewise,itissimpletoappropriatelyreconfiguretheloadbalanceruponthedeploymentofanewversion.However,incaseofafailureoftheloadbalancerstheMicroservicewillnotbeavailableanymore.

Technologies

ForLoadBalancingtherearedifferentapproaches:

TheApachehttpdwebserversupportsLoadBalancingwiththeextensionmod_proxy_balancer.ThewebservernginxcanlikewisebeconfiguredinawaythatitsupportsLoadBalancing.Touseawebserverasloadbalancerhastheadvantagethatitcanalsodeliverstaticwebsites,CSSandimages.Besides,thenumberoftechnologieswillbereduced.HAProxyisasolutionforLoadBalancingandhighavailability.ItdoesnotsupportHTTP,butallTCP-basedprotocols.Cloudprovidersfrequentlyalsoofferloadbalancer.AmazonforinstanceoffersElasticLoadBalancing.ThiscanbecombinedwithAutoScalingsothathigherloadsautomaticallytriggerthestartofnewinstances,andtherebytheapplicationautomaticallyscaleswithload.

ServiceDiscovery

AnotherpossibilityforLoadBalancingisServiceDiscovery(Fig.33)(comparesection8.9).WhentheServiceDiscoveryreturnsdifferentnodesforaservice,theloadcanbedistributedacrossseveralnodes.However,thisapproachallowsredirectingtoanothernodeonlyinthecasethatanewServiceDiscoveryisperformed.ThismakesitdifficulttoachieveafinegranularLoadBalancing.Foranewnodeitwillthereforetakesometimeuntilitgetsasufficientshareofload.Finally,thefailureofanodeishardtocorrectbecauseanewServiceDiscoverywouldbenecessaryforthat.ItisusefulthatincaseofDNSitcanbestatedforasetofdatahowlongthedataisvalid(time-to-live).AfterwardstheServiceDiscoveryhastoberunagain.ThisallowsasimpleLoadBalancingviaDNS

solutionsandalsowithConsul.However,unfortunatelythistime-to-liveisoftennotcompletelycorrectlyimplemented.

Fig.33:LoadBalancingwithServiceDiscovery

LoadBalancingwithServiceDiscoveryissimplebecauseServiceDiscoveryanyhowhastobepresentinaMicroservice-basedsystem.Therefore,theLoadBalancingdoesnotintroduceadditionalsoftwarecomponents.Besidesavoidingacentralloadbalancerhasthepositiveeffectthatthereisnobottleneckandnocentralcomponentwhosefailurewouldhavetremendousconsequences.

Client-basedLoadBalancing

Theclientitselfcanalsousealoadbalancer.TheloadbalancercanbeimplementedasapartofthecodeoftheMicroserviceoritcancomeasaproxy-basedloadbalancersuchasnginxorApachehttpd,whichrunsonthesamecomputerastheMicroservice.Inthatcasethereisnobottleneckbecauseeachclienthasitsownloadbalancer,andthefailureofanindividualloadbalancerhashardlyconsequences.However,configurationchangeshavetobepassedontoallloadbalancers,whichcancausequitealotofnetworktrafficandload.

Fig.34:Client-basedLoadBalancing

Ribbonisanimplementationofclient-basedLoadBalancing.ItisalibrarywhichiswritteninJavaandcanuseEurekatofindserviceinstances.Alternatively,alistofserverscanbehandedovertoRibbon.RibbonimplementsdifferentalgorithmsforLoadBalancing.EspeciallywhenusingitincombinationwithEureka,theindividualloadbalancerdoesnotneedtobeconfiguredanymore.BecauseoftheSidecarconceptRibboncanalsobeusedbyMicroserviceswhicharenotimplementedinJava.TheexamplesystemusesRibbon(comparesection14.11).

Consuloffersthepossibilitytodefineatemplateforconfigurationfilesofloadbalancers.ThisallowstofeedtheloadbalancerconfigurationwithdatafromServiceDiscovery.Aclient-basedLoadBalancingcanbeimplementedbydefiningatemplateforeachclient,intowhichConsulwritesallserviceinstances.Thisprocesscanberegularlyrepeated.Inthismanneracentralsystem

configurationisagainpossibleandaclient-basedLoadBalancingrelativelysimpletoimplement.

LoadBalancingandArchitecture

ItishardlysensibletousemorethanonekindofLoadBalancingwithinasingleMicroservice-basedsystem.Therefore,thisdecisionshouldbemadeoncefortheentiresystem.LoadBalancingandServiceDiscoveryhaveanumberofcontactpoints.ServiceDiscoveryknowsallserviceinstances;LoadBalancingdistributestheloadsbetweentheinstances.Bothtechnologieshavetoworktogether.Thusthetechnologydecisionsinthisareawillinfluenceeachother.

8.11ScalabilityTobeabletocopewithhighloads,Microserviceshavetoscale.Scalabilitymeansthatasystemcanprocessmoreloadwhenitgetsmoreresources.

Therearetwodifferentkindsofscalability:

Horizontalscalabilitymeansthatmoreresourcesareused,whicheachprocesspartoftheload,i.e.thenumberofresourcesincreases.

Verticalscalabilitymeansthatmorepowerfulresourcesareemployedtohandleahigherload.Here,anindividualresourcewillprocessmoreload,whilethenumberofresourcesstaysconstant.

Fig.35:Horizontalandverticalscaling

Horizontalscalabilityisoftenthebetterchoicesincethelimitforthepossiblenumberofresourcesandthereforethelimitforthescalabilityisveryhigh.Besides,itischeapertobuymoreresourcesthanmorepowerfulones.Onefastcomputerisoftenmoreexpensivethanmanyslowones.

Scaling,MicroservicesandLoadBalancing

MicroservicesemploymostlyhorizontalscalingwheretheloadisdistributedacrossseveralMicroserviceinstancesviaLoadBalancing.TheMicroservicesthemselveshavetobestatelessforthis.Moreprecisely:Theyshouldnothaveanystate,whichisspecificforanindividualuser,becausethentheloadcanonlybedistributedtonodes,whichhavetherespectivestate.Thestateforausercanbestoredinadatabaseoralternativelybeputintoanexternalstorage(e.g.In-Memory-Store),whichcanbeaccessedbyallMicroservices.

DynamicScaling

Scalabilitymeansonlythattheloadcanbedistributedtomultiplenodes.Howthesystemreallyreactstotheload,isnotdefined.Intheenditismoreimportantthatthesystemreallyadaptstoanincreasingload.Forthatitisnecessarythat,dependingontheload,aMicroservicestartsnewinstances,ontowhichtheloadcanbedistributed.ThisallowstheMicroservicetoalsocopewithhighloads.Thisprocesshastobeautomatedasmanualprocesseswouldbetoolaborious.

TherearedifferentplacesintheContinuousDeploymentpipeline(chapter12)whereitisnecessarytostartaMicroservicetotesttheservices.ForthatasuitabledeploymentsystemsuchasCheforPuppetcanbeused.Alternatively,anewvirtualmachineoranewDockercontainerwiththeMicroserviceissimplystarted.Thismechanismcanalsobeusedfordynamicscaling.ItonlyhasadditionallytoregisterthenewinstanceswiththeLoadBalancing.However,theinstanceshouldbeabletohandletheproductionloadrightfromthestart:Therefore,thecachesshouldforinstancealreadybefilledwithdata.

DynamicscalingisespeciallysimplewithServiceDiscovery:TheMicroservicehastoregisterwiththeServiceDiscovery.TheServiceDiscoverycanconfiguretheloadbalancerinawaythatitdistributesloadtothenewinstance.

Thedynamicscalinghastobeperformedbasedonametric.WhentheresponsetimeofaMicroserviceistoolongorthenumberofrequestsisveryhigh,newinstanceshavetobestarted.Thedynamicscalingcanbepartofamonitoring(comparesection12.3)sincethemonitoringshouldenablethereactionto

extraordinarymetricvalues.Mostmonitoringinfrastructuresofferthepossibilitytoreacttometricvaluesbycallingascript.ThescriptcanstartadditionalinstancesoftheMicroservice.Thisisfairlyeasytodowithmostcloudandvirtualizationenvironments.EnvironmentsliketheAmazonCloudoffersuitablesolutionsforautomaticscaling,whichworkinasimilarmanner.However,ahome-grownsolutionisnotverycomplicatedsincethescriptsrunanyhowonlyeveryfewminutessothatfailuresaretolerable,atleastforalimitedtime.Sincethescriptsarepartofthemonitoring,theywillhaveasimilaravailabilitylikethemonitoringandshouldthereforebesufficientlyavailable.

Especiallyinthecaseofcloudinfrastructuresitisimportanttoshuttheinstancesdownagainincaseoflowloadbecauseeveryrunninginstancecostsmoneyinacloud.Alsoherescriptscanserveasreactiontocertainmetricvalues.

Microservices:AdvantagesforScaling

Inregardstoscaling,Microserviceshavefirstofalltheadvantagethattheycanbescaledindependentlyofeachother.IncaseofaDeploymentMonolithonlytheentiremonolithcanbestartedasmoreinstances.Thefinegranularscalingdoesnotappeartobeanespeciallystrikingadvantageatfirstglance,however,torunanentireE-commerceshopinmanyinstancesjusttospeedupthesearch,causeshighexpenditures:Alotofhardwareisneeded,acomplexinfrastructurehastobebuiltup,andsystempartsareheldavailable,whicharenotusedatall.Thesesystempartsrenderthedeploymentandmonitoringmorecomplex.Thepossibilitiesfordynamicscalingdependcriticallyonthesizeoftheservicesandonthespeedwithwhichnewinstancescanbestarted.InthisareaMicroservicespossessclearadvantages.

InmostcasesMicroserviceshavealreadyanautomateddeployment,whichisalsoveryeasytoimplement.Inaddition,thereisalreadyamonitoring.WithoutautomateddeploymentandmonitoringaMicroservice-basedsystemcanhardlybeoperated.Ifthereisinadditionloadbalancing,thenitisonlyascriptwhichisstillmissingforautomatedscaling.ThereforeMicroservicesrepresentanexcellentbasisfordynamicscaling.

Sharding

Shardingmeansthattheadministrateddataamountisdividedandthateachinstancegetstheresponsibilityforpartofthedata.Forexample,aninstancecanberesponsibleforthecustomersA-Eorforallcustomerswhosecustomernumberendswiththenumber9.Shardingisavariationofhorizontalscaling:More

serversareused.However,notallserversareequal,buteveryserverisresponsibleforadifferentsubsetofthedataset.IncaseofMicroservicesthistypeofscalingiseasytoimplementsincethedomainisanyhowdistributedacrossmultipleMicroservices.EveryMicroservicecanthensharditsdataandviathisshardingscalehorizontally.ADeploymentMonolithishardlyscalableinthismannerbecauseithandlesallthedata.WhentheDeploymentMonolithadministratescustomersanditems,itcanhardlybeshardedforbothtypesofdata.InordertoreallyimplementshardingtheLoadBalancerhasofcoursetodistributetheloadappropriatelytotheshards.

Scalability,ThroughputandResponseTimes

Scalabilitymeansthatmoreloadcanbeprocessedbymoreresources.Thethroughputincreases–i.e.thenumberofprocessedrequestsperunitoftime.However,theresponsetimestaysconstantinthebestcase–dependingoncircumstancesitmightrise,butnottosuchanextentthatthesystemcauseserrorsorgetstooslowfortheuser.

Whenfasterresponsetimesarerequired,horizontalscalingdoesnothelp.However,therearesomeapproachestooptimizetheresponsetimeofMicroservices:

TheMicroservicescanbedeployedonfastercomputers.Thisisverticalscaling.ThentheMicroservicescanprocesstheindividualrequestsmorerapidly.Becauseoftheautomateddeploymentverticalscalingisrelativelysimpletoimplement.Theservicehasonlytobedeployedonfasterhardware.Callsviathenetworkhavealonglatency.Therefore,apossibleoptimizationcanbetoforegosuchcalls.Insteadcachescanbeused,orthedatacanbereplicated.Cachescanoftenveryeasilybeintegratedintotheexistingcommunication.ForREST,forinstance,asimpleHTTPcacheissufficient.IfthedomainarchitectureofMicroservicesiswelldesigned,arequestshouldonlybeprocessedinoneMicroservicesothatnocommunicationviathenetworkisnecessary.IncaseofagooddomainarchitecturethelogicforprocessingarequestisimplementedinoneMicroservicesothatchangestothelogiconlyrequirechangestooneMicroservice.InthatcaseMicroservicesdonothavelongerresponsetimesthanDeploymentMonoliths.InregardstoanoptimizationofresponsetimesMicroserviceshavethedisadvantagethattheircommunicationviathenetworkcausesratherlongerresponsetimes.However,therearemeanstocounteractthiseffect.

8.12SecurityInaMicroservice-basedarchitectureeachMicroservicehastoknowwhichusertriggeredthecurrentcallandwantstousethesystem.Therefore,auniformsecurityarchitecturehastoexist:Afterall,Microservicescanworktogetherforarequest,andforeachpartoftheprocessingoftherequestanotherMicroservicemightberesponsible.Thusthesecuritystructurehastobedefinedattheleveloftheentiresystem.Thisistheonlywaytoensurethattheaccessofauserisuniformlytreatedintheentiresysteminregardstosecurity.

Securitycomprisestwoessentialaspects:Authenticationandauthorization.Authenticationistheprocess,whichvalidatestheidentityoftheuser.Authorizationdenotesthedecisionwhetheracertainuserisallowedtoexecuteacertainaction.Bothprocessesareindependentofeachother:Thevalidationoftheuseridentityinthecontextofauthenticationisnotdirectlyrelatedtoauthorization.

SecurityandMicroservices

InaMicroservice-basedarchitecturetheindividualMicroservicesshouldnotperformauthentication.ItdoesnotmakemuchsenseforeachMicroservicetovalidateusernameandpassword.Forauthenticationacentralserverhastobeused.Forauthorizationaninterplayisnecessary:Oftenthereareusergroupsorroleswhichhavetobecentrallyadministered.However,whetheracertainusergrouporroleisallowedtousecertainfeaturesofaMicroserviceshouldbedecidedbytheconcernedMicroservice.TherebychangestotheauthorizationofacertainMicroservicecanbelimitedtotheimplementationofthisMicroservice.

OAuth2

OnepossiblesolutionforthischallengeisOAuth2.Thisprotocolisalsowidelyusedintheinternet.Google,Microsoft,Twitter,XINGorYahooalloffersupportforthisprotocol.

Fig.36:TheOAuth2protocol

Fig.36showstheworkflowoftheOAuth2protocolasdefinedbythestandard:

1. TheclientinquiresoftheResourceOwnerwhetheritmightexecuteacertainaction.Forexample,theapplicationcanrequestaccesstotheprofileor

certaindatainasocialnetworkwhichtheResourceOwnerstoredthere.TheResourceOwnerisusuallytheuserofthesystem.

2. IftheResourceOwnergrantstheclientaccess,theclientreceivesarespectiveresponsefromtheResourceOwner.

3. TheclientusestheresponseoftheResourceOwnertoputarequesttotheauthorizationserver.Intheexampletheauthorizationserverwouldbelocatedinthesocialnetwork.

4. Theauthorizationserverreturnsanaccesstoken.5. WiththisaccesstokentheclientcannowcallaResourceServerandthere

obtainthenecessaryinformation.ForthecallthetokencanforinstancebeputintoanHTTPheader.

6. TheResourceServeranswerstherequests.

PossibleAuthorizationGrants

Theinteractionwiththeauthorizationservercanworkindifferentways:

IncaseofthePasswordGranttheclientshowsanHTMLformtotheuserinstep1.TheResourceOwnercanenterusernameandpassword.Instep3thisinformationisusedbytheclienttoobtaintheaccesstokenfromtheauthorizationserverviaanHTTPPOST.Thisapproachhasthedisadvantagethattheclientprocessesusernameandpassword.Theclientcanbeinsecurelyimplemented,andthenthesedataareendangered.IncaseoftheAuthorizationGranttheclientdirectstheuserinstep1toawebpage,whichtheauthorizationserverdisplays.Theretheusercanchoosewhetherhe/shepermitstheaccess.Ifthatisthecase,theclientwillobtaininstep2anauthorizationcodeviaanHTTP-URL.InthiswaytheauthorizationservercanbesurethatthecorrectclientobtainsthecodesincetheserverchoosestheURL.Instep3theclientcanthengeneratetheaccesstokenwiththisauthorizationcodeviaanHTTPPOST.Theapproachismainlyimplementedbytheauthorizationserverandthusveryeasytousebyaclient.Inthisscenariotheclientwouldbeawebapplicationontheserver:ItwillobtainthecodefromtheauthorizationserverandistheonlyoneabletoturnitviatheHTTPPOSTintoanaccesstoken.IncaseofImplicittheprocedureresemblestheAuthorizationGrant.Aftertheredirecttotheauthorizationserverinstep1theclientdirectlygetsanaccesstokenviaanHTTPredirect.Thisallowsthebrowseroramobileapplicationtoimmediatelyreadouttheaccesstoken.Step3and4areomitted.However,heretheaccesstokenisnotaswellprotectedagainstattackssincetheauthorizationserverdoesnotdirectlysendittotheclient.

ThisapproachissensiblewhenJavaScriptcodeontheclientoramobileapplicationissupposedtousetheaccesstoken.IncaseofClientCredentialstheclientusesinstep1acredential,whichtheclientknows,toobtaintheaccesstokenfromtheauthorizationserver.TherebytheclientcanaccessthedatawithoutadditionalinformationfromtheResourceOwner.Forexample,astatisticssoftwarecouldreadoutandanalyzecustomerdatainthismanner.

Viatheaccesstokentheclientcanaccessresources.Theaccesstokenhastobeprotected:Whenunauthorizedpeopleobtainaccesstotheaccesstoken,theycantherebytriggerallactions,whichtheResourceOwnercanalsotrigger.Withinthetokenitselfsomeinformationcanbeencoded.Forinstance,inadditiontotherealnameoftheResourceOwnerthetokencanalsocontaininformation,whichassignscertainrightstotheuserorthemembershiptocertainusergroups.

JSONWebToken(JWT)

JSONWebToken(JWT)isastandardfortheinformation,whichiscontainedinanaccesstoken.JSONservesasdatastructure.ForthevalidationoftheaccesstokenadigitalsignaturewithJWS(JSONWebSignature)canbeused.LikewisetheaccesstokencanbeencryptedwithJSONWebEncryption(JWE).Theaccesstokencancontaininformationabouttheissueroftheaccesstoken,theResourceOwner,thevalidityintervalortheaddresseeoftheaccesstoken.Individualdatacanalsobecontainedintheaccesstoken.TheaccesstokenisoptimizedforuseasHTTPheaderbyanencodingoftheJSONwithBASE64.Theseheadersarenormallysubjecttosizerestrictions.

OAuth2,JWTandMicroservices

InaMicroservice-basedarchitecturetheusercaninitiallyauthenticateviaoneoftheOAuth2approaches.AfterwardstheusercanusethewebpageofaMicroserviceorcallaMicroserviceviaREST.WitheachfurthercalleveryMicroservicecanhandovertheaccesstokentootherMicroservices.BasedontheaccesstokentheMicroservicescandecidewhetheracertainaccessisgrantedornot.Forthatthevalidityofthetokencanfirstbechecked.IncaseofJWTthetokenonlyhastobedecryptedandthesignatureoftheauthorizationserverhastobechecked.Subsequently,itcanbedecidedbasedontheinformationofthetokenwhethertheusermayusetheMicroserviceashe/sheintends.Informationfromthetokencanbeusedforthat.Forinstance,itispossibletostoretheaffiliationwithcertainusergroupsdirectlyinthetoken.

Itisimportantthatitisnotdefinedintheaccesstoken,whichaccesstowhichMicroserviceisallowed.Theaccesstokenisissuedbytheauthorizationserver.Iftheinformationabouttheaccesswasavailableintheauthorizationserver,everymodificationoftheaccessrightswouldhavetooccurintheauthorizationserver–andnotintheMicroservices.ThislimitsthechangeabilityoftheMicroservicessincemodificationstotheaccessrightswouldrequirechangesoftheauthorizationserverascentralcomponent.TheauthorizationservershouldonlyadministertheassignmenttousergroupsandtheMicroservicesshouldthenalloworprohibitaccessbasedonsuchinformationfromthetoken.

Technologies

Inprinciple,othertechnicalapproachesthanOAuth2couldalsobeusedaslongastheyemployacentralserverforauthorizationanduseatokenforregulatingtheaccesstoindividualMicroservices.OneexampleisKerberos,whichhasarelativelylonghistory.However,itisnotaswelltunedtoRESTlikeOAuth2.OtheralternativesareSAMLandSAML2.0.Theydefineaprotocol,whichusesXMLandHTTPtoperformauthorizationandauthentication.

Finally,signedcookiescanbecreatedbyahome-grownsecurityservice.Viaacryptographicsignatureitcanbedeterminedwhetherthecookiehasreallybeenissuedbythesystem.Thecookiecanthencontaintherightsorgroupsoftheuser.Microservicescanexaminethecookieandrestricttheaccessifnecessary.Thereistheriskthatthecookieisstolen.However,forthattooccurthebrowserhastobecompromisedorthecookiehastobetransferredviaanonencryptedconnection.Thisisoftenacceptableasrisk.

WithatokenapproachitispossiblethatMicroservicesdonothavetohandletheauthorizationofthecaller,butstillcanrestricttheaccesstocertainusergroupsorroles.

TherearegoodreasonsfortheuseofOAuth2:

Therearenumerouslibrariesforpracticallyallestablishedprogramminglanguages,whichimplementOAuth2oranOAuth2server.ThedecisionforOAuth2hardlyrestrictsthetechnologychoiceforMicroservices.BetweentheMicroservicesonlytheaccesstokenstillhastobetransferred.ThiscanoccurinastandardizedmannerviaanHTTPheaderwhenRESTisused.Incaseofdifferentcommunicationprotocolssimilarmechanismscanbeexploited.AlsointhisareaOAuth2hardlylimitsthetechnologychoice.

ViaJWTinformationcanbeplacedintothetoken,whichtheauthorizationservercommunicatestotheMicroservicesinorderforthemtoalloworprohibitaccess.Therefore,alsointhisareatheinterplaybetweentheindividualMicroserviceandthesharedinfrastructureissimpletoimplement–withstandards,whicharewidelysupported.

SpringCloudSecurityoffersespeciallyforJava-basedMicroservicesagoodbasisforimplementingOAuth2systems.

AdditionalSecurityMeasures

OAuth2solvesfirstofalltheproblemofauthenticationandauthorization–primarilyforhumanusers.ThereareadditionalmeasuresforsecuringaMicroservice-basedsystem:

ThecommunicationbetweentheMicroservicescanbeprotectedbySSL/TLSagainstwiretapping.Allcommunicationisthenencrypted.InfrastructureslikeRESTormessagingsystemsmostlysupportsuchprotocols.ApartfromauthenticationwithOAuth2certificatescanbeusedtoauthenticateclients.Acertificateauthoritycreatesthecertificates.Theycanbeusedtoverifydigitalsignatures.Thismakesitpossibletoauthenticateaclientbasedonitsdigitalsignature.SinceSSL/TLSsupportscertificates,atleastatthisleveltheuseofcertificatesandauthenticationviacertificatesispossible.APIkeysrepresentasimilarconcept.Theyaregiventoexternalclientstoenablethemtousethesystem.ViatheAPIkeytheexternalclientsauthenticatethemselvesandcanobtaintheappropriaterights.IncaseofOAuth2thiscanbeimplementedwithClientCredential.FirewallscanbeusedtoprotectthecommunicationbetweenMicroservices.Normallyfirewallssecureasystemagainstunauthorizedaccessfromoutside.AfirewallforthecommunicationbetweentheMicroservicespreventsthatallMicroservicesareendangeredifanindividualMicroservicehasbeensuccessfullytakenover.InthiswaytheintrusioncanberestrictedtooneMicroservice.Finally,thereshouldbeanintrusiondetectiontodetectunauthorizedaccesstothesystem.Thistopiciscloselyrelatedtomonitoring.Themonitoringsystemcanalsobeusedtotriggeranappropriatealarmincaseofanintrusion.Datensparsamkeitisalsoaninterestingconcept.Itisderivedfromthedatasecurityfieldandstatesthatonlythosedataaretobesaved,whichare

absolutelynecessary.Formasecurityperspectivethisresultsintheadvantagethatcollectinglotsofdataisavoided.Thismakesthesystemlessattractiveforattacks,andinadditiontheconsequencesofasecuritybreachwillnotbeasbad.

HashicorpVault

HashicorpVaultisatool,whichsolvesmanyproblemsintheareaofMicroservicesecurity.Itoffersthefollowingfeatures:

Secretslikepasswords,APIKeys,keysforencryptionorcertificatescanbesaved.Thiscanbeusefultoallowuserstoadministratetheirsecrets.InadditionalsoMicroservicescanbeequippedwithcertificatesinsuchamannerastoprotecttheircommunicationwitheachotherorwithexternalservers.Secretsaregivenviaaleasetoservices.Besides,theycanbeequippedwithanaccesscontrol.Thishelpstolimittheproblemincaseofacompromisedservice.Secretscanforinstancealsobedeclaredinvalid.DatacanbeimmediatelyencryptedordecryptedwiththekeyswithouttheMicroservicesthemselveshavingtosavethesekeys.Accessismadetraceablebyanaudit.Thisallowstotracewhogotwhichsecretandatwhichtime.InthebackgroundVaultcanuseHSMs,SQLdatabasesorAmazonIAMtostoresecrets.Inaddition,itcanforinstancealsogeneratenewaccesskeysfortheAmazonCloudbyitself.

InthismannerVaulttakescareofhandlingkeysandtherebyrelievesMicroservicesofthistask.Itisabigchallengetoreallyhandlekeyssecurely.Itisdifficulttoimplementsomethinglikethatinareallysecuremanner.

AdditionalSecurityGoals

Inregardstoasoftwarearchitecturesecuritycomesinverydifferentshapes.ApproacheslikeOAuth2onlyhelptoachieveconfidentiality.Theypreventthatdataisaccessibleforunauthorizedusers.However,eventhisconfidentialityisnotentirelysafeguardedbyOAuth2onitsown:Thecommunicationinthenetworklikewisehastobeprotectedagainstwiretapping–forinstanceviaHTTPSorotherkindsofencryption.

Additionalsecurityaspectsare:

Integritymeansthattherearenounnoticedchangestothedata.EveryMicroservicehastosolvethisproblem.Forinstance,datacanbesignedtoensurethattheyhavenotbeenmanipulatedinsomeway.TheconcreteimplementationhastobeperformedbyeachMicroservice.

Confidentialityensuresthatmodificationscannotbedenied.Thiscanbeachievedbysigningthechangesintroducedbydifferentusersbykeysthatarespecificfortheindividualuser.Thenitisclearthatexactlyonespecificuserhasmodifiedthedata.Theoverallsecurityarchitecturehastoprovidethekeys;thesigningisthenthetaskofeachindividualservice.

Datasecurityisensuredaslongasnodataarelost.Thisissuecanbehandledbybackupsolutionsandhighlyavailablestoragesolutions.ThisproblemhastobeaddressedbytheMicroservicessinceitiswithintheirresponsibilityaspartoftheirdatastorage.However,thesharedinfrastructurecanoffercertaindatabases,whichareequippedwithappropriatebackupanddisasterrecoverymechanisms.

Availabilitymeansthatasystemisavailable.AlsoheretheMicroserviceshavetocontributeindividually.However,sinceespeciallyinthecaseofMicroservice-basedarchitecturesonehastodealwiththepossibilityoffailuresofindividualMicroservices,Microservice-basedsystemsareoftenwellpreparedinthisarea.Resilience(section10.5)isforinstanceusefulforthis.

Theseaspectsareoftennotconsideredwhendevisingsecuritymeasures–however,thefailureofaservicehasoftenevenmoredramaticconsequencesthantheunauthorizedaccesstodata.OnedangerisDenialofServiceattacks,whichresultinsuchanoverloadingofserversthattheycannotperformanysensibleworkanymore.Thetechnicalhurdlesforthisareoftenshockinglylow,andthedefenseagainstsuchattacksisfrequentlyverydifficult.

8.13DocumentationandMetadataTokeeptheoverviewinaMicroservice-basedarchitecturecertaininformationabouteachMicroservicehastobeavailable.Therefore,theMicroservice-basedarchitecturehastodefinehowMicroservicescanprovidesuchinformation.Only

whenallMicroservicesprovidethisinformationinauniformway,theinformationcanbeeasilycollected.Possibleinformationofinterestisforinstance:

Fundamentalinformationlikethenameoftheserviceandtheresponsiblecontactperson.Informationaboutthesourcecode:Wherethecodecanbefoundintheversioncontrolandwhichlibrarieshavebeenused.TheusedlibrariescanbeinterestinginordertocompareopensourcelicensesofthelibrarieswiththecompanypoliciesortoidentifyincaseofasecuritygapinalibrarytheaffectedMicroservices.ForsuchpurposestheinformationhastobeavailableevenifthedecisionabouttheuseofacertainlibraryratherconcernsonlyoneMicroservice.Thedecisionitselfcanbemadelargelyindependentlybytheresponsibleteam.AnotherinterestinginformationiswithwhichotherMicroservicestheMicroserviceworkstogether.Thisinformationiscentralforthearchitecturemanagement(comparesection8.2).Inaddition,informationaboutconfigurationparametersoraboutfeaturetogglesmightbeinteresting.Featuretogglescanswitchfeaturesonoroff.Thisisusefulforactivatingnewfeaturesonlyinproductionwhentheirimplementationisreallyfinished,orforavoidingthefailureofaservicebydeactivatingcertainfeatures.

ItisnotsensibletodocumentallcomponentsoftheMicroservicesortounifytheentiredocumentation.Aunificationonlymakessenseforinformation,whichisrelevantoutsideoftheteamimplementingtheMicroservice.WheneveritisnecessarytomanagetheinterplayofMicroservicesortochecklicenses,therelevantinformationhastobeavailableoutsideoftheresponsibleteam.ThesequestionshavetobesolvedacrossMicroservices.EachteamcancreateadditionaldocumentationabouttheirownMicroservices.However,thisdocumentationisonlyrelevantforthisoneteamandthereforedoesnothavetobestandardized.

OutdatedDocumentation

Acommonproblemconcerningthedocumentationofanysoftwareisthatthedocumentationgetseasilyoutdatedandthendocumentsastatewhichisnotuptodateanymore.Therefore,thedocumentationshouldbeversionedtogetherwiththecode.Besides,thedocumentationshouldbecreatedfrominformation,whichisanyhowpresentinthesystem.Forinstance,thelistofallusedlibrariescanbetakenfromthebuildsystemsinceexactlythisinformationisneededduringthe

compilationofthesystem.WhichotherMicroservicesareusedcanbeobtainedfromServiceDiscovery.ThisinformationcanforinstancebeusedtocreatefirewallruleswhenafirewallissupposedtobeusedtoprotectthecommunicationbetweentheMicroservices.Insummary,thedocumentationdoesnothavetobemaintainedseparately,butresultsfromtheanyhowavailableinformation.

AccesstoDocumentation

Thedocumentationcanbepartoftheartifactswhicharecreatedduringthebuild.Inaddition,therecanbearun-timeinterfacewhichallowstoreadoutmetadata.SuchaninterfacecancorrespondtotheotherwisecommoninterfacesformonitoringandforinstanceprovideJSONdocumentsviaHTTP.Inthisway,themetadataareonlyanadditionalinformationMicroservicesprovideatrun-time.

Inaservicetemplateitcanexemplarilybeshownhowthedocumentationiscreated.TheservicetemplatecanthenformthebasisfortheimplementationofnewMicroservices.Whentheservicetemplatealreadycontainsthisaspect,itfacilitatestheimplementationofastandard-conformdocumentation.Inaddition,atleasttheformalcharacteristicsofthedocumentationcanbecheckedbyatest.

8.14ConclusionThedomainarchitectureofaMicroservice-basedsystemisessentialbecauseitinfluencesnotonlythestructureofthesystem,butalsotheorganization(section8.1).Unfortunately,especiallyforMicroservicestoolsfordependencymanagementareraresothatteamshavetodevelophome-madesolutions.However,oftenanunderstandingoftheimplementationoftheindividualbusinessprocesseswillbesufficientandanoverviewoftheentirearchitectureisnotreallynecessary(section8.2).

Foranarchitecturetobesuccessfulithastobepermanentlyadjustedtothechangingrequirements.ForDeploymentMonolithstherearenumerousrefactoringtechniquestoachievethis.SuchpossibilitiesdoalsoexistforMicroservices–howeverwithoutthesupportoftoolsandwithmuchhigherhurdles(section8.3).StillMicroservice-basedsystemscanbesensiblydevelopedfurther–forinstancebystartinginitiallywithfewlargeMicroservicesandcreatingovertimemoreandmoreMicroservices(section8.4).AnearlydistributionintomanyMicroservicesentailstherisktoendupwithawrongdistribution.

AspecialcaseisthemigrationofalegacyapplicationtoaMicroservice-basedarchitecture(section8.5).Inthiscase,thecodebaseofthelegacyapplicationcanbedividedintoMicroservices-howeverthiscanleadtoabadarchitectureduetotheoftenbadstructureofthelegacyapplication.Alternatively,thelegacyapplicationcanbesupplementedbyMicroservices,whichreplacefunctionalitiesofthelegacyapplicationinastepwisemanner.

Event-drivenArchitecture(section8.6)canservetouncouplethelogicintheMicroservices.Thisallowsaneasyextensibilityofthesystem.

Definingthetechnologicalbasisisoneofthetasksofanarchitecture(section8.7).IncaseofMicroservice-basedsystemsthisdoesnotrelatetothedefinitionofasharedtechnologystackforimplementation,buttothedefinitionofsharedcommunicationprotocols,interfaces,monitoringandlogging.Additionaltechnicalfunctionsoftheentiresystemarecoordinationandconfiguration(section8.8).Inthisareatoolscanbeselected,whichallMicroserviceshavetoemploy.Alternatively,onecandowithoutacentralconfigurationandinsteadleaveeachMicroservicetobringalongitsownconfiguration.

ForServiceDiscovery(section8.9)likewiseacertaintechnologycanbechosen.AsolutionforServiceDiscoveryisinanycasesensibleforaMicroservice-basedsystem–exceptmessagingisusedforcommunication.BasedonServiceDiscoveryLoadBalancingcanbeintroduced(section8.10)todistributetheloadacrosstheinstancesoftheMicroservices.ServiceDiscoveryknowsallinstances,theloadbalancingdistributestheloadtotheseinstances.LoadBalancingcanbeimplementedviaacentralloadbalancer,viaServiceDiscoveryorviaoneloadbalancerperclient.Thisprovidesthebasisforscalability(section8.11).ThisallowsaMicroservicetoprocessmoreloadbyscalingup.

MicroserviceshaveasignificantlyhighertechnicalcomplexitythanDeploymentMonoliths.Operatingsystems,networks,loadbalancer,ServiceDiscoveryandcommunicationprotocolsallbecomepartofthearchitecture.DevelopersandarchitectsofDeploymentMonolithsarelargelysparedfromtheseaspects.Thusarchitectshavetodealwithentirelydifferenttechnologiesandhavetocarryoutarchitectureatanentirelydifferentlevel.

Intheareaofsecurityacentralcomponenthastotakeoveratleastauthenticationandpartsofauthorization.TheMicroservicesshouldthensettlethedetailsofaccess(section8.12).Inordertoobtaincertaininformationfromasystem,which

iscomposedofmanyMicroservices,theMicroserviceshavetopossessastandardizeddocumentation(section8.13).Thisdocumentationcanforinstanceprovideinformationabouttheusedlibraries–tocomparethemwithopensourcelicenseregulationsortoremovesecurityissueswhenalibraryhasasecuritygap.

ThearchitectureofaMicroservice-basedsystemisdifferentfromclassicalapplications.ManydecisionsareonlymadeintheMicroservices,whiletopicslikemonitoring,loggingorContinuousDeliveryarestandardizedfortheentiresystem.

EssentialPoints

RefactoringbetweenMicroservicesislaborious.Therefore,itishardtochangethearchitectureatthislevel.Accordingly,thecontinueddevelopmentofthearchitectureisacentralpoint.Anessentialpartofthearchitectureisthedefinitionofoverarchingtechnologiesforconfigurationandcoordination,ServiceDiscovery,LoadBalancing,security,documentationandmetadata.

1. EricEvans:Domain-DrivenDesign:TacklingComplexityintheHeartofSoftware,Addison-Wesley,2003,ISBN978-0-32112-521-7↩

2. MartinFowler:Refactoring:ImprovingtheDesignofExistingCode,Addison-Wesley,1999,ISBN978-0201485677↩

3. SamNewman:BuildingMicroservices:DesigningFine-GrainedSystems,O’ReilleyMedia,2015,ISBN978-1-4919-5035-7↩

4. GregorHohpe,BobbyWoolf:EnterpriseIntegrationPatterns:↩

9IntegrationandCommunication

Microserviceshavetobeintegratedandneedtocommunicate.Thiscanbeachievedatdifferentlevels(Fig.37).Eachapproachhascertainadvantagesanddisadvantages.Besides,ateachleveldifferenttechnicalimplementationsofintegrationarepossible.

Fig.37:Differentlevelsofintegration

Microservicescontainagraphicaluserinterface.Therefore,MicroservicescanbeintegratedattheleveloftheUI.Thistypeofintegrationisintroducedinsection9.1.Alsothelogiccanbeintegrated.MicroservicescanuseREST(section9.2),SOAPorRCP(section9.3)ormessaging(section9.4)toachievetheintegrationoflogic.Finally,theintegrationcanbeperformedatthelevelofthedatabaseviadatareplication(section9.5).

Generalrulesforthedesignofinterfacesareprovidedinsection9.6.

9.1WebandUI

MicroservicesshouldbringtheirownUIalong.ThisallowstoimplementfunctionalitieseveninthosecasesinonlyoneMicroservice,whenthechangesalsoaffecttheUI.AttheleveloftheentiresystemitisnecessarytojointlyintegratetheUIsoftheMicroservices.Thiscanbeachievedbydifferentapproaches,whicharereviewedintheinnoQBlog.

MultipleSingle-Page-Apps

Single-Page-App(SPA)implementstheentireUIwithjustoneHTMLpage.ThelogicisimplementedinJavaScript,whichdynamicallychangespartsofthepage.ThelogiccanmanipulatetheURLdisplayedinthebrowsersothatbookmarksandothertypicalbrowserfeaturescanbeused.However,SPAsarenotinlinewiththeoriginalwebthinking:SPAsmarginalizeHTMLascentralwebtechnology.MostlogicisimplementedinJavaScript.Classicalwebarchitecturesimplementlogicnearlyexclusivelyontheserver.

SPAsareespeciallyadvantageouswhencomplexinteractionsorofflineabilityarerequired.Google’sGMailisanexamplewhichalsodecisivelyshapedthetermSPA.Mailclientsareoftennativeapplications.GMailasSPAoffersnearlythesamecomfort.

TherearedifferenttechnologiesfortheimplementationofSingle-Page-Apps:

AngularJSisverypopular.AngularJShasamongstotherfeaturesabidirectionalUIdata-binding:IftheJavaScriptcodeassignsanewvaluetoanattributeofaboundmodel,theviewcomponentsdisplayingthevalueareautomaticallychanged.ThebindingworksalsofromUItothecode:AngularJScanbindtheinputofausertoaJavaScriptvariable.Furthermore,AngularJScanrenderHTMLtemplatesinthebrowser.TherebyJavaScriptcodecanalsogeneratecomplexDOMstructures.InthatcasetheentirefrontendlogicisimplementedintheJavaScriptcoderunningthebrowser.AngularJSwasmadebyGooglewhoputtheframeworkundertheveryliberalMITlicense.Ember.jsworksinlinewiththeprincipleConventionoverConfigurationandrepresentsinessencethesamefeatureslikeAngularJS.ViathesupplementarymoduleEmberDataitoffersamodel-drivenapproachforaccessingRESTresources.Ember.jsisundertheMITlicenseandislookedafterbydevelopersfromtheopensourcecommunity.ExtJSoffersapartfromanMVCapproachalsocomponentswhichdeveloperscancomposetoaUIsimilarlikeforRichClientapplications.Ext

JSisavailableasOpenSourceunderGPLv3.0.However,forcommercialdevelopmentalicencehastobeboughtfromthemanufacturerSencha.

SPAperMicroservice

IncaseofMicroserviceswithSinglePageAppseachMicroservicecanbringitsownSPAalong(Fig.38).TheSPAcancalltheMicroserviceforinstanceviaJSON/REST.ThisisespeciallyeasytoimplementwithJavaScript.BetweentheSPAsalinkcanbeused.

Fig.38:MicroserviceswithSinglePageApps

TherebytheSPAsarecompletelyseparateandindependent.NewversionsofaSPAandoftheassociatedMicroservicecanberolledoutwithoutfurtherado.However,atighterintegrationofSPAsisdifficult.WhentheuserswitchesfromoneSPAtoanother,thebrowserloadsanewwebpageandstartsadifferentJavaScriptapplication.EvenmodernbrowsersneedsomuchtimeforthisthatthisapproachisonlysensiblewhenswitchingbetweenSPAsisanexception.

AssetServerforUniformity

BesidesSPAscanbeheterogeneous.EachbringsitsownindividuallydesignedUIalong.However,thisissuecanbesolvedbyusinganAssetServer.SuchaserverisusedtoprovideJavaScriptfilesandCSSfilesfortheapplications.WhentheSPAsoftheMicroservicesareonlyallowedtousethesekindsofresourcesviatheAssetServer,auniformuserinterfacecanbeachieved.Toaccomplishthis,aProxyServercandistributerequeststotheAssetServerandtheMicroservices.

TherebyitwilllookforthewebbrowserasifallresourcesaswellastheMicroservicespossessasharedURL.ThisapproachavoidsthatsecurityrulesprohibittheuseofthecontentsbecausetheyoriginatefromdifferentURLs.Cachingcanthenreducethetimeforloadingtheapplications.WhenonlyJavaScriptlibraries,whicharestoredontheAssetServer,areallowedtobeused,thechoiceoftechnologiesfortheMicroservicescanbereduced.Therefore,uniformityandfreetechnologychoicearecompetingaims.

BesidesthesharedassetswillcreatecodedependenciesbetweentheAssetServerandallMicroservices.AnewversionofanassetentailsthemodificationofallMicroserviceswhichusethisasset.Intheend,theyhavetomodifiedinawaythattheyusethenewversion.Suchcodedependenciesendangertheindependentdeploymentandthereforeshouldbeavoided.Codedependenciesinthebackendareoftenaproblem(comparesection8.3).Infact,suchdependenciesshouldalsobereducedinthefrontend.However,insuchacaseanAssetServerisratheraproblemthanasolution.

ApartfromanAssetServerUIguidelinescanbehelpful,whichdescribethedesignoftheapplicationinmoredetailandtherebyenableauniformapproachalsoatdifferentlevels.ThisallowsfortheimplementationofauniformUIevenwithoutasharedAssetServerandcodedependencies.

Inaddition,ithastobeensuredthattheSPAspossessauniformauthenticationandauthorizationsothattheusersdonothavetologinmultipletimes.AnOAuth2orasharedsignedcookiecanbeasolutionforthis(comparealsosection8.12).

JavaScriptcanonlyaccessdatawhichareavailableunderthedomainfromwheretheJavaScriptcodeoriginates.ThisSameOriginPolicyavoidsthatJavaScriptcodecanreaddatafromotherdomains.WhenallMicroservicesareaccessibletotheoutsideunderthesamedomainduetoaProxy,thisisnolimitation.OtherwisethepolicyhastobedeactivatedwhentheUIofaMicroserviceissupposedtoaccessthedataofanotherMicroservice.ThisproblemcanbesolvedbyCORS(CrossOriginResourceSharing)withwhichtheserverdeliveringthedatacanalsoallowJavaScriptfromotherdomains.AnotheroptionistoofferallSPAandRESTservicestotheoutsideonlyviaonedomainsothatanaccessacrossdomainsisnotnecessary.InthiswayalsotheaccesstosharedJavaScriptcodeonanAssetServercanbeimplemented.

ASinglePageAppforallMicroservices

ThedivisionintomultipleSPAsresultsinastrictseparationofthefrontendsoftheMicroservices.IfforinstanceaSPAisresponsibleforregisteringordersandanotheroneforafundamentallydifferentusecaselikereports,theloadtimesneededwhenchangingbetweenSPAsarestillacceptable.Maybetheusergroupsareevendifferentsothatchangesbetweentheapplicationsdonotoccur.

TherearecaseswhenatighterintegrationoftheuserinterfacesoftheMicroservicesisnecessary.Forexample,inanorderalsodetailsabouttheitemscanbedisplayed.DisplayingtheorderistheresponsibilityofoneMicroservice,displayingtheitemsisperformedbyanother.InthiscasetheSPAcanbedistributedintomodules.EachmodulebelongstoanotherMicroserviceandthereforetoanotherteam.Themodulesshouldbedeployedseparately.TheycanforinstancebestoredontheserverinindividualJavaScriptfilesandpossessseparateContinuousDeliverypipelines.Besidestherehavetobesuitableconventionsfortheinterfaces.Forexample,onlythesendingofeventsmightbeallowed.Eventsuncouplethemodulesbecausethemodulescommunicateonlychangesinthestates,butnothowothermoduleshavetoreacttothem.

Fig.39:CloseintegrationofMicroservicessharingoneSingle-Page-App

AngularJSforinstancehasamoduleconceptwhichallowstoimplementindividualpartsoftheSPAinseparateunits.AMicroservicecouldprovideanAngularJSmodulefordisplayingtheuserinterfaceoftheMicroservice.Themodelcanintegrate,ifnecessary,AngularJSmodulesofotherMicroservices.

However,suchanapproachhasdisadvantages:

DeployingtheSPAisoftenonlypossibleascompleteapplication.Whenamoduleismodified,theentireSPAhastoberebuiltanddeployed.ThishastobecoordinatedbetweentheMicroservices,whichprovidethemodulesoftheapplication.Inaddition,thedeploymentoftheMicroservicesontheserverhastobecoordinatedwiththedeploymentofthemodulessincethemodulescalltheMicroservices.ThisnecessityforcoordinationforthedeploymentofmodulesofanapplicationshouldbeavoidedbyMicroservices.Themodulescancalleachother.Dependingonthewaycallsareimplemented,changestoamodulecanentailthatalsoothermoduleshavetochanged,forinstancebecauseaninterfacehasbeenmodified.WhenthemodulesbelongtoseparateMicroservices,thisenforcesagainacoordinationacrossMicroservices,whichshouldbeavoided.

ForSPAmodulesamuchclosercoordinationisnecessarythanforlinksbetweenapplications.OntheotherhandtheSPAmodulesoffertheadvantagethatUIelementsfromdifferentMicroservicescanbesimultaneouslydisplayedtotheuser.However,thisapproachcloselycouplestheMicroservicesattheleveloftheUI.TheSPAmodulescorrespondtothemoduleconceptswhichalsoexistinotherprogramminglanguagesandcauseasimultaneousdeployment.Thus,theMicroservices,whichreallyshouldbeindependentofeachother,arecombinedattheUIlevelinoneshareddeploymentartifact.Therefore,thisapproachundoesoneofthemostimportantadvantagesofaMicroservice-basedarchitecture–theindependentdeployment.

HTMLApplications

AnotheroptionforimplementingtheuserinterfaceareHTML-baseduserinterfaces.EveryMicroservicehasoneormorewebpageswhicharegeneratedontheserver.ThewebpagecanalsouseJavaScript.Here,contrarytoSPAs,only

anewHTMLwebpageandnotnecessarilyanapplicationisloadedbytheserverwhenchangingbetweenwebpages.

ROCA

ROCA(ResourceOrientedClientArchitecture)offersthepossibilitytoarrangethehandlingofJavaScriptanddynamicalelementsinHTMLuserinterfaces.ROCAviewsitselfasalternativetoSPAs.InROCAtheroleofJavaScriptislimitedtooptimizingtheusabilityofthewebpages.JavaScriptcanfacilitatetheiruseorcanaddeffectstotheHTMLwebpages.However,theapplicationhastoremainuseablewithoutJavaScript.ItisnotthepurposeofROCAthatusersreallyusewebpageswithoutJavaScript.Theapplicationsareonlysupposedtousethearchitectureoftheweb,whichisbasedonHTMLandHTTP.EspeciallywhenawebapplicationissupposedtobedividedintoMicroservices,ROCAreducesthedependenciesandsimplifiesthedivision.BetweenMicroservicesthecouplingoftheUIcanbeachievedbylinks.ForHTMLapplicationslinksaretheusualtoolfornavigatingbetweenthewebpagesandrepresentanaturalintegration.TheyarenoforeignbodylikeinthecaseofSPAs.

Fig.40:HTMLuserinterfacewithanassetserver

TosupporttheuniformityoftheHTMLuserinterfaces,theMicroservicescanuseasharedAssetServerlikeinthecaseofSPAs(Fig.40).ItcontainsallCSSandJavaScriptlibraries.WhentheteamsinadditiondefinedesignguidelinesfortheHTMLwebpagesandlookaftertheassetsontheAssetServer,theuserinterfacesofthedifferentMicroserviceswillbelargelyidentical.However,asdescribedbefore,thiswillleadtocodedependenciesbetweentheUIsoftheMicroservices.

EasyRouting

TotheoutsidetheMicroservicesshouldappearlikeasinglewebapplication–ideallywithoneURL.ThisalsofacilitatestheshareduseofassetssincetheSameOriginPolicyisnotviolated.However,fromtheoutsideuserrequestshavetobedirectedtotherightMicroservice.Thisisthefunctionoftherouter.ItcanreceiveHTTPrequestsandforwardthemtooneoftheMicroservices.ThiscanbedonebasedontheURL.HowindividualURLsaremappedtoMicroservicescanbedecidedbyrules,whichcanalsobecomplex.TheexampleapplicationusesZuulforthistask(comparesection14.9).ReverseProxiesareanalternative.ThesecanforinstancebewebserverslikeApachehttpdornginx,whichcandirectrequeststootherservers.Intheprocesstherequestscanbemodified,URLscan

forinstanceberewritten.However,thesemechanismsarenotasflexibleasZuul,whichisveryeasytoextendwithhome-growncode.

Whenthelogicintherouterisverycomplex,thiscancauseproblems.IfthislogichastobechangedbecauseanewversionofaMicroserviceisbroughtintoproduction,anisolateddeploymentisnoteasyanymore.ThisendangerstheindependentdevelopmentandtheindependentdeploymentoftheMicroservices.

ArrangeHTMLwithJavaScript

Insomecases,acloserintegrationisnecessary.ItcanhappenthatinformationoriginatingfromdifferentMicroservicesisdisplayedononeHTMLwebpage.ForexampleawebpagemightdisplayorderdatafromoneMicroserviceanddataconcerningtheordereditemsfromanotherMicroservice.Inthatcaseonerouterisnotsufficientanymore.AroutercanonlyallowthataMicroservicegeneratesacompleteHTMLwebpage.

AsimplesolutionwhichemploysthearchitecturepresentedinFig.40isbasedonlinks.AJAXallowstoloadthecontentofalinkfromanotherMicroservice.AfterwardsthelinkisreplacedbythetherebyreceivedHTML.IntheexamplealinktoanitemcouldbetransformedintoanHTMLdescriptionofthisitem.ThisallowstoimplementthelogicforthepresentationofaproductinoneMicroservice,whilethedesignoftheentirewebpageisimplementedinanotherMicroservice.TheentirewebpagewouldbetheresponsibilityoftheorderMicroservice,whilethepresentationoftheproductswouldbetheresponsibilityoftheproductMicroservice.ThisenablesthecontinuedindependentdevelopmentofbothMicroservicesanddisplayingpresentationsfrombothcomponents.Ifthepresentationoftheitemshastobechangedornewproductsnecessitatearevisedpresentation,thesemodificationscanbeimplementedintheproductMicroservice.TheentirelogicoftheorderMicroserviceremainsunchanged.

AnotherexampleforthisapproachisFacebook’sBigPipe.Itoptimizesnotonlytheloadtime,butallowsalsothecompositionofwebpagesfrompagelets.AcustomimplementationcanuseJavaScripttoreplacecertainelementsofthewebpagebyotherHTML.Thiscanbelinksordiv-elementsliketheonesalsootherwiseusedforstructuringwebpages.Suchadiv-elementcanbereplacedbyHTMLcode.

However,thisapproachcausesrelativelylongloadtimes.ItismainlyadvantageouswhenthewebUIanyhowusesalotofJavaScriptandwhenthere

arenotmanytransitionsbetweenwebpages.

FrontendServer

Fig.41showsanalternativeforatightintegration.AfrontendservercomposestheHTMLwebpagefromHTMLsnippets,whichareeachgeneratedbyaMicroservice.AssetslikeCSSorJavaScriptlibrariescanalsobestoredinthefrontendserver.EdgeSideIncludes(ESI)representsapossibilitytoimplementthisconcept.ESIoffersarelativelysimplelanguageforcombiningHTMLfromdifferentsources.WithESIcachescansupplementstaticcontent–forinstancetheskeletonofawebpage–withdynamiccontent.Inthiswaycachescanhelpwiththedeliveryofwebpages,eveniftheycontaindynamiccontent.ProxiesandcacheslikeVarnishorSquidimplementESI.AnotheralternativeareServerSideIncludes(SSI).TheyareverysimilartoESIs,however,theyarenotimplementedincaches,butinwebservers.WithSSIswebserverscanintegrateHTMLsnippetsfromotherserversintoHTMLwebpages.TheMicroservicescandelivercomponentsforthewebpage,whichthenwillbeassembledontheserver.ApachehttpdsupportsSSIsforinstancewithmod_include.nginxusesthengx_http_ssi_moduleforthesupportofSSIs.

Fig.41:IntegrationusingaFrontendserver

Portalsalsoconsolidateinformationfromdifferentsourcesononewebpage.MostproductsuseJavaPortletsinlinewiththeJavastandardJSR168(Portlet1.0)orJSR286(Portlet2.0).PortletscanbebroughtintoproductionindependentlyofeachotherandthereforesolveoneofthecentralchallengessurroundingMicroservice-basedarchitectures.Inpracticethesetechnologiesresultfrequentlyincomplexsolutions.PortletsbehavetechnicallyverydifferentlyincomparisontonormalJavawebapplicationssothattheuseofmanytechnologiesfromtheJavaenvironmentiseitherdifficultorimpossible.Portletsallowtheusertocomposeawebpagefrompreviouslydefinedportlets.Inthiswaytheusercanassembleforinstancehis/hermostimportantinformationsourcesononewebpage.However,thisisnotreallynecessaryforcreatingaUIforMicroservices.Theadditionalfeaturesresultinadditionalcomplexity.Therefore,portalserverswhicharebasedonportletsarenotareallygoodsolutionforthewebuserinterfacesofMicroservices.Inaddition,theyrestricttheavailablewebtechnologiestotheJavafield.

MobileClientsandRichClients

Webuserinterfacesdonotneedanyinstallationofsoftwareontheclient.Thewebbrowseristheuniversalclientforallwebapplications.OntheserversitethedeploymentofthewebuserinterfacecaneasilybecoordinatedwiththedeploymentoftheMicroservice.TheMicroserviceimplementsapartoftheUIandcandeliverthecodeofthewebuserinterfaceviaHTTP.Thisallowsforarelativelyeasycoordinateddeploymentofclientandserver.

Formobileapps,RichClients,ordesktopapplicationsthesituationisdifferent:Asoftwarehastobeinstalledontheclient.ThisclientapplicationisaDeploymentMonolith,whichhastoofferaninterfaceforallMicroservices.IftheclientapplicationissupposedtocomprisefunctionalitiesofdifferentMicroservices,itwouldtechnicallyhavetobemodularized,andtheindividualmodulesliketheassociatedMicroserviceswouldhavetobebroughtintoproductionindependentlyofeachother.However,thisisnotpossiblesincetheclientapplicationisaDeploymentMonolith.ASPAcanalsoeasilyturnintoaDeploymentMonolith.SometimesaSPAisusedtoseparatethedevelopmentofclientandserver.InaMicroservicescontextsuchauseofSPAsisnotdesirable.

WhenanewfeatureisimplementedinaMicroservice,whichalsorequiresmodificationsoftheclientapplication,thischangecannotsolelyberolledoutviaanewversionoftheMicroservice.Inaddition,anewversionoftheclientapplicationhastobedelivered.However,itisunrealistictodelivertheclientapplicationoverandoveragainforeachsmallchangeofafeature.Iftheclientapplicationsissupposedtobeavailableintheappstoreofamobileoperationsystem,anextensivereviewofeachversionisnecessary.Ifmultiplechangesaresupposedtobedeliveredtogether,thechangehastobecoordinated.AndthenewversionoftheclientapplicationhastobecoordinatedwiththeMicroservicessothatthenewversionsoftheMicroservicesarereadyintime.ThisresultsindeploymentdependenciesbetweentheMicroservices,whichshouldreallybeavoided.

OrganizationalLevel

Attheorganizationallevelthereisoftenadesignatedteamfordevelopingtheclientapplication.Inthismannerthedivisionintoanindividualmoduleisalsoimplementedattheorganizationallevel.Especiallywhendifferentplatformsaresupported,itisunrealisticthatthereisonedeveloperineachMicroserviceteamforeachplatform.Thedevelopersaregoingtoformoneteamforeachplatform.ThisteamhastocommunicatewithallMicroserviceteams,whichofferMicroservicesformobileapplications.Thiscannecessitatealotof

communication.However,Microserviceshavesetouttoavoidsuchexcessivecommunicationrequirements.Therefore,theDeploymentMonolithposesachallengeforclientapplicationsattheorganizationallevel.

Fig.42:MobileAppsandRichClientareDeploymentMonolithsthatintegratemultipleMicroservices.

Onepossiblesolutionistodevelopnewfeaturesinitiallyfortheweb.EachMicroservicecandirectlybringfunctionalitiesintotheweb.Uponareleaseoftheclientapplicationthesefeatureswillalsobeavailablethere.However,inthatcaseeachMicroserviceneedstosupportacertainsetoffeaturesforthewebapplicationand,whererequired,anothersetfortheclientapplication.Inexchangethisapproachcankeepthewebapplicationandthemobileapplicationuniform.Itsupportsanapproachwherethedomain-basedteamsprovidefeaturesoftheMicroservicestomobileusersaswellastowebusers.Mobileapplicationsandwebapplicationsareonlytwochannelstoofferthesamefunctionalities.

BackendforeachFrontend

However,therequirementscanalsobeentirelydifferent.Forinstance,themobileapplicationcanbealargelyindependentapplicationwhichissupposedtobedevelopedfurtherasindependentlyoftheMicroservicesandthewebuserinterfaceaspossible.Oftentheusecasesofthemobileapplicationaresodifferentfromtheusecasesofthewebapplicationthataseparatedevelopmentisrequiredduetothedifferencesinthefeatures.

InsuchcasestheapproachdepictedinFig.43canbesensible:Theteamforthemobileappresp.theRichClienthasanumberofdeveloperswhoimplementaspecialbackend.Thisallowstoalsodevelopfunctionalitiesofthemobileapp

independentlyinthebackend,becauseatleastapartoftherequirementsfortheMicroservicescanbeimplementedbydevelopersfromthesameteam.InthatcaseitshouldnothappenthatlogicforthemobileappisimplementedintheMicroservice,whichreallybelongsintoabackendMicroservice.However,thebackendforamobileapplicationdiffersfromotherAPIs.Mobileclientshavelittlebandwidthandahighlatency.Therefore,APIsformobiledevicesareoptimizedforgettingbywithasfewcallsaspossibleandforonlytransferingreallyessentialdata.ThisisalsotrueforRichClients,howevernotexactlytothesameextent.TheadaptionofanAPItothespecificrequirementsofamobileapplicationscanbeimplementedinaMicroservice,whichisimplementedbythefrontendteam.

Fig.43:MobileAppsorRichClientswiththeirownbackend

Inamobileappauserinteractionshouldrapidlyleadtoareactionoftheapp.WhenitisnecessarytocallaMicroserviceasreactiontoauserinteraction,thiscanalreadyconflictwiththisaim.Iftherearemultiplecalls,thelatencywillincreasefurther.Therefore,theAPIforamobileAppshouldbeoptimizedfordeliveringtherequireddatawithasfewcallsaspossible.Alsotheseoptimizationscanbeimplementedbyabackendforthemobileapp.

Theoptimizationscanbeimplementedbytheteamwhichisresponsibleforthemobileapp.TherebytheMicroservicescanofferuniversallyvalidinterfaceswhiletheteamsforthemobileappscanassembletheirspecialAPIsbythemselves.DuetothatthemobileappteamsarenotsodependentanymoreontheteamswhichareresponsiblefortheimplementationoftheMicroservices.

Tomodularizewebapplicationsissimplerthanthemodularizationofmobileapps,especiallywhenthewebapplicationsarebasedonHTMLandnotonSPAs.FormobileappsorRichClientAppsitismuchmoredifficultsincetheyformanindividualdeploymentunitandcannotbeeasilydivided.

ThearchitectureshowninFig.43makesitpossibletoreuseMicroservicesfordifferentclients.Atthesametime,itisanentryintoalayeredarchitecture.TheUIlayerisseparatedfromtheMicroservicesandisimplementedbyanotherteam.Inthatcaserequirementshavetobeimplementedbymultipleteams.Microservicesweremeanttoavoidexactlythis.Besidesthisarchitectureentailsthedangerthatlogicisimplementedintheservicesfortheclientapplication,whichreallybelongsintheMicroservices.Therefore,thissolutiondoesnotonlyhaveadvantages.

TryandExperiment

ThissectionpresentedasalternativeforwebapplicationsaSPAperMicroservice,aSPAwithmodulesperMicroservice,anHTMLapplicationperMicroserviceandafrontendserverwithHTMLsnippets.Whichoftheseapproacheswouldyouchoose?Why?

Howwouldyoudealwithmobileapps?Oneoptionwouldbeateamwithbackenddevelopers–orwouldyouratherchooseateamwithoutbackenddevelopers?

9.2RESTMicroserviceshavetobeabletocalleachotherinordertoimplementlogictogether.Thiscanbesupportedbydifferenttechnologies.

REST(RepresentationalStateTransfer)isoneoptiontoenablecommunicationbetweenMicroservices.RESTisthetermforthefundamentalapproachesoftheWWW:

ThereisaplethoraofresourceswhichcanbeidentifiedviaURIs.URIstandsforUniformResourceIdentifier.Itunambiguouslyandgloballyidentifiesresources.URLsarepracticallythesameasURIs.

Theresourcescanbemanipulatedviaafixedsetofmethods.InthecaseofHTTPtheseareforinstanceGETforrequestingaresource,PUTforstoringaresourceandDELETEfordeletingaresource.Themethodssemanticsarerigidlydefined.Therecanbedifferentrepresentationsforresources–forinstanceasPDForHTML.HTTPsupportstheso-calledContentNegotiationviatheAcceptHeader.Inthismannertheclientcandeterminewhichdatarepresentationitcanprocess.TheContentNegotiationallowsforinstancetodisplayresourcesinawaythatishuman-readableandtoprovidethematthesametimeunderthesameURLinamachine-readablemanner.TheclientcancommunicateviaanAcceptHeaderwhetheritonlyacceptshuman-readableHTMLoronlyJSON.Relationshipsbetweenresourcescanberepresentedbylinks.LinkscanpointtootherMicroservicestherebyenablingtheintegrationoflogicofdifferentMicroservices.TheserversinaRESTsystemaresupposedtobestateless.ThereforeHTTPimplementsastatelessprotocol.

Thelimitedvocabularyrepresentstheexactoppositeofwhatobject-orientedsystemsemploy.Object-orientationfocusesonaspecificvocabularywithspecificmethodsforeachclass.TheRESTvocabularycanlikewiseexecutecomplexlogic.Whendatavalidationsarenecessary,thiscanbecheckedatthePOSTorPUTofnewdata.Ifcomplexprocessesaresupposedtoberepresented,aPOSTcanstarttheprocess,andsubsequentlythestatecanbeupdated.ThecurrentstateoftheprocesscanbefetchedbytheclientundertheknownURLviaGET.Likewise,POSTorPUTcanbeusedtoinitiatethenextstate.

CacheandLoadBalancer

ARESTfulHTTPinterfacecanveryeasilybesupplementedwithacache:SinceRESTfulHTTPusesthesameHTTPprotocolliketheweb,asimplewebcacheissufficient.Likewise,theusualHTTPLoadBalancercanalsobeusedforRESTfulHTTP.ThepoweroftheseconceptsisimpressivelyillustratedbythesizeoftheWWW.ThissizeisonlypossibleduetothepropertiesofHTTP.HTTPforinstancealsopossessessimpleandusefulmechanismsforsecurity–notonlyencryptionviaHTTPS,butalsoauthenticationwithHTTPHeaders.

HATEOAS

HATEOAS(HypermediaastheEngineofApplicationState)isanotherimportantcomponentofREST.Therelationshipsbetweentheresourcesaremodeledby

links.Therefore,aclientonlyhastoknowanentrypoint.Fromthereitcangoonnavigatingatwillandtherebylocatealldatainastepwisemanner.IntheWWWitisforinstancepossibletostartfromGoogleandfromtheretoreachpracticallytheentirewebvialinks.

RESTdescribesthearchitectureoftheWWWandtherebythelargestintegratedcomputersystem.However,RESTcouldalsobeimplementedwithotherprotocols.Itisanarchitecturewhichcanbeimplementedwithdifferenttechnologies.TheimplementationofRESTwithHTTPiscalledRESTfulHTTP.WhenRESTfulHTTPservicesexchangedataasJSONorXMLinsteadasHTML,thisapproachallowstoexchangedataandnotonlytoaccesswebpages.

MicroservicescanalsoprofitfromHATEOAS.HATEOASdoesnothaveacentralcoordination,justlinks.ThisfitsverywelltotheconceptthatMicroservicesshouldhaveaslittlecentralcoordinationaspossible.IncaseofRESTclientsknowonlyentrypointsbasedonwhichtheycandiscovertheentiresystem.Therefore,inaREST-basedarchitectureservicescanbemovedinamannerthatistransparentfortheclient.Theclientsimplygetsnewlinks.Acentralcoordinationislikewisenotnecessaryforthis.TheRESTservicejusthastoreturndifferentlinks.IntheidealcasetheclientonlyhastounderstandthefundamentalsofHATEOASandthencannavigatevialinkstoanydataintheMicroservicesystem.TheMicroservice-basedsystemsontheotherhandcanmodifytheirlinksandtherebychangethedistributionoffunctionalitiesbetweenMicroservices.Evenextensivearchitecturechangescanbekepttransparent.

HAL

HATEOASisaconcept.HALisapossibilitytoimplementit.ItisastandarddescribinghowthelinkstootherdocumentsshouldbecontainedinaJSONdocument.TherebyHATEOASisveryeasytoimplementespeciallyinJSON/RESTfulHTTPservices.Thelinksareseparatefromtheactualdocument.Thisallowstoimplementlinkstodetailsortoindependentdatasets.

XML

XMLhasalonghistoryasdataformat.ItiseasytousetogetherwithRESTfulHTTP.TherearedifferenttypesystemsforXMLwhichcandeterminewhetheranXMLdocumentisvalid.Thisisveryusefulforthedefinitionofaninterface.AmongthelanguagesforthedefinitionofvaliddataisforinstanceXMLSchema(XSD)orRelaxNG.SomeframeworksallowforthegenerationofcodeinordertoadministrateXMLdata,whichcorrespondtosuchaschema.ViaXLinkXML

documentscancontainlinkstootherdocuments.ThisenablestheimplementationofHATEOAS.

HTML

XMLwasdesignedtotransferdataanddocuments.Todisplaytheinformationisthetaskofdifferentsoftware.MeanwhileHTMLhasasimilarapproachasXML:HTMLdefinesonlythestructures.ThedisplayoccursviaCSS.ForthecommunicationbetweenprocessesHTMLdocumentscanbesufficientbecauseinmodernwebapplicationsdocumentscontainonlydata-justlikeXML.InaMicroservicesworldthisapproachhastheadvantagethatthecommunicationtotheuserandbetweentheMicroservicesemploysthesameformat.Thisreducestheeffort.TherebyitgetseveneasiertoimplementMicroserviceswhichcontainaUIandacommunicationoptionforotherMicroservices.

JSON

JSON(JavaScriptObjectNotation)isarepresentationofdatawhichisespeciallyoptimizedforJavaScript.LikeJavaScriptthedataaredynamicallytyped.However,meanwhilethereareinfactsuitableJSONlibrariesforallprogramminglanguages.InadditiontherearetypesystemslikeJSONSchema,whichsupplementJSONwithanappropriatevalidation.WiththatJSONisnotinferioratallanymoretodataformatslikeXML.

ProtocolBuffer

BinaryprotocolslikeProtocolBuffercanalsobeusedinsteadoftext-baseddatarepresentations.ThistechnologyhasbeendesignedbyGoogletorepresentdatamoreefficientlyandtoachieveahigherperformance.ThereareimplementationsformanydifferentprogramminglanguagessothatProtocolBuffercanbeuniversallyusedsimilartoJSONorXML.

RESTfulHTTPissynchronous.

RESTfulHTTPissynchronous:Typicallyaservicesendsoutarequestandwaitsforaresponsewhichissubsequentlyanalyzedinordertocontinuewiththeprogramsequence.Thiscancauseproblemsincaseoflonglatencytimeswithinthenetwork.Itcanlengthentheprocessingofarequestsinceresponsesofotherserviceshavetobewaitedfor.Besides,afteracertainwaitingtimetherequesthastobeabortedbecauseitislikelythattherequestisnotgoingtobeansweredatall.Possiblereasonsarethattheserverisnotavailableatthemomentorthat

thenetworkhasaproblem.Correctlyhandledtimeoutsincreasethestabilityofthesystem(section10.5).

Thefailuremaynotresultinthefailureofadditionalservices.Therefore,viathetimeoutithastobeensuredthattheparticularsystemstillrespondsandthefailuredoesnotpropagate.

9.3SOAPandRPCItispossibletobuildaMicroservices-basedarchitectureonSOAP.SOAPusesalsoHTTPlikeREST,butemploysonlyPOSTmessagestotransferdatatoaserver.IntheendaSOAPcallsamethodonacertainobjectontheserver.ThereforeSOAPisanRPCmechanism(RemoteProcedureCall),whichcallsmethodsinadifferentprocess.

SOAPlacksmechanismslikeHATEOAS,whichallowtoflexiblyhandlerelationshipsbetweenMicroservices.Theinterfaceshavetobecompletelydefinedbytheserverandknownontheclient.

FlexibleTransport

SOAPcanconveymessageswithdifferenttransportmechanisms.ItisforinstancepossibletoreceiveamessageviaHTTPandtosubsequentlysentitonasmessageviaJMSorasemailviaSMTP/POP.SOAP-basedtechnologiesalsosupporttheforwardingofrequests.Forexample,thesecuritystandardWS-Securitycanencryptorsignpartsofamessage.Afterwardsthepartscanbesentontodifferentserviceswithouthavingtobedecrypted.Thesendercansendamessageinwhichsomepartsareencrypted.Thismessagecanbeprocessedviadifferentstations.Eachstationcanprocessapartofthemessageorsendittootherrecipients.Finally,theencryptedpartswillarriveattheirfinalrecipients–andonlytheretheyhavetobedecryptedandprocessed.

SOAPhasmanyextensionsforspecialusecontexts.ThedifferentextensionsfromtheWS-*-environmentcompriseforinstancetransactionsandthecoordinationofwebservices.Inthiswayacomplexprotocolstackcanarise.Theinteroperabilitybetweenthedifferentservicesandsolutionscansufferduetothecomplexity.SometechnologiesarealsonotverysensibleforMicroservices.Forexample,acoordinationofdifferentMicroservicesisproblematicasthiswillresultinacoordinationlayer,andmodificationsofabusinessprocesswillprobablyconcernthecoordinationoftheMicroservicesandalsotheMicroservicesthemselves.

WhenthecoordinationlayercomprisesallMicroservices,aMonolithiscreatedwhichalsohastobechangeduponeachmodification.ThiscontradictstheMicroservicesideaofindependentdeployment.WS-*isratherinlinewithsuchconceptsasSOA.

Thrift

AnothercommunicationpossibilityisApacheThrift.ItusesaveryefficientbinaryencodinglikeProtocolBuffer.Furthermore,Thriftcanforwardrequestsfromaprocesswithaprogramminglanguageviathenetworktootherprocesses.TheinterfaceisdescribedinaninterfacedefinitionspecificforThrift.Basedonthisdefinitiondifferentclientandservertechnologiescancommunicatewitheachother.

9.4MessagingAnotheroptionforthecommunicationbetweenMicroservicesaremessagesandmessagingsystems.Asthenamesuggests,thesesystemsarebaseduponthesendingofmessages.Themessagescanresultinaresponsewhichagainissentasmessage.Messagescangotooneormultiplerecipients.

Especiallyincaseofdistributedsystemsmessagingsolutionscandemonstratetheiradvantages:

Messagescanstillbetransferredincaseofnetworkfailures.Themessagingsystembuffersthemanddeliversthemwhenthenetworkisavailableagain.Theguaranteescanbefurtherstrengthened:Themessagingsystemcannotonlyguaranteethecorrecttransferofthemessages,buteventheirprocessing.Iftherewasaproblemduringtheprocessingofthemessage,themessagecanbetransferredanew.Asuccessfulprocessingispossiblewhentheerrordisappearsaftersometime.Otherwiseitwillbeattemptedacouplemoretimestoprocessthemessageuntilfinallythemessageisdiscardedbecauseitcannotbeprocessedsuccessfully.Inamessagingarchitectureresponsesaretransferredandprocessedasynchronously.Sucharchitecturesarewelltunedtohighlatencytimesliketheyoccurinthenetwork.Waitingforaresponseistheusualcaseinsuchanarchitecture.Thereforetheprogrammingmodelalwaysactsontheassumptionofahighlatency.Thecallofanotherservicedoesnotblockthefurtherprocessing.Eveniftheresponsehasnotbeenreceivedyet,theservicecancontinueworkingandfor

instancecalladditionalservices.Thesenderdoesnotknowtherecipientofthemessage.Thesendersendsthemessagetoaqueueoratopic.Theretherecipientregisters.Therebysenderandrecipientaredecoupled.Therecanevenbemultiplerecipientswithoutthatthesenderisawareofthis.Besidesthemessagescanbemodifiedontheirway.Datacanbeforinstancesupplementedorremoved.Inaddition,messagescanalsobeforwardedtoentirelydifferentrecipients.

MessagingisalsoagoodbasisforcertainarchitecturesofMicroservice-basedsystemslikeEventSourcing(comparesection10.3)orEvent-drivenArchitecture(section8.6).

MessagesandTransactions

MessagingoffersasolutionfortransactionalsystemswithMicroservices.InaMicroservice-basedsystemtheguaranteesfortransactionsarehardtoensurewhentheMicroservicescalleachother.InthatcaseallMicroserviceswouldhavetoparticipateinatransaction.TheyareonlyallowedtowritechangeswhenallMicroservicesinthetransactionhaveprocessedthelogicwithouterrors.Thismeansthatthechangeswouldhavetobeheldbackforaverylongtime.Thatisbadfortheperformancesincenonewtransactioncanchangethedatameanwhile.Besidesinanetworkitisalwayspossiblethataparticipantfails.Inthatcasethetransactionwillremainopenforalongtimeormightevennotbeclosedatall.Thiswillblockchangestothedataforalongtime.Suchproblemsariseforinstancewhenthecallingsystemcrashes.

Fig.44:TransactionsandMessaging

Inamessagingsystemtransactionscanbetreateddifferently:Thesendingandreceivingofmessagesispartofatransaction–justasforinstancethewritingandreadingfromthedatabase(Fig.44).Whenanerroroccursduringtheprocessingofthemessage,alloutgoingmessagesarecanceledandthedatabasechangesarerolledback.Inthecaseofsuccessalltheseactionstakeplace.Therecipientsofthemessagescanlikewisebesafeguardedtransactionally.Inthatcasetheprocessingoftheoutgoingmessagesissubjecttothesametransactionalguarantees.

Theimportantpointisthatthesendingandreceivingofmessagesandthetransactionsonthedatabasecanbecombinedinonetransaction.Thecoordinationistakencareofbytheinfrastructure.Noextracodeneedstobewritten.ForthecoordinationofmessaginganddatabasestheprotocolTwoPhaseCommit(2PC)canbeemployed.Thisprotocolistheusualsolutionforcoordinatingtransactionalsystemslikedatabasesandmessagingsystemswitheachother.AnalternativeareproductslikeOracleAQorActiveMQ.Theystorethemessagesinadatabase.Thenthecoordinationbetweendatabaseandmessagingcansimplybeachievedbywritingthemessagesaswellasthedatamodificationsinthesamedatabasetransaction.Messaginganddatabaseareintheendthesamesystemsinthatcase.

Messagingallowstoimplementtransactionswithouttheneedforaglobalcoordination.EachMicroserviceistransactional.Thetransactionalsendingofmessagesisensuredbythemessagingtechnology.However,whenamessagecannotbeprocessed,forinstanceduetoinvalidvalues,thereisnopossibilitytorollthealreadyprocessedmessagesback.Therefore,thecorrectprocessingoftransactionsisnotgivenunderallcircumstances.

MessagingTechnology

Fortheimplementationofmessagingatechnologyhastobeused:

AMQP(AdvancedMessageQueuingProtocol)isastandard.Itdefinesaprotocolwithwhichmessagingsolutionscancommunicateonthewirewitheachotherandwithclients.AnimplementationofthisstandardisRabbitMQ,whichiswritteninErlangandisunderMozillalicence.AnotherimplementationisforinstanceApacheQpid.ApacheKafkafocusesonhighthroughput,replicationandfailsafeness.Therefore,itiswellsuitedfordistributedsystemslikeMicroservices,especiallythefailsafenessisveryhelpfulinthisusecontext.

0MQ(alsocalledZeroMQorZMQ)getsalongwithoutaserverandisthereforeverylight-weight.Ithassomeprimitivswhichcanbeassembledintocomplexersystems.0MQisundertheLGPLlicenceandwritteninC++.JMS(JavaMessagingService)definesanAPI,withwhichaJavaapplicationcanreceivemessagesandsendthem.IncontrasttoAMQPthespecificationdoesnotdefinehowthetechnologytransfersmessagesonthewire.Sinceitisastandard,Java-EEserverimplementthisAPI.WellknownimplementationsareActiveMQandHornetQ.ItisalsopossibletouseATOMFeedsformessaging.Thistechnologyisnormallyusedtotransferblogcontents.Clientscanrelativelyeasilyrequestnewentriesofablog.InthesamemanneraclientcanuseATOMtorequestnewmessages.ATOMisbasedonHTTPandthereforefitswellinaRESTenvironment.However,ATOMhasonlyfunctionalitiesfordeliveringnewinformation.Itdoesnotsupportmorecomplextechniquesliketransactions.

Formanymessagingsolutionsamessagingserverandthereforeanadditionalinfrastructurearerequired.ThisinfrastructurehastobeoperatedinamannerthatpreventsfailuresbecausefailureswouldcausethecommunicationintheentireMicroservice-basedsystemtobreakdown.However,messagingsolutionsaremostlydesignedtoachievehighavailabilityforinstanceviaclustering.

Formanydevelopersmessagingisratherunfamiliarsinceitrequiresasynchronouscommunication.Thismakesitappearasrathercomplex.Inmostcasesthecallingofamethodinadifferentprocessiseasiertounderstand.WithapproacheslikeReactive(comparesection10.6)asynchronousdevelopmentisintroducedintotheMicroservicesthemselves.AlsotheAJAXmodelfromJavaScriptdevelopmentresemblestheasynchronoustreatmentofmessages.Moreandmoredevelopersarethereforefamiliarwiththeasynchronousmodel.

TryandExperiment

REST,SOAP/RPCandmessagingeachhaveadvantagesanddisadvantages.Collecttheadvantagesanddisadvantagesandmakeupyourmindwhichofthealternativestouse.

InaMicroservice-basedsystemtherecanbedifferenttypesofcommunication–however,thereshouldbeonepredominantcommunicationtype.Whichwouldyouchoose?Whichotherswouldbeallowedinaddition?Inwhichsituations?

9.5DataReplicationAtthedatabaselevelMicroservicescouldshareadatabaseandtherebyconcertedlyaccessdata.Thistypeofintegrationhasalreadybeeninpracticeforalongtime:Itisnotunusualthatadatabaseisusedbyseveralapplications.Oftendatabaseslastlongerthanapplicationssothatnottheapplicationwithitsdemandsisfocusedon,butratherthedatabase.Althoughtheintegrationviaashareddatabaseiswidespread,ithascriticaldisadvantages:

Thedatarepresentationcannoteasilybemodifiedsinceseveralapplicationsaccessthedata.Achangecancauseoneoftheapplicationstobreak.Therefore,changeshavetobecoordinatedacrossallapplications.Thismakesitimpossibletorapidlymodifyapplicationsincaseswherethisentailschangestothedatabase.However,rapidchangeabilityisexactlytheareawhereMicroservicesshouldbringadvantages.Finally,itisalsohardlypossibletoclearuptheschema–i.e.toremovecolumnswhicharenotneededanymorebecauseitisunclearwhetheranysystemisstillusingthesecolumns.Inthelongrunthedatabasewillgetmoreandmorecomplexandhardertomaintain.

Intheendtheshareduseofadatabaseisaviolationofanimportantarchitecturerule.Componentsshouldbeabletochangetheirinternaldatarepresentationwithoutothercomponentsbeingaffected.Thedatabaseschemaisanexampleforaninternaldatarepresentation.Whenmultiplecomponentssharethedatabase,itisnotpossibleanymoretochangethedatarepresentation.Therefore,Microservicesshouldhaveastrictlyseparatedatastorageandnotshareadatabaseschema.

However,adatabaseinstancecanbeusedformultipleMicroserviceswhenthedatasetsoftheindividualMicroservicesarecompletelyseparate.Forinstance,eachMicroservicecanuseitsownschemawithinashareddatabase.However,inthatcasetheremaynotbeanyrelationshipsbetweentheschemas.

Replication

ReplicatingdataisonepossiblealternativefortheintegrationofMicroservices.However,thedatareplicationmustnotintroduceadependencyofthedatabaseschemasbythebackdoor.Whenthedataarejustreplicatedandthesameschemaisused,thesameproblemoccurslikeinthecaseofashareduseofthedatabase.AschemachangewillalsoaffectotherMicroservicessothattheMicroservicesareintheendcoupledagain.Thishastobeavoided.

ThedatashouldbetransferredintoanotherschematoensuretheindependencyoftheschemasandthereforetheMicroservices.Inaddition,suchatransformationisalsoinmostcasesdesirablefordomain-basedreasons.

AtypicalexamplefortheuseofreplicationinclassicalITareDataWarehouses.Theyreplicatedata,butstorethemdifferently.ThatisduetothefactthatdataaccessingintheDataWarehousehasverydifferentrequirements:Theaimistoanalyzelotsofdata.Thedataareoptimizedforreadingaccessandoftenalsocombinedasnoteverysingledatasetisrelevantforstatistics.

BecauseofBoundedContextinmostcasesdifferentrepresentationsorsubsetsofdataarerelevantfordifferentMicroservices.WhenreplicatingdatabetweenMicroservicesitwillforthisreasonfrequentlyanyhowbenecessarytotransformthedataortoreplicatejustsubsetsofthedata.

Problems:RedundancyandConsistency

Thereplicationcausesaredundantstorageofthedata.Thismeansthatthedataarenotimmediatelyconsistent:Ittakessometimeuntilchangeswillhavebeenreplicatedtoalllocations.

However,immediateconsistencycanbedispensable.IncaseofanalysistaskslikeinaDataWarehouseananalysiswhichdoesnotcomprisetheordersofthelastfewminutes,canbesufficient.Therearealsoothercasesinwhichconsistencyisnotthatimportant.WhenanordertakesalittlebitoftimeuntilitisvisibleinthedeliveryMicroservice,thiscanbeacceptablebecausemaybeanyhownobodywillrequestthedatainthemeanwhile.

Consistencyisarequirementforthesystem.Highconsistencyrequirementsmakereplicationdifficult.Whensystemrequirementsaredetermined,itisoftennotclearhowconsistentthedatareallyhavetobe.Thislimitsthepossibilitiesfordatareplication.

Alsoforreplicationtherehastobealeadingsystemwhichcontainsthecurrentdata.Allotherreplicatesshouldobtainthedatafromthissystem.Thenitisalwaysclearwhichdataarereallyup-to-date.Datamodificationsshouldnotbetriggeredbydifferentsystems.Thiseasilycausesconflictsandaverycompleximplementation.Suchconflictsareexcludedwhenthereisjustonesourceforchanges.

Implementation

Somedatabasesofferreplicationasfeature.However,thisisnothelpfulforthereplicationofdatabetweenMicroservicesbecausetheschemasoftheMicroservicesshouldbedifferent.Thereplicationhastobeselfimplemented.Forthispurpose,acustominterfacecanbeimplemented.Thisinterfaceshouldallowforhighperformanceaccesseventolargedatasets.Toachievethenecessaryperformance,onecanalsodirectlywriteintothetargetschema.TheinterfacedoesnotnecessarilyhavetouseaprotocollikeREST,butcanemployfasteralternativeprotocols.TothisenditcanbenecessarytouseanothercommunicationmechanismthantheonenormallyusedbytheMicroservices.

Batch

Thereplicationcanbeactivatedinabatch.Inthatcasetheentiredataoratleastchangesfromalongertimeintervalcanbetransferred.Forthefirstreplicationruntheamountofdatacanbelargesothatthereplicationtakesalongtime.Itcanstillbesensibletotransferallthedataeachtime.Thisallowstocorrectmistakeswhichhappenedduringthelastreplication.

Aneasyimplementationcanassignaversiontoeachdataset.Basedontheversiondatasetswhichhavechangedcanbespecificallyselectedandreplicated.Thisapproachcanbeeasilyrestartedagainincaseofaninterruptionofthereplicationbecausetheprocessitselfdoesnotholdastate.Insteadthestateisstoredwiththedataitself.

Event

Onealternativeistostartthereplicationincaseofcertainevents.Forinstance,whenadatasetisnewlygenerated,thedatacanalsoimmediatelybecopiedinto

thereplicates.Suchapproachesareespeciallyeasytoimplementwithmessaging(section9.4).

Datareplicationisanespeciallygoodchoiceforhighperformanceaccesstolargeamountsofdata.ManyMicroservice-basedsystemsgetalongwithoutreplicatingdata.Eventhosesystemswhichusedatareplicationwillalsoemployotherintegrationmechanisms.

TryandExperiment

WouldyouusedatareplicationinaMicroservice-basedsystem?Inwhichareas?Howwouldyouimplementit?

9.6Interfaces:InternalandExternalMicroservice-basedsystemshavedifferenttypesofinterfaces:

EachMicroservicecanhaveoneormoreinterfacesforotherMicroservices.AchangetotheinterfacecanrequirecoordinationwithotherMicroserviceteams.TheinterfacesbetweenMicroserviceswhicharedevelopedbythesameteamareaspecialcase.Teammemberscancloselyworktogethersothattheseinterfacesareeasiertochange.BesidestheMicroservice-basedsystemcanofferinterfacestotheoutsidewithwhichthesystemcanalsobeusedoutsideoftheorganizationofthedevelopers.Inextremecasesthiscanbepotentiallyeveryinternetuserwhenthesystemoffersapublicinterfaceintheinternet.

Theseinterfacesaredifferentlyeasytochange:Itisveryeasytoaskacolleagueinthesameteamforachange.Thiscolleagueispresumablyeveninthesameroom.

ChangestoaninterfaceofaMicroserviceofanotherteamaremoredifficult.Thechangehastoprevailagainstotherchangesandnewfeatures.Whenthechangehastobecoordinatedwithotherteams,additionalexpendituresarise.

InterfacechangesbetweenMicroservicescanbesafeguardedbyappropriatetests(Consumer-drivenContractTests,section11.7).Thesetestsexaminewhetherthe

interfacestillfulfillstheexpectationsoftheinterfaceusers.

ExternalInterfaces

Incaseofinterfacestotheoutsidethecoordinationwithusersismorecomplicated.Theremightbeverymanyusers.Forpublicinterfacestheusersmightevenbeunknown.Therefore,techniqueslikeConsumer-drivenContractTestsarehardtoimplementinsuchscenarios.However,forinterfacestotheoutsiderulescanbedefinedwhichdetermineforinstanceforhowlongacertainversionoftheinterfaceissupported.Astrongerfocusonbackwardscompatibilitycanalsobesensibleforpublicinterfaces.

Forinterfacestotheoutsideitcanbenecessarytosupportseveralversionsoftheinterfaceinordertonotforcealluserstoperformchanges.BetweenMicroservicesitshouldbeanaimtoacceptmultipleversionsonlyforuncouplingdeployments.WhenaMicroservicechangesaninterface,itshouldstillsupporttheoldinterface.InthatcasetheMicroserviceswhichdependontheoldinterfacedonothavetobeinstantlydeployedanew.However,thenextdeploymentshouldusethenewinterface.Afterwardstheoldinterfacecanberemoved.Thisreducesthenumberofinterfaceswhichhavetobesupportedandthereforethecomplexityofthesystem.

SeparatingInterfaces

Sincetheinterfacesaredifferentlyeasytochange,theyshouldbeimplementedseparately.WhenaninterfaceofaMicroserviceissupposedtobeusedexternally,itcansubsequentlyonlybechangedwhenthischangeiscoordinatedwiththeexternalusers.However,anewinterfaceforinternalusecanbesplitoff.Inthatcasetheinterfacewhichisexposedtotheoutsideisthestartingpointforaseparateinternalinterfacewhichcanbemoreeasilychangedagain.

Besides,severalversionsofthesameinterfacecanbeinternallyimplementedtogether.Inthiswaynewparametersofanewversioncanincasesofcallstotheoldinterfacesimplybesettodefaultvaluessothatbothinterfacesinternallyusethesameimplementation.

ImplementingExternalInterfaces

Microservice-basedsystemscanalsoofferinterfacestotheoutsideindifferentways.ApartfromawebinterfaceforuserstherecanalsobeanAPI,whichcanbeaccessedfromoutside.Forthewebinterfacesection9.1showedalreadyhowthe

MicroservicescanbeintegratedinawaywhichallowsthatallMicroservicescanimplementapartoftheUI.

WhenthesystemoffersaRESTinterfacetotheoutside,thecallsfromoutsidecanbeforwardedtoaMicroservicewiththehelpofarouter.IntheexampleapplicationtherouterZuulisusedforthis(section14.9).ZuulisveryflexibleandcanforwardrequesttodifferentMicroservicesbasedonverydetailedrules.However,HATEOASoffersalsothefreedomtomoveresources.Inthatcaseroutingisdispensable.TheMicroservicesareaccessiblefromtheoutsideviaURLs,buttheycanbemovedatanytime.IntheendtheURLsaredynamicallydeterminedbyHATEOAS.

ItwouldalsobepossibletoofferanadaptorfortheexternalinterfacewhichmodifiestheexternalcallsbeforetheyreachtheMicroservices.However,inthatcaseachangetothelogiccannotalwaysbelimitedtoaMicroservice,butcouldalsoaffecttheadaptor.

SemanticVersioning

Todenotechangestoaninterfaceaversionnumbercanbeused.SemanticVersioningdefinesapossibleversionnumbersemantics.TheversionnumberissplitintoMAJOR.MINOR.PATCH.Thecomponentshavethefollowingmeaning:

AchangeinMAJORindicatesthatthenewversionbreaksbackwardscompatibility.Theclientshavetoadjusttothenewversion.TheMINORversionischangedwhentheinterfaceoffersnewfeatures.However,thechangesshouldbebackwardscompatible.Achangeoftheclientsisonlynecessaryiftheywanttousethenewfeatures.PATCHisincreasedinthecaseofbugfixes.Suchchangesshouldbecompletelybackwardscompatibleandshouldnotrequireanymodificationsoftheclients.

IncaseofRESToneshouldkeepinmindthatitisnotsensibletoencodetheversionintheURL.TheURLshouldrepresentaresource–independentofthefactwithwhichAPIversionitiscalled.Therefore,theversioncanforinstancealsobedefinedinanAcceptHeaderoftherequest.

Postel’sLawortheRobustnessPrinciple

AnotherimportantbasisforthedefinitionofinterfacesisPostel’sLaw,whichisalsoknownastheRobustnessPrinciple.Itstatesthatcomponentsshouldbestrict

inregardstowhattheyarepassingonandliberalinregardstowhattheyareacceptingfromothers.Differentlyput:Eachcomponentshouldadhereascloselyaspossibletothedefinedinterfacewhenusingothercomponents,butshouldwheneverpossiblecompensateerrorswhichariseduringtheuseofitsowninterface.

WheneachcomponentbehavesaccordingtotheRobustnessPrincipletheinteroperabilitywillimprove:Infact,ifeachcomponentadheresexactlytothedefinedinterfaces,interoperabilityshouldalreadybeensured.Ifadeviationhappensnevertheless,theusedcomponentwilltrytocompensateforitandtherebyattemptto“save”theinteroperability.ThisconceptisalsoknownasTolerantReader.

Inpracticeacalledserviceshouldacceptthecallsaslongasthisispossibleatall.Onewaytoachievethisistoonlyreadoutthoseparametersfromacallwhicharereallynecessary.Onnoaccountshouldacallberejectedjustbecauseitdoesnotformallyconformwiththeinterfacespecification.However,theincomingcallsshouldbevalidated.SuchanapproachmakesiteasiertoensureasmoothcommunicationindistributedsystemslikeMicroservices.

9.7ConclusionTheintegrationofMicroservicescanoccuratdifferentlevels.

Client

Onepossiblelevelfortheintegrationisthewebinterface(section9.1):

EachMicroservicecanbringalongitsownSingle-Page-App(SPA).TheSPAscanbedevelopedindependently.ThetransitionbetweentheMicroservices,however,startsacompletelynewSPA.TherecanbeoneSPAfortheentiresystem.EachMicroservicesuppliesonemodulefortheSPA.Therefore,thetransitionsbetweentheMicroservicesareverysimpleintheSPA.However,theMicroservicesgetverytightlyintegratedsothatacoordinationofdeploymentscanbecomenecessary.EachMicroservicecanbringalonganHTMLapplication.Theintegrationcanoccurvialinks.Thisapproachiseasytoimplementandallowsforamodularizationofthewebapplication.JavaScriptcanloadHTML.TheHTMLcanbesuppliedbydifferentMicroservicessothateachMicroservicecancontributearepresentationof

itsdata.InthiswayanordercanloadthepresentationofaproductfromanotherMicroservice.AskeletoncanassembleindividualHTMLsnippets.TherebyanE-commercelandingpagecandisplaythelastorderfromoneMicroserviceandrecommendationsfromanotherMicroservice.ESI(EdgeSideIncludes)orSSI(ServerSideIncludes)canbeusefulforthis.

IncaseofaRichClientoramobileapptheintegrationisdifficultbecausetheclientapplicationisaDeploymentMonolith.Therefore,changesofdifferentMicroservicescaninfactonlybedeployedtogether.TheteamscanmodifytheMicroservicesandthendeliveracertainamountoffittingUIchangestogetherasnewreleaseoftheclientapplication.TherecanalsobeateamforeachclientapplicationwhichadoptsnewfunctionalitiesoftheMicroservicesintotheclientapplication.Fromanorganizationalperspectivetherecanevenbedevelopersintheteamoftheclientapplicationwhichdevelopacustomservice.Thisservicecanforinstanceimplementtheinterfaceinawaythatallowstheclientapplicationtouseitinahighperformancemanner.

LogicLayer

RESTisanoptionforthecommunicationofthelogiclayer(section9.2).RESTusesthemechanismsoftheWWWtoenablecommunicationbetweenservices.HATEOAS(HypermediaastheEngineofApplicationState)meansthattherelationshipsbetweensystemsarerepresentedaslinks.TheclientknowsonlyanentryURL.AlltheotherURLscanbechangedbecausetheyarenotdirectlycontactedbytheclients,butarefoundbythemvialinksstartingattheentryURL.HALdefineshowlinkscanbeexpressedandsupportstheimplementationofREST.OtherpossibledataformatsforRESTareXML,JSON,HTMLorProtocolBuffer.

ClassicalprotocolslikeSOAPorRPC(section9.3)canalsobeusedforthecommunicationofMicroservices.SOAPofferspossibilitiesforforwardingamessagetootherMicroservices.Thrifthasanefficientbinaryprotocolandcanlikewiseforwardcallsbetweenprocesses.

Messaging(section9.4)hastheadvantagethatitcanhandlenetworkproblemsandhighlatencytimesverywell.Inaddition,transactionsarealsoverywellsupportedbymessaging.

DataReplication

Atthedatabaselevelasharedschemaisnotrecommended(section9.5).ThiswouldcoupleMicroservicestootightlysincetheywouldhaveasharedinternaldatarepresentation.Thedatahavetobereplicatedintoanotherschema.TheschemacanbeinlinewiththerequirementsfortherespectiveMicroservice.AsMicroservicesareBoundedContexts,itisveryunlikelythattheMicroservicesshouldusethesamedatamodel.

InterfacesandVersions

Finally,interfacesareanimportantfoundationforcommunicationandintegration(section9.6).Notallinterfacesareequallyeasytochange:Publicinterfacesarepracticallynotchangeableatallbecausetoomanysystemsdependonthem.Internalinterfacescanmoreeasilybechanged.PublicinterfacesinthesimplestcasejustroutecertainfunctionalitiestosuitableMicroservices.SemanticVersioningisusefulforgivingameaningtoversionnumbers.ToensureahighlevelofcompatibilitytheRobustnessPrincipleishelpful.

ThissectionshouldhaveshownthatMicroservicesarenotjustserviceswhichuseRESTfulHTTP.ThisisonlyoneoptionforthecommunicationbetweenMicroservices.

EssentialPoints

AttheUIleveltheintegrationwithHTMLuserinterfacesisespeciallysimple.SPAs,desktopapplicationsormobileappsareDeploymentMonolithssothatchangestotheuserinterfaceforaMicroservicehavetobecloselycoordinatedwithotherchanges.ThoughRESTorRPCapproachesofferatthelogiclevelasimpleprogrammingmodel,messagingallowsforaloosercouplingandcanbettercopewiththechallengesofdistributedcommunicationviathenetwork.Datareplicationallowshighperformanceaccesseventolargeamountsofdata.TheMicroservicesmayonnoaccountusethesameschemafortheirdatasinceinthatcasetheinternaldatarepresentationcannotbechangedanymore.

10ArchitectureofIndividualMicroservices

WhenimplementingMicroservicesanumberofpointshavetobeheeded.ThischapteraddressesfirstthedomainarchitectureofMicroservices(section10.1).ForimplementingaMicroservice-basedsystemCQRS(section10.2)canbeinteresting.Thisapproachseparateswritestodatafromreadingdata.EventSourcing(section10.3)placeseventsintothecenterofthemodeling.ThestructureofaMicroservicecancorrespondtoaHexagonalArchitecture(section10.4)whichsubdividesfunctionalitiesintoalogickernelandadaptors.Section10.5focusesonresilienceandstabilityasessentialrequirementsforMicroservices.TechnicalpossibilitiesfortheimplementationofMicroservicessuchasReactivearediscussedinsection10.6.

10.1DomainArchitectureThedomainarchitectureofaMicroservicedefineshowtheMicroserviceimplementsitsdomain-basedfunctionalities.AMicroservice-basedarchitectureaimsatnotpredeterminingthisdecisionforallMicroservices.Thereby,theinternalstructureofMicroservicescanbeindependentlydecided.Thisallowstheteamstoactlargelyindependentlyofeachother.ItisforsuresensibletoadheretoestablishedrulesinordertokeeptheMicroserviceeasytounderstand,simpletomaintainandalsoreplaceable.However,thereisnostrictneedforregulationsatthislevel.

ThissectionshowshowtoidentifypotentialproblemswiththedomainarchitectureofaMicroservice.Whethertherereallyisaproblemandhowitcanbesolved,thenhastobeansweredbytheresponsibleteam.

Cohesion

ThedomainarchitectureoftheoverallsysteminfluencesthedomainarchitectureoftheindividualMicroservices.Aspresentedinsection8.1,Microservicesshouldbelooselycoupledtoeachother.Besides,theMicroservicesshouldhaveahighinternalcohesion.AMicroserviceshouldhaveonlyoneresponsibilityinregardstothedomain.Consequently,thepartsofaMicroservicehavetobelooselycoupled,andtheMicroservicehastohaveahighcohesion.Ifthatisnotthecase,theMicroservicewilllikelyhavemorethanoneresponsibility.Ifthe

cohesionwithintheMicroserviceisnothighenough,theMicroservicecanbesplitintoseveralMicroservices.DuetothesplittheMicroservicesremainsmallandthuseasiertounderstand,tomaintainandtoreplace.

Encapsulation

Encapsulationmeansthatapartofthearchitecturehidesinternalinformationfromtheoutside–especiallyallinternaldatastructures.Instead,theaccessissupposedtooccurviaaninterface.Therebythesoftwareremainseasytomodify:Internalstructurescanbechangedwithoutinfluencingotherpartsofthesystem.Forthisreason,MicroservicesmayinnocaseallowotherMicroservicesaccesstotheirinternaldatastructures.Otherwisethesedatastructurescannotbemodifiedanymore.Besides,inthismanner,everyMicroserviceneedsonlytounderstandtheinterfaceofanotherMicroservice.Thisimprovesthestructureandintelligibilityofthesystem.

Domain-DrivenDesign

Domain-drivenDesign(DDD)isapossibilitytointernallystructureMicroservices.EachMicroservicecanhaveaDDDdomainmodel.ThenecessarypatternsfromDomain-DrivenDesignwerealreadyintroducedinsection4.3.EspeciallywhenDomain-drivenDesignandStrategicDesigndefinethestructureoftheoverallsystem(section8.1),theMicroservicesshouldalsousetheseapproaches.DuringthedevelopmentoftheoverallsystemStrategicDesignorientatesitselftothefactwhichdomainmodelsthereareandhowtheyaredistributedacrosstheMicroservices.

Transactions

Transactionsbundlemultipleactionssothattheycanonlybeexecutedtogetherornotatall.AtransactioncanhardlycomprisemorethanoneMicroservice.OnlymessagingisabletosupporttransactionsacrossMicroservices(comparesection9.4).Thedomain-baseddesignwithinaMicroserviceensuresthateachoperationattheinterfacecorrespondstoonetransaction.InthiswayitcanbeavoidedthatmultipleMicroserviceshavetoparticipateinonetransaction.Thiswouldbeveryhardtoimplementtechnically.

10.2CQRSSystemsusuallysaveastate.Operationscanchangedataorreadthem.Thesetwotypesofoperationscanbeseparated:Operationsthatchangedataandthereforehavesideeffects(commands)canbedistinguishedfromoperationsthatjustread

data(queries).Anoperationmaynotsimultaneouslychangethestateandreturndata.Thisdistinctionmakesthesystemeasiertounderstand:Whenanoperationreturnsavalue,itisaqueryanddoesnotchangeanyvalues.Thisentailsadditionaladvantages.Queriescanforexamplebeprovidedwithacache.Ifreadoperationschangedalsodata,theadditionofacachewouldnotbesoeasysinceoperationswithsideeffectsstillhavetobeexecutedinspiteofacache.TheseparationbetweenqueriesandcommandsiscalledCQS(CommandQuerySeparation).ThisprincipleisnotlimitedtoMicroservices,butcanbeappliedingeneral.Forexample,classesinanobject-orientedsystemcandivideoperationsinthesamemanner.

CQRS

CQRS(CommandQueryResponsibilitySegregation)ismoredrasticthanCQSandcompletelyseparatestheprocessingofqueriesandcommands.

Fig.45:OverviewofCQRS

Fig.45showsthestructureofaCQRSsystem.EachcommandisstoredintheCommandStore.Inaddition,therecanbeCommandHandlers.TheCommandHandlerintheexampleusesthecommandsforstoringthecurrentstateofthedatainadatabase.AQueryHandlerusesthisdatabasetoprocessqueries.ThedatabasecanbeadjustedtotheneedsoftheQueryHandler.Forexample,adatabasefortheanalysisoforderprocessescanlookcompletelydifferentfroma

databasewhichcustomersusefordisplayingtheirownorderprocesses.Entirelydifferenttechnologiescanbeemployedforthequerydatabase.ItisforinstancepossibletouseanIn-Memory-Cachewhichlosesthedataincaseofaserverfailure.TheinformationpersistencyisensuredbytheCommandStore.InanemergencythecontentofthecachecanbereconstructedbytheCommandStore.

MicroservicesandCQRS

CQRScanbeimplementedwithMicroservices:

ThecommunicationinfrastructurecanimplementtheCommandQueuewhenamessagingsolutionisused.IncaseofapproacheslikeRESTaMicroservicehastoforwardthecommandstoallinterestedCommandHandlersandimplementtheCommandQueuethatway.EachCommandHandlercanbeaseparateMicroservice.Itcanhandlethecommandswithitsownlogic.TherebylogiccanveryeasilybedistributedtomultipleMicroservices.Likewise,aQueryHandlercanbeaseparateMicroservice.ThechangestothedatawhichtheQueryHandlerusescanbeintroducedbyaCommandHandlerinthesameMicroservice.However,theCommandHandlercanalsobeaseparateMicroservice.InthatcasetheQueryHandlerhastoofferasuitableinterfaceforaccessingthedatabasesothattheCommandHandlercanchangethedata.

Advantages

CQRShasanumberofadvantagesespeciallyintheinterplaywithMicroservices:

ReadingandwritingofdatacanbeseparatedintoindividualMicroservices.ThisallowsforevensmallerMicroservices.WhenthewritingandreadingisthatcomplexthatasingleMicroserviceforbothwouldgettoolargeandtoohardtounderstand,asplitmightbeverysensible.Likewise,anothermodelcanbeusedforwritingandreading.MicroservicescaneachrepresentaBoundedContextandthereforeusedifferentdatamodels.Forinstance,inanE-commerceshopalotofdatacanbewrittenforanonlinepurchasewhilestatisticalevaluationsreadonlyfewdataforeachpurchase.Fromatechnicalperspectivethedatacanbeoptimizedforreadingoperationsviadenormalizationorviaothermeansforcertainqueries.WritingandreadingcanbescaleddifferentlybystartingdifferentnumbersofQueryHandlerMicroservicesandCommandHandlerMicroservices.ThissupportsthefinegranularscalabilityofMicroservices.

TheCommandQueuefacilitatesthehandlingofloadpeaksduringwriting.Thequeuebuffersthechangeswhicharethenprocessedlateron.However,inthatcaseachangetothedatawillnotbeimmediatelytakenintoconsiderationbythequeries.ItiseasytorundifferentversionsoftheCommandHandlersinparallel.ThisfacilitatesthedeploymentofMicroservicesinnewversions.

CQRScanservetomakeMicroservicesevensmaller,evenwhenoperationsanddataarereallyverycloselyconnected.EachMicroservicecanindependentlydecidefororagainstCQRS.Therearedifferentwaystoimplementaninterfacewhichoffersoperationsforchangingandreadingdata.CQRSisonlyoneoption.BothaspectscanalsobeimplementedwithoutCQRSinjustoneMicroservice.ThefreedomtobeabletousedifferentapproachesisoneofthemainadvantagesofMicroservice-basedarchitectures.

Challenges

CQRScausesalsosomechallenges:

Transactionswhichcomprisereadandwriteoperationsarehardtoimplement.TherespectiveoperationscanbeimplementedindifferentMicroservices.InthatcaseitishardlypossibletocombinetheoperationsintoonetransactionsincetransactionsacrossMicroservicesareusuallyimpossible.Itishardtoensuredataconsistencyacrossdifferentsystems.Theprocessingofeventsisasynchronoussothatdifferentnodescanfinishprocessingatdifferentpointsintime.Theexpenditurefordevelopmentandinfrastructureishigher.Moresystemcomponentsandmorecomplexcommunicationtechnologiesarerequired.

ItisnotsensibletoimplementeachMicroservicewithCQRS.However,theapproachrepresentsinmanycircumstancesagoodsupplementforMicroservice-basedarchitectures.

10.3EventSourcingEventSourcinghasasimilarapproachlikeCQRS.However,theeventsfromEventSourcingdifferfromthecommandsfromCQRS.Commandsarespecific:Theyexactlydefinewhatistobechangedinanobject.Eventscontaininformationaboutsomethingthathashappened.Bothapproachescanalsobecombined:A

commandcanchangedata.Thiswillresultineventstowhichothercomponentsofthesystemcanreact.

InsteadofthestateitselfEventSourcingstoreseventswhichhaveleadtothecurrentstate.Whilethestateitselfisnotsaved,itcanbereconstructedfromtheevents.

Fig.46:OverviewofEventSourcing

Fig.46givesanoverviewofEventSourcing:

TheEventQueuesendsalleventstothedifferentrecipients.Itcanforinstancebeimplementedwithmessagingmiddleware.TheEventStoresavesallevents.Therefore,itisalwayspossibletoreconstructthechainofeventsandtheeventsthemselves.AnEventHandlerreactstotheevents.Itcancontainbusinesslogicwhichreactstoevents.

Insuchasystemitisonlytheeventswhichareeasytotrace.Thecurrentstateofthesystemisnoteasytofollowupon.Therefore,itcanbesensibletomaintainaSnapshotwhichcontainsthecurrentstate.AteacheventorafteracertaintimethedataintheSnapshotwillbechangedinlinewiththenewevents.TheSnapshotisoptional.Itisalsopossibletoadhocreconstructthestatefromtheevents.

Eventsmaynotbechangedafterwards.Erroneouseventshavetobecorrectedbynewevents.

EventSourcingisbasedonDomain-DrivenDesign(comparesection4.3).Therefore,inlinewithUbiquitousLanguage,theeventsshouldhavenameswhicharealsosensibleinthebusinesscontext.Insomedomainsanevent-basedmodelisespeciallysensiblefromadomainperspective.Forinstance,bookingstoanaccountcanbeconsideredasevents.RequirementslikeauditingareveryeasytoimplementwithEventSourcing:Sincethebookingismodeledasanevent,itisveryeasytotracewhohasperformedwhichbooking.Inaddition,itisrelativelyeasytoreconstructahistoricalstateofthesystemandoldversionsofthedata.EventSourcingcanbeagoodoptionfromadomainperspective.Generally,approacheslikeEventSourcingaresensibleincomplexdomainswhichalsoprofitfromDomain-drivenDesign.

EventSourcinghassimilaradvantagesanddisadvantageslikeCQRS,andbothapproachescaneasilybecombined.EventSourcingisespeciallysensiblewhentheoverallsystemworkswithanEvent-drivenArchitecture(section8.6).InthatcasetheMicroservicesanyhowsendalreadyeventsconcerningchangesofthestateanditissensibletousethisapproachalsointheMicroservices.

TryandExperiment

Chooseaprojectyouknow.

InwhichplaceswouldEventSourcingbesensible?Why?WouldEventSourcingbeuseableinanisolatedmanneratsomeplacesorwouldtheentiresystemhavetobechangedtoEvents?

WherecouldCQRSbehelpful?Why?

DotheinterfacesadheretotheCQRrule?Inthatcasethereadandwriteoperationswouldhavetobeseparateinallinterfaces.

10.4HexagonalArchitectureAHexagonalArchitecturefocusesonthelogicoftheapplication(Fig.47).Thelogiccontainsonlythebusinessfunctionalities.Ithasdifferentinterfaceswhichareeachrepresentedbyanedgeofthehexagon.Intheexamplethesearetheinterfacefortheinteractionwithusersandtheinterfaceforadministrators.UserscanutilizetheseinterfacesviaawebinterfacewhichisimplementedbyHTTPadaptors.Forteststherearespecialadaptors.Theyenabletheteststosimulateusers.Finally,thereisanadaptorwhichmakesthelogicalsoaccessibleviaREST.ThisallowsotherMicroservicestocallthelogic.

Interfacesdonotonlytakerequestsfromothersystems.Inaddition,alsoothersystemsarecontactedviasuchinterfaces:thedatabaseviatheDBadaptorwhichinfactusesadatabase.Thealternativeisanadaptorfortestdata.Finally,anotherapplicationcanbecontactedviaaRESTadaptor.Insteadoftheseadaptorsatestsystemcanbeusedwhichsimulatestheusedsystem.

Fig.47:OverviewofHexagonalArchitecture

AnothernameforHexagonalArchitecturesis“PortsandAdaptors”.Eachfacetoftheapplicationlikeuser,admin,dataoreventisaport.TheadaptorsimplementtheportsbasedontechnologieslikeRESTorwebuserinterfaces.Viatheportsontherightsideofthehexagontheapplicationfetchesdata,whileviatheportsontheleftsideitsfunctionalitiesanddataforuserandothersystemsareoffered.

TheHexagonalArchitecturedividesasystemintoalogickernelandadaptors.Onlytheadaptorsenablethecommunicationtotheoutside.

HexagonsorLayers?

AHexagonalArchitectureisanalternativetoalayeredarchitecture.InalayeredarchitecturethereisalayerinwhichtheUIisimplementedandalayerinwhichthepersistenceisimplemented.InaHexagonalArchitecturethereareadaptorswhichareconnectedtothelogicviaports.AHexagonalArchitectureclearlyshowsthattherecanbemoreportsthanjustpersistenceandUI.Besidestheterm“adaptor”illustratesthatthelogicandtheportsaresupposedtobeseparatefromtheconcreteprotocolsandimplementationsoftheadaptors.

HexagonalArchitecturesandMicroservices

ItisverynaturalforHexagonalArchitecturestoofferlogicnotonlyforotherMicroservicesviaaRESTinterface,butalsoforusersviaawebUI.Exactlythis

ideaisalsothebasisofMicroservices.TheyarenotonlysupposedtoprovidelogicforotherMicroservices,butshouldalsosupportthedirectinteractionofusersviaaUI.

Sinceindividualtestimplementationscanbeimplementedforallports,theisolatedtestingofaMicroserviceiseasierwithaHexagonalArchitecture.Forthispurpose,testadaptorsjusthavetobeusedinsteadoftheactualimplementation.EspeciallytheindependenttestingofindividualMicroservicesisanimportantprerequisitefortheindependentimplementationandtheindependentdeploymentofMicroservices.

Thenecessarylogicforresilienceandstability(comparesection10.5)orLoadBalancing(section8.10)canalsobeimplementedintheadaptor.

ItislikewiseimaginabletodistributetheadaptorsandtheactuallogicintoindividualMicroservices.Thiswillresultinmoredistributedcommunicationandthereforeintoanoverhead.However,ontheotherhandtheimplementationofadaptorandkernelcanbedistributedtodifferentteams.Forinstance,oneteamwhichdevelopsamobileclientcanimplementaspecificadaptorwhichisadaptedtothebandwidthrestrictionsofmobileapplications(comparealsosection9.1).

AnExample

AMicroserviceforordersshallserveasexampleforaHexagonalArchitecture(Fig.48).TheusercanutilizethefunctionalitiesoftheMicroserviceviathewebUItoplaceorders.LikewisethereisaRESTinterfacewithwhichotherMicroservicesorexternalclientscanusethe“userfunctionalities”.ThewebUI,theRESTinterfaceandthetestadaptorarethreeadaptorsforthe“userfunctionalities”oftheMicroservice.TheimplementationwiththreeadaptorsemphasizesthatRESTandwebUIarejusttwooptionstousethesamefunctionalities.Besides,inthismannerMicroservicesareimplementedwhichintegrateUIandREST.TechnicallytheadaptorscanstillbeimplementedinseparateMicroservices.

Fig.48:TheorderMicroserviceasanexampleforHexagonalArchitecture

Anotherinterfacearetheorderevents.TheyannouncetotheMicroservice“Delivery”whennewordershavearrivedsothattheorderscanbedelivered.ViathisinterfacetheMicroservice“Delivery”communicatesalsowhenanorderhasbeendeliveredorwhendelayshaveoccurred.Inaddition,thisinterfacecanbeservedbyanadaptorfortests.Therefore,theinterfacetotheMicroservice“Delivery”doesnotjustsimplywritedata,butcanalsointroducechangestotheorders.ThismeansthattheinterfaceusesotherMicroservices,butdoesalsoitselftakechanges.

TheHexagonalArchitecturehasadomain-baseddistributionintoaninterfaceforuserfunctionalitiesandaninterfacefororderevents.Therebythearchitectureunderlinesthedomain-baseddesign.

Thestateoftheordersissavedinadatabase.Alsointhiscasethereisaninterfacewheretestdatacanbeusedfortestsinsteadofthedatabase.Thisinterfacecorrespondstothepersistencelayerofaclassicalarchitecture.

Finally,thereisaninterfacewhichviadatareplicationtransmitstheinformationregardingtheordertoreporting.Therestatisticscanbegeneratedfromtheorders.Reportingappearstobeapersistenceinterface,butisreallymore:Thedataarenotjuststored,butchangedtoenablequickgenerationofstatistics.

Astheexampleshows,aHexagonalArchitecturecreatesagooddomain-baseddistributionintodifferentdomain-basedinterfaces.Eachdomain-basedinterfaceandeachadaptorcanbeimplementedasaseparateMicroservice.ThisallowstodividetheapplicationintonumerousMicroservices,ifnecessary.

TryandExperiment

Chooseaprojectyouknow.

Whichindividualhexagonswouldtherebe?

Whichportsandadaptorswouldthehexagonshave?

WhichadvantageswouldaHexagonalArchitectureoffer?

Whatwouldtheimplementationlooklike?

10.5ResilienceandStabilityThefailureofaMicroserviceshouldaffecttheavailabilityofotherMicroservicesaslittleaspossible.AsaMicroservice-basedsystemisadistributedsystem,thedangerofafailureisfundamentallyhigher:Networkandserversareunreliable.AsMicroservicesaredistributedonmultipleservers,thenumberofserversishigherpersystemandthereforealsotheprobabilityofafailure.Whenthefailure

ofoneMicroservicecanresultinthefailureofadditionalMicroservices,stepbysteptheentiresystemcanbreakdown.Thishastobeavoided.

Forthisreason,MicroserviceshavetobeshieldedfromthefailureofotherMicroservices.Thispropertyiscalledresilience.ThenecessarymeasurestoachieveresiliencehavetobepartoftheMicroservice.Stabilityisabroadertermwhichdenotesahighsoftwareavailability.“ReleaseIt!”1listsseveralpatternstothistopic:

Timeout

Timeoutshelptodetectunavailabilitywhencommunicatingwithanothersystem.Ifnoresponsehasbeenreturnedafterthetimeout,thesystemisconsideredunavailable.Unfortunately,manyAPIsdonothavethepossibilitytodefinetimeouts,andsomedefaulttimeoutsareveryhigh.AttheleveloftheoperatingsystemdefaultTCPtimeoutscanbee.g.fiveminutes.DuringthistimetheMicroservicedoesnotrespondtocallerssincetheserviceiswaitingfortheotherMicroservice.Therefore,alsothisMicroserviceseemstohavefailed.Besidestherequestcanblockathreadduringthistime.Atsomepointallthreadsareblocked,andtheMicroservicecannotreceiveanyadditionalrequestsanymore.Exactlysuchadominoeffecthastobeavoided.WhentheAPIintendsatimeoutforaccessinganothersystemoradatabase,thistimeoutshouldbeset.Analternativeoptionistoletallrequeststoexternalsystemsordatabasestakeplaceinaextrathreadandtoterminatethisthreadafteratimeout.

CircuitBreaker

ACircuitBreakerisasafetymeasureinanelectricitycircuit.IncaseofashortcircuittheCircuitBreakerinterruptstheflowofelectricitytoavoiddangerousconsequenceslikeoverheatingorfire.Thisideacanbeappliedtosoftwareaswell:Whenanothersystemisnotavailableanymoreorreturnsonlyerrors,aCircuitBreakerpreventscallingthesystem.Callsareanyhowmeaninglessinthisscenario.

Normally,theCircuitBreakerisclosed,andcallsareforwardedtotheothersystem.Whenanerroroccurs,dependingontheerrorfrequencytheCircuitBreakerwillbeopened.Inthatcasecallsarenotsendontotheothersystem,butrundirectlyintoanerror.

Thistakesloadofftheothersystem.Alsothereisnoneedforatimeoutastheerrorisinstantaneous.AftersometimetheCircuitBreakerwillcloseagain.

Incomingcallswillnowbeforwardedagaintotheothersystem.Iftheerrorpersists,theCircuitBreakerwillopenagain.

TheCircuitBreakercanbecombinedwithatimeout.AtimeoutcanopentheCircuitBreaker.ThestateoftheCircuitBreakersshowsoperationswherecurrentlyproblemsinthesystemare.AnopenCircuitBreakerindicatesthataMicroserviceisnotabletocommunicatewithanotherMicroserviceanymore.Therefore,thestateoftheCircuitBreakersshouldbedisplayedinmonitoringforoperations.

WhentheCircuitBreakerisopen,anerrordoesnotnecessarilyhavetobegenerated.Itisalsopossibletojustdegradethefunctionality.LetusassumethataAutomatedTellerMachine(ATM)cannotverifywhetheranaccountcontainsenoughmoneyforthedesiredwithdrawal,becausetheresponsiblesystemisnotreachable.Nevertheless,cashwithdrawalscanbepermitteduptoacertainlimitsothatcustomerswillnotbedissatisfied.Inaddition,thebankwillmakelessprofitifallcashwithdrawalsareprohibitedasitwillnotgetthewithdrawal-associatedfees.Whetheranduptowhichlimitacashwithdrawalisstillpermittedisabusinessdecision.Thepossibledamagehastobebalancedagainstthepotentialforprofit.Therecanalsobeotherrulestobeappliedincaseofthefailureofanothersystem.Callscanforinstancebeansweredfromacache.Moreimportantthanthetechnicalpossibilitiesisthedomain-basedrequirementfordecidingontheappropriatehandlingofasystemfailure.

Bulkhead

ABulkheadisaspecialdooronashipwhichcanbeclosedinawatertightmanner.Itdividestheshipintoseveralareas.Whenwatergetsin,onlyapartoftheshipisaffected,andthustheshipwillnotsink.

Similarapproachesareapplicabletosoftware:Theentiresystemhastobedividedintoindividualareas.Abreakdownoraprobleminoneareamaynotaffecttheotherareas.Forexample,therecanbeseveralinstancesofaMicroservicefordifferentclients.WhenaclientoverloadstheMicroservices,theotherclientswillnotbenegativelyaffected.Thesameistrueforresourceslikedatabaseconnectionsorthreads.WhendifferentpartsofaMicroserviceusedifferentpoolsfortheseresources,onepartcannotblocktheotherpartsevenifitusesupallitsresources.

InMicroservices-basedarchitecturestheMicroservicesthemselvesformseparateareas.ThisisespeciallythecasewheneachMicroservicebringsitsownvirtualmachinealong.EveniftheMicroservicecausestheentirevirtualmachinetocrashoroverloadsit,theotherMicroserviceswillhardlybeaffected.Theyrunondifferentvirtualmachinesandarethereforeseparate.

SteadyState

ThetermSteadyStatestandsforthefactthatsystemsshouldbebuiltinamannerthatallowsfortheirpermanentoperation.Thismeansforinstancethatsystemsshouldnotstoreincreasingamountsofdata.Otherwisethesystemwillhaveusedupitsentirecapacityatsomepointandthereforebreakdown.Logfilesforexamplehavetobedeletedatsomepoint.Usuallytheyareanyhowonlyinterestingduringacertaintimeinterval.Anotherexampleiscaching:Whenacachealwayskeepsgrowing,itwillatsomepointhavefilledallstoragespace.Thereforevaluesalsohavetobedeletedagainfromcacheatsomepointtokeepthecachefrompermanentlygrowing.

FailFast

Timeoutsareonlynecessarybecauseanothersystemrequiresalongtimetorespond.TheideabehindFailFastistoaddresstheproblemfromtheotherside:Eachsystemissupposedtorecognizeerrorsasfastaspossibleandtoindicatethemimmediately.Whenacallrequiresacertainserviceandthisserviceisunavailableforthemoment,thecallcanbedirectlyansweredwithanerrormessage.Thesameistruewhenotherresourcesarenotavailableatthetime.Moreover,thecallcanbevalidatedrightatthestart.Whenitcontainserrors,thereisanyhownothinggainedbyprocessingit.Therefore,anerrormessagecanbereturnedimmediately.TheadvantagesofFailFastareidenticalwiththeonesofferedbytimeout:Arapidfailureusesuplessresourcesandthereforeresultsinamorestabilesystem.

Handshaking

Handshakinginaprotocolservestoinitiatecommunication.Therebyprotocolsallowthataserverrejectsadditionalcallsincasesofoverload.Thisavoidsadditionaloverload,abreakdownortooslowresponses.Unfortunately,protocolslikeHTTPdonotsupportthis.Therefore,theapplicationhastomimicthefunctionalityforinstancewithHealthChecks.Anapplicationcansignalinthatwaythatitisprincipallyreachable,buthasrightnowsomuchloadthatitisnotsensibletosendmorecallstoit.Protocolswhichbuildonsocketconnectionscanimplementsuchapproachesbythemselves.

TestHarness

ATestHarnesscanbeusedtofindouthowanapplicationbehavesincertainerrorsituations.AmongthosecanbeproblemsattheleveloftheTCP/IPorforinstanceresponsesofothersystemswhichcontainHTTPheader,butnoHTTPbody.Somethinglikethatshouldinfactnotoccursinceoperatingsystemornetworkstackshoulddealwithit.Nevertheless,sucherrorscanoccurinpracticeandcanhavedramaticconsequencessinceapplicationsarenotatallpreparedforhandlingthem.ATestHarnesscanbeanextensionofthetestswhicharediscussedinsection11.8.

UncouplingviaMiddleware

Callsinoneprogramonlyfunctiononthesamehostatthesametimeinthesameprocess.Synchronousdistributedcommunication(e.g.REST)allowsforcommunicationbetweendifferenthostsanddifferentprocessesatthesametime.Asynchronouscommunicationviamessagingsystems(section9.4)alsoallowsanuncouplingovertime.Asystemshouldnotwaitforaresponseofanasynchronousprocess.Thesystemshouldcontinueworkingonothertasksinsteadofjustwaitingforaresponse.Errorswhichcauseonesystemafteranothertobreakdownlikedominostonesaremuchlesslikelyincaseofasynchronouscommunication.Thesystemsareforcedtodealwithlongresponsetimessinceasynchronouscommunicationanyhowcanresultinlongresponsetimes.

StabilityandMicroservices

StabilitypatternslikeBulkheadrestrictfailurestoaunit.Microservicesaretheobviouschoiceforaunit.Theyrunonseparatevirtualmachinesandaccordinglyarealreadyisolatedinregardstomostissues.TherebytheBulkheadpatternarisesverynaturallyinaMicroservices-basedarchitecture.Fig.49showsanoverview:AMicroservicecanviaBulkhead,CircuitBreakerandtimeoutssafeguardtheuseofotherMicroservices.TheusedMicroservicecanadditionallyimplementFailFast.ThesafeguardingcanbeimplementedviapatternsinthosepartsofaMicroservicewhichareresponsibleforcommunicatingwithotherMicroservices.Therebythisaspectisimplementedinoneareaofthecodeandnotdistributedacrosstheentirecode.

Fig.49:StabilityinthecaseofMicroservices

Onatechnicallevelthepatternscanbeimplementeddifferently.ForMicroservicestherearethefollowingoptions:

Timeoutsareeasytoimplement:Foraccessingtheothersystemanindividualthreadisstartedwhichisterminatedafteratimeout.AtthefirstglanceCircuitBreakersarenotverycomplexandcanbedevelopedinyourowncode.However,theimplementationhasalsotoworkunderhighloadandhastoofferaninterfaceforoperationstoallowmonitoring.Thisisnottrivial.Thereforeahome-grownimplementationisnotverysensible.BulkheadsarebroughtalongbyMicroservicessinceaproblemisinmanycasesalreadylimitedtojustoneMicroservice.Forinstance,amemoryleakwillonlycauseoneMicroservicetofail.SteadyState,FailFast,HandshakingandTestHarnesshavetobeimplementedbyeachMicroservice.UncouplingviaMiddlewareisanoptionforthesharedcommunicationofMicroservices.

ResilienceandReactive

TheReactiveManifestolistsResilienceasessentialpropertyofaReactiveapplication.Resiliencecanbeimplementedinanapplicationbyprocessingcallsasynchronously.Eachpartofanapplicationwhichprocessesmessages(“actor”)hastobemonitored.Whenanactordoesnotreactanymore,itcanberestarted.Thisallowstohandleerrorsandtomakeapplicationsmoreresilient.

Hystrix

HystriximplementstimeoutandCircuitBreaker.Forthispurpose,developershavetoencapsulatecallsincommands.Alternatively,Javaannotationscanbeused.Thecallstakeplaceinindividualthreadpools.Severalthreadpoolscanbe

created.IfthereisonethreadpoolpercalledMicroservice,thecallsoftheMicroservicescanbeseparatedfromeachotherinsuchamannerthataproblemwithoneMicroservicedoesnotaffecttheuseoftheotherMicroservices.ThisisinlinewiththeBulkheadidea.HystrixisaJavalibrarywhichisunderApachelicenseandoriginatesfromtheNetflixstack.TheexampleapplicationusesHystrixtogetherwithSpringCloud(comparesection14.10).IncombinationwithaSidecarHystrixcanalsobeusedforapplicationswhicharenotwritteninJava(comparesection8.7).HystrixsuppliesinformationaboutthestateofthethreadpoolsandtheCircuitBreakerformonitoringandoperation.Thisinformationcanbedisplayedinaspecialmonitoringtool–theHystrixdashboard.InternallyHystrixusestheReactiveExtensionsforJava(RxJava).HystrixisthemostwidelyusedlibraryintheareaofResilience.

TryandExperiment

Thischapterintroducedeightpatternsforstability.Prioritizethesepatterns.Whichpropertiesareindispensable?Whichareimportant?Whichareunimportant?

HowcanbeverifiedwhethertheMicroservicesreallyimplementthepatterns?

10.6TechnicalArchitectureThetechnicalarchitectureofaMicroservicecanbeindividuallydesigned.FrameworksorprogramminglanguagesdonothavetobeuniformforallMicroservices.Therefore,eachMicroservicecanwellusedifferentplatforms.However,certaintechnicalinfrastructuresfitbettertoMicroservicesthanothers.

ProcessEngines

ProcessengineswhichnormallyservetoorchestrateservicesinaSOA(section7.1)canbeusedinaMicroservicetomodelabusinessprocess.TheimportantpointisthatoneMicroserviceimplementsonlyonedomain–forinstanceoneBoundedContext.AMicroserviceshouldnotendupasapureintegrationororchestrationofotherMicroserviceswithoutitsownlogic.OtherwisechangeswillrequirethatnotonlythisoneMicroserviceismodified,butalsotheintegratedMicroservices.However,itisacentralaimofMicroservice-based

architecturestolimitchangestooneMicroserviceifpossible.Ifmultiplebusinessprocesseshavetobeimplemented,differentMicroservicesshouldbeusedforit.EachoftheseMicroservicesshouldimplementonebusinessprocesstogetherwiththedependentservices.Ofcourse,itwillnotalwaysbepossibletoavoidthatotherMicroserviceshavetobeintegratedtoimplementabusinessprocess.However,aMicroservicewhichjustrepresentsanintegrationisnotsensible.

Statelessness

StatelessMicroservicesareveryadvantageous.Toputitmoreclearly:Microservicesshouldnotsaveanystateintheirlogiclayer.Statesinthedatabaseorontheclientareacceptable.Whenusingthisapproachthefailureofanindividualinstancedoesnothaveabigimpact.Theinstancecanjustbereplacedbyanewinstance.Inaddition,theloadcanbedistributedbetweenmultipleinstances–withouthavingtotakeintoconsiderationwhichinstanceprocessedthepreviouscallsoftheuser.Andfinally,thedeploymentofanewversioniseasiersincetheoldversioncanjustbestoppedandreplacedwithouthavingtomigrateitsstate.

Reactive

ImplementingMicroserviceswithReactivetechnologiescanbeespeciallyuseful.TheseapproachesarecomparabletoErlang(comparesection15.7):Applicationsconsistofactors.InErlangtheyarecalledprocesses.Workineachactorissequential,however,differentactorscanworkinparallelondifferentmessages.Thisenablestheparallelprocessingoftasks.Actorscansendmessagestootheractorswhichendupinthemailboxesoftheseactors.I/OoperationsarenotblockinginReactiveapplications:Arequestfordataissentout.Whenthedataarethere,theactoriscalledandcanprocessthedata.Inthemeantimetheactorscanworkonotherrequests.

EssentialpropertiesareaccordingtotheReactiveManifesto:

Responsive:Thesystemshouldreacttorequestsasfastaspossible.ThishasamongothersadvantagesforFailFastandthereforeforstability(comparesection10.5).Oncethemailboxisfilledtoacertainpredetermineddegree,theactorcanforinstancerejecttoacceptadditionalmessages.Therebythesenderissloweddown,andthesystemassuchdoesnotgetoverloaded.Otherrequestscanstillbeprocessed.TheaimtoberesponsiveisalsosupportedbytheabdicationofblockingI/Ooperations.

ResilienceanditsrelationshipwithReactiveapplicationshasalreadybeendiscussedinsection10.5.Elasticmeansthatnewsystemscanbestartedatruntimewhichsharetheload.Forthatpurposethesystemhastobescalable,andatthesametimeithastobepossibletochangethesystematruntimeinsuchawaythattheloadcanbedistributedtothedifferentnodes.MessageDrivenmeansthattheindividualcomponentscommunicatewitheachotherviamessaging.Asdescribedinsection9.4,thiscommunicationfitswelltoMicroservices.Reactiveapplicationsuseverysimilarapproachesalsowithintheapplicationitself.

ReactivecanimplementMicroservicesespeciallyeasilysincetheideasfromtheReactiveareafitverywelltoMicroservices.However,similarlygoodresultscanalsobeachievedbytheuseofclassicaltechnologies.

TechnologiesfromtheareaofReactiveareforinstance:

TheprogramminglanguageScalawiththeReactiveframeworkAkkaandwebframeworkPlaywhichisbasedonit.TheseframeworkscanalsobeusedwithJava.ThereareReactiveextensionsforpracticallyallpopularprogramminglanguages.AmongthoseareRxJavaforJavaorRxJSforJavaScript.SimilarapproachesarealsosupportedbyVert.x(comparealsosection15.6).EventhoughthisframeworkisbasedontheJVM,itsupportsmanydifferentprogramminglanguageslikeJava,Groovy,Scala,JavaScript,Clojure,RubyorPython.

MicroserviceswithoutReactive?

ReactiveisonlyoneoptionforimplementingasystemwithMicroservices.TheclassicalprogrammingmodelwithblockingI/O,withoutactorsandwithsynchronouscallsislikewisesuitableforthistypeofsystem.Aspreviouslydiscussed,Resiliencecanbeimplementedvialibraries.ElasticcanbeachievedbystartingnewinstancesoftheMicroservicesforinstanceasvirtualmachinesorDockercontainers.Andclassicalapplicationscanalsocommunicatewitheachotherviamessages.ReactiveapplicationshaveadvantagesforResponsive.However,inthatcaseithastobeensuredthatoperationsreallydonotblock.ForI/OoperationstheReactivesolutionscanusuallyguaranteethat.However,acomplexcalculationcanblockthesystem.Sointhatcasenomessagescanbeprocessedanymore,andtheentiresystemisblocked.AMicroservicedoesnot

havetobeimplementedwithReactivetechnologies,buttheyareforsureaninterestingalternative.

TryandExperiment

GetmoreinformationaboutReactiveandMicroservices.

Howexactlyaretheadvantagesimplemented?

IsthereaReactiveextensionforyourpreferredprogramminglanguage?Whichfeaturesdoesitoffer?HowdoesthishelpwithimplementingMicroservices?

10.7ConclusionTheteamimplementingacertainMicroserviceisalsoresponsibleforitsdomain-basedarchitecture.Thereshouldbefewguidelinesrestrictingteamdecisionssothattheindependenceoftheteamsisensured.

Lowcohesioncanbeanindicationforaproblemwiththedomain-baseddesignofaMicroservice.Domain-drivenDesign(DDD)isaninterestingoptionforstructuringaMicroservice.Likewisetransactionscanprovidecluesforasensibledomain-baseddivision:AnoperationofaMicroserviceshouldbeatransaction(section10.1).

CQS(CommandQuerySeparation)dividesoperationsofaMicroserviceoraclassintoreadoperations(queries)andwriteoperations(commands).CQRS(CommandQueryResponsibilitySegregation)(section10.2)separatesdatachangesviacommandsfromQueryHandlerswhichcanprocessrequests.TherebyMicroservicesorclassesarecreatedwhichcanonlyimplementreadingorwritingaccess.EventSourcing(Section10.3)storeseventsandtherebydoesnotfocusonthecurrentstate,butonthehistoryofallevents.TheseapproachesareusefulforbuildingupMicroservicesbecausetheyallowforthecreationofsmallerMicroserviceswhichcanimplementonlyreadorwriteoperations.Thisenablesanindependentscalingandoptimizationsforbothtypesofoperations.

HexagonalArchitecture(section10.4)focusesonakernelwhichcanbecalledviaadaptorsforinstancebyaUIoranAPI,asthecenterpointofeachMicroservice.LikewiseadaptorscanenabletheuseofotherMicroservicesorofdatabases.ForMicroservicesthisresultsinanarchitecturewhichsupportsaUIandaRESTinterfaceinaMicroservice.

Section10.5haspresentedsomepatternsforResilienceandStability.ThemostimportantofthoseareCircuitBreaker,TimeoutandBulkhead.ApopularimplementationisHystrix.

Section10.6introducedcertaintechnicaloptionsforMicroservices:TheuseofProcessEnginesisforinstanceanoptionforaMicroservice.Statelessnessisadvantageous.Andfinally,ReactiveapproachesareagoodbasisfortheimplementationofMicroservices.

Insummary,thechapterexplainedessentialfactorsfortheimplementationofindividualMicroservices.

EssentialPoints

MicroserviceswithinaMicroservice-basedsystemcanhavedifferentdomain-basedarchitectures.MicroservicescaninternallybeimplementedwithEventSourcing,CQRSorHexagonalArchitectures.TechnicalpropertieslikestabilitycanonlybeimplementedindividuallybyeachMicroservice.

1. MichaelT.Nygard:ReleaseIt!:DesignandDeployProduction-ReadySoftware,PragmaticProgrammers,2007,ISBN978-0-97873-921-8↩

11TestingMicroservicesandMicroservice-basedSystems

TheseparationofasystemintoMicroserviceshasconsequencesfortesting.Section11.1explainsthemotivationbehindsoftwaretests.Section11.2discussesfundamentalapproachesfortests,notonlyinregardstoMicroservices.Section11.3illustrateswhytherearespecialchallengeswhentestingMicroserviceswhicharenotpresentinthisforminothersystems.Oneexample:InaMicroservice-basedsystemtheentiresystemcomprisingallMicroserviceshastobetested(section11.4).ThisislaborioussincetherecanbeamultitudeofMicroservices.Section11.5describesthespecialcaseofalegacyapplicationwhichissupposedtobereplacedbyMicroservices.InthatcasetheintegrationofMicroservicesandlegacyapplicationhastobetested.TestingjusttheMicroservicesisnotsufficient.AnotherpossibilitytosafeguardtheinterfacesbetweenMicroservicesareconsumer-drivencontracttests(section11.7).Theyreducetheexpenditurefortestingtheentiresystem.Ofcourse,theindividualMicroserviceshavetobetestedaswell.InthiscontextthequestionariseshowindividualMicroservicescanatallberuninisolationwithoutotherMicroservices(section11.6).Microservicesprovidetechnologyfreedom,neverthelesstherehavetobecertainstandards.Thereforetestscancomprisetechnicalstandards(section11.8)whichhavebeendefinedinthearchitecture.

11.1WhyTests?Testingsoftwareisanessentialpartofeverysoftwaredevelopmentproject.Nevertheless,questionsaboutthegoalofthetestingarehardlyasked.Intheendtestsareriskmanagement.Theyaresupposedtominimizetheriskthaterrorsappearinproductionandarenoticedbyusers–orthatotherdamageisdone.

Thisanswerentailsanumberofconsequences:

Eachtesthastobeevaluatedbasedonthequestionwhichriskitminimizes.Intheendatestisonlymeaningfulwhenithelpstoavoidconcreteerrorscenarioswhichotherwisewouldoccurinproduction.

Testsrepresentonlyoneoptiontodealwithrisk.Consequencesofanerroroccurringinproductioncanalsobeminimizedindifferentways.Animportantpointishowlongitwilltakeuntilacertainerroriscorrectedinproduction.Thelongeranerrorpersistsinproduction,themoreprofoundareusuallytheconsequences.Howlongittakestoputacorrectedversionoftheservicesintoproductiondependsonthedeploymentapproach.Therefore,thereisaconnectionbetweentestsanddeploymentstrategies.Likewise,itisaveryimportantaspecthowlongitwilltakeuntilanerrorinproductionisnoticed.Thisdependsonthequalityofmonitoringandlogging.

Intheendmanymeasurescanaddresserrorsinproduction.Justfocusingontestsisnotsufficientinordertobeabletoofferhighqualitysoftwaretocustomers.

TestsMinimizeExpenditure

Testscandomorethanjustminimizerisk.Theycanhelptominimizeoravoidexpenditure.Anerrorinproductioncangenerateahighexpenditure.Theerrorcaninfluencethecustomerserviceandcancauseextraexpenditurethere.Identifyingandcorrectingerrorsinproductionisusuallymorelaboriousthanduringtests.Accesstothesystemsisoftenrestricted.Besidesthedeveloperswillhaveimplementedotherfeaturesmeanwhilesothattheywillfirsthavetofamiliarizethemselvesagainwiththeerroneouscode.

Inaddition,theapproachfortestscanhelptoavoidorreduceexpenditure.Automatingtestsonlyappearslaboriousatfirstglance.Whentestsaresowelldefinedthatresultsarereproducible,thesteptoacompleteformalizationandautomationisnothuge.Inthatcasethecostsfortheexecutionofthetestswillbenegligible.Thisallowstotestmorefrequently,andthiswillpromotequality.

Test=Documentation

Atestdefineswhatthecodeissupposedtodo.Therebyitrepresentsakindofdocumentation.Unittestsdefinehowtheproductivecodeissupposedtobeusedandalsohowitissupposedtobehaveinexceptionalandborderlinecases.Acceptancetestsreflecttherequirementsofthecustomers.Theadvantageoftestsincomparisontodocumentationisthattheyareexecuted.Thisensuresthatthetestsreallyreflectthecurrentbehaviorandnotanoutdatedstateorastatewhichwillonlybereachedinthefuture.

Test-drivenDevelopment

Test-drivendevelopmentexploitsthefactthattestsrepresentrequirements:Inthisapproachdevelopersinitiallywritetestsandsubsequentlytheimplementation.Thisensuresthattheentirecodeissafeguardedbytests.Besides,inthatcasetestsarenotinfluencedbyknowledgeaboutthecodesincethecodedoesnotevenexistyetwhenthetestiswritten.Iftestsareonlyimplementedafterwards,developersmightnottestforcertainpotentialproblemsduetotheirknowledgeabouttheimplementation.Incaseoftest-drivendevelopmentthisisveryunlikely.Therebyteststurnintoaveryimportantbasisforthedevelopmentprocess.Theypushthedevelopment:Priortoeachchangetherehastobeatestwhichdoesnotwork.Codemayonlybeadjustedwhenthetestwassuccessful.Thisistrueatthelevelofindividualclasses,whicharesafeguardedbypreviouslywrittenunittests,butalsoatthelevelofrequirementswhichareensuredbypreviouslywrittenacceptancetests.

11.2HowtoTest?Therearedifferenttypesoftestswhichhandledifferentrisks:

UnitTests

Unittestsexaminetheunitsthesystemconsistsof-justliketheirnamesuggests.Theyminimizetheriskthattheindividualunitscontainerrors.Unittestscheckespeciallysmallunits–individualmethodsorfunctions.Forthispurpose,alldependencieshavetoreplacedbecauseotherwisenotonlytheindividualunitbutalsothedependentunitsaretested.Toreplacethedependenciestherearetwopossibilities:

Mockssimulateacertaincallwithacertainresult.Afterthecallthetestcanverifywhethertheexpectedcallsreallyhavetakenplace.AtestcanforinstancedefineaMockwhichwillreturnadefinedcustomerforacertaincustomernumber.Afterthetestitcanevaluatewhetherthecustomerhasreallybeenreadoutbythecode.InanothertestscenariotheMockcansimulateanerrorifaskedforacustomer.Therebyunittestscansimulateerrorsituationswhichotherwisewouldbehardtoreproduce.StubsontheotherhandsimulatetheentireMicroservice–however,withalimitedfunctionality.Forexample,theStubcanreturnaconstantvalue.TherebyatestcanbeperformedwithoutthereallydependentMicroservice.Forinstance,aStubcanbeimplementedwhichreturnstestcustomersforcertaincustomernumbers–eachwithcertainproperties.

Unittestsarewithintheresponsibilityofthedevelopers.Thereareunittestframeworksforallpopularprogramminglanguages.Thetestsuseknowledgeabouttheinternalstructureoftheunits.ForexampletheyreplacedependenciesbyMocksorStubs.Besides,theknowledgecanbeemployedtorunthroughallcodepathsforcodebrancheswithinthetests.ThetestsareWhiteBoxTestsbecausetheyexploitknowledgeaboutthestructureoftheunits.Actually,onewouldhavetotalkofatransparentbox,however,“WhiteBox”isthecommonlyusedterm.

Oneadvantageofunittestsistheirspeed:Evenforacomplexprojecttheunittestscanbecompletedwithinafewminutes.Therebyliterallyeachcodechangecanbesafeguardedbyunittests.

IntegrationTests

Integrationtestschecktheinterplayofthecomponents.Therebytheyaresupposedtominimizetheriskthattheintegrationofthecomponentscontainserrors.TheydonotuseStubsorMocks.ThecomponentscanbetestedasapplicationsviatheUIorviaspecialtestframeworks.Integrationtestsevaluateatleastwhethertheindividualpartsareabletocommunicatewitheachother.Furthermore,theycanforinstancetestthelogicbasedonbusinessprocesses.

Incaseswheretheytestbusinessprocessestheintegrationtestsaresimilartoacceptancetestswhichchecktherequirementsofthecustomers.ThisareaiscoveredbytoolsforBDD(Behavior-DrivenDesign)andATDD(AcceptanceTest-DrivenDesign).Thesetoolsenableatest-drivenapproachwherefirstthetestsarewrittenandafterwardstheimplementation-evenforintegrationandacceptancetests.

Integrationtestsdonotuseinformationaboutthesystemwhichistobetested.TheyarecalledBlackBoxTestssincetheydonotexploitknowledgeabouttheinternalstructureofthesystem.

UITests

UItestschecktheapplicationviatheuserinterface.Inprinciple,theyonlyhavetotestwhethertheuserinterfaceworkscorrectly.Therearenumerousframeworksandtoolsfortestingtheuserinterface.AmongthosearetoolsforwebUIs,butalsofordesktopormobileapplications.ThetestsareBlackboxtests.Sincetheytesttheuserinterface,thetestsarefragile:Changestotheuserinterfacecancauseproblemsevenifthelogicremainsunchanged.Besides,thetestsusuallyrequireacompletesystemsetupsothattheyareslow.

ManualTests

Finallytherecanbemanualtests.Theycaneitherminimizetheriskoferrorsinnewfeaturesorcheckcertainaspectslikesecurity,performanceorfeatureswhichhavepreviouslyexposedqualityproblems.Theyshouldbeexplorative:Theylookatproblemsincertainareasoftheapplications.Testswhichareaimedatdetectingwhetheracertainerrorshowsupagain(regressiontests),shouldneverbedonemanuallysinceautomatedtestsfindsucherrorseasierandinamorecost-efficientandreproduciblemanner.Manualtestingislimitedtoexplorativetests.

LoadTests

Loadtestsanalyzethebehavioroftheapplicationunderload.Performancetestsontheotherhandcheckthespeed,andcapacitytestsexaminehowmanyusersorrequeststhesystemisabletoprocess.Allofthesetestsevaluatetheefficiencyoftheapplication.Forthispurpose,theyusesimilartoolswhichmeasureresponsetimesandgenerateload.Besides,suchtestscanalsomonitortheuseofresourcesorcheckwhethererrorsoccuruponacertainload.Testswhichinvestigatewhetherasystemisabletocopewithahighloadinthelongtermarecalledendurancetests.

TestPyramid

ThedistributionoftestsisillustratedbytheTestPyramid((Fig.50)[#Fig50]):ThebroadbasisofthePyramiddemonstratesthattherearemanyunittests.Theycanberapidlyperformed,andmosterrorscanbedetectedatthislevel.Therearefewerintegrationtestssincetheyaremorelaboriousandrunlonger.Inaddition,thereareusuallynottoomanypotentialerrorsupontheintegrationoftheparts.Thelogicitselfisalsosafeguardedbytheunittests.UItestsonlyhavetoverifythecorrectnessofthegraphicaluserinterface.TheyareevenmorelaborioussinceautomatingUIiscomplicated,andacompleteenvironmentisnecessary.Manualtestsareonlyrequirednowandthen.

Test-drivendevelopmentusuallyresultsinaTestPyramid:Foreachrequirementthereisanintegrationtestwrittenandforeachchangetoaclassaunittest.Therebyautomaticallymanyintegrationtestsarecreatedandevenmoreunittests.

Fig.50:TestPyramide:Theideal

TheTestPyramidachieveshighqualitywithlowexpenditure.Thetestsareautomatedasmuchaspossible.Eachriskisaddressedwithatestthatisassimpleaspossible:Logicistestedbysimpleandrapidunittests.Morelaborioustestsarerestrictedtoareaswhichcannotbetestedwithlesseffort.

ManyprojectsareveryremotefromtheidealoftheTestPyramid.Unfortunately,inrealitytestsareoftenratherlikeanice-creamcone(Fig.51.Inthatcasetherearethefollowingchallenges:

Therearecomprehensivemanualtestssincesuchtestsareveryeasy.Besides,manytestersdonothavesufficientexperiencewithtestautomation.

Especiallyifthetestersarenotabletowritemaintainabletestcode,itishardlypossibletoautomatetests.Testsviatheuserinterfacearetheeasiesttypeofautomationbecausetheyareverysimilartothemanualtests.Whenthereareautomatedtests,itismostlyUItests.Unfortunately,automatedUItestsarefragile:Changestothegraphicaluserinterfaceoftenalreadyleadtoproblems.Sincethetestsaretestingtheentiresystem,theyareslow.Ifthetestsareparallelized,thereareoftenfailuresbecausethesystemexperiencesatoohighload.Thereareratherfewintegrationtests.Suchtestsrequireacomprehensiveknowledgeaboutthesystemandaboutautomationtechniques,whichtestersoftenlack.Therecanbeinfactmoreunitteststhanpresentedintheschema.However,theirqualityisoftenbadsincedevelopersfrequentlylackexperienceinwritingunittests.

Fig.51:TestIce-CreamCone:Fartoocommon

Inaddition,unnecessarilycomplextestsareoftenusedforcertainerrorsources.UItestsormanualtestsareusedtotestlogic.Forthispurpose,however,unittestswouldbesufficientandmuchfaster.Whentesting,developersshouldtrytoavoidtheseproblemsandtheice-creamconeandinsteadattempttoimplementaTestPyramid.

Besides,thetestconcepthastobeadjustedtotherisksoftherespectivesoftwareandprovidetestsfortherightproperties.Forexample,aprojectwhichis

predominantlyevaluatedbasedonperformanceshouldhaveautomatedloadorcapacitytests.Functionaltestsmightnotbesoimportantinthisscenario.

TryandExperiment

InwhichplacesdoestheapproachinyourcurrentprojectnotcorrespondtotheTestPyramid,buttotheTestIce-CreamCone?

Wherearemanualtestsused?Areatleastthemostimportanttestsautomated?WhatistherelationshipbetweenUItointegrationandunittests?Howisthequalityofthedifferenttests?Istest-drivendevelopmentused?Forindividualclassesoralsoforrequirements?

ContinuousDeliveryPipeline

TheContinuousDeliveryPipeline(Fig.11,section5.1)definesthedifferenttestphases.Therefore,itisinterestingforthetestingoftheMicroservicesandnotasmuchforthedeployment.TheunittestsfromtheTestPyramidareexecutedinthecommitphase.UItestscanbepartoftheacceptancetestsorcanlikewiseberuninthecommitphase.ThecapacitytestsusethecompletesystemandthereforecanberegardedasintegrationtestsfromtheTestPyramid.TheexplorativetestsarethemanualtestsfromtheTestPyramid.

AutomatingtestsisevenmoreimportantforMicroservicesthaninothersoftwarearchitectures.ThemainobjectiveofMicroservice-basedarchitecturesisindependentandfrequentsoftwaredeployment.ThiscanonlybeimplementedwhenthequalityofMicroservicesissafeguardedbytests.Otherwisethedeploymentintoproductionistoorisky.

11.3MitigateRisksatDeploymentAnimportantadvantageofMicroservicesistheirfastdeploymentduetothesmallsizeofthedeployableunits.BesidesResilienceavoidsthatthefailureofanindividualMicroservicecausesotherMicroservicesortheentiresystemtofail.Therebytheriskislowerifanerroroccursinproductioninspiteofthetests.

However,thereareadditionalreasonswhyMicroservicesminimizetheriskofadeployment:

ItismuchfastertocorrectanerrorsinceonlyoneMicroservicehastobedeployedanew.ThisisbyfarfasterandeasierthanthedeploymentofaDeploymentMonolith.ApproacheslikeBlue/GreenDeploymentorCanaryReleasing(section12.4)furtherreducetheriskassociatedwithdeployments.UsingthesetechniquesaMicroservicethatcontainsabugcanberemovedfromproductionagainwithlittleexpenditureandtimeloss.TheseapproachesareeasiertoimplementwithMicroservicessinceitislessefforttoprovidetherequiredenvironmentsforaMicroservicethanforanentireDeploymentMonolith.Theservicecanparticipateinproductionwithoutdoingactualwork.Althoughitwillgetthesamerequestsliketheversioninproduction,allchangestodatawhichthenewservicewouldtriggerarenotactuallyperformedonthedatabutonlycomparedtothemodificationsfromtheserviceinproduction.Thiscanforexamplebeachievedbymanipulationstothedatabasedriverorthedatabaseitself.Theservicecanalsouseacopyofthedatabase.ThemainpointisthatinthisphasetheMicroservicewillnotchangethedatainproduction.Inaddition,messageswhichtheMicroservicesendstotheoutsidecanbecomparedwiththemessagesoftheMicroservicesinproductioninsteadofsendingthemreallytotherecipients.WiththisapproachtheMicroservicerunsalreadywithallspecialcasesofthedatainproductionwhicheventhebesttestcannotallcover.Moreover,suchaprocedurecanprovidemorereliableinformationinregardstoperformance,althoughthewritesofthedatadonotoccursothattheperformanceisnotentirelycomparable.SuchapproachescanhardlybeimplementedforaDeploymentMonolithsinceitishardlypossibletohavetheentireDeploymentMonolithruninanotherinstanceinproduction.ThiswouldrequirealotofresourcesandaverycomplexconfigurationbecausetheDeploymentMonolithcanintroducechangestodatainnumerouslocations.EvenwithMicroservicesthisapproachisstillcomplexsincecomprehensivesupportisnecessaryinsoftwareanddeployment.Extracodehastobewrittenforcallingtheoldandthenewversionandtocomparethechangesandoutgoingmessagesofbothversions.However,thisapproachisatleastfeasible.Finally,theservicecanbecloselyexaminedviamonitoringinordertorapidlyrecognizeandsolveproblems.Thisshortensthetimeuntilaproblemisnoticedandaddressed.Themonitoringfulfillstoacertaindegreethefunctionofacceptancecriteriaofloadtests.Codewhichfailsinaloadtestshouldalsocreateanalarmduringmonitoringinproduction.Thereforeaclosecoordinationbetweenmonitoringandtestsissensible.

IntheendtheideabehindtheseapproachesistoreducetheriskassociatedwithbringingaMicroserviceintoproductioninsteadofaddressingtheriskbytests.WhenthenewversionofaMicroservicecannotchangeanydata,itsdeploymentispracticallyfreeofrisk.ThisishardlypossibleforDeploymentMonolithssincethedeploymentprocessismuchmorelaboriousandtimeconsuming,andrequiresmoreresources.Therefore,thedeploymentcannotbeperformedfast.Accordingly,thedeploymentcannoteasilyberolledbackwhenerrorsoccur.

Theapproachisalsointerestingbecausesomeriskscanhardlybeeliminatedbytests.Forexample,loadandperformancetestscanbeanindicatorforthebehavioroftheapplicationinproduction.However,thesetestscannotbecompletelyreliablesincetheamountofdataisdifferentinproduction,theuserbehaviorisdifferentandthehardwareisdifferentlysized.Itisnotfeasibletocoveralltheseaspectsinonetestenvironment.Inaddition,therecanbeerrorswhichonlyoccurwithdatasetsfromproduction.Theyarehardtosimulatewithtests.MonitoringandrapiddeploymentcaninfactbeanalternativetotestsinaMicroservicesenvironment.Itisimportanttothinkaboutwhichriskcanbereducedwithwhichtypeofmeasure-testsoroptimizationsofthedeploymentpipeline.

11.4TestingtheOverallSystemInadditiontothetestsoftheindividualMicroservicesalsotheoverallsystemhastobetested.SotherearemultipleTestPyramids:oneforeachindividualMicroserviceandoneforthesysteminitsentirety.ForthecompletesystemthereareintegrationtestsoftheMicroservices,UItestsoftheentireapplicationandmanualtests.UnittestsatthislevelarethetestsoftheMicroservicessincetheyaretheunitsoftheoverallsystem.ThesetestsconsistofacompleteTestPyramidoftheindividualMicroservices.

Fig.52:TestPyramidforMicroservices

ThetestsoftheoverallsystemareresponsibleforidentifyingproblemswhichoccurintheinterplayofthedifferentMicroservices.Microservicesaredistributedsystems.CallscanrequiretheinterplayofmultipleMicroservicestoreturnaresulttotheuser.Thisisachallengefortesting:Distributedsystemshavemanymoresourcesoferrors.Testsoftheoverallsystemhavetoaddresstheserisks.However,whentestingMicroservicesanotherapproachischosen:DuetoResiliencetheindividualMicroservicesshouldstillworkincaseofproblemswithotherMicroservices.FunctionaltestscanbeperformedwithStubsorMocksoftheotherMicroservices.InthiswayMicroservicescanbetestedwithouttheneedtobuildupacomplexdistributedsystemandexamineitinregardstoallpossibleerrorscenarios.

SharedIntegrationTests

StilleachMicroserviceshouldbetestedpriortoitsdeploymentinproductioninregardstoitsintegrationwiththeotherMicroservices.ThisnecessitateschangestotheContinuousDeliveryPipelineasitwasdescribedsection5.1:AttheendofthedeploymentpipelineeachMicroserviceshouldbetestedtogetherwiththeotherMicroservices.EachMicroserviceshouldrunthroughthissteponitsown.WhennewversionsofmultipleMicroservicesaretestedtogetheratthisstep,it

willnotbeclearwhichMicroservicemighthavecausedthefailureofthetest.OnlyifincaseofafailureitisstillclearwhichMicroservicetriggeredit,isitpossibletotestmultipleMicroservicestogetheratthisstep.Butinpracticesuchoptimizationsarehardlyfeasible.

Fig.53:IntegrationtestsattheendoftheContinuousDeliveryPipelines

ThisreasoningleadstotheproceduredepictedinFig.53:TheContinuousDeliveryPipelinesoftheMicroservicesendinacommonintegrationtestintowhicheachMicroservicehastoenterseparately.WhenaMicroserviceisintheintegrationtestphase,theotherMicroserviceshavetowaituntiltheintegrationtestiscompleted.ToensurethatindeedonlyoneMicroserviceatattimerunsthroughtheintegrationteststhetestscanbeperformedinanextraenvironment.InthatcaseonlyoneMicroservicemaybedeliveredinanewversioninthisenvironmentatagivenpointintime.TheenvironmentenforcestheserializedprocessingoftheintegrationtestsoftheMicroservices.

Suchasynchronizationpointslowsdownthedeploymentandthereforetheentireprocess.Iftheintegrationtestlastsforexampleonehour,itwillonlybepossibletoputeightMicroservicesthroughtheintegrationtestandintoproductionpereighthoursworkday.Ifthereareeightteamsintheproject,eachteamwillbeabletodeployaMicroserviceexactlyonceperday.Thisisnotsufficienttoachievearapiderrorcorrectioninproduction.Besides,thisweakensanessentialadvantageofMicroservices:ItshouldbepossibletodeployeachMicroserviceindependently.Eventhoughthisisinprinciplestillpossible,thedeploymenttakestoolong.Moreover,theMicroserviceshavenowdependenciestoeachotherduetotheintegrationtests–notatthecodelevel,butinthedeploymentpipelines.Inaddition,thingsarenotbalancedwhentheContinuousDeliverywithoutthelast

integrationtestrequiresforinstanceonlyonehour,butitisstillnotpossibletogetmorethanonereleaseintoproductionperday.

AvoidingIntegrationTestsoftheOverallSystem

ThisproblemcanbesolvedbytheTestPyramid.ItmovesthefocusfromintegrationtestsoftheoverallsystemtointegrationtestsoftheindividualMicroservicesandunittests.Whentherearefewintegrationtestsoftheoverallsystem,theywillnottakeasmuchtime.Inaddition,lesssynchronizationisnecessary,andthedeploymentinproductionisfaster.TheintegrationtestsareonlymeanttotesttheinterplaybetweenMicroservices.ItissufficientwheneachMicroservicescanreachalldependentMicroservices.Allotherriskscanbetakencareofpriortothislasttest.Withconsumer-drivencontracttests(section11.7)itisevenpossibletoexcludeerrorsinthecommunicationbetweentheMicroserviceswithouthavingtotesttheMicroservicestogether.Allthesemeasurehelptoreducethenumberofintegrationtestsandtherebytheirtotalduration.Intheendthereisnoreductioninoveralltesting–thetestingisjustmovedtootherphases:tothetestsoftheindividualMicroservicesandtotheunittests.

Thetestsfortheoverallsystemcanbedevelopedbyallteamstogether.Consistently,theyformpartofthemacroarchitecturebecausetheyconcernthesystemassuchandthereforecannotbetheresponsibilityofanindividualteam(comparesection13.3).

Thecompletesystemcanalsobetestedmanually.However,itisnotfeasiblethateachnewversionofaMicroserviceonlygoesintoproductionafteramanualtestwiththeotherMicroservices.Thedelayswilljustbetoolarge.Manualtestsofthesystemassuchcanforexampleaddressfeatureswhicharenotyetactivatedinproduction.Alternatively,certainaspectslikesecuritycanbetestedinthismannerifproblemsoccurredintheseareaspreviously.

11.5TestingLegacyApplicationsandMicroservicesMicroservicesareoftenusedtoreplacelegacyapplications.ThelegacyapplicationsareusuallyDeploymentMonoliths.ThereforetheContinuousDeliveryPipelineofthelegacyapplicationtestsmanyfunctionalitieswhichhavetobesplitintoMicroservices.BecauseofthemanyfunctionalitiestheteststepsoftheContinuousDeliveryPipelinetakeverylongforDeploymentMonoliths.Accordingly,thedeploymentinproductionisverycomplexandtakeslong.Under

suchconditionsitisunrealisticthateachsmallcodechangetothelegacyapplicationgoesintoproduction.Oftentherearedeploymentsattheendofasprintof14daysorevenonlyonereleaseperquarter.Nightlytestsinspectthecurrentstateofthesystem.TestscanbetransferredfromtheContinuousDeliveryPipelineintothenightlytests.InthatcasetheContinuousDeliveryPipelinewillbefasterbutcertainerrorsareonlyrecognizedduringthenight-timetesting.Thenthequestionariseswhichofthechangesofthepastdayisresponsiblefortheerror.

RelocatingTestsoftheLegacyApplication

WhenmigratingfromalegacyapplicationtoMicroservices,testsareespeciallyimportant.Ifjustthetestsofthelegacyapplicationareused,theywilltestanumberoffunctionalitieswhichmeanwhilehavebeenmovedtoMicroservices.InthatcasethesetestshavetoberunateachreleaseofaMicroservice–whichtakesmuchtoolong.Thetestshavetoberelocated.TheycanturnintointegrationtestsfortheMicroservices(Fig.54).However,theintegrationtestsoftheMicroservicesshouldrunrapidly.Inthisphaseitisnotnecessarytousetestsforfunctionalities,whichresideinasingleMicroservice.ThenthetestsofthelegacyapplicationhavetoturnintointegrationtestsoftheindividualMicroservicesorevenintounittests.Inthatcasetheyaremuchfaster.AndtheyrunastestsforasingleMicroservicesothattheydonotslowdownthesharedtestsoftheMicroservices.

Notonlythelegacyapplicationhastobemigrated,butalsothetests.Otherwisefastdeploymentswillnotbepossibleinspiteofthemigrationofthelegacyapplication.

ThetestsforthefunctionalitieswhichhavebeentransferredtoMicroservicescanberemovedfromthetestsofthelegacyapplication.Stepbystepthiswillspeedupthedeploymentofthelegacyapplication.Consequently,changestothelegacyapplicationwillalsogetincreasinglyeasier.

Fig.54:Relocatingtestsoflegacyapplications

IntegrationTest:LegacyApplicationandMicroservices

ThelegacyapplicationalsohastobetestedtogetherwiththeMicroservices.TheMicroserviceshavetobetestedtogetherwiththeversionofthelegacyproductionwhichisinproduction.ThisensuresthattheMicroserviceswillalsoworkinproductiontogetherwiththelegacyapplication.Forthispurpose,theversionofthelegacyapplicationrunninginproductioncanbeintegratedintotheintegrationtestsoftheMicroservices.ItistheresponsibilityofeachMicroservicetopassthetestswithoutanyerrorswiththisversion(Fig.55).

Fig.55:LegacyApplicationintheContinuousDeliveryPipelines

Whenthedeploymentcyclesofthelegacyapplicationlastdaysorweeks,anewversionofthelegacyapplicationwillbeindevelopmentinparallel.TheMicroservicesalsohavetobetestedwiththisversion.Thisensuresthattherewillnotsuddenlybeerrorsoccurringuponthereleaseofthenewlegacyapplication.TheversionofthelegacyapplicationwhichiscurrentlyindevelopmentrunsanintegrationtestwiththecurrentMicroservicesaspartofitsowndeploymentpipeline(Fig.56).ForthistheversionsoftheMicroserviceswhichareinproductionhavetobeused.

TheversionsoftheMicroserviceschangemuchmorefrequentlythantheversionofthelegacyapplication.AnewversionofaMicroservicecanbreaktheContinuousDeliveryPipelineofthelegacyapplication.TheteamofthelegacyapplicationcannotsolvetheseproblemssinceitdoesnotknowthecodeoftheMicroservices.ThisversionoftheMicroserviceispossiblyalreadyinproductionthough.InthatcaseanewversionoftheMicroservicehastobedeliveredtoeliminatetheerror–althoughtheContinuousDeliveryPipelineoftheMicroserviceranthroughsuccessfully.

Fig.56:MicroservicesintheContinuousDeliveryPipelineofthelegacyapplication

AnalternativewouldbetosendtheMicroservicesalsothroughanintegrationtestwiththeversionofthelegacyapplicationwhichiscurrentlyindevelopment.However,thisprolongstheoverarchingintegrationtestoftheMicroservicesandthereforerendersthedevelopmentoftheMicroservicesmorecomplex.

Theproblemcanbeaddressedbyconsumer-drivencontracttests(section11.7).TheexpectationsofthelegacyapplicationtotheMicroservicesandoftheMicroservicestothelegacyapplicationcanbedefinedbyconsumer-drivencontracttestssothattheintegrationtestscanbereducedtoaminimum.

Inaddition,thelegacyapplicationcanbetestedtogetherwithaStuboftheMicroservices.Thesetestsarenointegrationtestssincetheyonlytestthelegacyapplication.Thisallowstoreducethenumberofoverarchingintegrationtests.Thisconceptisillustratedinsection11.6usingtestsofMicroservicesasexample.However,thismeansthatthetestsofthelegacyapplicationhavetobeadjusted.

11.6TestingIndividualMicroservicesTestsoftheindividualMicroservicesarethedutyoftheteamwhichisresponsiblefortherespectiveMicroservice.Theteamhastoimplementthedifferenttestssuchasunittests,loadtestsandacceptancetestsaspartoftheirownContinuousDeliveryPipeline–aswouldalsobethecaseforsystemswhicharenoMicroservices.

However,MicroservicesrequireforsomefunctionalitiesaccesstootherMicroservices.Thisposesachallengeforthetests:ItisnotsensibletoprovideacompleteenvironmentwithallMicroservicesforeachtestofeachMicroservice.Ontheonehandthiswoulduseuptoomanyresources.Ontheotherhand,itisdifficulttosupplyalltheseenvironmentswiththeup-to-datesoftware.Technically,light-weightvirtualizationapproacheslikeDockercanatleastreducetheexpenditureintermsofresources.However,for50or100Microservicesalsothisapproachwillnotbesufficientanymore.

ReferenceEnvironment

AreferenceenvironmentinwhichtheMicroservicesareavailableintheircurrentversionisonepossiblesolution.ThetestsofthedifferentMicroservicescanusetheMicroservicesfromthisenvironment.However,errorscanoccurwhenmultipleteamstestdifferentMicroservicesinparallelwiththeMicroservices

fromthereferenceenvironment.Thetestscaninfluenceeachotherandtherebycreateerrors.Besidesthereferenceenvironmenthastobeavailable.Whenapartofthereferenceenvironmentbreaksdownduetoatest,inextremecasestestsmightbeimpossibleforallteams.TheMicroserviceshavetobeholdavailableinthereferenceenvironmentintheircurrentversion.Thisgeneratesadditionalexpenditure.ThereforeareferenceenvironmentisnotagoodsolutionfortheisolatedtestingofMicroservices.

Stubs

AnotherpossibilityisthesimulationoftheusedMicroservice.Forthesimulationofpartsofasystemfortestingtherearetwodifferentoptionsassection11.2presented,namelyStubsandMocks.StubsarethebetterchoiceforthereplacementofMicroservices.Theycansupportdifferenttestscenarios.TheimplementationofasingleStubscansupportthedevelopmentofalldependentMicroservices.

IfStubsareused,theteamshavetodeliverStubsfortheirMicroservices.ThisensuresthattheMicroservicesandtheStubsreallybehavelargelyidentically.Whenconsumer-drivencontracttestsalsovalidatetheStubs(comparesection11.7),thecorrectsimulationoftheMicroservicesbytheStubsisensured.

TheStubsshouldbeimplementedwithauniformtechnology.AllteamswhichuseaMicroservicealsohavetousestubsfortesting.Handlingthestubsisfacilitatedbyauniformtechnology.OtherwiseateamwhichemploysseveralMicroserviceshastomasteraplethoraoftechnologiesforthetests.

StubscouldbeimplementedwiththesametechnologyastheassociatedMicroservices.However,theStubsshoulduselessresourcesthantheMicroservices.Therefore,itisbetterwhentheStubsutilizeasimplertechnologystack.Theexampleinsection14.13usesfortheStubsthesametechnologyastheassociatedMicroservices.However,theStubsdeliveronlyconstantvaluesandruninthesameprocessastheMicroserviceswhichemploytheStub.TherebytheStubsuseuplessresources.

TherearetechnologieswhichspecializeonimplementingStubs.Toolsforclient-drivencontracttestscanoftenalsogenerateStubs(comparesection11.7).

mountebankiswritteninJavaScriptwithNode.js.ItcanprovideStubsforTCP,HTTP,HTTPSandSMTP.NewStubscanbegeneratedatruntime.The

definitionoftheStubsisstoredinaJSONfile.ItdefinesunderwhichconditionswhichresponsesaresupposedtobereturnedbytheStub.AnextensionwithJavaScriptislikewisepossible.mountebankcanalsoserveasproxy.Inthatcaseitforwardsrequeststoaservice–alternatively,onlythefirstrequestisforwardedandtheresponseisrecorded.Allsubsequentrequestswillbeansweredbymountebankwiththerecordedresponse.InadditiontoStubsmountebankalsosupportsMocks.WireMockiswritteninJavaandisunderApache2license.Thisframeworkmakesitveryeasytoreturncertaindataforcertainrequests.ThebehaviorisdeterminedbyJavacode.WireMocksupportsHTTPandHTTPS.TheStubcanruninanseparateprocess,inaservletcontainerordirectlyinaJUnittest.MocoislikewisewritteninJavaandisundertheMITlicense.ThebehavioroftheStubscanbeexpressedwithJavacodeorwithaJSONfile.ItsupportsHTTP,HTTPSandsimplesocketprotocols.TheStubscanbestartedinaJavaprogramorinanindependentserver.stubby4jiswritteninJavaandunderMITlicense.ItutilizesaYAMLfilefordefiningthebehavioroftheStub.HTTPSissupportedasprotocolinadditiontoHTTP.ThedefinitionofthedatatakesplaceinYAMLorJSON.ItisalsopossibletostartaninteractionwithaserverortoprogramthebehaviorofStubswithJava.Outoftherequestinformationcanbecopiedintotheresponse.

TryandExperiment

Usetheexamplepresentedinchapter14andsupplementStubswithaStubframeworkofyourchoice.Theexampleapplicationusestheconfigurationfileapplication-test.properties.InthisconfigurationitisdefinedwhichStubisusedforthetests.

11.7Consumer-drivenContractTestsEachinterfaceofacomponentisultimatelyacontract:Thecallerexpectsthatcertainsideeffectsaretriggeredorthatvaluesarereturnedwhenitusestheinterface.Thecontractisusuallynotformallydefined.WhenaMicroserviceviolatestheexpectations,thismanifestsitselfaserrorwhichiseithernoticedinproductionorinintegrationtests.Whenthecontractcanbemadeexplicitandtestedindependently,theintegrationtestscanbefreedfromtheobligationtotestthecontractwithoutincurringalargerriskforerrorsduringproduction.Besides,

thenitwouldgeteasiertomodifytheMicroservicesbecauseitwouldbeeasiertoanticipatewhichchangescauseproblemswithusingotherMicroservices.

Oftenchangestosystemcomponentsarenotperformedbecauseitisunclearwhichothercomponentsusethatspecificcomponentandhowtheyusit.ThereisariskoferrorsduringtheinterplaywithotherMicroservices,andtherearefearsthattheerrorwillbenoticedtoolate.WhenitisclearhowaMicroserviceisused,changesaremucheasiertoperformandtosafeguard.

ComponentsoftheContract

TheseaspectsbelongtothecontractofaMicroservice:

ThedataformatsdefineinwhichformatinformationisexpectedbytheotherMicroservicesandhowtheyarepassedovertoaMicroservice.Theinterfacedetermineswhichoperationsareavailable.Proceduresorprotocolsdefinewhichoperationscanbeperformedinwhichsequencewithwhichresults.Finally,thereismetainformationassociatedwiththecallswhichcancompriseforexampleauserauthentication.Inaddition,therecanbecertainnon-functionalaspectslikethelatencytimeoracertainthroughput.

Contracts

Therearedifferentcontractsbetweentheconsumersandtheproviderofaservice:

TheProviderContractcompriseseverythingtheserviceproviderprovides.Thereisonesuchcontractperserviceprovider.Itcompletelydefinestheentireservice.Itcanforinstancechangewiththeversionoftheservice(comparesection9.6).TheConsumerContractcomprisesallfunctionalitieswhichaserviceuserreallyutilizes.Thereareseveralsuchcontractsperservice–atleastonewitheachuser.Thecontractcomprisesonlythepartsoftheservicewhichtheuserreallyemploys.Itcanchangethroughmodificationstotheserviceconsumer.TheConsumer-drivenContract(CDC)comprisesallusercontracts.Therefore,itcontainsallfunctionalitieswhichanyserviceconsumerutilizes.Thereisonlyonesuchcontractperservice.Sinceitdependsontheusercontracts,itcanchangewhentheserviceconsumersaddnewcallstotheserviceproviderorwhentherearenewrequirementsforthecalls.

Fig.57:DifferencesbetweenConsumerandProviderContracts

TheConsumer-drivenContractmakesclearwhichwhichcomponentsoftheprovidercontractsarereallyused.ThisclarifiesalsowheretheMicroservicecanstillchangeitsinterfaceandwhichcomponentsoftheMicroservicearenotused.

Implementation

Ideally,aConsumer-drivenContractturnsintoaconsumer-drivencontracttestwhichtheserviceprovidercanperform.Ithastobepossiblefortheserviceconsumertochangethesetests.TheycanbestoredtogetherintheversioncontrolwiththeMicroserviceoftheserviceprovider.Inthatcasetheserviceconsumershavetogetaccesstotheversioncontroloftheserviceprovider.Otherwisethetestscanalsobestoredintheversioncontroloftheserviceconsumers.Inthatcasetheserviceproviderhastofetchthetestsoutoftheversioncontrolandexecutethemwitheachversionofthesoftware.However,inthatcaseitisnotpossibletoversiontheteststogetherwiththetestedsoftwaresincetestsandtestedsoftwareareintwoseparateprojectswithintheversioncontrol.

TheentiretyofalltestsrepresentstheConsumer-drivenContract.ThetestsofeachteamcorrespondtotheConsumerContractofeachteam.Theconsumer-drivencontracttestscanbeperformedaspartofthetestsoftheMicroservice.Iftheyaresuccessful,allserviceconsumersshouldbeabletosuccessfullyworktogetherwiththeMicroservice.Thetestprecludesthaterrorswillonlybenoticedduringtheintegrationtest.Besides,modificationstotheMicroservicesgeteasierbecauserequirementsfortheinterfacesareknownandcanbetestedwithout

specialexpenditure.Therefore,theriskassociatedwithchangeswhichaffecttheinterfaceismuchsmallersinceproblemswillbenoticedpriortointegrationtestsandproduction.

Tools

Towriteconsumer-drivencontracttestsatechnologyhastobedefined.ThetechnologyshouldbeuniformforallprojectsbecauseaMicroservicecanuseseveralotherMicroservices.InthatcaseateamhastowritetestsfordifferentotherMicroservices.Thisiseasierwhenthereisauniformtechnology.Otherwisetheteamshavetoknownumerousdifferenttechnologies.Thetechnologyforthetestscandifferfromthetechnologyusedforimplementation.

Anarbitrarytestframeworkisanoptionforimplementingtheconsumer-drivencontracttests.Forloadtestsadditionaltoolscanbedefined.Inadditiontothefunctionalrequirementstherecanalsoberequirementsinregardstotheloadbehavior.However,ithastobeclearlydefinedhowtheMicroserviceisprovidedforthetest.Forexample,itcanbeavailableatacertainportonthetestmachine.InthiswaythetestcantakeplaceviatheinterfacewhichisalsousedforaccessbyotherMicroservices.Intheexampleapplication(section14.13)simpleJUnittestsareusedfortestingtheMicroserviceandforverifyingwhethertherequiredfunctionalitiesaresupported.Whenincompatiblechangestodataformatsareperformedortheinterfaceismodifiedinaincompatiblemanner,thetestsfail.Therearetoolsespeciallydesignedfortheimplementationofconsumer-drivencontracttests.AnexampleisPacto.ItiswritteninRubyandundertheMITlicence.PactosupportsREST/HTTPandsupplementssuchinterfaceswithacontract.Pactocanbeintegratedintoateststructure.InthatcasePactocomparestheheaderwithexpectedvaluesandtheJSONdatastructuresinthebodywithJSONschemas.Thisinformationrepresentsthecontract.Thecontractcanalsobegeneratedoutofarecordedinteractionbetweenaclientandaserver.BasedonthecontractPactocanvalidatethecallsandresponsesofasystem.Inaddition,PactocancreatewiththisinformationsimpleStubs.Moreover,PactocanbeusedinconjunctionwithRSpectowritetestsinRuby.AlsotestsystemswhicharewritteninotherlanguagesthanRubycanbetestedinthisway.WithoutRSpecPactooffersthepossibilitytorunaserver.TherebyitispossibletousePactoalsooutsideofaRubysystem.

PactislikewisewritteninRubyandunderMITlicence.TheserviceconsumercanemployPacttowriteaStubfortheserviceandtorecordtheinteractionwiththeStub.ThisresultsinaPactfilewhichrepresentsthecontract.Itcanalsobeusedfortestingwhethertheactualservicecorrectlyimplementsthecontract.PactisespeciallyusefulforRuby,howeverpact-jvmsupportsasimilarapproachfordifferentJVMlanguageslikeScala,Java,GroovyorClojure.

TryandExperiment

Usetheexamplepresentedinchapter14andsupplementconsumer-drivencontractswithaframeworkofyourchoice.Theexampleapplicationhastheconfigurationapplication-test.properties .InthisconfigurationitisdefinedwhichStubisusedforthetests.Verifyalsothecontractsintheproductionenvironment.

11.8TestingTechnicalStandardsMicroserviceshavetofulfillcertaintechnicalrequirements.Forexample,MicroservicesshouldregisterthemselvesinServiceDiscoveryandkeepfunctioningevenifotherMicroservicesbreakdown.Testscanverifytheseproperties.Thisentailsanumberofadvantages:

Theguidelinesareunambiguouslydefinedbythetest.Therefore,thereisnodiscussionhowpreciselytheguidelinesaremeant.Theycanbetestedinanautomatedfashion.TherebyitisclearatanytimewhetheraMicroservicefulfillstherulesornot.Newteamscantestnewcomponentsastowhethertheycomplywiththerulesornot.WhenMicroservicesdonotemploytheusualtechnologystack,itcanstillbeensuredthattheybehavecorrectlyfromatechnicalpointofview.

Amongthepossibletestsare:

TheMicroserviceshavetoregisterintheServiceDiscovery(section8.9).Thetestcanverifywhetherthecomponentregistersatserviceregistryuponstarting.Besides,thesharedmechanismsforconfigurationandcoordinationhavetobeused(section8.8).Thetestcancontrolwhethercertainvaluesfromthe

centralconfigurationarereadout.Forthispurpose,anindividualtestinterfacecanbeimplemented.AsharedsecurityinfrastructurecanbecheckedbytestingtheuseoftheMicroserviceviaacertaintoken(section8.12).Inregardstodocumentationandmetadata(section8.13)itcanbetestedwhetheratestcanaccessthedocumentationviathedefinedpath.Inregardstomonitoring(section12.3)andlogging(section12.2)itcanbeexaminedwhethertheMicroserviceprovidesdatatothemonitoringinterfacesuponstartinganddeliversvaluesresp.logentries.Inregardstodeployment(section12.4)itissufficienttodeployandstarttheMicroserviceonaserver.Whenthedefinedstandardisusedforthis,thisaspectislikewisecorrectlyimplemented.Astestforcontrol(section12.5)theMicroservicecansimplyberestarted.TotestforResilience(section10.5)inthesimplestscenarioitcanbecheckedwhethertheMicroserviceatleastbootsalsoinabsenceofthedependentMicroservicesanddisplayserrorsinmonitoring.ThecorrectfunctioningoftheMicroserviceuponavailabilityoftheotherMicroservicesisensuredbythefunctionaltests.However,ascenariowheretheMicroservicecannotreachanyotherserviceisnotaddressedinnormaltests.

IntheeasiestcasethetechnicaltestcanjuststartanddeploytheMicroservice.Therebydeploymentandcontrolarealreadytested.DependentMicroservicesdonothavetobepresentforthat.StartingtheMicroserviceshouldalsobepossiblewithoutdependentMicroservicesduetoResilience.Subsequently,loggingandmonitoringcanbeexaminedwhichshouldalsoworkandcontainerrorsinthissituation.Finally,theintegrationinthesharedtechnicalserviceslikeServiceDiscovery,configurationandcoordinationorsecuritycanbechecked.

Suchatestisnothardtowriteandcanrendermanydiscussionsaboutthepreciseinterpretationoftheguidelinessuperfluous.Therefore,thistestisveryuseful.Besides,ittestsscenarioswhichareusuallynotcoveredbyautomatedtests–forinstancethebreakdownofdependentsystems.

ThistestdoesnotnecessarilyprovidecompletesecuritythattheMicroservicecomplieswithallrules.However,itcanatleastexaminewhetherthefundamentalmechanismsfunction.

Technicalstandardscaneasilybetestedwithscripts.ThescriptsshouldinstalltheMicroserviceinthedefinedmanneronavirtualmachineandstartit.

Afterwardsthebehavior,forinstanceinregardstologgingandmonitoring,canbetested.Sincetechnicalstandardsarespecificforeachproject,auniformapproachishardlypossible.UndercertainconditionsatoollikeServerspeccanbeuseful.Itservestoexaminethestateofaserver.Therefore,itcaneasilydeterminewhetheracertainportisusedorwhetheracertainserviceisactive.

11.9ConclusionReasonsfortestingareontheonehandtheriskthatproblemsareonlynoticedinproductionandontheotherhandthattestsserveasanexactspecificationofthesystem(section11.1).

Section11.2illustratedbyusingtheconceptoftheTestPyramidhowtestsshouldbestructured:Thefocusshouldbeonfast,easilyautomatableunittests.Theyaddresstheriskthatthereareerrorsinthelogic.IntegrationtestsandUIteststhenonlyensuretheintegrationoftheMicroserviceswitheachotherandthecorrectintegrationoftheMicroservicesintotheUI.

Assection11.3showed,Microservicescanadditionallydealwiththeriskoferrorsinproductioninadifferentmanner:Microservicedeploymentsarefaster,theyinfluenceonlyasmallpartofthesystem,andMicroservicescanevenrunblindlyinproduction.Therebytheriskofdeploymentdecreases.Thusitcanbesensibleinsteadofcomprehensiveteststoratheroptimizethedeploymentinproductiontosuchanextentthatitisforallpracticalpurposesfreeofrisk.Inaddition,thesectiondiscussedthattherearetwotypesofTestPyramidsforMicroservice-basedsystems:oneperMicroserviceandonefortheoverallsystem.

TestingtheoverallsystementailstheproblemthateachchangetoaMicroservicenecessitatesarunthroughthistest.Therefore,thistestcanturnintoabottleneckandshouldbeveryfast.Thus,whentestingMicroservices,oneobjectiveistoreducethenumberofintegrationtestsacrossallMicroservices(section11.4).

WhenreplacinglegacyapplicationsnotonlytheirfunctionalityhastobetransferredintoMicroservices,butalsothetestsforthefunctionalitieshavetobemovedintothetestsoftheMicroservices(section11.5).Besides,eachmodificationtoaMicroservicehastobetestedintheintegrationwiththeversionofthelegacyapplicationusedinproduction.ThelegacyapplicationnormallyhasamuchslowerreleasecyclethantheMicroservices.Therefore,theversionofthe

legacyapplicationwhichisatthetimeindevelopmenthastobetestedtogetherwiththeMicroservices.

FortestingindividualMicroservicestheotherMicroserviceshavetobereplacedbyStubs.ThisallowstouncouplethetestsoftheindividualMicroservicesfromeachother.Section11.6introducedanumberofconcretetechnologiesforcreatingStubs.

Insection11.7client-drivencontracttestswerepresented.WiththisapproachthecontractsbetweentheMicroservicesgetexplicit.ThisallowsaMicroservicetocheckwhetheritfulfillstherequirementsoftheotherMicroservices–withouttheneedforanintegrationtest.Alsoforthisareaanumberoftoolareavailable.

Finally,section11.8demonstratedthattechnicalrequirementstotheMicroservicescanlikewisebetestedinanautomatedmanner.ThisallowstounambiguouslyestablishwhetheraMicroservicefulfillsalltechnicalstandards.

EssentialPoints

EstablishedbestpracticesliketheTestPyramidarealsosensibleforMicroservices.CommontestsacrossallMicroservicescanturnintoabottleneckandthereforeshouldbereduced,forexamplebyperformingmoreconsumer-drivencontracttests.WithsuitabletoolsStubscanbecreatedfromMicroservices.

12OperationsandContinuousDeliveryofMicroservices

DeploymentandoperationareadditionalcomponentsoftheContinuousDeliveryPipeline(comparesection11.1).WhenthesoftwarehasbeentestedinthecontextofthepipelinetheMicroservicesgointoproduction.TheremonitoringandloggingcollectinformationwhichcanbeusedforthefurtherdevelopmentoftheMicroservices.

TheoperationofaMicroservice-basedsystemismorelaboriousthantheoperationofaDeploymentMonolith.Therearemanymoredeployableartifactswhichallhavetobesurveilled.Section12.1discussesthetypicalchallengesassociatedwiththeoperationofMicroservice-basedsystemsindetail.Loggingisthetopicofsection12.2.Section12.3focusesonthemonitoringoftheMicroservices.Deploymentistreatedinsection12.4.Section12.5showsnecessarymeasuresfordirectingaMicroservicefromtheoutside,andsection12.6finallydescribessuitableinfrastructuresfortheoperationofMicroservices.

Thechallengesassociatedwithoperationshouldnotbeunderestimated.ItisinthisareawherethemostcomplexproblemsassociatedwiththeuseofMicroservicesfrequentlyarise.

12.1ChallengesAssociatedwiththeOperationofMicroservicesChallenge:NumerousArtifacts

TeamswhohavesofaronlyrunDeploymentMonolithsareconfrontedwiththeproblemthatthereareverymanyadditionaldeployableartifactsinMicroservices-basedsystems.EachMicroserviceisindependentlybroughtintoproductionandthereforeaseparatedeployableartifact.Fifty,hundredormoreMicroservicesaredefinitelyrealistic.TheconcretenumberdependsonthesizeoftheprojectandthesizeoftheMicroservices.SuchanumberofdeployableartifactsishardlymetwithoutsideofMicroservices-basedarchitectures.Alltheseartifactshavetobeversionedindependentlybecauseonlythenitcanbe

trackedwhichcoderunscurrentlyinproduction.Besides,thisallowstobringeachMicroserviceindependentlyinanewversionintoproduction.

Whentherearesomanyartifacts,therehastobeacorrespondinglyhighnumberofContinuousDeliveryPipelines.Theydonotonlycomprisethedeploymentinproductionbutalsothedifferenttestingphases.Inaddition,manymoreartifactshavetobesurveilledinproductionbyloggingandmonitoring.Thisisonlypossiblewhenalltheseprocessesaremostlyautomated.Forasmallnumberofartifactsmanualinterventionsmightstillbeacceptable.SuchanapproachissimplynotpossibleanymoreforthelargenumberofartifactscontainedinaMicroservice-basedarchitecture.

ThechallengesintheareasofdeploymentandinfrastructureareforsurethemostdifficultonesencounteredwhenintroducingMicroservices.Manyorganizationsarenotsufficientlyproficientinautomationalthoughautomationisalsoveryadvantageousinotherarchitecturalapproachesandshouldalreadyberoutine.

Therearedifferentapproachesforachievingthenecessaryautomation:

DelegateintoTeams

TheeasiestoptionistodelegatethischallengetotheteamswhichareresponsibleforthedevelopmentoftheMicroservices.InthatcaseeachteamhasnotonlytodevelopitsMicroservice,butalsototakecareofitsoperation.Theyhavethechoicetoeitheruseappropriateautomationforitortoadoptautomationapproachesfromotherteams.

Theteamdoesnotevenhavetocoverallareas.Whenthereisnoneedtoevaluatelogdatatoachievereliableoperation,theteamcandecidenottoimplementasystemforevaluatinglogdata.Areliableoperationwithoutsurveillingthelogoutputishardlypossiblethough.However,thisriskisthenwithintheresponsibilityoftherespectiveteam.

Thisapproachonlyworkswhentheteamshavealotofknowledgeregardingoperation.Anotherproblemisthatthewheelisinventedoverandoveragainbythedifferentteams:Eachteamimplementsautomationindependentlyandmightusedifferenttoolsforit.ThisapproachentailsthedangerthattheanyhowlaboriousoperationoftheMicroservicesgetsevenmorelaboriousduetotheheterogeneousapproachestakenbytheteams.Theteamshavetodothiswork.Thisinterferes

withtherapidimplementationofnewfeatures.However,thedecentralizeddecisionwhichtechnologiestouseincreasestheindependenceoftheteams.

UnifyTools

Becauseofthehigherefficiency,unificationcanbeasensibleapproachfordeployment.Theeasiestwaytoobtainuniformtoolsistoprescribeonetoolforeacharea–deployment,test,monitoring,logging,deploymentpipeline.Inaddition,therewillbeguidelinesandbestpracticeslikeforinstanceimmutableserverortheseparationofbuildenvironmentanddeploymentenvironment.ThisallowsfortheidenticalimplementationofallMicroservicesandwillfacilitateoperationsincetheteamsonlyneedtobefamiliarwithonetoolforeacharea.

SpecifyBehavior

Anotheroptionistospecifythebehaviorofthesystem.Oneexample:Whenlogoutputissupposedtobeevaluatedinauniformmanneracrossservices,itissufficienttodefineauniformlogformat.Thelogframeworkdoesnotnecessarilyhavetobeprescribed.Ofcourse,itissensibletoofferforatleastonelogframeworkaconfigurationwhichgeneratesthisoutputformat.Thisincreasesthemotivationoftheteamstousethislogframework.Inthiswayuniformityisnotforced,butemergesonitsownsincetheteamswillminimizetheirowneffort.Whenateamregardstheuseofanotherlogframeworkorprogramminglanguagewhichnecessitatesanotherlogframeworkasmoreadvantageous,itcanstillusethesetechnologies.

Defininguniformformatsforlogoutputhasanadditionaladvantage:Theinformationcanbedeliveredtodifferenttoolswhichprocesslogfilesdifferently.Thisallowsoperationstoscreenlogfilesforerrorswhilethebusinessstakeholderscreatestatistics.Operationandbusinessstakeholderscanusedifferenttoolswhichusetheuniformformatassharedbasis.

Similarly,behaviorcanbedefinedfortheotherareasofoperationsuchasdeployment,monitoringorthedeploymentpipeline.

MicroandMacroArchitecture

Whichdecisionscanbemadebytheteamandwhichhavetobemadefortheoverallprojectcorrespondstotheseparationofthearchitectureintomicroandmacroarchitecture(comparesection13.3).Decisionstheteamcanmakebelongtomicroarchitecturewhiledecisionswhicharemadeacrossallteamsforthe

overallprojectarepartofthemacroarchitecture.Technologiesorthedesiredbehaviorforloggingcanbeeitherpartofthemacroorthemicroarchitecture.

Templates

TemplatesoffertheoptiontounifyMicroservicesintheseareasandtoincreasetheproductivityoftheteams.BasedonaverysimpleMicroserviceatemplatedemonstrateshowthetechnologiescanbeusedandhowMicroservicesareintegratedintotheoperationinfrastructure.Theexamplecansimplyrespondtoarequestwithaconstantvaluesincethedomainlogicisnotthepointhere.

ThetemplatewillmakeiteasyandfastforateamtoimplementanewMicroservice.Atthesametime,eachteamcaneasilymakeuseofthestandardtechnologystack.Sotheuniformtechnicalsolutionisatthesametimethemostattractivefortheteams.TemplatesachievealargedegreeoftechnicaluniformitybetweenMicroserviceswithoutprescribingtheusedtechnology.Inaddition,afaultyuseofthetechnologystackisavoidedwhenthetemplatedemonstratesthecorrectuse.

AtemplateshouldcontainthecompleteinfrastructureinadditiontothecodeforanexemplaryMicroservice.ThisreferstotheContinuousDeliveryPipeline,thebuild,theContinuousIntegrationPlatform,thedeploymentinproductionandthenecessaryresourcesforrunningtheMicroservice.EspeciallybuildandContinuousDeliveryPipelineareimportantsincethedeploymentofalargenumberofMicroservicesisonlypossiblewhentheseareautomated.

Thetemplatecanbeverycomplexwhenitreallycontainsthecompleteinfrastructure–eveniftherespectiveMicroserviceisverysimple.Itisnotnecessarilyrequiredtoprovideatonceacompleteandperfectsolution.Thetemplatecanalsobebuiltupinastepwisemanner.

Thetemplatecanbecopiedintoeachproject.ThisentailstheproblemthatchangestothetemplatearenotpropagatedintotheexistingMicroservices.Ontheotherhand,thisapproachismucheasiertoimplementthananapproachwhichallowsfortheautomatedadoptionofchanges.BesidessuchanapproachwouldcreatedependenciesbetweenthetemplateandpracticallyallMicroservices.SuchdependenciesshouldbeavoidedforMicroservices.

ThetemplatesfundamentallyfacilitatethegenerationofnewMicroservices.Accordingly,teamsaremorelikelytocreatenewMicroservices.Therebythey

canmoreeasilydistributeMicroservicesinmultiplesmallerMicroservices.ThustemplateshelptokeepMicroservicessmall.WhentheMicroservicesarerathersmall,theadvantagesofaMicroservice-basedarchitecturecanbeexploitedevenbetter.

12.2LoggingBylogginganapplicationcaneasilyprovideinformationaboutwhicheventsoccurred.Thesecanbeerrors,butalsoeventsliketheregistrationofanewuserwhicharemostlyinterestingforstatistics.Finally,logdatacanhelpdeveloperstolocateerrorsbyprovidingdetailedinformation.

Innormalsystemslogshavetheadvantagethattheycanbewrittenveryeasilyandthatthedatacanbepersistedwithouthugeeffort.Besides,logfilesarehuman-readableandcanbeeasilysearched.

LoggingforMicroservices

ForMicroserviceswritingandanalyzinglogfilesishardlysufficient:

ManyrequestscanonlybehandledbytheinterplayofmultipleMicroservices.InthatcasethelogfileofasingleMicroserviceisnotsufficienttounderstandthecompletesequenceofevents.TheloadisoftendistributedacrossmultipleinstancesofoneMicroservice.Therefore,theinformationcontainedinthelogfileofanindividualinstanceisnotveryuseful.Finally,duetoincreasedload,newreleasesorcrashes,newinstancesofaMicroservicestartconstantly.Thedatafromalogfilecangetlostwhenavirtualmachineisshutdownanditsharddiscissubsequentlydeleted.

ItisnotnecessaryforMicroservicestowritelogsintotheirfilesystembecausetheinformationcananyhownotbeanalyzedthere.Onlywritingtothecentrallogserverisdefinitelynecessary.ThishasalsotheadvantagethattheMicroservicesutilizelesslocalstorage.

Usually,applicationsjustlogtextstrings.Thecentralizedloggingparsesthestring.Duringparsingrelevantinformationliketimestampsorservernamesareextracted.Oftenparsinggoesevenbeyondthatandscrutinizesthetextsmoreclosely.Ifitispossibletodetermineforinstancetheidentityofthecurrentuserfromthelogs,allinformationaboutausercanbeselectedfromthelogdataoftheMicroservices.InawaytheMicroservicehidestherelevantinformationina

stringwhichthelogsystemsubsequentlytakesapartagain.TofacilitatetheparsinglogdatacanbetransferredintoadataformatlikeJSON.Inthatcasethedatacanalreadybestructuredduringlogging.Theyarenotfirstpackagedintoastringwhichthenhastobelaboriouslyparsed.Likewise,itissensibletohaveuniformstandards:WhenaMicroservicelogssomethingasanerror,thenanerrorshouldreallyhaveoccurred.Inaddition,thesemanticsoftheotherloglevelsshouldbeuniformacrossallMicroservices.

TechnologiesforLoggingviatheNetwork

Microservicescansupportcentralloggingbysendinglogdatadirectlyviathenetwork.Mostloglibrariessupportsuchanapproach.SpecialprotocolslikeGELF(GraylogExtendedLogFormat)canbeusedforthisorlongestablishedprotocolslikesyslogwhichisthebasisforlogginginUNIXsystems.Toolslikethelogstash-forwarder,BeaverorWoodchuckaremeanttosendlocalfilesviathenetworktoacentrallogserver.Theyaresensibleincaseswherethelogdataaresupposedtobealsolocallystoredinfiles.

ELKforCentralizedLogging

Logstash,ElasticsearchandKibanacanserveastoolsforthecollectionandprocessingoflogsonacentralserver.

Fig.58:ELKinfrastructureforloganalysis

WiththeaidofLogstashlogfilescanbeparsedandcollectedbyserversinthenetwork.Logstashisaverypowerfultool.Itcanreaddatafromasource,modifyorfilterdata,andfinallywriteitintoasink.ApartfromimportinglogsfromthenetworkandstorageinElasticsearchLogstashsupportsmanyotherdatasourcesanddatasinks.Forexample,datacanbereadfrommessagequeuesordatabasesorwrittenintothem.Finally,Logstashcanalsoparsedataandsupplementit–forexampletimestampscanbeaddedtoeachlogentryorindividualfieldscanbecutoutandfurtherprocessed.Elasticsearchstoreslogdataandmakesthemavailableforanalyses.Elasticsearchcannotonlysearchthedatawithfulltextsearch,butitcanalso

searchinindividualfieldsofstructureddataandpermanentlystorethedatalikeadatabase.Finally,Elasticsearchoffersstatisticalfunctionsandcanusethosetoanalyzedata.AsasearchengineElasticsearchisoptimizedforfastresponsetimessothatthedatacanbeanalyzedquasiinteractively.KibanaisawebuserinterfacewhichallowstoanalyzedatafromElasticsearch.Inadditiontosimplequeriesalsostatisticalevaluations,visualizationsanddiagramscanbecreated.

ThesetoolsformtheELKstack(Elasticsearch,Logstash,Kibana).AllthreeareopensourceprojectsandareunderApache2.0license.

ScalingELK

EspeciallyincaseofMicroserviceslogdataaccumulateofteninlargeamounts.Therefore,inMicroservice-basedarchitecturesthesystemforthecentralprocessingoflogsshouldbehighlyscalable.AgoodscalabilityisoneoftheadvantagesoftheELKstack:

Elasticsearchcandistributetheindicesintoshards.Eachdatasetisstoredinasingleshard.Astheshardscanbelocatedondifferentservers,thisallowsforloadbalancing.Inaddition,shardscanbereplicatedacrossseveralserverstoimprovefailsafeness.Besides,areadaccesscanbedirectedtoanarbitraryreplicaofthedata.Therebyreplicascanservetoscalereadaccess.Logstashcanwritelogsintodifferentindices.WithoutanadditionalconfigurationLogstashwouldwritethedataforeachdayintoadifferentindex.Sincethecurrentdatausuallyisreadmorefrequently,thisallowstoreducetheamountofdatawhichhastobesearchedforatypicalrequestandthereforeimprovesperformance.Besides,therearestillotherpossibilitiestodistributethedatatoindices–forinstanceaccordingtothegeographicoriginoftheuser.Thisalsopromotestheoptimizationofthedataamountswhichhavetobesearched.LogdatacanbebufferedinaBrokerpriortoprocessingbyLogstash.TheBrokerservesasbuffer.Itstoresthemessageswhentherearesomanylogmessagesthattheycannotbeimmediatelyprocessed.RedisisoftenusedasBroker–afastinmemorydatabase.

Graylog

TheELKstackisnottheonlysolutionfortheanalysisoflogfiles.GraylogisalsoanopensourcesolutionandlikewiseutilizesElasticsearchforstoringlogdata.

BesidesitusesMongoDBformetadata.Graylogdefinesitsownformatforthelogmessages:ThealreadymentionedGELF(GraylogExtendedLogFormat)standardizesthedatawhicharetransmittedviathenetwork.FormanyloglibrariesandprogramminglanguagesthereareextensionsforGELF.Likewise,therespectiveinformationcanbeextractedfromthelogdataorsurveyedwiththeUNIXtoolsyslog.AlsoLogstashsupportsGELFasin-andoutputformatsothatLogstashcanbecombinedwithGraylog.Grayloghasawebinterfacewhichallowstoanalyzetheinformationfromthelogs.

Splunk

Splunkisacommercialsolutionandalreadyforalongtimeonthemarket.Splunkpresentsitselfasasolutionwhichdoesnotonlyanalyzelogfiles,butcangenerallyanalyzemachinedataandbigdata.ForprocessinglogsSplunkgathersthedataviaaForwarder,preparesitviaanIndexerforsearching,andSearchHeadstakeovertheprocessingofsearchrequests.Itsintentiontoserveasanenterprisesolutionisunderlinedbythesecurityconcept.Customizedanalysis,butalsoalertsincaseofcertainproblemsarepossible.Splunkcanbeextendedbynumerousplug-ins.Besidesthereareappswhichprovideready-madesolutionsforcertaininfrastructuressuchasMicrosoftWindowsServer.Thesoftwaredoesnotnecessarilyhavetobeinstalledinyourowncomputingcenter,butisalsoavailableasCloudsolution.

StakeholdersforLogs

Therearedifferentstakeholdersforlogging.However,theanalysisoptionsofthelogserversaresoflexibleandtheanalysessosimilarthatonetoolisnormallysufficient.Thestakeholderscancreatetheirowndashboardswiththeinformationthatisrelevanttothem.Forspecificrequirementsthelogdatacanbepassedontoothersystemsforevaluation.

CorrelationIDs

OftenmultipleMicroservicesworktogetheronarequest.ThepaththerequesttakesthroughtheMicroserviceshastobetraceableforanalysis.ForfilteringalllogentriestoacertaincustomerortoacertainrequestacorrelationIDcanbeused.ThisIDunambiguouslyidentifiesarequesttotheoverallsystemandispassedalongduringallcommunicationbetweenMicroservices.Inthismannerlogentriesforallsystemstoasinglerequestareeasytofindinthecentrallogsystem,andtheprocessingoftherequestscanbetrackedacrossallMicroservices.

SuchanapproachcanforinstancebeimplementedbytransferringarequestIDforeachmessagewithintheheadersorwithinthepayloads.Manyprojectsimplementthetransferintheirowncodewithoutusingaframework.ForJavathereisthelibrarytraceewhichimplementsthetransferoftheIDs.Somelogframeworkssupportacontextwhichisloggedtogetherwitheachlogmessage.InthatcaseitisonlynecessarytoputthecorrelationIDintothecontextwhenreceivingamessage.ThisobliteratestheneedtopassthecorrelationIDonfrommethodtomethod.WhenthecorrelationIDisboundtothethread,problemscanarisewhentheprocessingofarequestinvolvesseveralthreads.SettingthecorrelationIDinthecontextensuresthatalllogmessagescontainthecorrelationID.HowthecorrelationIDisloggedhastobeuniformacrossallMicroservicessothatthesearchforarequestinthelogsworksforallMicroservices.

Zipkin:DistributedTracing

AlsoinregardstoperformanceevaluationshavetobemadeacrossMicroservices.Whenthecompletepathoftherequestsistraceable,itcanbeidentifiedwhichMicroservicerepresentsabottleneckandrequiresanespeciallylongtimeforprocessingrequests.WiththeaidofadistributedtracingitcanbedeterminedforarequestwhichMicroserviceneedshowmuchtimeforansweringarequestandwhereoptimizationshouldstart.Zipkinenablesexactlythistypeofinvestigations.ItcomprisessupportfordifferentnetworkprotocolssothatarequestIDisautomaticallypassedonviatheseprotocols.IncontrasttothecorrelationIDstheobjectiveisnottocorrelatelogentries,buttoanalyzethetimebehavioroftheMicroservices.ForthispurposeZipkinofferssuitableanalysistools.

TryandExperiment

DefineatechnologystackwhichenablesaMicroservice-basedarchitecturetoimplementlogging:

Howshouldthelogmessagesbeformatted?Definealoggingframeworkifnecessary.Determineatechnologyforcollectingandevaluatinglogs.

Thissectionlistedanumberoftoolsforthedifferentareas.Whichpropertiesareespeciallyimportant?Theobjectiveisnotacompleteproductevaluation,butageneralweighingofadvantagesanddisadvantages.

Chapter14showsanexampleforaMicroservice-basedarchitectureandinsection14.14therearesuggestionshowthearchitecturecanbesupplementedwithaloganalysis.

Howdoesyourcurrentprojecthandlelogging?Isitmaybepossibletoimplementpartsoftheseapproachesandtechnologiesalsoinyourproject?

12.3MonitoringMonitoringsurveilsthemetricsofaMicroserviceandusesotherinformationsourcesthanlogging.Monitoringusesmostlynumericalvalueswhichprovideinformationaboutthecurrentstateoftheapplicationandindicatehowthisstatechangesovertime.Suchvaluescanrepresentthenumberofprocessedcallsoveracertaintime,thetimeneededforprocessingthecallsoralsosystemvaluesliketheCPUormemoryutilization.Ifcertainthresholdsaresurpassedornotreached,thisindicatesaproblemandcantriggeranalarmsothatsomebodycansolvetheproblem.Orevenbetter:Theproblemissolvedautomatically.Forexample,anoverloadcanbeaddressedbystartingadditionalinstances.

Monitoringoffersfeedbackfromproductionwhichisnotonlyrelevantforoperation,butalsofordevelopersortheusersofthesystem.Basedontheinformationfrommonitoringtheycanbetterunderstandthesystemandthereforemakeinformeddecisionsabouthowthesystemshouldbedevelopedfurther.

BasicInformation

BasicmonitoringinformationshouldbemandatoryforallMicroservices.Thismakesiteasiertogetanoverviewofthestateofthesystem.AllMicroservicesshoulddelivertherequiredinformationinthesameformat.Besidescomponents

oftheMicroservicesystemcanlikewiseusethevalues.LoadbalancingforinstancecanuseahealthchecktoavoidaccessingMicroserviceswhichcannotprocesscalls.

ThebasicvaluesallMicroservicesshouldprovidecancomprisethefollowing:

ThereshouldbeavaluewhichindicatestheavailabilityoftheMicroservice.InthismannertheMicroservicesignalswhetheritiscapableofprocessingcallsatall(“alive”).DetailedinformationregardingtheavailabilityoftheMicroserviceisanotherimportantmetric.OnerelevantinformationiswhetherallMicroservicesusedbytheMicroserviceareaccessibleandwhetherallotherresourcesareavailable(“health”).ThisinformationdoesnotonlyindicatewhethertheMicroservicefunctions,butalsoprovidehintswhichpartofaMicroserviceiscurrentlyunavailableandwhyitfailed.Importantly,itbecomesapparentwhethertheMicroserviceisunavailablebecauseofthefailureofanotherMicroserviceorbecausetherespectiveMicroserviceitselfishavingaproblem.InformationabouttheversionofaMicroserviceandadditionalmetainformationlikethecontactpartnerorusedlibrariesandtheirversionsaswellasotherartifactscanalsobeprovidedasmetrics.Thiscancoverpartofthedocumentation(comparesection8.13).Alternatively,itcanbecheckedwhichversionoftheMicroserviceisactuallycurrentlyinproduction.Thisfacilitatesthesearchforerrors.Besides,anautomatedcontinuousinventoryoftheMicroservicesandotherusedsoftwareispossible,whichsimplyinquiresafterthesevalues.

AdditionalMetrics

Additionalmetricscanlikewiseberecordedbymonitoring.Amongthepossiblevaluesareforinstanceresponsetimes,thefrequencyofcertainerrorsorthenumberofcalls.ThesevaluesareusuallyspecificforaMicroservicesothattheydonotnecessarilyhavetobeofferedbyallMicroservices.Analarmcanbetriggeredwhencertainthresholdsarereached.SuchthresholdsaredifferentforeachMicroservice.

Nevertheless,auniforminterfaceforaccessingthevaluesissensiblewhenallMicroservicesaresupposedtousethesamemonitoringtool.Uniformitycantremendouslyreduceexpenditureinthisarea.

Stakeholders

Therearedifferentstakeholdersfortheinformationfrommonitoring:

OperationswantstimelytobeinformedaboutproblemstoenableasmoothoperationoftheMicroservice.Incaseofacuteproblemsorfailuresitwantstogetanalarm–atanydayornighttime–viadifferentmeanslikepagerorSMS.Detailedinformationisonlynecessarywhentheerrorhastobeanalyzedmoreclosely–oftentogetherwiththedevelopers.OperationsisnotonlyinterestedinthevaluesfromtheMicroserviceitself,butalsoinmonitoringvaluesoftheoperatingsystem,thehardwareorthenetwork.Developersmostlyfocusoninformationfromtheapplication.Theywanttounderstandhowtheapplicationfunctionsinproductionandhowitisemployedbytheusers.Fromthisinformationtheydeduceoptimizations,especiallyatthetechnicallevel.Therefore,theyneedveryspecificinformation.Iftheapplicationisforinstancetooslowinrespondingtoacertaintypeofcall,thesystemhastobeoptimizedforthistypeofcall.Todosoitisnecessarytoobtainasmuchinformationaspossibleaboutexactlythistypeofcall.Othercallsarenotasinteresting.Developersevaluatethisinformationindetail.Theymightevenbeinterestedinanalyzingcallsofjustonespecificuseroracircleofusers.Thebusinessstakeholdersareinterestedinthebusinesssuccessandtheresultingbusinessnumbers.Suchinformationcanbeprovidedbytheapplicationspecificallyforthebusinessstakeholders.Thebusinessstakeholdersthengeneratestatisticsbasedonthisinformationandtherebypreparebusinessdecisions.Ontheotherhand,theyareusuallynotinterestedintechnicaldetails.

Thedifferentstakeholdersarenotonlyinterestedindifferentvalues,butalsoanalyzethemdifferently.Standardizingthedataformatissensibletosupportdifferenttoolsandneverthelessenableallstakeholderstoaccessalldata.

Fig.59:Stakeholdersandtheirmonitoringdata

Fig.59showsanoverviewofapossiblemonitoringofaMicroservice-basedsystem.TheMicroserviceoffersthedataviaauniforminterface.Operationsusesmonitoringtosurveilforinstancethresholdvalues.Developmentutilizesadetailedmonitoringtounderstandprocesseswithintheapplication.Andthebusinessstakeholderslookatthebusinessdata.Theindividualstakeholdersmightusemoreorlesssimilarapproaches:Thestakeholderscanforinstanceusethesamemonitoringsoftwarewithdifferentdashboardsorentirelydifferentsoftware.

CorrelatewithEvents

Inaddition,itcanbesensibletocorrelatedatawithaneventsuchasanewrelease.Thisrequiresthatinformationabouttheeventhastobehandedovertomonitoring.Whenanewreleasecreatesmarkedlymorerevenueorcausesdecisivelylongerresponsetimes,thisisforsureaninterestingrealization.

Monitoring=Tests?

Inacertainwaymonitoringisanotherversionoftesting(comparesection11.4).Whiletestslookatthecorrectfunctioningofanewreleaseinatestenvironment,monitoringexaminesthebehavioroftheapplicationinaproductionenvironment.Theintegrationtestsshouldalsobereflectedinmonitoring.Whenaproblemcausesanintegrationtesttofail,therecanbeanassociatedalarminmonitoring.Besides,monitoringshouldalsobeactivatedfortestenvironmentstopinpointproblemsalreadyinthetests.Whentheriskassociatedwithdeploymentsisreducedbysuitablemeasures(comparesection12.4),themonitoringcaneventakeoverpartofthetests.

DynamicEnvironment

AnotherchallengewhenworkingwithMicroservice-basedarchitecturesisthatMicroservicescomeandgo.Duringthedeploymentofanewreleaseaninstancecanbestoppedandstartedanewwithanewsoftwareversion.Whenserversfail,instancesshutdown,andnewonesarestarted.ForthisreasonmonitoringhastooccurseparatedfromtheMicroservices.OtherwisethestoppingofaMicroservicewouldinfluencethemonitoringinfrastructureormayevencauseittofail.Besides,Microservicesareadistributedsystem.Thevaluesofasingleinstancearenottellinginthemselves.Onlybycollectingvaluesofmultipleinstancesthemonitoringinformationgetsrelevant.

ConcreteTechnologies

DifferenttechnologiescanbeusedformonitoringMicroservices:

Graphitecanstorenumericaldataandisoptimizedforprocessingtimeseriesdata.Suchdataoccurfrequentlyduringmonitoring.Thedatacanbeanalyzedinawebapplication.Graphitestoresthedatainitsowndatabase.Aftersometimethedataareautomaticallydeleted.MonitoringvaluesareacceptedbyGraphiteinaverysimpleformatviaasocketinterface.GrafanaextendsGraphitebyalternativedashboardsandothergraphicalelements.SeyrenextendsGraphitebyafunctionalityfortriggeringalarms.NagiosisacomprehensivesolutionformonitoringandcanbeanalternativetoGraphite.IcingahasoriginallybeenaforkofNagiosandthereforecoversaverysimilarusecase.Riemannfocusesontheprocessingofeventstreams.Itusesafunctionalprogramminglanguagetodefinelogicforthereactiontocertainevents.For

thispurpose,afittingdashboardcanbeconfigured.MessagescanbesentbySMSore-mail.Packetbeatusesanagentwhichrecordsthenetworktrafficonthecomputertobemonitored.ThisallowsPacketbeattodeterminewithminimaleffortwhichrequeststakehowlongandwhichnodescommunicatewitheachother.ItisespeciallyinterestingthatPacketbeatusesElasticsearchfordatastorageandKibanaforanalysis.Thesetoolsarealsowidelyusedforanalyzinglogdata(comparesection12.2).Havingonlyonestackforthestorageandanalysisoflogsandmonitoringreducesthecomplexityoftheenvironment.Inaddition,therearedifferentcommercialtools.AmongthoseareHP’sOperationsManager,IBMTivoli,CAOpscenterandBMCRemedy.Thesetoolsareverycomprehensive,havebeenonthemarketforalongtimeandoffersupportformanydifferentsoftwareandhardwareproducts.Suchplatformsareoftenusedenterprise-wideandintroducingthemintoanorganizationisusuallyaverycomplexproject.Someofthesesolutionscanalsoanalyzeandmonitorlogfiles.DuetotheirlargenumberandthehighdynamicsoftheenvironmentitcanbesensibleforMicroservicestoestablishtheirownmonitoringtoolsevenifanenterprise-widestandardexistsalready.Whentheestablishedprocessesandtoolsrequireahighmanualexpenditureforadministration,thisexpendituremightnotbefeasibleanymoreinthefaceofthelargenumberofMicroservicesandthedynamicsoftheMicroserviceenvironment.MonitoringcanbemovedtotheCloud.Inthismannernoextrainfrastructurehastobeinstalled.Thisfacilitatestheintroductionoftoolsandmonitoringtheapplications.AnexampleisNewRelic.

Thesetoolsarefirstofallusefulforoperationsandfordevelopers.Businessmonitoringcanbeperformedwithdifferenttools.Suchmonitoringisnotonlybasedoncurrenttrendsanddata,butalsoonhistoricalvalues.Therefore,theamountofdataismarkedlylargerthanforoperationsanddevelopment.ThedatacanbeexportedintoaseparatedatabaseorinvestigatedwithBigDatasolutions.Infact,theanalysisofdatafromwebserversisoneoftheareaswherebigdatasolutionshavefirstbeenused.

EnablingMonitoringinMicroservices

Microserviceshavetodeliverdatawhicharedisplayedinthemonitoringsolutions.ItispossibletoprovidethedataviaasimpleinterfacelikeHTTPwithadataformatsuchasJSON.Thenthemonitoringtoolscanreadthesedataoutandimportthem.Forthispurpose,adaptorscanbewrittenasscriptsbythe

developers.Thismakesitpossibletoprovidedifferenttoolsviathesameinterfacewithdata.

Metrics

IntheJavaworldthemetricsframeworkcanbeused.Itoffersfunctionalitiesforrecordingcustomvaluesandsendingthemtoamonitoringtool.Thismakesitpossibletorecordmetricsintheapplicationandtohandthemovertoamonitoringtool.

StatsD

StatsDcancollectvaluesfromdifferentsources,performcalculationsandhandovertheresultstomonitoringtools.Thisallowstocondensedatabeforetheyarepassedontothemonitoringtoolinordertoreducetheloadonthemonitoringtool.TherearealsomanyclientlibrariesforStatsDwhichfacilitatethesendingofdatatoStatsD.

collectd

collectdcollectsstatisticsaboutasystem–likeforinstancetheCPUutilization.Thesedatacanbeanalyzedwiththefrontendortheycanbestoredinmonitoringtools.collectdcancollectdatafromaHTTPJSONdatasourceandsendthemontothemonitoringtool.Viadifferentplug-inscollectdcancollectdatafromtheoperatingsystemandthebasicprocesses.

Fig.60:Partsofamonitoringsystem

TechnologyStackforMonitoring

Atechnologystackformonitoringcomprisesdifferentcomponents(Fig.60):

WithintheMicroserviceitselfdatahavetoberecordedandprovidedtomonitoring.Forthispurpose,alibrarycanbeusedwhichdirectlycontactsthemonitoringtool.Alternatively,thedatacanbeofferedviaauniforminterface–forexampleJSONviaHTTP–,andanothertoolcollectsthedataandsendsthemontothemonitoringtool.Inaddition,ifnecessary,thereshouldbeanagenttorecordthedatafromtheoperatingsystemandthehardwareandpassthemontomonitoring.Themonitoringtoolstoresandvisualizesthedataandcan,ifneeded,triggeranalarm.Differentaspectscanbecoveredbydifferentmonitoringapplications.ForanalysesofhistoricaldataorbycomplexalgorithmsasolutionbasedonBigDatatoolscanbecreatedinparallel.

EffectsontheIndividualMicroservice

AMicroservicealsohastobeintegratedintotheinfrastructure.Ithastohandovermonitoringdatatothemonitoringinfrastructureandprovidesomemandatorydata.ThiscanbeensuredbyasuitabletemplatefortheMicroserviceandbytests.

TryandExperiment

DefineatechnologystackwhichallowstoimplementmonitoringinaMicroservice-basedarchitecture.Todosodefinethestakeholdersandthedatathatarerelevantforthem.Eachofthestakeholdersneedstohaveatoolforanalyzingthedatathatarerelevantforhim/her.Finally,ithastobedefinedwithwhichtoolsthedatacanberecordedandhowtheyarestored.Thissectionlistedanumberoftoolsforthedifferentareas.Inconjunctionwithfurtherresearchitispossibletoassembleatechnologystackthatiswellsuitedforindividualprojects.

Chapter14showsanexampleforaMicroservice-basedarchitecture,andinsection14.14thereisalsoasuggestionhowthearchitecturecanbeextendedbymonitoring.

Howdoesyourcurrentprojecthandlemonitoring?Cansomeofthetechnologiespresentedinthissectionalsobeadvantageousforyourproject?Which?Why?

12.4DeploymentIndependentdeploymentisacentralaimofMicroservices.Besides,thedeploymenthastobeautomatedbecausemanualdeploymentorevenjustmanual

correctionsarenotfeasibleduetothelargenumberofMicroservices.

DeploymentAutomation

Therearedifferentpossibilitiesforautomatingdeployment:

Installationscriptscanbeusedwhichonlyinstallthesoftwareonthecomputer.Suchscriptscanforinstancebeimplementedasshellscripts.Theycaninstallnecessarysoftwarepackages,generateconfigurationfilesandcreateuseraccounts.Suchscriptscanbeproblematicwhentheyarecalledrepeatedly.Inthatcasetheinstallationfindsacomputeronwhichthesoftwareisalreadyinstalled.However,anupdateisdifferentfromafreshinstallation.Insuchasituationascriptcanfailforexamplebecauseuseraccountsorconfigurationfilesmightalreadybepresentandcannoteasilybeoverwritten.Whenthescriptsaresupposedtohandleupdates,developmentandtestingthescriptsgetmorelaborious.ImmutableServersareanoptiontohandletheseproblems.Insteadofupdatingthesoftwareontheservers,theserverarecompletelydeployedanew.Thisdoesnotonlyfacilitatetheautomationofdeployment,butalsotheexactreproductionofthesoftwareinstalledonaserver.Itissufficienttoconsiderfreshinstallations.Afreshinstallationiseasiertoreproducethananupdate,thatcanbestartedfrommanydifferentconfigurationstatesandshouldleadtothesamestatefromanyofthose.ApproacheslikeDockermakeitpossibletotremendouslyreducetheexpenditureforinstallingsoftware.Dockerisakindoflight-weightvirtualization.Italsooptimizesthehandlingofvirtualharddrives.Ifthereisalreadyavirtualharddrivewiththecorrectdata,itisrecycledinsteadofinstallingthesoftwareanew.WheninstallingapackagelikeJava,firstavirtualharddriveislookedforwhichalreadyhasthisinstallation.Onlywhensuchaonedoesnotexist,theinstallationisreallyperformed.ShouldthereonlybeachangeinaconfigurationfilewhengoingfromanoldtoanewversionofanImmutableServer,Dockerwillrecycletheoldvirtualharddrivesbehindthescenesandonlysupplementthenewconfigurationfile.Thisdoesnotonlyreducetheconsumptionofharddrivespace,butalsoprofoundlyspeedsuptheinstallationoftheservers.Dockeralsodecreasesthetimeavirtualteamneedsforbooting.TheseoptimizationsturnImmutableServerinconjunctionwithDockerintoaninterestingoption.ThenewdeploymentoftheserversisveryfastwithDocker,andthenewservercanalsorapidlybebooted.AnotherpossibilityaretoolslikePuppet,Chef,AnsibleorSalt.Theyarespecializedforinstallingsoftware.Scriptsforthesetoolsdescribewhatthe

systemissupposedtolooklikeaftertheinstallation.Duringaninstallationrunthetoolwilltakethenecessarystepstotransferthesystemintothedesiredstate.Duringthefirstrunonafreshsystemthetoolcompletelyinstallsthesoftware.Iftheinstallationisrunasecondtimeimmediatelyafterwards,itwillnotchangethesystemanyfurthersincethesystemisalreadyinthedesiredstate.Besidesthesetoolscanuniformlyinstallalargenumberofserversinanautomatedmannerandarealsoabletorolloutchangestoalargenumberofservers.OperatingsystemsfromtheLinuxareapossesspackagemanagerlikerpm(RedHat),dpkg(Debian/Ubuntu)orzypper(SuSE).Theymakeitpossibletocentrallyrolloutsoftwareontoalargenumberofservers.Theusedfileformatsareverysimplesothatitisveryeasytogenerateapackageinafittingformat.Theconfigurationofthesoftwareposesaproblemthough.Packagemanagersusuallysupportscriptswhichareexecutedduringinstallation.Suchscriptscangeneratethenecessaryconfigurationfiles.However,therecanalsobeanextrapackagewiththeindividualconfigurationsforeachhost.Theinstallationtoolsmentionedunderthelastbulletpointcanalsousepackagemanagerforinstallingtheactualsoftwaresothattheythemselvesonlygeneratetheconfigurationfiles.

InstallationandConfiguration

Section8.8alreadydescribedtoolswhichcanbeusedforconfiguringMicroservices.Ingeneral,itishardtoseparatetheinstallationfromthesoftwareconfiguration.Theinstallationhastogenerateaconfiguration.Therefore,manyofthetoolslikeforinstancePuppet,Chef,AnsibleorSaltcanalsocreateconfigurationsandrollthemoutontoservers.ThusthesesolutionsareanalternativetotheconfigurationsolutionswhicharespecializedforMicroservices.

RisksAssociatedwithMicroserviceDeployments

Microservicesaresupposedtoallowforaneasyandindependentdeployment.Nevertheless,itcanneverbeexcludedthatproblemsariseinproduction.TheMicroservice-basedarchitecturebyitselfwillalreadyhelptoreducetherisk.WhenaMicroservicefailsasresultofaproblemwithanewversion,thisfailureshouldbelimitedtothefunctionalityofthisMicroservice.Apartfromthatthesystemshouldkeepworking.Thisismadepossiblebystabilitypatternsandresiliencedescribedinsection10.5.AlreadyforthisreasonthedeploymentofaMicroserviceismuchlessriskythanthedeploymentofamonolith.Incaseofamonolithitismuchhardertolimitafailuretoacertainfunctionality.IfanewversionoftheDeploymentMonolithhasamemoryleak,thiswillcausetheentire

processtobreakdownsothattheentiremonolithwillnotbeavailableanymore.AmemoryleakinaMicroserviceonlyinfluencesthisMicroservice.TherearedifferentchallengesforwhichMicroservicesarenotpersehelpful:Schemachangesinrelationaldatabasesareforinstanceproblematicbecausetheyoftentakeverylongandmightfail–especiallywhenthedatabaseisalreadycontainingalotofdata.AsMicroserviceshavetheirowndatastorage,aschemamigrationisalwayslimitedtojustoneMicroservice.

DeploymentStrategies

TofurtherreducetheriskassociatedwithaMicroservicedeploymenttherearedifferentstrategies:

ARollbackbringstheoldversionofaMicroservicebackintoproduction.Handlingthedatabasecanbeproblematic:OftentheoldversionoftheMicroservicedoesnotworkanymorewiththedatabaseschemacreatedbythenewerversion.Whentherearealreadydatainthedatabasewhichusethenewschema,itcangetverydifficulttorecreatetheoldstatewithoutlosingthenewdata.Besidestherollbackishardtotest.ARollForwardbringsanewversionofaMicroserviceinproduction,whichdoesnotcontaintheerroranymore.TheprocedureisidenticaltotheprocedureforthedeploymentofanyothernewversionoftheMicroservicesothatnospecialmeasuresarenecessary.ThechangeisrathersmallsothatdeploymentandthepassagethroughtheContinuousDeliveryPipelineshouldrapidlytakeplace.ContinuousDeploymentisevenmoreradical:EachchangetoaMicroserviceisbroughtintoproductionwhentheContinuousDeliveryPipelinewaspassedsuccessfully.Thisfurtherreducesthetimenecessaryforthecorrectionoferrors.Besides,thisentailsthattherearelesschangesperreleasewhichfurtherdecreasestheriskandmakesiteasiertotrackwhichchangestothecodecausedaproblem.ContinuousDeploymentisthelogicalconsequencewhenthedeploymentprocessworkssowellthatgoingintoproductionisjustaformality.Moreover,theteamwillpaymoreattentiontothequalityoftheircodewheneachchangereallygoesintoproduction.ABlue/GreenDeploymentbuildsupacompletelynewenvironmentwiththenewversionofaMicroservice.Theteamcancompletelytestthenewversionandthenbringitintoproduction.Shouldproblemsoccur,theoldversioncanbeusedagainwhichiskeptforthispurpose.Alsointhisscenariotherearechallengesincaseofchangestothedatabaseschema.Whenswitchingfromtheoneversiontotheotherversionofthe

Microservice,alsothedatabasehastobeswitched.Datawhichhavebeenwrittenintotheolddatabasebetweenthebuilt-upofthenewenvironmentandtheswitchhavetobetransferredintothenewdatabase.CanaryReleasingisbasedontheideatodeploythenewversioninitiallyjustononeserverinacluster.Whenthenewversionrunswithouttroubleononeserver,itcanalsobedeployedontheotherservers.ThedatabasehastosupporttheoldandthenewversionoftheMicroserviceinparallel.Microservicescanalsorunblindlyinproduction.Inthatcasetheygetallrequests,buttheymaynotchangedata,andcallswhichtheysendoutarenotpassedon.Bymonitoring,loganalysesandcomparisonwiththeoldversionitispossibletodeterminewhetherthenewservicehasbeencorrectlyimplemented.

Theoretically,suchprocedurescanalsobeimplementedwithDeploymentMonoliths.However,inpractisethisisverydifficult.WithMicroservicesitiseasiersincetheyaremuchsmallerdeploymentunits.Microservicesrequirelesscomprehensivetests.InstallingandstartingMicroservicesismuchfaster.Therefore,MicroservicescanmorerapidlypassthroughtheContinuousDeliveryPipelineintoproduction.ThiswillhavepositiveeffectsforRollForwardorRollbackbecauseproblemsrequirelesstimetofix.AMicroserviceneedslessresourcesinoperation.ThisishelpfulforCanaryReleasingorBlue/GreenDeploymentsincenewenvironmentshavetobebuiltup.Ifthisispossiblewithlessresources,theseapproachesareeasiertoimplement.ForaDeploymentMonolithitisoftenverydifficulttobuildupanenvironmentatall.

CombinedorSeparateDeployment?(JörgMüller)byJörgMüller,HypoportAG

Thequestionwhetherdifferentservicesarerolledouttogetherorindependentlyfromeachotherisofgreaterrelevancethansometimessuspected.Thisisanexperiencewehadtomakeinthecontextofaprojectwhichstartedapproximatelyfiveyearsago.

ThetermMicroserviceswasnotyetimportantinourindustry.However,achievingagoodmodularizationwasourgoalrightfromthestart.TheentireapplicationconsistedinitiallyofanumberofwebmodulescomingintheshapeoftypicalJavawebapplicationarchives(WAR).Thesecomprisedinturnmultiplemoduleswhichhadbeensplitbasedondomainaswellastechnicalcriteria.In

additiontomodularizationwereliedfromthestartononContinuousDeploymentasamethodforrollingouttheapplication.Eachcommitgoesstraightintoproduction.

Initially,itseemedanobviouschoicetobuildanintegrateddeploymentpipelinefortheentireapplication.Thisenabledintegrationtestsacrossallcomponents.Asingleversionfortheentireapplicationenabledcontrolledbehavior,evenifmultiplecomponentsoftheapplicationswerechangedsimultaneously.Finally,thepipelineitselfwaseasiertoimplement.Thelatterwasanimportantreasonsincetherewererelativelyfewtoolsforcontinuousdeploymentatthetimesothatwehadtobuildmostourselves.

However,aftersometimethedisadvantagesofourapproachbecameobvious.Thefirstconsequencewasalongerandlongerruntimeofourdeploymentpipeline.Thelargerthenumberofcomponentsthatwerebuilt,testedandrolledout,thelongertheprocesstook.Theadvantagesofcontinuousdeploymentsrapidlydiminishedwhentheruntimeofthepipelinebecamelonger.Thefirstcountermeasurewastheoptimizationthatonlychangedcomponentswerebuiltandtested.However,thisincreasedthecomplexityofthedeploymentpipelinetremendously.Atthesametimeotherproblemsliketheruntimeforchangestocentralcomponentsorthesizeoftheartifactscouldnotbeimprovedthisway.

Buttherewasalsoamoresubtleproblem.Acombinedrolloutwithintegrativetestsofferedastrongsecuritynet.Itwaseasytoperformrefactoringsacrossmultiplemodules.However,thisoftenchangedinterfacesbetweenmodulesjustbecauseitwassoeasytodo.Thisisinprincipleagoodthing.However,ithadtheconsequencethatitbecameveryfrequentlynecessarytostarttheentiresystem.Especiallywhenworkingonthedevelopermachinethisturnedintoaburden.Therequirementsforthehardwaregotveryhighandtheturnaroundtimeslengthenedconsiderably.

Theapproachgotevenmorecomplicatedwhenmorethanoneteamworkedwiththisintegratedpipeline.Themorecomponentsweretestedinonepipeline,themorefrequentlyerrorswereuncovered.Thisblockedthepipelinesincetheerrorshadtobefixedfirst.Atthetimewhenonlyoneteamwasdependentonthepipeline,itwaseasytofindsomebodywhotookoverresponsibilityandfixedtheproblem.Whentherewereseveralteamsthisresponsibilitywasnotsoclearanymore.Thisentailedthaterrorsinthepipelinepersistedforalongertime.Simultaneouslythevarietyoftechnologiesincreased.Againthecomplexityrose.

Thispipelinenowneededveryspecializedsolutions.Therefore,theexpenditureformaintenanceincreased,andthestabilitydecreased.Thevalueofcontinuousdeploymentgothardtoputintoeffect.

Atthistimepointitbecameobviousthatthecombineddeploymentinonepipelinecouldnotbecontinuedanymore.Allnewservices,regardlesswhetherMicroservicesorlargermodules,nowhadthereownpipeline.However,itcausedalotofexpendituretoseparatethepreviouspipelinewhichwasbasedonshareddeploymentintomultiplepipelines.

Inanewprojectitcanbetherightdecisiontostartwithacombineddeployment.Thisespeciallyholdstruewhenthebordersbetweentheindividualservicesandtheirinterfacesarenotyetwellknown.Insuchacasegoodintegrativetestsandsimplerefactoringcanbeveryuseful.However,startingatacertainsizeanindependentdeploymentisobligatory.Indicationsforthisarethenumberofmodulesorservices,theruntimeandstabilityofthedeploymentpipelineandlast,butnotleastthequestionhowmanyteamsworkontheoverallsystem.Iftheseindicationsareoverlookedandtherightpointintimetoseparatethedeploymentismissed,itcaneasilyhappenthatonebuildsamonolithwhichconsistsofmanysmallMicroservices.

12.5ControlInterventionsinaMicroservicemightbenecessaryatruntime.Forinstance,aproblemwithaMicroservicemightrequiretorestarttherespectiveMicroservice.Likewise,astartorastopofaMicroservicemightbenecessary.Thesearewaysforoperationtointerveneincaseofaproblemorforaloadbalancertoterminateinstanceswhichcannotprocessrequestsanymore.

Differentmeasurescanbeusedforcontrol:

WhenaMicroservicerunsinavirtualmachine,thevirtualmachinecanbeshutdownorrestarted.InthatcasetheMicroserviceitselfdoesnothavetomakespecialarrangements.Theoperatingsystemsupportsserviceswhicharestartedtogetherwiththeoperatingsystem.Usually,servicescanalsobestopped,startedorrestartedbymeansoftheoperatingsystem.InthatcasetheinstallationonlyhastoregistertheMicroserviceasservice.Workingwithservicesisnothingunusualforoperationwhichissufficientforthisapproach.

Finally,aninterfacecanbeusedwhichallowsrestartingorshuttingdown,forinstanceviaREST.SuchaninterfacehastobeimplementedbytheMicroserviceitself.ThisissupportedbyseverallibrariesintheMicroservicesarea–forinstancebySpringBootwhichisusedtoimplementtheexampleinchapter14.SuchaninterfacecanbecalledwithsimpleHTTPtoolslikecurl.

Technically,theimplementationofcontrolmechanismsisnotabigproblem,buttheyhavetobepresentforoperatingtheMicroservices.WhentheyareidenticallyimplementedforallMicroservices,thiscanreducetheexpenditureforoperatingthesystem.

12.6InfrastructureMicroserviceshavetorunonasuitableplatform.ItisbesttoruneachMicroserviceinaseparatevirtualmachine(VM).OtherwiseitisdifficulttoassureanindependentdeploymentoftheindividualMicroservices.

WhenmultipleMicroservicesrunonavirtualmachine,thedeploymentofoneMicroservicecaninfluenceanotherMicroservice.ThedeploymentcangenerateahighloadorintroducechangestothevirtualmachinewhichalsoconcernotherMicroservicesrunningonthevirtualmachine.

BesidesMicroservicesshouldbeisolatedfromeachothertoachieveabetterstabilityandresilience.WhenmultipleMicroservicesarerunningononevirtualmachine,oneMicroservicecangeneratesomuchloadthattheotherMicroservicesfail.However,preciselythatshouldbeprevented:WhenoneMicroservicefails,thisfailureshouldbelimitedtothisoneMicroserviceandnotaffectadditionalMicroservices.TheisolationofvirtualmachinesishelpfulforlimitingthefailureortheloadtooneMicroservice.

ScalingMicroservicesislikewiseeasierwheneachMicroservicerunsinanindividualvirtualmachine.Whentheloadistoohigh,itissufficienttostartanewvirtualmachineandregisteritwiththeloadbalancer.

IncaseofproblemsitisalsoeasiertoanalyzetheerrorwhenallprocessesonavirtualmachinebelongtooneMicroservice.EachmetriconthesystemthenunambiguouslybelongstothisMicroservice.

Finally,theMicroservicecanbedeliveredasharddriveimagewheneachMicroservicerunsonitsownvirtualmachine.SuchadeploymenthastheadvantagethattheentireenvironmentofthevirtualmachineisexactlyinlinewiththerequirementsoftheMicroserviceandthattheMicroservicecanbringalongitsowntechnologystackuptoitsownoperatingsystem.

VirtualizationorCloud

ItishardlypossibletoinstallnewphysicalhardwareuponthedeploymentofanewMicroservice.BesidesMicroservicesprofitfromvirtualizationorCloudsincethisrenderstheinfrastructuresmuchmoreflexibel.Newvirtualmachinesforscalingortestingenvironmentscaneasilybeprovided.IntheContinuousDeliveryPipelineMicroservicesareconstantlystartedtoperformdifferenttests.Moreover,inproductionnewinstanceshavetobestarteddependingontheload.

Thereforeitshouldbepossibletostartanewvirtualmachineinacompletelyautomatedmanner.StartingnewinstanceswithsimpleAPIcallsisexactlywhataCloudoffers.ACloudinfrastructureshouldbeavailableinordertoreallybeabletoimplementaMicroservice-basedarchitecture.Virtualmachineswhichareprovidedbyoperationviamanualprocessesarenotsufficient.ThisalsodemonstratesthatMicroservicescanhardlyberunwithoutmoderninfrastructures.

Docker

WhenthereisanindividualvirtualmachineforeachMicroservice,itislaborioustogenerateatestenvironmentcontainingallMicroservices.EvencreatinganenvironmentwithrelativelyfewMicroservicescanbeachallengeforadevelopermachine.TheusageofRAMandCPUisveryhighforsuchanenvironment.Infact,itishardlysensibletouseanentirevirtualmachineforoneMicroservice.Intheend,theMicroserviceshouldjustrunandintegrateinloggingandmonitoring.ThereforesolutionslikeDockerareconvenient:Dockerdoesnotcomprisemanyofthenormallycommonoperatingsystemfeatures.

InsteadDockeroffersaverylight-weightvirtualization.TothispurposeDockerusesdifferenttechnologies:

InplaceofacompletevirtualizationDockeremploysLinuxContainers(LXC–LinuXContainer).SupportforsimilarmechanismsinMicrosoftWindowshasbeenannounced.Thisallowstoimplementalight-weightalternativetovirtualmachines:Allcontainersusethesamekernel.Thereisonlyoneinstanceofthekernelinmemory.Processes,networks,datasystemsand

usersareseparatefromeachother.Incomparisontoavirtualmachinewithitsownkernelandoftenalsomanyoperatingsystemservicesacontainerhasaprofoundlyloweroverhead.ItiseasilypossibletorunhundredsofLinuxcontainersonasimplelaptop.Besidesacontainerstartsmuchmorerapidlythanavirtualmachinewithitsownkernelandcompleteoperatingsystem.Thecontainerdoesnothavetobootanentireoperatingsystem;itjuststartsanewprocess.Thecontaineritselfdoesnotaddalotofoverheadsinceitonlyrequiresacustomconfigurationoftheoperatingsystemresources.Inaddition,thefilesystemisoptimized:Basicread-onlyfilesystemscanbeused.Atthesametimeadditionalfilesystemscanbeaddedtothecontainerwhichalsoallowforwriting.Onefilesystemcanbeputontopofanotherfilesystem.Forinstance,abasicfilesystemcanbegeneratedwhichcontainsanoperatingsystem.Ifsoftwareisinstalledintherunningcontaineroriffilesaremodified,thecontaineronlyhastostoretheseadditionalfilesinasmallcontainer-specificfilesystem.Inthiswaythememoryrequirementforthecontainersontheharddriveissignificantlyreduced.

Besidesadditionalinterestingpossibilitiesarise:Forexample,abasicfilesystemcanbestartedwithanoperatingsystem,andsubsequentlysoftwarecanbeinstalled.Asmentioned,onlychangestothefilesystemaresavedwhichareintroducedupontheinstallationofthesoftware.Basedonthisdeltaafilesystemcanbegenerated.Thenacontainercanbestartedwhichputsafilesystemwiththisdeltaontopofthebasicfilesystemcontainingtheoperatingsystem–andafterwardsadditionalsoftwarecanbeinstalledinyetanotherlayer.Inthismannereach“layer”inthefilesystemcancontainspecificchanges.Therealfilesystematruntimecanbecomposedfromnumeroussuchlayers.Thisallowstorecyclesoftwareinstallationsveryefficiently.

Fig.61showsanexampleforthefilesystemofarunningcontainer:ThelowestlevelisanUbuntuLinuxinstallation.OntoptherearechangeswhichhavebeenintroducedbyinstallingJava.Thenthereistheapplication.Fortherunningcontainertobeabletowritechangesintothefilesystem,thereisafilesystemontopintowhichthecontainerwritesfiles.Whenthecontainerwantstoreadafile,itwillmovethroughthelayersfromtoptobottomuntilitfindstherespectivedata.

Fig.61:FilesystemsinDocker

DockerContainervs.Virtualization

Dockercontainersofferaveryefficientalternativetovirtualization.However,theyareno“real”virtualizationsinceeachcontainerhasseparateresources,itsownmemory,anditsownfilesystems,butallshareforinstanceonekernel.Therefore,thisapproachhassomedisadvantages.ADockercontainercanonlyuseLinuxandonlythesamekernellikethehostoperatingsystem–consequently

WindowsapplicationsforinstancecannotberunonaLinuxmachinethisway.Theseparationofthecontainersisnotasstrictasinthecaseofrealvirtualmachines.Anerrorinthekernelwouldforexampleaffectallcontainers.Moreover,DockeralsodoesnotrunonMacOSXorWindows.Nevertheless,Dockercandirectlybeinstalledontheseplatforms.BehindthescenesavirtualmachinewithLinuxisbeingused.MicrosofthasannouncedaversionforWindowswhichcanruntheWindowscontainer.

CommunicationBetweenDockerContainers

Dockercontainershavetocommunicatewitheachother.Forexample,awebapplicationcommunicateswithitsdatabase.Forthispurpose,containersexportnetworkportswhichothercontainersuse.Besidesfilesystemscanbeusedtogether.Therecontainerswritedatawhichcanbereadbyothercontainers.

DockerRegistry

Dockerimagescomprisethedataofavirtualharddrive.DockerregistriesallowtosaveanddownloadDockerimages.ThismakesitpossibletosaveDockerimagesasresultofabuildprocessandsubsequentlytorollthemoutonservers.Becauseoftheefficientstorageofimages,itiseasilypossibletodistributeevencomplexinstallationsinaperformantmanner.BesidesmanyCloudsolutionscandirectlyrunDockercontainers.

DockerandMicroservices

DockerconstitutesanidealrunningenvironmentforMicroservices.IthardlylimitstheusedtechnologyaseverytypeofLinuxsoftwarecanruninaDockercontainer.DockerregistriesallowtoeasilydistributeDockercontainers.AtthesametimetheoverheadofaDockercontainerisnegligibleincomparisontoanormalprocess.SinceMicroservicesrequireamultitudeofvirtualmachines,theseoptimizationsareveryvaluable.OntheonehandDockerisveryefficient,andontheotherhanditdoesnotlimitthetechnologyfreedom.

TryandExperiment

Athttp://www.docker.com/tryit/theDockeronlinetutorialcanbefound.Completethetutorial–itdemonstratesthebasicsofworkingwithDocker.Thetutorialisfasttocomplete.

DockerandServers

TherearedifferentpossibilitiestouseDockerforservers:

OnaLinuxserverDockercanbeinstalled,andafterwardsoneormultipleDockercontainerscanberun.Dockerthenservesassolutionfortheprovisioningofthesoftware.ForaclusternewserversarestartedonwhichagaintheDockercontainersareinstalled.Dockeronlyservesfortheinstallationofthesoftwareontheservers.Dockercontainersarerundirectlyonacluster.OnwhichphysicalcomputeracertainDockerislocatedisdecidedbythesoftwareforclusteradministration.SuchanapproachissupportedbytheschedulerApacheMesos.Itadministratesaclusterofserversanddirectsjobstotherespectiveservers.MesosphereallowstorunDockercontainerswiththeaidoftheMesosscheduler.BesidesMesossupportsmanyadditionalkindsofjobs.KuberneteslikewisesupportstheexecutionofDockercontainersinacluster.However,theapproachtakenisdifferentfromMesos.Kubernetesoffersaservicewhichdistributespodsinthecluster.PodsareinterconnectedDockercontainerswhicharesupposedtorunonaphysicalserver.AsbasisKubernetesrequiresonlyasimpleoperatingsysteminstallation–Kubernetesimplementstheclustermanagement.CoreOSisaverylight-weightserveroperatingsystem.Withetcditsupportsthecluster-widedistributionofconfigurations.fleetdenablesthedeploymentofservicesinacluster–uptoredundantinstallation,failuresecurity,dependenciesandshareddeploymentonanode.AllserviceshavetobedeployedasDockercontainerswhiletheoperatingsystemitselfremainsessentiallyunchanged.DockerMachineallowstheinstallationofDockerondifferentvirtualizationandCloudsystems.BesidesDockermachinecanconfiguretheDockercommandlinetoolinsuchamannerthatitcommunicateswithsuchasystem.TogetherwithDockerComposemultipleDockercontainerscanbecombinedtoanoverallsystem.Theexampleapplicationemploysthisapproach,comparesection14.6andsection14.7.DockerSwarmaddsawaytoconfigureandrunclusterswiththistoolstack:IndividualserverscanbeinstalledwithDockerMachineandcombinedtoaclusterwithDockerSwarm.DockerComposecanruneachDockercontaineronaspecificmachineinthecluster.

Kubernetes,CoreOS,DockerCompose,DockerMachine,DockerSwarmandMesosofcourseinfluencetherunningofthesoftwaresothatthesolutionsrequirechangesintheoperationproceduresincontrasttovirtualization.These

technologiessolvechallengeswhichwerepreviouslyaddressedbyvirtualizationsolutions,namelytoadministrateaclusterofserverssothatcontainersresp.virtualmachinescanbedistributedinthecluster.

PaaS

PaaS(PlatformasaService)isbasedonafundamentallydifferentapproach.Thedeploymentofanapplicationcanbedonesimplybyupdatingtheapplicationinversioncontrol.ThePaaSfetchesthechanges,buildstheapplicationandrollsitoutontheservers.TheseserversareinstalledbyPaaSandrepresentastandardizedenvironment.Theactualinfrastructure–i.e.thevirtualmachines–arehiddenfromtheapplication.PaaSoffersastandardizedenvironmentfortheapplication.Theenvironmenttakesforinstancealsocareofthescalingandcanofferserviceslikedatabasesandmessagingsystems.BecauseoftheuniformplatformPaaSsystemslimitthetechnologyfreedomwhichisnormallyanadvantageofMicroservices.OnlytechnologieswhicharesupportedbyPaaScanbeused.Ontheotherhand,deploymentandscalingarefurtherfacilitated.

Microservicesimposehighdemandsoninfrastructure.AutomationisanessentialprerequisiteforoperatingthenumerousMicroservices.APaaSoffersagoodbasisforthissinceitprofoundlyfacilitatesautomation.TouseaPaaScanbeespeciallysensiblewhenthedevelopmentofahome-grownautomationistoolaboriousandthereisnotenoughknowledgeabouthowtobuildthenecessaryinfrastructure.However,theMicroserviceshavetorestrictthemselvestothefeatureswhichareofferedbythePaaS.WhentheMicroserviceshavebeendevelopedforthePaaSfromthestart,thisisnotverylaborious.However,iftheyhavetobeported,considerableexpenditurecanensue.

Nanoservices(chapter15)havedifferentoperatingenvironments,whichforexampleevenfurtherrestrictthetechnologychoice.Ontheotherhandtheyareofteneveneasiertooperateandevenmoreefficientinregardstoresourceusage.

12.7ConclusionOperatingaMicroservice-basedsystemisoneofthecentralchallengeswhenworkingwithMicroservices(section12.1).AMicroservice-basedsystemcontainsatremendousnumberofMicroservicesandthereforeoperatingsystemprocesses.Fiftyoronehundredvirtualmachinesarenorarity.Theresponsibilityforoperationcanbedelegatedtotheteams.However,thisapproachcreatesahigheroverallexpenditure.Standardizingoperationsisamoresensiblestrategy.

Templatesareapossibilitytoachieveuniformitywithoutexertingpressure.Templatesturntheuniformapproachintotheeasiestone.

Forlogging(section12.2)acentralinfrastructurehastobeprovidedwhichcollectslogsfromallMicroservices.Therearedifferenttechnologiesavailableforthis.TotraceacallacrossthedifferentMicroservicesaCorrelationIDcanbeusedwhichunambiguouslyidentifiesacall.

Monitoring(section12.3)hastoofferatleastbasicinformationsuchastheavailabilityoftheMicroservice.Additionalmetricscanforinstanceprovideanoverviewoftheoverallsystemorcanbeusefulforloadbalancing.MetricscanbeindividuallydefinedforeachMicroservice.Therearedifferentstakeholdersforthemonitoring:Operations,developersandbusinessstakeholders.TheyareinterestedindifferentvaluesandusewherenecessarytheirowntoolsforevaluatingtheMicroservicesdata.EachMicroservicehastoofferaninterfacewithwhichthedifferenttoolscanfetchvaluesfromtheapplication.TheinterfaceshouldbeidenticalforallMicroservices.

ThedeploymentofMicroservices(section12.4)hastobeautomated.Simplescripts,especiallyinconjunctionwithImmutableServer,specialdeploymenttoolsandPackageManagercanbeusedforthispurpose.

Microservicesaresmalldeploymentunits.TheyaresafeguardedbystabilityandresilienceagainstthefailureofotherMicroservices.Therefore,theriskassociatedwithdeploymentsisalreadyreducedbytheMicroservice-basedarchitectureitself.StrategieslikeRollback,RollForward,ContinuousDeployment,Blue/Green-Deploymentorablindmovingalonginproductioncanfurtherreducetherisk.SuchstrategiesareeasytoimplementwithMicroservicessincethedeploymentunitsaresmallandtheconsumptionofresourcesbyMicroservicesislow.Therefore,deploymentsarefaster,andenvironmentsforBlue/Green-DeploymentorCanaryReleasingaremucheasiertoprovide.

Control(section12.5)comprisessimpleinterventionoptionslikestarting,stoppingandrestartingofMicroservices.

VirtualizationorCloudaregoodoptionsforinfrastructuresforMicroservices(section12.6).OneachVMonlyasingleMicroserviceshouldruntoachieveabetterisolation,stabilityandscaling.EspeciallyinterestingisDockerbecausetheconsumptionofresourcesbyaDockerContainerismuchlowerthantheoneofa

VM.ThismakesitpossibletoprovideeachMicroservicewithitsownDockerContainerevenifthenumberofMicroservicesislarge.PaaSarelikewiseinteresting.Theyallowforaverysimpleautomation.However,theyalsorestrictthechoiceoftechnologies.

ThissectiononlyfocusesonthespecificsofContinuousDeliveryandoperationinaMicroservicesenvironment.ContinuousDeliveryisoneofthemostimportantreasonsfortheintroductionofMicroservices.Atthesametimeoperationposesthebiggestchallenges.

EssentialPoints

OperationandContinuousDeliveryarecentralchallengesforMicroservices.TheMicroservicesshouldhandlemonitoring,logginganddeploymentinauniformmanner.Thisistheonlywaytokeeptheeffortreasonable.Virtualization,Cloud,PaaSandDockerareinterestinginfrastructurealternativesforMicroservices.

13OrganizationalEffectsofaMicroservices-basedArchitecture

ItisanessentialfeatureoftheMicroservice-basedapproachthatoneteamisresponsibleforeachMicroservice.Therefore,whenworkingwithMicroservices,itisnecessarytolooknotonlyatthearchitecture,butalsoattheorganizationofteamsandtheresponsibilitiesfortheindividualMicroservices.ThischapterdiscussestheorganizationaleffectsofMicroservices.

Insection13.1organizationaladvantagesofMicroservicesaredescribed.Section13.2showsthatcollectivecodeownershippresentsanalternativetodevisingteamsaccordingtoConway’sLaw.TheindependenceoftheteamsisanimportantconsequenceofMicroservices.Section13.3definesmicroandmacroarchitectureandshowshowtheseapproachesofferahighdegreeofautonomytotheteamsandletthemmakeindependentdecisions.Closelyconnectedisthequestionabouttheroleofthetechnicalleadership(section13.4).DevOpsisanorganizationalapproachwhichcombinesdevelopment(Dev)andoperations(Ops)(section13.5).DevOpshassynergieswithMicroservices.SinceMicroservicesfocusonindependentdevelopmentfromadomainperspective,theyinfluencealsoproductownersandbusinessstakeholderse.g.thedepartmentsofthebusinessthatusesthesoftware.Section13.6discusseshowthesegroupscanhandleMicroservices.ReusablecodecanonlybeachievedinMicroservicesystemsviaorganizationalmeasuresasillustratedinsection13.7.Finally,section13.8followsuponthequestionwhetheranintroductionofMicroservicesispossiblewithoutchangingtheorganization.

13.1OrganizationalBenefitsofMicroservicesMicroservicesareanapproachfortacklingalsolargeprojectswithsmallteams.Astheteamsareindependentofeachother,lesscoordinationisnecessarybetweenthem.Especiallythecommunicationoverheadrenderstheworkoflargeteamssoinefficient.Microservicesareanapproachonthearchitecturallevelforsolvingthisproblem.Thearchitecturehelpstoreducetheneedforcommunicationandtoletmanysmallteamsworkintheprojectinsteadofonelargeone.Each

domain-basedteamcanhavetheidealsize:TheScrumguiderecommendsthreetoninemembers.

Besides,modernenterprisesstressselforganizationandteamswhicharethemselvesactivedirectlyatthemarket.MicroservicessupportthisapproachbecauseeachserviceisintheresponsibilityofanindividualteamconsistentwithConway’sLaw(Section4.2).ThereforeMicroservicesfitwelltoselforganization.Eachteamcanimplementnewfeaturesindependentlyofotherteamsandcanevaluatethesuccessonthemarketbythemselves.

Ontheotherhandthereisaconflictbetweenindependenceandstandardization:Whentheteamsaresupposedtoworkontheirown,theyhavetobeindependent.Standardizationrestrictsindependence.Thisconcernsforinstancethedecisionwhichtechnologiesshouldbeused.Iftheprojectisstandardizedinregardstoacertaintechnologystack,theteamscannotdecideindependentlyanymorewhichtechnologytheywanttouse.Inaddition,independenceconflictswiththewishtoavoidredundancy:Ifthesystemissupposedtobefreeofredundancy,therehastobecoordinationbetweentheteamsinordertoidentifytheredundanciesandtoeliminatethem.Thisinturnlimitstheindependenceoftheteams.

TechnicalIndependence

Animportantaspectisthetechnologicaldecoupling.Microservicescanusedifferenttechnologiesandcanhaveentirelydifferentstructuresinternally.Thismeansthatdevelopershavelessneedtocoordinate.Onlyfundamentaldecisionshavetobemadetogether.Allothertechnicaldecisionscanbemadebytheteams.

SeparateDeployment

EachMicroservicecanbebroughtintoproductionindependentlyoftheotherMicroservices.Thereisalsononeedtocoordinatereleasedatesortestphasesacrossteams.Eachteamcanchooseitsownspeedanditsowndates.Adelayedreleasedateofoneteamdoesnotinfluencetheotherteams.

SeparateRequirementStreams

Theteamsshouldeachimplementindependentstoriesandrequirements.Thisallowseachteamtopursueitsownbusinessobjectives.

ThreeLevelsofIndependence

Microservicesenableindependenceonthreelevels:

Decouplingviaindependentreleases:EachteamtakescareofoneormultipleMicroservices.TheteamcanbringthemintoproductionindependentlyoftheotherteamsandtheotherMicroservices.Technologicaldecoupling:ThetechnicaldecisionsmadebyacertainteamconcernfirstofalltheirMicroservicesandnoneoftheotherMicroservices.Domain-baseddecoupling:Thedistributionofthedomaininseparatecomponentsallowseachteamtoimplementtheirownrequirements.

ForDeploymentMonoliths,incontrast,thetechnicalcoordinationanddeploymentconcernstheentiremonolith(Fig.62).Thisnecessitatessuchaclosecoordinationbetweenthedevelopersthatintheendalldevelopersworkingonthemonolithhavetoactlikeoneteam.

Fig.62:DeploymentMonolith

AprerequisitefortheindependenceoftheMicroserviceteamsisthatthearchitecturereallyoffersthenecessaryindependenceoftheMicroservices.Thisrequiresfirstofallagooddomainarchitecture.Thisarchitectureenablesalsoindependentrequirementstreamsforeachteam.

Fig.63:SeparationintoMicroservices

TherearethefollowingteamsintheexamplefromFig.63:

Theteam“userregistration”takescareofhowuserscanregisterintheE-commerceshop.Apossiblebusinessobjectiveistoachieveahighnumberofregistrations.Newfeaturesaimatoptimizingthisnumber.ThecomponentsoftheteamaretheprocesseswhicharenecessaryfortheregistrationandtheUIelements.Theteamcanchangeandoptimizethematwill.Theteam“orderprocess”addresseshowtheshoppingcartturnsintoanorder.Here,apossibleobjectiveisthatasmanyshoppingcartsaspossibleturnintoorders.Theentireprocessisimplementedbythisteam.Theteam“productsearch”improvesthesearchforproducts.Thesuccessofthisteamdependsonhowmanysearchprocessesleadtoitemsbeingputintoashoppingcart.

Ofcourse,therecanbeadditionalteamswithothergoals.OverallthisapproachdistributesthetaskofdevelopinganE-commerceshopontomultipleteamswhichallhavetheirownobjectives.TheteamscanlargelyindependentlypursuetheirobjectivesbecausethearchitectureofthesystemisdistributedintoMicroserviceswhicheachteamcandevelopindependently–withoutmuchneedforcoordination.

Inadditionsmallprojectshavemanymoreadvantages:

Estimationsaremoreaccuratesinceestimatesconcerningsmallereffortsareeasiertomake.Smallprojectsarebettertoplan.Theriskdecreases–becauseofthemoreaccurateestimatesandbecauseofthebetterforecastreliability.Iftherestillisaproblem,itseffectsaresmallerbecausetheprojectissmaller.

Inaddition,Microservicesoffermuchmoreflexibility.Thismakesdecisionsfasterandeasierbecausetheriskissmallerandchangescanbeimplementedmorerapidly.Thisideallysupportsagilesoftwaredevelopmentwhichreliesonsuchflexibility.

13.2AnAlternativeApproachtoConway’sLawSection4.2introducedConway’sLaw.Accordingtothislaw,anorganizationcanonlygeneratearchitectureswhichmirroritscommunicationstructures.InMicroservice-basedarchitecturestheteamsarebuiltaccordingtotheMicroservices.EachteamdevelopsoneormultipleMicroservices.ThuseachMicroserviceisonlydevelopedbyexactlyoneteam.ThisensuresthatthedomainarchitectureisnotonlyimplementedbythedistributionintoMicroservices,butalsosupportedbytheorganizationaldistribution.Thisrendersviolationsofthearchitecturepracticallyimpossible.MoreovertheteamscanindependentlydevelopfeatureswhenthefeaturesarelimitedtooneMicroservice.ForthistoworkthedistributionofdomainsbetweentheMicroserviceshastobeofveryhighquality.

TheChallengesAssociatedwithConway’sLaw

However,thisapproachalsohasdisadvantages:

Theteamshavetoremainstableinthelongrun.EspeciallywhentheMicroservicesusedifferenttechnologies,therampuptimeforanindividualMicroserviceisverylong.Developerscannoteasilyswitchbetweenteams.Especiallyinteamscontainingexternalconsultantslongtermstabilityisoftenhardtoensure.AlreadytheusualfluctuationofpersonnelcanturnintoachallengewhenworkingwithMicroservices.Intheworstcase,ifthereisnobodylefttomaintainaspecificMicroservice,itisstillpossibletorewrite

therespectiveMicroservice.Microservicesareeasytoreplaceduetotheirlimitedsize.Ofcourse,thisstillentailssomeexpenditure.Onlytheteamunderstandsthecomponent.Whenteammembersquit,theknowledgeaboutoneormultipleMicroservicescangetlost.InthatcasetheMicroservicecannotbemodifiedanymore.Suchislandsofknowledgeneedtobeavoided.InsuchacaseitwillnotbeanoptiontoreplacetheMicroservicesinceanexactknowledgeofthedomainisnecessaryforthis.Changesaredifficultwhenevertheyrequirethecoordinatedworkofmultipleteams.WhenateamcanimplementallchangesforafeatureinitsownMicroservices,architectureandscalingofdevelopmentwillworkverywell.However,whenthefeatureconcernsalsoanotherMicroserviceandthereforeanotherteam,theotherteamneedstoimplementthechangestotherespectiveMicroservice.Thisrequiresnotonlycommunication,butthenecessarychangesalsohavetobeprioritizedversustheotherrequirementsoftheteam.Iftheteamsworkinsprints,ateamcandelivertherequiredchangeswithoutprematurelyterminatingthecurrentsprintearliestinthefollowingsprint–thiscausesamarkeddelay.Incaseofasprintlengthoftwoweeksthedelaycanamounttotwoweeks–iftheteamprioritizesthechangehighenoughsothatitistakencareofinthenextsprint.Otherwisetheensuingdelaycanbeevenlonger.

CollectiveCodeOwnership

WhenitisalwaysonlytheresponsibleteamwhichcanintroducechangestoaMicroservice,anumberofchallengesresultasdescribed.Thereforeitisworthwhiletoconsideralternatives.Agileprocesseshaveledtotheconceptof“CollectiveCodeOwnership”.Here,eachdeveloperhasnotonlytheright,buteventhedutytoalteranycode–forexamplewhenhe/sheconsidersthecodequalityasinsufficientinacertainplace.Therebyalldeveloperstakecareofcodequality.Besidestechnicaldecisionsarebettercommunicatedbecausemoredevelopersunderstandthemduetotheirreadingandchangingcode.Thisleadstothecriticalquestioningofdecisionssothattheoverallqualityofthesystemincreases.

CollectiveCodeOwnershipcanrelatetoateamanditsMicroservices.Sincetheteamsarerelativelyfreeintheirorganization,suchanapproachispossiblewithoutmuchcoordination.

AdvantagesofCollectiveCodeOwnership

However,inprincipleteamscanalsomodifyMicroserviceswhichbelongtootherteams.ThisapproachisusedbysomeMicroserviceprojectstodealwiththediscussedchallengesbecauseitentailsanumberofadvantages:

ChangestoaMicroserviceofanotherteamcanbefasterandmoreeasilyimplemented.Whenamodificationisnecessary,thechangehasnottobeintroducedbyanotherteam.Insteadtheteamrequiringthechangecanimplementitbyitself.Itisnotnecessaryanymoretoprioritizethechangeinregardstootherchangestothecomponent.Teamscanbeputtogethermoreflexibly.Thedevelopersarefamiliarwithalargerpartofthecode–atleastsuperficiallyduetochangeswhichtheyhaveintroducedinthecode.Thismakesiteasiertoreplaceteammembersorevenanentireteam–ortoenlargeateam.Thedevelopersdonothavetorampupfromtheverybasics.Astableteamisstillthebestoption–however,oftenthiscannotbeachieved.ThedistributioninMicroservicesiseasytochange.BecauseofthebroaderknowledgeofthedevelopersitiseasiertomoveresponsibilityforaMicroservicetoadifferentteam.ThiscanbesensiblewhenMicroserviceshavealotofdependenciesoneachother,butareintheresponsibilityofdifferentteamswhichthenhavetocloselyandlaboriouslycoordinate.IftheresponsibilityfortheMicroservicesischangedsothatthesameteamisresponsibleforbothofthecloselycoupledMicroservices,coordinationiseasierthaninthecasewheretwoteamswereworkingontheseMicroservices.Withinoneteamtheteammembersoftensitinthesameoffice.Thereforetheycaneasilyanddirectlycommunicatewitheachother.

DisadvantagesofCollectiveCodeOwnership

However,therealsodisadvantagesassociatedwiththisapproach:

CollectiveCodeOwnershipsisincontrasttotechnologyfreedom:Wheneachteamusesothertechnologies,itisdifficultfordevelopersoutsideofateamtochangetherespectiveMicroservices.TheymightnotevenknowthetechnologyusedintheMicroservice.Theteamscanlosetheirfocus.Thedevelopersacquirealargeroverviewofthefullsystem.However,itmightbebetterwhenthedevelopersconcentrateontheirownMicroservicesinstead.Thearchitectureisnotassolidanymore.Byknowingthecodeofothercomponentsdeveloperscanexploittheinternalsandtherebyrapidlycreatedependencieswhichhadnotbeenintendedinthearchitecture.Finally,the

distributionoftheteamsaccordingtoConway’sLawissupposedtosupportthearchitecturebyturninginterfacesbetweendomaincomponentsintointerfacesbetweenteams.However,theinterfacesbetweentheteamsloseimportancewheneverybodycanchangethecodeofeveryotherteam.

PullRequestsforCoordination

Communicationbetweenteamsisstillnecessary:IntheendtheteamresponsiblefortherespectiveMicroservicehasthemostknowledgeabouttheMicroservice.Sochangesshouldbecoordinatedwiththerespectiveteam.Thiscanbesafeguardedtechnically:Thechangesoftheexternalteamscaninitiallybeintroducedseparatelyfromotherchangesandsubsequentlybesenttotheresponsibleteamviaapullrequest.Pullrequestsbundlechangestothesourcecode.Especiallyintheopensourcecommunitytheyareapopularapproachtoallowforexternalcontributionswithoutgivingupcontroloftheproject.Theresponsibleteamcanacceptthepullrequestordemandfixes.Thismeansthatthereisareviewforeachchangebytheresponsibleteam.ThisallowstheresponsibleteamtoensurethatthearchitectureanddesignoftheMicroserviceremainsound.

Sincethereisstilltheneedforcommunicationbetweenteams,Conway’sLawisnotviolatedbythisapproach.Itisjustadifferentwayofplayingthegame.IncaseofabadsplitamongteamsinaMicroservice-basedarchitecturealloptionsareassociatedwithtremendousdisadvantages.TocorrectthedistributionisdifficultaslargerchangesacrossMicroservicesarelaboriousasdiscussedinsection8.4.Duetotheunsuitabledistributiontheteamsareforcedtocommunicatealotwitheachother.Therebyproductivityislost.Thereforeitisalsonooptiontoleavethedistributionasitis.CollectiveCodeOwnershipcanbeusedtolimittheneedforcommunication.Theteamsdirectlyimplementrequirementsinthecodeofotherteams.Thiscauseslessneedforcommunicationandbetterproductivity.Todosothetechnologyfreedomshouldberestricted.ThechangestotheMicroservicesstillhavetobecoordinated–atleastreviewsaredefinitelynecessary.However,ifthearchitecturehadbeensetupappropriatelyfromthestart,thismeasurewouldnotbenecessaryatallasworkaround.

TryandExperiment

DidyoualreadyencounterCollectiveCodeOwnership?Whichexperiencesdidyoumakewithit?

Whichrestrictionsarethereinyourcurrentprojectwhenadeveloperwantstochangesomecodewhichhasbeenwrittenbyanotherdeveloperinthesameteamorbyadeveloperfromanotherteam?Arechangestothecodeofotherteamsnotmeanttooccur?Inthatcase,howisitstillpossibletoimplementthenecessarychanges?Whichproblemsareassociatedwiththiscourseofaction?

13.3MicroandMacroArchitectureMicroservicesallowtolargelyavoidoverarchingarchitecturedecisions.EachteamcanchoosetheoptimaltypeofarchitectureforitsMicroservices.

BasisforthisistheMicroservicesarchitecture.Itallowsalargedegreeoftechnicalfreedom.Whilenormallyduetotechnicalreasonsuniformtechnologiesaremandatory,Microservicesdonothavetheserestrictions.However,therecanbeotherreasonsforuniformity.Thequestioniswhichdecisionismadebywhom.Therearetwolayersofdecisionmaking:

Macroarchitecturecomprisesthedecisionswhichconcerntheoverallsystem.Theseareatleastthedecisionspresentedinchapter8regardingthedomainarchitectureandbasictechnologies,whichhavetobeusedbyallMicroservices,aswellascommunicationprotocols(chapter9).ThepropertiesandtechnologiesofindividualMicroservicescanalsobepreset(chapter10).However,thisdoesnothavetobethecase.DecisionsabouttheinternalsoftheindividualMicroservicesdonothavetobemadeinthemacroarchitecture.Themicroarchitecturedealswithdecisionseachteamcanmakebyitself.TheseshouldaddresstopicswhichconcernonlytheMicroservicesdevelopedbytherespectiveteam.Amongthesetopicscanbeallaspectspresentedinchapter10aslongastheyhavenotalreadybeendefinedaspartofthemacroarchitecture.

Themacroarchitecturecannotbedefinedonceforall,buthastoundergocontinuousdevelopment.Newfeaturescanrequireadifferentdomainarchitecture

ornewtechnologies.Optimizingthemacroarchitectureisapermanentprocess.

Decision=Responsibility

Thequestioniswhodefinesmacroandmicroarchitectureandtakescareoftheiroptimization.Itisimportanttokeepinmindthateachdecisionislinkedtoresponsibility.Whoevermakesadecisionisresponsibleforitsconsequences-goodorbad.InturntheresponsibilityforaMicroserviceentailsthenecessitytomaketherequireddecisionsforitsarchitecture.Whenthemacroarchitecturedefinesacertaintechnologystack,theresponsibilityforthisstackrestswiththepersonsresponsibleforthemacroarchitecture–notwiththeteamswhichusethemintheMicroservicesandmightlaterhaveproblemswiththistechnologystack.ThereforeastrongrestrictionofthetechnologyfreedomoftheindividualMicroservicesbythemacroarchitectureisoftennothelpful.ItonlyshiftsdecisionsandresponsibilitytoalevelwhichdoesnothavemuchtodowiththeindividualMicroservices.Thiscanleadtoanivorytowerarchitecturethatisnotbasedontherealrequirements.Inthebestcaseitisignored.Intheworstcaseitcausesseriousproblemsintheapplication.Microservicesallowtolargelydowithoutmacroarchitecturedecisionsinordertoavoidsuchanivorytowerarchitecture.

WhoCreatesMacroArchitecture?

FordefiningmacroarchitecturedecisionshavetobemadewhichaffectallMicroservices.SuchdecisionscannotbemadebyasingleteamsincetheteamsonlycarryresponsibilityfortheirrespectiveMicroservices.MacroarchitecturedecisionsgobeyondindividualMicroservices.

Themacroarchitecturecanbedefinedbyateamwhichiscomposedfrommembersofeachindividualteam.Thisapproachseemstobeobviousatfirstglance:Itallowsallteamstovoicetheirperspectives.Nobodydictatescertainapproaches.Theteamsarenotleftoutofthedecisionprocess.TherearemanyMicroserviceprojectswhichverysuccessfullyemploythisapproach.

However,thisapproachhasalsodisadvantages:

Fordecisionsatthemacroarchitecturelevelanoverviewoftheoverallsystemisnecessaryandaninteresttodevelopthesysteminitsentirety.MembersoftheindividualteamsoftenhaveastrongfocusontheirownMicroservices.ThatisofcourseverysensiblesincethedevelopmentoftheseMicroservicesistheirprimarytask.However,thiscanmakeithardfor

themtomakeoverarchingdecisionssincethoserequireadifferentperspective.Thegroupcanbetoolarge.Effectiveteamsnormallyhavefivetotenmembersatmaximum.Iftherearemanyteamsandeachissupposedtoparticipatewithatleastonemember,themacroarchitectureteamwillgettoolargeandthuscannotworkeffectivelyanymore.Largeteamsarehardlyabletodefineandmaintainthemacroarchitecture.

Thealternativeistohaveasinglearchitectoranarchitectureteamwhichisexclusivelyresponsibleforshapingthemacroarchitecture.Forlargerprojectsthistaskissodemandingthatforsureanentirearchitectureteamisneededtoworkonit.Thisarchitectureteamtakestheperspectiveoftheoverallproject.However,thereisadangerthatthearchitectureteamdistancesitselftoomuchfromtherealworkoftheotherteamsandconsequentlymakesivory-towerdecisionsorsolvesproblemstheteamsdonotactuallyhave.Therefore,thearchitectureteamshouldmainlymoderatetheprocessofdecisionmakingandmakesurethattheviewpointsofthedifferentteamsareallconsidered.Itshouldnotsetacertaindirectionallbyitself.IntheendthedifferentMicroservicesteamswillhavetolivewiththeconsequencesofthearchitectureteam’sdecisions.

ExtentoftheMacroArchitecture

Thereisnooneandonlywaytodividethearchitectureintomicroandmacroarchitecture.Thecompanyculture,thedegreeofselforganizationandotherorganizationalcriteriaplayaprominentrole.Ahighlyhierarchicalorganizationwillgivetheteamslessfreedom.Whenasmanydecisionsaspossiblearemadeonthelevelofthemicroarchitecture,theteamswillgainmoreresponsibility.Thisoftenhaspositiveeffectsbecausetheteamsreallyfeelresponsibleandwillactaccordingly.

TheNUMMIcarfactoryintheUSAforinstancewasaveryunproductivefactorywhichwasknownfordrugabuseandsabotage.Byfocusingmoreonteamworkandtrustthesameworkerscouldbeturnedintoaveryproductiveworkforce.Whenteamsareabletomakemoredecisionsontheirownandhavemorefreedomofchoice,theworkclimateaswellasproductivitywillprofoundlybenefit.

Besides,bydelegatingdecisionstoteamslesstimeisspentoncoordinationsothattheteamscanworkmoreproductively.Toavoidtheneedforcommunicationbydelegatingmoredecisionstotheteamsandthereforetomicroarchitectureisanessentialpointforarchitecturescaling.

However,whentheteamsareveryrestrictedintheirchoices,oneofthemainadvantagesofMicroservicesisnotrealized.Microservicesincreasethetechnicalcomplexityofthesystem.ThisonlymakessenseiftheadvantagesofMicroservicesarereallyexploited.Consequently,whenthedecisionforMicroserviceshasbeenmade,thereshouldalsobeadecisionforhavingasmuchmicroarchitectureandaslittlemacroarchitectureaspossible.

Thedecisionformoreorlessmacroarchitecturecanbemadeforeachareadifferently.

Technology:Macro/MicroArchitecture

Forthetechnologiesthefollowingdecisionscanbemadeconcerningmacrovs.microarchitecture:

Uniformsecurity(section8.12),servicediscovery(section8.9)andcommunicationprotocols(chapter9)arenecessarytoenableMicroservicestocommunicatewitheachother.Thereforedecisionsintheseareasclearlybelongtomacroarchitecture.Amongthesearealsothedecisionsfortheuseanddetailsofdownwardscompatibleinterfaceswhicharerequiredfortheindependentdeploymentofmicroservices.Configurationandcoordination(Section8.8)donotnecessarilyhavetobedeterminedgloballyforthecompleteproject.WheneachMicroserviceisoperatedbyitsrespectiveteam,theteamcanalsohandletheconfigurationanduseitsowntoolofchoiceforit.However,auniformtoolforallMicroserviceshasclearadvantages.Besidesthereishardlyanysensiblereasonwhyeachteamshoulduseadifferentmechanism.Theuseofresilience(section10.5)orloadbalancing(section8.10)canbedefinedinthemacroarchitecture.ThemacroarchitecturecaneitherdefineacertainstandardtechnologyorjustenforcethatthesepointshavetobeaddressedduringtheimplementationoftheMicroservices.Thiscanforinstancebeensuredbytests(section11.8).ThetestscancheckwhetheraMicroserviceisstillavailableafteradependentMicroservicefailed.Inaddition,theycancheckwhethertheloadisdistributedtomultipleMicroservices.Thedecisionfortheuseofresilienceorloadbalancingcanbetheoreticallylefttotheteams.Whentheyareresponsiblefortheavailabilityandtheperformanceoftheirservice,theyhavetohavethefreedomtousetheirchoiceoftechnologiesforit.WhentheirMicroservicesaresufficientlyavailablewithoutresilienceandloadbalancing,theirstrategy

isacceptable.However,intherealworldsuchscenariosarehardtoimagine.Inregardstoplatformandprogramminglanguagethedecisioncanbemadeatthelevelofmacroormicroarchitecture.Thedecisionmightnotonlyinfluencetheteamsbutalsooperationssinceoperationsneedstounderstandthetechnologiesandneedtobeabletodealwithfailures.Itisnotnecessarilyrequiredtoprescribeaprogramminglanguage.Alternatively,thetechnologycanberestrictede.g.totheJVM(JavaVirtualMachine)whichsupportsanumberofprogramminglanguages.Inregardstotheplatformapotentialcompromiseisthatacertaindatabaseisprovidedbyoperations,butthattheteamscanalsouseandoperatedifferentones.Whetherthemacroarchitecturedefinesplatformandprogramminglanguagedependsalsoonwhetherdevelopersneedtobeabletochangebetweenteams.AsharedplatformfacilitatestransferringtheresponsibilityforaMicroservicefromoneteamtoanotherteam.

Fig.64showswhichdecisionsarepartofthemacroarchitecture-theyareontherightside.Themicroarchitecturepartsareontheleftside.Theareasinthemiddlecanbeeitherpartofthemacroormicroarchitecture.Eachprojectcanhandlethemdifferently.

Fig.64:Technology:macroandmicroarchitecture

Operations

Intheareaofoperationsthereiscontrol(section12.5),monitoring(section12.3),logging(section12.2)anddeployment(section12.4).Toreducethecomplexityoftheenvironmentandtoenableauniformoperationssolutiontheseareashavetobedefinedbymacroarchitecture.Thesameholdstrueforplatformandprogramminglanguage.However,standardizingisnotobligatory:Whentheentireoperationsof

theMicroservicesrestswiththeteams,theoreticallyeachteamcanuseadifferenttechnologyforeachofthementionedareas.Butwhilethisscenariodoesnotgeneratemanyadvantages,itcreatesahugetechnologicalcomplexity.However,itisforexamplepossiblethattheteamsusetheirownspecialsolutionforcertaintasks.Whenforinstancetherevenueissupposedtobetransferredinadifferentwayintothemonitoringforthebusinessstakeholders,thisiscertainlydoable.

Fig.65:Operations:macroandmicroarchitecture

DomainArchitecture

Inthecontextofdomainarchitecturethedistributionofdomainstoteamsispartofthemacroarchitecture(section8.1).Itdoesnotonlyinfluencethearchitecture,butdecidesalsowhichteamsareresponsibleforwhichdomains.Thereforethistaskcannotbemovedintothemicroarchitecture.However,thedomainarchitectureoftheindividualMicroserviceshastobelefttotheteams(section10.1,10.2,10.3,10.4).TodictatethedomainarchitectureoftheindividualMicroservicestotheteamswouldbeequivalenttotreatingMicroservicesattheorganizationallevellikemonolithsbecausetheentirearchitectureiscentrallycoordinated.InthatcaseonecouldaswelldevelopaDeploymentMonolithwhichistechnicallyeasier.Suchadecisionwouldnotmakesense.

Fig.66:Architecture:macroandmicroarchitecture

Tests

Intheareaoftestingintegrationtests(section11.4)belongtothemacroarchitecture.Inpracticeithastobedecidedwhetherthereshouldbean

integrationtestforacertaindomainandwhoshouldimplementit.Integrationtestsonlymakesensewhentheyconcernfunctionalitiesacrossteams.Therespectiveteamscantestallotherfunctionalitiesontheirown.Thereforeintegrationtestshavetobegloballycoordinatedacrossteams.Technicaltests(section11.8)canbedictatedtotheteamsbythemacroarchitecture.Theyareagoodoptiontoenforceandcontrolglobalstandardsandtechnicalareasofmacroarchitecture.Consumer-drivencontracttests(CDC)(section11.7)andStubs(section11.6)canbecoordinatedbetweentheteamsthemselves.Asharedtechnologicalfoundationaspartofmacroarchitecturecanprofoundlyfacilitatedevelopment.UniformtechnologiesareespeciallysensibleinthisareasinceteamshavetousetheCDCsandStubsofotherteams.Whenonlyonetechnologyisused,workismarkedlyeasier.However,itisnotobligatorythattechnologiesarerigidlyprescribedbythemacroarchitecture.

HowtotesttherespectiveMicroservicesshouldbeuptotheindividualteamsastheyhavetheresponsibilityforthequalityoftheMicroservices.

Fig.67:Test:macroandmicroarchitecture

Inmanyareasdecisionscanbemadeeitheratthelevelofmacrooratthelevelofmicroarchitecture.ItisacentralobjectiveofMicroservice-basedarchitecturestogivetheindividualteamsasmuchindependenceaspossible.Therefore,asmanydecisionsaspossibleshouldbemadeonthelevelofmicroarchitectureandthereforebytheindividualteams.However,inregardstooperationsthequestionariseswhethertheteamsreallyprofitfromthefreedomtousetheirowndistincttools.Itseemsmorelikelythatthetechnologyzoojustgetsbiggerwithoutrealadvantages.InthisareathereisaconnectiontoDevOps(section13.5).Dependingonthedegreeofcooperationbetweendevelopersandoperationstherecanbedifferentdegreesoffreedom.Incaseofacleardivisionbetween

developmentandoperationsoperationswilldefinemanystandardsinmacroarchitecture.IntheendoperationswillhavetotakecareoftheMicroservicesinproduction.WhenallMicroservicesemployauniformtechnology,thistaskiseasier.

Whendefiningprogramminglanguageandplatformoneshouldlikewiseweightheadvantagesofspecializedtechnologystacksversusthedisadvantagesofhavingheterogeneoustechnologiesintheoverallsystem.Dependingonthecircumstancesthedecisiontoprescribeatechnologystackmightbeassensibleasthedecisiontoleavethetechnologychoicetotheindividualteams.AuniformtechnologystackcanfacilitateoperationsandmakeiteasierfordeveloperstochangebetweenMicroservicesandteams.Specializedtechnologystacksmakeiteasiertohandlespecialchallengesandmotivateemployeeswhothushavethepossibilitytousecuttingedgetechnologies.

WhetheraMicroservicereallyconformstothemacroarchitecturecanbeevaluatedbyatest(comparesection11.8).Thistestcanbeanartifactwhichislikewisepartofthemacroarchitecture.Thegroupresponsibleforthemacroarchitecturecanusethisartifacttounambiguouslydefinethemacroarchitecture.ThisallowstocheckwhetherallMicroservicesareinlinewithmacroarchitecture.

13.4TechnicalLeadershipThedivisioninmicroandmacroarchitecturecompletelychangesthetechnicalleadershipteamsandisanessentialadvantageofMicroservices.Themacroarchitecturedefinestechnicaldutiesandfreedom.Thefreedomofchoiceentailsalsotheresponsibilityfortherespectivedecisions.

Forexampleadatabasecanbeprescribed.Inthatcasetheteamcandelegatetheresponsibilityforthedatabasetothetechnicalleadershipteam.Ifthedatabasedecisionwerepartofthemicroarchitecture,thedatabasewouldberunbytheteamsinceitmadethedecisionforthetechnology.Nootherteamwouldneedtodealwithpotentialconsequencesofthisdecision(comparesection8.7).Whoevermakesthedecision,alsohastheresponsibility.Thetechnicalleadershipteamforsurecanmakesuchdecisions,butbydoingsoittakesawayresponsibilityfromtheMicroservicesteamsandtherebyindependence.

Alargerdegreeoffreedomentailsmoreresponsibility.Theteamshavetobeabletodealwiththisandalsohavetowantthisfreedom.Unfortunately,thisisnot

alwaysthecase.Thiscaneitherargueformoremacroarchitectureorfororganizationalimprovementswhichintheendleadtomoreselforganizationandthuslessmacroarchitecture.Itisoneoftheobjectivesofthetechnicalleadershipteamtoenablelessmacroarchitectureandtoleadthewaytomoreselforganization.

DeveloperAnarchy

TheapproachDeveloperAnarchyisevenmoreradicalinregardstothefreedomoftheteams.Itconferstheentireresponsibilitytothedevelopers.Theycannotonlyfreelychoosetechnologies,butevenrewritecodeiftheydeemitnecessary.Besides,theycommunicatedirectlywiththestakeholders.Thisapproachisemployedinveryfastgrowingenterprisesandworksverywellthere.BehindthisideaisFredGeorgewhohascollectedmorethan40yearsofexperiencewhileworkinginmanydifferentcompanies.InamodellikethismacroarchitectureandDeploymentMonolithsareabolishedsothatthedeveloperscandowhattheythinkisbest.Thisapproachisveryradicalandshowshowfartheideacanbeextended.

TryandExperiment

InFig.64,Fig.65,Fig.66andFig.67areasaremarkedwhichcanbelongtoeithermicroormacroarchitecture.Thesearetheelementswhicharedepictedinthecenteroftherespectivefigure.Lookthroughtheseelementsanddecidewhetheryouwouldplacetheminmicroormacroarchitecture.Mostimportantisyourreasoningfortheoneortheotheralternative.TakeintoconsiderationthatmakingdecisionsatthelevelofthemicroarchitecturerathercorrespondstotheMicroserviceideaofindependentteams.

13.5DevOpsDevOpsdenotestheconceptthatdevelopments(Dev)andoperations(Ops)mergeintooneteam(DevOps).Thisisanorganizationalchange:Eachteamhasdevelopersandoperationsexperts.TheyworktogetherinordertodevelopandoperateaMicroservice.Thisrequiresadifferentmindsetsinceoperations-associatedtopicsareoftenunfamiliartodeveloperswhilepeopleworkinginoperationsoftendonotworkinprojects,butusuallyrunsystemsindependentlyofprojects.Ultimately,thetechnicalskillsbecomeverysimilar:Operationsworksmoreonautomationandassociatedsuitabletests–andthisisintheendsoftware

development.Atthesametimemonitoring,loganalysisordeploymentturnmoreandmorealsointotopicsfordevelopers.

DevOpsandMicroservices

DevOpsandMicroservicesideallycomplementeachother:

Theteamscannotonlytakecareofthedevelopment,butalsooftheoperationsoftheMicroservices.Thisrequiresthattheteamshaveknowledgeintheareasofoperationsanddevelopment.OrientingtheteamsinlinewithfeaturesandMicroservicesrepresentsasensibleorganizationalalternativetothedivisionintooperationsanddevelopment.Communicationbetweenoperationsanddevelopmentgetseasierwhenmembersofbothareasworktogetherinoneteam.Communicationwithinateamiseasierthanbetweenteams.ThisisinlinewiththeaimofMicroservicestoreducetheneedforcoordinationandcommunication.

DevOpsandMicroservicesfitverywelltogether.Infact,theaimthatteamsdeployMicroservicesuptoproductionandkeeptakingcareoftheminproductioncanonlybeachievedwithDevOpsteams.Thisistheonlywaytoensurethatteamshavethenecessaryknowledgeaboutbothareas.

DoMicroservicesNecessitateDevOps?

DevOpsissuchaprofoundchangeinorganizationthatmanyenterprisesarestillreluctanttotakethisstep.ThereforethequestionariseswhetherMicroservicescanalsobeimplementedwithoutintroducingDevOps.Infact,thisispossible:

Viathemacrovs.microarchitecturedivisionoperationscandefinestandards.Thentechnicalelementslikelogging,monitoringordeploymentbelongtothemacroarchitecture.Whenthesestandardsareconformedto,operationscantakeoverthesoftwareandmakeitpartofthestandardoperationsprocesses.Inaddition,platformandprogramminglanguagecanbedefinedasmuchasneededforoperations.WhenoperationsonlyfeelscomfortablewithrunningJavaapplicationsonaTomcat,thiscanbeprescribedasplatforminthemacroarchitecture.Thesameholdstrueforinfrastructureelementslikedatabasesormessagingsystems.Moreover,therecanbeorganizationalrequirements:Forexample,operationscanaskthatmembersoftheMicroservicesteamsareavailableatcertain

timessothatproblemsarisinginproductioncanbereferredtotheteams.Toputitconcretely:Whowantstodeployonhis/herown,hastoprovideaphonenumberandwillalsobecalledatnightincaseofproblems.Ifthecallisnotanswered,themanagementcanbecallednext.Thisincreasesthelikelihoodthatdevelopersactuallyanswersuchcalls.

InsuchacontexttheteamscannotberesponsibleanymoreforbringingallMicroservicesuptoproduction.Accessandresponsibilityrestwithoperations.TherehastobeapointintheContinuousDeliveryPipelinewheretheMicroservicesarepassedontooperationsandthenarerolledoutinproduction.AtthispointtheMicroservicepassesintotheresponsibilityofoperationswhichhastocoordinatewiththerespectiveteamabouttheirMicroservices.Atypicalpointforthetransfertooperationsisimmediatelyafterthetestphases,priortopossibleexplorativetests.Operationsisatleastresponsibleforthelastphase,i.e.therolloutinproduction.OperationscanturnintoabottleneckifahighnumberofmodifiedMicroserviceshavetobebroughtintoproduction.

OverallDevOpsandMicroserviceshavesynergies–however,itisnotnecessarilyrequiredtoalsointroduceDevOpswhendecidingforMicroservices.

WhenMicroservicesMeetClassicalITOrganizations(AlexanderHeusingfeld)byAlexanderHeusingfeld,innoQ

The“Microservices”topichasmeanwhilereachednumerousITdepartmentsandisdiscussedthere.Interestingly,initiativesforintroducingMicroservicesareoftenstartedbymiddlemanagement.However,frequentlytoolittlethoughtisspentontheeffectaMicroservicearchitecturehasonthe(IT)organizationofenterprises.BecauseofthisIwouldliketotellofanumberof“surprises”whichIexperiencedduringtheintroductionofsuchanarchitectureapproach.

Petsvs.Cattle

“Petsvs.Cattle”isasloganwhichreachedacertainfameattheoutsetoftheDevOpsmovement.Itsbasicmessageisthatintimesofcloudandvirtualizationserversshouldnotbetreatedlikepets,butratherlikeaherdofcattle.Ifapetgetssick,theownerwilllikelynurseitbacktohealth.Sickcattleontheotherhandiskilledimmediatelyinordernottoendangerthehealthoftheentireherd.

Thusthepointistoavoidthepersonificationofservers–e.g.bygivingthemnames(likeLeviathan,Pollux,BerlinorLorsch).Ifyouassignsuch“pet”namestoservers,therewillbeatendencytocareforthemlikepetsandthusprovideindividualupdates,scripts,adjustmentsorotherspecificmodifications.However,itiswellknownthatthishasnegativeconsequencesforthereproducibilityofinstallationsandserverstate.Especiallyconsideringauto-scalingandfailoverfeaturesastheyarerequiredforMicroservice-basedarchitectures,thisisaK.O.criterion.

Oneofmyprojectsaddressedthisprobleminaveryinterestingmanner:Theserverandvirtualmachinesstillhadnames.However,theadministrationofthesesystemswascompletelyautomatedviaPuppet.PuppetdownloadedtherespectivescriptsfromanSVNrepository.Inthisrepositoryindividualscriptsforeachserverwerestored.Thisscenariocouldbecalled“Puppetsforautomatedpetcare”.Theadvantageisthatcrashedserverscanquicklybereplacedbyexactcopies.

However,requirementsforscalabilityarenottakenintoconsiderationatall,sincetherecanalwaysonlybeoneinstanceofa“petserver”namedLeviathan.Analternativeistoswitchtoparameterizedscriptsandtousetemplateslike“productionVMforappXYZ”.AtthesametimethisalsoallowsmoreflexibledeploymentscenarioslikeBlue/GreenDeployments.InthatcaseitisnotrelevantanymorewhethertheVMapp-xyz-prod08.zone1.company.comorapp-xyz-prod045.zone1.company.comgetsthejobdone.Theonlyrelevantpointisthateightinstancesofthisserviceareconstantlyavailableandattimesofhighloadadditionalinstancescanbestarted.Howtheseinstancesarenameddoesnotmatter.

Usvs.Them

“Alarmingisourconcern!”

“Youshouldn’tcareaboutthat!”

“Thatisnoneofyourbusiness,it’sourarea!”

UnfortunatelyIfrequentlyhearsentencesliketheseinso-calledcross-functionalteams.Theseareteamscomposedofarchitects,developers,testersandadministrators.Especiallyifthememberspreviouslyworkedinother,purelyfunctionalteamswithinthesamecompany,oldtrenchwarsandprejudicesare

carriedalongintothenewteam–oftensubconsciously.Therefore,itisimportanttobeawareofthesocialaspectsrightfromthestartandtocountertheseproactively.Forexample,inmyexperienceithasverypositiveeffectstoletnewlysetupteamsworkinthesameofficeforthefirsttwotofourweeks.Thisallowsthenewteammatestogettoknoweachother’shumansideandtodirectlyexperiencethecolleague’sbodylanguage,characterandhumor.Thiswillmarkedlyfacilitatecommunicationduringthelatercourseoftheproject,misunderstandingsareavoided.

Inaddition,teambuildingmeasuresduringthefirstweekswhichrequirethattheteammembersrelyoneachothercanhelptobreaktheice,togetanideaofthestrengthsandweaknessesoftheindividualmembersandtobuildupandstrengthentrustwithintheteam.Ifthesepointsareneglected,therewillbenoticeableadverseconsequencesthroughouttheruntimeoftheproject.Peoplewhodonotlikeeachotherordonottrusteachother,willnotrelyoneachother,evenifonlysubconsciously.Andthismeansthattheywillnotbeabletowork100%asateam.

Developmentvs.Testvs.Operation:ChangeofPerspective

Inmanycompaniesthereareinitiativesforachangeofperspective.Forexample,employeesfromsalesmayworkinthepurchasingdepartmentforadaytogettoknowthepeopleandtheprocessesthere.Theexpectationisthattheemployeeswilldevelopabetterunderstandingfortheircolleaguesandtoletthatbecomepartoftheirdailyworksothatcross-departmentprocessesharmonizebetter.Themottois:“On‘theotherside’yougettoknowanewperspective!”

SuchachangeofperspectivecanalsobeadvantageousinIT.Adevelopercouldforinstancegetanewperspectivewithregardstotheusecasesortestcases.Thismightmotivatethemtoenforceamodularizationinthedevelopmentwhichiseasiertotest.Ortheymightconsiderearlyindevelopmentwhichcriteriawillbeneededlaterontobettermonitorthesoftwareinproductionortomoreeasilyfinderrors.Adeeperinsightintotheinternalprocessesoftheapplicationcanhelpanadministratortodevelopabetterunderstandingforimplementingamorespecificandmoreefficientmonitoring.Eachperspective,whichdeviatesfromone’sownperspective,canraisequestionswhichpreviouslywerenotconsideredinthissectionoftheapplicationlifecycle.Andthesequestionswillhelptheteamtoevolveasawholeanddeliverbettersoftware.

ForOpsthereisNeveran“EntirelyGreenField”

ForsureMicroservicesareatopicalsubjectandbringalongnewtechnologies,conceptsandorganizationalchanges.However,oneshouldalwaysconsiderthatenterprisesintroducingMicroserviceshardlyeverstartfromscratch!TherearealwayssomekindoflegacysystemsorentireITenvironmentswhichalreadyexistandmightbetternotbereplacedinaBigBangapproach.UsuallytheselegacysystemshavetobeintegratedintothebravenewworldofMicroservices,atleasttheywillhavetocoexist.

Forthisreason,itisimportanttotakethesesystemsintoconsiderationwhenplanningaMicroservices-basedarchitecture,especiallyinregardstoITcosts.CantheexistinghardwareinfrastructurereallyberestructuredfortheMicroservicesoristherealegacysystemwhichreliesexactlyonthisinfrastructure?Theseareoftenquestionswhichgetcaughtontheinfrastructureoroperationsteam–ifthereissuchanorganizationalunitinthecompany.Otherwiseitmighthappenthatthesequestionsfirstarisewhenadeploymenttothesystemtestorproductionenvironmentissupposedtobedone.Especiallyforbeingabletorecognizethesequestionsearlyon,Irecommendtodealwiththedeploymentpipelineasearlyaspossibleinthereorganizationproject.Thedeploymentpipelineshouldalreadybeinplacebeforethefirstbusinessfunctionalityisimplementedbytheteams.Asimple“HelloWorld”willoftenbesufficientwhichthenisbroughttowardsproductionbythecombinedforcesoftheentireteam.Whiledoingso,theteamwillalmostalwaysencounteropenquestionswhichintheworstcasewillhaveeffectsonthedesignofthesystems.However,asnotmuchisimplementedatthisstage,earlyonduringtheprojectsuchchangesarestillcomparablycost-efficienttoimplement.

Conclusion

Theorganizationalchanges(resp.“Conway’sLaw”),whichaccompanytheintroductionofMicroservices,areuptonowoftenunderestimated.Oldhabits,prejudicesandmaybeeventrenchwarsareoftendeep-rooted.Especiallyifthenewteammateswerepreviouslyassignedtodifferentdepartments.However,“oneteam”hastobemorethanjustabuzzword.Iftheteammanagestoburytheirprejudicesandtoputtheirdifferentexperiencestogooduse,itcanadvancetogether.Everyonehastounderstandthatallofthemnowsharethetaskandresponsibilitytobringastablesoftwareintoproductionforthecustomer.Everybodycanprofitfromtheexperiencesoftheotherswheneverybodyactsonthepremise:“Everybodyvoicestheirconcerns,andwewillsolveitjointly”.

13.6InterfacetotheCustomer

ToensurethatthedevelopmentcanreallybescaledtomultipleteamsandMicroservices,eachteamneedstohaveitsownProductOwner.InlinewithScrumapproacheshe/sheisresponsibleforthefurtherdevelopmentoftheMicroservice.Forthispurposehe/shedefinesstorieswhichareimplementedintheMicroservice.TheProductOwneristhesourceofallrequirementsandprioritizesthem.ThisisespeciallyeasywhenaMicroserviceonlycomprisesfeatureswhicharewithintheresponsibilityofasingledepartmentatthebusinesslevel(Fig.68).UsuallythisobjectiveisachievedbyadjustingMicroservicesandteamstotheorganizationofdepartments.Eachdepartmentgets“its”ProductOwnerandtherefore“its”teamand“its”Microservices.

WhentheMicroserviceshaveagooddomainarchitecture,theycanbeindependentlydeveloped.Ultimately,eachdomainshouldbeimplementedinoneormanyMicroservices,andthedomainshouldonlybeofinteresttoonedepartment.ThearchitecturehastotaketheorganizationofthedepartmentsintoconsiderationwhendistributingthedomainsintoMicroservices.ThisensuresthateachdepartmenthasitsownMicroservicesthatarenotsharedwithotherdomainsordepartments.

Fig.68:Department,productownerandMicroservices

Unfortunately,thearchitectureoftenisnotperfect.Besides,Microserviceshaveinterfaces–anindicationthatfunctionalitiesmightspanmultipleMicroservices.WhenmultiplefunctionalitiesconcernoneMicroserviceandthereforemultipledepartmentswanttoinfluencethedevelopmentofaMicroservice,theProductOwnerhastoensureaprioritizationwhichiscoordinatedwiththedifferentdepartments.Thiscanbeachallengebecausedepartmentscanhavedifferentpriorities.InthatcasetheProductOwnerhastocoordinatebetweentheconcerneddepartments.

LetusassumethatthereisadepartmentwhichtakescareofsalescampaignsinanE-commerceshop.Itstartsacampaignwhereorderscontainingacertainitemgetarebateonthedeliverycost.Therequiredmodificationconcernstheorderteam:Ithastofindoutwhetheranordercontainssuchanitem.ThisinformationhastobetransmittedtothedeliveryMicroservicewhichhastocalculatethecostsfor

thedelivery.Accordingly,theProductOwnersofthesetwoteamshavetoprioritizethesechangesinregardstothechangesdesiredbythedepartmentsinchargeofdeliveryandorders.Unfortunately,manyofthesesalescampaignscombinedifferentfunctionalitiessothatsuchaprioritizationisoftenrequired.ThedepartmentsforordersanddeliverieshavetheirownMicroservices,whilethedepartmentinchargeofsalescampaignsdoesnothaveitsownMicroservices.InsteadithastointroduceitsfeaturesintotheotherMicroservices.

ArchitectureLeadstoDepartments

TheMicroservicearchitecturecanthusbeadirectresultofthedepartmentalorganizationofthecompany.However,therearealsocaseswhereanewdepartmentiscreatedaroundanITsystem,whichthentakescareofthissystemfromthebusinessside.InsuchacaseonecanarguethattheMicroservicesarchitecturedirectlyinfluencestheorganization.ForinstancetheremightbeanewInternetmarketplacewhichisimplementedbyanITsystem.Ifitissuccessful,adepartmentcanbecreatedwhichtakesoverthefurtherdevelopmentofthismarketplace.ThisdepartmentwillcontinuetodeveloptheITsystemfromadomainandfromabusinessperspective.Inthiscasethemarketplacewasdevelopedfirstandsubsequentlythedepartmenthasbeencreated.Thereforethesystemarchitecturehasdefinedthedepartmentalstructureoftheorganization.

13.7ReusableCodeAtfirstsightthereuseofcodeisatechnicalproblem.[Section8.3]{#section8-3}alreadydescribedthechallengeswhicharisewhentwoMicroservicesusethesamelibrary:WhentheMicroservicesusethelibraryinsuchawaythatanewreleaseofthelibrarynecessitatesanewdeploymentoftheMicroservices,theresultisadeploymentdependency.ThishastobeavoidedtoallowforanindependentdeploymentoftheMicroservices.ThereisadditionalexpenditurebecausetheteamsresponsiblefortheMicroserviceshavetocoordinatetheirchangestothelibrary.NewfeaturesforthedifferentMicroserviceshavetobeprioritizedanddeveloped.Theserepresentalsodependenciesbetweentheteamswhichshouldratherbeavoided.

ClientLibraries

ClientlibrarieswhichencapsulatecallsfromaMicroservicecanbeacceptable.WhentheinterfacesoftheMicroservicesaredownwardscompatible,theclientlibrarydoesnothavetobereplacedincaseofanewversionoftheMicroservice.Insuchascenarioclientlibrariesdonotcauseproblemsbecauseanew

deploymentofthecalledMicroservicesdoesnotleadtoanupdateoftheclientlibraryoranewdeploymentofthecallingMicroservice.

However,whentheclientlibraryalsocontainsdomainobjects,problemscanoccur.WhenaMicroservicewantstochangethedomainmodel,theteamhastocoordinatethischangewiththeotherusersoftheclientlibraryandthereforecannotdevelopindependentlyanymore.Theboundariesbetweenasimplifieduseoftheinterfacewhichcanbesensibleandasharedimplementationoflogicorotherdeploymentdependencieswhichcanbeproblematicisnotclearcut.Oneoptionistoentirelyforbidsharedcode.

ReuseAnyhow?

However,obviously,projectscanreusecode.Hardlyanyprojectnowadaysmanageswithoutsomeopensourcelibrary.Usingthiscodeisobviouslyeasyandthusfacilitateswork.ProblemsliketheonesarisinguponreusingcodebetweenMicroservicesareunlikelyforanumberofreasons:

Opensourceprojectsingeneralareofhighquality.Developersworkingindifferentcompaniesusethecodeandtherebyspoterrors.Oftentheyevenremovetheerrorssothatthequalitypermanentlyincreases.Topublishsourcecodeandtherebyprovideinsightintointernalsisoftenalreadymotivationenoughtoincreasethequality.Thedocumentationallowstoimmediatelystarttousethecodewithoutaneedtodirectlycommunicatewiththedevelopers.Withoutagooddocumentationopensourceprojectshardlyfindenoughusersoradditionaldeveloperssincegettingstartedwouldbetoohard.Thereisacoordinateddevelopmentwithabugtrackerandaprocessforacceptingcodechangesintroducedbyexternaldevelopers.Thereforeerrorsandtheirfixescanbetracked.Inaddition,itisclearhowchangesfromtheoutsidecanbeincorporatedintothecodebasis.Moreover,incaseofanewversionoftheopensourcelibraryitisnotnecessaryforalluserstousethenewversion.Thedependenciesinregardstothelibraryarenotsopronouncedthatadeploymentdependencyensues.Finally,thereareclearruleshowone’sownsupplementscanbeincorporatedintotheopensourcelibrary.

Intheendthedifferencebetweenasharedlibraryandanopensourceprojectismainlyahigherqualityinregardstodifferentaspects.Besidesthereisalsoanorganizationalaspect:Thereisateamwhichtakescareoftheopensource

project.Itdirectstheprojectandkeepsdevelopingit.Thisteamdoesnotnecessarilymakeallchanges,butitcoordinatesthem.Ideally,theteamhasmembersfromdifferentorganizationsandprojectssothattheopensourceprojectisdevelopedunderdifferentviewpointsandinthecontextofdifferentusecases.

ReuseasOpenSource

WithopensourceprojectsasrolemodelsinmindtherearedifferentoptionsforreusablecodeinaMicroservicesproject:

Theorganizationaroundreusablelibrariesisstructuredlikeinanopensourceproject.Thereareemployeesresponsibleforthecontinuedcodedevelopment,theconsolidationofrequirementsandforincorporatingthechangesofotheremployees.TheteammembersideallycomefromdifferentMicroserviceteams.Thereusablecodeturnsintoarealopensourceproject.Developersoutsideoftheorganizationcanuseandextendtheproject.

Bothdecisionscanresultintoasignificantinvestmentsincemarkedlymoreefforthastogointoqualityanddocumentationetc.Besides,theemployeesworkingontheprojecthavetogetenoughfreedomtodosointheirteams.Theteamscancontroltheprioritizationintheopensourceprojectbyonlymakingtheirmembersavailableforcertaintasks.Duetothelargeinvestmentandpotentialproblemswithprioritizationthedecisiontoestablishanopensourceprojectshouldbewellconsidered.Theideaitselfisnotnew–experiencesinthisareahavealreadybeencollectedforquitesometime.

Iftheinvestmentisveryhigh,itmeansthatthecodeishardlyreusableforthemomentandusingthecodeinitscurrentstatecausesquitesomeeffort.Probablythecodeisnotonlyhardtoreuse,buthardtouseatall.Thequestioniswhyteammemberswouldacceptsuchabadcodequality.Investingintocodequalityinordertomakethecodereusablecanpayoffalreadybyreusingitjustonce.

Atfirstglanceitdoesnotappearverysensibletomakecodeavailabletoexternaldevelopers.Thisrequiresthatcodequalityanddocumentationareofhighenoughqualityforexternaldeveloperstobeabletousethecodewithoutdirectcontacttothedevelopersoftheopensourceproject.Onlytheexternaldevelopersseemtoprofitfromthisapproachastheygetgoodcodeforfree.

However,arealopensourceprojecthasanumberofadvantages:

Externaldevelopersfindweakspotsbyusingthecode.Besides,theywillusethecodeindifferentprojectssothatitgetsmoregeneralized.Thiswillimprovequalityaswellasdocumentation.Maybeexternaldeveloperscontributetothefurtherdevelopmentofthecode.However,thisisrathertheexceptionthanthenorm.Buthavingexternalfeedbackviabugreportsandrequestsfornewfeaturescanalreadyrepresentasignificantadvantage.Runningopensourceprojectsisgreatmarketingfortechnicalcompetence.Thiscanbeusefulforattractingemployeesaswellascustomers.Importantistheextentoftheproject.Ifitisonlyasimplesupplementofanexistingopensourceproject,theinvestmentcanbemanageable.Anentirelynewopensourceframeworkisaverydifferenttopic.

Blueprints,i.e.documentationsforcertainapproaches,representelementswhicharefairlyeasytoreuse.Thiscanbeelementsofmacroarchitecturelikeforinstanceadocumentdetailingthecorrectapproachforlogging.LikewisetherecanbetemplateswhichcontainallnecessarycomponentsofaMicroserviceincludingacodeskeleton,abuildscriptandaContinuousDeliveryPipeline.Suchartifactscanrapidlybewrittenandareimmediatelyuseful.

TryandExperiment

Maybeyouhavealreadypreviouslyusedyourowntechnicallibrariesinprojectsorevendevelopedsomeyourself.Trytoestimatehowlargetheexpenditurewouldbetoturntheselibrariesintorealopensourcelibraries.Apartfromagoodcodequalitythisnecessitatesalsodocumentationabouttheuseandtheextensionofthecode.Besides,therehavetobeabugtrackerandforums.Howeasywoulditbetoreuseitintheprojectitself?Howhighwouldbethequalityofthelibrary?

13.8MicroservicesWithoutChangingtheOrganization?Microservicesaremorethanjustanapproachforsoftwarearchitecture.Theyhavepronouncedeffectsonorganization.Changestotheorganizationareoftenverydifficult.ThereforethequestionariseswhetherMicroservicescanbeimplementedwithoutchangingtheorganization.

MicroservicesWithoutChangingtheOrganization?

Microservicesallowforindependentteams.Thedomain-focusedteamsareresponsibleforoneormultipleMicroservices–thisincludesideallytheir

developmentaswellasoperations.TheoreticallyitispossibletoimplementMicroserviceswithoutdividingdevelopersintodomain-focusedteams.InthatcasethedeveloperscouldmodifyeachMicroservice–anextensionoftheideaspresentedinsection13.2.ItwouldevenbepossiblethattechnicallyfocusedteamsworkonMicroserviceswhicharesplitaccordingtodomain-basedcriteria.InthisscenariotherewouldbeaUI,amiddletierandadatabaseteamwhichworkondomainMicroservicessuchasorderprocessorregistration.However,anumberofadvantagesusuallyassociatedwithMicroservicescannotbeexploitedanymoreinthatcase.Firstly,itisnotpossibleanymoretoscaletheagileprocessesviaMicroservices.Secondly,itwillbenecessarytorestrictthetechnologyfreedomsincetheteamswillnotbeabletohandlethedifferentMicroservicesiftheyallemploydifferenttechnologies.Besides,eachteamcanmodifyeachMicroservice.ThisentailsthedangerthatthoughadistributedsystemiscreatedtherearedependencieswhichpreventtheindependentdevelopmentofindividualMicroservices.ThenecessityforindependentMicroservicesisobliteratedbecauseateamcanchangemultipleMicroservicestogetherandthereforecanhandlealsoMicroserviceshavingnumerousdependencies.However,evenundertheseconditionssustainabledevelopment,aneasierstartwithContinuousDelivery,independentscalingofindividualMicroservicesorasimplehandlingoflegacysystemscanstillbeimplementedbecausethedeploymentunitsaresmaller.

Evaluation

Toputitclearly:IntroducingMicroserviceswithoutcreatingdomain-focusedteamsdoesnotleadtothemainbenefitsmeanttobederivedfromMicroservices.Itisalwaysproblematictoimplementonlysomepartsofacertainapproachasonlythesynergiesbetweenthedifferentpartswillgeneratetheoverallvalue.AlthoughimplementingMicroserviceswithoutdomain-focusedteamsisapossibleoption–itisforsurenotrecommended.

Departments

Asalreadydiscussedinsection13.6,theMicroservicestructureshouldideallyextendtothedepartments.However,inrealitythisissometimeshardtoachievesincetheMicroservicearchitectureoftendeviatestoomuchfromtheorganizationalstructureofthedepartments.ItisunlikelythattheorganizationofthedepartmentswilladapttothedistributionintoMicroservices.WhenthedistributionoftheMicroservicecannotbeadjusted,therespectiveProductOwnershavetotakecareofprioritizationandcoordinatethewishesofthedepartments,whichconcernmultipleMicroservices,insuchawaythatall

requirementsareunambiguouslyprioritizedfortheteams.Ifthisisnotpossible,aCollectiveCodeOwnershipapproach(section13.2)canlimittheproblem.InthiscasetheProductOwnerandhis/herteamcanalsomodifyMicroserviceswhichdonotreallybelongtotheirsphereofinfluence.Thiscanbethebetteralternativeincontrasttoacoordinationacrossteams–howeverbothsolutionsarenotoptimal.

Operations

Inmanyorganizationsthereisaseparateteamforoperations.TheteamsresponsiblefortheMicroservicesshouldalsotakecareoftheoperationsoftheirMicroservicesfollowingtheprincipleofDevOps.However,asdiscussedinsection13.5,itisnotastrictrequirementforMicroservicestointroduceDevOps.Iftheseparationbetweenoperationsanddevelopmentissupposedtobemaintained,operationshastodefinethenecessarystandardsfortheMicroservicesinthemacroarchitecturetoensureasmoothoperationsofthesystem.

Architecture

Oftenarchitectureanddevelopmentarelikewisekeptseparated.InaMicroservicesenvironmentthereistheareaofmacroarchitecturewherearchitectsmakeglobaldecisionsforallteams.Alternatively,thearchitectscanbedistributedtothedifferentteamsandworktogetherwiththeteams.Inaddition,theycanfoundanoverarchingcommitteewhichdefinestopicsformacroarchitecture.Inthatcaseithastobeensuredthatthearchitectsreallyhavetimeforthistaskandarenotcompletelybusywithworkintheirteam.

TryandExperiment

Whatdoestheorganizationofaprojectyouknowlooklike?

Isthereaspecialorganizationalunitwhichtakescareofarchitecture?HowwouldtheyfitintoaMicroservices-basedarchitecture?Howisoperationsorganized?HowcantheorganizationofoperationsbestsupportMicroservices?Howwelldoesthedomain-baseddivisionfittothedepartments?Howcoulditbeoptimized?CanaProductOwnerwithfittingtaskareabeassignedtoeachteam?

13.9ConclusionMicroservicesenabletheindependenceofteamsinregardstotechnicaldecisionsanddeployments(section13.1).Thisallowstheteamstoindependently

implementrequirements.Intheendthismakesitpossiblefornumeroussmallteamstoworktogetheronalargeproject.Thisreducesthecommunicationoverheadbetweentheteams.Sincetheteamscandeployindependently,theoverallriskoftheprojectisreduced.

Ideallytheteamsshouldbeputtogetherinawaythatallowsthemtoworkseparatelyondifferentdomainaspects.Ifthisisnotpossibleorrequirestoomuchcoordinationbetweentheteams,CollectiveCodeOwnershipcanbeanalternative(section13.2).Inthatcaseeachdevelopercanchangeallofthecode.StilloneteamhastheresponsibilityforeachMicroservice.ChangestothisMicroservicehavetobecoordinatedwiththeresponsibleteam.

Section13.3describedthatMicroserviceshaveamacroarchitecturewhichcomprisesdecisionswhichconcernallMicroservices.Inaddition,thereisthemicroarchitecturewhichcanbedifferentforeachMicroservice.Intheareasoftechnology,operations,domainarchitectureandtestingtherearedecisionswhichcaneitherbeattributedtomicroormacroarchitecture.Eachprojecthasthechoicetodelegatethemtoteams(microarchitecture)ortocentrallydefinethem(macroarchitecture).Delegatingintoteamsisinlinewiththeobjectivetoachievealargedegreeofindependence–andisthereforeoftenthebetteroption.Aseparatearchitectureteamcandefinethemacroarchitecture–alternatively,theresponsibleteamisassembledfrommembersofthedifferentMicroserviceteams.

Responsibilityforthemacroarchitectureiscloselylinkedtoaconceptfortechnicalleadership(section13.4):LessmacroarchitecturemeansmoreresponsibilityfortheMicroserviceteamsandlessresponsibilityforthecentralarchitectureteam.

ThoughMicroservicesprofitfrommergingoperationsanddevelopmenttoDevOps(section13.5),itisnotstrictlyrequiredtointroduceDevOpstodoMicroservices.IfDevOpsisnotpossibleordesired,operationscandefineguidelinesinthecontextofmacroarchitecturetounifycertainaspectsinordertoensureasmoothoperationsoftheMicroservice-basedsystem.

Microservicesshouldalwaysimplementtheirownseparaterequirements.ThereforeitisbestwheneachMicroservicecanbeassignedtoacertaindepartmentonthebusinessside(section13.6).Ifthisisnotpossible,theProductOwnershavetocoordinatetherequirementscomingfromdifferentdepartmentsinsuchawaythateachMicroservicehasclearlyprioritizedrequirements.When

CollectiveCodeOwnershipisused,aProductOwnerandhis/herteamcanalsochangeMicroservicesofotherteams–whichcanlimitthecommunicationoverhead.Insteadofcoordinatingpriorities,ateamwillintroducethechangeswhicharenecessaryforanewfeaturebyitself–eveniftheyconcerndifferentMicroservices.TheteamresponsibleforthemodifiedMicroservicecanreviewtheintroducedchangesandadjustthemifnecessary.

CodecanbereusedinaMicroservicesprojectifthecodeistreatedlikeanopensourceproject(section13.7).Aninternalprojectcanbehandledlikeaninternalopensourceproject–orcaninfactbeturnedintoapublicopensourceproject.Ithastobeconsideredthattheeffortforarealopensourceprojectishigh.Therefore,itcanbemoreefficientnottoreusecode.Besides,thedevelopersoftheopensourceprojecthavetoprioritizedomainrequirementsversuschangestotheopensourceprojectwhichcanbeadifficultdecisionattimes.

Section13.8discussedthatanintroductionofMicroserviceswithoutchangestotheorganizationalstructureatthedevelopmentleveldoesnotworkinreallife.Whentherearenodomain-focusedteamswhichcandevelopcertaindomainaspectsindependentlyofotherteams,itispracticallyimpossibletodevelopmultiplefeaturesinparallelandthustobringmorefeaturestothemarketwithinthesametime.However,thisisjustwhatMicroservicesweremeanttoachieve.Sustainabledevelopment,aneasyintroductionofContinuousDelivery,independentscalingofindividualMicroservicesorasimplehandlingoflegacysystemsarestillpossible.Operationsandanarchitectureteamcandefinethemacroarchitecturesothatinthisareachangestotheorganizationalstructurearenotstrictlyrequired.Ideally,therequirementsofthedepartmentsarealwaysreflectedbyoneMicroservice.Ifthatisnotpossible,theProductOwnershavetocoordinateandprioritizetherequiredchanges.

EssentialPoints

Microserviceshavesignificanteffectsontheorganization.IndependentsmallteamswhichtogetherworkonalargeprojectareanimportantadvantageofMicroservices.ViewingtheorganizationaspartofthearchitectureisanessentialinnovationofMicroservices.AcombinationofDevOpsandMicroservicesisadvantageous,butnotobligatory.

PartIV:Technologies

ThispartofthebookshowshowMicroservicescanbeimplementedwithconcretetechnologies.Chapter14containsacompleteexampleforaMicroservices-architecturebasedonJava,Spring,SpringBoot,SpringCloud,theNetflixstackandDocker.Theexampleisagoodstartingpointforyourownimplementationorexperiments.ManyofthetechnologicalchallengesdiscussedinPart3aresolvedinthispartwiththeaidofconcretetechnologies–forinstancebuild,deployment,servicesdiscovery,communication,loadbalancingandtests.

EvensmallerthanMicroservicesaretheNanoservicesfromchapter15.Theyrequirespecialtechnologiesandanumberofcompromises.Thereforethechapterintroducestechnologieswhichcanimplementverysmallservicesi.e.AmazonLambdaforJavaScriptandJava,OSGiforJava,JavaEE,Vert.xontheJVM(JavaVirtualMachine)withsupportforlanguageslikeJava,Scala,Clojure,Groovy,Ceylon,JavaScript,RubyorPython.TheprogramminglanguageErlanglikewiseenablesverysmallservices,butisalsoabletointegrateothersystems.SenecaisaJavaScriptframeworkspecializedintheimplementationofNanoservices.

Atthecloseofthebookchapter16showswhatcanbeachievedwithMicroservices.

14ExampleforaMicroservices-basedArchitecture

ThischapterprovidesanexampleforanimplementationofaMicroservices-basedarchitecture.Itaimsatdemonstratingconcretetechnologiesinordertolaythefoundationforexperiments.Theexampleapplicationhasaverysimpledomainarchitecturecontainingafewcompromises.Section14.1dealswiththistopicindetail.

ForarealsystemwithacomparablelowcomplexityasthepresentedexampleapplicationanapproachwithoutMicroserviceswouldbebettersuited.However,thelowcomplexitymakestheexampleapplicationeasytounderstandandsimpletoextend.SomeaspectsofaMicroserviceenvironment,suchassecurity,documentation,monitoringorlogging,arenotillustratedintheexampleapplication–buttheseaspectscanberelativelyeasilyaddressedwithsomeexperiments.

Section14.2explainsthetechnologystackoftheexampleapplication.Thebuildtoolsaredescribedinsection14.3.Section14.4dealswithDockerastechnologyforthedeployment.DockerneedstoruninaLinuxenvironment.Section14.5describesVagrantasatoolforgeneratingsuchenvironments.Section14.6introducesDockerMachineasalternativetoolforthegenerationofaDockerenvironment,whichcanbecombinedwithDockerComposeforthecoordinationofseveralDockerContainers(section14.7).TheimplementationofServiceDiscoveryisdiscussedinsection14.8.ThecommunicationbetweentheMicroservicesandtheuserinterfaceisthemaintopicofsection14.9.ThankstoResilienceotherMicroservicesarenotaffectedifasingleMicroservicefails.IntheexampleapplicationresilienceisimplementedwithHystrix(section14.10).LoadBalancing(section14.11),whichcandistributetheloadontoseveralinstancesofaMicroservice,iscloselyrelatedtothat.PossibilitiesfortheintegrationofNon-Java-technologiesaredetailedinsection14.12,andtestingisdiscussedinsection14.13.

Thecodeoftheexampleapplicationcanbefoundathttps://github.com/ewolff/microservice.ItisApache-licensed,andcan,

accordingly,beusedandextendedfreelyforanypurpose.

14.1DomainArchitectureTheexampleapplicationhasasimplewebinterface,withwhichuserscansubmitorders.TherearethreeMicroservices(Fig.69):

Catalogkeepstrackofproducts.Itemscanbeaddedordeleted.Customerperformsthesametaskinregardstocustomers:Itcanregisternewcustomersordeleteexistingones.Ordercannotonlyshoworders,butalsocreateneworders.

Fig.69:Architectureoftheexampleapplication

FortheorderstheMicroservice“Order”needsaccesstothetwootherMicroservices,“Customer”and“Catalog”.ThecommunicationisachievedviaREST.However,thisinterfaceisonlymeantfortheinternalcommunicationbetweentheMicroservices.TheusercaninteractwithallthreeMicroservicesviatheHTML-/HTTP-interface.

SeparateDataStorages

ThedatastoragesofthethreeMicroservicesarecompletelyseparate.OnlytherespectiveMicroserviceknowstheinformationaboutthebusinessobjects.TheMicroservice“Order”savesonlytheprimarykeysoftheitemsandcustomers,whicharenecessaryfortheaccessviatheRESTinterface.Arealsystemshouldratheruseartificialkeysastheinternalprimarykeysotherwisegetvisibletotheoutside.Theseareinternaldetailsofthedatastoragethatshouldbehidden.Toexposetheprimarykeys,theclassSpringRestDataConfigwithintheMicroservicesconfiguresSpringDataRestaccordingly.

LotsofCommunication

Wheneveranorderneedstobeshown,theMicroservice“Customer”iscalledforthecustomerdataandtheMicroservice“Catalog”foreachlineoftheorderinordertodeterminethepriceoftheitem.ThiscanhaveanegativeinfluenceontheresponsetimesoftheapplicationasthedisplayoftheordercannottakeplacebeforeallrequestshavebeenansweredbytheotherMicroservices.Astherequeststotheotherservicestakeplacesynchronouslyandsequentially,latencieswilladdup.Thisproblemcanbesolvedbyusingasynchronousparallelrequests.

Inadditionalotofcomputingpowerisneededtomarshalthedataforsendingandreceiving.Thisisacceptableincaseofsuchasmallexampleapplication.Whensuchanapplicationissupposedtoruninproduction,alternativeshavetobeconsidered.

Thisproblemcanforinstancebesolvedbycaching.Thisisrelativelyeasyascustomerdatawillnotchangefrequently.Itemscanchangemoreoften–still,byfarnotsofastthatcachingwouldposeaproblem.Onlytheamountofdatacaninterferewiththisapproach.TheuseofMicroserviceshastheadvantagethatsuchacachecanbeimplementedrelativelysimplyattheinterfaceoftheMicroservices,orevenatthelevelofHTTP,ifthisprotocolisused.AnHTTPCache,liketheoneusedforwebsites,canbeaddedtoRESTServicesinatransparentmannerandwithoutmuchprogrammingeffort.

BoundedContext

Cachingwillsolvetheproblemoftoolongresponsetimestechnically.However,verylongresponsetimescanalsobeasignforafundamentalproblem.Section4.3arguedthataMicroserviceshouldcontainaBoundedContext.AspecificdomainmodelisonlyvalidinaBoundedContext.ThemodularizationintoMicroservicesinthisexamplecontradictsthisidea:ThedomainmodelisusedtomodularizethesystemintotheMicroservices“Order”fororders,“Catalog”for

itemsand“Customer”forcustomers.InprinciplethedataoftheseentitiesshouldbemodularizedindifferentBoundedContexts.

ThedescribedmodularizationimplementsinspiteoflowdomaincomplexityasystemconsistingofthreeMicroservices.InthismannertheexampleapplicationiseasytounderstandwhilestillhavingseveralMicroservicesanddemonstratingthecommunicationbetweenMicroservices.InarealsystemtheMicroservice“Order”canalsohandleinformationabouttheitemsthatisrelevantfortheorderprocesssuchastheprice.Ifnecessary,theservicecanreplicatethedatafromanotherMicroserviceintoitsowndatabaseinordertoaccessitefficiently.Thisisanalternativetotheaforementionedcaching.TherearedifferentpossibilitieshowthedomainmodelscanbemodularizedintothedifferentBoundedContexts“Order”and“Customer”resp.“Catalog”.

Thisdesigncancauseerrors:Whenanorderhasbeenputintothesystemandafterwardsthepriceoftheitemischanged,thepriceoftheorderchangesaswell–thatshouldnothappen.Incasetheitemisdeleted,thereisevenanerrorwhendisplayingtheorder.Inprincipletheinformationconcerningtheitemandthecustomershouldbecomepartoftheorder.Inthatcasethehistoricaldataoftheordersincludingcustomeranditemdatawouldbetransferredintotheservice“Order”.

Don’tModularizeMicroservicesbyData!

ItisimportanttounderstandtheprobleminherentinarchitectingaMicroservicessystembydomainmodel.Oftenthetaskofaglobalarchitectureismisunderstood:Theteamdesignsadomainmodel,whichcomprisesforinstanceobjectssuchascustomers,orderanditems.BasedonthismodelMicroservicesaredefined.ThatishowthemodularizationintoMicroservicescouldhavecomeaboutintheexampleapplication,resultinginahugeamountofcommunication.Amodularizationbasedonprocessessuchasordering,customerregistrationandproductsearchmightbemoreadvantageous.EachprocesscouldbeaBoundedContextthathasitsowndomainmodelforthemostimportantdomainobjects.Forproductsearchthecategoriesofitemsmightbethemostrelevantwhilefortheorderingprocessdatalikeweightandsizemightmattermore.

Themodularizationbydatacanalsobeadvantageousinarealsystem.WhentheMicroservice“Order”getstoobigincombinationwiththehandlingofcustomerandproductdata,itissensibletomodularizedatahandling.InadditionthedatacanbeusedbyotherMicroservices.Whendevisingthearchitectureforasystem,

thereisrarelyasinglerightwayofdoingthings.Thebestapproachdependsonthesystemandthepropertiesthesystemshouldhave.

14.2BasicTechnologiesMicroservicesintheexampleapplicationareimplementedwithJava.BasicfunctionalitiesfortheexampleapplicationareprovidedbytheSpringFramework.ThisframeworkoffersnotonlyDependencyInjection,butalsoaWeb-Framework,whichallowsfortheimplementationofREST-basedservices.

HSQLDatabase

ThedatabaseHSQLDBhandlesandstoresdata.ItisanIn-Memorydatabase,whichiswritteninJava.ThedatabasestoresthedataonlyinRAMsothatalldataarelostuponrestartingtheapplication.Inlinewiththis,thisdatabaseisnotreallysuitedforproductionuse,evenifitcanwritedatatoaharddisk.Ontheotherhanditisnotnecessarytoinstallanadditionaldatabaseserver,whichkeepstheexampleapplicationeasy.ThedatabaserunsintherespectiveJavaapplication.

SpringDataREST

TheMicroservicesuseSpringDataRESTinordertoprovidethedomainobjectswithlittleeffortviaRESTandtowritethemintothedatabase.Handingobjectsoutdirectlymeansthattheinternaldatarepresentationleaksintotheinterfacebetweentheservices.Changingthedatastructuresisverydifficultastheclientsneedtobeadjustedaswell.However,SpringDataRESTcanhidecertaindataelementsandcanbeconfiguredflexiblysothatthetightcouplingbetweentheinternalmodelandtheinterfacecanbedecoupledifnecessary.

SpringBoot

SpringBootfacilitatesSpringfurther.SpringBootrendersthegenerationofaSpringsystemveryeasy:WithSpringBootStarterspredefinedpackagesareavailable,whichcontaineverythingthatisnecessaryforacertaintypeofapplication.SpringBootcangenerateWARfiles,whichcanbeinstalledonaJavaapplicationorwebserver.Inadditionitispossibletoruntheapplicationwithoutanapplicationorwebserver.TheresultofthebuildisaJARfileinthatcase,whichcanberunwithaJavaRuntimeEnvironment(JRE).TheJARfilecontainseverythingforrunningtheapplicationandalsothenecessarycodetodealwithHTTPrequests.Thisapproachisbyfarlessdemandingandsimplerthantheuseofanapplicationserverhttps://jaxenter.com/java-application-servers-dead-112186.html.

AsimpleexampleforaSpringBootapplicationisshowninListing1.ThemainprogrammainhandsthecontrolovertoSpringBoot.Theclassispassedinasaparametersothattheapplicationcanbecalled.Theannotation@SpringBootApplicationmakessurethatSpringBootgeneratesasuitableenvironment.Forexampleawebserverisstarted,andanenvironmentforaSpringwebapplicationisgeneratedastheapplicationisawebapplication.Becauseof@RestControllertheSpringFrameworkinstantiatestheclassandcallsmethodsfortheprocessingofRESTrequests.@RequestMappingshowswhichmethodissupposedtohandlewhichrequest.UponrequestsoftheURL“/”themethodhello()iscalled,whichreturnsasresultthesignchain“hello”intheHTTPbody.Ina@RequestMappingannotationURLtemplatessuchas“/customer/{id}”canbeused.ThenaURLlike“/customer/42”canbecutintoseparatepartsandthe42boundtoaparameterannotatedwith@PathVariable.Asdependencytheapplicationusesonlyspring-boot-starter-webpullingallnecessarylibrariesfortheapplicationalong,forinstancethewebserver,theSpringFrameworkandadditionaldependentclasses.Section14.3willdiscussthistopicinmoredetail.Listing1:AsimpleSpringBootRESTservice

1@RestController

2@SpringBootApplication

3publicclassControllerAndMain{

4

5@RequestMapping("/")

6publicStringhello(){

7return"hello";

8}

9

10publicstaticvoidmain(String[]args){

11SpringApplication.run(ControllerAndMain.class,

12args);

13}

14

15}

SpringCloud

FinallytheexampleapplicationusesSpringCloudtogaineasyaccesstotheNetflixStack.Fig70showsanoverview.

Fig.70:OverviewofSpringCloud

SpringCloudoffersviatheSpringCloudConnectorsaccesstothePaaS(PlatformasaService)HerokuandCloudFoundry.SpringCloudforAmazonWebServicesoffersaninterfaceforservicesfromtheAmazonCloud.ThispartofSpringCloudisresponsibleforthenameoftheproject,butnothelpfulfortheimplementationofMicroservices.

However,theothersubprojectsofSpringCloudprovideaverygoodbasisfortheimplementationofMicroservices:

SpringCloudSecuritysupportstheimplementationofsecuritymechanismsastypicallyrequiredforMicroservices,amongthoseSingleSignOnintoaMicroservicesenvironment.ThatwayausercanuseeachoftheMicroserviceswithouthavingtologinaneweverytime.InadditiontheusertokenistransferredautomaticallyforallcallstootherRESTservicestoensurethatthosecallscanalsoworkwiththecorrectuserrights.SpringCloudConfigcanbeusedtocentralizeanddynamicallyadjusttheconfigurationofMicroservices.Section12.4alreadypresentedtechnologies,whichconfigureMicroservicesduringdeployment.Tobeabletoreproducethestateofaserveratanytime,anewservershouldbestartedwithanewMicroserviceinstanceincaseofaconfigurationchangeinsteadofdynamicallyadjustinganexistingserver.Ifaserverisdynamicallyadjusted,thereisnoguaranteethatnewserversaregeneratedwiththerightconfigurationastheyareconfiguredviaadifferentway.Becauseofthesedisadvantagestheexampleapplicationrefrainsfromusingthistechnology.SpringCloudBuscansenddynamicconfigurationchangesforSpringCloudConfig.Moreover,theMicroservicescancommunicateviaSpringCloudBus.However,theexampleapplicationdoesnotusethistechnologybecauseSpringCloudConfigisnotusedandtheMicroservicescommunicateviaREST.SpringCloudSleuthenablesdistributedtracingwithtoolslikeZipkinorHtrace.ItcanalsouseacentrallogstoragewithELK(seesection12.2).SpringCloudZookeepersupportApacheZookeeper(seesection8.8).Thistechnologycanbeusedtocoordinateandconfiguredistributedservices.SpringCloudConsultfacilitatesServicesDiscoveryusingConsul(seesection8.9).SpringCloudClusterimplementsleaderelectionandstatefulpatternsusingtechnologieslikeZookeeperorConsul.ItcanalsousedtheNoSQLdatastoreRedisortheHazelcastcache.FinallySpringCloudStreamsupportsmessagingusingRedis,RabbitorKafka.

SpringCloudNetflix

SpringCloudNetflixofferssimpleaccesstoNetflixStack,whichhasbeenespeciallydesignedfortheimplementationofMicroservices.Thefollowingtechnologiesarepartofthisstack:

Zuulcanimplementroutingofrequeststodifferentservices.RibbonservesasLoadBalancer.

HystrixassistswithimplementingresilienceinMicroservices.TurbinecanconsolidatemonitoringdatafromdifferentHystrixservers.FeignisanoptionforaneasierimplementationofRESTclients.ItisnotlimitedtoMicroservices.Itisnotusedintheexampleapplication.EurekacanbeusedforServiceDiscovery.

Thesetechnologiesaretheonesthatinfluencetheimplementationoftheexampleapplicationmost.

TryandExperimentForanintroductionintoSpringitisworthwhiletocheckouttheSpringGuidesathttps://spring.io/guides/.TheyshowindetailhowSpringcanbeusedtoimplementRESTservicesortorealizemessagingsolutionsviaJMS.AnintroductionintoSpringBootcanbefoundathttps://spring.io/guides/gs/spring-boot/.Workingyourwaythroughtheseguidesprovidesyouwiththenecessaryknow-howforunderstandingtheadditionalexamplesinthischapter.

14.3BuildTheexampleprojectisbuiltwiththetoolMaven.Theinstallationofthetoolisdescribedathttps://maven.apache.org/download.cgi.Thecommandmvnpackageinthedirectorymicroservice/microservice-democanbeusedtodownloadalldependentlibrariesfromtheInternetandtocompiletheapplication.

TheconfigurationoftheprojectsforMavenissavedinfilesnamedpom.xml.TheexampleprojecthasaParent-POMinthedirectorymicroservice-demo.Itcontainstheuniversalsettingsforallmodulesandinadditionalistoftheexampleprojectmodules.EachMicroserviceissuchamodule,andsomeinfrastructureserversaremodulesaswell.Theindividualmoduleshavetheirownpom.xml,whichcontainsthemodulenameamongotherinformation.Inadditiontheycontainthedependencies,i.e.theJavalibrariestheyuse.Listing2:Partofpom.xmlincludingdependencies1...

2<dependencies>

3

4<dependency>

5<groupId>org.springframework.cloud</groupId>

6<artifactId>spring-cloud-starter-eureka</artifactId>

7</dependency>

8

9<dependency>

10<groupId>org.springframework.boot</groupId>

11<artifactId>

12 spring-boot-starter-data-jpa

13 </artifactId>

14</dependency>

15...

16</dependencies>

17...

Listing2showsapartofapom.xml,whichliststhedependenciesofthemodule.DependingonthenatureoftheSpringCloudfeaturestheprojectisusing,additionalentrieshavetobeaddedinthispartofthepom.xmlusuallywiththegroupIdorg.springframework.cloud.

ThebuildprocessresultsinoneJARfileperMicroservice,whichcontainsthecompiledcode,theconfigurationandallnecessarylibraries.JavacandirectlystartsuchJARfiles.AlthoughtheMicroservicescanbeaccessedviaHTTP,theydonothavetobedeployedonanapplicationorwebserver.ThispartoftheinfrastructureisalsocontainedintheJARfile.

AstheprojectsarebuiltwithMaven,theycanbeimportedintoallusualJavaIDEs(IntegratedDevelopmentEnvironment)forfurtherdevelopment.IDEssimplifycodechangestremendously.

TryandExperiment

DownloadandCompiletheExampleDownloadtheexampleprovidedathttps://github.com/ewolff/microservice.InstallMaven,seehttps://maven.apache.org/download.cgi.Inthesubdirectorymicroservices-demoexecutethecommandmvnpackage .Thiswillbuildthecompleteproject.

CreateaContinuousIntegrationServerfortheProjecthttps://github.com/ewolff/user-registrationisanexampleprojectforaContinuousDeliveryproject.Thiscontainsinsubdirectoryci-setupasetupforaContinuousIntegrationServer(Jenkins)withstaticcodeanalysis(Sonarqube)andArtifactoryforthehandlingofbinaryartefacts.IntegratetheMicroservicesprojectintothisinfrastructuresothatanewbuiltistriggereduponeachchange.

Thenextsection(14.4)willdiscussVagrantinmoredetail.ThistoolisusedfortheContinuousIntegrationServers.Itsimplifiesthegenerationoftestenvironmentsgreatly.

14.4DeploymentUsingDockerDeployingMicroservicesisveryeasy:

Javahastobeinstalledontheserver.TheJARfile,whichresultedfromthebuild,hastobecopiedtotheserver.Aseparateconfigurationfileapplication.propertiescanbecreatedforfurtherconfigurations.ItisautomaticallyreadoutbySpringBootandcanbeusedforadditionalconfigurations.Anapplication.propertiescontainingdefaultvaluesiscomprisedintheJARfile.FinallyaJavaprocesshastostarttheapplicationoutoftheJARfile.

EachMicroservicestartswithinitsownDockerContainer.Asdiscussedinsection12.6,DockerusesLinuxContainers.InthismannertheMicroservicecannotinterferewithprocessesinotherDockerContainersandhasacompletelyindependentfilesystem.TheDockerImageisthebasisforthisfilesystem.However,allDockerContainerssharetheLinuxKernel.Thissavesresources.IncomparisontoanoperatingsystemprocessaDockerContainerhasvirtuallynoadditionaloverhead.Listing3:DockerfileforaMicroserviceusedintheexampleapplication

1FROMjava

2CMD/usr/bin/java-Xmx400m-Xms400m\

3-jar/microservice-demo/microservice-demo-catalog\

4/target/microservice-demo-catalog-0.0.1-SNAPSHOT.jar

5EXPOSE8080

AfilecalledDockerfiledefinesthecompositionofaDockerContainer.Listing3showsaDockerfileforaMicroserviceusedintheexampleapplication:

FROMdeterminesthebaseimageusedbytheDockerContainer.ADockerfilefortheimagejavaiscontainedintheexampleproject.ItgeneratesaminimalDockerimagewithonlyaJVMinstalled.CMDdefinesthecommandexecutedatthestartoftheDockerContainer.Inthecaseofthisexampleitisasimplecommandline.ThislinestartsaJavaapplicationoutoftheJARfilegeneratedbythebuild.DockerContainersareabletocommunicatewiththeoutsidevianetworkports.EXPOSEdetermineswhichportsareaccessiblefromoutside.IntheexampletheapplicationreceivesHTTPrequestsviaport8080.

14.5VagrantDockerrunsexclusivelyunderLinuxasitusesLinuxContainers.However,therearesolutionsforotheroperatingsystems,whichstartavirtualLinuxmachineandthusallowtheuseofDocker.ThisislargelytransparentsothattheuseispracticallyidenticaltotheuseunderLinux.ButinadditionallDockerContainersneedtobebuiltandstarted.

TomakeinstallingandhandlingDockeraseasyaspossible,theexampleapplicationusesVagrant.Fig.71showshowVagrantworks:

Fig.71:HowVagrantworks

ToconfigureVagrantasinglefileisnecessary,theVagrantfile.Listing4showstheVagrantfileoftheexampleapplication:Listing4:Vagrantfilefromtheexampleapplication

1Vagrant.configure("2")do|config|

2config.vm.box="ubuntu/trusty64"

3config.vm.synced_folder"../microservice-demo",

4"/microservice-demo",create:true

5config.vm.network"forwarded_port",

6guest:8080,host:18080

7config.vm.network"forwarded_port",

8guest:8761,host:18761

9config.vm.network"forwarded_port",

10 guest:8989,host:18989

11

12config.vm.provision"docker"do|d|

13d.build_image"--tag=java/vagrant/java"

14d.build_image"--tag=eureka/vagrant/eureka"

15d.build_image

16 "--tag=customer-app/vagrant/customer-app"

17d.build_image

18 "--tag=catalog-app/vagrant/catalog-app"

19d.build_image"--tag=order-app/vagrant/order-app"

20d.build_image"--tag=turbine/vagrant/turbine"

21d.build_image"--tag=zuul/vagrant/zuul"

22end

23config.vm.provision"docker",run:"always"do|d|

24d.run"eureka",

25args:"-p8761:8761"+

26 "-v/microservice-demo:/microservice-demo"

27d.run"customer-app",

28args:"-v/microservice-demo:/microservice-demo"+

29 "--linkeureka:eureka"

30d.run"catalog-app",

31args:"-v/microservice-demo:/microservice-demo"+

32 "--linkeureka:eureka"

33d.run"order-app",

34args:"-v/microservice-demo:/microservice-demo"+

35 "--linkeureka:eureka"

36d.run"zuul",

37args:"-v/microservice-demo:/microservice-demo"+

38 "-p8080:8080--linkeureka:eureka"

39d.run"turbine",

40args:"-v/microservice-demo:/microservice-demo"+

41 "--linkeureka:eureka"

42end

43

44end

config.vm.boxselectsabaseimage–inthiscaseaUbuntu-14.04Linuxinstallation(TrustyTahr).config.vm.synced_foldermountsthedirectorycontainingtheresultsoftheMavenbuildintothevirtualmachine.InthismannertheDockerContainerscandirectlymakeuseofthebuildresults.Theportsofthevirtualmachinecanbelinkedtotheportsofthecomputerrunningthevirtualmachine.Theconfig.vm.networksettingscanbeusedforthat.InthismannerapplicationsintheVagrantvirtualmachinebecomeaccessibleasifrunningdirectlyonthecomputer.config.vm.provisionstartsthepartoftheconfiguration,whichdealswiththesoftwareprovisioningwithinthevirtualmachine.Dockerservesasprovisioningtoolandisautomaticallyinstalledwithinthevirtualmachine.Finallyd.build_imagegeneratestheDockerimagesusingDockerfiles.Firstthebaseimagejavaiscreated.ImagesforthethreeMicroservicescustomer-app,catalog-appandorder-appfollow.TheimagesfortheNetflixtechnologiesserversbelongtotheinfrastructure:EurekaforServiceDiscovery,TurbineformonitoringandZuulforroutingofclientrequests.Vagrantstartstheindividualimagesusingd.run.Thisstepisnotonlyperformedwhenprovisioningthevirtualmachine,butalsowhenthesystemisstartedanew(run:“always”).Theoption–vmountsthedirectory/microservice-demointoeachDockerContainersothattheDockerContainercandirectlyexecutethecompiledcode.-plinksaportoftheDockerContainertoaportofvirtualmachine.ThislinkallowstoaccesstheDockerContainerEurekaunderthehostnameeurekafromwithintheotherDockerContainers.

IntheVagrantsetuptheJARfilescontainingtheapplicationcodearenotcontainedintheDockerimage.Thedirectory/microservice-demodoesnotbelongtotheDockerContainer.ItresidesonthehostrunningtheDockerContainersi.e.theVagrantVM.ItwouldalsobepossibletocopythesefilesintotheDockerimage.Afterwardstheresultingimagecouldbecopiedonarepositoryserveranddownloadedfromthere.ThentheDockerContainerwouldcontainallnecessaryfilestoruntheMicroservice.AdeploymentinproductionthenonlyneedstostarttheDockerimagesonaproductionserver.ThisapproachisusedintheDockerMachinesetup(seesection14.6).

NetworkingintheExampleApplication

Fig.72showshowtheindividualMicroservicesoftheexampleapplicationcommunicateviathenetwork.AllDockerContainersareaccessibleinthenetworkviaIPaddressesfromthe172.17.0.0/16range.DockergeneratessuchanetworkautomaticallyandconnectsallDockerContainerstothenetwork.WithinthenetworkallportsareaccessiblethataredefinedintheDockerfilesusingEXPOSE.TheVagrantvirtualmachineisalsoconnectedtothisnetwork.ViatheDockerlinks(compareListing4)allDockerContainersknowtheEurekacontainerandcanaccessitunderthehostnameeureka.TheotherMicroserviceshavetobelookedupviaEureka.AllfurthercommunicationtakesplaceviatheIPaddress.

Inadditionthe-p-Optioninthed.runentriesfortheDockerContainersinListing4hasconnectedtheportstotheVagrantvirtualmachine.TheseContainerscanbeaccessedviatheseportsoftheVagrantvirtualmachine.ToreachthemalsofromthecomputerrunningtheVagrantvirtualmachinethereisaportmapping,whichlinkstheportstothelocalcomputer.Thisisaccomplishedviatheconfig.vm.networkentriesinVagrantfile.Theport8080oftheDockerContainer“zuul”canforinstancebeaccessedviatheport8080intheVagrantvirtualmachine.Thisportcanbereachedfromthelocalcomputerviatheport18080.SotheURLhttp://localhost:18080/accessesthisDockerContainer.

Fig.72:Networkandportsoftheexampleapplication

TryandExperiment

RuntheExampleApplicationTheexampleapplicationdoesnotneedmuchefforttomakeitrun.Arunningexampleapplicationlaysthefoundationfortheexperimentsdescribedlaterinthischapter.

Oneremark:TheVagrantfile defineshowmuchRAMandhowmanyCPUsthevirtualmachinesgets.Thesettingsv.memoryandv.cpus ,whicharenotshownintheListing,dealwiththis.Dependingontheusedcomputer,thevaluesshouldbeincreasedifalotofRAMormanyCPUsarepresent.Wheneverthevaluescanbeincreased,theyshouldbeelevatedinordertospeedtheapplicationup.

TheinstallationofVagrantisdescribedinhttp://docs.vagrantup.com/v2/installation/index.html.VagrantneedsavirtualizationsolutionlikeVirtualBox.TheinstallationofVirtualBoxisexplainedathttps://www.virtualbox.org/wiki/Downloads.Bothtoolsarefree.

Theexamplecanonlybestartedoncethecodehasbeencompiled.Instructionshowtocompilethecodecanbefoundintheexperimentdescribedinsection14.3.Afterwardsyoucanchangeintothedirectorydocker-vagrantandstarttheexampledemousingthecommandvagrantup.

TointeractwiththedifferentDockerContainersyouhavetologintothevirtualmachineviathecommandvagrantssh.Thiscommandhastobeexecutedwithinthesubdirectorydocker-vagrant.Forthistobepossibleasshclienthastobeinstalledonthecomputer.OnLinuxandMacOSXsuchaclientisusuallyalreadypresent.InWindowsinstallinggitwillbringansshclientalongasdescribedathttp://git-scm.com/download/win.Afterwardsvagrantsshshouldwork.

InvestigateDockerContainersDockercontainsseveralusefulcommands:

dockerps providesanoverviewoftherunningDockerContainers.Thecommanddockerlog“nameofDockerContainer”showsthelogs.dockerlog-f“nameofDockerContainer”providesincessantlytheup-to-dateloginformationoftheContainer.dockerkill“nameoftheDockeContainer”terminatesaDockerContainer.dockerrm“nameoftheDockerContainer”deletesalldata.ForthatallContainersfirstneedstobestopped.

AfterstartingtheapplicationthelogfilesoftheindividualDockerContainerscanbelookedat.

UpdateDockerContainersADockerContainercanbeterminated(dockerkill)andthedataoftheContainerdeleted(dockerrm).ThecommandshavetobeexecutedinsidetheVagrantvirtualmachine.vagrantprovisionstartsthemissingDockerContainersagain.ThiscommandhastobeexecutedonthehostrunningVagrant.IfyouwanttochangetheDockerContainer,simplydeleteit,compilethecodeagainandgeneratethesystemanewusingvagrantprovision.

AdditionalVagrantcommands:

vagranthaltterminatesthevirtualmachine.vagrantupstartsitagain.vagrantdestroydestroysthevirtualmachineandallsaveddata.

StoreDataonDiskRightnowtheDockerContainerdoesnotsavethedatasothatitislostuponrestarting.TheusedHSQLDBdatabasecanalsosavethedataintoafile.ToachievethatasuitableHSQLDBURLhastobeused,seehttp://hsqldb.org/doc/guide/dbproperties-chapt.html#dpc_connection_url.SpringBootcanreadtheJDBCURLoutoftheapplication.properties file,seehttp://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-sql.html#boot-features-connect-to-production-database.NowtheContainercanberestartedwithoutdataloss.ButwhathappensiftheDockerContainerhastobegeneratedagain?DockercansavedataalsooutsideoftheContaineritself,comparehttps://docs.docker.com/userguide/dockervolumes/.Theseoptionsprovideagoodbasisforfurtherexperiments.AlsoanotherdatabasethanHSQLDBcanbeusedsuchasMySQL.ForthatpurposeanotherDockerContainerhastobeinstalled,whichcontainsthedatabase.InadditiontoadjustingtheJDBCURLaJDBCdriverhastobeaddedtotheproject.

HowistheJavaDockerImageBuilt?TheDockerfileismorecomplexthantheonesdiscussedhere.https://docs.docker.com/reference/builder/demonstrateswhichcommandsareavailableinDockerfiles.TrytounderstandthestructureoftheDockerfiles.

14.6DockerMachineVagrantservestoinstallenvironmentsonadeveloperlaptop.InadditiontoDockerVagrantcanusee.g.simpleshellscriptsfordeployment.However,forproductionenvironmentsthissolutionisunsuitable.DockerMachineis

specializedinDocker.ItsupportsmanymorevirtualizationsolutionsaswellassomeCloudproviders.

Fig.73demonstrateshowDockerMachinebuildsaDockerenvironment:First,usingavirtualizationsolutionlikeVirtualBoxavirtualmachineisinstalled.Thisvirtualmachineisbasedonboot2docker,averylightweightLinuxdesignedspecificallyasarunningenvironmentforDockerContainers.OnthatDockerMachineinstallsacurrentversionofDocker.Acommandlikedocker-machinecreate–drivervirtualboxdevgeneratesforinstanceanewenvironmentwiththenamedevrunningonaVirtualBoxcomputer.

Fig.73:DockerMachine

TheDockertoolnowcancommunicatewiththisenvironment.TheDockercommandlinetoolsuseaRESTinterfacetocommunicatewiththeDockerserver.Accordingly,thecommandlinetooljusthastobeconfiguredinawaythatallowsittocommunicatewiththeserverinasuitablemanner.InLinuxorMacOSXthecommandeval“$(docker-machineenvdev)”issufficienttoconfiguretheDockerappropriately.ForWindowsPowerShellthecommanddocker-machine.exeenv–shellpowershelldevmustbeusedandinWindowscmddocker-machine.exeenv–shellcmddev.

DockerMachinerendersitthusveryeasytoinstalloneorseveralDockerenvironments.AlltheenvironmentscanbehandledbyDockerMachineandaccessedbytheDockercommandlinetool.AsDockerMachinealsosupportstechnologieslikeAmazonCloudorVMwarevSphere,itcanbeusedtogenerateproductionenvironments.

TryandExperimentTheexampleapplicationcanalsoruninanenvironmentcreatedbyDockerMachine.

TheinstallationofDockerMachineisdescribedathttps://docs.docker.com/machine/#installation.DockerMachinerequiresavirtualizationsolutionlikeVirtualBox.HowtoinstallVirtualBoxcanbefoundathttps://www.virtualbox.org/wiki/Downloads.Usingdocker-machinecreate–virtualbox-memory“4096”–drivervirtualboxdevaDockerenvironmentcalleddevcannowbecreatedonaVirtualBox.Withoutanyfurtherconfigurationthestoragespaceissetto1GB,whichisnotsufficientforalargernumberofJavaVirtualMachines.

docker-machine withoutparametersdisplaysahelptext,anddocker-machinecreate showstheoptionsforthegenerationofanewenvironment.https://docs.docker.com/machine/get-started-cloud/demonstrateshowDockerMachinecanbeusedinaCloud.ThismeansthattheexampleapplicationcanalsoeasilybestartedinaCloudenvironment.

Attheendofyourexperimentsdocker-machinermdeletestheenvironment

14.7DockerComposeAMicroservice-basedsystemcomprisestypicallyseveralDockerContainers.Thesehavetobegeneratedtogetherandneedtobeputintoproductionsimultaneously.

ThiscanbeachievedwithDockerCompose.ItenablesthedefinitionofDockerContainers,whicheachhouseoneservice.YAMLservesasformat.Listing5:Dockercomposeconfigurationfortheexampleapplication1eureka:

2build:../microservice-demo/microservice-demo-eureka-server

3ports:

4-"8761:8761"

5customer:

6build:../microservice-demo/microservice-demo-customer

7links:

8-eureka

9catalog:

10build:../microservice-demo/microservice-demo-catalog

11links:

12-eureka

13order:

14build:../microservice-demo/microservice-demo-order

15links:

16-eureka

17zuul:

18build:../microservice-demo/microservice-demo-zuul-server

19links:

20-eureka

21ports:

22-"8080:8080"

23turbine:

24build:../microservice-demo/microservice-demo-turbine-server

25links:

26-eureka

27ports:

28-"8989:8989"

Listing5showstheconfigurationoftheexampleapplication.Itconsistsofthedifferentservices.buildreferencesthedirectorycontainingtheDockerfile.TheDockerfileisusedtogeneratetheimagefortheservice.linksdefineswhichadditionalDockerContainerstherespectiveContainershouldbeabletoaccess.AllContainerscanaccesstheEurekaContainerunderthenameeureka.IncontrasttotheVagrantconfigurationthereisnoJavabaseimage,whichcontainsonlyaJavainstallation.Thisisbecause,DockerComposesupportsonlycontainerswhichreallyofferaservice.ThereforethisbaseimagehastobedownloadedfromtheInternet.Besides,incaseoftheDockerComposecontainerstheJARfilesarecopiedintotheDockerimagessothattheimagescontaineverythingforstartingtheMicroservices.

Fig.74:NetworkforDockerCompose

TheresultingsystemisverysimilartotheVagrantsystem(Fig.74).TheDockercontainersarelinkedviatheirownprivatenetwork.FromtheoutsideonlyZuulcanbeaccessedfortheprocessingofrequestsandEurekaforthedashboard.Thearerunningdirectlyonahostthatthencanbeaccessedfromtheoutside.

Usingdocker-composebuildthesystemiscreatedbasedontheDockerComposeconfiguration.ThusthesuitableImagesaregenerated.docker-composeupthenstartsthesystem.DockerComposeusesthesamesettingsastheDockercommandlinetool.SoitcanalsoworktogetherwithDockerMachine.ThusitistransparentwhetherthesystemisgeneratedonalocalvirtualmachineorsomewhereintheCloud.

TryandExperiment

RuntheExamplewithDockerComposeTheexampleapplicationpossessesasuitableDockerComposeconfiguration.UponthegenerationofanenvironmentwithDockerMachineDockerComposecanbeusedtocreatetheDockercontainers.README.mdinthedirectorydockerdescribesthenecessaryprocedure.

ScaletheApplicationHavealookatthedocker-composescale command.Itcanscaletheenvironment.Servicescanberestarted,logscanbeanalyzedandfinallystopped.Onceyouhavestartedtheapplication,youcantestthesefunctionalities.

ClusterEnvironmentsforDockerMesos(http://mesos.apache.org/)togetherwithMesosphere(http://mesosphere.com/),Kubernetes(http://kubernetes.io/)orCoreOS(http://coreos.com/)offerssimilaroptionsasDockerComposeandDockerMachine,howevertheyaremeantforserversandserverclusters.TheDockerComposeandDockerMachineconfigurationscanprovideagoodbasisforrunningtheapplicationontheseplatforms.

14.8ServiceDiscoverySection8.9introducedthegeneralprinciplesofServiceDiscovery.TheexampleapplicationusesEurekaforServiceDiscovery.

EurekaisaREST-basedserver,whichallowsservicestoregisterthemselvessothatotherservicescanrequesttheirlocationinthenetwork.Inessence,eachservicecanregisteraURLunderitsname.OtherservicescanfindtheURLbythenameoftheservice.UsingthisURLotherservicescanthensendRESTmessagestothisservice.

Eurekasupportsreplicationontoseveralserversandcachesontheclient.Thismakesthesystemfail-safeagainstthefailureofindividualEurekaserversandallowstoanswerrequestsrapidly.Changestodatahavetobereplicatedtoall

servers.Accordingly,itcantakesometimetilltheyarereallyupdatedeverywhere.Duringthistimethedataisinconsistent:Eachserverhasadifferentversionofthedata.

InadditionEurekasupportsAmazonWebServicesbecauseNetflixusesitinthisenvironment.EurekacanforinstancequiteeasilybecombinedwithAmazon’sscaling.

EurekamonitorstheregisteredservicesandremovesthemfromtheserverlistiftheycannotbereachedanymorebytheEurekaserver.

EurekaisthebasisformanyotherservicesoftheNetflixStackandforSpringCloud.ThroughauniformServiceDiscoveryotheraspectssuchasroutingcaneasilybeimplemented.

EurekaClient

ForaSpringBootapplicationtobeabletoregisterwithaEurekaserverandtofindotherMicroservices,theapplicationhastobeannotatedwith@EnableDiscoveryClientor@EnableEurekaClient.Inadditionadependencyfromspring-cloud-starter-eurekahastobeincludedinthepom.xml.TheapplicationregistersautomaticallywiththeEurekaserverandcanaccessotherMicroservices.TheexampleapplicationaccessesotherMicroservicesviaaloadbalancer.Thisisdescribedindetailinsection14.11.

Configuration

ConfiguringtheapplicationisnecessarytodefineforinstancetheEurekaservertobeused.Thefileapplication.properties(Listing6)isusedforthat.SpringBootreadsitoutautomaticallyinordertoconfiguretheapplication.Thismechanismcanalsobeusedtoconfigureone’sowncode.IntheexampleapplicationthevaluesservetoconfiguretheEurekaclient:

ThefirstlinedefinestheEureka-Server.TheexampleapplicationusestheDockerlink,whichprovidestheEurekaserverunderthehostname“eureka”.leaseRenewalIntervalInSecondsdetermineshowoftendataareupdatedbetweenclientandserver.Asthedatahavetobeheldlocallyinacacheoneachclient,anewservicefirstneedstocreateitsowncacheandreplicateitontotheserver.Afterwardsthedataarereplicatedontotheclients.Withinatestenvironmentitisimportanttotracksystemchangesrapidlysothattheexampleapplicationusesfivesecondsinsteadofthepresetvalueof30

seconds.Inproductionwithmanyclientsthisvalueshouldbeincreased.Otherwisetheupdatesofinformationwillusealotofresources,eventhoughtheinformationremainsessentiallyunchanged.spring.application.nameservesasnamefortheserviceduringtheregistrationatEureka.Duringregistrationthenameisconvertedintocapitalletters.ThisservicewouldthusbeknownbyEurekaunderthename“CUSTOMER”.Therecanbeseveralinstancesofeachservicetoachievefailoverandloadbalancing.TheinstanceIdhastobeuniqueforeachinstanceofaservice.Becauseofthatitcontainsarandomnumber,whichensuresunambiguousness.preferIpAddressmakessurethatMicroservicesregisterwiththeirIPaddressandnotwiththeirhostname.InaDockerenvironmenthostnamesareunfortunatelynoteasilyresolvablebyotherhosts.ThisproblemiscircumventedbytheuseofIPaddresses.

Listing6:Partofapplication.properties withEurekaconfiguration

1eureka.client.serviceUrl.defaultZone=http://eureka:8761/eureka/

2eureka.instance.leaseRenewalIntervalInSeconds=5

3spring.application.name=catalog

4eureka.instance.metadataMap.instanceId=catalog:${random.value}

5eureka.instance.preferIpAddress=true

EurekaServer

TheEurekaserver(Listing7)isasimpleSpringBootapplication,whichturnsintoaEurekaserverviathe@EnableEurekaServerannotation.Inadditiontheserverneedsadependencyonspring-cloud-starter-eureka-server.Listing7:EurekaServer1@EnableEurekaServer

2@EnableAutoConfiguration

3publicclassEurekaApplication{

4publicstaticvoidmain(String[]args){

5SpringApplication.run(EurekaApplication.class,

6args);

7}

8}

TheEurekaserveroffersadashboard,whichshowstheregisteredservices.Intheexampleapplicationthiscanbefoundathttp://localhost:18761/(Vagrant)oronDockerhostunderport8761(DockerCompose).Fig.75showsascreenshotoftheEurekaDashboardsfortheexampleapplication.ThethreeMicroservicesand

theZuul-Proxy,whichisdiscussedinthenextsection,arepresentonthedashboard.

Fig.75:EurekaDashboard

14.9CommunicationChapter9explainedhowMicroservicescommunicatewitheachotherandcanbeintegrated.TheexampleapplicationusesRESTforinternalcommunication.TheRESTendpointscanbecontactedfromoutside,howeverthewebinterfacethesystemoffersisoffargreaterimportance.TheRESTimplementationusesHATEOAS.Thelistcontainingallordersforinstancecontainslinkstotheindividualorders.ThisisautomaticallyimplementedbySpringDataREST.However,therearenolinkstothecustomerandtheitemsoftheorder.

UsingHATEOAScangofurther:TheJSONcancontainalinktoanHTMLdocumentforeachorder–andviceversa.InthiswayaJSON-REST-basedservicecangeneratelinkstoHTMLpagestodisplayormodifydata.SuchHTMLcodecanforinstancepresentaniteminanorder.AsthecatalogteamprovidestheHTMLcodefortheitem,thecatalogteamitselfcanintroducechangestothepresentation–eveniftheitemsaredisplayedinanothermodule.

RESTisalsoofusehere:HTMLandJSONarereallyonlyrepresentationsofthesameresourcethatcanbeaddressedbyaURL.ViaContentNegotiationtherightresourcerepresentationasJSONorHTMLcanbeselected(comparesection9.2).

Zuul:Routing

TheZuulProxytransfersincomingrequeststotherespectiveMicroservices.TheZuulProxyisaseparateJavaprocess.TotheoutsideonlyoneURLisvisible,howeverinternallythecallsareprocessedbydifferentMicroservices.ThisallowsthesystemtointernallychangethestructureoftheMicroservices,whilestillofferingaURLtotheoutside.InadditionZuulcanprovidewebresources.IntheexampleZuulprovidesthefirstHTMLpageviewedbytheuser.

Fig.76:Zuul-Proxyintheexampleapplication

ZuulneedstoknowwhichrequeststotransfertowhichMicroservice.WithoutadditionalconfigurationEurekawillforwardarequesttoaURLstartingwith“/customer”totheMicroservicecalledCUSTOMER.ThisrenderstheinternalMicroservicenamesvisibletotheoutside.Butthisroutingcanalsobeconfigureddifferently.MoreoverZuulfilterscanchangetherequestsinordertoimplementgeneralaspectsinthesystem.ThereisforinstanceanintegrationwithSpringCloudSecuritytopassonsecuritytokenstotheMicroservices.Suchfilterscanalsobeusedtopassoncertainrequeststospecificservers.Thisallowsforinstancetotransferrequeststoservershavingadditionalanalysisoptionsforinvestigatingerrorsituations.InadditionapartofaMicroservicefunctionalitycanbereplacedbyanotherMicroservice.

ImplementingtheZuul-ProxyserverwithSpringCloudisveryeasyandanalogoustotheEurekaserverpresentedinListing7.Insteadof@EnableEurekaServeritis@EnableZuulProxy,whichactivatestheZuul-Proxy.Asadditionaldependencyspring-cloud-starter-zuulhastobeaddedtotheapplication,for

instancewithintheMavenbuildconfiguration,whichthenintegratestheremainingdependenciesofZuulintotheapplication.

AZuulserverrepresentsanalternativetoaZuulProxy.Itdoesnothaveroutingbuilt-in,butusesfiltersinstead.AZuulserverisactivatedby@EnableZuulServer.

TryandExperiment

AddLinkstoCustomerandItemsExtendtheapplicationsothatanordercontainsalsolinkstothecustomerandtotheitemsandthusimplementsHATEOASbetter.SupplementtheJSONdocumentsforcustomer,itemsandorderswithlinkstotheforms.

UsetheCatalogServicetoShowItemsinOrdersChangetheorderpresentationsothatHTMLfromtheCatalogserviceisusedforitems.Todoso,youhavetoinsertsuitableJavaScriptcodeintotheordercomponent,whichloadsHTMLcodefromtheCatalog.

ImplementZuulFiltersImplementyourownZuulfilter(comparehttps://github.com/Netflix/zuul/wiki/Writing-Filters).Thefiltercanforinstanceonlyreleasetherequests.IntroduceanadditionalroutingtoanexternalURL.Forinstance/googlecouldredirecttohttp://google.com/.Comparethe

SpringCloudreferencedocumentation.

AuthenticationandAuthorizationInsertanauthenticationandauthorizationwithSpringCloudSecurity.Comparehttp://cloud.spring.io/spring-cloud-security/.

14.10ResilienceResiliencemeansthatMicroservicescandealwiththefailureofotherMicroservices.EvenifacalledMicroserviceisnotavailable,theywillstillwork.Section10.5presentedthistopic.

TheexampleapplicationimplementsResiliencewithHystrix.Thislibraryprotectscallssothatnoproblemsariseifasystemfails.WhenacallisprotectedbyHystrix,itisexecutedinadifferentthreadthanthecallitself.Thisthreadistakenfromadistinctthreadpool.Thismakesitcomparativelyeasytoimplementatimeoutduringacall.

CircuitBreaker

InadditionHystriximplementsaCircuitBreaker.Ifacallcausesanerror,theCircuitBreakerwillopenafteracertainnumberoferrors.Inthatcasesubsequentcallsarenotdirectedtothecalledsystemanymore,butgenerateanerrorimmediately.AfterasleepwindowtheCircuitBreakerclosessothatcallsaredirectedtotheactualsystemagain.Theexactbehaviorcanbeconfigured.Intheconfigurationtheerrorthresholdpercentagecanbedetermined.ThatisthepercentageofcallswhichhavetocauseanerrorwithinthetimewindowfortheCircuitBreakertoopen.Alsothesleepwindowcanbedefined,inwhichtheCircuitBreakerisopenandnotsendingcallstothesystem.

HystrixwithAnnotations

SpringCloudusesJavaAnnotationsfromtheprojecthystrix-javanicafortheconfigurationofHystrix.Thisprojectispartofhystrix-contrib.TheannotatedmethodsareprotectedaccordingtothesettingintheAnnotation.WithoutthisapproachHystrixcommandswouldhavetobewritten,whichisalotmoreeffortthanjustaddingsomeAnnotationstoaJavamethod.

TobeabletouseHystrixwithinaSpringCloudapplication,theapplicationhastobeannotatedwith@EnableCircuitBreakerresp.@EnableHystrix.Moreover,theprojectneedstocontainadependencytospring-cloud-starter-hystrix.

Listing8showsasectionfromtheclassCatalogClientoftheOrderMicroservicefromtheexampleapplication.ThemethodfindAll()isannotatedwith@HystrixCommand.ThisactivatestheprocessinginadifferentthreadandtheCircuitBreaker.TheCircuitBreakercanbeconfigured–intheexamplethenumberofcalls,whichhavetocauseanerrorinordertoopentheCircuitBreaker,

issetto2.InadditiontheexampledefinesafallbackMethod.Hystrixcallsthismethodiftheoriginalmethodgeneratesanerror.ThelogicinfindAll()savesthelastresultinacache,whichisreturnedbythefallbackMethodwithoutcallingtherealsystem.InthiswayareplycanstillbereturnedwhenthecalledMicroservicefails,howeverthisreplymightnolongerbeup-to-date.Listing8:ExampleforamethodprotectedbyHystrix

1@HystrixCommand(

2fallbackMethod="getItemsCache",

3commandProperties={

4@HystrixProperty(

5name="circuitBreaker.requestVolumeThreshold",

6value="2")})

7publicCollection<Item>findAll(){

8this.itemsCache=...

9...

10returnpagedResources.getContent();

11}

12

13privateCollection<Item>getItemsCache(){

14returnitemsCache;

15}

MonitoringwiththeHystrixDashboard

WhetheraCircuitBreakeriscurrentlyopenorclosed,givesanindicationofhowwellasystemisrunning.Hystrixoffersdatatomonitorthis.AHystrixsystemprovidessuchdataasastreamofJSONdocumentsviaHTTP.TheHystrixDashboardcanvisualizethedatainawebinterface.ThedashboardpresentsallCircuitBreakersalongwiththenumberofrequestsandtheirstate(open/closed)(Fig.77).Inadditionitdisplaysthestateofthethreadpools.

Fig.77:ExampleforaHystrixDashboard

ASpringBootApplicationneedstohavetheannotation@EnableHystrixDashboardandadependencytospring-cloud-starter-hystrix-dashboardtobeabletodisplayaHystrixDashboard.ThatwayanySpringBootapplicationmightinadditionshowaHystrixDashboardorthedashboardcanbeimplementedinanapplicationbyitself.

Turbine

InacomplexMicroservicesenvironmentitisnotusefulthateachinstanceofaMicroservicevisualizestheinformationconcerningthestateofitsHystrixCircuitBreaker.ThestateofallCircuitBreakersintheentiresystemshouldbesummarizedonasingledashboard.TovisualizethedataofthedifferentHystrixsystemsononedashboardthereistheTurbineproject.Fig.78illustratestheapproachTurbinetakes:ThedifferentstreamsoftheHystrixenabledMicroservicesareprovidedatURLslikehttp://<host:port>/hystrix.stream.TheTurbineserverrequeststhemandprovidestheminaconsolidatedmannerattheURLhttp://<host:port>/turbine.stream.ThisURLcanbeusedbythedashboardinordertodisplaytheinformationofallCircuitBreakersofthedifferentMicroserviceinstances.

Fig.78:TurbineconsolidatesHystrixmonitoringdata.

Turbinerunsinaseparateprocess.WithSpringBoottheTurbineserverisasimpleapplication,whichisannotatedwith@EnableTurbineand@EnableEurekaClient.Intheexampleapplicationithastheadditionalannotation@EnableHystrixDashboardsothatitalsodisplaystheHystrixDashboard.Italsoneedsadependencyonspring-cloud-starter-turbine.

WhichdataareconsolidatedbytheTurbineserverisdeterminedbytheconfigurationoftheapplication.Listing9showstheconfigurationoftheTurbineserversoftheexampleproject.ItservesasaconfigurationforaSpringBootapplicationjustlikeapplication.propertiesfiles,butiswritteninYAML.Theconfigurationsetsthevalue“ORDER”forturbine.aggregator.clusterConfig.ThisistheapplicationnameinEureka.turbine.aggregator.appConfigisthenameofthedatastreamintheTurbineserver.IntheHystrixDashboardaURLlikehttp://172.17.0.10:8989/turbine.stream?cluster=ORDERhastobeusedinvisualizethedatastream.PartoftheURListheIP-AdresseoftheTurbineserver,whichcanbefoundintheEurekaDashboard.ThedashboardaccessestheTurbineserverviathenetworkbetweentheDockercontainers.

Listing9:Configurationapplication.yml

1turbine:

2aggregator:

3clusterConfig:ORDER

4appConfig:order

TryandExperiment

TerminateMicroservicesUsingtheexampleapplicationgenerateanumberoforders.FindthenameoftheCatalogDockerContainerusingdockeps .StoptheCatalogDockerContainerwithdockerkill.ThisuseisprotectedbyHystrix.Whathappens?

WhathappensiftheCustomerDockerContaineristerminatedaswell?TheuseofthisMicroserviceisnotprotectedbyHystrix.

AddHystrixtoCustomerMicroserviceProtecttheuseoftheCustomerDockerContaineralsowithHystrix.InordertodosochangetheclassCustomerClientfromtheOrderproject.CatalogClientcanserveasatemplate.

ChangeHystrixConfigurationChangetheconfigurationofHystrixfortheCatalogMicroservice.Thereareseveralconfigurationoptions.Listing8(CatalogClientfromtheOrder-Project)showstheuseoftheHystrixannotations.OthertimeintervalsforopeningandclosingoftheCircuitBreakersareforinstanceapossiblechange.

14.11LoadBalancingForLoadBalancingtheexampleapplicationusesRibbon.ManyLoadBalancersareproxy-based.InthismodeltheclientssendallcallstoaLoadBalancer.TheLoadBalancerrunsasadistinctserverandforwardstherequesttoawebserver–oftendependingonthecurrentloadofthewebservers.

RibbonimplementsadifferentmodelcalledClientSideLoadBalancing:Theclienthasalltheinformationtocommunicatewiththerightserver.Theclientcallstheserverdirectlyanddistributestheloadbyitselftodifferentservers.Inthearchitecturethereisnobottleneckasthereisnocentralserverallcallswouldhavetopass.InconjunctionwithdatareplicationbyEurekaRibbonisquiteresilient:Aslongastheclientruns,itcansendrequests.ThefailureofaProxyLoadBalancerwouldstopallcallstotheserver.

Dynamicscalingisverysimplewithinthissystem:Anewinstanceisstarted,enlistsitselfatEurekaandthentheRibbonClientsredirectloadtotheinstance.

AsalreadydiscussedinthesectiondealingwithEureka(Section14.8),datacanbeinconsistentoverthedifferentservers.Becausedataarenotup-to-date,serverscanbecontacted,whichreallyshouldbeleftoutbytheLoadBalancing.

RibbonwithSpringCloud

SpringCloudsimplifiestheuseofRibbon.Theapplicationhastobeannotatedwith@RibbonClient.Whiledoingso,anamefortheapplicationcanbedefined.Inadditiontheapplicationneedstohaveadependencyonspring-cloud-starter-ribbon.InthatcaseaninstanceofaMicroservecanbeaccessedusingcodelikeinListing10.ForthatpurposethecodeusestheEurekanameoftheMicroservice.Listing10:DeterminingaserverwithRibbonLoadBalancing

1ServiceInstanceinstance

2=loadBalancer.choose("CATALOG");

3Stringurl="http://"+

4instance.getHost()+":"+

5instance.getPort()+

6"/catalog/";

Theusecanalsobetransparenttoalargeextent.ToillustratethisListing11showstheuseofRestTemplateswithRibbon.ThisisaSpringclass,whichcanbeusedtocallRESTservices.IntheListingtheRestTemplateofSpringisinjectedintotheobjectasitisannotatedwith@Autowired.ThecallincallMicroservice()lookslikeitiscontactingaservercalled“stores”.InrealitythisnameisusedtosearchaserveratEureka,andtothisservertheRESTcallissent.ThisisdoneviaRibbonsothattheloadisalsodistributedacrosstheavailableservers.Listing11:UsingRibbonwithRestTemplate1@RibbonClient(name="ribbonApp")

2…//LeftoutotherSpringCloud/BootAnnotations

3publicclassRibbonApp{

4

5@Autowired

6privateRestTemplaterestTemplate;

7

8publicvoidcallMicroservice(){

9Storestore=restTemplate.

10getForObject("http://stores/store/1",Store.class);

11}

12

13}

TryandExperiment

LoadBalancetoanAdditionalServiceInstanceTheOrderMicroservicedistributestheloadontoseveralinstancesoftheCustomerandCatalogMicroservice–ifseveralinstancesexist.Withoutfurthermeasures,onlyasingleinstanceisstarted.TheOrderMicroserviceshowsinthelogwhichCatalogorCustomerMicroserviceitcontacts.InitiateanorderandobservewhichServicesarecontacted.

AfterwardsstartanadditionalCatalogMicroservice.Youcandothatusingthecommand:dockerrun-v/microservice-demo:/microservice-demo–linkeureka:eurekacatalog-appinVagrant.ForDockerComposedocker-composescalecatalog=2shouldbeenough.Verifywhetherthecontainerisrunningandobservethelogoutput.

Forreference:TryandExperimentinsection14.4showsthemaincommandsforusingDocker.Section14.7showshowtouseDockerCompose.

CreateDataCreateanewdatasetwithanewitem.Istheitemalwaysdisplayedintheselectionofitems?Hint:ThedatabaserunswithintheprocessoftheMicroservice–i.e.eachMicroserviceinstancepossessesitsowndatabase.

14.12IntegratingOtherTechnologiesSpringCloudandtheentireNetflixStackarebasedonJava.Thus,itseemsimpossibleforotherprogramminglanguagesandplatformstousethisinfrastructure.However,thereisasolution:Theapplicationcanbesuppliedwithasidecar.ThesidecariswritteninJavaandusesJavalibrariestointegrateintoaNetflix-basedinfrastructure.Thesidecarforinstancetakescareofregistration

andfindingotherMicroservicesinEureka.NetflixitselfoffersforthispurposethePranaproject.TheSpringCloudsolutionisexplainedinthedocumentation.ThesidecarrunsinadistinctprocessandservesasaninterfacebetweentheMicroserviceitselfandtheMicroserviceinfrastructure.InthismannerotherprogramminglanguagesandplatformscanbeeasilyintegratedintoaNetflixorSpringCloudenvironment.

14.13TestsTheexampleapplicationcontainstestapplicationsforthedevelopersofMicroservices.ThesedonotneedaMicroserviceinfrastructureoradditionalMicroservices–incontrasttotheproductionsystem.ThisallowsdeveloperstoruneachMicroservicewithoutacomplexinfrastructure.

TheclassOrderTestAppintheOrderprojectcontainssuchatestapplication.Theapplicationscontaintheirownconfigurationfileapplication-test.propertieswithspecificsettingswithinthedirectorysrc/test/resources.ThesettingspreventthattheapplicationsregisterwiththeServiceDiscoveryEureka.BesidestheycontaindifferentURLsforthedependentMicroservices.ThisconfigurationisautomaticallyusedbythetestapplicationasitusesaSpringprofilecalled“test”.AllJUnittestsusethesesettingsaswellsothattheycanrunwithoutdependentservices.

Stubs

TheURLsforthedependentMicroservicesinthetestapplicationandtheJUnittestspointtoStubs.ThesearesimplifiedMicroservices,whichonlyofferapartofthefunctionalities.TheyrunwithinthesameJavaprocessastherealMicroservicesorJUnittests.SoonlyasingleJavaprocesshastobestartedforthedevelopmentofaMicroservice,analogoustotheusualwayofdevelopingwithJava.TheStubscanbeimplementeddifferently–forinstanceusingadifferentprogramminglanguageorevenawebserver,whichreturnscertainstaticdocumentsrepresentingthetestdata(comparesection11.6).Suchapproachesmightbebettersuitedforreal-lifeapplications.

Stubsfacilitatedevelopment.IfeachdeveloperneedstouseacompleteenvironmentincludingallMicroservicesduringdevelopment,atremendousamountofhardwareresourcesandalotofefforttokeeptheenvironmentcontinuouslyup-to-datewouldbenecessary.TheStubscircumventthisproblemasnodependentMicroservicesareneededduringdevelopment.Duetothestubs

theefforttostartaMicroserviceishardlybiggerthantheoneforaregularJavaapplication.

InarealprojecttheteamscanimplementStubstogetherwiththerealMicroservices.TheCustomerteamcanimplementinadditiontotherealserviceastubfortheCustomerMicroservice,whichisusedbytheotherMicroservicesfordevelopment.ThisensuresthatthestublargelyresemblestheMicroserviceandisupdatediftheoriginalserviceischanged.TheStubcanbetakencareofinadifferentMavenprojects,whichcanbeusedbytheotherteams.

Consumer-drivenContractTest

IthastobeensuredthattheStubsbehaveliketheMicroservicestheysimulate.InadditionaMicroservicehastodefinetheexpectationsregardingtheinterfaceofadifferentMicroservice.ThisisachievedbyConsumer-drivenContractTests(comparesection11.7).Thesearewrittenbytheteam,whichusestheMicroservices.Intheexamplethisistheteam,whichisresponsiblefortheOrderMicroservice.IntheOrderMicroservicetheConsumer-drivenContractTestsarefoundintheclassesCatalogConsumerDrivenContractTestandCustomerConsumerDrivenContractTest.TheyruntheretotestthestubsoftheCustomerandCatalogMicroserviceforcorrectness.

EvenmoreimportantthanthecorrectfunctioningofthestubsisthecorrectfunctioningoftheMicroservicesthemselves.ForthatreasontheConsumer-drivenContractTestsarealsocontainedintheCustomerandCatalogproject.TheretheyrunagainsttheimplementedMicroservices.ThisensuresthattheStubsaswellastherealMicroservicesareinlinewiththisspecification.Incasetheinterfaceissupposedtobechanged,thesetestscanbeusedtoconfirmthatthechangedoesnotbreakthecallingMicroservice.ItisuptotheusedMicroservices–CustomerandCatalogintheexample–,tocomplywiththesetests.InthismannertherequirementsoftheOrderMicroserviceinregardstotheCustomerandCatalogMicroservicecanbeformallydefinedandtested.TheConsumer-drivenContractTestsserveintheendasformaldefinitionoftheagreedinterface.

IntheexampleapplicationtheConsumer-drivenContractTestsarepartoftheCustomerandCatalogprojectsinordertoverifythattheinterfaceiscorrectlyimplemented.BesidestheyarepartoftheOrderprojectforverifyingthecorrectfunctioningofthestubs.Inarealprojectcopyingthetestsshouldbeprevented.TheConsumer-drivenContractTestscanbelocatedinoneprojecttogetherwiththetestedMicroservices.ThenallteamsneedtohaveaccesstotheMicroservice

projectstobeabletoalterthetests.Alternatively,theyarelocatedwithintheprojectsofthedifferentteams,whichareusingtheMicroservice.InthatcasethetestedMicroservicehastocollectthetestsfromtheotherprojectsandexecutethem.

InarealprojectitisnotreallynecessarytoprotectstubsbyConsumer-drivenContractTests,especiallyasitisthepurposeofthestubstoofferaneasierimplementationthantherealMicroservices.ThusthefunctionalitieswillbedifferentandconflictwithConsumer-drivenContractTests.

TryandExperiment

InsertafieldintoCatalogorCustomerdata.Isthesystemstillworking?Why?

DeleteafieldintheimplementationoftheserverforCatalogorCustomer.Whereistheproblemnoticed?Why?

Replacethehomegrownstubswithstubs,whichuseatoolfromSection11.6.

ReplacetheConsumer-drivenContractTestswithtests,whichuseatoolfromSection11.7.

ExperienceswithJVM-basedMicroservicesintheAmazonCloud(SaschaMöllering)bySaschaMöllering,zanoxAG

Duringthelastmonthszanoxhasimplementedalight-weightMicroservicesarchitectureinAmazonWebServices(AWS),whichrunsinseveralAWSregions.RegionsdividetheAmazonCloudintosectionslikeUS-EastorEU-West,whicheachhavetheirowndatacenters.Theyworkcompletelyindependentlyofeach

otheranddonotexchangeanydatadirectly.DifferentAWSregionsareusedbecauselatencyisveryimportantforthistypeofapplicationandisminimizedbylatency-basedrouting.Inadditionitwasafundamentalaimtodesignthearchitectureinanevent-drivenmanner.Furthermore,theindividualserviceswereintendednottocommunicatedirectly,butrathertobeseparatedbymessagequeuesresp.bussystems.AnApacheKafkaclusterasmessagebusinthezanoxdatacenterservesascentralpointofsynchronizationforthedifferentregions.Eachserviceisimplementedasastatelessapplication.Thestateisstoredinexternalsystemslikethebussystems,AmazonElastiCache(basedontheNoSQLdatabaseRedis),thedatastreamprocessingtechnologyAmazonKinesisandtheNoSQLdatabaseAmazonDynamoDB.TheJVMservesasbasisfortheimplementationoftheindividualservices.WechoseVert.xandtheembeddedwebserverJettyasframeworks.Wedevelopedallapplicationsasself-containedservicessothataFatJAR,whichcaneasilybestartedviajava–jar,isgeneratedattheendofthebuildprocess.

Thereisnoneedtoinstallanyadditionalcomponentsoranapplicationserver.Vert.xservesasbasisframeworkfortheHTTPpartofthearchitecture.Withintheapplicationworkisperformedalmostcompletelyasynchronouslytoachievehighperformance.FortheremainingcomponentsweuseJettyasframework:TheseacteitherasKafka/KinesisconsumerorupdatetheRediscachefortheHTTPlayer.AllcalledapplicationsaredeliveredinDockerContainers.Thisallowstheuseofauniformdeploymentmechanismindependentoftheutilizedtechnology.Tobeabletodelivertheservicesindependentlyinthedifferentregions,anindividualDockerRegistrystoringtheDockerimagesinaS3bucketwasimplementedineachregion.S3isaservicethatallowsthestorageoflargefileonAmazonserver.

IfyouintendtouseCloudServices,youhavetoaddressthequestionwhetheryouwanttousethemanagedservicesofaCloudproviderordevelopandruntheinfrastructureyourself.zanoxdecidedtousethemanagedservicesofaCloudproviderbecausebuildingandadministratingproprietaryinfrastructuremodulesdoesnotprovideanybusinessvalue.TheEC2computersoftheAmazonportfolioarepureinfrastructure.IAMontheotherhandofferscomprehensivesecuritymechanisms.InthedeployedservicestheAWSJavaSDKisused,whichallowsincombinationwithIAMrolesforEC2togenerateapplications,whichareabletoaccessthemanagedservicesofAWSwithoutusingexplicitcredentials.DuringinitialbootstrappinganIAMrolecontainingthenecessarypermissionsisassignedtoanEC2instance.ViatheMetadataServicetheAWSSDKisgiventhenecessarycredentials.Thisenablestheapplicationtoaccessthemanaged

servicesdefinedintherole.Thus,anapplicationcanbeimplemented,whichsendsmetricstothemonitoringsystemAmazonCloudWatchandeventstothedatastreamingprocessingsolutionAmazonKinesiswithouthavingtoroleoutexplicitcredentialstogetherwiththeapplication.

AllapplicationsareequippedwithRESTinterfacesforheartbeatsandhealthcheckssothattheapplicationitselfaswellastheinfrastructurenecessaryfortheavailabilityoftheapplicationcanbemonitoredatalltimes:Eachapplicationuseshealthcheckstomonitortheinfrastructurecomponentsituses.ApplicationscalingisimplementedviaElasticLoadBalancing(ELB)andAutoScalingtobeabletoachieveafine-grainedapplicationdependingontheconcreteload.AutoScalingstartsadditionalEC2instancesifneeded.ELBdistributestheloadbetweentheinstances.TheAWSELBserviceisnotonlysuitableforwebapplicationsworkingwithHTTPprotocols,butforalltypesofapplications.AhealthcheckcanalsobeimplementedbasedonaTCPprotocolwithoutHTTP.ThisisevensimplerthananHTTPhealthcheck.

StillthedeveloperteamdecidedtoimplementtheELBhealthchecksviaHTTPforallservicestoachievethattheyallbehaveexactlythesame,independentoftheimplementedlogic,theusedframeworksandthelanguage.Itiswellpossiblethatinthefuturealsoapplications,whichdonotrunonJVMandforinstanceuseGoorPythonasprogramminglanguages,aredeployedinAWS.

FortheELBhealthcheckzanoxusestheapplicationheartbeatURL.Asaresult,trafficisonlydirectedtotheapplicationresp.potentiallynecessaryinfrastructurescalingoperationsareonlyperformedoncetheEC2instancewiththeapplicationhasproperlybeenstartedandtheheartbeatwassuccessfullymonitored.

ForapplicationmonitoringAmazonCloudWatchisagoodchoiceasCloudWatchalarmscanbeusedtodefinescalingeventsfortheAutoScalingPolicies,i.e.theinfrastructurescalesautomaticallybasedonmetrics.ForthispurposeEC2basismetricslikeCPUcanforinstancebeused.Alternatively,itispossibletosendyourownmetricstoCloudWatch.Forthispurposethisprojectusesaforkoftheprojectjmxtrans-agent,whichusestheCloudWatchAPItosendJMXmetricstothemonitoringsystem.JMX(JavaManagementExtension)isthestandardformonitoringandmetricsintheJavaworld.Besidesmetricsaresentfromwithintheapplication(i.e.fromwithinthebusinesslogic)usingthelibraryCodaHaleMetricsandamodulefortheCloudWatchintegrationbyBlacklocus.

Aslightlydifferentapproachischosenforthelogging:InaCloudenvironmentitisneverpossibletoruleoutthataserverinstanceisabruptlyterminated.Thiscausesoftenthesuddenlossofdata,whicharestoredontheserver.Logfilesareanexampleforthat.Forthisreasonalogstash-forwarderrunsinparalleltothecoreapplicationontheserverforsendingthelogentriestoourELK-Servicerunninginourowndatacenter.ThisstackconsistsofElasticsearchforstorage,LogstashforparsingthelogdataandKibanaforUI-basedanalysis.ELKisanacronymforElasticsearch,LogstashundKibana.InadditionaUUIDiscalculatedforeachrequestresp.eacheventinourHTTPlayersothatlogentriescanstillbeassignedtoeventsafterEC2instanceshaveceasedtoexist.

Conclusion

ThepatternofMicroservicesarchitecturesfitswelltothedynamicapproachofAmazonCloudifthearchitectureiswelldesignedandimplemented.Theclearadvantageoverimplementinginyourowndatacenteristheinfrastructureflexibility.Thisallowstoimplementanearlyendlesslyscalablearchitecture,whichisinadditionverycost-efficient.

14.14ConclusionThetechnologiesusedintheexampleprovideaverygoodfoundationforimplementingaMicroservicesarchitecturewithJava.Essentially,theexampleisbasedontheNetflixStack,whichhasdemonstrateditsefficacyforyearsalreadyinoneofthelargestwebsites.

TheexampledemonstratestheinterplayofdifferenttechnologiesforServiceDiscovery,LoadBalancingandResilience–aswellasanapproachfortestingMicroservicesundfortheirexecutioninDockerContainers.Theexampleisnotmeanttobedirectlyuseableinaproductioncontext,butisfirstofalldesignedtobeveryeasytosetupandgetrunning.Thisentailsanumberofcompromises.However,theexampleservesverywellasfoundationforfurtherexperimentsandthetestingofideas.

InadditiontheexampledemonstratesaDocker-basedapplicationdeployment,whichisagoodfoundationforMicroservices.

EssentialPoints

Spring,SpringBoot,SpringCloudandtheNetflixStackofferawellintegratedstackforJava-basedMicroservices.Thesetechnologiessolveall

typicalchallengesposedduringthedevelopmentofMicroservices.DockerbaseddeploymentiseasytoimplementandinconjunctionwithDockerMachineandDockerComposecanbeusedfordeploymentintheCloud,too.TheexampleapplicationshowshowtotestMicroservicesusingConsumer-DrivenContractTestsandStubswithoutspecialtools.However,forreallifeprojectstoolsmightbemoreuseful.

TryandExperiment

AddLogAnalysisTheloganalysisofalllogfilesisimportantforrunningaMicroservicesystem.Athttps://github.com/ewolff/user-registrationanexampleprojectisprovided.Inthesubdirectorylog-analysis itcontainsasetupforanELK(Elasticsearch,LogstashundKibana)stack-basedloganalysis.UsethisapproachtoalsoaddaloganalysistotheMicroserviceexample.

AddMonitoringInadditiontheexampleprojectfromtheContinuousDeliverybookcontainsinthesubdirectorygraphiteaninstallationofGraphiteformonitoring.AdaptthisinstallataionfortheMicroserviceexample.

RewriteaServiceRewriteoneoftheservicesinadifferentprogramminglanguage.UsetheConsumer-drivenContractTests(compareSection14.13and11.7toprotecttheimplementation.Makeuseofasidecarfortheintegrationintothetechnologystack(compareSection14.12).

15TechnologiesforNanoservices

Section15.1discussestheadvantagesofNanoservicesandwhyNanoservicescanbeuseful.Section15.2definesNanoservicesanddistinguishesthemfromMicroservices.Section15.3focusesonAmazonLambda:aCloudtechnologywhichcanbeusedwithPython,JavaScriptorJava.Hereeachfunctioncallisbilledinsteadofrentingvirtualmachinesorapplicationservers.OSGi(section15.4)modularizesJavaapplicationsandalsoprovidesservices.AnotherJavatechnologyforNanoservicesisJavaEE(section15.5),ifusedcorrectly.Vert.x,anotheroption,(section15.6)alsorunsontheJVM,butsupportsinadditiontoJavaabroadvarietyofprogramminglanguages.Section15.7focusesontheprogramminglanguageErlangwhichisquiteold.ThearchitectureofErlangallowstheimplementationofNanoservices.Seneca(section15.8)hasasimilarapproachasErlang,butisbasedonJavaScriptandhasbeenspeciallydesignedforthedevelopmentofNanoservices.

ThetermMicroserviceisnotuniformlydefined.SomepeoplebelieveMicroservicesshouldbeextremelysmallservices–i.e.tentoahundredlinesofcode(LoC).ThisbookcallssuchservicesNanoservices.ThedistinctionbetweenMicroservicesandNanoservicesisthefocusofthischapter.Asuitabletechnologyisanessentialprerequisitefortheimplementationofsmallservices.Ifthetechnologyforinstancecombinesseveralservicesintooneoperatingsystemprocess,theresourceutilizationperservicecanbedecreasedandtheservicerolloutinproductionfacilitated.ThisdecreasestheexpenditureperservicewhichallowstosupportalargenumberofsmallNanoservices.

15.1WhyNanoservices?NanoservicesarewellinlinewiththealreadydiscussedsizelimitsofMicroservices:Theirsizeisbelowthemaximumsize,whichwasdefinedinsection4.1anddependsforinstanceonthenumberofteammembers.Inaddition,aMicroserviceshouldbesmallenoughtostillbeunderstoodbyadeveloper.WithsuitabletechnologiesthetechnicallimitsfortheminimalsizeofaMicroservice,whichwerediscussedinsection4.1,canbefurtherreduced.

Verysmallmodulesareeasiertounderstandandthereforeeasiertomaintainandchange.BesidessmallerMicroservicescanmoreeasilybereplacedbynewimplementationsorarewrite.Accordingly,systemsconsistingofminimallysizedNanoservicescanmoreeasilybedevelopedfurther.

TherearesystemswhichsuccessfullyemployNanoservices.Infact,inpracticeitisratherthetoolargemodulesthatarethesourceofproblemsandpreventthesuccessfulfurtherdevelopmentofasystem.EachfunctionalitycouldbeimplementedinitsownMicroservice–eachclassorfunctioncouldbecomeaseparateMicroservice.Section10.2demonstratedthatitcanbesensibleforCQRStoimplementaMicroservicewhichonlyreadsdataofacertaintype.WritingthesametypeofdatacanalreadybeimplementedinanotherMicroservice.SoMicroservicescanreallyhaveaprettysmallscope.

MinimumSizeofMicroservicesisLimited

WhatarereasonsagainstverytinyMicroservices?Section4.1identifiedfactorswhichrenderMicroservicesbelowacertainsizenotpracticable:

Theexpenditureforinfrastructureincreases.WheneachMicroserviceisaseparateprocessandrequiresinfrastructuresuchasanapplicationserverandmonitoring,theexpenditurenecessaryforrunninghundredsoreventhousandsofMicroservicesbecomestoolarge.Therefore,Nanoservicesrequiretechnologieswhichallowtokeeptheexpenditureforinfrastructureperindividualserviceassmallaspossible.Inaddition,alowresourceutilizationisdesirable.TheindividualservicesshouldconsumeaslittlememoryandCPUaspossible.Incaseofverysmallservicesalotofcommunicationviathenetworkisrequired.Thathasanegativeinfluenceonsystemperformance.Consequently,whenworkingwithNanoservicescommunicationbetweentheservicesshouldnotoccurviathenetwork.Thismightresultinlesstechnologicalfreedom.WhenallNanoservicesruninasingleprocess,theyareusuallyrequiredtoemploythesametechnology.Suchanapproachalsoaffectssystemrobustness.Whenseveralservicesruninthesameprocess,itismuchmoredifficulttoisolatethemfromeachother.ANanoservicecanuseupsomanyresourcesthatotherNanoservicesdonotoperateerror-freeanymore.WhentwoNanoservicesruninthesameprocess,theoperatingsystemcannotinterveneinsuchsituations.Inaddition,acrashofaNanoservicecanresultinthefailureofadditionalNanoservices.Ifthe

processescrashes,itwillaffectallNanoservicesrunninginthesameprocess.

ThetechnicalcompromisescanhaveanegativeeffectonthepropertiesofNanoservices.InanycasetheessentialfeatureofMicroserviceshastobemaintained–namely,theindependentdeploymentoftheindividualservices.

Compromises

IntheendthemaintaskistoidentifytechnologieswhichminimizetheoverheadperNanoserviceandatthesametimepreserveasmanyadvantagesofMicroservicesaspossible.

Indetailthefollowingpointsneedtobeachieved:

Theexpenditureforinfrastructuresuchasmonitoringanddeploymenthastobekeptlow.IthastobepossibletobringanewNanoserviceintoproductionwithoutmucheffortandtohaveitimmediatelydisplayedinmonitoring.ResourceutilizationforinstanceinregardstomemoryshouldbeaslowaspossibletoallowalargenumberofNanoservicesalsowithlittlehardware.Thisdoesnotonlymaketheproductionenvironmentcheaper,butalsofacilitatesthegenerationoftestenvironments.Communicationshouldbepossiblewithoutnetwork.Thisdoesnotonlyimprovelatencyandperformance,butincreasesthereliabilityofthecommunicationbetweenNanoservicesbecauseitisnotinfluencedbynetworkfailures.Concerningisolationacompromisehastobefound.TheNanoservicesshouldbeisolatedfromeachothersothatoneNanoservicecannotcauseanotherNanoservicetofail.OtherwiseasingleNanoservicemightcausetheentiresystemtobreakdown.However,achievingaperfectisolationmightbelessimportantthanhavingalowerexpenditureforinfrastructure,alowresourceutilizationandtheotheradvantagesofNanoservices.UsingNanoservicescanlimitthechoiceofprogramminglanguages,platformsandframeworks.Microservicesontheotherhandallowinprincipleafreechoiceoftechnology.

DesktopApplications

NanoservicesenabletheuseofMicroserviceapproachesinareasinwhichMicroservicesthemselvesarehardlyuseable.OneexampleisthepossibilitytodivideadesktopapplicationinNanoservices.OSGi(section15.4)isforinstance

usedfordesktopandevenforembeddedapplications.AdesktopapplicationconsistingofMicroservicesisontheotherhandprobablytoodifficulttodeploytoreallyuseitfordesktopapplications.EachMicroservicehastobedeployedbyitselfandthatishardlypossibleforalargenumberofdesktopclients-someofwhichmightevenbelocatedinothercompanies.MoreovertheintegrationofseveralMicroservicesintoacoherentdesktopapplicationishard-inparticulariftheyareimplementedascompletelyseparatedprocesses.

15.2Nanoservices:DefinitionANanoservicediffersfromaMicroservice:Itcompromisesincertainareas.Oneoftheseareasisisolation:MultipleNanoservicesrunonasinglevirtualmachineorinasingleprocess.Anotherareaistechnologyfreedom:Nanoservicesuseasharedplatformorprogramminglanguage.OnlywiththeselimitationsdoestheuseofNanoservicesbecomefeasible.Theinfrastructurecanbesoefficientthatamuchlargernumberofservicesispossible.Thisallowstheindividualservicestobesmaller.ANanoservicemightcompriseonlyafewlinesofcode.

However,bynomeansmaythetechnologyrequireajointdeploymentofNanoservicessinceindependentdeploymentisthecentralcharacteristicofMicroservicesandalsoNanoservices.IndependentdeploymentconstitutesthebasisfortheessentialadvantagesofMicroservices:Teamswhichcanworkindependently,astrongmodularizationandasconsequenceasustainabledevelopment.

Therefore,Nanoservicescanbedefinedasfollows:

NanoservicescompromiseinregardstosomeMicroservicepropertiessuchasisolationandtechnologyfreedom.However,Nanoservicesstillhavetobeindependentlydeployable.Thecompromisesallowforalargernumberofservicesandthereforeforsmallerservices.Nanoservicescancontainjustafewlinesofcode.Toachievethis,Nanoservicesusehighlyefficientruntimeenvironments.TheseexploittherestrictionsofNanoservicesinordertoallowformoreandsmallerservices.

ThusNanoservicesdependalotontheemployedtechnologies.ThetechnologyenablescertaincompromisesinNanoservicesandthereforeNanoservicesofacertainsize.Therefore,thischapterisgearedtodifferenttechnologiestoexplainthepossiblevarietiesofNanoservices.

TheobjectiveofNanoservicesistoamplifyanumberofadvantagesofMicroservices.Havingevensmallerdeploymentunitsdecreasesthedeploymentriskfurther,facilitatesdeploymentevenmoreandachievesbetterunderstandableandreplaceableservices.Inaddition,thedomainarchitecturewillchange:ABoundedContextwhichmightconsistofoneorafewMicroserviceswillnowcompriseamultitudeofNanoserviceswhicheachimplementaverynarrowlydefinedfunctionality.

ThedifferencebetweenMicroservicesandNanoservicesisnotstrictlydefined:IftwoMicroservicesaredeployedinthesamevirtualmachine,efficiencyincreasesandisolationiscompromised.ThetwoMicroservicesnowshareanoperatingsysteminstanceandavirtualmachine.WhenoneoftheMicroservicesusesuptheresourcesofthevirtualmachine,theotherMicroservicerunningonthesamevirtualmachinewillalsofail.Thisisthecompromiseintermsofisolation.SoinasensetheseMicroservicesarealreadyNanoservices.

Bytheway,theterm“Nanoservice”isnotusedverymuch.Thisbookusestheterm“Nanoservice”tomakeitplainthattherearemodularizationswhicharesimilartoMicroservices,butdifferwhenitcomestodetailtherebyallowingforevensmallerservices.Todistinguishthesetechnologieswiththeircompromisesclearlyfrom“real”Microservicestheterm“Nanoservice”isuseful.

15.3AmazonLambdaAmazonLambdaisaserviceintheAmazonCloud.ItisavailableworldwideinallAmazoncomputingcenters.

AmazonLambdacanexecuteindividualfunctionswhicharewritteninPython,JavaScriptwithNode.jsorJava8withOpenJDK.ThecodeofthesefunctionsdoesnothavedependenciesonAmazonLambda.Accesstotheoperatingsystemispossible.ThecomputersthecodeisexecutedoncontaintheAmazonWebServicesSDKaswellasImageMagickforimagemanipulations.ThesefunctionalitiescanbeusedbyAmazonLambdaapplications.Besidesadditionallibrariescanbeinstalled.

AmazonLambdafunctionshavetostartquicklybecauseitcanhappenthattheyarestartedforeachrequest.Therefore,thefunctionsmayalsonotholdastate.

Thustherearenocostswhentherearenorequeststhatcauseanexecutionofthefunctions.Eachrequestisbilledindividually.Currentlythefirstmillionrequests

isforfreeandafurthermillioncosts0,20$.

CallingLambdaFunctions

Lambdafunctionscanbecalleddirectlyviaacommandlinetool.Theprocessingoccursasynchronously.ThefunctionscanreturnresultsviadifferentAmazonfunctionalities.Forthispurpose,theAmazonCloudcontainsmessagingsolutionssuchasSNS(SimpleNotificationService)orSQS(SimpleQueuingService).

ThefollowingeventscantriggeracallofaLambdafunction:

InS3(SimpleStorageService)largefilescanbestoredanddownloaded.SuchactionstriggereventstowhichanAmazonLambdafunctioncanreact.AmazonKinesiscanbeusedtoadministrateanddistributedatastreams.Thistechnologyismeantfortherealtimeprocessingoflargedataamounts.Lambdacanbecalledasreactiontonewdatainthesestreams.WithAmazonCognitoitispossibletouseAmazonLambdatoprovidesimplebackendsformobileapplications.TheAPIGatewayprovidesawaytoimplementRESTAPIsusingAmazonLambda.FurthermoreitispossibletohaveAmazonLambdafunctionsbecalledatregularintervals.AsareactiontoanotificationinSNS(SimpleNotificationService)anAmazonLambdafunctioncanbeexecuted.Astherearemanyserviceswhichcanprovidesuchnotifications,thismakesAmazonLambdauseableinmanyscenarios.DynamoDBisadatabasewithintheAmazonCloud.IncaseofchangestothedatabaseitcancallLambdafunctions.SoLambdafunctionsessentiallybecomedatabasetriggers.

EvaluationforNanoservices

AmazonLambdaallowstheindependentdeploymentofdifferentfunctionswithoutproblems.Theycanalsobringtheirownlibrariesalong.

Thetechnologicalexpenditureforinfrastructureisminimalwhenusingthistechnology:AnewversionofanAmazonLambdafunctioncaneasilybedeployedwithacommandlinetool.Monitoringisalsosimple:ThefunctionsareimmediatelyintegratedintoCloudWatch.CloudWatchisofferedbyAmazontocreatemetricsofCloudapplicationsandtoconsolidateandmonitorlogfiles.Inaddition,alarmscanbedefinedbasedonthesedatawhichcanbeforwardedby

SMSoremail.SinceallAmazonservicescanbecontactedviaanAPI,monitoringordeploymentcanbeautomatedandintegratedintotheirowninfrastructures.

AmazonLambdaprovidesintegrationwiththedifferentAmazonservicese.g.S3,KinesisandDynamoDB.ItisalsoeasilypossibletocontactanAmazonLambdafunctionviaRESTusingtheAPIGateway.However,AmazonLambdaexactsthatNode.js,PythonorJavaareused.Thisprofoundlylimitsthetechnologyfreedom.

AmazonLambdaoffersanexcellentisolationoffunctions.Thisisalsonecessarysincetheplatformisusedbymanydifferentusers.ItwouldnotbeacceptableforaLambdafunctionofoneusertonegativelyinfluencetheLambdafunctionsofotherusers.

Conclusion

AmazonLambdaallowstoimplementextremelysmallservices.Theoverheadfortheindividualservicesisverysmall.Independentdeploymentiseasilypossible.APython,JavaScriptorJavafunctionarethesmallestdeploymentunitssupportedbyAmazonLambda–itishardlypossibletomakethemanysmaller.EvenifthereisamultitudeofPython,JavaorJavaScriptfunctions,theexpenditureforthedeploymentsremainsrelativelylow.

AmazonLambdaisapartoftheAmazonecosystem.Therefore,itcanbesupplementedbytechnologieslikeAmazonElasticBeanstalk.ThereMicroservicescanrunwhichcanbelargerandwritteninotherlanguages.Inaddition,acombinationwithEC2(ElasticComputingCloud)ispossible.EC2offersvirtualmachinesonwhichanysoftwarecanbeinstalled.Moreover,thereisabroadchoiceinregardstodatabasesandotherserviceswhichcanbeusedwithlittleadditionaleffort.AmazonLambdadefinesitselfasasupplementofthistoolkit.IntheendoneofthecrucialadvantagesoftheAmazonCloudisthatnearlyeverypossibleinfrastructureisavailableandcaneasilybeused.Thusdeveloperscanconcentrateonthedevelopmentofspecificfunctionalitieswhilemoststandardcomponentscanjustberented.

TryandExperiment

ThereisacomprehensivetutorialwhichillustrateshowtouseAmazonLambda.Itdoesnotonlydemonstratesimplescenarios,butalsoshowshowtousecomplexmechanismssuchasdifferentNode.jslibraries,implementingRESTservicesorhowtoreacttodifferenteventsintheAmazonsystem.Amazonofferscostfreequotasofmostservicestonewcustomers.IncaseofLambdaeachcustomergetssuchalargefreequotathatitisfullysufficientfortestsandafirstgettingtoknowthetechnology.Alsonotethatthefirstmillioncallsduringamontharefree.However,youshouldcheckthecurrentpricing.

15.4OSGiOSGiisastandardwithmanydifferentimplementations.EmbeddedsystemsoftenuseOSGi.AlsothedevelopmentenvironmentEclipseisbasedonOSGi,andmanyJavadesktopapplicationsusetheEclipseframework.OSGidefinesamodularizationwithintheJVM(JavaVirtualMachine).EventhoughJavaallowsforadivisionofcodeintoclassesorpackages,thereisnomodularconceptforlargerunits.

TheOSGiModuleSystem

OSGisupplementsJavabysuchamodulesystem.TodosoOSGiintroducesbundlesintotheJavaworld.BundlesarebasedonJava’sJARfileswhichcomprisecodeofmultipleclasses.BundleshaveanumberofadditionalentriesinthefileMETA-INF/MANIFEST.MF,whicheachJARfileshouldcontain.Theseentriesdefinewhichclassesandinterfacesthebundleexports.Otherbundlescanimporttheseclassesandinterfaces.TherebyOSGiextendsJavawithaquitesophisticatedmoduleconceptwithoutinventingentirelynewconcepts.Listing12:OSGiMANIFEST.MF1Bundle-Name:Aservice

2Bundle-SymbolicName:com.ewolff.service

3Bundle-Description:Asmallservice

4Bundle-ManifestVersion:2

5Bundle-Version:1.0.0

6Bundle-Acltivator:com.ewolff.service.Activator

7Export-Package:com.ewolff.service.interfaces;version="1.0.0"

8Import-Package:com.ewolff.otherservice.interfaces;version="1.3.0"

Listing12showsanexampleofaMANIFEST.MFfile.Itcontainsthedescriptionandnameofthebundleandthebundleactivator.ThisJavaclassisexecuteduponthestartofthebundleandcaninitializethebundle.Export-Packageindicates

whichJavapackagesareprovidedbythisbundle.Allclassesandinterfacesofthesepackagesareavailabletootherbundles.Import-Packageservestoimportpackagesfromanotherbundle.Thepackagescanalsobeversioned.

Inadditiontointerfacesandclassesbundlescanalsoexportservices.However,anentryinMANIFEST.MFisnotsufficientforthis.Codehastobewritten.ServicesareintheendonlyJavaobjects.Otherbundlescanimportandusetheservices.Alsocallingtheserviceshappensinthecode.

Bundlescanbeinstalled,started,stoppedanduninstalledatruntime.Sobundlesareeasytoupdate:Stopanduninstalltheoldversion,theninstallanewversionandstart.However,ifabundleexportsclassesorinterfacesandanotherbundleusesthese,anupdateisnotsosimpleanymore.Allbundleswhichuseclassesorinterfacesoftheoldbundleandnowwanttousethenewlyinstalledbundlehavetoberestarted.

HandlingBundlesinPractice

SharingcodeisbyfarnotasimportantforMicroservicesastheuseofservices.Neverthelessatleasttheinterfaceoftheserviceshastobeofferedtootherbundles.

InpracticeaprocedurehasbeenestablishedwhereabundleonlyexportstheinterfacecodeoftheserviceasclassesandJavainterfaces.Anotherbundlecontainstheimplementationoftheservice.Theclassesoftheimplementationarenotexported.TheserviceimplementationisexportedasOSGiservice.Tousetheserviceabundlehastoimporttheinterfacecodefromtheonebundleandtheservicefromtheotherbundle(compareFig.79).

OSGiallowstorestartservices.Withthedescribedapproachtheimplementationoftheservicecanbeexchangedwithouthavingtorestartotherbundles.ThesebundlesonlyimporttheJavainterfacesandclassesoftheinterfacecode.Thatcodedoesnotchangeforanewserviceimplementationsothatrestartingisnotnecessaryanymore.Thatwaytheaccesstoservicescanbeimplementedinsuchamannerthatthenewversionoftheserviceisinfactused.

WiththeaidofOSGiblueprintsorOSGideclarativeservicesthesedetailscanbeabstractedawaywhendealingwiththeOSGiservicemodel.ThisfacilitatesthehandlingofOSGi.Thesetechnologiesforinstancerenderitmucheasiertohandletherestartofaserviceoritstemporaryfailureduringtherestartofabundle.

Fig.79:OSGiservice,implementationandinterfacecode

Anindependentdeploymentofservicesispossible,butalsolaborioussinceinterfacecodeandserviceimplementationhavetobecontainedindifferentbundles.Thismodelallowsonlychangestotheimplementation.Modificationsoftheinterfacecodearemorecomplex.Insuchacasethebundlesusingaservicehavetoberestartedbecausetheyhavetoreloadtheinterface.

InrealityOSGisystemsareoftencompletelyreinstalledforthesereasonsinsteadofmodifyingindividualbundles.AnEclipseupdateforinstanceoftenentailsarestart.Acompletereinstallationfacilitatesalsothereproductionoftheenvironment.WhenanOSGisystemisdynamicallychanged,atsomepointitwillbeinastatewhichnobodyisabletoreproduce.However,modifyingindividualbundlesisanessentialprerequisiteforimplementingtheNanoserviceapproachwithOSGi.IndependentdeploymentisanessentialpropertyofaNanoservice.SoOSGicompromisesthisessentialproperty.

EvaluationforNanoservices

OSGihasapositiveeffectonJavaprojectsinregardstoarchitecture.Thebundlesareusuallyrelativelysmallsothattheindividualbundlesareeasytounderstand.

Inaddition,thesplitintobundlesforcesthedevelopersandarchitectstothinkabouttherelationshipsbetweenthebundlesandtodefinethemintheconfigurationsofthebundles.Otherdependenciesbetweenbundlesarenotpossiblewithinthesystem.Normallythisleadstoaverycleanarchitecturewithclearandintendeddependencies.

However,OSGidoesnotoffertechnologicalfreedom:ItisbasedontheJVMandthereforecanonlybeusedwithJavaorJVM-basedlanguages.Forexample,itisnearlyimpossiblethatanOSGibundlebringsalongitsowndatabasebecausedatabasesarenormallynotwritteninJava.ForsuchcasesadditionalsolutionsalongsidetheOSGiinfrastructurehavetobefound.

ForsomeJavatechnologiesanintegrationwithOSGiisdifficultsinceloadingJavaclassesworksdifferentlywithoutOSGi.Moreover,manypopularJavaapplicationserversdonotsupportOSGifordeployedapplicationssothatchangingcodeatruntimeisnotsupportedinsuchenvironments.TheinfrastructurehastobespeciallyadaptedforOSGi.

Furthermore,thebundlesarenotfullyisolated:WhenabundleusesalotofCPUorcausestheJVMtocrash,theotherbundlesinthesameJVMwillbeaffected.Failurescanoccurforinstanceduetomemoryleakwhichcausesmoreandmorememorytobeallocatedduetoanerroruntilthesystembreaksdown.Sucherrorseasilyariseduetoblunders.

Ontheotherhand,thebundlescanlocallycommunicateduetoOSGi.Distributedcommunicationisalsopossiblewithdifferentprotocols.Moreover,thebundlesshareaJVMwhichreducesforinstancethememoryutilization.

SolutionsformonitoringarelikewisepresentinthedifferentOSGiimplementations.

Conclusion

OSGileadsfirstofalltorestrictionsinregardstotechnologicalfreedom.ItrestrictstheprojecttoJavatechnologies.Inpracticetheindependentdeploymentofthebundlesishardtoimplement.Especiallyinterfacechangesarepoorlysupported.Besidesbundlesarenotwellisolatedfromeachother.Ontheotherhand,bundlescaneasilyinteractvialocalcalls.

Tryandexperiment

GetfamiliarwithOSGiforinstancewiththeaidofatutorial.

Createaconceptforthedistributionintobundlesandservicesforapartofasystemyouknow.IfyouhadtoimplementthesystemwithOSGi:Whichadditionaltechnologies(databasesetc.)wouldyouhavetouse?Howwouldyouhandlethis?

15.5JavaEEJavaEEisastandardfromtheJavafield.ItcomprisesdifferentAPIssuchasforinstanceJSF(JavaServerFaces),ServletandJSP(JavaServerPages)forwebapplications,JPA(JavaPersistenceAPI)forpersistenceorJTAfortransactions.BesidesJavaEEdefinesadeploymentmodel.WebapplicationscanbepackagedintoWARfiles(WebARchive),JARfiles(JavaARchive)cancontainlogiccomponentslikeEnterpriseJavaBeans(EJBs),andEARs(EnterpriseARchives)cancompriseacollectionofJARsandWARs.Allthesecomponentsaredeployedinoneapplicationserver.TheapplicationserverimplementstheJavaEEAPIsandoffersforinstancesupportforHTTP,threadsandnetworkconnectionsandalsosupportforaccessingdatabases.

ThissectiondealswithWARsandthedeploymentmodelofJavaEEapplicationservers.Chapter14alreadydescribedindetailaJavasystemthatdoesnotrequireanapplicationserver.InsteaditdirectlystartsaJavaapplicationontheJavaVirtualMachine(JVM).TheapplicationispackagedinaJARfileandcontainstheentireinfrastructure.ThisdeploymentiscalledFatJARdeployment,becausetheapplicationincludingtheentireinfrastructureiscontainedinonesingleJAR.Theexamplefromchapter14usesSpringBootwhichalsosupportsanumberofJavaEEAPIssuchasJAX-RSforREST.DropwizardalsoofferssuchaJARmodel.ItisactuallyfocusedonJAXRS-basedRESTwebservices,however,itcanalsosupportotherapplications.WildflySwarmisavariantoftheJavaEEserverWildflywhichalsosupportssuchadeploymentmodel.

NanoserviceswithJavaEE

AFatJARdeploymentutilizestoomanyresourcesforNanoservices.InaJavaEEapplicationservermultipleWARscanbedeployedtherebysavingresources.EachWARcanbeaccessedviaitsownURL.Furthermore,eachWARcanbeindividuallydeployed.ThisallowstobringeachNanoserviceindividuallyintoproduction.

However,theseparationbetweenWARsisnotoptimal:

MemoryandCPUarecollectivelyusedbyallNanoservices.WhenaNanoserviceusesalotofCPUormemory,thiscaninterferewithotherNanoservices.AcrashofoneNanoservicepropagatestoallotherNanoservices.Inpractice,redeploymentofaWARcausesmemoryleaksifitisnotpossibletoremovetheentireapplicationfrommemory.Therefore,inpracticetheindependentdeploymentofindividualNanoservicesishardtoachieve.IncontrasttoOSGitheClassLoadersoftheWARsarecompletelyseparate.ThereisnopossibilityforaccessingthecodeofotherNanoservices.BecauseoftheseparationofthecodeWARscanonlycommunicateviaHTTPorREST.Localmethodcallsarenotpossible.

SincemultipleNanoservicesshareanapplicationserverandaJVM,thissolutionismoreefficientthantheFatJARDeploymentofindividualMicroservicesintheirownJVMasdescribedinchapter14.TheNanoservicesuseasharedheapandtherebyuselessmemory.However,scalingworksonlybystartingmoreapplicationservers.EachoftheapplicationserverscontainsallNanoservices.AllNanoserviceshavetobescaledcollectively.ItisnotpossibletoscaleindividualNanoservices.

ThetechnologychoiceisrestrictedtoJVMtechnologies.BesidesalltechnologiesareexcludedwhichdonotworkwiththeservletmodelsuchasVert.x(section15.6)orPlay.

MicroserviceswithJavaEE?

ForMicroservicesJavaEEcanalsobeanoption:TheoreticallyitwouldbepossibletoruneachMicroserviceinitsownapplicationserver.Inthiscaseanapplicationserverhastobeinstalledandconfiguredinadditiontotheapplication.Theversionoftheapplicationserveranditsconfigurationhavetofittotheversionoftheapplication.ForFatJARdeploymentthereisnoneedforaspecificconfigurationoftheapplicationserverbecauseitispartoftheFatJAR

andthereforeconfiguredjustliketheapplication.Thisadditionalcomplexityoftheapplicationserverisnotcounterbalancedbyanyadvantage.SincedeploymentandmonitoringoftheapplicationserveronlyworkforJavaapplications,thesefeaturescanonlybeusedinaMicroservices-basedarchitecturewhenthetechnologychoiceisrestrictedtoJavatechnologies.Ingeneral,applicationservershavehardlyanyadvantages–especiallyforMicroservices.

Anexample

Theapplicationfromchapter14isalsoavailablewiththeJavaEEdeploymentmodel.Fig.80providesanoverviewoftheexample:TherearethreeWARs,whichcompriseorder,customerandcatalog.TheycommunicatewitheachotherviaREST.Whencustomerfails,orderwouldalsofailinthehostsinceordercommunicatesonlywiththissinglecustomerinstance.Toachievebetteravailability,theaccesswouldhavetobereroutedtoothercustomerinstances.

AcustomercanusetheUIoftheNanoservicesfromtheoutsideviaHTML/HTTP.Thecodecontainsonlysmallmodificationscomparedtothesolutionfromchapter14.TheNetflixlibrarieshavebeenremoved.Ontheotherhand,theapplicationhasbeenextendedwithsupportforservletcontainers.

Fig.80:ExampleapplicationwithJavaEENanoservices

TryandExperiment

TheapplicationasJavaEENanoservicescanbefoundonGitHub.

TheapplicationdoesnotusetheNetflixtechnologies.

HystrixoffersResilience(comparesection14.10).

DoesitmakesensetointegrateHystrixintotheapplication?HowaretheNanoservicesisolatedfromeachother?IsHystrixalwayshelpful?Comparealsosection10.5concerningstabilityandresilience.Howcanthesepatternsbeimplementedinthisapplication?

Eurekaishelpfulforservicediscovery.HowwoulditfitintotheJavaEENanoservices?Howcanotherservicediscoverytechnologiesbeintegrated(comparesection8.9)?

RibbonforloadbalancingbetweenRESTservicescouldlikewisebeintegrated.Whichadvantageswouldthathave?WoulditalsobepossibletouseRibbonwithoutEureka?

15.6Vert.xVert.xisaframeworkcontainingnumerousinterestingapproaches.Althoughitrunsonthe(JavaVirtualMachine),itsupportsmanydifferentprogramminglanguages–suchasJava,Scala,Clojure,Groovy,CeylonaswellasJavaScript,RubyorPython.AVert.xsystemisbuiltfromVerticles.Theyreceiveeventsandcanreturnmessages.

Listing13showsasimpleVert.xVerticle,whichonlyreturnstheincomingmessages.Thecodecreatesaserver.Whenaclientconnectstotheserver,acallbackiscalled,andtheservercreatesapump.Thepumpservestotransferdatafromasourcetoatarget.Intheexamplesourceandtargetareidentical.

Theapplicationbecomesonlyactivewhenaclientconnectsandthecallbackiscalled.Likewise,thepumpbecomesonlyactivewhennewdataareavailable

fromtheclient.SucheventsareprocessedbytheeventloopwhichcallstheVerticles.TheVerticlesthenhavetoprocesstheevents.Aneventloopisathread.UsuallyoneeventloopisstartedperCPUcoresothattheeventloopsareprocessedinparallel.Aneventloopandthusathreadresp.aCPUcorecansupportanarbitrarynumberofnetworkconnections.Eventsofallconnectionscanbeprocessedinasingleeventloop.Therefore,Vert.xisalsosuitableforapplicationswhichhavetohandlealargenumberofnetworkconnections.Listing13:SimpleJavaVert.xEchoVerticle

1publicclassEchoServerextendsVerticle{

2

3publicvoidstart(){

4vertx.createNetServer().connectHandler(newHandler<NetSocket>(){

5publicvoidhandle(finalNetSocketsocket){

6Pump.createPump(socket,socket).start();

7}

8}).listen(1234);

9}

10}

AsdescribedVert.xsupportsdifferentprogramminglanguages.Listing14showsthesameEchoVerticleinJavaScript.ThecodeadherestoJavaScriptconventionsandusesforinstanceaJavaScriptfunctionforcallback.Vert.xhasalayerforeachprogramminglanguagethatadaptsthebasicfunctionalityinsuchawaythatitseemslikeanativelibraryfortherespectiveprogramminglanguage.Listing14:SimpleJavaScriptVert.xEchoVerticle1varvertx=require('vertx')

2

3vertx.createNetServer().connectHandler(function(sock){

4newvertx.Pump(sock,sock).start();

5}).listen(1234);

Vert.xmodulescancontainmultipleVerticlesindifferentlanguages.Verticlesandmodulescancommunicatewitheachotherviaaneventbus.ThemessagesontheeventbususeJSONasdataformat.Theeventbuscanbedistributedontomultipleservers.InthismannerVert.xsupportsdistributionandcanimplementhighavailabilitybystartingmodulesonotherservers.BesidestheVerticlesandmodulesarelooselycoupledsincetheyonlyexchangemessages.Vert.xalsoofferssupportforothermessagingsystemsandcanalsocommunicatewithHTTPandREST.SoitisrelativelyeasytointegrateVert.xsystemsintoMicroservice-basedsystems.

Modulescanbeindividuallydeployedandalsoremovedagain.Sincethemodulescommunicatewitheachotherviaevents,modulescanbeeasilyreplacedbynewmodulesatruntime.Theyonlyhavetoprocessthesamemessages.AmodulecanimplementaNanoservice.ModulescanbestartedinnewnodessothatthefailureofaJVMcanbecompensated.

Vert.xsupportsalsoFatJARswheretheapplicationbringsallnecessarylibrariesalong.ThisisusefulforMicroservicessincethismeansthattheapplicationbringsalldependenciesalongandiseasiertodeploy.ForNanoservicesthisapproachisnotsousefulbecausetheapproachconsumestoomanyresource-deployingmultipleVert.xmodulesinoneJVMisabetteroptionforNanoservices.

Conclusion

ViatheindependentmoduledeploymentandtheloosecouplingbytheeventbusVert.xsupportsmultipleNanoserviceswithinaJVM.However,acrashoftheJVM,amemoryleakorblockingtheeventloopwouldaffectallmodulesandVerticlesintheJVM.Ontheotherhand,Vert.xsupportsmanydifferentprogramminglanguages–inspiteoftherestrictiontoJVM.Thisisnotonlyatheoreticaloption.InfactVert.xaimsatbeingeasilyuseableinallsupportedlanguages.Vert.xpresumesthattheentireapplicationiswritteninanonblockingmanner.However,thereisthepossibilitytoexecuteblockingtasksinWorkerVerticles.TheyuseseparatethreadpoolssothattheydonotinfluencethenonblockingVerticles.SoevencodethatdoesnotsupporttheVert.xnonblockingapproachcanstillbeusedinaVert.xsystem.Thisallowsforevengreatertechnologicalfreedom.

TryandExperiment

TheVert.xhomepageoffersaneasystarttodevelopingwithVert.x.Itdemonstrateshowawebservercanbeimplementedandexecutedwithdifferentprogramminglanguages.ThemodulesintheexampleuseJavaandMaven.Therearealsocomplexexamplesinotherprogramminglanguages.

15.7ErlangErlangisafunctionalprogramminglanguagewhichisfirstofallusedincombinationwiththeOTP(OpenTelecomPlatform)framework.Originally,Erlanghasbeendevelopedfortelecommunication.Inthisfieldapplicationshavetobeveryreliable.MeanwhileErlangisemployedinallareaswhichprofitfrom

itsstrengths.ErlangusesavirtualmachinesimilartoJavaasruntimeenvironmentwhichiscalledBEAM(Bogdan/Björn’sErlangAbstractMachine).

Erlang’sstrengthsarefirstofallitsresilienceagainstfailuresandthepossibilitytoletsystemsrunforyears.Thisisonlypossibleviadynamicsoftwareupdates.AtthesametimeErlanghasalight-weightconceptforparallelism.Erlangusestheconceptofprocessesforparallelcomputing.Theseprocessesarenotrelatedtooperatingsystemprocessesandareevenmorelight-weightthanoperatingsystemthreads.InanErlangsystemmillionsofprocessescanrunwhichareallisolatedfromeachother.

Anotherfactorcontributingtotheisolationistheasynchronouscommunication.ProcessesinanErlangsystemcommunicatewitheachotherviamessages.Messagesaresenttothemailboxofaprocess(seeFig.81).Inoneprocessonlyonemessageisprocessedatatime.Thisfacilitatesthehandlingofparallelism:Thereisparallelexecutionbecausemanymessagescanbehandledatthesametime.Buteachprocesstakescareofonlyonemessageatatime.Parallelismisachievedbecausetherearemultipleprocesses.Thefunctionalapproachofthelanguage,whichattemptstogetbywithoutastate,fitswelltothismodel.ThisapproachcorrespondstotheVerticlesinVert.xandtheircommunicationviatheeventbus.

Fig.81:CommunicationbetweenErlangprocesses

Listing15showsasimpleErlangserverwhichreturnsthereceivedmessage.Itisdefinedinitsownmodule.Themoduleexportsthefunctionloop,whichdoesnothaveanyparameters.ThefunctionreceivesamessageMsgfromanodeFromandthenreturnsthesamemessagetothisnode.Theoperator“!”servesforsendingthemessage.Afterwardsthefunctioniscalledagainandwaitsforthenextmessage.Exactlythesamecodecanalsobeusedforbeingcalledbyanothercomputerviathenetwork.Localmessagesandmessagesviathenetworkareprocessedbythesamemechanisms.Listing15:AnErlangechoserver

1-module(server).

2-export([loop/0]).

3loop()->

4receive

5{From,Msg}->

6From!Msg,

7loop()

8end.

DuetothesendingofmessagesErlangsystemsareespeciallyrobust.Erlangmakesuseof“LetItCrash”.Anindividualprocessisjustrestartedwhenproblemsoccur.Thisistheresponsibilityofthesupervisor:Aprocesswhichisspecificallydedicatedtomonitoringotherprocessesandrestartingthemifnecessary.Thesupervisoritselfisalsomonitoredandrestartedincaseofproblems.TherebyatreeiscreatedinErlangwhichintheendpreparesthesystemforthecasethatprocessesshouldfail(seeFig.82).

Fig.82:MonitoringinErlangsystems

SincetheErlangprocessmodelissolight-weight,restartingaprocessisrapidlydone.Whenthestateisstoredinothercomponents,therewillalsobenoinformationloss.Theremainderofthesystemisnotaffectedbythefailureoftheprocess:Asthecommunicationisasynchronous,theotherprocessescanhandlethehigherlatencycausedbytherestart.Inpracticethisapproachhasprovenveryreliable.Erlangsystemsareveryrobustandstilleasytodevelop.

Thisapproachisbasedontheactormodel:Actorscommunicatewitheachotherviaasynchronousmessages.Asaresponsetheycanthemselvessendmessages,startnewactorsorchangetheirbehaviorforthenextmessages.Erlang’sprocessescorrespondtoactors.

Inaddition,thereareeasypossibilitiestomonitorErlangsystems.Erlangitselfhasbuilt-infunctionswhichcanmonitormemoryutilizationorthestateofthe

mailboxes.OTPoffersforthispurposetheOperationsandMaintenanceSupport(OAM),whichcanforinstancealsobeintegratedintoSNMPsystems.

SinceErlangsolvestypicalproblemsarisingupontheimplementationofMicroserviceslikeresilience,itsupportstheimplementationofMicroservicesquitewell.InthatcaseaMicroserviceisasystemwritteninErlangwhichinternallyconsistsofmultipleprocesses.

However,theservicescanalsogetsmaller:EachprocessinanErlangsystemcouldbeconsideredasNanoservice.Itcanbedeployedindependentlyoftheothers,evenduringruntime.Furthermore,Erlangsupportsoperatingsystemprocesses.Inthatcasetheyarealsointegratedintothesupervisorhierarchyandrestartedincaseofabreakdown.ThismeansthatanyoperatingsystemprocesswritteninanylanguagemightbecomeapartofanErlangsystemanditsarchitecture.

EvaluationforNanoservices

AsdiscussedanindividualprocessinErlangcanbeviewedasNanoservice.Theexpenditurefortheinfrastructureisrelativelysmallinthatcase:Monitoringispossiblewithbuilt-inErlangfunctions.Thesameistruefordeployment.SincetheprocessesshareaBEAMinstance,theoverheadforasingleprocessisnotveryhigh.Inaddition,itispossiblefortheprocessestoexchangemessageswithouthavingtocommunicateviathenetworkandthereforewithlittleoverhead.Theisolationofprocessesisalsoimplemented.

Finally,evenprocessesinotherlanguagescanbeaddedtoanErlangsystem.ForthispurposeanoperatingsystemprocesswhichcanbeimplementedinanarbitrarylanguageisputunderthecontrolofErlang.Theoperatingsystemprocesscanforinstancebesafeguardedby“LetItCrash”.ThisallowstointegratepracticallyalltechnologiesintoErlang–eveniftheyruninaseparateprocess.

Ontheotherhand,Erlangisnotverycommon.Theconsequentfunctionalapproachalsoneedsgettingusedto.Finally,theErlangsyntaxisnotveryintuitiveformanydevelopers.

TryandExperiment

Averysimpleexampleisbasedonthecodefromthissectionanddemonstrateshowcommunicationbetweennodesispossible.YoucanuseittogetabasicunderstandingofErlang.

ThereisaverynicetutorialforErlang,whichalsotreatsdeploymentandoperation.Withtheaidoftheinformationfromthetutorialtheexamplecanbesupplementedbyasupervisor.

AnalternativelanguageoutoftheErlangecosystemisElixir.Elixirhasadifferentsyntax,butalsoprofitsfromtheconceptsofOTP.ElixirismuchsimplertolearnthanErlangandthuslendsitselftoafirststart.

Therearemanyotherimplementationsoftheactormodel.ItisworthwhiletolookmorecloselybeforedecidingwhethersuchtechnologiesarealsousefulfortheimplementationofMicroservicesorNanoservicesandwhichadvantagesmightbeassociated.AkkafromtheScala/Javaareamightbeofinteresthere.

15.8SenecaSenecaisbasedonNode.jsandaccordinglyusesJavaScriptontheserver.Node.jshasaprogrammingmodelwhereoneoperatingsystemprocesscantakecareofmanytasksinparallel.Toachievethisthereisaneventloopwhichhandlestheevents.Whenamessageentersthesystemviaanetworkconnection,thesystemwillfirstwaituntiltheeventloopisfree.Thentheeventloopprocessesthemessage.Theprocessinghastobefastsincetheloopisblockedotherwiseresultinginlongwaitingtimesforallothermessages.Forthisreason,theresponseofotherserversmayinnocasebewaitedforintheeventloop.Thatwouldblockthesystemfortoolong.Theinteractionwithothersystemshastobeimplementedinsuchawaythattheinteractionisonlyinitiated.Thentheeventloopisfreedtohandleotherevents.Onlywhentheresponseoftheothersystemarrives,itisprocessedbytheeventloop.Thentheeventloopcallsacallbackwhichhasbeenregisteredupontheinitiationoftheinteraction.ThismodelissimilartotheapproachesusedbyVert.xandErlang.

SenecaintroducesamechanisminNode.jswhichallowstoprocesscommands.Patternsofcommandsaredefinedwhichcausecertaincodetobeexecuted.

Communicatingviasuchcommandsisalsoeasytodoviathenetwork.Listing16showsaserverwhichcallsseneca.add().Therebyanewpatternandcodeforhandlingeventswiththispatternaredefined.Tothecommandwiththecomponentcmd:“echo”afunctionreacts.Itreadsoutthevaluefromthecommandandputsitintothevalueparameterofthefunctioncallback.Thenthefunctioncallbackiscalled.Withseneca.listen()theserverisstartedandlistenstocommandsfromthenetwork.Listing16:SenecaServer

1varseneca=require("seneca")()

2

3seneca.add({cmd:"echo"},function(args,callback){

4callback(null,{value:args.value})

5})

6

7seneca.listen()

TheclientinListing17sendsallcommandswhichcannotbeprocessedlocallyviathenetworktotheserver.seneca.client().seneca.act()createsthecommandsthataresenttotheserver.Itcontainscmd:“echo”–thereforethefunctionoftheserverinListing16iscalled.“echothis”isusedasvalue.Theserverreturnsthisstringtothefunctionwhichwaspassedinasacallback–andinthiswayitisfinallyprintedontheconsole.TheexamplecodecanbefoundonGitHub.Listing16:SenecaClient1varseneca=require("seneca")()

2

3seneca.client()

4

5seneca.act('cmd:"echo",value:"echothis",function(err,result){

6console.log(result.value)

7})

Therefore,itisveryeasytoimplementadistributedsystemwithSeneca.However,theservicesdonotuseastandardprotocollikeRESTforcommunicating.Nevertheless,alsoRESTsystemscanbeimplementedwithSeneca.BesidestheSenecaprotocolisbasedonJSONandthereforecanalsobeusedbyotherlanguages.

ANanoservicecanbeafunctionwhichreactswithSenecatocallsfromthenetwork–andthereforeitcanbeverysmall.Asalreadydescribed,aNode.jssystemasimplementedwithSenecaisfragilewhenafunctionblockstheeventloop.Therefore,theisolationisnotverygood.

ForthemonitoringofaSenecaapplicationthereisanadminconsolewhichatleastoffersasimplemonitoring.However,itisineachcaseonlyavailableforoneNode.jsprocess.Monitoringacrossallservershastobeachievedbydifferentmeans.

AnindependentdeploymentofasingleSenecafunctionisonlypossibleifthereisasingleNode.jsprocessfortheSenecafunction.ThisrepresentsaprofoundlimitationforindependentdeploymentsincetheexpenditureofaNode.jsprocessishardlyacceptableforasingleJavaScriptfunction.Inaddition,itisnoteasytointegrateothertechnologiesintoaSenecasystem.IntheendtheentireSenecasystemhastobeimplementedinJavaScript.

EvaluationforNanoservices

SenecahasbeenespeciallydevelopedfortheimplementationofMicroserviceswithJavaScript.Infact,itenablesaverysimpleimplementationforserviceswhichcanalsobecontactedviathenetwork.ThebasicarchitectureissimilartoErlang:Inbothapproachesservicessendmessagesresp.commandstoeachothertowhichfunctionsreact.Inregardstotheindependentdeploymentofindividualservices,theisolationofservicesfromeachotherandtheintegrationofothertechnologiesErlangisclearlysuperior.BesidesErlanghasamuchlongerhistoryandhaslongbeenemployedindifferentverydemandingapplications.

TryandExperiment

ThecodeexamplecanbeafirststeptogetfamiliarwithSeneca.Youcanalsousethebasictutorial.Inaddition,itisworthwhiletolookatotherexamples.TheNanoserviceexamplecanbeenlargedtoacomprehensiveapplicationorcanbedistributedtoalargernumberofNode.jsprocesses.

15.9ConclusionThetechnologiespresentedinthischaptershowhowMicroservicescanalsobeimplementedverydifferently.Sincethedifferenceissolarge,theuseoftheseparateterm“Nanoservice”appearsjustified.Nanoservicesarenotnecessarily

independentprocessesanymorewhichcanonlybecontactedviathenetwork,butmightruntogetherinoneprocessanduselocalcommunicationmechanismstocontacteachother.Therebynotonlytheuseofextremelysmallservicesispossible,butalsotheadoptionofMicroserviceapproachesinareassuchasembeddedordesktopapplications.

AnoverviewoftheadvantagesanddisadvantagesofdifferenttechnologiesinregardstoNanoservicesisprovidedinTab.3.ErlangisthemostinterestingtechnologysinceitalsoallowstheintegrationofothertechnologiesandisabletoisolatetheindividualNanoservicesquitewellfromeachothersothataprobleminoneNanoservicewillnottriggerthefailureoftheotherservices.Inaddition,Erlanghasbeenthebasisofmanyimportantsystemsforalongtimealreadysothatthetechnologyassuchhasprovenitsreliabilitybeyonddoubt.

Senecafollowsasimilarapproach,butcannotcompetewithothertechnologiesintermsofisolationandtheintegrationofothertechnologiesthanJavaScript.Vert.xhasasimilarapproachontheJVMandsupportsnumerouslanguages.However,itdoesnotisolateNanoservicesaswellasErlang.JavaEEdoesnotallowforcommunicationwithoutnetwork,andindividualdeploymentisdifficultinJavaEE.InpracticememoryleaksoccurfrequentlyduringthedeploymentofWARs.Soduringadeploymenttheapplicationserverisusuallyrestartedtoavoidmemoryleaks.ThenallNanoservicesareunavailableforsometime.ThereforeaNanoservicecannotbedeployedwithoutinfluencingtheotherNanoservices.OSGiallowsincontrasttoJavaEEtheshareduseofcodebetweenNanoservices.Inaddition,OSGiusesmethodscallsforcommunicationbetweenservicesandnotcommandsresp.messageslikeErlangandSeneca.Commandsormessageshavetheadvantageofbeingmoreflexible.Partsofamessagewhichacertainservicedoesnotunderstandarenotaproblem-theycanjustbeignored.

Tab.3:TechnologyevaluationforNanoservices Lambda OSGi JavaEE Vert.x Erlang SenecaEffortforinfrastructure ++ + + + ++ ++perservice Resourceconsumption ++ ++ ++ ++ ++ ++Communication - ++ -- + ++ -withnetwork Isolation ++ -- -- - ++ -ofservices Useofdifferent - -- -- + + --

technologies

AmazonLambdaisespeciallyinterestingsinceitisintegratedintotheAmazonecosystem.Thismakeshandlingtheinfrastructureveryeasy.TheinfrastructurecanbeachallengingproblemincaseofsmallNanoservicesbecausesomanymoreenvironmentsareneededduetothehighnumberofservices.WithAmazonadatabaseserverisonlyanAPIcalloraclickaway–alternatively,anAPIcanbeusedtostoredatainsteadofaserver.Serversbecomeinvisibleforstoringdata–andthisisalsothecasewithAmazonLambdaforexecutingcode.Thereisnoinfrastructureforanindividualservice,butonlycodewhichisexecutedandcanbeusedbyotherservices.Becauseofthepreparedinfrastructuremonitoringisalsonochallengeanymore.

EssentialPoints

Nanoservicesdividesystemsintoevensmallerservices.Toachievethis,theycompromiseincertainareassuchastechnologyfreedomorisolation.NanoservicesrequireefficientinfrastructureswhichcanhandlealargenumberofsmallNanoservices.

16HowtoStartwithMicroservices

AsconclusionofthebookthischaptershowswhatthestartwithMicroservicescanlooklike.Section16.1enumeratesthedifferentadvantagesofMicroservicesoncemoretoillustratethatthereisnotonlyasinglereasontointroduceMicroservices,butseveral.Section16.2describesseveralwaysforintroducingMicroservices–dependingontheusecontextandtheexpectedadvantages.Section16.3finallyfollowsuponthequestionwhetherMicroservicesaremorethanjustahype.

16.1WhyMicroservices?Microservicesentailanumberofadvantagessuchas(comparealsochapter5):

Microservicesmakeiteasiertoimplementagilityforlargeprojectssinceteamscanworkindependently.Microservicescanhelptosupplementandreplacelegacyapplicationsstepwise.Microservice-basedarchitecturesallowforsustainabledevelopmentsincetheyarelesssusceptibletoarchitecturedecayandbecauseindividualMicroservicescanbeeasilyreplaced.Thisincreasesthelong-termmaintainabilityofthesystem.Inaddition,therearetechnicalreasonsforMicroservicessuchasrobustnessandscalability.

Toprioritizetheseadvantagesandtheadditionalonesmentionedinchapter5shouldbethefirststepwhenconsideringtheadaptationofaMicroservice-basedarchitecture.Likewisethechallengesdiscussedinchapter6havetobeevaluatedand,wherenecessary,strategiesfordealingwiththesechallengeshavetobedevised.

ContinuousDeliveryandinfrastructureplayaprominentroleinthiscontext.Ifthedeploymentprocessesarestillmanual,theexpenditureforoperatingalargenumberofMicroservicesissohighthattheirintroductionishardlyfeasible.Unfortunately,manyorganizationsstillhaveprofoundweaknessesespeciallyintheareaofContinuousDeliveryandinfrastructure.InsuchacaseContinuous

DeliveryshouldbeintroducedalongsideMicroservices.SinceMicroservicesaremuchsmallerthanDeploymentMonoliths,ContinuousDeliveryisalsoeasierwithMicroservices.Therefore,bothapproacheshavesynergies.

Inadditiontheorganizationallevel(chapter13)hastobetakenintoaccount.WhenthescalabilityofagileprocessesconstitutesanimportantreasonforintroducingMicroservices,theagileprocessesshouldalreadybewellestablished.Forexample,therehastobeaProductOwnerperteam,whoalsodecidesaboutallfeatures,aswellasagileplanning.Theteamsshouldalsobealreadylargelyself-reliant–otherwiseintheendtheymightnotmakeuseoftheindependenceMicroservicesoffer.

IntroducingMicroservicescansolvemorethanjustoneproblem.ThespecificmotivationforMicroserviceswilldifferbetweenprojects.ThelargenumberofadvantagescanonitsownbeagoodreasonforintroducingMicroservices.IntheendthestrategyforintroducingMicroserviceshastobeadaptedtotheadvantagesthataremostimportantinthecontextofaspecificproject.

16.2RoadstowardsMicroservicesTherearedifferentapproacheswhichpavethewaytowardsMicroservices:

ThemosttypicalscenarioistostartoutwithamonolithwhichisconvertedstepwiseintoamultitudeofMicroservices.Usually,differentfunctionalitiesaretransferredonebyoneintoMicroservices.Adrivingforcebehindthisconversionisoftenthewishforaneasierdeployment.However,independentscalingandachievingamoresustainablearchitecturecanalsobeimportantreasons.However,migratingfromamonolithtoMicroservicescanalsooccurinadifferentmanner.WhenforinstanceresilienceisthemainreasonforswitchingtoMicroservices,themigrationcanbestartedbyfirstaddingtechnologieslikeHystrixtothemonolith.AfterwardsthesystemcanbesplitintoMicroservices.StartingaMicroservice-basedsystemfromscratchisbyfartherarerscenario.Eveninsuchacaseaprojectcanstartbybuildingamonolith.However,itismoresensibletodeviseafirstcoarse-graineddomainarchitecturewhichleadstothefirstMicroservices.TherebyaninfrastructureiscreatedwhichsupportsmorethanjustoneMicroservice.Thisapproachalsoallowsteamstoalreadyworkindependentlyonfeatures.However,a

fine-granulardivisionintoMicroservicesrightfromthestartoftendoesnotmakesensebecauseitwillprobablyhavetoberevisedagainlateron.IntroducingthenecessaryprofoundchangesintoanalreadyexistingMicroservicesarchitecturecanbehighlycomplex.

Microservicesareeasytocombinewithexistingsystemswhichfacilitatestheirintroduction.AsmallMicroserviceassupplementtoanexistingDeploymentMonolithisrapidlywritten.Ifproblemsarise,suchaMicroservicecanalsoberapidlyremovedagainfromthesystem.Othertechnicalelementscanthenbeintroducedinastepwisemanner.

TheeasycombinationofMicroserviceswithlegacysystemsisanessentialreasonforthefactthattheintroductionofMicroservicesisquitesimpleandcanimmediatelyresultinadvantages.

16.3Microservice:HypeorReality?WithoutdoubtMicroservicesareanapproachwhichisinthefocusofattentionrightnow.Thisdoesnothavetobebad–yet,suchapproachesoftenareatsecondglanceonlyafashionanddonotsolveanyrealproblems.

However,theinterestinMicroservicesismorethanjustafashionorhype:

Asdescribedintheintroduction,AmazonhasbeenemployingMicroservicesformanyyears.Likewise,manyinternetcompanieshavebeenfollowingthisapproachforalongtime.Therefore,Microservicesarenotjustanewfashion,buthavealreadybeenusedforalongtimebehindthescenesinmanycompaniesbeforetheybecamefashionable.FortheMicroservicepioneerstheadvantagesassociatedwithMicroservicesweresoprofoundthattheywerewillingtoinvestalotofmoneyintocreatingthenotyetexistingnecessaryinfrastructures.TheseinfrastructuresarenowadaysavailablefreeofcostasOpenSource–Netflixisaprominentexample.Therefore,itismucheasiernowadaystointroduceMicroservices.ThetrendtowardsagilityandCloudinfrastructuresissuitablycomplementedbyMicroservices-basedarchitectures:TheyenablethescalingofagilityandfulfillthedemandsoftheCloudinregardstorobustnessandscalability.LikewiseMicroservicesassmalldeploymentunitssupportContinuousDeliverywhichisemployedbymanyenterprisestoincreasesoftwarequalityandtobringsoftwaremorerapidlyintoproduction.

ThereismorethanonereasonforMicroservices.Therefore,Microservicesrepresentanimprovementformanyareas.SincethereisnotasinglereasonfortheintroductionofMicroservices,butanumberofthem,itismorelikelythatevenverydiverseprojectswillintheendreallybenefitfromswitchingtoMicroservices.

Presumably,everybodyhasalreadyseenlarge,complexsystems.Maybeitisnowthetimetodevelopsmallersystemsandtoprofitfromtheassociatedadvantages.Inanycasethereseemtobeonlyveryfewreasonsarguingformonoliths–exceptfortheirlowertechnicalcomplexity.

16.4ConclusionIntroducingMicroservicesmakessenseforanumberofreasons:

Thereisaplethoraofadvantages(discussedinsection16.1andchapter5).ThewaytoMicroservicesisevolutionary.ItisnotnecessarytostartadoptingMicroservicesforthewholesystemfromthebeginning.Quiteincontrast:Astepwisemigrationistheusualway(section16.2).ManydifferentapproachescanbechoseninordertoprofitasquicklyaspossiblefromtheadvantagesMicroservicesoffer.Thestartisreversible:IfMicroservicesprovenottobesuitableforacertainproject,theycaneasilybereplacedagain.Microservicesareclearlymorethanahype(section16.3).Forbeingjustahypetheyhavebeeninusefortoolongandhavebeentoobroadlyadapted.Therefore,oneshouldatleastexperimentwithMicroservices–andthisbooksinvitesthereaderinmanyplacestodojustthat.

TryandExperiment

Answerthefollowingquestionsforanarchitecture/systemyouarefamiliarwith:

WhicharethemostimportantadvantagesofMicroservicesinthiscontext?HowcouldamigrationtoMicroservicesbeachieved?Possibleapproaches:

ImplementnewfunctionalitiesinMicroservicesEnablecertainproperties(e.g.robustnessorrapiddeployment)viasuitabletechnologies

WhatcouldaprojectlooklikewhichteststheintroductionofMicroserviceswithaslittleexpenditureaspossible?

InwhichcasewouldthisprojectbeasuccessandtheintroductionofMicroservicesthereforesensible?