From Monolith to Microservices

Tony Maher

DoseMedia

• www.dose.com• www.omgfacts.com

• TonyMaher,TeamLead• tony@dose.com,@tonymaher5

DoseMedia

• Largescalewebsites-55millionmonthlyuniques.• Uptimeisparamount.

• Small,autonomous,andflexibleteams.

Outline

• DoseArchitecture,2012-2014• Resultsofthisarchitecture• ThestartofMicroservicesandstepswestartedtaking

• InitialResults• IntroductionofDocker• CurrentStatus• NextSteps

DoseLegacyArchitecture

DoseLegacyArchitecture

• ~3millionlinesofcode

• 415commitstoproductioninQ12013,mostofwhichwerebugfixesorredalertbandaids.

DoseLegacyArchitecture

• ResponseTime:?• Downtime:?

• Horrible/missingmonitoring,logging,documentation

Symptoms

Symptoms

Symptoms

Symptoms

• Frequentcrashes.

• HUGEresourcecostsforrelativelysimplefunctionality.

• Extremelylongdebugtimes.

• Probleminoneareaballoonedtoproblemsacrossentirenetwork.

DoseLegacyArchitecture

• ResponseTime:?• Downtime:?

• Weknowtheywerereeeeaaaallybad.

• Bestguesswouldbearound1-2secondsserverresponsetime,<99.0%uptime.

TheStartofMicroservices

• Fullteambuy-in…Noedictsfromthemountaintop.

• Multiplemicroservicerelatedbookclubs.• Regulararchitectureplanningmeetings.

TheStartofMicroservices

• Thegeneralconcept:It’ssimplygoodOOclassdesign,abstractedtoservicesandapplications.

• SOLIDDesignPrinciples…SRP

TheStartofMicroservices

• Justlittlethingsatfirst…• Keepmodulessmallandisolated.

• Splitdistinctfunctionalityintoseparatecodebase,withitsownwebcluster,database,cache,everything.

• USEINTERFACES.• NoGodClasses.

TheStartofMicroservices

• ResourceAPIs-Databasedmicroserviceswhichjustexposerelatedresources/entities.

• ServiceAPIs-BehaviorbasedmicroserviceswhichcommunicatewithResourceAPIs.

• ClientApplications-WebandmobileappswhichonlycommunicatewithServiceAPIs.

TheStartofMicroservices

TheStartofMicroservices

• Whenwewantedtosplitaservice,buttoomuchofitsfunctionalitywasstilltieddirectlytothefunctioningmonolith…

• Wecreatedwhatwecalla“hydra”-sharedresources(usuallythemonolithicdatabase)usedbyseparateservices.

TheStartofMicroservices

TheStartofMicroservices

• Atthispoint(late2014-early2015),we’vegotacoupleMicroservices,acoupleHydras,andthelegacymonolith.

• Alreadyweseevastimprovementsthough.

InitialResults

• Averageserverresponsetime:800ms• Uptime:99.96%

• Stillnotgreat,butatleastwe’reheadingintherightdirection.

StateofDevops

• Localdevelopmentwasdoneinavagrantbox,whichmayormaynothavehadthesameversionsasqaorprod,buildorbatchnodes.

• Updateswererunonalongrunning“build”nodewithapotentiallyverydifferentarchitecturethanotherenvironments.

StateofDevops

• Tossitoverthewallattitudetowarddevopsanddeployments…

“Itworkslocallysomustbeadevopsproblem”

StateofDevops

• Soweidentifiedourneeds:• Consistencybetweenenvironments.• Transparencyonprojectrequirementsanddependencies.

• Flexibilitytochangeasweexperimentandlearnmoreabouttheprocessandhowitworksforus.

IntroductionofDocker

• Westartedusingdocker-compose,aswellassemi-regularlyupdateddockerbaseimages,toensureconsistentarchitecturesacrossenvironments.

• Movedconfigurationanddeploymentclosertodevelopment.

• Puteverythingyouneedtorunanenvironmentinthecodebase.

IntroductionofDocker

• Everyservicehasitsowndockercomposefileinitsrepository.

• Versionsareimagedbygithash,sodockerhelpsusensurewe’retestingexactlywhat’sgoingintoproduction.

• Developersareintimatelyfamiliarwithdependenciesanddeploymentprocesses.

CurrentStatus

• Atthispoint,we’ve…• Createdafewindependentmicroservices.

• Shuntedsomeofourbulkierlegacyfunctionalityintohydras.

• Killedalotofoldcode.• Startedusingadockerbaseddeploymentpipelinetodecreasethedifferencesbetweenenvironments.

CurrentStatus

• FromJan1,2016tonow:

• Ourlargestmicroservicehasonlyacouplehundredlinesofcustomcode.

• Websites’Uptime:100%• Websites’AverageServerResponseTime:119ms

NextSteps

• Allnewanddistinctfunctionalitygoesintoitsownmicroservice,deployedtoitsowncluster.• OnlycommunicatewithotherservicesoverAPIrequests.

• NOBACKDOORS.• Use3rdpartyresourceswheneverpossible.• Don’treinventthewheel.

NextSteps

• Continuetodecouplethehydras/monoliths.• ConvertsharedresourcesintoResourceAPIs.• Killlegacycode.

• Createmicroservices(orhopefullyuse3rdpartyresources)tohelporchestrationbetweenmicroservices.

KeyTakeaways

• Don’tfallpreytoanalysisparalysis…takelittlesteps.

• Useshuntstoeasetransitions(butputdeadlinesontheirlifetime!).

• Deletecodewhereverpossible.• Treatinternalservicesjustlikeyouwould3rdpartyservices.

KeyTakeaways

• Limit(hopefullyto1service)thenumberofintegrationpointstosharedsystems,especiallydatabases.

• VersionAPIstofurtherdecoupleservicesandpreventchangesinoneservicefromaffectinganother.

• Keepmicroservicessosmallthatit’seasiertorewritethantorefactor.

QuestionsandContact

• Feelfreetoreachout…• tony@dose.com,@tonymaher5