The 7 Deadly Sins of Microservices

MuCon 2014

Transcript

1. The 7 Deadly Sins of Microservices Tareq Abedrabbo - MuCon 2014
2. About me CTO at OpenCredo Author, developer, open-source committer, with a long term interest in service-based architecture
3. Disclaimer Any resemblance to existing projects, overrunning or axed, is purely intentional!
4. What are microservices?
5. Microservices Design Principles Tools Decoupling Separation of concerns Encapsulation Engineering Practices Spring Boot RabbitMQ Hystrix Automation Scalability Fault-tolerance Continuous Delivery Testing Dropwizard Config Management
6. Why microservices anti-patterns?
7. 1. The Enterprise-OSGI-Application-Service-Bus Building the wrong thing
8. There is no unique way to implement microservices
9. Don't build what you don't need - think about your goals and your non-goals
10. Questions to ask: - What languages do I need to support? - What libraries? - How dynamic and flexible does my implementation need to be?
11. Communicate goals and non-goals. Keep it simple.
12. 2. Porcine Cosmetics Failing to adopt a contract-first design approach
13. Why do we need service contracts?
14. Abstraction
15. Encapsulation
16. Composition
17. Always start by designing the contract of your service (CDD, it is like TDD but for microservices!)
18. Seriously, we've known this for 10 years!
19. 3. Message in a Bottle Assuming the wrong communication protocol
20. Typically, microservices use http or lightweight messaging to communicate. Messages can be binary or human-readable
21. Don't enforce one particular communication pattern before understanding what you really need
22. Do I need: - Simple request/response paradigm? - Message persistence? - Reliability? - Asynchronous notification?
23. Distinguish between services: external vs internal core vs supporting
24. 4. The Single Domain of Failure Introducing a shared domain model
25. Designing a shared domain model is common in a monolithic architecture (it is even a best practice!)
26. Things domain models are used for: - drive business logic - map business entities to the database - manage input & output
27. The shared domain model fallacy: we are in full control of the context and the boundaries of the application
28. A shared domain model breaks encapsulation and introduces coupling between services
29. Shared dependency on volatile binary artefacts makes deployments really hard
30. Define the domain in terms of service interaction, not service implementation
31. Resource-oriented design
32. 5. The Distributed Monolith Defining inappropriate service boundaries
33. A distributed monolith is an application that externalises its internal services indiscriminately
34. Internal application components don't always make good microservices
35. Internal application services: - often have the wrong granularity - can have interdependencies - or a dependency on a shared domain
36. Microservices are not a remoting abstraction
37. Design services that have business meaning and clear boundaries
38. 6. The Horseless Cart Neglecting Macro System Concerns
39. Microservices: micro vs macro (macro is often missed)
40. Macro things to think about: - updating, deploying and scaling services independently - functional, performance and regression testing - system-wide behaviour, including failure scenarios
41. Design for a distributed system (runtime introspection, fault-tolerance, latency, failure, etc...)
42. Introduce continuous delivery and automated testing form the very start
43. 7. The Sausage Factory Disregarding the Human Factor
44. In microservices world, developers need to have good understanding of: - Messaging - Scalability, fault-tolerance and resilience - Integration and remoting And potentially learn a few new technologies and tools
45. Monolithic architecture is a rabbit hole!
46. Microservices do not make up for the gaps in your developers' skills
47. Invest in your developers
48. –Melvin Conway “organisations which design systems […] are constrained to produce designs which are copies of the communication structures of these organisations.”
49. Corollary organisations that operate in silos cannot benefit from a microservices architecture
50. Microservices do not fix broken organisations
51. Collaboration on a microservices project between: - devs and ops - techies and business - and across teams
52. The essence of microservices is collaboration
53. In conclusion
54. Microservices: it feels a little bit like quantum mechanics!
55. Hopefully, we can now begin to have pragmatic answers to questions such as: - How do I design a (micro)service? - How big or small should a service be? - Should a microservices be reusable?
56. Links Microservice anti-patterns: http://bit.ly/ microservices-antipatterns OpenCredo: http://www.opencredo.com/blog Twitter: @tareq_abedrabbo Personal blog: http://www.terminalstate.net Thank you! Any questions?
57. Credits • https://unsplash.com/ • The horseless cart: https://www.flickr.com/photos/ ellesmerefnc/4249596803/ • Message in a bottle: https://www.flickr.com/photos/ rpenalozan/5128413528