How to avoid microservice pitfalls

Download How to avoid microservice pitfalls

Post on 24-Jan-2017




1 download

Embed Size (px)


<p>How To AvoidMicroservice Pitfalls</p> <p></p> <p>1</p> <p>Jeffrey Palermo@jeffreypalermojeffrey@clear-measure.comCEO, Clear Measure</p> <p>Justin Self@thejustinselfjustin.self@clear-measure.comPrincipal Solution Architect, Clear Measure</p> <p>David Boike@davidboikedavid.boike@particular.netSolution Architect, Particular</p> <p>What is and isnt a microservice?It IS a service that encapsulates one capability or function.It ISNT a service that has multiple responsibilities.</p> <p>3</p> <p>Microservice PitfallsAnd how to get around them</p> <p>Pitfall: More than one microservice in a repositoryDifficult to enforce complete separationCI/CD and Build chains become complicatedIntroduces more codeClutters the repo historyDifficult to segregate team responsibilities</p> <p>5</p> <p>Guidance: One microservice per repo</p> <p>Its generally freeSimplified CI/CD pipelineFocused historyEasy to hold the entire repo in your mindPromotes best tool for job </p> <p>David: Segregate team responsibilitiesTalk about Particular maintainer groups, organizationally multiple repos is a good idea anyway.</p> <p>6</p> <p>Pitfall: More than one microservice per databaseData ownership becomes muddledAllows for cross dependencies between other microservicesLeads to using one storage hammer for all storage needsComplicates deploymentsDatabase and service code are coupledForced to scale and shard all data at the same time</p> <p>Guidance: Each microservice gets at least one private datastore</p> <p>Pick the right data storage for the given requirementExpose APIs for querying important dataUse NServiceBus events to propagate data between services if neededAvoid schema only abstractionsAutomate all database migrations and interactionsSQL QueriesDocument patchesIndex creationsEtc.</p> <p>Demo of AliasQL8</p> <p>Pitfall: Making everything publicPromotes a tangled mess of dependencies2016 version of dependency hellVersioning becomes difficultExposing all commands is like making all methods public</p> <p>Guidance: Create boundaries</p> <p>Group your microservices by capabilitiesShare events, not commands outside of the boundariesAPIs could act as boundaries</p> <p>Source: @adrianco</p> <p>David - Talk about deploying messages with MyGet10</p> <p>Pitfall: Coupled deploymentsLockstep deploymentsNo versioning scheme for APIsHard coding service locations</p> <p>11</p> <p>Guidance: Make them independent</p> <p>Version APIs from day oneDont HTTP all the thingsPass messages unless you shouldntUse service discovery tools and proxiesConsulNGINXDNS</p> <p>12</p> <p>Pitfall: Automation as an afterthoughtWaiting to implement CI/CDSnowflake serversPets vs cattle approachNo iteration zero repoNo centralized logging and monitoring</p> <p>More details on snowflake services13</p> <p>Guidance: Automate all the things</p> <p>Forces a level of consistency among all servicesConfiguration as codeLog, log and log some moreImplement consistent health checkingEmbrace build tools and taskspsakeCakeBatch files</p> <p>David :This is the approach we use at Particular as wellWe automate everything we canConventions based on the endpoint name</p> <p>14</p> <p>Pitfall:Thinking microservices are a panacea</p> <p>15</p> <p>Guidance:Approach microservices like buying a horse</p> <p>David :Ive seen plenty of examples of companies thinking microservices should be used for everything, or that its a quick fix.Its a way to deliberately build systems that are maintainable for the long term</p> <p>16</p> <p>Jeffrey</p> <p>Thank You</p> <p>Questions?</p> <p></p> <p>18</p>