pictures: sxc.hu
Philippe Collet, with a set of slides assembled by Sébastien Mosser Microservices Architectures 30.09.2019
pictures: sxc.hu @MELANIECEBULA / SEPT 2017 / FUTURESTACK
From Monolith to Microservices:
How to Scale Your Architecture
Developing applications A pattern language for with a microservice microservices architecture Chris Richardson
Founder of Eventuate.io Chris Richardson Founder of the original CloudFoundry.com Author of POJOs in Action Author of POJOs in Action
@crichardson Founder of the original CloudFoundry.com [email protected] http://microservices.io @crichardson http://eventuate.io [email protected] http://plainoldobjects.com http://plainoldobjects.com @crichardson @crichardson ARAF KARSH HAMID Co-Founder / CTO MetaMagic Global Inc., NJ, USA Domain @arafkarsh arafkarsh Driven Design / Architecture Microservices Novotel Techpark, Bangalore, June 22, 2018 Bangalore, Techpark, Novotel World Agile Testing & Automation & Testing Agile World https://1point21gws.com/testingsummit/bangalore Co Founder / CTO, MetaMagic Global Inc., NJ, USA NJ, Inc.,Global MetaMagic CTO, / Founder Co – Part 1 : Infrastructure Comparison & 1 : Infrastructure Part Araf Karsh Hamid Hamid Karsh Araf will have its own Code Pipeline for build and deployment functionalities and it’s scope will scope be defined functionalities and it’s build will and deployment have its Code Pipeline own for
3D � 2 � 3
���� 3 Design Styles (DDD, Event Sourcing / CQRS, Functional Reactive Programming) Reactive Functional CQRS, / Sourcing Event (DDD, Design Styles arafkarsh
= Micro Services Architecture Micro @arafkarsh Micro Service Founder Founder CTO / ) - � A Services will between Micro be on and the Business Capabilities the interoperability focusing the Boundedby Context using message achieved based communication. ( � ARAF KARSH ARAF HAMID KARSH Co USA Global NJ, MetaMagic Inc., 1 � = � The AirBnB Case Study “Monorail” OUR MONOLITHIC RUBY ON RAILS APPLICATION
1 GitHub repo 1 SRE Sysops 4000000
3000000 When it starts to become a problem 2000000 MONORAIL LOC 1000000
0 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 Democratic deploys All developers are expected to “own” their features from implementation to production.
Each developer is expected to: • deploy their changes • monitor their changes • roll back, abort, or revert if necessary Scaling Deploy Process
• builds, tests, and deploys must be fast and reliable • ping authors when they need to take action • automatic (and fast) reverts • merge queue • automatic rollbacks for new exceptions Why Not Microservices? Why Microservices?
• Distributed systems • Independent are hard! deployment • Naming things is • Modular structure / hard! Ownership • Having to support • Secure / Performant different languages / • Upgrading frameworks dependencies Why Microservices? SCALING CONTINUOUS DELIVERY Why Microservices? Deploys per week (all apps, all environments) Why Microservices?
75,000 production deploys per year Services 900 300 4k developers services deploys per week Splitting the Monolith
UI Layer API Layer Monorail P1 P2 P3 P4
Vertical concerns Horizontal concerns Splitting the Monolith
UI Layer API Layer
Vertical concerns
Horizontal concerns 1. Monolith first 2. Devops culture 3. Configuration as code 4. Monitoring and Alerting The important part 5. Continuous delivery 10 TAKEAWAYS 6. Automate what you can 7. Your first service is going to be bad 8. Services own their own data 9. Break apart the Monolith 10. Standardize service creation Elements of Domain-driven design 2 Understanding Requirement Analysis using DDD
Bounded Context
Areas of the domain treated independently
Discovered as you assess requirements and build language
15 April 2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 19 2 DDD : Understanding Bounded Context 20 • DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships. • Bounded Contexts have both unrelated concepts • Such as a support ticket only existing in a customer support context • But also share concepts such as products and customers. • Different contexts may have completely different models of common concepts with mechanisms to map between these polysemic Source: BoundedContext By Martin Fowler : concepts for integration. http://martinfowler.com/bliki/BoundedContext.html
15 April 2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 2 DDD: Bounded Context – Strategic Design
Semi Cooked An App User’s Journey can run across Recipes Frozen multiple Bounded Context / Micro Chef Steward Raw Services. uses Materials Tables Dinning User Journey X Order Appetizer Veg Main Course Reservation uses Veg Menu Appetizer Non Bounded Bounded Bounded Veg Context Context Context Main Course Soft Drinks Hot Drinks Desserts Non Veg
Dinning Semi Cooked Kitchen Recipes Frozen Context Areas of the domain treated Context Chef independently Steward Raw uses Materials Tables Dinning Order Appetizer Veg Main Course Discovered as you assess Reservation uses Veg requirements and build language Menu Appetizer Non Veg Main Course Soft Drinks Hot Drinks Desserts Non Veg
Source: Domain-Driven Design App (DDD) of a Restaurant Bounded Context Understanding 8/10/2018 Reference by Eric Evans Menu Context 13 2 DDD: Ubiquitous Language: Strategic Design
Ubiquitous Vocabulary shared by Used in all forms of spoken / Language all involved parties written communication
Restaurant Context – Food Item : Role-Feature-Reason Matrix Analyst Developers Eg. Food Item (Navrathnakurma) As an Restaurant Owner Domain I want to know who my Customers are can have different meaning or Expert properties depends on the So that I can serve them better context. BDD Construct
• In the Menu Context it’s a Ubiquitous QA Veg Dish. Language Given Customer John Doe exists • In the Kitchen Context it’s is recipe. When Customer orders food • And in the Dining Context it will have more info Assign customer preferences Design Test Cases Then related to user feed back Docs as Veg or Non Veg customer etc. Code BDD – Behavior Driven Development
10 August 2018 14 2 125 Understanding Aggregate Root Domain Driven • An aggregate will have one of its component Design objects be the aggregate root. Any references Aggregate Root Customer from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as a whole. Order * Line Item Line Item • Aggregates are the basic element of transfer of Line Item data storage - you request to load or save whole aggregates. Transactions should not cross Shipping aggregate boundaries. Address Payment • Aggregates are sometimes confused with Strategy collection classes (lists, maps, etc.).
Bank Transfer • Aggregates are domain concepts (order, clinic visit, playlist), while collections are generic. An aggregate will often contain multiple collections, Cash
together with simple fields. Credit Card Source: Martin Fowler : Aggregate Root
(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 17 2 Designing and Fine Tuning Aggregate Root Aggregate Root - #1 Aggregate Root - #2 10 August August 2018 10
Super Dense Single Aggregate Root Super Dense Aggregate Root is split into 4 Results in Transaction concurrency issues. different smaller Aggregate Root in the 2nd Iteration. Working on different design models helps the developers to come up with best possible design. Source : Effective Aggregate Design Part 1/2/3 : Vaughn Vernon http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf
(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 18 2 Anemic Domain Model : Anti Pattern 25 • There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. • The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. • The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented design; which is to combine data and process together. • The anemic domain model is really just a procedural style design, exactly the kind of thing that object bigots like me (and Eric) have been fighting since our • lockUser() early days in Smalltalk. • unlockUser() • addAddress(String address) • removeAddress(String address)
Source: Anemic Domain Model By Martin Fowler : http://martinfowler.com/bliki/AnemicDomainModel.html 2 Event Sourcing & CQRS (Command and Query Responsibility Segregation) • In traditional data management systems, both commands (updates to the data) and queries (requests for data) are executed against the same set of entities in a single data repository.
• CQRS is a pattern that segregates the operations that read data (Queries) from the operations that update data (Commands) by using separate interfaces.
• CQRS should only be used on specific portions of a system in Bounded Context (in DDD). (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA JERSEY, NEW INC., GLOBALMETAMAGIC COPYRIGHT(C)
• CQRS should be used along with Event Sourcing.
Java Axon Framework Resource : http://www.axonframework.org Axon CQS : Greg MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx | Framework Bertrand Meyer Young Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html For Java
6/24/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 29 2 Source: https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs CRUD and CQRS https://blogs.msdn.microsoft.com/maarten_mullender/2004/07/23/crud-only-when-you-can-afford-it-revisite
Traditional CRUD Architecture CRUD Disadvantages Presentation • A mismatch between the read and write representations of the data. Services • It risks data contention when records are locked in Business Logic the data store in a collaborative domain, where multiple actors operate in parallel on the same set of
Data Access data. These risks increase as the complexity and throughput of the system grows.
Queries Updates • It can make managing security and permissions more complex because each entity is subject to both read and write operations, which might expose data Data Store in the wrong context.
8/10/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 33 2 Event Sourcing Intro
Standard CRUD Operations – Customer Profile – Aggregate Root
Profile Created Title Updated New Address added Notes Removed
Time T1 T2 T3 T4
Event Sourcing and Derived Aggregate Root
Commands Events Event store 1. Create Profile 1. Profile Created Event Derived 2. Update Title 2. Title Updated Event Greg 3. Add Address 3. Address Added Event Current State of the Young 4. Delete Notes 4. Notes Deleted Event Customer Profile
2 3 Single Source of Truth 4
8/10/2018 35 2 Restaurant Dining – Event Sourcing and CQRS Processes 1 When people arrive at the Restaurant and take a table, a Table is opened. They may then order drinks and food. Drinks are served immediately by the table staff, however food must be cooked by a chef. Once the chef prepared the food it can then be served. Table is closed then the bill is prepared. Customer Journey thru Dinning Processes ES Aggregate Commands 2 • Open Table • Remove Soda 4 • Add Juice • Add Food 1 • Serve Drinks • Prepare Bill • Add Drinks • Add Soda • Add Food 2 • Prepare Food • Process • Dinning Order • Add Food • Add Appetizer 1 • Place Order • Serve Food Payment • Billable Order • Update Food • Add Appetizer 2 • Close Table
Food Menu Dining Kitchen Order Payment Microservices
Events 3 • Table Opened • Remove Soda • Juice Served • Drinks Added • Juice Added • Food 1 Added • Soda Served • Payment Approved • Bill Prepared • Food Added • Soda Added • Food 2 Added • Appetizer Served • Payment Declined • Payment Processed • Food Updated • Appetizer 1 Added • Order Placed • Food Prepared • Cash Paid • Food Discontinued • Appetizer 2 Added • Table Closed • Food Served
8/10/2018 The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles. 36 2 Summary – Event Sourcing and CQRS
1. Immutable Events 2. Events represents the state change in Aggregate Root 3. Aggregates are Derived from a Collection of Events. 4. Separate Read and Write Models 5. Commands (originated from user or systems) creates Events. 6. Commands and Queries are always separated and possibly reads and writes using different data models.
6/24/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 34 2 Design Patterns – Holy Grail of Developers
Design Patterns are solutions to general problems that software developers faced during software development.
8/10/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 39 Microservice Architecture (and hexagonal ones) Pioneers in Microservices Implementation
New Entrants
4/15/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 2 1 A Adapters OrderService Hexagonal Architecture Interface Ports & Adapters Services OrderService for UI REST Service Implementation Use Case Boundary The layer between the Adapter and Bounded Context the Domain is identified as the Ports OrderProcessing Web Interface A A layer. The Domain is inside the port, Services
adapters for external entities are on p Order Data OrderProcessing p Validation Domain Service the outside of the port. (Business Rules) Implementation Domain Layer The notion of a “port” invokes the A Domain OS idea that any device that adheres Models to a known protocol can be plugged External A Apps A into a port. Similarly many adapters Others may use the Ports. p
Ports Order Tracking • Reduces Technical Debt Repository Data Interface • Dependency Injection A A • Auto Wiring Store
Source : http://alistair.cockburn.us/Hexagonal+architecture Order Tracking https://skillsmatter.com/skillscasts/5744-decoupling-from-asp-net-hexagonal-architectures-in-net JPA Repository File Implementation system Database 6/24/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 14 1 Micro Services Characteristics By James Lewis and Martin Fowler
Components Organized around Products via Business NOT Services Capabilities Projects
Smart Decentralized Endpoints Governance & & Dumb Pipes Data Management
Evolutionary Infrastructure Design for Automation Failure Design
The key in making great and growable systems is much more Modularity ... is to a technological economy what We can scale our operation independently, maintain to design how its modules communicate rather than what the division of labor is to a manufacturing one. unparalleled system availability, and introduce new services their internal properties and behaviors should be. W. Brian Arthur, quickly without the need for massive reconfiguration. — Alan Kay, 1998 email to the Squeak-dev list author of e Nature of Technology Werner Vogels, CTO, Amazon Web Services
6 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 1 Pros and Cons Pros Cons 1. Robust 1. Adds Complexity 2. Scalable 2. Skillset shortage 3. Testable (Local) 3. Confusion on getting the 4. Easy to Change and right size Replace 4. Team need to manage 5. Easy to Deploy end-to-end of the Service (From UI to Backend to 6. Technology Agnostic Running in Production).
6/24/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 5 1 Monolithic vs. Micro Services Example
Micro Services with Multiple Technology Stack
Existing API Gateway (Zuul Edge Server) Service Discovery (Eureka) aPaaS UI Layer vendors creates Load Balancer (Ribbon) Load Balancer (Ribbon) Load Balancer (Ribbon) Monolithic Apps. Circuit Breaker (Hystrix) Circuit Breaker (Hystrix) Circuit Breaker (Hystrix) WS This 3 tier model is SE 8 EE 7 obsolete BL now. UI Layer UI Layer UI Layer UI Layer DL Customer Order Shopping Cart Source: Inventory Web Services Web Services Web Services Web Services Gartner Market Business Logic Business Logic Business Logic Business Logic Guide for Application Database Layer Database Layer Database Layer Database Layer Order Customer Shopping Cart Shopping Platforms Database Inventory Nov 23, 2016 Micro Micro Micro Micro Service Service Service Service 1 2 3 4 Traditional Monolithic App using Single Technology Stack Event Stream (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 9 6/24/2018 1 SOA vs. Micro Services Example
3rd Party Apps Consumers
Micro Services with Multiple Technology Stack
Smart Pipes API Gateway Service Discovery Lot of Business logic UI Layer resides in the Pipe Load Balancer Load Balancer Load Balancer
Enterprise Service Circuit Breaker Circuit Breaker Circuit Breaker Messaging Web Services Bus REST / SOAP XML SE 8 HTTP WSDL Addressing MOM UI Layer UI Layer UI Layer JMS Security ODBC / JDBC Registry Translation Management Web Services Web Services Web Services Business Logic Business Logic Business Logic Customer Order Shopping Cart Inventory Database Layer Database Layer Database Layer Order Customer Producers Cart Shopping
Shared Micro Micro Micro Database Service Service Service Database 1 2 3
Traditional Monolithic App with SOA Event Stream 6/24/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 10