The 7 Deadly Sins of Microservices

Spring eXchange 2014
Microservices Anti-patterns

Transcript

1. The 7 Deadly Sins of Microservices Tareq Abedrabbo - OpenCredo The Spring Exchange 2014, London
2. About me • CTO at OpenCredo • Spring user since 1.0 • Previously committer on Spring-WS!
3. Disclaimer: Any resemblance to existing projects, overrunning or axed, is purely intentional!
4. Microservices, as an emerging architectural style
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. • What languages do I need to support? • What libraries? • How dynamic and flexible does my implementation need to be?
11. keep it simple
12. 2. Porcine Cosmetics Failing to adopt a contract-first design approach
13. Always start by designing the contract of your service
14. Abstraction
15. Encapsulation
16. Composition
17. • Raison d’être of a any service! • The simplest form of composition is simple client invocation • A service can be composed in increasingly sophisticated ways, potentially leading to reuse
18. Contract-first services Seriously, we’ve known this for 10 years!
19. 3. Message in a Bottle Assuming the wrong communication protocol
20. • Microservices commonly use http or lightweight messaging to communicate • Messages can be binary (Protobuf, serialised objects, etc..) or human-readable (json, yaml, etc…) • Interfaces can be ReSTful, RPC-like, etc…
21. Don’t assume one communication pattern before understanding what you really need
22. • Simple request/response paradigm? • Message persistence? • Reliability? • Asynchronous notification?
23. Sometimes you need to mix styles
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” • A domain object model is used • to drive business logic • to map business entities to the database • to manage input & output
26. A shared domain model assumes that we are in full control the context and the boundaries within which the domain model is valid
27. • This is not the case for microservices • A shared domain model breaks encapsulation and introduces tight coupling between services: • Conceptually • At the implementation level by making a number of services dependant on common binary artefacts that are frequently changing
28. The domain in a microservices system should be defined by how services interact with each other, not how they are implemented
29. 5. The Distributed Monolith Defining inappropriate service boundaries
30. A distributed monolith is an application that indiscriminately externalises its own internal services
31. Microservices are not a remoting abstraction
32. • Internal application services often have the wrong granularity • They can have interdependencies • …or a dependency on a shared domain
33. Internal application components don’t always make good microservices
34. The result is an application that is monolithic but that needs to deal with issues related to remote objects as well
35. 6. The Horseless Cart Neglecting DevOps and Testing Concerns
36. • For a microservices implementation to be effective we need: • the ability to update, deploy and scale each service individually • while keeping services as simple as possible
37. • Testing services individually is not that hard • What is hard • Functional testing • Regression testing • Performance testing • Testing for failure
38. A continuous delivery pipeline should be an integral part of a microservices implementation, form the very start
39. 7. The Sausage Factory Disregarding the Human Factor
40. • Developers need to have good understanding of a number of essential concepts, including • Messaging • Fault-tolerance and resilience • Scalability • Integration concerns • And potentially learn a number of new technologies and tools
41. If anything, microservices forces us to come out of the rabbit hole!
42. Microservices do not make bad developers good. Invest in your developers.
43. –Melvin Conway “organisations which design systems […] are constrained to produce designs which are copies of the communication structures of these organisations.”
44. An obvious corollary to Conway’s law: organisations that operate in silos will not be able to benefit from a microservices architecture
45. Microservices do not fix broken organisations
46. Summary
47. • Resource-oriented design • Event-driven architectures • Separation of concerns based on data flow
48. Links • OpenCredo: http://www.opencredo.com/blog/ • Twitter: @tareq_abedrabbo Thank you! questions?
49. 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