Microservices - The good, The bad, The does and The don'ts
Download as PPTX, PDF2 likes738 views
The document discusses microservices, highlighting their benefits such as strong modularity, independent deployment, and technology diversity. It also outlines the challenges including operational complexity, distribution issues, and eventual consistency concerns. Best practices for microservices include maintaining helpful documentation, monitoring, and consistent API conventions, while bad practices include dictating architecture and using shared databases.
Microservices - The good, The bad, The does and The don'ts
- 1. Microservices - The good, the bad and the ugly
- 2. - A small service that does one thing well - Independent - Owner of its own data Clear definition of a microservice https://blog.codeship.com/microservices-best-practices/
- 5. Strong Module Boundaries • Microservices reinforce modular structure, which is particularly important for larger teams. https://martinfowler.com/microservices/
- 6. Independent Deployment • Simple services are easier to deploy, and since they are autonomous, are less likely to cause system failures when they go wrong. https://martinfowler.com/microservices/
- 7. Technology Diversity • With microservices you can mix multiple languages, development frameworks and data-storage technologies. https://martinfowler.com/microservices/
- 9. Distribution • Distributed systems are harder to program • Calls between services are • Slower • Always at risk of failure. • Hard to follow through services https://martinfowler.com/microservices/
- 10. Eventual Consistency • Maintaining strong consistency is extremely difficult for a distributed system, which means everyone has to manage eventual consistency. https://martinfowler.com/microservices/
- 11. Operational Complexity • You need a mature operations team to manage lots of services, which are being redeployed regularly. https://martinfowler.com/microservices/
- 12. Best Practices
- 13. Helpful documentation • You no longer write the whole system and so you need to make it easy to integrate with the services. https://blog.codeship.com/microservices-best-practices/
- 14. Built with monitoring and troubleshooting in mind • Distributed systems easily becomes very complex and following requests is no longer just following stack traces. https://blog.codeship.com/microservices-best-practices/
- 15. Easily deployable and scalable • Deploying often and scaling the services when needed is a big benefit of using microservices. https://blog.codeship.com/microservices-best-practices/
- 16. Easy to consume • Make sure your consumers can hit the API directly in a nonproduction environment. https://blog.codeship.com/microservices-best-practices/ Develop Test Stable Production
- 17. Coexists with established conventions • Make sure the microservices API is consistent and follow predefined conventions • Content format • Date format • Error responses • Etc… https://blog.codeship.com/microservices-best-practices/
- 18. Bad Practices
- 19. Dictating the architecture • This interferes with product team’s responsibility which is one of the more important aspects of microservices and breaks the feedback loop from the actual code back to the design https://www.infoq.com/news/2015/01/bad-practices-microservices
- 20. A dedicated DBA or shared database • A Prevents a team from • optimizing their database structures • choosing the storage engine that best fits the for the specific service • Approval needed - creates confusion about who owns the different tables • Reluctance of removing anything in fear of destroying products for other teams. https://www.infoq.com/news/2015/01/bad-practices-microservices
- 21. A shared code base that is not owned by the teams • The code must be shared by all teams with each developer able to send a pull request. • Only utility logic should be shared • sharing domain logic breaks the boundaries between contexts https://www.infoq.com/news/2015/01/bad-practices-microservices
- 22. Preferring SDKs over APIs • Leads to one platform enforced on all teams • SDKs introduces another level of complexity • Forcing a team to support both a service’ public API as well as the client code that uses the API. https://www.infoq.com/news/2015/01/bad-practices-microservices