Buzzwords often give context to concepts that evolved and needed a good “tag” to facilitate dialogue. Microservices is a new “tag” that defines areas I have personally been discovering and using for some time now. Articles and conferences described something that I slowly realized I had been evolving in my own personal experience for the past few years.

1. MicroservicesAnti-patterns
Buzzwordsoftengive contexttoconceptsthatevolvedandneededagood“tag” to facilitate
dialogue.Microservices isanew“tag” that definesareasIhave personallybeendiscoveringand
usingforsome time now. ArticlesandconferencesdescribedsomethingthatI slowlyrealizedIhad
beenevolvinginmyownpersonal experience forthe pastfew years.
What it Was, Was Microservices
Buzzwordsoftengive contexttoconceptsthatevolvedandneededagood“tag” to facilitate
dialogue.Microservicesisanew“tag” that definesareasIhave personallybeendiscoveringand
usingforsome time now. ArticlesandconferencesdescribedsomethingthatI slowlyrealizedIhad
beenevolvinginmyownpersonal experience forthe pastfew years. While industryand
professionaldiscussionsonMicroserviceshave giventhe limelighttothe companieslike Netflix,
Amazon,andGoogle and to the practitionerswhohave done itsuccessfully,Ihave some personal
experience thatcanprovide insighttosuccessful Microservicesimplementation.
The three standardand most commonbusinessdriversforanyarchitecture are:
>ImprovedAgility –The abilitytorespondtothe businessneedsinatimelyfashionsothatthe
businesscangrow
>ImprovedCustomerExperience–Improve the customerexperience sothatcustomerchurn is
reduced
>DecreasedCost– reduce the costto add more products,customersor businesssolutions
In fact,all of us are tryingto do thisin our day-to-daywork.SOA createsabusinessalignedsoftware
frameworkthatenablesthe enterprisetogetthere.Several large software vendorshave emerged
and claimedthattheirsuite of productscan enable the enterprise todeliverSOA.
If you do nothave the rightpeople,culture,andinvestment,SOA will notdeliverthe businessvalue.
Microservicesarchitecture isnotfundamentallydifferentfromSOA,the goalsandobjectivesare the
same but the approach isslightlyrefinedandinfact,IwouldsimplysaythatMicroservicesismere
SOA made scalable.Microservicesenablesapplications/systemsthatdesperatelymustmove away
froma monolithicimplementation,toadistributed,decentralized,servicesplatformservingmany
applications.Microservicesare independentthatembrace agilityandapplicationevolutionasan
enterprise digitallytransform.Microservicessuccessdependsuponthe service independenceand
the service flexibility.
I woulddefine Microservicesas“Anapproach todeliveringSOA bybuildingfine-grainedservicesto
supportbusinesscapabilitiesthatare distributedandorganizedasfunctional domains".Nopattern
isa magicwand or silverbullet.Youshouldconceive andtailorthe patterncorrectlyforan
enterprise.Enterprisesshouldfocusonresolvingthe itemsthatare requiredtosupportthe
architecture tomake an adaptive platform.
A fewenterprisesfailedintheirSOA implementationmiserably–because theydid notfullyanalyze
theirbusinesscapabilitymodel andconsidereddevelopingweb-servicesmeanSOA orbuyingaSOA

2. suite fromlarge vendorwouldmake themSOA-enabledorthe inabilitytoshow the alignment
betweenSOA andtheirbusinessdriver/goals.
For Example
An example fromexperience mightclarifythispoint.Atone pastjob,the enterprise wasaimingto
improve agility,customerexperience anddrive downcost.We decidedtobuildastandardmulti-
tenantSOA platform.The approachwas setto developfine-grainedservicessothatwe couldmake
changesveryoftenanddeploysmall,manageable changestothe platform.If we didthe same
approach today,we wouldlikelycall itmicroservicesarchitecture.Backthenwe didnothave this
term,but itjustmade sense.
Serviceswere modeledbasedonbusinesscapabilitymodel andthe firstrelease wentwell.They
were XML overJMS syncservicesandprimarilyfocusedondeliveringthe capabilitiesrequiredfor
claimsplatformexposedtoAgents,webandvoice channel application.Itgave usthe abilityto
deployfrequent,small changesandA/Bfeature supportseamlesslyforourapplications.
Whenthe requirementswere incrementallyadded(andtheyalwayswere) itwasveryhardto
release the solutionrapidlybecause of the integrationcomplexitybetweenapplicationsandthe
consumers.Integration,functional testing,andproductionreleaserequiredtightcoordination.As
the businessstartedtoexpandandthe changeswere 10x more frequentthanthe initial release,and
as most of the tasks indeliverylifecyclewere manual,the time tomarketdidnotmeetbusiness
expectation.Soon,none of ourgoalswere metas poorMicroservicesautomationandlifecycle
managementledtodeliveryentropy.
LessonsLearned – Don’tDo These Things,Instead…DoThese OTHERThings
Thisbringsme to share some of the lessonsthatI learnedaspart of my journeysothat youcan keep
an eye onthese itemswhenyouhitthe roadwithMicroservices
1) CohesionChaos
We developedaservice togetthe customerinformationdesignedtopull the customerpolicy
information,personal informationandthe planthattheyenrolledin.Overatime,itstartedtodo
more than gettingthe customerinformation.Asnew requirementscame in,thisservicewent
throughfrequentchangesanddeployments.Itwasunable toscale and meetthe required
availability.Itbecame the proverbial “Bigball of mud”. How didit getthere?For starters,there was
no governance aroundfunctional separationof concern.If aninfluentialconsumeraskingtoput
unrelatedlogicinthisone service toreduce roundtrips,thatfunctiongotslappedonwithout
question. Perhapsagatewayora BPMlayercouldhave avoidedthisscenario,butthere wasnotime
for that…justtime tocrank out anotherbusinessfunctionpoint.
The preventative cure istogovernbusinessfunctionalitiesthatare notrelevanttothe service.
Servicesmustalignclearlytoabusinesscapabilityandshouldnottryto do somethingoutsideof
theirboundary.Functional separationof concernisvital forarchitecture togovernotherwiseitwill
destroythe agility,performance,andscalabilityandendedupinestablishingatightlycoupled
architecture,resultingindeliveryentropyandcohesionchaos.

3. 2) Not takingAutomationSeriously
We didn'thave a strategyfor automateddeploymentandopsmonitoringof services(runtime QoS
metrics).Itobviouslyincreasedoperational expensesandmanual errorsduringdeployment.Several
timesproductiondeploymentscausedoutages due toconfigurationerrors.The serviceswere always
deployedinHA mode andsothe numberof containerswas3x to the total numberof services.The
operationsteamwasunable tohandle the configurationforeachservice manually.Afteracertain
time,opsstartedto complainthatthe architecture wasinefficientastheywere notable tohandle
the increasednumberof containers.
What isthe vaccine forthis?The recipe has multipleingredients. Continuousdeployment,if you
have not done so,isa mustinvestmentanda cultural change that everyenterprise shouldaimfor.
At least,if youdon'thave a wayto automaticallytestanddeploy –do notdo micro-services.
Microservicesare aimingtodrive agility,withthe speedwe needtochange;qualityassurance
involveseachservicehavingautomatedunit,functional,securityandperformance testing.Service
Virtualizationisanotherpowerful conceptwhenwe developservicesthatare integratedwith
servicesoutside of ourcontrol.
3) LayeredServicesArchitecture
One commonmistake people made withSOA weremisunderstandinghow toachieve the re-
usabilityof services.Teamsmostlyfocusedontechnical cohesionratherthanfunctionalregarding
reusability.Forexample,several servicesfunctionedasadata access layer(ORM) to expose tablesas
services;theythoughtitwouldbe highlyreusable.Thiscreatedanartificial physical layermanaged
by a horizontal team,whichcauseddeliverydependency.Anyservice createdshouldbe highly
autonomous – meaningindependentof eachother.
Creatingmultiple,technical,physical layersof serviceswouldonlycause deliverycomplexityand
runtime inefficiency.We endedupinhavingwrapperservices,orchestrationservices,business
servicesanddataservices.These servicemodelsservedtechnical concerns.Individual teamsformed
to manage these layersandendeduphavingbusinesslogicsprawl,nosingleownerfora capability,
lostthe efficiencyandthere wasalwaysablaminggame.
Logical separationof layerswithina service isfine,however,thereshouldnotbe anyoutof process
calls.Try to lookat a service asone atomic businessentity,whichmustimplementeverythingto
achieve the desiredbusinessfunctionality.The self-containedservicesare more autonomousand
scalable thanthe layeredservices.It'sperfecttore-write some commoncode acrossmultiple
services,that'sfine andit'sa good trade-off tokeepthe autonomylevel.The bottomline isthat
don't have servicesseparatedbytechnical concernsinstead theymustbe separatedbasedonthe
businesscapability.The conceptof containerizationisthrivingbecause of thischaracter.
4) RelyingonConsumerSign-off
We hada service consumedbymultipleapplicationsfromthree differentchannelsi.e.agent,the
web,andvoice.Agentchannel wasourprimary,sothe serviceshadtowaitto get theirsign-off
before theycango intoproduction.Itdelayedthe voice andwebapplicationproductionreleases.
What boundthose three channelstogethersotightly?

4. The service wasnot a looselycoupledwhenitcame tochannel specificfunctionality.Give
independencetoyourservices.Everyservicethatyoudelivermusthave a testsuite,whichshould
coverall the service functionality,security,performance,errorhandling,andconsumptiondriven
testingforeverycurrentandfuture consumer.Thismustbe includedaspart of the buildpipeline for
automatedregressiontesting.
5) Manual ConfigurationsManagement:
As we startedto doa largernumberof services(andthe inevitablesprawl due tolackof service
lifecycle governance manifesteditself) managingthe configurationsforeachservice wentoutof
control.Most of ourproductiondeploymentwasnotsmoothbecause of configurationfailureslike
the bad password,wrongURL, incorrectvalues.Itbecame harderandharder to manage these
manually.If we hadonlyusedapplicationconfigurationmanagementtoolsaspartof a PaaS or
CD…but we didn’t.
6) VersioningAvoidance:
Naively,we thoughtitwouldbe onlyneedone versionof the service.Thenwe startedtoaddmajor,
minorversionstoaccommodate multiple consumersandfrequentchanges.Eventually,every
release hadtobe a majorrelease since the serviceswere relyingonconsumersignoff.Asa result,
the numberof containersincreasedveryfastanditbecame a huge painto manage them.Lack of
runtime governance wasanotheraspectthatcontributedtothisissue.Some enterprisesfoolishlytry
to avoidversioning.Servicesneedtobe architectedassumingthatchange isinevitable. Have a
strategyto manage the forwardcompatible servicechangesandallow yourconsumerstoupgrade
gracefully.Otherwise,itwillleadtohaving consumerstightlyboundtoaservice versionandbreak
whenthere isa change.
The complexitygrowsasthe numberof servicesgrowswhichthe microservicesworldexpects.Have
a versioningstrategythatcanallowthe consumersagraceful migrationandassure providerscan
transparentlydeploychangeswithoutaffectinganyone.Limitthe numberof side-by-sidemajor
versionsinthe productionandgovernthem.
7) Buildingagatewayineveryservice
We didn'thave an APIgatewayandwe didn'thave runtime governance (we didn’tknow whowas
consumingwhatandat whatrate at whattime).We startedto implementend-userauthentication,
throttle,orchestrate,transform, androute etc.ineachservice.Itaddedcomplexitytoeachservice
and we lostconsistencyof implementationfromservice toservice,sowe hadno ideawho
implementedwhatandwhere.Ontopof it,some of our serviceswere builttosatisfyone consumer
non-functional requirements,butnotanother’s.If we hada gateway,applyingsome datafiltering
and enrichmentpatternscouldhave done it.If only.
InvestinAPIManagementsolutionstocentralize,manage andmonitorsome of the non-functional
concernsand whichwouldalsoeliminate the burdenof consumer'smanagingseveral microservices
configurations.APIgatewaycanbe usedorchestrate the cross-functional microservicesthatmay
reduce roundtripsfor webapplications.

5. Conclusion
The goal of microservicesistosolve the three mostcommonproblemsi.e.improvecustomer
experience, highlyagile tothe newrequirementsanddrive downcostbydeliveringthe business
functionsasfine grainedservices.Thisisnota silverbulletandrequiresadisciplinedplatform,
where deliveringthe servicesinanagile fashionwithhighqualityispossible.Learnfromother’s
mistakes(mine) andavoidthe above listedpatternsinthe architecture anddeliveryprocess.Thisis
the firstbaby stepbefore we caneventalkaboutcontainerization,cloudadoptionetc.Ihope this
article givesyousomethingtothinkaboutforyour enterprise andworktowardsresolvingtheseanti-
patternsbefore youweave themintoyourarchitectures.Mostof the itemswill drive cultural
changeswithinthe organizationandcannotbe done justbyyourself,ensurepartnershipwithyour
executiveandseniorleaders.
Source : infoq.com
Recommendedby:
JonCohn ,CTO, VP IT Architecture
https://www.linkedin.com/in/jonacohn
joncohn@comcast.net
"JonCohn ExtonPA""JonCohn Exton""JonCohnEvolution"