How to avoid microservice pitfalls
Download as PPTX, PDF4 likes572 views
The document discusses common pitfalls in microservice architectures and provides guidance on avoiding them. Key pitfalls include using more than one microservice per repository or database, making services public, coupled deployments, and treating automation as an afterthought. Recommendations emphasize the importance of isolation between services, appropriate data storage strategies, and automation from the beginning.
How to avoid microservice pitfalls
- 1. How To Avoid Microservice Pitfalls www.clear-measure.com www.particular.net github.com/ClearMeasureLabs/cm-particular-webinar
- 2. Jeffrey Palermo @jeffreypalermo [email protected] CEO, Clear Measure Justin Self @thejustinself [email protected] Principal Solution Architect, Clear Measure David Boike @davidboike [email protected] Solution Architect, Particular
- 3. What is and isn’t a microservice? It IS a service that encapsulates one capability or function. It ISN’T a service that has multiple responsibilities.
- 4. Microservice Pitfalls And how to get around them
- 5. Pitfall: More than one microservice in a repository • Difficult to enforce complete separation • CI/CD and Build chains become complicated • Introduces more code • Clutters the repo history • Difficult to segregate team responsibilities
- 6. Guidance: One microservice per repo • It’s generally free • Simplified CI/CD pipeline • Focused history • Easy to hold the entire repo in your mind • Promotes best tool for job
- 7. Pitfall: More than one microservice per database • Data ownership becomes muddled • Allows for cross dependencies between other microservices • Leads to using one storage hammer for all storage needs • Complicates deployments • Database and service code are coupled • Forced to scale and shard all data at the same time
- 8. Guidance: Each microservice gets at least one private datastore • Pick the right data storage for the given requirement • Expose API’s for querying important data • Use NServiceBus events to propagate data between services if needed • Avoid schema only abstractions • Automate all database migrations and interactions • SQL Queries • Document patches • Index creations • Etc.
- 9. Pitfall: Making everything public • Promotes a tangled mess of dependencies • 2016 version of dependency hell • Versioning becomes difficult • Exposing all commands is like making all methods public
- 10. Guidance: Create boundaries • Group your microservices by capabilities • Share events, not commands outside of the boundaries • API’s could act as boundaries Source: @adrianco http://www.slideshare.net/adriancockcroft/ qcon-new-york-speed-and-scale
- 11. Pitfall: Coupled deployments • Lockstep deployments • No versioning scheme for APIs • Hard coding service locations
- 12. Guidance: Make them independent • Version APIs from day one • Don’t “HTTP all the things” • Pass messages unless you shouldn’t • Use service discovery tools and proxies • Consul • NGINX • DNS
- 13. Pitfall: Automation as an afterthought • Waiting to implement CI/CD • Snowflake servers • Pets vs cattle approach • No “iteration zero” repo • No centralized logging and monitoring
- 14. Guidance: Automate all the things • Forces a level of consistency among all services • Configuration as code • Log, log and log some more • Implement consistent health checking • Embrace build tools and tasks • psake • Cake • Batch files
- 15. Pitfall: Thinking microservices are a panacea
- 16. Guidance: Approach microservices like buying a horse
- 17. Thank You Jeffrey Palermo [email protected] @jeffreypalermo Justin Self [email protected] @thejustinself David Boike [email protected] @davidboike
Editor's Notes
- #7: David: Segregate team responsibilities Talk about Particular maintainer groups, organizationally multiple repos is a good idea anyway.
- #9: Demo of AliasQL
- #11: David - Talk about deploying messages with MyGet
- #14: More details on snowflake services
- #15: David : This is the approach we use at Particular as well We automate everything we can Conventions based on the endpoint name
- #17: David : I’ve seen plenty of examples of companies thinking microservices should be used for everything, or that it’s a quick fix. It’s a way to deliberately build systems that are maintainable for the long term