Recommended
More Related Content
Similar to Study the past if you would define the future: How Gang of Four patterns are more relevant than ever with microservice architecture
Similar to Study the past if you would define the future: How Gang of Four patterns are more relevant than ever with microservice architecture (20)
Recently uploaded
Recently uploaded (20)
Study the past if you would define the future: How Gang of Four patterns are more relevant than ever with microservice architecture
- 1. Gang of Four’s Design Patterns for Microservices Hari Ramamurthy @hari_ram Thomas Gamble @gambtho
- 2. So you want to use microservices? image credit: @alvaro_sanchez
- 4. DDD - Landscape Layout the core domain. An example of such a model for a Retail order management system
- 5. DDD - Landscape With some domain boundaries color coded..
- 6. DDD – Customer order A more detailed view of just the customer order
- 7. DDD – Customer order Slice it up further, just keep references to every other domain and yet..
- 8. Takeaway It’s still a large domain, even if you slice it up Care needs to be taken to not add undue complexity when separating into bounded contexts As with microservices in general, DDD is all about balance
- 9. Creational Patterns On that Order domain model - Abstract Factory to create families of entities. - Singleton for some entities – like configurations - Builder to setup an order/configurator based order as a multi stage step
- 10. Service Discovery For instance Consul or Eureka (or platform provided) - Factory Pattern - Object pool
- 11. Structural Patterns On that Order domain model - The Order is a composite - Json/XML representations for most entities - Client interface specific Decorators and Adaptors - Aggregators services - Consumer driven contracts - Logic variations for discount calculations and representations by a Bridge
- 12. API Gateway Kong or Apigee or Zuul - Decorator - Facade - Proxy
- 13. Proxy – Circuit Breaker
- 14. Behavioral Patterns On that Order domain model - Every api that accepts a json/xml and has varied behavior based on the actual content of the message, leveraging “command” pattern - Either synchronous or async - Extensive usage of “iterators” for multiple loops - Heavy usage of “Observer”, all the event based triggers like sending an email on an action on the order or notifying a down stream system on an action like a cancellation. - “Chain of Responsibility” as we step through to the appropriate class or the appropriate micro service to handle an action for a specific scenario. - Delegating to the correct domain specific logic if a specialized one exists, like online specific cancellation rules. - Scratch pad for uncommitted change or database’s uncommitted transaction on orders would be a representation of “memento”
- 15. Event driven Kafka or Java streams or Akka - Actor - Observer Pattern
- 16. CQRS
- 17. Therefore.. Start with monolith - drivers license Organize team effectively Service discovery or Centralized Router Interservice communication – - circuit breaker Decentralized data issues - DDD
- 18. In summary Make your life easier by not reinventing the wheel Improve your object-oriented skills Recognize patterns in libraries, languages and technologies (or the need) Use the power of a shared vocabulary Find truth and beauty Credit : https://www.oreilly.com/ideas/5-reasons-to-finally-learn-design-patterns
- 19. The Goal
- 20. References https://www.oreilly.com/ideas/5-reasons-to-finally-learn-design-patterns http://www.oodesign.com/object-pool-pattern.html http://microservices.io http://martinfowler.com https://www.nginx.com/blog/building-microservices-inter-process-communication appcontinuum.io http://nordicapis.com/microservices-architecture-the-good-the-bad-and-what-you-could-be-doing- better https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture http://www.slideshare.net/alvarosanchezmariscal/stateless-authentication-for-microservices https://www.nginx.com/blog/building-microservices-using-an-api-gateway https://dzone.com/refcardz/getting-started-with-microservices
Editor's Notes
- Build a monolith firstBuild a monolith first Scale independently Upgrade/replace separately Easy to understand/maintain Supports more implement choices by developers We all know moving to microservices will solve all of your problems…....right? Not exactly.... This is not to say that microservices are a bad idea, but it’s important to understand what outcomes you want to achieve 1. do you need to scale certain portions of your application? – scale independently 2. are you only making changes in certain areas? 3. understandable purpose for each 4. organize so that teams can run independently
- So – lets assume you’re bought in, and have a reason to move there – Big ball of….”mud” arch. How do you move that to microservices...... Namespace -> Libraries -> Services extracting a service too earlier can be costly easier to refactor an in-process component easier to make interface changes before extraction example extract a service, implement remote facade at created seamed point application API gateway at the service sprout method extracting new behavior to a new method or class can then add tests/new behavior strangler - gradually create a new system around the edges of the old, letting it grow and strangled the old system
- Abstract Factory Creates an instance of several families of classes Builder Separates object construction from its representation Factory Method Creates an instance of several derived classes Object Pool Avoid expensive acquisition and release of resources by recycling objects that are no longer in use Prototype A fully initialized instance to be copied or cloned Singleton A class of which only a single instance can exist
- Object pool – remove the need to instantiate new copies for each service, LB can scale up/down based on need Factory – declare what you need, and let it be created Given the need to communicate across services, need an easy way to find your dependencies Typically register on startup, and refreshed/removed based on health monitor/heartbeat Client Side – client aware of registry, and uses provided information to call correct service instance Server Side – simplifies client logic, requests made to load balance (LB must be HA) – often provided by platform
- Adapter Match interfaces of different classes Bridge Separates an object's interface from its implementation Composite A tree structure of simple and composite objects Decorator Add responsibilities to objects dynamically Facade A single class that represents an entire subsystem Flyweight A fine-grained instance used for efficient sharing Private Class Data Restricts accessor/mutator access Proxy An object representing another object
- As we move to microservices, it’s important to not pass on all of the complexity to our clients. One way to avoid this is using a API gateway Lots of open source and commercial choices for this – utilizing a variety of design patterns Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. Wrap a complicated subsystem with a simpler interface. Benefit encapsulates the internal structure of the application Reduction of round trip calls Drawbacks Must be highly available Potential development bottleneck
- Decorator Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. Client-specified embellishment of a core object by recursively wrapping it. Wrapping a gift, putting it in a box, and wrapping the box. Proxy Provide a surrogate or placeholder for another object to control access to it. Use an extra level of indirection to support distributed, controlled, or intelligent access. Add a wrapper and delegation to protect the real component from undue complexity.
- Chain of responsibility A way of passing a request between a chain of objects Command Encapsulate a command request as an object Interpreter A way to include language elements in a program Iterator Sequentially access the elements of a collection Mediator Defines simplified communication between classes Memento Capture and restore an object's internal state Null Object Designed to act as a default value of an object Observer A way of notifying change to a number of classes State Alter an object's behavior when its state changes Strategy Encapsulates an algorithm inside a class Template method Defer the exact steps of an algorithm to a subclass Visitor Defines a new operation to a class without change
- Service based approaches separate state – but still need to communicate state between them request/response or event based options Microservices architectures are renowned for being eventually consistent, given that there are multiple datastores that store state within the architecture. Individual microservices can themselves be strongly consistent, but the system as a whole may exhibit eventual consistency in parts. Eventual consistency -- one should consider the use of an event-driven architecture where data-changes in one microservice are relayed to interested microservices through events. A pub-sub messaging architecture may be employed to realize the event-driven architecture. One microservice may publish events as they occur in its context, and the events wouldResilientResponsiveElasticMessage-driven Observer Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. Encapsulate the core (or common or engine) components in a Subject abstraction, and the variable (or optional or user interface) components in an Observer hierarchy. The "View" part of Model-View-Controller.
- Command Query Responsibility Segregation having the same conceptual model for commands and queries leads to a more complex model that does neither well. CQRS allows you to separate the load from reads and writes allowing you to scale each independently.
- Componentization as a Service: bringing certain components together to make a customized service. Organized Around Business Capabilities: segregating capabilities for specific business areas like user interface and external integrations. Development Process is Based on Products Not Projects: following Amazon’s “eat your own dog food,” developers stay with the software for the product’s lifetime. Smart Endpoints and Dumb Pipes: each microservice is as decoupled as possible with its own domain logic. Decentralized Governance: enabling developer choice to build on preferred languages for each component. Decentralized Data Management: having each microservice label and handle data differently. Infrastructure Automation: including automated deployment up the pipeline. Design for Failure: meaning that more ongoing testing of “what if” has to occur to prepare for failure Things to Avoid excessive mapping code between architectural layers and across transport protocols developers spending more time writing code external to the core domain developers having to find ways to build or leverage tools that will help them understand what is going on in the ecosystem. straying away from lean programming and due to a lack of a wholesome understanding of microservice ecosystems, and attempting to tackle hypothesized problems ahead of time. slow ramp up times for new hires when they first roll on a project because of the number of technologies and sometimes a lack of uniformity in the patterns used across microservice code bases
- http://nordicapis.com/microservices-architecture-the-good-the-bad-and-what-you-could-be-doing-better/ 1. Domain-Driven Design: Functional decomposition can be easily achieved using Eric Evans’s DDD approach. 2. Single Responsibility Principle: Each service is responsible for a single part of the functionality, and does it well. 3. Explicitly Published Interface: A producer service publishes an interface that is used by a consumer service. 4. Independent DURS (Deploy, Update, Replace, Scale): Each service can be independently deployed, updated, replaced, and scaled. 5. Lightweight communication: REST over HTTP, STOMP over WebSocket, and other similar lightweight pro 1. Independent scaling: Each microservice can scale independently via X-axis scaling (cloning with more CPU or memory) and Z-axis scaling (sharding), based upon their needs. This is very different from monolithic applications, which may have very different requirements that must be deployed together. 2. Independent upgrades: Each service can be deployed independent of other services. Any change local to a service can be easily made by a developer without requiring coordination with other teams. For example, performance of a service can be improved by changing the underlying implementation. As a result this maintains the agility of the microservice. This is also a great enabler of CI/CD. 3. Easy maintenance: Code in a microservice is restricted to one function and is thus easier to understand. IDEs can load the smaller amounts of code more easily, and increased readability can keep developers more productive. 4. Potential heterogeneity and polyglotism: Developers are free to pick the language and stack that are best suited Componentization as a Service: bringing certain components together to make a customized service. Organized Around Business Capabilities: segregating capabilities for specific business areas like user interface and external integrations. Development Process is Based on Products Not Projects: following Amazon’s “eat your own dog food,” developers stay with the software for the product’s lifetime. Smart Endpoints and Dumb Pipes: each microservice is as decoupled as possible with its own domain logic. Decentralized Governance: enabling developer choice to build on preferred languages for each component. Decentralized Data Management: having each microservice label and handle data differently. Infrastructure Automation: including automated deployment up the pipeline. Design for Failure: meaning that more ongoing testing of “what if” has to occur to prepare for failure Things to Avoid excessive mapping code between architectural layers and across transport protocols developers spending more time writing code external to the core domain developers having to find ways to build or leverage tools that will help them understand what is going on in the ecosystem. straying away from lean programming and due to a lack of a wholesome understanding of microservice ecosystems, and attempting to tackle hypothesized problems ahead of time. slow ramp up times for new hires when they first roll on a project because of the number of technologies and sometimes a lack of uniformity in the patterns used across microservice code bases
- Pivotal.io