Top Banner
Micro- Services DevOps Distributed Systems
67

Micro- Services DevOps Distributed Systems

Feb 13, 2017

Download

Documents

trinhxuyen
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Micro- Services DevOps Distributed Systems

Micro-Services

DevOpsDistributedSystems

Page 2: Micro- Services DevOps Distributed Systems

Microservices andScienceGateways

Page 3: Micro- Services DevOps Distributed Systems

MartinFowler’sDefinition

• Developasingleapplicationasasuiteofsmallservices• Eachservicerunsinitsownprocess• Services communicatewithlightweightmechanisms

• “Often anHTTPresourceAPI”• Butthathassomeproblems• Messagingisbetter.

• Theseservicesarebuiltaroundbusinesscapabilities• Independentlydeployablebyfullyautomateddeploymentmachinery.• Minimumofcentralizedmanagementoftheseservices,

• Maybewrittenindifferentprogramminglanguages• Mayusedifferentdatastoragetechnologies.

http://martinfowler.com/articles/microservices.html

Page 4: Micro- Services DevOps Distributed Systems

MonolithicApplications

•aclient-sideuserinterface•adatabase•aserver-sideapplication.

Enterprise applicationsthree tieredarchitecture

•handleHTTPrequests,•executedomainlogic,•retrieveandupdatedatafromthedatabase,•selectandpopulateHTMLviewstobesenttothebrowser.

Server-side Application

•Asinglelogicalexecutable.•Changesrequirebuildinganddeployinganewversionoftheserver-sideapplication.

Thisserver-sideapplicationisamonolith

Page 5: Micro- Services DevOps Distributed Systems

OtherQuestionableMonolithicPatterns

• Theserver-sideapplicationinteractswithasingledatabase• NoteverythingneedstofitintooneDBsystem• NotjustCAPchoices:usetheDBthatfitseachsubsytem’s problemandyourdevelopmentpatterns

• Splittingteamsintotiers• TheDBteam,theUXteam,theServerAppteam• Thedeploymentandoperationsteam

CAP:Consistency-Availability-PartitionTolerance

Page 6: Micro- Services DevOps Distributed Systems

Browser

Web InterfaceServer

Application Server

ServerSDK

Client SDK

Karst:MOAB/Torque

ResourcePlugins

Stampede:SLURM

Comet:SLURM Jureca:SLURM

HTTPS

HTTPorTCP/IP

RecalltheGatewayOctopusDiagram

“Super”SchedulingandResourceManagement

Inmicro-servicearch,thesealsoneedscheduling

Page 7: Micro- Services DevOps Distributed Systems

APIServer

ApplicationManager

MetadataServerApplication

ManagerApplicationManagerApplicationManagerApplicationManagerApplicationManager

MetadataServerMetadataServerMetadataServerMetadataServerMetadataServer

APIServerAPIServerAPIServer

APIServer

ApplicationManager

MetadataServer

DecouplingtheApp

Server,Take1

Page 8: Micro- Services DevOps Distributed Systems

WhatScienceGatewayMicroservices CanWeIdentify?

Page 9: Micro- Services DevOps Distributed Systems

MySuggestedList(1/2)

• APIServer• Highavailability,load-balancedEntryPoint

• Scheduler• HighlyavailableleaderOrchestrator

• Resources,Applications• Highlyavailable?

StatelessMetadataServer

Page 10: Micro- Services DevOps Distributed Systems

MySuggestedList(2/2)

• Experiment stateStatefulMetadataServer

• Submitsjobs• FireandforgetApplicationManager

• MonitorsjobsonremoteresourcesMonitorService

• Centralizeyourservice logsLogging

Page 11: Micro- Services DevOps Distributed Systems

DrawandThink

Page 12: Micro- Services DevOps Distributed Systems

ThoughtExercise

• AssumeAmazonCloudandabigbudget• Howdothesecomponentsinteract?• HowcanIdistributecopiesofcomponentsacrossmultipleavailabilityzones?

• Whatkindsoffailurescanoccur?• HowcanIhandlefailuresofdifferentcomponents?

Page 13: Micro- Services DevOps Distributed Systems

LastThoughts:AreMonolithicApplicationsBad?• Amonolithicserverisanaturalwaytoapproachbuildingmanysystems.• Monolithicapplicationscanandshouldstillbemodular• Allyourlogicforhandlingarequestrunsinasingleprocess

• Youcanusethebasicfeaturesofyourlanguage todivideuptheapplicationintoclasses,functions,andnamespaces.

• MonolithscanstilluseDevOps• Youcanrunandtesttheapplicationonadeveloper'slaptop,• Useadeploymentpipeline toensurethatchangesareproperlytestedanddeployedintoproduction.

• Youcanhorizontallyscalethemonolithbyrunningmanyinstancesbehindaload-balancer.

• DBCAPproblemsdon’thitmostapplications

Page 14: Micro- Services DevOps Distributed Systems

TheDividingLine

Whendoyoudecoupleyourcode?Whenisamonolithicapplicationbetter?

Page 15: Micro- Services DevOps Distributed Systems

MonolithicApplications:TraditionalSoftwareReleases• Softwarereleasesoccurindiscreteincrements• Runonclients’systems• Releasesmaybefrequentbuttheyarestilldistinct

• Firefox• OSsystemupgrades

• Traditionalreleasecycles• Extensive testing• Alpha,beta,release candidates,andfullreleases

• Extensiverecompilingandtestingrequiredaftercodechanges• Codechangesrequiretheentirereleasecycletoberepeated

Page 16: Micro- Services DevOps Distributed Systems

MicroServices:SoftwareasaService

• Doesyoursoftwarerunasaservice?• Doyourunthisserviceyourself?Ordoesanotherpartofyourorganizationruntheservicethatyourteamdevelops?

• Traditionalreleasecyclesdon’tworkwell• Test-release-deploy takestoolong• Maymakereleasesmanytimesperday

• Youcanbealittlemoretolerantofbugsdiscoveredafterreleaseifyoucanfixquicklyorrollbackquickly.

• Getnewfeaturesandimprovementsintoproductionquickly.

Page 17: Micro- Services DevOps Distributed Systems

Microservices:StartwithModularity

• Thinkaboutyourcurrentapplication.• Howcanyoubreakitintomodularcomponentparts?• Whataretheinterfaces?Whatarethemessagesthatyouneedtosendbetweentheparts?

• Yourcodeshouldbemodularanyway.• OGSIandSpringdothisforsingleJVMJavaapplications• Youcanmaintainamodulewithouttouchingothercode.

Page 18: Micro- Services DevOps Distributed Systems

SpringCoders,SpeakUp!

Whatcomponents,POJOs,etc doyouhaveinyourcodenow?

Page 19: Micro- Services DevOps Distributed Systems

Shouldapersonorgroup“own”asubsetofmodulesormicroservices?

• Teammemberscomeandgo• Theyaren’talwaysavailableanyway• Work-lifebalancewilleventuallybecomeimportanttomost• Nooneshouldbeindispensable

Forsmallteams,NOinmyexperience.

• “Possessiveownership”culture• Opaquecode• “Notmyproblem”ifithappens inanothermodule

Moduleownershipleadstootherproblems

Page 20: Micro- Services DevOps Distributed Systems

Ownership and Conway’s Law

• Anyorganizationthatdesignsasystem(definedbroadly)willproduceadesignwhosestructureisacopyoftheorganization'scommunication structure.–MelvinConway

Page 21: Micro- Services DevOps Distributed Systems

InOtherWords

• If youseparateyourorganizationinto• Systemsspecialists,• DBadmins,• Softwaredevelopers,• Userexperiencespecialists, etc,

• Andaskthemtobuildsomething,• Then

• thesystemwilllookliketheorgchart.• ThisistheoppositeoftheDevOps approach• Createsthebureaucraticinfightingthatplagueorganizations.

Page 22: Micro- Services DevOps Distributed Systems

Products,NotProjects

• Thealternative:organizearoundproducts• Aproductteamhasalltheexpertise itneeds• JimGrayinterviewsWernerVogels:https://queue.acm.org/detail.cfm?id=1142065

• “Youbuildit,youownit”

• Problemswiththisapproach:• Someonemayworkonmultipleproducts• Whoisthatperson’sboss?

Page 23: Micro- Services DevOps Distributed Systems

MyAdvice:OwntheEntireProduct

Evenifyouaren’tthemanager.Owntheproduct.

Page 24: Micro- Services DevOps Distributed Systems

Doyouseethisinthewayyouworknow?

Orinthewayyouworkedbeforeyoucamebacktoschool?

Page 25: Micro- Services DevOps Distributed Systems

HowBigIsaModule?Howlittle ismicro?

Page 26: Micro- Services DevOps Distributed Systems

RulesofThumbYouMightEncounter

• Amazon’stwo-pizzarule• Teamsshouldn’tbelargerthanwhattwopizzascanfeed

• “Agoodprogrammershouldbeabletorewriteamicroservice inacoupleofweeks”

• BoundedContextsfromDomainDrivenDesign

CanWeMakeThisMoreRigorous?

Page 27: Micro- Services DevOps Distributed Systems

Messagingpatternsbetweencomponents

•REST•CommoninInternetapplicationsbutyouwouldneverdothiswithincodeinasingleJVM

Request-response

•CommoninsingleJVMapplication:Observer,listenerpatterns•Butnot socommonindecoupledapplications.•Moregenerally,asynchronousmessagingisalittlescary.

Push

•Thecomponentknowswhichcomponentneedstogetthenewinformation.One-to-one

•Componentsdon’tneedtoknowwhichothercomponentsneedstheinformation.Theyjustbroadcastit.Many-to-many

Page 28: Micro- Services DevOps Distributed Systems

HowBigIsaComponent?

• Oneanswer:theoptimalmessagepatternshouldnotchangewhengoingfromsingleJVMtodistributedcomponents.

• Telescope inandtelescopeout

• Componentsthatruninthesameprocesscanbechattyandsendlotsofmessages.

• Messages canbepointerstoshareddataobjects• Messages arealwaysreceived• Thisistrueforbothrequestandpushmessaging.

Page 29: Micro- Services DevOps Distributed Systems

Pan-GalacticComponents

• Componentsthatrunacrosstheuniverseneeddifferentmessages,eitherinfrequentorterse.

• Noshareddataobjects topointto.• Distributedcomponentsmustalsoassumeawidevarietyofmessagefailures

• Lostconnections• Recipients neverreceived themessage• Recipients receivedmessages inthewrongorder• Recipients crashedwhileprocessing• ...

• Microservices aredistributedsystems• ShouldknowanduseDSideas

Page 30: Micro- Services DevOps Distributed Systems

Microservices AreNotDistributedObjects

• AcomponentisnotanobjectintheOOsense.• AcomponentshouldbeaserviceintheSOAsense• RecallRESTarchitecture:services shouldbeasidempotentaspossible.

• Ifyousendthesamemessagemorethanonce, theserverstateafterprocessingthemessageisthesame.

• Ex:Ifacomponentreceives10identicalmessagesayingsubmitajob,thecomponentshouldonlysubmitthejobonce.

• Howdoyouknowthemessageisreally identical?Timestamps,otheridentifiers,etc

• “Sharednothing”betweenservices• Messageprocessingshouldhavenosideeffectsthatneedtobeexposedtoothercomponents

• Anti-pattern:allthoseoutputfilesgeneratedbyscientificapplications

Page 31: Micro- Services DevOps Distributed Systems

DecentralizedDataManagement

• TheRegistrycomponent,backedbyasingleDBsystem,holdsallthedata

Thisisanopenchallengefor

ApacheAiravata

• Onedatabasehasall theinformationfortheapplication• Limitsyourchoiceofdatastores:youhavetousethesameDBtechnologyforeverything.

• Microservices constantlyneedtomakeremoteDBcalls• Performanceandsecurity

MicroserviceAntipattern

Page 32: Micro- Services DevOps Distributed Systems

SettingDataBoundaries

• Thisiseasywhenthedataisn’tconnectedorlightlyconnected.• ButnoteasytosplitupatraditionallydesignedDBschema.• Sciencegatewaydataboundaries

• Youmaywanttosplitstateless andstateful data

• Ifyousplitevenlightlyconnecteddataacrossservices,youwillneedtoconsiderconsistency

• Strong:requiresdistributedtransactions,whichcanbetricky• Weak:eventualconsistency.Canyoulivewiththis?

• Whatdataboundariesdosciencegatewayshave?

Page 33: Micro- Services DevOps Distributed Systems

Howdoservicescommunicate?

• Ideally,alwaysdothesamething.• Yourdevelopmentenvironmentshouldbeaminiatureversionofyourdeploymentenvironment:containerization

• Encapsulateandabstract• ThistouchesDevOps CI/CD,sothoseareseparate lectures

• Keepthecommunicationpatternsthesame• Push,pull• 1-1,orN-N

• We’lllookatmessagingsystemsindetailnext• Pushmessaging,many-to-many,reliabledelivery,replay,etc

Page 34: Micro- Services DevOps Distributed Systems

IfImakeeverythingdistributed,howcanItest?• Unittestswithincomponentsaresimple• Buttestingtheentiresystembecomesanoperationaltest

• Thisisnotabadthingifyoucanscriptyouroperationtests

• Andyoushould

• Monolith:testyourcodewhilebuildingwithMaven

• BringupsimpletestDBslikeSQLiteorDerby• Onebigbuilddoeseverything

Page 35: Micro- Services DevOps Distributed Systems

Microservice Testing

• Microservice:testyourcodeinanoperation-likesetting• Don’tbuildtheentirecodeeverytime• Buildonlythemicroservice youareworkingon.• Soyourbuildshouldbemodular

• Somaybeyoudon’tneedonebigbuildsystemafterall• Andmaybeyoudon’tneedonegit repoforeverything...• Andmaybeyoudon’tneedoneversion#thatcoversallyourcode...

• Soreleasesbecomeincremental• Testing,monitoring,andloggingbecomemorecontinuous

• ThisisatouchpointbetweenMicroservices andDevOps

Page 36: Micro- Services DevOps Distributed Systems

DesigningforFailure

• Microservices needtobebuilttotolerateerrors.• Whatkindsoferrorswillsciencegatewaymicroservices encounter?• Howdoyoudetectthesefailures?• Whattoolsdoyouneed?• Whatstrategiescanyouusetodosystemtesting?

Page 37: Micro- Services DevOps Distributed Systems

MessaginginDistributedSystems

Page 38: Micro- Services DevOps Distributed Systems

Zab:AtomicBroadcasting

ClientsSeeSpaces

Zookeeper’sclientAPIresemblesastructuredversionoftheTupleSpacesconceptofparallelprogramming.

Page 39: Micro- Services DevOps Distributed Systems

AdvancedMessageQueuingProtocolOverview

MoreDistributedServiceConcepts

Page 40: Micro- Services DevOps Distributed Systems

AMQP:NetworkProtocolandArchitecture,NotAnAPI• ManyImplementations

• RabbitMQ• ApacheActiveMQ• ApacheQpid• SwiftMQ• Andothers:• Thiscontradictsmyearlierdistinctionbetweenhorizontalandverticalstandardizationefforts

• AtleastforVersion0-9-1• EachimplementationcanhaveitsownAPI• I’llfocusonVersion0-9-1• ThisisnotanAMQPtutorial

Page 41: Micro- Services DevOps Distributed Systems

BasicConcepts

Page 42: Micro- Services DevOps Distributed Systems

AnAMQPServer(orBroker)

• Exchange• Message Queue• Exchanges caninteract withmultiple message queues

Twomainparts

• Accepts producermessages• SendstotheMessage QueueExchange

• Routesmessages todifferentconsumers depending onarbitrarycriteria• Buffersmessages when consumers arenotabletoaccept them fastenough.

MessageQueue

Page 43: Micro- Services DevOps Distributed Systems

ProducersandConsumers

• ProducersonlyinteractwithExchanges• ConsumersinteractwithMessageQueues• Consumersaren’tpassive

• Cancreateanddestroymessagequeues

• Thesameapplicationcanactasbothapublisherandaconsumer• Youcanimplement Request-Response withAMQP• Exceptthepublisherdoesn’tblock

• Ex:yourapplicationmaywantanACKorNACKwhenitpublishes• Thisisareplyqueue

Page 44: Micro- Services DevOps Distributed Systems

MessageQueue

• Typesofqueueproperties:• Privateorshared• Durableortemporary• Client-named orserver- named,etc.

• Store-and-forward queue:holdsmessagesanddistributesthesebetweenconsumersonaround-robinbasis.

• Durable andsharedbetweenmultipleconsumers.• Privatereplyqueue:holdsmessagesandforwardsthesetoasingleconsumer.

• Replyqueuesaretypicallytemporary,server-named, andprivatetooneconsumer.• Privatesubscriptionqueue:holdsmessagescollectedfromvarious"subscribed"sources,andforwardsthesetoasingleconsumer.

Page 45: Micro- Services DevOps Distributed Systems

ConsumersandMessageQueues

• AMQPConsumerscancreatetheirownqueuesandbindthemtoExchanges

• Thishasaninterestingimplication• Queuescanhavemorethanoneattachedconsumer• AMQPqueuesareFIFO

• AMQPallowsonlyoneconsumerperqueue toreceivethemessage.• Useround-robindeliveryif>1attachedconsumer.• Thisgreatlysimplifiesthings

• Ifyouneed>1consumertoreceiveamessage,youcangiveeachconsumertheirownqueue.

• Usetopicmatchingtoroutemessages• ComparethistoZab andatomicbroadcastprotocols,generally.

• AMQPmakessomesimplifications

Page 46: Micro- Services DevOps Distributed Systems

TheExchange

• Receivesmessages• Inspectsamessageheader,body,andproperties• Routesmessagestoappropriatemessagequeues• Routingusuallydonewithroutingkeys inthemessagepayload

• Forpoint-to-pointmessages,theroutingkeyisthenameofthemessagequeue

• Forpub-subrouting,theroutingkeyisthenameofthetopic• Topicscanbehierarchical

Page 47: Micro- Services DevOps Distributed Systems

Publish-SubscribePatterns

• Usefulformany-to-manymessaging• Inmicroservice-basedsystems,severaldifferenttypesofcomponentsmaywanttoreceivethesamemessage

• Buttakedifferentactions• Ex:youcanalwaysaddaloggerservice

• Youcanalwaysdothiswithexplicitlynamedroutingkeys.• Youmayalsowanttousehierarchical(namespace)keynamesandpatternmatching.

• gateway.jobs.jobtype.gromacs• Gateway.jobs.jobtype.*

Page 48: Micro- Services DevOps Distributed Systems

TheMessagePayload

• Readthespecificationformoredetails.• IngeneralAMQPfollowsthehead-bodyformat• Themessagebodypayloadisbinary• AMQPassumesthecontentishandledbyconsumers

• Itistheconsumer’sjobtodosomethingwiththecontent.• UnlikeJMS

• YoucouldserializeyourcontentwithJSONorThriftanddeserialize ittodirectlysendobjects.

Page 49: Micro- Services DevOps Distributed Systems

MessageExchangePatterns

Page 50: Micro- Services DevOps Distributed Systems

DirectExchange

• Apublishersendsamessagetoanexchangewithaspecificroutingkey.

• Theexchangeroutesthistothemessagequeueboundtotheroutingkey.

• Oneormoreconsumersreceivemessagesiflisteningtothequeue.

• Default:round-robinqueuingtodelivertomultiplesubscribersofsamequeue

Queue.Declare queue=app.svc01 Basic.Consume queue=app.svc01 Basic.Publish routing-key=app.svc01

Page 51: Micro- Services DevOps Distributed Systems

Fanout Exchange

• MessageQueuebindstoanExchangewithnoargument

• PublishersendsamessagetotheExchange

• TheExchangesendsthemessagetotheMessageQueue

• AllconsumerslisteningtoallMessageQueuesassociatedwithanExchangegetthemessage

Page 52: Micro- Services DevOps Distributed Systems

TopicExchange

• MessageQueuesbindusingroutingpatternsinsteadofroutingkeys.

• APublishersendsamessagewitharoutingkey.

• ExchangewillroutetoallMessageQueuesthatmatchtheroutingkey’spattern

Page 53: Micro- Services DevOps Distributed Systems

MoreExamples

• TheRabbitMQ tutorialpagehasseveralniceexamplesofclassicmessageexchangepatterns.

• https://www.rabbitmq.com/getstarted.html

Page 54: Micro- Services DevOps Distributed Systems

SomeUsefulCapabilitiesofMessagingSystemsfor

MicroservicesOverarchingRequirement:Itshouldsupportyoursystem’s

distributedstatemachine

Let’sbrainstormsome

Page 55: Micro- Services DevOps Distributed Systems

UsefulCapabilities:MyList(1/2)

• Supportsbothpushandpullmessaging• Delivermessagesinorder• Successfullydeliveredmessagesaredeliveredexactlyonce

• MultiplerecipientsOK• Delivermessagestooneormorelistenersbasedonpre-definedtopics.

• Storemessagespersistently• Therearenoactiverecipients.• Allrecipientsarebusy

• Determineifcriticalmessagesweredeliveredcorrectly

Page 56: Micro- Services DevOps Distributed Systems

UsefulCapabilities:MyList(2/2)

• Redelivermessagesthatweren’tcorrectlyreceived• Corruptedmessages,norecipients,etc• Recipientcanchange

• Redelivermessagesonrequest• Helpsclientsresynchtheirstates

• Allowothercomponentstoinspectmessagedeliverymetadata.• Supportselasticity, faulttolerance

• Prioritymessaging?• QualitiesofService

• Security,faulttolerance

Page 57: Micro- Services DevOps Distributed Systems

WhichMessagingSoftwaretoChoose?

• AMQPdoesnotcoverallthecapabilitieslistedabove.• Itcanbeextendedtocoverthese inmanycases

• AMQPmessagingsystemimplementationsarenotnecessarilycloud-ready

• Theyhavetobeconfiguredashighlyavailableservices.• Primary+failover

• Nofancyleaderelections, etc asused inZookeeper+Zab• Havescalinglimitations,althoughthesemaynotmatteratourscales.

• Othermessagingsystems(Kafka,HedWig)arealternatives

Page 58: Micro- Services DevOps Distributed Systems

SomeApplications

Page 59: Micro- Services DevOps Distributed Systems

SimpleWorkQueue

• Queueupworktobedone.• Publisher:pushesarequestforworkintothequeue

• Queue shouldbeasimpleDirectExchange• MessageQueueshouldimplement“onlydelivermessageoncetoonceconsumer”.

• Round-robinscheduling.• RabbitMQ doesthisoutofthebox

• Consumer:SendsanACKaftercompletingthetask• IfaQueue-ClientclosesbeforeanACK,resendmessagetoanewconsumer.

• RabbitMQ detectsthesetypesoffailures.

Page 60: Micro- Services DevOps Distributed Systems

GatewayAPIServer

AppMan Worker

AppMan Worker

AppMan Worker

Broker

MSG1, 2,3MSG2

MSG1

MSG3

ACK

ACK

ACK

• 3Job requests come totheAPIServer• APIServer publishes toBroker(Exchange+Message

Queue)• Brokersends toworkersinround-robin• Workers sendACKswhendone• IfBrokerdetectsaclosed connection beforeanACK, sends

MSGtoadifferentworker

SimpleWorkQueue

Page 61: Micro- Services DevOps Distributed Systems

WhatCouldPossiblyGoWrong?

• Jobstakealongtimetofinish,soACKsmaynotcomeforhours.• DurableconnectionsneededbetweenConsumersandMessageQueues• Alternatively,theACKcouldcomefromadifferentprocess

• Jobsmayactuallygetlaunchedontheexternalsupercomputer,soyoudon’twanttolaunchtwicejustbecauseofamissingACK

• Clientshavetoimplementtheirownqueues• Couldgetanotherworkrequestwhiledoingwork.

Page 62: Micro- Services DevOps Distributed Systems

WorkQueue,TakeTwo

• Orchestratorpushesworkintoaqueue.• Haveworkers requestworkwhentheyarenotbusy.

• RabbitMQ supportsthisas“prefetchCount”• Useround-robinbutdon’tsendworktobusyworkerswithoutstandingACKs.• Workers donotreceiveworkrequestswhentheyarebusy.

• WorkersendsACKaftersuccessfullysubmittingthejob.• Thisonlymeansthejobhasbeensubmitted• Worker cantakemorework

• Aseparateprocesshandlesthestatechangesonthesupercomputer• Publishes”queued”, “executing”, ”completed”or“failed”messages

• Whenjobisdone,Orchestratorcreatesa“cleanup”job• Anyworker availablecantakethis.

Page 63: Micro- Services DevOps Distributed Systems

WorkQueue,Take2

Orchestrator Broker

AppMan Worker

EmailListener

1a.Ready

2.RunJob

3.ACK

AppMan Worker

5.Done

1b.Ready

8.CleanUp

9.ACK

0.RunJob

ExperimentMetadataManager

4.,6.,10.JobStatus

7.Cleanup

Page 64: Micro- Services DevOps Distributed Systems

WhatCouldPossiblyGoWrong?

• AWorkermaynotbeabletosubmitthejob• Remotesupercomputer isunreachable, forexample• WeneedaNACK

• TheOrchestratorandExperimentMetadatacomponentsarealsoconsumers.

• ShouldsendACKstomakesuremessagesaredelivered.• OrchestratorandExperimentMetadataManagermayalsodieandgetreplaced.

• UnlikeAppMan workers,OrchestratorandEMMmayneed aleader-followerimplementation

• Brokercrashes• RabbitMQ providessomedurabilityforrestarting• Possibletolosecachedmessages thathaven’tgonetopersistentstorage

Page 65: Micro- Services DevOps Distributed Systems

WhatElseCouldGoWrong?

• Lotsofthings.• Howdoyoudebugunexpectederrors?

• Logs

• AloggerlikeLogStash shouldbeoneofyourconsumers• Noone-to-onemessagesanymore.• Everythinghasatleast2subscribers

• Yourlogservice• Themaintarget

• OryoucoulduseFanout

Page 66: Micro- Services DevOps Distributed Systems

Summary

• Microservices areapplicationsbuiltoutofdistributedcomponents• ImportantifyourunSoftwareasaService• ConnectiontoDevOps:

• Acceleratethedevelop-test-deploycycle• ContinuousIntegrationandContinuousDeliveryareessential

• Servicesneedtocommunicate• Asynchronousmessaging ispowerfulmechanism• Push,many-to-many• Caneasilyextendtoaddmorecomponents

Page 67: Micro- Services DevOps Distributed Systems

Micro-Services

DevOpsDistributedSystems