Jon Cohn Exton PA - Microservices anti
•Als DOCX, PDF herunterladen•
1 gefällt mir•541 views
Jon Cohn Exton PA
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (16)
Ähnlich wie Jon Cohn Exton PA - Microservices anti
Ähnlich wie Jon Cohn Exton PA - Microservices anti (20)
Mehr von Jon Cohn
Mehr von Jon Cohn (10)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Jon Cohn Exton PA - Microservices anti
- 1. MicroservicesAnti-patterns What it Was,Was Microservices Buzzwordsoftengive contexttoconceptsthatevolvedandneededagood“tag” to facilitate dialogue.Microservices isanew“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 theydidnotfullyanalyze theirbusinesscapabilitymodel andconsidereddevelopingweb-servicesmeanSOA orbuyingaSOA suite fromlarge vendorwouldmake themSOA-enabledorthe inabilitytoshow the alignment betweenSOA andtheirbusinessdriver/goals. For Example
- 2. 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 syncservices andprimarilyfocusedondeliveringthe 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,andproductionreleaserequired tightcoordination.As the businessstartedtoexpandandthe changeswere 10x more frequentthanthe initial release,and as most of the tasks indeliverylifecyclewere manual,the time tomarketdidnotmeetbusiness expectation.Soon,none of ourgoals were metas poorMicroservicesautomationandlifecycle managementledtodeliveryentropy. LessonsLearned – Don’tDo These Things,Instead…DoThese OTHERThings Thisbringsme to share some of the lessonsthatI learnedaspart of my journeysothat you can 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. 2) Not takingAutomationSeriously We didn'thave a strategyfor automateddeploymentandopsmonitoringof services(runtime QoS metrics).Itobviouslyincreasedoperational expensesandmanual errorsduringdeployment.Several timesproductiondeploymentscausedoutagesdue toconfigurationerrors.The serviceswere always
- 3. 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 layersandendeduphavingbusiness logicsprawl,nosingleownerfora capability, lostthe efficiencyandthere wasalwaysablaminggame. Logical separationof layerswithinaservice 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 concernsinsteadtheymustbe 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? The service wasnot a looselycoupledwhenitcame tochannel specificfunctionality.Give independencetoyourservices.Everyservicethatyoudelivermusthave a testsuite,whichshould coverall the service functionality,security,performance,error handling,andconsumptiondriven
- 4. testingforeverycurrentandfuture consumer.Thismustbe includedaspart of the buildpipeline for automatedregressiontesting. 5) Manual ConfigurationsManagement: As we startedto doa largernumberof services(and the 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,itwillleadtohavingconsumerstightlyboundtoaservice 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. Conclusion The goal of microservicesistosolve the three mostcommonproblemsi.e.improvecustomer experience, highlyagile tothe newrequirementsanddrive downcostbydeliveringthe business
- 5. functionsasfine grainedservices.Thisisnota silverbulletandrequiresadisciplinedplatform, where deliveringthe servicesinanagile fashionwithhighqualityispossible.Learnfromother’s mistakes(mine) andavoidthe above listedpatternsinthe architecture and deliveryprocess.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" https://docs.google.com/document/d/1jhU5Mis7YoGzJvK85coGd8yZIHs-JnCG_cyz- p_y9Jk/edit?usp=sharing http://issuu.com/jonacohn/docs/jon.cohn.resume.docx https://www.scribd.com/doc/294344968/Jon-cohn-Resume http://www.slideshare.net/jonacohn/joncohnresume https://penzu.com/p/e1f1fb23 http://jonacohn.tumblr.com/post/136671484928/jon-a-cohn https://jonacohn.wordpress.com/2016/01/06/jon-a-cohn/ http://jonacohn.blogspot.com/2016/01/jon-cohn-resume.html www.slideserve.com/jonacohn/jon-a-cohn-exton-pa http://www.authorstream.com/Presentation/jonacohn-2711402-jon-cohn-exton-pa-19341/ www.slideserve.com/jonacohn/jon-a-cohn-exton-pa http://slideonline.com/presentation/99077-jon-a-cohn-exton-pa https://docs.google.com/document/d/1NJujdCMyQTF9qReGp6oMbmvWBXWEqP- u1avWwEMAgmo/edit?usp=sharing https://plus.google.com/105089455909133040148/posts/1j3SQfwm6QW http://jonacohn.blogspot.com/2016/01/knowledge-management-in-software.html http://docslide.net/technology/knowledge-management-in-software-architecture-.html http://issuu.com/jonacohn/docs/knowledge_management_in_software_ar https://www.scribd.com/doc/294345138/Knowledge-Management-in-Software-Architecture http://www.slideshare.net/jonacohn/knowledge-management-in-software-architecture