How To AvoidMicroservice Pitfalls
www.clear-measure.comwww.particular.netgithub.com/ClearMeasureLabs/cm-particular-webinar
1
Jeffrey Palermo@[email protected], Clear Measure
Justin [email protected]@clear-measure.comPrincipal Solution Architect, Clear Measure
David [email protected]@particular.netSolution Architect, Particular
What is and isnt a microservice?It IS a service that encapsulates one capability or function.It ISNT a service that has multiple responsibilities.
3
Microservice PitfallsAnd how to get around them
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
5
Guidance: One microservice per repo
Its generally freeSimplified CI/CD pipelineFocused historyEasy to hold the entire repo in your mindPromotes best tool for job
David: Segregate team responsibilitiesTalk about Particular maintainer groups, organizationally multiple repos is a good idea anyway.
6
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
Guidance: Each microservice gets at least one private datastore
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.
Demo of AliasQL8
Pitfall: Making everything publicPromotes a tangled mess of dependencies2016 version of dependency hellVersioning becomes difficultExposing all commands is like making all methods public
Guidance: Create boundaries
Group your microservices by capabilitiesShare events, not commands outside of the boundariesAPIs could act as boundaries
Source: @adrianco http://www.slideshare.net/adriancockcroft/qcon-new-york-speed-and-scale
David - Talk about deploying messages with MyGet10
Pitfall: Coupled deploymentsLockstep deploymentsNo versioning scheme for APIsHard coding service locations
11
Guidance: Make them independent
Version APIs from day oneDont HTTP all the thingsPass messages unless you shouldntUse service discovery tools and proxiesConsulNGINXDNS
12
Pitfall: Automation as an afterthoughtWaiting to implement CI/CDSnowflake serversPets vs cattle approachNo iteration zero repoNo centralized logging and monitoring
More details on snowflake services13
Guidance: Automate all the things
Forces a level of consistency among all servicesConfiguration as codeLog, log and log some moreImplement consistent health checkingEmbrace build tools and taskspsakeCakeBatch files
David :This is the approach we use at Particular as wellWe automate everything we canConventions based on the endpoint name
14
Pitfall:Thinking microservices are a panacea
15
Guidance:Approach microservices like buying a horse
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
16
Jeffrey [email protected]@jeffreypalermoJustin [email protected]@thejustinselfDavid [email protected]@davidboike
Thank You
Questions?
github.com/ClearMeasureLabs/cm-particular-webinar
18