Intro Videos Design Agile Refactoring NoSQL DSL ContinuousDelivery Microservices Photos AboutMe

ThoughtWorks

Microservices
adefinitionofthisnewarchitecturalterm
Theterm"MicroserviceArchitecture"hassprungupoverthelastfewyearstodescribea
particularwayofdesigningsoftwareapplicationsassuitesofindependentlydeployable
services.Whilethereisnoprecisedefinitionofthisarchitecturalstyle,therearecertain
commoncharacteristicsaroundorganizationaroundbusinesscapability,automated
deployment,intelligenceintheendpoints,anddecentralizedcontroloflanguagesand
data.
25March2014
JamesLewis
JamesLewisisaPrincipal
Consultantat
ThoughtWorksand
memberoftheTechnology
AdvisoryBoard.James'
interestinbuildingapplicationsoutofsmall
collaboratingservicesstemsfroma
backgroundinintegratingenterprise
systemsatscale.He'sbuiltanumberof
systemsusingmicroservicesandhasbeen
anactiveparticipantinthegrowing
communityforacoupleofyears.

MartinFowler
MartinFowlerisanauthor,
speaker,andgeneralloud
mouthonsoftware
development.He'slong
beenpuzzledbythe
problemofhowtocomponentizesoftware
systems,havingheardmorevagueclaims
thanhe'shappywith.Hehopesthat
microserviceswillliveuptotheearly
promiseitsadvocateshavefound.

Contents
CharacteristicsofaMicroserviceArchitecture
ComponentizationviaServices
OrganizedaroundBusinessCapabilities
ProductsnotProjects
Smartendpointsanddumbpipes
DecentralizedGovernance
DecentralizedDataManagement
InfrastructureAutomation
Designforfailure
EvolutionaryDesign
AreMicroservicestheFuture?
Sidebars
Howbigisamicroservice?
MicroservicesandSOA
Manylanguages,manyoptions
Battletestedstandardsandenforcedstandards
Makeiteasytodotherightthing
Thecircuitbreakerandproductionreadycode
Synchronouscallsconsideredharmful

Translations:JapaneseRussian
Korean
Findsimilararticlestothisbylooking
atthesetags:popularapplication
architecturewebservices
microservices

"Microservices"yetanothernewtermonthecrowdedstreetsofsoftwarearchitecture.
Althoughournaturalinclinationistopasssuchthingsbywithacontemptuousglance,this
bitofterminologydescribesastyleofsoftwaresystemsthatwearefindingmoreandmore
appealing.We'veseenmanyprojectsusethisstyleinthelastfewyears,andresultssofar
havebeenpositive,somuchsothatformanyofourcolleaguesthisisbecomingthe
defaultstyleforbuildingenterpriseapplications.Sadly,however,there'snotmuch
informationthatoutlineswhatthemicroservicestyleisandhowtodoit.

Inshort,themicroservicearchitecturalstyle[1]isanapproachtodevelopingasingle
applicationasasuiteofsmallservices,eachrunninginitsownprocessand
communicatingwithlightweightmechanisms,oftenanHTTPresourceAPI.These
servicesarebuiltaroundbusinesscapabilitiesandindependentlydeployablebyfully
automateddeploymentmachinery.Thereisabareminimumofcentralizedmanagement
oftheseservices,whichmaybewrittenindifferentprogramminglanguagesanduse
differentdatastoragetechnologies.
Tostartexplainingthemicroservicestyleit'susefultocompareittothe
monolithicstyle:amonolithicapplicationbuiltasasingleunit.Enterprise
Applicationsareoftenbuiltinthreemainparts:aclientsideuserinterface
(consistingofHTMLpagesandjavascriptrunninginabrowseronthe
user'smachine)adatabase(consistingofmanytablesinsertedintoa
common,andusuallyrelational,databasemanagementsystem),anda
serversideapplication.TheserversideapplicationwillhandleHTTP
requests,executedomainlogic,retrieveandupdatedatafromthe
database,andselectandpopulateHTMLviewstobesenttothebrowser.
Thisserversideapplicationisamonolithasinglelogicalexecutable[2].
Anychangestothesysteminvolvebuildinganddeployinganewversion
oftheserversideapplication.

MyMicroservicesResourceGuide
provideslinkstothebestarticles,videos,
books,andpodcastsaboutmicroservices.

Suchamonolithicserverisanaturalwaytoapproachbuildingsuchasystem.Allyour
logicforhandlingarequestrunsinasingleprocess,allowingyoutousethebasic
featuresofyourlanguagetodivideuptheapplicationintoclasses,functions,and
namespaces.Withsomecare,youcanrunandtesttheapplicationonadeveloper's
laptop,anduseadeploymentpipelinetoensurethatchangesareproperlytestedand
deployedintoproduction.Youcanhorizontallyscalethemonolithbyrunningmany
instancesbehindaloadbalancer.
Monolithicapplicationscanbesuccessful,butincreasinglypeoplearefeelingfrustrations
withthemespeciallyasmoreapplicationsarebeingdeployedtothecloud.Change
cyclesaretiedtogetherachangemadetoasmallpartoftheapplication,requiresthe
entiremonolithtoberebuiltanddeployed.Overtimeit'softenhardtokeepagood
modularstructure,makingithardertokeepchangesthatoughttoonlyaffectonemodule
withinthatmodule.Scalingrequiresscalingoftheentireapplicationratherthanpartsofit
thatrequiregreaterresource.

Figure1:MonolithsandMicroservices

Thesefrustrationshaveledtothemicroservicearchitecturalstyle:buildingapplicationsas
suitesofservices.Aswellasthefactthatservicesareindependentlydeployableand
scalable,eachservicealsoprovidesafirmmoduleboundary,evenallowingfordifferent
servicestobewrittenindifferentprogramminglanguages.Theycanalsobemanagedby
differentteams.
Wedonotclaimthatthemicroservicestyleisnovelorinnovative,itsrootsgobackatleast
tothedesignprinciplesofUnix.Butwedothinkthatnotenoughpeopleconsidera
microservicearchitectureandthatmanysoftwaredevelopmentswouldbebetteroffifthey
usedit.

CharacteristicsofaMicroserviceArchitecture
Wecannotsaythereisaformaldefinitionofthemicroservicesarchitecturalstyle,butwe
canattempttodescribewhatweseeascommoncharacteristicsforarchitecturesthatfit
thelabel.Aswithanydefinitionthatoutlinescommoncharacteristics,notallmicroservice
architectureshaveallthecharacteristics,butwedoexpectthatmostmicroservice
architecturesexhibitmostcharacteristics.Whileweauthorshavebeenactivemembersof
thisratherloosecommunity,ourintentionistoattemptadescriptionofwhatweseeinour
ownworkandinsimilareffortsbyteamsweknowof.Inparticularwearenotlayingdown
somedefinitiontoconformto.

ComponentizationviaServices
Foraslongaswe'vebeeninvolvedinthesoftwareindustry,there'sbeenadesiretobuild
systemsbypluggingtogethercomponents,muchinthewayweseethingsaremadein
thephysicalworld.Duringthelastcoupleofdecadeswe'veseenconsiderableprogress
withlargecompendiumsofcommonlibrariesthatarepartofmostlanguageplatforms.
Whentalkingaboutcomponentswerunintothedifficultdefinitionofwhatmakesa

component.Ourdefinitionisthatacomponentisaunitofsoftwarethatisindependently
replaceableandupgradeable.
Microservicearchitectureswilluselibraries,buttheirprimarywayofcomponentizingtheir
ownsoftwareisbybreakingdownintoservices.Wedefinelibrariesascomponentsthat
arelinkedintoaprogramandcalledusinginmemoryfunctioncalls,whileservicesare
outofprocesscomponentswhocommunicatewithamechanismsuchasawebservice
request,orremoteprocedurecall.(Thisisadifferentconcepttothatofaserviceobjectin
manyOOprograms[3].)
Onemainreasonforusingservicesascomponents(ratherthanlibraries)isthatservices
areindependentlydeployable.Ifyouhaveanapplication[4]thatconsistsofamultiple
librariesinasingleprocess,achangetoanysinglecomponentresultsinhavingto
redeploytheentireapplication.Butifthatapplicationisdecomposedintomultiple
services,youcanexpectmanysingleservicechangestoonlyrequirethatservicetobe
redeployed.That'snotanabsolute,somechangeswillchangeserviceinterfacesresulting
insomecoordination,buttheaimofagoodmicroservicearchitectureistominimizethese
throughcohesiveserviceboundariesandevolutionmechanismsintheservicecontracts.
Anotherconsequenceofusingservicesascomponentsisamoreexplicitcomponent
interface.Mostlanguagesdonothaveagoodmechanismfordefininganexplicit
PublishedInterface.Oftenit'sonlydocumentationanddisciplinethatpreventsclients
breakingacomponent'sencapsulation,leadingtooverlytightcouplingbetween
components.Servicesmakeiteasiertoavoidthisbyusingexplicitremotecall
mechanisms.
Usingserviceslikethisdoeshavedownsides.Remotecallsaremoreexpensivethanin
processcalls,andthusremoteAPIsneedtobecoarsergrained,whichisoftenmore
awkwardtouse.Ifyouneedtochangetheallocationofresponsibilitiesbetween
components,suchmovementsofbehaviorarehardertodowhenyou'recrossingprocess
boundaries.
Atafirstapproximation,wecanobservethatservicesmaptoruntimeprocesses,butthat
isonlyafirstapproximation.Aservicemayconsistofmultipleprocessesthatwillalways
bedevelopedanddeployedtogether,suchasanapplicationprocessandadatabase
that'sonlyusedbythatservice.

OrganizedaroundBusinessCapabilities
Whenlookingtosplitalargeapplicationintoparts,oftenmanagementfocusesonthe
technologylayer,leadingtoUIteams,serversidelogicteams,anddatabaseteams.
Whenteamsareseparatedalongtheselines,evensimplechangescanleadtoacross
teamprojecttakingtimeandbudgetaryapproval.Asmartteamwilloptimisearoundthis
andplumpforthelesseroftwoevilsjustforcethelogicintowhicheverapplicationthey
haveaccessto.Logiceverywhereinotherwords.ThisisanexampleofConway'sLaw[5]
inaction.
Anyorganizationthatdesignsasystem(definedbroadly)willproduceadesignwhose
structureisacopyoftheorganization'scommunicationstructure.
MelvynConway,1967

Figure2:Conway'sLawinaction

Themicroserviceapproachtodivisionisdifferent,splittingupintoservicesorganized
aroundbusinesscapability.Suchservicestakeabroadstackimplementationof
softwareforthatbusinessarea,includinguserinterface,persistantstorage,andany
externalcollaborations.Consequentlytheteamsarecrossfunctional,includingthefull
rangeofskillsrequiredforthedevelopment:userexperience,database,andproject
management.

Figure3:Serviceboundariesreinforcedbyteamboundaries

Onecompanyorganisedinthiswayiswww.comparethemarket.com.
Crossfunctionalteamsareresponsibleforbuildingandoperatingeach

Howbigisamicroservice?

productandeachproductissplitoutintoanumberofindividualservices
communicatingviaamessagebus.
Largemonolithicapplicationscanalwaysbemodularizedaround
businesscapabilitiestoo,althoughthat'snotthecommoncase.Certainly
wewouldurgealargeteambuildingamonolithicapplicationtodivide
itselfalongbusinesslines.Themainissuewehaveseenhere,isthatthey
tendtobeorganisedaroundtoomanycontexts.Ifthemonolithspans
manyofthesemodularboundariesitcanbedifficultforindividual
membersofateamtofitthemintotheirshorttermmemory.Additionally
weseethatthemodularlinesrequireagreatdealofdisciplinetoenforce.
Thenecessarilymoreexplicitseparationrequiredbyservicecomponents
makesiteasiertokeeptheteamboundariesclear.

ProductsnotProjects
Mostapplicationdevelopmenteffortsthatweseeuseaprojectmodel:
wheretheaimistodeliversomepieceofsoftwarewhichisthen
consideredtobecompleted.Oncompletionthesoftwareishandedover
toamaintenanceorganizationandtheprojectteamthatbuiltitisdisbanded.

Althoughmicroservicehasbecomea
popularnameforthisarchitecturalstyle,its
namedoesleadtoanunfortunatefocuson
thesizeofservice,andargumentsabout
whatconstitutesmicro.Inour
conversationswithmicroservicepractitioners,
weseearangeofsizesofservices.The
largestsizesreportedfollowAmazon'snotion
oftheTwoPizzaTeam(i.e.thewholeteam
canbefedbytwopizzas),meaningnomore
thanadozenpeople.Onthesmallersize
scalewe'veseensetupswhereateamof
halfadozenwouldsupporthalfadozen
services.
Thisleadstothequestionofwhetherthere
aresufficientlylargedifferenceswithinthis
sizerangethattheserviceperdozenpeople
andserviceperpersonsizesshouldn'tbe
lumpedunderonemicroserviceslabel.At
themomentwethinkit'sbettertogroup
themtogether,butit'scertainlypossiblethat
we'llchangeourmindasweexplorethis
stylefurther.

Microserviceproponentstendtoavoidthismodel,preferringinsteadthenotionthata
teamshouldownaproductoveritsfulllifetime.AcommoninspirationforthisisAmazon's
notionof"youbuild,yourunit"whereadevelopmentteamtakesfullresponsibilityforthe
softwareinproduction.Thisbringsdevelopersintodaytodaycontactwithhowtheir
softwarebehavesinproductionandincreasescontactwiththeirusers,astheyhaveto
takeonatleastsomeofthesupportburden.
Theproductmentality,tiesinwiththelinkagetobusinesscapabilities.Ratherthanlooking
atthesoftwareasasetoffunctionalitytobecompleted,thereisanongoingrelationship
wherethequestionishowcansoftwareassistitsuserstoenhancethebusiness
capability.
There'snoreasonwhythissameapproachcan'tbetakenwithmonolithicapplications,but
thesmallergranularityofservicescanmakeiteasiertocreatethepersonalrelationships
betweenservicedevelopersandtheirusers.

Smartendpointsanddumbpipes
Whenbuildingcommunicationstructuresbetweendifferentprocesses,we'veseenmany
productsandapproachesthatstressputtingsignificantsmartsintothecommunication
mechanismitself.AgoodexampleofthisistheEnterpriseServiceBus(ESB),whereESB
productsoftenincludesophisticatedfacilitiesformessagerouting,choreography,
transformation,andapplyingbusinessrules.
Themicroservicecommunityfavoursanalternativeapproach:smartendpointsanddumb
pipes.Applicationsbuiltfrommicroservicesaimtobeasdecoupledandascohesiveas
possibletheyowntheirowndomainlogicandactmoreasfiltersintheclassicalUnix
sensereceivingarequest,applyinglogicasappropriateandproducingaresponse.
ThesearechoreographedusingsimpleRESTishprotocolsratherthancomplexprotocols
suchasWSChoreographyorBPELororchestrationbyacentraltool.
ThetwoprotocolsusedmostcommonlyareHTTPrequestresponsewithresourceAPI's

andlightweightmessaging[6].Thebestexpressionofthefirstis
Beoftheweb,notbehindtheweb
IanRobinson
Microserviceteamsusetheprinciplesandprotocolsthattheworldwideweb(andtoa
largeextent,Unix)isbuilton.Oftenusedresourcescanbecachedwithverylittleefforton
thepartofdevelopersoroperationsfolk.
Thesecondapproachincommonuseismessagingoveralightweightmessagebus.The
infrastructurechosenistypicallydumb(dumbasinactsasamessagerouteronly)
simpleimplementationssuchasRabbitMQorZeroMQdon'tdomuchmorethanprovidea
reliableasynchronousfabricthesmartsstillliveintheendpointsthatareproducingand
consumingmessagesintheservices.
Inamonolith,thecomponentsareexecutinginprocessandcommunicationbetween
themisviaeithermethodinvocationorfunctioncall.Thebiggestissueinchanginga
monolithintomicroservicesliesinchangingthecommunicationpattern.Anaive
conversionfrominmemorymethodcallstoRPCleadstochattycommunicationswhich
don'tperformwell.Insteadyouneedtoreplacethefinegrainedcommunicationwitha
coarsergrainedapproach.

DecentralizedGovernance
Oneoftheconsequencesofcentralisedgovernanceisthetendencytostandardiseon
singletechnologyplatforms.Experienceshowsthatthisapproachisconstrictingnot
everyproblemisanailandnoteverysolutionahammer.Wepreferusingtherighttoolfor
thejobandwhilemonolithicapplicationscantakeadvantageofdifferentlanguagestoa
certainextent,itisn'tthatcommon.
Splittingthemonolith'scomponentsoutintoserviceswehaveachoice
whenbuildingeachofthem.YouwanttouseNode.jstostandupasimple
reportspage?Goforit.C++foraparticularlygnarlynearrealtime
component?Fine.Youwanttoswapinadifferentflavourofdatabasethat
bettersuitsthereadbehaviourofonecomponent?Wehavethe
technologytorebuildhim.
Ofcourse,justbecauseyoucandosomething,doesn'tmeanyoushould
butpartitioningyoursysteminthiswaymeansyouhavetheoption.
Teamsbuildingmicroservicespreferadifferentapproachtostandards
too.Ratherthanuseasetofdefinedstandardswrittendownsomewhere
onpapertheyprefertheideaofproducingusefultoolsthatother
developerscanusetosolvesimilarproblemstotheonestheyarefacing.
Thesetoolsareusuallyharvestedfromimplementationsandsharedwith
awidergroup,sometimes,butnotexclusivelyusinganinternalopen
sourcemodel.Nowthatgitandgithubhavebecomethedefactoversion
controlsystemofchoice,opensourcepracticesarebecomingmoreand
morecommoninhouse.
Netflixisagoodexampleofanorganisationthatfollowsthisphilosophy.
Sharingusefuland,aboveall,battletestedcodeaslibrariesencourages
otherdeveloperstosolvesimilarproblemsinsimilarwaysyetleavesthe

MicroservicesandSOA
Whenwe'vetalkedaboutmicroservicesa
commonquestioniswhetherthisisjust
ServiceOrientedArchitecture(SOA)thatwe
sawadecadeago.Thereismerittothis
point,becausethemicroservicestyleisvery
similartowhatsomeadvocatesofSOA
havebeeninfavorof.Theproblem,
however,isthatSOAmeanstoomany
differentthings,andthatmostofthetime
thatwecomeacrosssomethingcalled
"SOA"it'ssignificantlydifferenttothestyle
we'redescribinghere,usuallyduetoafocus
onESBsusedtointegratemonolithic
applications.
Inparticularwehaveseensomanybotched
implementationsofserviceorientationfrom
thetendencytohidecomplexityawayin
ESB's[7],tofailedmultiyearinitiativesthat
costmillionsanddelivernovalue,to
centralisedgovernancemodelsthatactively
inhibitchange,thatitissometimesdifficult
toseepasttheseproblems.
Certainly,manyofthetechniquesinusein
themicroservicecommunityhavegrown
fromtheexperiencesofdevelopers
integratingservicesinlargeorganisations.

dooropentopickingadifferentapproachifrequired.Sharedlibrariestend
tobefocusedoncommonproblemsofdatastorage,interprocess
communicationandaswediscussfurtherbelow,infrastructure
automation.

TheTolerantReaderpatternisanexample
ofthis.Effortstousethewebhave
contributed,usingsimpleprotocolsis
anotherapproachderivedfromthese
experiencesareactionawayfromcentral
standardsthathavereachedacomplexity
thatis,frankly,breathtaking.(Anytimeyou
needanontologytomanageyourontologies
youknowyouareindeeptrouble.)

Forthemicroservicecommunity,overheadsareparticularlyunattractive.
Thatisn'ttosaythatthecommunitydoesn'tvalueservicecontracts.Quite
ThiscommonmanifestationofSOAhasled
theopposite,sincetheretendtobemanymoreofthem.It'sjustthatthey
somemicroserviceadvocatestorejectthe
arelookingatdifferentwaysofmanagingthosecontracts.Patternslike
SOAlabelentirely,althoughothersconsider
microservicestobeoneformofSOA[8],
TolerantReaderandConsumerDrivenContractsareoftenappliedto
perhapsserviceorientationdoneright.Either
microservices.Theseaidservicecontractsinevolvingindependently.
way,thefactthatSOAmeanssuchdifferent
thingsmeansit'svaluabletohaveaterm
Executingconsumerdrivencontractsaspartofyourbuildincreases
thatmorecrisplydefinesthisarchitectural
confidenceandprovidesfastfeedbackonwhetheryourservicesare
style.
functioning.IndeedweknowofateaminAustraliawhodrivethebuildof
newserviceswithconsumerdrivencontracts.Theyusesimpletoolsthat
allowthemtodefinethecontractforaservice.Thisbecomespartoftheautomatedbuild
beforecodeforthenewserviceisevenwritten.Theserviceisthenbuiltoutonlytothe
pointwhereitsatisfiesthecontractanelegantapproachtoavoidthe'YAGNI'[9]dilemma
whenbuildingnewsoftware.Thesetechniquesandthetoolinggrowinguparoundthem,
limittheneedforcentralcontractmanagementbydecreasingthetemporalcoupling
betweenservices.
Perhapstheapogeeofdecentralisedgovernanceisthebuildit/runit
ethospopularisedbyAmazon.Teamsareresponsibleforallaspectsof
thesoftwaretheybuildincludingoperatingthesoftware24/7.Devolution
ofthislevelofresponsibilityisdefinitelynotthenormbutwedoseemore
andmorecompaniespushingresponsibilitytothedevelopmentteams.
Netflixisanotherorganisationthathasadoptedthisethos[11].Being
wokenupat3ameverynightbyyourpageriscertainlyapowerful
incentivetofocusonqualitywhenwritingyourcode.Theseideasare
aboutasfarawayfromthetraditionalcentralizedgovernancemodelasit
ispossibletobe.

DecentralizedDataManagement

Manylanguages,manyoptions
ThegrowthofJVMasaplatformisjustthe
latestexampleofmixinglanguageswithina
commonplatform.It'sbeencommon
practicetoshellouttoahigherlevel
languagetotakeadvantageofhigherlevel
abstractionsfordecades.Asisdropping
downtothemetalandwritingperformance
sensitivecodeinalowerlevelone.However,
manymonolithsdon'tneedthislevelof
performanceoptimisationnorareDSL'sand
higherlevelabstractionsthatcommon(to
ourdismay).Insteadmonolithsareusually
singlelanguageandthetendencyistolimit
thenumberoftechnologiesinuse[10].

Decentralizationofdatamanagementpresentsinanumberofdifferent
ways.Atthemostabstractlevel,itmeansthattheconceptualmodelof
theworldwilldifferbetweensystems.Thisisacommonissuewhenintegratingacrossa
largeenterprise,thesalesviewofacustomerwilldifferfromthesupportview.Some
thingsthatarecalledcustomersinthesalesviewmaynotappearatallinthesupport
view.Thosethatdomayhavedifferentattributesand(worse)commonattributeswith
subtlydifferentsemantics.
Thisissueiscommonbetweenapplications,butcanalsooccurwithin
applications,particularwhenthatapplicationisdividedintoseparate
components.AusefulwayofthinkingaboutthisistheDomainDriven
DesignnotionofBoundedContext.DDDdividesacomplexdomainup
intomultipleboundedcontextsandmapsouttherelationshipsbetween
them.Thisprocessisusefulforbothmonolithicandmicroservice
architectures,butthereisanaturalcorrelationbetweenserviceand
contextboundariesthathelpsclarify,andaswedescribeinthesectionon
businesscapabilities,reinforcetheseparations.

Battletestedstandardsand
enforcedstandards
It'sabitofadichotomythatmicroservice
teamstendtoeschewthekindofrigid
enforcedstandardslaiddownbyenterprise
architecturegroupsbutwillhappilyuseand
evenevangelisetheuseofopenstandards
suchasHTTP,ATOMandother
microformats.

Aswellasdecentralizingdecisionsaboutconceptualmodels,
microservicesalsodecentralizedatastoragedecisions.Whilemonolithic
applicationspreferasinglelogicaldatabaseforpersistantdata,
enterprisesoftenpreferasingledatabaseacrossarangeofapplications
manyofthesedecisionsdriventhroughvendor'scommercialmodels
aroundlicensing.Microservicespreferlettingeachservicemanageits
owndatabase,eitherdifferentinstancesofthesamedatabase
technology,orentirelydifferentdatabasesystemsanapproachcalled
PolyglotPersistence.Youcanusepolyglotpersistenceinamonolith,but
itappearsmorefrequentlywithmicroservices.

Thekeydifferenceishowthestandardsare
developedandhowtheyareenforced.
Standardsmanagedbygroupssuchasthe
IETFonlybecomestandardswhenthereare
severalliveimplementationsoftheminthe
widerworldandwhichoftengrowfrom
successfulopensourceprojects.
Thesestandardsareaworldapartfrom
manyinacorporateworld,whichareoften
developedbygroupsthathavelittlerecent
programmingexperienceoroverlyinfluenced
byvendors.

Decentralizingresponsibilityfordataacrossmicroserviceshasimplicationsformanaging
updates.Thecommonapproachtodealingwithupdateshasbeentousetransactionsto
guaranteeconsistencywhenupdatingmultipleresources.Thisapproachisoftenused
withinmonoliths.
Usingtransactionslikethishelpswithconsistency,butimposessignificanttemporal
coupling,whichisproblematicacrossmultipleservices.Distributedtransactionsare
notoriouslydifficulttoimplementandandasaconsequencemicroservicearchitectures
emphasizetransactionlesscoordinationbetweenservices,withexplicitrecognitionthat
consistencymayonlybeeventualconsistencyandproblemsaredealtwithby
compensatingoperations.
Choosingtomanageinconsistenciesinthiswayisanewchallengeformanydevelopment
teams,butitisonethatoftenmatchesbusinesspractice.Oftenbusinesseshandlea
degreeofinconsistencyinordertorespondquicklytodemand,whilehavingsomekindof
reversalprocesstodealwithmistakes.Thetradeoffisworthitaslongasthecostof
fixingmistakesislessthanthecostoflostbusinessundergreaterconsistency.

InfrastructureAutomation
Infrastructureautomationtechniqueshaveevolvedenormouslyoverthelastfewyears
theevolutionofthecloudandAWSinparticularhasreducedtheoperationalcomplexityof
building,deployingandoperatingmicroservices.

Manyoftheproductsorsystemsbeingbuildwithmicroservicesarebeingbuiltbyteams
withextensiveexperienceofContinuousDeliveryandit'sprecursor,Continuous
Integration.Teamsbuildingsoftwarethiswaymakeextensiveuseofinfrastructure
automationtechniques.Thisisillustratedinthebuildpipelineshownbelow.

Figure5:basicbuildpipeline

Sincethisisn'tanarticleonContinuousDeliverywewillcallattentiontojustacoupleof
keyfeatureshere.Wewantasmuchconfidenceaspossiblethatoursoftwareisworking,
sowerunlotsofautomatedtests.Promotionofworkingsoftware'up'thepipelinemeans
weautomatedeploymenttoeachnewenvironment.
Amonolithicapplicationwillbebuilt,testedandpushedthroughthese
environmentsquitehapplily.Itturnsoutthatonceyouhaveinvestedin
automatingthepathtoproductionforamonolith,thendeployingmore
applicationsdoesn'tseemsoscaryanymore.Remember,oneofthe
aimsofCDistomakedeploymentboring,sowhetheritsoneorthree
applications,aslongasitsstillboringitdoesn'tmatter[12].
Anotherareawhereweseeteamsusingextensiveinfrastructure
automationiswhenmanagingmicroservicesinproduction.Incontrastto
ourassertionabovethataslongasdeploymentisboringthereisn'tthat
muchdifferencebetweenmonolithsandmicroservices,theoperational
landscapeforeachcanbestrikinglydifferent.

Figure6:Moduledeploymentoftendiffers

Designforfailure

Makeiteasytodotherightthing
Onesideeffectwehavefoundofincreased
automationasaconsequenceofcontinuous
deliveryanddeploymentisthecreationof
usefultoolstohelpdevelopersand
operationsfolk.Toolingforcreating
artefacts,managingcodebases,standingup
simpleservicesorforaddingstandard
monitoringandloggingareprettycommon
now.Thebestexampleonthewebis
probablyNetflix'ssetofopensourcetools,
butthereareothersincludingDropwizard
whichwehaveusedextensively.

Aconsequenceofusingservicesascomponents,isthatapplicationsneedtobedesigned
sothattheycantoleratethefailureofservices.Anyservicecallcouldfaildueto
unavailabilityofthesupplier,theclienthastorespondtothisasgracefullyaspossible.
Thisisadisadvantagecomparedtoamonolithicdesignasitintroducesadditional
complexitytohandleit.Theconsequenceisthatmicroserviceteamsconstantlyreflecton
howservicefailuresaffecttheuserexperience.Netflix'sSimianArmyinducesfailuresof
servicesandevendatacentersduringtheworkingdaytotestboththeapplication's
resilienceandmonitoring.
Thiskindofautomatedtestinginproductionwouldbeenoughtogive
mostoperationgroupsthekindofshiversusuallyprecedingaweekoff
work.Thisisn'ttosaythatmonolithicarchitecturalstylesaren'tcapableof
sophisticatedmonitoringsetupsit'sjustlesscommoninourexperience.

Thecircuitbreakerandproduction
readycode
CircuitBreakerappearsinReleaseIt!

alongsideotherpatternssuchasBulkhead
Sinceservicescanfailatanytime,it'simportanttobeabletodetectthe
andTimeout.Implementedtogether,these
failuresquicklyand,ifpossible,automaticallyrestoreservice.
patternsarecruciallyimportantwhen
Microserviceapplicationsputalotofemphasisonrealtimemonitoringof
buildingcommunicatingapplications.This
Netflixblogentrydoesagreatjobof
theapplication,checkingbotharchitecturalelements(howmanyrequests
explainingtheirapplicationofthem.
persecondisthedatabasegetting)andbusinessrelevantmetrics(such
ashowmanyordersperminutearereceived).Semanticmonitoringcan
provideanearlywarningsystemofsomethinggoingwrongthattriggersdevelopment
teamstofollowupandinvestigate.

Thisisparticularlyimportanttoamicroservicesarchitecturebecausethemicroservice
preferencetowardschoreographyandeventcollaborationleadstoemergentbehavior.
Whilemanypunditspraisethevalueofserendipitousemergence,thetruthisthat
emergentbehaviorcansometimesbeabadthing.Monitoringisvitaltospotbademergent
behaviorquicklysoitcanbefixed.
Monolithscanbebuilttobeastransparentasamicroserviceinfact,
theyshouldbe.Thedifferenceisthatyouabsolutelyneedtoknowwhen
servicesrunningindifferentprocessesaredisconnected.Withlibraries
withinthesameprocessthiskindoftransparencyislesslikelytobe
useful.
Microserviceteamswouldexpecttoseesophisticatedmonitoringand
loggingsetupsforeachindividualservicesuchasdashboardsshowing
up/downstatusandavarietyofoperationalandbusinessrelevant
metrics.Detailsoncircuitbreakerstatus,currentthroughputandlatency
areotherexamplesweoftenencounterinthewild.

EvolutionaryDesign

Synchronouscallsconsidered
harmful
Anytimeyouhaveanumberofsynchronous
callsbetweenservicesyouwillencounterthe
multiplicativeeffectofdowntime.Simply,
thisiswhenthedowntimeofyoursystem
becomestheproductofthedowntimesof
theindividualcomponents.Youfacea
choice,makingyourcallsasynchronousor
managingthedowntime.At
www.guardian.co.uktheyhaveimplemented
asimpleruleonthenewplatformone
synchronouscallperuserrequestwhileat
Netflix,theirplatformAPIredesignhasbuilt
asynchronicityintotheAPIfabric.

Microservicepractitioners,usuallyhavecomefromanevolutionarydesign
backgroundandseeservicedecompositionasafurthertooltoenable
applicationdeveloperstocontrolchangesintheirapplicationwithoutslowingdown
change.Changecontroldoesn'tnecessarilymeanchangereductionwiththeright
attitudesandtoolsyoucanmakefrequent,fast,andwellcontrolledchangestosoftware.
Wheneveryoutrytobreakasoftwaresystemintocomponents,you'refacedwiththe
decisionofhowtodivideupthepieceswhataretheprinciplesonwhichwedecideto
sliceupourapplication?Thekeypropertyofacomponentisthenotionofindependent
replacementandupgradeability[13]whichimplieswelookforpointswherewecan

imaginerewritingacomponentwithoutaffectingitscollaborators.Indeedmany
microservicegroupstakethisfurtherbyexplicitlyexpectingmanyservicestobescrapped
ratherthanevolvedinthelongerterm.
TheGuardianwebsiteisagoodexampleofanapplicationthatwasdesignedandbuiltas
amonolith,buthasbeenevolvinginamicroservicedirection.Themonolithstillisthecore
ofthewebsite,buttheyprefertoaddnewfeaturesbybuildingmicroservicesthatusethe
monolith'sAPI.Thisapproachisparticularlyhandyforfeaturesthatareinherently
temporary,suchasspecializedpagestohandleasportingevent.Suchapartofthe
websitecanquicklybeputtogetherusingrapiddevelopmentlanguages,andremoved
oncetheeventisover.We'veseensimilarapproachesatafinancialinstitutionwherenew
servicesareaddedforamarketopportunityanddiscardedafterafewmonthsoreven
weeks.
Thisemphasisonreplaceabilityisaspecialcaseofamoregeneralprincipleofmodular
design,whichistodrivemodularitythroughthepatternofchange[14].Youwanttokeep
thingsthatchangeatthesametimeinthesamemodule.Partsofasystemthatchange
rarelyshouldbeindifferentservicestothosethatarecurrentlyundergoinglotsofchurn.If
youfindyourselfrepeatedlychangingtwoservicestogether,that'sasignthattheyshould
bemerged.
Puttingcomponentsintoservicesaddsanopportunityformoregranularreleaseplanning.
Withamonolithanychangesrequireafullbuildanddeploymentoftheentireapplication.
Withmicroservices,however,youonlyneedtoredeploytheservice(s)youmodified.This
cansimplifyandspeedupthereleaseprocess.Thedownsideisthatyouhavetoworry
aboutchangestooneservicebreakingitsconsumers.Thetraditionalintegrationapproach
istotrytodealwiththisproblemusingversioning,butthepreferenceinthemicroservice
worldistoonlyuseversioningasalastresort.Wecanavoidalotofversioningby
designingservicestobeastolerantaspossibletochangesintheirsuppliers.

AreMicroservicestheFuture?
Ourmainaiminwritingthisarticleistoexplainthemajorideasandprinciplesof
microservices.Bytakingthetimetodothisweclearlythinkthatthemicroservices
architecturalstyleisanimportantideaoneworthseriousconsiderationforenterprise
applications.Wehaverecentlybuiltseveralsystemsusingthestyleandknowofothers
whohaveusedandfavorthisapproach.
Thoseweknowaboutwhoareinsomewaypioneeringthearchitecturalstyleinclude
Amazon,Netflix,TheGuardian,theUKGovernmentDigitalService,realestate.com.au,
Forwardandcomparethemarket.com.Theconferencecircuitin2013wasfullofexamples
ofcompaniesthataremovingtosomethingthatwouldclassasmicroservicesincluding
TravisCI.Inadditionthereareplentyoforganizationsthathavelongbeendoingwhatwe
wouldclassasmicroservices,butwithouteverusingthename.(Oftenthisislabelledas
SOAalthough,aswe'vesaid,SOAcomesinmanycontradictoryforms.[15])
Despitethesepositiveexperiences,however,wearen'targuingthatwearecertainthat
microservicesarethefuturedirectionforsoftwarearchitectures.Whileourexperiencesso
fararepositivecomparedtomonolithicapplications,we'reconsciousofthefactthatnot
enoughtimehaspassedforustomakeafulljudgement.

Oftenthetrueconsequencesofyourarchitecturaldecisionsareonly
evidentseveralyearsafteryoumadethem.Wehaveseenprojectswhere
agoodteam,withastrongdesireformodularity,hasbuiltamonolithic
architecturethathasdecayedovertheyears.Manypeoplebelievethat
suchdecayislesslikelywithmicroservices,sincetheserviceboundaries
areexplicitandhardtopatcharound.Yetuntilweseeenoughsystems
withenoughage,wecan'ttrulyassesshowmicroservicearchitectures
mature.
Therearecertainlyreasonswhyonemightexpectmicroservicesto
maturepoorly.Inanyeffortatcomponentization,successdependson
howwellthesoftwarefitsintocomponents.It'shardtofigureoutexactly
wherethecomponentboundariesshouldlie.Evolutionarydesign
recognizesthedifficultiesofgettingboundariesrightandthusthe
importanceofitbeingeasytorefactorthem.Butwhenyourcomponents
areserviceswithremotecommunications,thenrefactoringismuchharder
thanwithinprocesslibraries.Movingcodeisdifficultacrossservice
boundaries,anyinterfacechangesneedtobecoordinatedbetween
participants,layersofbackwardscompatibilityneedtobeadded,and
testingismademorecomplicated.

OurcolleagueSamNewmanspentmostof
2014workingonabookthatcapturesour
experienceswithbuildingmicroservices.This
shouldbeyournextstepifyouwanta
deeperdiveintothetopic.

AnotherissueisIfthecomponentsdonotcomposecleanly,thenallyou
aredoingisshiftingcomplexityfrominsideacomponenttothe
connectionsbetweencomponents.Notjustdoesthisjustmovecomplexityaround,it
movesittoaplacethat'slessexplicitandhardertocontrol.It'seasytothinkthingsare
betterwhenyouarelookingattheinsideofasmall,simplecomponent,whilemissing
messyconnectionsbetweenservices.
Finally,thereisthefactorofteamskill.Newtechniquestendtobeadoptedbymoreskillful
teams.Butatechniquethatismoreeffectiveforamoreskillfulteamisn'tnecessarily
goingtoworkforlessskillfulteams.We'veseenplentyofcasesoflessskillfulteams
buildingmessymonolithicarchitectures,butittakestimetoseewhathappenswhenthis
kindofmessoccurswithmicroservices.Apoorteamwillalwayscreateapoorsystemit's
veryhardtotellifmicroservicesreducethemessinthiscaseormakeitworse.
Onereasonableargumentwe'veheardisthatyoushouldn'tstartwithamicroservices
architecture.Insteadbeginwithamonolith,keepitmodular,andsplititintomicroservices
oncethemonolithbecomesaproblem.(Althoughthisadviceisn'tideal,sinceagoodin
processinterfaceisusuallynotagoodserviceinterface.)
Sowewritethiswithcautiousoptimism.Sofar,we'veseenenoughaboutthe
microservicestyletofeelthatitcanbeaworthwhileroadtotread.Wecan'tsayforsure
wherewe'llendup,butoneofthechallengesofsoftwaredevelopmentisthatyoucanonly
makedecisionsbasedontheimperfectinformationthatyoucurrentlyhavetohand.

Share:

ifyoufoundthisarticleuseful,pleaseshareit.I
appreciatethefeedbackandencouragement

Forarticlesonsimilartopics
takealookatthefollowingtags:
popular applicationarchitecture webservices
microservices

Footnotes
1:Theterm"microservice"wasdiscussedataworkshopofsoftwarearchitectsnearVeniceinMay,2011to
describewhattheparticipantssawasacommonarchitecturalstylethatmanyofthemhadbeenrecently
exploring.InMay2012,thesamegroupdecidedon"microservices"asthemostappropriatename.James
presentedsomeoftheseideasasacasestudyinMarch2012at33rdDegreeinKrakowinMicroservicesJava,
theUnixWayasdidFredGeorgeaboutthesametime.AdrianCockcroftatNetflix,describingthisapproachas
"finegrainedSOA"waspioneeringthestyleatwebscaleasweremanyoftheothersmentionedinthisarticle
JoeWalnes,DanNorth,EvanBotcherandGrahamTackley.
2:ThetermmonolithhasbeeninusebytheUnixcommunityforsometime.ItappearsinTheArtofUnix
Programmingtodescribesystemsthatgettoobig.
3:Manyobjectorienteddesigners,includingourselves,usethetermserviceobjectintheDomainDrivenDesign
senseforanobjectthatcarriesoutasignificantprocessthatisn'ttiedtoanentity.Thisisadifferentconceptto
howwe'reusing"service"inthisarticle.Sadlythetermservicehasbothmeaningsandwehavetolivewiththe
polyseme.
4:Weconsideranapplicationtobeasocialconstructionthatbindstogetheracodebase,groupoffunctionality,
andbodyoffunding.
5:TheoriginalpapercanbefoundonMelvynConway'swebsitehere
6:Atextremesofscale,organisationsoftenmovetobinaryprotocolsprotobufsforexample.Systemsusing
thesestillexhibitthecharacteristicofsmartendpoints,dumbpipesandtradeofftransparencyforscale.Most
webpropertiesandcertainlythevastmajorityofenterprisesdon'tneedtomakethistradeofftransparencycan
beabigwin.
7:Wecan'tresistmentioningJimWebber'sstatementthatESBstandsfor"EgregiousSpaghettiBox".
8:NetflixmakesthelinkexplicituntilrecentlyreferringtotheirarchitecturalstyleasfinegrainedSOA.
9:"YAGNI"or"YouAren'tGoingToNeedIt"isanXPprincipleandexhortationtonotaddfeaturesuntilyou
knowyouneedthem.
10:It'salittledisengenuousofustoclaimthatmonolithsaresinglelanguageinordertobuildsystemson
todaysweb,youprobablyneedtoknowJavaScriptandXHTML,CSS,yourserversidelanguageofchoice,SQL
andanORMdialect.Hardlysinglelanguage,butyouknowwhatwemean.
11:AdrianCockcroftspecificallymentions"developerselfservice"and"Developersrunwhattheywrote"(sic)in
thisexcellentpresentationdeliveredatFlowconinNovember,2013.
12:Wearebeingalittledisengenuoushere.Obviouslydeployingmoreservices,inmorecomplextopologiesis
moredifficultthandeployingasinglemonolith.Fortunately,patternsreducethiscomplexityinvestmentin
toolingisstillamustthough.
13:Infact,DanNorthreferstothisstyleasReplaceableComponentArchitectureratherthanmicroservices.
Sincethisseemstotalktoasubsetofthecharacteristicswepreferthelatter.
14:KentBeckhighlightsthisasonehisdesignprinciplesinImplementationPatterns.
15:AndSOAishardlytherootofthishistory.Irememberpeoplesaying"we'vebeendoingthisforyears"when
theSOAtermappearedatthebeginningofthecentury.Oneargumentwasthatthisstyleseesitsrootsasthe
wayCOBOLprogramscommunicatedviadatafilesintheearliestdaysofenterprisecomputing.Inanother
direction,onecouldarguethatmicroservicesarethesamethingastheErlangprogrammingmodel,butapplied
toanenterpriseapplicationcontext.

References
Whilethisisnotanexhaustivelist,thereareanumberofsourcesthatpractitionershavedrawninspirationfrom
orwhichespouseasimilarphilosophytothatdescribedinthisarticle.
Blogsandonlinearticles
ClemensVastersblogoncloudatmicrosoft
DavidMorgantinisintroductiontothetopiconhisblog
12factorappsfromHeroku
UKGovernmentDigitalServicedesignprinciples
JimmyNilssonsblogandarticleoninfoqaboutCloudChunkComputing
AlistairCockburnonHexagonalarchitectures
Books
Releaseit
Restinpractice
WebAPIDesign(freeebook).BrianMulloy,Apigee.
EnterpriseIntegrationPatterns
Artofunixprogramming
GrowingObjectOrientedSoftware,GuidedbyTests
TheModernFirm:OrganizationalDesignforPerformanceandGrowth
ContinuousDelivery:ReliableSoftwareReleasesthroughBuild,Test,andDeploymentAutomation
DomainDrivenDesign:TacklingComplexityintheHeartofSoftware
Presentations
ArchitecturewithoutArchitects.ErikDoernenburg.
Doesmybuslookbiginthis?.JimWebberandMartinFowler,QCon2008
GuerillaSOA.JimWebber,2006
PatternsofEffectiveDelivery.DanNorth,2011.
AdrianCockcroft'sslidesharechannel.
HydrasandHypermedia.IanRobinson,JavaZone2010
Justicewilltakeamillionintricatemoves.LeonardRichardson,Qcon2008.
Java,theUNIXway.JamesLewis,JavaZone2012
Microservicesarchitecture.FredGeorge,YOW!2012
Democratisingattentiondataatguardian.co.uk.GrahamTackley,GOTOAarhus2013
FunctionalReactiveProgrammingwithRxJava.BenChristensen,GOTOAarhus2013(registrationrequired).
BreakingtheMonolith.StefanTilkov,May2012.
Papers
L.Lamport,"TheImplementationofReliableDistributedMultiprocessSystems",1978http://
research.microsoft.com/enus/um/people/lamport/pubs/implementation.pdf
L.Lamport,R.Shostak,M.Pease,"TheByzantineGeneralsProblem",1982(availableat)http://
www.cs.cornell.edu/courses/cs614/2004sp/papers/lsp82.pdf
R.T.Fielding,"ArchitecturalStylesandtheDesignofNetworkbasedSoftwareArchitectures",2000
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
E.A.Brewer,"TowardsRobustDistributedSystems",2000http://www.cs.berkeley.edu/~brewer/cs262b
2004/PODCkeynote.pdf
E.Brewer,"CAPTwelveYearsLater:Howthe'Rules'HaveChanged",2012,http://
www.infoq.com/articles/captwelveyearslaterhowtheruleshavechanged

FurtherReading
Theabovelistcapturesthereferencesweusedwhenweoriginallywrotethis
articleinearly2014.Foranuptodatelistofsourcesformoreinformation,
takealookattheMicroserviceResourceGuide.

SignificantRevisions
25March2014:lastinstallmentonaremicroservicesthefuture?
24March2014:addedsectiononevolutionarydesign
19March2014:addedsectionsoninfrastructureautomationanddesignforfailure
18March2014:addedsectionondecentralizeddata

17March2014:addedsectionondecentralizedgovernance
14March2014:addedsectiononsmartendpointanddumbpipes
13March2014:addedsectiononproductsnotprojects
12March2014:addedsectiononorganizingaroundbusinesscapabilities
10March2014:publishedfirstinstallment

Guides
Intro
Videos
Design
Agile
NoSQL
DSL
Continuous
Delivery
Microservices
AboutMe

PopularArticles
Microservices
NewMethodology
DependencyInjection
Mocksaren'tStubs
IsDesignDead?
ContinuousIntegration
RichardsonMaturity
Model

Books

SiteSections

NoSQLDistilled
DomainSpecificLanguages
Refactoring
PatternsofEnterpriseApplicationArchitecture
UMLDistilled
AnalysisPatterns
PlanningExtremeProgramming
SignatureSeries

ThoughtWorks
Blogs
Careers
Mingle
Snap
Go

MartinFowler|PrivacyPolicy|Disclosures

FAQ
ContentIndex
Bliki
Books
DSLCatalog
EAACatalog
EAADev
Photos