How To AvoidMicroservice Pitfalls

www.clear-measure.comwww.particular.netgithub.com/ClearMeasureLabs/cm-particular-webinar

1

Jeffrey Palermo@jeffreypalermojeffrey@clear-measure.comCEO, Clear Measure

Justin Self@thejustinselfjustin.self@clear-measure.comPrincipal Solution Architect, Clear Measure

David Boike@davidboikedavid.boike@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 PalermoJeffrey@clear-measure.com@jeffreypalermoJustin SelfJustin.Self@clear-measure.com@thejustinselfDavid BoikeDavid.Boike@particular.net@davidboike

Thank You

Questions?

github.com/ClearMeasureLabs/cm-particular-webinar

18