Microservices Design Patterns
0 likes730 views
The document discusses microservices architecture and its evolution from traditional design patterns, emphasizing the use of loosely coupled services and RESTful web services. It introduces various tools and frameworks like Postman, Curl, and gRPC for API development and management. Additionally, it outlines challenges and solutions associated with database management in microservices, including the use of shared databases and message queues for communication.
Microservices Design Patterns
- 1. Microservices Architecture Haim Michael January 3rd , 2023 All logos, trade marks and brand names used in this presentation belong to the respective owners. life michae l www.lifemichael.com Design Patterns
- 2. Introduction
- 3. 01/03/23 © Abelski eLearning 3 Design Pattern? “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King and Shlomo Angel. A Pattern Language. Oxford University Press, New York, 1977.
- 4. 01/03/23 © Abelski eLearning 4 Software Design Pattern? “Software patterns are reusable solutions to recurring problems that we encounter during software development.” Mark Grand, Patterns in Java. John Wiley & Sons, 2002.
- 5. 01/03/23 © Abelski eLearning 5 History The idea of using patterns evolves from the architecture field. Christopher Alexander. A Pattern Language: Towns, Buildings, Construction (Oxford University Press, 1977) The first GUI software patterns were set in 1987. Ward Cunningham and Kent Beck. Using Pattern Languages for Object-Oriented Programs. OOPSLA-87. The Gang of Four (AKA GOF) publish their “Design Patterns” book in 1994. Erich Gamma, Richard Helm, John Vlissides, and Ralph Johnson. Design Patterns. Addison Wesley, 1994.
- 6. 01/03/23 © Abelski eLearning 6 The Pattern Elements Each Pattern has the following elements: Pattern Name The official well known name we use to refer each one of the patterns. Problem Description A description of the problem the pattern comes to solve. Solution Description A description of the design solution. This element can include UML diagram and a code sample. Consequences The benefits & costs of using a specific design pattern. This element is required in order to evaluate one pattern comparing with others.
- 7. 01/03/23 © Abelski eLearning 7 Continuous Evolvement Apart of the classic design patterns described by the Gang of Four book, during the last 20 years we can identify many more design patterns that evolved in specific domains (e.g. Server Side), specific programming languages paradigms (e.g. Functional Programming), specific architectures (e.g. Microservices Architecture), and specific programming languages (e.g. JavaScript).
- 9. © 2008 Haim Michael 20150805 The Microservices Architecture The microservices architecture is a modern variation of the Service-Oriented Architecture (SOA). Instead of developing one monolithic application we develop multiple separated small fine grained applications that provide their service using a lightweight protocol.
- 10. © 2008 Haim Michael 20150805 Loosely Coupling Services Each and every micro-service is independent of the others. This loosely coupling architecture reduced the dependencies between the services.
- 11. © 2008 Haim Michael 20150805 REStful Web Services Representational state transfer (REST) is a software architectural style that dominates the World Wide Web. REST emphasizes the scalability of interactions between components, uniform interfaces, independent deployment of components, and the creation of a layered architecture to facilitate caching components to reduce user-perceived latency, enforce security, and encapsulate legacy systems.
- 12. © 2008 Haim Michael 20150805 REStful Web Services REST has been employed throughout the software industry and is a widely accepted set of guidelines for creating stateless, reliable web APIs. Web APIs that obey the REST constraints is informally described as RESTful.
- 13. © 2008 Haim Michael 20150805 REStful Web Services RESTful web APIs are typically loosely based on HTTP methods to access resources via URL-encoded parameters and the use of JSON or XML to transmit data.
- 14. © 2008 Haim Michael 20150805 REStful Web Services This image was taken from https://en.wikipedia.org/wiki/Representational_state_transfer
- 15. © 2008 Haim Michael 20150805 The postman Platform Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration. We can download the Postman application and use it for checking web APIs we want to use. https://postman.com
- 16. © 2008 Haim Michael 20150805 The postman Platform
- 17. © 2008 Haim Michael 20150805 The curl Utility The curl utility is a command line tool and library for transferring data with URLs. https://curl.se
- 18. © 2008 Haim Michael 20150805 The curl Utility
- 19. © 2008 Haim Michael 20150805 The grpc Framework gRPC is a modern open source high performance Remote Procedure Call (RPC) framework. This framework allows us to connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication.
- 20. © 2008 Haim Michael 20150805 The grpc Framework This framework is also relevant in last mile of distributed computing. We can use gRPC for connecting devices, mobile applications and browsers to backend services. https://grpc.io
- 21. © 2008 Haim Michael 20150805 The grpc Framework
- 22. Data Management
- 23. 01/03/23 © Abelski eLearning 23 Database Per Service Most services need to persist data, and they usually use a database for doing so (e.g. invoices service stores information about invoices we issue, customers service stores information about customers, etc.). The Services must be loosely coupled in order to allow us to develop, deploy and scale them independently. The Problem
- 24. 01/03/23 © Abelski eLearning 24 Database Per Service There are many cases in which there is a need to query data managed by multiple micro services. Different micro services might have different requirements, which might lead to the use of relational databases in some of the cases, and the use of no-sql databases in others. The Problem
- 25. 01/03/23 © Abelski eLearning 25 Database Per Service The solution for these problems might be having a separated persistent data for each and every micro service, and have a separated API (for each and every micro service), that uses that persist data only. We can allocate private tables per service, we can allocate schema per service, and we can allocate a separated database. The Solution
- 26. 01/03/23 © Abelski eLearning 26 Database Per Service Implementing this pattern ensures that the services are loosely coupled. Changes to one service’s database won't cause impact any other services. Each and every service can use the type of database that is best suited to its needs. Consequences
- 27. 01/03/23 © Abelski eLearning 27 Shared Database Microservices might need to implement ACID (Atomicity, Consistency, Isolation, and Durability) transactions. The Problem
- 28. 01/03/23 © Abelski eLearning 28 Shared Database We can share a single database between different micro services in order to allow those micro services to implement ACID transactions. The Solution
- 29. 01/03/23 © Abelski eLearning 29 Shared Database The developers can easily implement ACID transactions when working with a single database. The single database is simpler to handle. The development of the entire server side might be slower due to the need to coordinate between different developers that work on different micro services every schema change. The coupling between the micro services increases. Consequences
- 30. 01/03/23 © Abelski eLearning 30 Shared Database When the server side is up and running the increased coupling between the micro services might damage the performance of our server side. Single database for multiple microservices might be not the optimal one for some of the microservices. Consequences
- 31. Communication
- 32. 01/03/23 © Abelski eLearning 32 Message Queue Pattern When implementing the micro services architecture, we might have micro services that need to communicate with each other. This communication needs to be asynchronous in order to keep the micro services loosely coupled. The Problem
- 33. 01/03/23 © Abelski eLearning 33 Message Queue Pattern The solution would be to implement a message queue component that allows communication between processes or between threads in the same process. The Solution Image Credit to AWS
- 34. 01/03/23 © Abelski eLearning 34 Message Queue Pattern The message queues provide an asynchronous communication protocol in which the sender and receiver don't need to interact at the same time. The messages are held in a queue until the recipient retrieves them. The Solution
- 35. 01/03/23 © Abelski eLearning 35 Message Queue Pattern When implementing the micro services architecture, this pattern allows multiple micro services to communicate with each other asynchronously. The Consequences