Downloaded 128 times
Uploaded byThe Software House
Design patterns for microservice architecture
The document discusses the fundamentals of microservice architecture, touching on aspects such as design patterns, communication methods, security, and the pros and cons of using microservices. It emphasizes the importance of careful consideration and resource availability before adopting a microservices approach and highlights various tools and best practices for effective implementation. Furthermore, it provides insights on organizing microservices in code repositories and suggests embracing standards and contracts for successful microservice operations.
Design patterns for microservice architecture
- 1. Design patterns for microservicearchitecture x
- 2. whoami • Lead SoftwareDeveloper @ The Software House • adiqpl @ twitter • adrian@zmenda.com • linkedin.com/in/adrianzmenda Adrian Zmenda
- 3. What we’ll covertoday • Basics • Communication • Internal Communication • Security • Availability • Configuration • Logging
- 4. Should I usemicroservices?
- 5. What is amicroservice? • Loosely coupled • Independently deployable • Highly maintainable and testable • Organized around business capabilities • Owned by a small team
- 6. When microservices aregood idea • Complex application • High scalability • Rapid and frequent delivery
- 7. Drawbacks • running distributedsystem is hard • maintaining consistency is challenging • ops complexity is high
- 8. Should I startwith microservices?
- 9.
- 10.
- 11.
- 12.
- 13. Can we goeven further?
- 14. Self-Contained System source: RomanStranghöner
- 15. Self-Contained System sooo, it’slike microservices. right?
- 16.
- 17.
- 18.
- 19.
- 20.
- 21. Remote Procedure Invocation •Synchronous • Simple • Easy to understand • Follows Request / (Response)
- 22. REST • Familiar • Basedon HTTP • No intermediate broker source: nginx
- 23. Apache Thrift • Backedby Facebook • Language neutral contract-file • Code generation • Support for notifications
- 24. • Backed byGoogle • Calls visible as internal • Code generation • Simple contracts (Protocol Buffers)
- 25. Message Broker • Asynchronous •Follows Publish / Subscribe • Increases complexity source: nginx
- 26.
- 27.
- 28.
- 29. No ACL • Simple •Rarely possible • No additional over-head
- 30. ACL in everymicroservice • Duplication of ACL logic • Redistributes ACL across all microservices • Contexts mixing
- 31. ACL as dependentmicroservice • ACL defined as single microservice • Prevents duplication and redistribution • Could be a Single Point of Failure
- 32. ACL on Gateway •ACL on Gateway (could be implemented as microservice) • No duplicated ACL code in microservices • No huge over-head, simplifies internal communication
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43. Consul • Service Registry •Healthchecking • Key/Value Storage • Secure Communication • Multi Datacenter
- 44. Handle Failures • Definenetwork timeouts • Limit no. of outstanding requests • Provide fallbacks
- 45.
- 46.
- 47.
- 48. One configuration torule them all { "sectionA":{ "valueA":"ABC123", "valueB":"XYZ321" }, "sectionB":{ "valueC":"ABC123", "valueD":"XYZ321" } }
- 49. One configuration torule them all { "sectionA":{ "valueA":"ABC123", "valueB":"XYZ321" }, "sectionB":{ "valueC":"ABC123", "valueD":"XYZ321" } } { "sectionA":{ "valueA":"ABC123", "valueB":"XYZ321" } }
- 50.
- 51. How to debugmicroservices? • Aggregate all logs in one place • Track Exceptions • Trace requests • Visualize
- 53. Measure • Monitor relevantplatform details: • execution time of db queries; • request execution time; • number of request per minute; • response times; • success/failure ratio; • resources usage
- 54.
- 55.
- 56. Now, we cando microservices the right way
- 57. Can we dothem fast?
- 58. Define standards /contracts
- 59.
- 60. Example: Service structuregeneration
- 61. Example: GRPC codegeneration
- 62. Example: GRPC codegeneration
- 63. How to organizemicroservices in code repositories?
- 64. Multi-repository • Pros: • betterowner (team) separation; • clear scope • Cons: • hard to keep consistency (versioning is complex); • risk of becoming a monolith; • introduces more CI/CD setup costs
- 65. Mono-repository • Pros: • easyto maintain consistency; • easier versioning • Cons: • different teams may affect each other; • might lead to tight coupling; • longer build times
- 66. • Databases • Testing •CI / CD as essential tool • Destructive Testing • Deployments • many, many more… What we didn’t covered today youtu.be/D8l19VEokBA
- 67. Summary • think twiceif you really need a microservice architecture • ensure you have all necessary resources to operate distributed systems • make cold and educated decisions what’s best for your case, not netflix • embrace contracts and tooling
- 68. Resources • microservices.io • martinfowler.com/microservices •scs-architecture.org • codingthearchitecture.com • nginx.com/blog/introduction-to-microservices
- 69. Don’t miss ourupcoming webinars! Sign up for our newsletter! ✍ tsh.io/newsletter
- 70.