Design patterns for microservice architecture
7 likes•24,059 views
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 microservice architecture x
- 2. whoami • Lead Software Developer @ The Software House • adiqpl @ twitter • [email protected] • linkedin.com/in/adrianzmenda Adrian Zmenda
- 3. What we’ll cover today • Basics • Communication • Internal Communication • Security • Availability • Configuration • Logging
- 4. Should I use microservices?
- 5. What is a microservice? • Loosely coupled • Independently deployable • Highly maintainable and testable • Organized around business capabilities • Owned by a small team
- 6. When microservices are good idea • Complex application • High scalability • Rapid and frequent delivery
- 7. Drawbacks • running distributed system is hard • maintaining consistency is challenging • ops complexity is high
- 8. Should I start with microservices?
- 9. Monolith
- 12. Modular Monolith source: Simon Brown
- 13. Can we go even further?
- 14. Self-Contained System source: Roman Stranghöner
- 15. Self-Contained System sooo, it’s like microservices. right?
- 16. Communication
- 17. Direct
- 18. Gateway
- 21. Remote Procedure Invocation • Synchronous • Simple • Easy to understand • Follows Request / (Response)
- 22. REST • Familiar • Based on HTTP • No intermediate broker source: nginx
- 23. Apache Thrift • Backed by Facebook • Language neutral contract-file • Code generation • Support for notifications
- 24. • Backed by Google • Calls visible as internal • Code generation • Simple contracts (Protocol Buffers)
- 25. Message Broker • Asynchronous • Follows Publish / Subscribe • Increases complexity source: nginx
- 26. Message Broker
- 28. Security
- 29. No ACL • Simple • Rarely possible • No additional over-head
- 30. ACL in every microservice • Duplication of ACL logic • Redistributes ACL across all microservices • Contexts mixing
- 31. ACL as dependent microservice • 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. Availability
- 34. ?
- 35. ? DNS
- 43. Consul • Service Registry • Healthchecking • Key/Value Storage • Secure Communication • Multi Datacenter
- 44. Handle Failures • Define network timeouts • Limit no. of outstanding requests • Provide fallbacks
- 45. Circuit Braker
- 46. Configuration
- 48. One configuration to rule them all { "sectionA":{ "valueA":"ABC123", "valueB":"XYZ321" }, "sectionB":{ "valueC":"ABC123", "valueD":"XYZ321" } }
- 49. One configuration to rule them all { "sectionA":{ "valueA":"ABC123", "valueB":"XYZ321" }, "sectionB":{ "valueC":"ABC123", "valueD":"XYZ321" } } { "sectionA":{ "valueA":"ABC123", "valueB":"XYZ321" } }
- 51. How to debug microservices? • Aggregate all logs in one place • Track Exceptions • Trace requests • Visualize
- 53. Measure • Monitor relevant platform details: • execution time of db queries; • request execution time; • number of request per minute; • response times; • success/failure ratio; • resources usage
- 54. Prometheus
- 55. Grafana
- 56. Now, we can do microservices the right way
- 57. Can we do them fast?
- 58. Define standards / contracts
- 59. Embrace tooling
- 60. Example: Service structure generation
- 61. Example: GRPC code generation
- 62. Example: GRPC code generation
- 63. How to organize microservices in code repositories?
- 64. Multi-repository • Pros: • better owner (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: • easy to 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 twice if 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 our upcoming webinars! Sign up for our newsletter! ✍ tsh.io/newsletter
- 70. Thanks 😉 tsh.io