How to avoid microservice pitfalls
•Als PPTX, PDF herunterladen•
4 gefällt mir•567 views
There are many resources out there that walk you through the process of setting up distributed systems, queuing and asynchronous processes — with and without NServiceBus. Despite all the online education, teams continue to make the same common mistakes when designing and implementing microservices architecture. While the mistakes can have devastating consequences, they are easy to avoid when approached intentionally. Jeffrey Palermo and Justin Self share their experiences in overcoming common microservices pitfalls and show how NServiceBus naturally encourages better architecture, such as easy adherence to SOLID principles. Learn: * What a microservice really is (and is not) * What mistakes teams commonly make * How to avoid the pitfalls and design more robust and scalable architecture * How to equip your team for a microservices architecture
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie How to avoid microservice pitfalls
Ähnlich wie How to avoid microservice pitfalls (20)
Mehr von Particular Software
Mehr von Particular Software (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
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 jeffrey@clear-measure.com CEO, Clear Measure Justin Self @thejustinself justin.self@clear-measure.com Principal Solution Architect, Clear Measure David Boike @davidboike david.boike@particular.net 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 Jeffrey@clear-measure.com @jeffreypalermo Justin Self Justin.Self@clear-measure.com @thejustinself David Boike David.Boike@particular.net @davidboike
Hinweis der Redaktion
- David: Segregate team responsibilities Talk about Particular maintainer groups, organizationally multiple repos is a good idea anyway.
- Demo of AliasQL
- David - Talk about deploying messages with MyGet
- More details on snowflake services
- David : This is the approach we use at Particular as well We automate everything we can Conventions based on the endpoint name
- 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