Araf Karsh Hamid, profile picture
Uploaded byAraf Karsh Hamid
PPTX, PDF2,628 views

Microservices Architecture - Bangkok 2018

The document discusses microservices architecture, highlighting its principles, benefits, and differences from monolithic systems. Key topics include the definition of microservices, when to use them, their characteristics, and various architectural methodologies like domain-driven design and the 12-factor app approach. It emphasizes the importance of modularity, independent deployment, and technology diversity in improving scalability and system resilience.

Technology◦
Related topics:
API Gateway•

Embed presentation

Downloaded 382 times
ARAF KARSH HAMID Co-Founder / CTO MetaMagic Global Inc., NJ, USA @arafkarsh arafkarsh Microservices Architecture Introduction World DevOps Summit Bangkok, October 26, 2018 Hilton, Sukhumvit, Bangkok http://www.metamagicglobal.com
Pioneers in Microservices Implementation 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 2 New Entrants
* For IT Services : They can do one more project of same size with ZERO COST in Platform Licensing (Based on 20 developer pack USD $50K per month for 3 months License cost = $150K) 311/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
Agenda 11/17/2018 4 • What are Microservices? • When Should I use them? • What is the right size for a Microservice? • Why is Microservices better than Monoliths? • 12 Factor Apps Methodology • Infrastructure Architecture Overview & Infrastructure Architecture1 • Capability Centric Design • Domain Driven Design • Hexagonal Architecture • Event Sourcing & CQRS • Functional Reactive Programming Software Architecture and Design2 • Microservices Scalability • CAP Theorem • ACID Vs BASE • Distributed Transactions • Eventual Consistency: SAGA Pattern • Scalability Lessons from EBay Scalability3 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA • Microservices Testing Strategy • Testing Anti Patterns • Testing Scenarios / Tools • Chaos Engineering • Behavior Driven Development Testing Strategies4 21 25 9 9
What are Microservices? 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 5 The microservice architectural style is an approach to developing • A single application as a suite of small services, • Each running in its own process and • Communicating with lightweight mechanisms, often an HTTP resource API. • These services are built around business capabilities and • Independently deployable by fully automated deployment machinery. • There is a bare minimum of centralized management of these services, • Which may be written in different programming languages and • Use different data storage technologies. - James Lewis and Martin Fowler 1 Source: https://www.martinfowler.com/microservices/
Microservices Characteristics 6 1 By James Lewis and Martin Fowler We can scale our operation independently, maintain unparalleled system availability, and introduce new services quickly without the need for massive reconfiguration. — Werner Vogels, CTO, Amazon Web Services Modularity ... is to a technological economy what the division of labor is to a manufacturing one. W. Brian Arthur, author of e Nature of Technology The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Alan Kay, 1998 email to the Squeak-dev list (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA Components via Services Organized around Business Capabilities Products NOT Projects Smart Endpoints & Dumb Pipes Decentralized Governance & Data Management Infrastructure Automation Design for Failure Evolutionary Design
What is the right size for a Microservice? 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 7 1 • Rather than the size what matters is the Business Function / Domain of the service. • One Microservice may have half a dozen entities and other a couple of dozen entities. What’s more important is the role Microservices plays. • Bounded Context from DDD helps you to decompose a large multi domain Monolith into a Microservice for each Bounded Context. • Focusing on User stories will help you clearly define the boundaries of the Business Domain.
Microservices System Design Model Service (Micro) Process & Tools CultureOrganization Solution (Macro) 11/17/2018 8 Service: Focuses on a specific Business Capability Process & Tools: Development, Code Deployment, Maintenance and Product Management Culture: A Shared set of values, beliefs by everyone. Ubiquitous Language in DDD is an important aspect of Culture. Organization: Structure, Direction of Authority, Granularity, Composition of Teams. Solution: Coordinate all inputs and outputs of multiple services. Macro level view of the system allows the designer to focus more on desirable system behavior. 1 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA All these concept of System Design will be explained in detailed in Section 2 Software Architecture & Design Marc Stickdorn, author of This is Service Design Thinking
When should I use them (Microservices)? 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 9 1 • Strong Module Boundaries: Microservices reinforce modular structure, which is particularly important for larger teams. • Independent Deployment: Simple services are easier to deploy, and since they are autonomous, are less likely to cause system failures when they go wrong. • Technology Diversity: With microservices you can mix multiple languages, development frameworks and data- storage technologies. When you have What’s the Cost Distribution: Distributed systems are harder to program, since remote calls are slow and are always at risk of failure. Eventual Consistency: Maintaining strong consistency is extremely difficult for a distributed system, which means everyone has to manage eventual consistency. Operational Complexity: You need a mature operations team to manage lots of services, which are being redeployed regularly. Source: https://www.martinfowler.com/microservices/
Why is Microservices better than Monoliths? 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 10 1 1. A monolith is built as a Large Single Unit and usually composed of the following 1. A Database (Typically RDBMS) 2. Backend Code (In Java – war/ear file) 3. Frontend Code (HTML5 / JSP / ASP) 2. Any feature addition requires the entire unit to be deployed. 3. When we need to scale we need to have Multiple copies of the entire App. 4. Entire App in Single Technology Stack. • Small autonomous services that work together. • Loosely coupled with Bounded Context. • It’s a natural consequence of applying SRP at Architecture level. • Asynchronous Microservices SRP = Single Responsibility Pattern
Microservices Architecture 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 11 1 • API Gateway • Service Discovery • Config Service • Event Bus / Streams • Service Mesh • Hexagonal Architecture • Domain Driven Design • Event Sourcing & CQRS • Functional Reactive Programming Infrastructure Architecture
11/17/201812 Monolithic vs. Micro Services Example Traditional Monolithic App using Single Technology Stack Micro Services with Multiple Technology Stack This 3 tier model is obsolete now. Source: Gartner Market Guide for Application Platforms Nov 23, 2016 Event Stream API Gateway (Zuul Edge Server) Load Balancer (Ribbon) Circuit Breaker (Hystrix) Service Discovery (Eureka) Load Balancer (Ribbon) Circuit Breaker (Hystrix) Load Balancer (Ribbon) Circuit Breaker (Hystrix) UI Layer Web Services Business Logic Database Layer Micro Service 4 EE 7 Inventory UI Layer Web Services Business Logic Database Layer Micro Service 1 Customer SE 8 UI Layer Web Services Business Logic Database Layer Micro Service 3 ShoppingCart UI Layer Web Services Business Logic Database Layer Micro Service 2 Order 1 UI Layer WS BL DL Database ShoppingCart Order Customer Inventory (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
11/17/2018 13 SOA vs. Micro Services Example Traditional Monolithic App with SOA Micro Services with Multiple Technology Stack Event Stream UI Layer Web Services Business Logic Database Layer Micro Service 1 Customer SE 8 UI Layer Web Services Business Logic Database Layer Micro Service 3 ShoppingCart UI Layer Web Services Business Logic Database Layer Micro Service 2 Order 1 API Gateway Load Balancer Circuit Breaker Service Discovery Load Balancer Circuit Breaker Load Balancer Circuit Breaker UI Layer Database ShoppingCart Order Customer Inventory Enterprise Service Bus Messaging REST / SOAP HTTP MOM JMS ODBC / JDBC Translation Web Services XML WSDL Addressing Security Registry Management Producers Shared Database Consumers3rd Party Apps (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA Smart Pipes Lot of Business logic resides in the Pipe
11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 14 1 • Authentication and Security: identifying authentication requirements for each resource. • Dynamic Routing: dynamically routing requests to different backend.. • Stress Testing: gradually increasing the traffic. • Load Shedding: allocating capacity for each type of request and dropping requests. • Insights and Monitoring: tracking meaningful data and statistics. • Static Response handling: building some responses directly. • Multi region Resiliency: routing requests across AWS regions. Source: https://dzone.com/articles/spring-cloud-netflix-zuul-edge-serverapi-gatewayga • Hystrix (CB) is used to wrap calls to our origins, which allows us to shed and prioritize traffic when issues occur. • Ribbon (LB) is our client for all outbound requests from Zuul, which provides detailed information into network performance and errors, as well as handles software load balancing for even load distribution. • Turbine aggregates fine-grained metrics in real-time so that we can quickly observe and react to problems. • Archaius handles configuration and gives the ability to dynamically change properties. API Gateway Other Services
11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 15 1 # Name * Who Uses Pros Cons 1 Media Type Versioning Accept: Application/vnd.api.article+xml; version=1.0 Med GitHub • Version Directly @ resource level • Preserve URI • Close to RESTful Specs • Harder to Test • Distort HTTP Headers purpose • Tools required for testing 2 Custom Headers Versioning X-API-Version: 2. Med Microsoft • Preservers URI • Harder to Test • Tools required for testing 3 URI Versioning api.example.com/v1/resource High Google Twitter Amazon • Most common method • Versions can be explored using Browser • Easy to use • Disrupts RESTful Compliance. URI should represent resource and not versions 4 Domain Versioning apiv1.example.com/resource Low Facebook • Same as are URI Versioning • Same as URI Versioning 5 Request Parameter Versioning GET /something/?version=0.1 High Pivotal NetFlix • Similar to URI versioning • It can get messy 6 Date Versioning First request saves the date. Low Clearbit • New APIs can be shipped without changing the end points • Complex to implement • Traceability is difficult. API Versioning
Service Mesh – Sidecar Design Pattern 17-11-2018 16 CB – Circuit Breaker LB – Load Balancer SD – Service Discovery Microservice Process1Process2 Service Mesh Control Plane Service Discovery Routing Rules Control Plane will have all the rules for Routing and Service Discovery. Local Service Mesh will download the rules from the Control pane will have a local copy. Service Discovery Calls Service Mesh Calls Customer Microservice Application Localhost calls http://localhost/order/processOrder Router Network Stack LBCB SD ServiceMesh Sidecar UI Layer Web Services Business Logic Order Microservice Application Localhost calls http://localhost/payment/processPayment Router Network Stack LBCB SD ServiceMesh Sidecar UI Layer Web Services Business Logic Data Plane 1
Service Mesh – Traffic Control 17-11-2018 17 API Gateway End User Business Logic Service Mesh Sidecar Customer Service Mesh Control Plane Admin Traffic Rules Traffic Control rules can be applied for • different Microservices versions • Re Routing the request to debugging system to analyze the problem in real time. • Smooth migration path Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Order v1.0 Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Order v2.0 Service Cluster 1
Micro Services Deployment Model Micro Services with Multiple Technology Stack Event Stream Users Service Discovery (Eureka) Config Server (Spring) API (Zuul) Gateway UI Layer Web Services Business Logic Database Layer Micro Service 2 ShoppingCart SE 8 LB = Ribbon CB = Hystrix LB = Ribbon CB = Hystrix UI Layer Web Services Business Logic Database Layer Product SE 8 Micro Service 1 With 4 node cluster LB = Ribbon CB = Hystrix UI Layer Web Services Business Logic Database Layer Order SE 8 Micro Service 3 With 2 node Cluster LB = Ribbon CB = Hystrix UI Layer Web Services Business Logic Database Layer Customer Micro Service 4 With 2 node cluster HTTP Server All UI Code is bundled Virtual Private Network 1
Pros 1. Adds Complexity 2. Skillset shortage 3. Confusion on getting the right size 4. Team need to manage end-to-end of the Service (From UI to Backend to Running in Production). 11/17/2018 19 1. Robust 2. Scalable 3. Testable (Local) 4. Easy to Change and Replace 5. Easy to Deploy 6. Technology Agnostic Cons Microservices Pros and Cons1 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
Summary – Micro Services Intro 17-11-2018 20 SOA Martin Fowler – Micro Services Architecture https://martinfowler.com/articles/microservices.html Dzone – SOA vs Micro Services : https://dzone.com/articles/microservices-vs-soa-2 1 Key Features 1. Small in size 2. Messaging–enabled 3. Bounded by contexts 4. Autonomously developed 5. Independently deployable 6. Decentralized 7. Language–agnostic 8. Built and released with automated processes Micro Service Micro Service Micro Service Micro Service Micro Service Micro Service Micro Service Micro Service Microservice is not SOA.
12 Factor App Methodology 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 21 1 4 Backing Services Treat Backing services like DB, Cache as attached resources 5 Build, Release, Run Separate Build and Run Stages 6 Process Execute App as One or more Stateless Process 7 Port Binding Export Services with Specific Port Binding 8 Concurrency Scale out via the process Model 9 Disposability Maximize robustness with fast startup and graceful exit 10 Dev / Prod Parity Keep Development, Staging and Production as similar as possible 11 Logs Treat logs as Event Streams 12 Admin Process Run Admin Tasks as one of Process Source:https://12factor.net/ Factors Description 1 Codebase One Code base tracked in revision control 2 Dependencies Explicitly declare dependencies 3 Configuration Configuration driven Apps
11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 22 • Business Solution & Process • Capability Centric Design • Domain Driven Design • Strategic Design • Tactical Design • Hexagonal Architecture • Event Sourcing & CQRS • ES and CQRS • Event Sourcing Example • Functional Reactive Programming • 4 Building Blocks of RxJava • Observable and Observer Design Pattern Microservices Architecture & Design2 It’s not necessary that you need to use all these patterns. You will be using these based on your technical requirement
Business Solution & Business Process 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 23  Business Solution focuses the entire Journey of the User which can run across multiple Micro Services.  Business Solution comprises a set of Business Processes.  A specific Micro Service functionality will be focused on a Business Process / Concern Business Solution: Customer Dining Experience Order PaymentFood Menu KitchenDining Browse Menu Order Dinner Dinner Served Get Bill Make Payment 2
Capability Centric Design 11/17/2018 24 Vertically sliced Product Team Business Centric Development • Focus on Business Capabilities • Entire team is aligned towards Business Capability. • From Specs to Operations – The team handles the entire spectrum of Software development. • Every vertical will have it’s own Code Pipeline Front-End-Team Back-End-Team Database-Team In a typical Monolithic way the team is divided based on technology / skill set rather than business functions. This leads to not only bottlenecks but also lack of understanding of the Business Domain. QA / QC Team Front-End Back-End Database Business Capability 1 QA/QCTeam Front-End Back-End Database Business Capability 2 QA/QCTeam Front-End Back-End Database Business Capability 3 QA/QCTeam 2
11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 25 Domain Driven Design • Strategic Design • Tactical Design
Bounded Context – Strategic Design 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 26 2 • Bounded Context is a Specific Business Process / Concern. • Components / Modules inside the Bounded Context are context specific. • Multiple Bounded Contexts are linked using Context Mapping. • One Team assigned to a Bounded Context. • Each Bounded Context will have it’s own Source Code Repository. • When the Bounded Context is being developed as a key strategic initiative of your organization, it’s called the Core Domain. • Within a Bounded Context the team must have same language called Ubiquitous language for Spoken and for Design / Code Implementation.
DDD: Bounded Context – Strategic Design 11/17/2018 27 An App User’s Journey can run across multiple Bounded Context / Micro Services. User Journey X Bounded Context Bounded Context Bounded Context Dinning Order Reservation Tables Recipes Raw Materials Frozen Semi Cooked Appetizer Veg Appetizer Non Veg Soft Drinks Main Course Non Veg Main Course Veg Hot Drinks Desserts Steward Chef Menu uses uses Dinning Order Reservation Tables Recipes Raw Materials Frozen Semi Cooked Appetizer Veg Appetizer Non Veg Soft Drinks Main Course Non Veg Main Course Veg Hot Drinks Desserts Steward Chef Menu uses uses UnderstandingBoundedContext(DDD)ofaRestaurantApp Dinning Context Kitchen Context Menu Context Source: Domain-Driven Design Reference by Eric Evans 2 Areas of the domain treated independently Discovered as you assess requirements and build language
17 November 2018 28 Ubiquitous Language Vocabulary shared by all involved parties Used in all forms of spoken / written communication Ubiquitous Language Domain Expert Analyst Developers QA Design Docs Test Cases Code Restaurant Context – Food Item : Eg. Food Item (Navrathnakurma) can have different meaning or properties depends on the context. • In the Menu Context it’s a Veg Dish. • In the Kitchen Context it’s is recipe. • And in the Dining Context it will have more info related to user feed back etc. 2 DDD: Ubiquitous Language: Strategic Design As an Restaurant Owner I want to know who my Customers are So that I can serve them better Role-Feature-Reason Matrix BDD – Behavior Driven Development Given Customer John Doe exists When Customer orders food Then Assign customer preferences as Veg or Non Veg customer BDD Construct
DDD : Context Map – Strategic Design 17November2018 29 Source: Domain-Driven Design Reference by Eric Evans 2 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA Context Map defines the relationship of Bounded Contexts
11/17/2018 30 Hexagonal Architecture Ports & Adapters The layer between the Adapter and the Domain is identified as the Ports layer. The Domain is inside the port, adapters for external entities are on the outside of the port. The notion of a “port” invokes the OS idea that any device that adheres to a known protocol can be plugged into a port. Similarly many adapters may use the Ports. Source : http://alistair.cockburn.us/Hexagonal+architecture https://skillsmatter.com/skillscasts/5744-decoupling-from-asp-net-hexagonal-architectures-in-net Services for UI Ports File system Database Order Tracking JPA Repository Implementation Adapters OrderProcessing Domain Service (Business Rules) Implementation Domain Models Domain Layer Order Data Validation OrderService REST Service Implementation OrderProcessing Interface p Order Tracking Repository Interface p A A External Apps A A A Others A A OrderService Interface p Web Services Data Store Use Case Boundary Bounded Context A (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA • Reduces Technical Debt • Dependency Injection • Auto Wiring 2
Shopping Portal Modules – Code Packaging 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 31 Auth Products Cart OrderCustomer Domain Layer • Models • Repo • Services • Factories Adapters • Repo • Services • Web Services Domain Layer • Models • Repo • Services • Factories Adapters • Repo • Services • Web Services Domain Layer • Models • Repo • Services • Factories Adapters • Repo • Services • Web Services Packaging Structure Bounded Context Implementation (Repositories, Business Services, Web Services) 1 Domain Models (Entities, Value Objects, DTOs) (Repositories, Business Services, Web Services) Entity Factories Interfaces (Ports)
Domain Driven Design – Tactical Design 11/17/2018 32 Source: Domain-Driven Design Reference by Eric Evans (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 2
DDD: Understanding Aggregate Root 33 Order Customer Shipping Address Aggregate Root Line Item Line Item Line Item * Payment Strategy Credit Card Cash Bank Transfer Source: Martin Fowler : Aggregate Root • An aggregate will have one of its component objects be the aggregate root. Any references from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as a whole. • Aggregates are the basic element of transfer of data storage - you request to load or save whole aggregates. Transactions should not cross aggregate boundaries. • Aggregates are sometimes confused with collection classes (lists, maps, etc.). • Aggregates are domain concepts (order, clinic visit, playlist), while collections are generic. An aggregate will often contain multiple collections, together with simple fields. 125 Domain Driven Design 2 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
Shopping Portal 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 34 Order ModuleModels Value Object • Currency • Item Value • Order Status • Payment Type • Record State • Audit Log Entity • Order (Aggregate Root) • Order Item • Shipping Address • Payment DTO • Order • Order Item • Shipping Address • Payment Domain Layer Adapters • Order Repository • Order Service • Order Web Service • Order Query Web Service • Shipping Address Web Service • Payment Web Service Adapters Consists of Actual Implementation of the Ports like Database Access, Web Services API etc. Converters are used to convert an Enum value to a proper Integer value in the Database. For Example Order Status Complete is mapped to integer value 100 in the database. Services / Ports • Order Repository • Order Service • Order Web Service Utils • Order Factory • Order Status Converter • Record State Converter • Order Query Web Service • Shipping Address Web Service • Payment Web Service
DDD – Summary 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 35 2 More on this in Event Sourcing & CQRS Section. 1. Bounded Context 2. Ubiquitous Language 3. Context Map Strategic Design 1. Aggregate Root 2. Value Object 3. Domain Events 4. Repository Pattern 5. Factory Tactical Design
11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 36 CRUD / CQRS & Event Sourcing A brief introduction, more in Part 2 of the Series Event Storming and SAGA
CRUD and CQRS 11/17/2018 37 Presentation Services Business Logic Data Access Data Store UpdatesQueries Traditional CRUD Architecture Source: https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs https://blogs.msdn.microsoft.com/maarten_mullender/2004/07/23/crud-only-when-you-can-afford-it-revisite • A mismatch between the read and write representations of the data. • It risks data contention when records are locked in the data store in a collaborative domain, where multiple actors operate in parallel on the same set of data. These risks increase as the complexity and throughput of the system grows. • It can make managing security and permissions more complex because each entity is subject to both read and write operations, which might expose data in the wrong context. CRUD Disadvantages (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 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). • CQRS should be used along with Event Sourcing. 11/17/2018 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 38 MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx | Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html CQS : Bertrand Meyer Axon Framework For Java Java Axon Framework Resource : http://www.axonframework.org Greg Young (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 2
Event Sourcing Intro 11/17/2018 39 Standard CRUD Operations – Customer Profile – Aggregate Root Profile Created Title Updated New Address added Derived Notes Removed Time T1 T2 T4T3 Event Sourcing and Derived Aggregate Root Commands 1. Create Profile 2. Update Title 3. Add Address 4. Delete Notes 2 Events 1. Profile Created Event 2. Title Updated Event 3. Address Added Event 4. Notes Deleted Event 3 Current State of the Customer Profile 4 Event store Single Source of Truth Greg Young 2
Restaurant Dining – Event Sourcing and CQRS 11/17/2018 40 Order Payment • Add Drinks • Add Food • Update Food Commands • Open Table • Add Juice • Add Soda • Add Appetizer 1 • Add Appetizer 2 • Serve Drinks • Prepare Food • Serve Food Events • Drinks Added • Food Added • Food Updated • Food Discontinued • Table Opened • Juice Added • Soda Added • Appetizer 1 Added • Appetizer 2 Added • Juice Served • Soda Served • Appetizer Served • Food Prepared • Food Served • Prepare Bill • Process Payment • Bill Prepared • Payment Processed • Payment Approved • Payment Declined • Cash Paid 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. Microservices • Dinning Order • Billable Order Customer Journey thru Dinning Processes Processes Food Menu KitchenDining • Remove Soda • Add Food 1 • Add Food 2 • Place Order • Close Table • Remove Soda • Food 1 Added • Food 2 Added • Order Placed • Table Closed ES Aggregate 3 2 4 1 The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles. 2
Use Case : Shopping Portal – Event Sourcing / CQRS 11/17/2018 41 Catalogue Shopping Cart Order Payment • Search Products • Add Products • Update Products Commands • Add to Cart • Remove Item • Update Quantity Customer • Process Order • Select Address • Select Delivery Mode Events • Product Added • Product Updated • Product Discontinued • Item Added • Item Removed / Discontinued • Item Updated • Order Initiated • Address Selected • Delivery Mode Selected • Order Created • Proceed for Payment • Confirm Order for Payment • Cancel Order • Payment Initiated • Order Cancelled • Order Confirmed • OTP Send • Payment Approved • Payment Declined Commands are End-User interaction with the App and based on the commands (Actions) Events are created. These Events includes both Domain Events and Integration Events. Event Sourced Aggregates will be derived using Domain Events. Each Micro Service will have its own separate Database. Depends on the scalability requirement each of the Micro Service can be scaled separately. For Example. Catalogue can be on a 50 node cluster compared to Customer Micro Service. Microservices • Customer • Shop.. Cart • Order Customer Journey thru Shopping Process The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles. 3 2 ES Aggregate 4 2
Summary – Event Sourcing and CQRS 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 42 2 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.
11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 43 Functional Reactive Programming
Functional Reactive Programming 11/17/2018 44 ResilientElastic Message – Driven 1. A responsive, maintainable & Extensible application is the goal. 2. A responsive application is both scalable (Elastic) and resilient. 3. Responsiveness is impossible to achieve without both scalability and resilience. 4. A Message-Driven architecture is the foundation of scalable, resilient, and ultimately responsive systems. Value Means Form Principles What it means? Responsive thus React to users demand Resilient thus React to errors and failures Elastic thus React to load Message-Driven thus React to events and messages Source: http://reactivex.io/ Responsive Maintainable Extensible (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 2
4 Building Blocks of RxJava 17 November 2018 45 Source of Data Stream [ Sender ]Observable1 Listens for emitted values [ Receiver ]Observer2 2 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA Source: http://reactivex.io/ Schedulers3 Schedulers are used to manage and control concurrency. 1. observeOn: Thread Observable is executed 2. subscribeOn: Thread subscribe is executed 4 Operators Content Filtering Time Filtering Transformation Operators that let you Transform, Combine, Manipulate, and work with the sequence of items emitted by Observables
Observable / Observer Design Pattern 17 November 2018 46 • Allows for Concurrent Operations: the observer does not need to block while waiting for the observable to emit values • Observer waits to receive values when the observable is ready to emit them • Based on push rather than pull 1 & 2Building Block Source: http://reactivex.io/RxJava/javadoc/index.html?rx/Observable.html 2 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
What’s missing from GOF Observer Pattern 17 November 2018 47 1 Building Block Source:http://reactivex.io/intro.html 1. The ability for the producer to signal to the consumer that there is no more data available (a foreach loop on an Iterable completes and returns normally in such a case; an Observable calls its observer’s onComplete method) 2. The ability for the producer to signal to the consumer that an error has occurred (an Iterable throws an exception if an error takes place during iteration; an Observable calls its observer’s onError method) 3. Multiple Thread Implementations and hiding those details. 4. Dozens of Operators to handle data. 2 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
Compare Iterable Vs. Observable 17 November 2018 48 Observable is the asynchronous / push dual to the synchronous pull Iterable • Composable: Easily chained together or combined • Flexible: Can be used to emit: • A scalar value (network result) • Sequence (items in a list) • Infinite streams (weather sensor) • Free from callback hell: Easy to transform one asynchronous stream into another Observables are: Event Iterable (Pull) Observable (Push) Retrieve Data T next() onNext(T) Discover Error throws Exception onError (Exception) Complete !hasNext() onComplete() 1Building Block Source: http://reactivex.io/RxJava/javadoc/index.html?rx/Observable.html 2 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
Comparison : Iterable / Streams / Observable 17 November 2018 49 1Building Block First Class Visitor (Consumer) Serial Operations Parallel Streams (10x Speed) Still On Next, On Complete and On Error are Serial Operations Completely Asynchronous Operations Java 8 – Blocking CallJava 6 – Blocking Call Rx Java - Freedom 2 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA Source Code: https://github.com/meta-magic/rxjava
17 November 2018 50 Functional Reactive Programming : Design Patterns Single Component Pattern A Component shall do ONLY one thing, But do it in FULL. Single Responsibility Principle By DeMarco : Structured Analysis & System Specification (Yourdon, New York, 1979) Let-It-Crash Pattern Prefer a FULL component restart to complex internal failure handling. Candea & Fox: Crash-Only Software (USENIX HotOS IX, 2003) Popularized by Netflix Chaos Monkey. Erlang Philosophy Saga Pattern Divide long-lived distributed transactions into quick local ones with compensating actions for recovery. Pet Helland: Life Beyond Distributed Transactions CIDR 2007 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 2
Summary – Functional Reactive Programming 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 51 2 1. A responsive, maintainable & Extensible application is the goal. 2. A responsive application is both scalable (Elastic) and resilient. 3. Responsiveness is impossible to achieve without both scalability and resilience. 4. A Message-Driven architecture is the foundation of scalable, resilient, and ultimately responsive systems.
11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 52 • Microservice Scalability • CAP Theorem • ACID vs BASE • Distributed Transactions : 2 Phase Commit • SAGA Design Pattern • Scalability Lessons from EBay Scalability3
Scale Cube and Micro Services 17-11-2018 53 1. Y Axis Scaling – Functional Decomposition : Business Function as a Service 2. Z Axis Scaling – Database Partitioning : Avoid locks by Database Sharding 3. X Axis Scaling – Cloning of Individual Services for Specific Service Scalability 3 Source: The NewStack. Based on the Art of Scalability by By Martin Abbot & Michael Fisher
CAP Theorem by Eric Allen Brewer 17November2018 54 Pick Any 2!! Say NO to 2 Phase Commit  Source: http://en.wikipedia.org/wiki/Eric_Brewer_(scientist) CAP 12 years later: How the “Rules have changed” : http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed “In a network subject to communication failures, it is impossible for any web service to implement an atomic read / write shared memory that guarantees a response to every request.” 3
ACID vs BASE 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 55 3 Atomic • All operations in a transaction succeed or every operation is rolled back. Consistent • On the completion of a transaction, the database is structurally sound. Isolated • Transactions do not contend with one another. Contentious access to data is moderated by the database so that transactions appear to run sequentially. Durable • The results of applying a transaction are permanent, even in the presence of failures. Basic Availability • The database appears to work most of the time. Soft-state • Stores don’t have to be write-consistent, nor do different replicas have to be mutually consistent all the time. Eventual consistency • Stores exhibit consistency at some later point (e.g., lazily at read time).
Distributed Transactions : 2 Phase Commit 2 PC or not 2 PC, Wherefore Art Thou XA? 17November2018 56 How does 2PC impact scalability? • Transactions are committed in two phases. • This involves communicating with every database (XA Resources) involved to determine if the transaction will commit in the first phase. • During the second phase each database is asked to complete the commit. • While all of this coordination is going on, locks in all of the data sources are being held. • The longer duration locks create the risk of higher contention. • Additionally, the two phases require more database processing time than a single phase commit. • The result is lower overall TPS in the system. Transaction Manager XA Resources Request to Prepare Commit Prepared Prepare Phase Commit PhaseDone Source : Pat Helland (Amazon) : Life Beyond Distributed Transactions Distributed Computing : http://dancres.github.io/Pages/ Solution : Resilient System • Event Based • Design for failure • Asynchronous Recovery • Make all operations idempotent. • Each DB operation is a 1 PC 3 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
SAGA Design Pattern instead of 2PC 11/17/2018 57 Long Lived Transactions (LLTs) hold on to DB resources for relatively long periods of time, significantly delaying the termination of shorter and more common transactions. Source: SAGAS (1987) Hector Garcia Molina / Kenneth Salem, Dept. of Computer Science, Princeton University, NJ, USA T1 T2 Tn Local Transactions C1 C2 Cn-1 Compensating Transaction Divide long–lived, distributed transactions into quick local ones with compensating actions for recovery. Travel : Flight Ticket & Hotel Booking Example BASE (Basic Availability, Soft State, Eventual Consistency) Room ReservedT1 Room PaymentT2 Seat ReservedT3 Ticket PaymentT4 Cancelled Room Reservation C1 Cancelled Room Payment C2 Cancelled Ticket Reservation C3 3
Scalability Best Practices : Lessons from Best Practices Highlights #1 Partition By Function • Decouple the Unrelated Functionalities. • Selling functionality is served by one set of applications, bidding by another, search by yet another. • 16,000 App Servers in 220 different pools • 1000 logical databases, 400 physical hosts #2 Split Horizontally • Break the workload into manageable units. • eBay’s interactions are stateless by design • All App Servers are treated equal and none retains any transactional state • Data Partitioning based on specific requirements #3 Avoid Distributed Transactions • 2 Phase Commit is a pessimistic approach comes with a big COST • CAP Theorem (Consistency, Availability, Partition Tolerance). Apply any two at any point in time. • @ eBay No Distributed Transactions of any kind and NO 2 Phase Commit. #4 Decouple Functions Asynchronously • If Component A calls component B synchronously, then they are tightly coupled. For such systems to scale A you need to scale B also. • If Asynchronous A can move forward irrespective of the state of B • SEDA (Staged Event Driven Architecture) #5 Move Processing to Asynchronous Flow • Move as much processing towards Asynchronous side • Anything that can wait should wait #6 Virtualize at All Levels • Virtualize everything. eBay created their on O/R layer for abstraction #7 Cache Appropriately • Cache Slow changing, read-mostly data, meta data, configuration and static data. 17November2018 58 Source: http://www.infoq.com/articles/ebay-scalability-best-practices 3 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
11/17/2018 59 Design Patterns are solutions to general problems that software developers faced during software development. Design Patterns3 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
Scalability Summary 11/17/2018 60 1. Scale Cube Scaling in All 3 Axis 1. Functional Decomposition 2. Database Partitioning 3. Cloning Services 2. Eventual Consistency 3. SAGA for Distributed Transaction (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 61 • Microservices Testing Strategies • Testing Anti Patterns • Testing Scenarios / Tools • Chaos Engineering • Behavior Driven Development Microservices Testing Strategies4
Microservices Testing Strategies 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 62 Ubiquitous Language Domain Expert Analyst Developers QA Design Docs Test Cases Code E2E Testing Integration Testing Contract Testing Component Testing Unit Testing Number of Tests Speed Cost Time 4 Mike Cohen’s Testing Pyramid Test Pyramid: https://martinfowler.com/bliki/TestPyramid.html 70% 20% 10%
Other Testing Strategies or Anti Patterns 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 63 Inverted Pyramid / Ice Cream Cone Strategy Unit Testing Integration Testing End 2 End Testing Hour Glass Strategy 70% 20% 10% 45% 45% 10% 4
Microservices Testing Strategy 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 64 Unit Testing A unit test exercises the smallest piece of testable software in the application to determine whether it behaves as expected. Source: https://martinfowler.com/articles/microservice-testing/#agenda Component Testing A component test limits the scope of the exercised software to a portion of the system under test, manipulating the system through internal code interfaces and using test doubles to isolate the code under test from other components. Integration Testing An integration test verifies the communication paths and interactions between components to detect interface defects Integration Contract Testing An Integration Contract test is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service. End 2 End Testing An end-to-end test verifies that a system meets external requirements and achieves its goals, testing the entire system, from end to end 4 Say NO to End 2 End Tests - Mike Walker April 22, 2015. Google Test Blog
Testing ToolsMicroservices Testing Scenarios / Tools 65 Contract Testing Scope Integration Testing Verifies the communication paths and interactions between components to detect interface defects Contract Testing It is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service. Payment Mock IntegrationContractTestingScope Test Double Montebank Cart Component Testing Unit Testing IntegrationTestingScope Order REST / HTTP or Events / Kafka Item ID, Quantity, Address.. Mock Order Component Testing A component test limits the scope of the exercised software to a portion of the system under test. 4 Order Payment Unit Testing Firewall Integration Testing Scope REST / HTTP Payment Sandbox Component Testing
Chaos Engineering – Load / Stress / Performance 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 66 4 Chaos Monkey Randomly disables production instances Chaos Kong Similar to Chaos Monkey, simulates an outage of an entire Amazon availability zone. Doctor Monkey Checks CPU load, Memory usage and removes it from network if the health is bad. Janitor Monkey Search for unused resources and disposes them. Compliance Monkey Finds instances that don’t adhere to best-practices and shuts them down. Latency Money Induces Artificial delays Security Monkey Is an extension of Compliance Monkey. Find security vulnerabilities and terminates offending instances. Source: https://github.com/Netflix/SimianArmy/wikiSource: http://principlesofchaos.org/
Behavior Driven Development 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 67 4 Source: https://dannorth.net/introducing-bdd/ As an insurance Broker I want to know who my Gold Customers are So that I sell more Given Customer John Doe exists When he buys insurance ABC for $1000 USD Then He becomes a Gold Customer BDD Construct Role-Feature-Reason Matrix As a Customer I want to withdraw Cash from ATM So that I don’t have to wait in line at the bank Given The account is in Credit AND the Card is Valid AND the dispenser contains Cash BDD Construct Role-Feature-Reason Matrix When The Customer requests Cash Then Ensure that the Account is debited AND Ensure cash is dispensed AND ensure that Card is returned.
Features of BDD 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 68 4 • Focus on Behavior of the System rather than tests. • Collaboration between Business Stake holders, Analysts, Developers, QA. • Ubiquitous Language • Driven By Business Value • Extends Test Driven Development Source: https://cucumber.io/ Cucumber merges specification and test documentation into one cohesive whole.
Microservices Architecture Summary 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 69 • API Gateway • Service Discovery • Service Mesh • Event Streams Infrastructure Architecture1 • Capability Centric Design • Domain Driven Design • Event Sourcing & CQRS • Functional Reactive Programming Software Architecture and Design2 • Microservices Scalability • CAP Theorem • Distributed Transactions • SAGA Design Pattern • Scalability Lessons from EBay Scalability3 • Microservices Testing Strategy • Testing Anti-Patterns • Testing Scenarios / Tools • Behavior Driven Development Testing Strategies4
70 Araf Karsh Hamid : Co-Founder / CTO araf.karsh@metamagic.in USA: +1 (973) 969-2921 India: +91.999.545.8627 Skype / LinkedIn / Twitter / Slideshare : arafkarsh http://www.slideshare.net/arafkarsh https://www.linkedin.com/in/arafkarsh/ http://www.arafkarsh.com/ DREAM | AUTOMATE | EMPOWER
References 11/17/2018 71 1. Lewis, James, and Martin Fowler. “Microservices: A Definition of This New Architectural Term”, March 25, 2014. 2. Miller, Matt. “Innovate or Die: The Rise of Microservices”. e Wall Street Journal, October 5, 2015. 3. Newman, Sam. Building Microservices. O’Reilly Media, 2015. 4. Alagarasan, Vijay. “Seven Microservices Anti-patterns”, August 24, 2015. 5. Cockcroft, Adrian. “State of the Art in Microservices”, December 4, 2014. 6. Fowler, Martin. “Microservice Prerequisites”, August 28, 2014. 7. Fowler, Martin. “Microservice Tradeoffs”, July 1, 2015. 8. Humble, Jez. “Four Principles of Low-Risk Software Release”, February 16, 2012. 9. Zuul Edge Server, Ketan Gote, May 22, 2017 10. Ribbon, Hysterix using Spring Feign, Ketan Gote, May 22, 2017 11. Eureka Server with Spring Cloud, Ketan Gote, May 22, 2017 12. Apache Kafka, A Distributed Streaming Platform, Ketan Gote, May 20, 2017 13. Functional Reactive Programming, Araf Karsh Hamid, August 7, 2016 14. Enterprise Software Architectures, Araf Karsh Hamid, July 30, 2016 15. Docker and Linux Containers, Araf Karsh Hamid, April 28, 2015 4
References 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 72 Domain Driven Design 16. Oct 27, 2012 What I have learned about DDD Since the book. By Eric Evans 17. Mar 19, 2013 Domain Driven Design By Eric Evans 18. May 16, 2015 Microsoft Ignite: Domain Driven Design for the Database Driven Mind 19. Jun 02, 2015 Applied DDD in Java EE 7 and Open Source World 20. Aug 23, 2016 Domain Driven Design the Good Parts By Jimmy Bogard 21. Sep 22, 2016 GOTO 2015 – DDD & REST Domain Driven API’s for the Web. By Oliver Gierke 22. Jan 24, 2017 Spring Developer – Developing Micro Services with Aggregates. By Chris Richardson 23. May 17. 2017 DEVOXX – The Art of Discovering Bounded Contexts. By Nick Tune Event Sourcing and CQRS 23. Nov 13, 2014 GOTO 2014 – Event Sourcing. By Greg Young 24. Mar 22, 2016 Spring Developer – Building Micro Services with Event Sourcing and CQRS 25. Apr 15, 2016 YOW! Nights – Event Sourcing. By Martin Fowler 26. May 08, 2017 When Micro Services Meet Event Sourcing. By Vinicius Gomes 4
References 11/17/2018 73 27. MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx 28. Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html 29. Udi Dahan : CQRS – http://www.udidahan.com/2009/12/09/clarified-cqrs/ 30. Greg Young : CQRS - https://www.youtube.com/watch?v=JHGkaShoyNs 31. Bertrand Meyer – CQS - http://en.wikipedia.org/wiki/Bertrand_Meyer 32. CQS : http://en.wikipedia.org/wiki/Command–query_separation 33. CAP Theorem : http://en.wikipedia.org/wiki/CAP_theorem 34. CAP Theorem : http://www.julianbrowne.com/article/viewer/brewers-cap-theorem 35. CAP 12 years how the rules have changed 36. EBay Scalability Best Practices : http://www.infoq.com/articles/ebay-scalability-best-practices 37. Pat Helland (Amazon) : Life beyond distributed transactions 38. Stanford University: Rx https://www.youtube.com/watch?v=y9xudo3C1Cw 39. Princeton University: SAGAS (1987) Hector Garcia Molina / Kenneth Salem 40. Rx Observable : https://dzone.com/articles/using-rx-java-observable 4
References – Micro Services – Videos 41. Martin Fowler – Micro Services : https://www.youtube.com/watch?v=2yko4TbC8cI&feature=youtu.be&t=15m53s 42. GOTO 2016 – Microservices at NetFlix Scale: Principles, Tradeoffs & Lessons Learned. By R Meshenberg 43. Mastering Chaos – A NetFlix Guide to Microservices. By Josh Evans 44. GOTO 2015 – Challenges Implementing Micro Services By Fred George 45. GOTO 2016 – From Monolith to Microservices at Zalando. By Rodrigue Scaefer 46. GOTO 2015 – Microservices @ Spotify. By Kevin Goldsmith 47. Modelling Microservices @ Spotify : https://www.youtube.com/watch?v=7XDA044tl8k 48. GOTO 2015 – DDD & Microservices: At last, Some Boundaries By Eric Evans 49. GOTO 2016 – What I wish I had known before Scaling Uber to 1000 Services. By Matt Ranney 50. DDD Europe – Tackling Complexity in the Heart of Software By Eric Evans, April 11, 2016 51. AWS re:Invent 2016 – From Monolithic to Microservices: Evolving Architecture Patterns. By Emerson L, Gilt D. Chiles 52. AWS 2017 – An overview of designing Microservices based Applications on AWS. By Peter Dalbhanjan 53. GOTO Jun, 2017 – Effective Microservices in a Data Centric World. By Randy Shoup. 54. GOTO July, 2017 – The Seven (more) Deadly Sins of Microservices. By Daniel Bryant 55. Sept, 2017 – Airbnb, From Monolith to Microservices: How to scale your Architecture. By Melanie Cubula 56. GOTO Sept, 2017 – Rethinking Microservices with Stateful Streams. By Ben Stopford. 57. GOTO 2017 – Microservices without Servers. By Glynn Bird. 11/17/2018 74 4
11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 75 Simoorg : LinkedIn’s own failure inducer framework. It was designed to be easy to extend and most of the important components are plug‐ gable. Pumba : A chaos testing and network emulation tool for Docker. Chaos Lemur : Self-hostable application to randomly destroy virtual machines in a BOSH- managed environment, as an aid to resilience testing of high-availability systems. Chaos Lambda : Randomly terminate AWS ASG instances during business hours. Blockade : Docker-based utility for testing network failures and partitions in distributed applications. Chaos-http-proxy : Introduces failures into HTTP requests via a proxy server. Monkey-ops : Monkey-Ops is a simple service implemented in Go, which is deployed into an OpenShift V3.X and generates some chaos within it. Monkey-Ops seeks some OpenShift components like Pods or DeploymentConfigs and randomly terminates them. Chaos Dingo : Chaos Dingo currently supports performing operations on Azure VMs and VMSS deployed to an Azure Resource Manager-based resource group. Tugbot : Testing in Production (TiP) framework for Docker. Testing tools
UI Design Patterns 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 76
UI DesignPatterns MVC/ MVP/ MVVM 77 View Controller Model Passes calls To Fire Events Manipulates • The Controller is responsible to process incoming requests. It receives input from users via the View, then process the user's data with the help of Model and passing the results back to the View. • Typically, it acts as the coordinator between the View and the Model. • The Presenter is responsible for handling all UI events on behalf of the view. This receive input from users via the View, then process the user's data with the help of Model and passing the results back to the View. • Unlike view and controller, view and presenter are completely decoupled from each other’s and communicate to each other’s by an interface. Also, presenter does not manage the incoming request traffic as controller. • Supports two-way data binding between View and ViewModel. View ViewModel Model Passes calls To Manipulates Updates Fire Events • The View Model is responsible for exposing methods, commands, and other properties that helps to maintain the state of the view, manipulate the model as the result of actions on the view, and trigger events in the view itself. • There is many-to-one relationship between View and ViewModel means many View can be mapped to one ViewModel. • Supports two-way data binding between View and ViewModel. View Presenter Model Passes calls To Fire Events Manipulates Updates1 1 1 * Model View Controller Model View Presenter Model View ViewModel
UI Design Patterns Flux / Redux ViewDispatcher Every action is sent to all Stores via callbacks the stores register with the Dispatcher Store Action Action 1 * Controller-Views • Listens to Store changes • Emit Actions to Dispatcher Dispatcher • Single Dispatcher per Application • Manages the Data Flow View to Model • Receives Actions and dispatch them to Stores Stores • Contains state for a Domain (Vs. Specific Component) • In Charge of modifying the Data • Inform the views when the Data is changed by emitting the Changed Event. Flux Core Concepts 1. One way Data Flow 2. No Event Chaining 3. Entire App State is resolved in store before Views Update 4. Data Manipulation ONLY happen in one place (Store). Actions • Simple JS Objects • Contains Name of the Action and Data (Payload) • Action represent something that has happened. • Has No Business Logic (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
UI Design Patterns Redux Actions • Simple JS Objects • Contains Name of the Action and Data (Payload) • Has NO Business Logic • Action represent something that has happened. Store • Multiple View layers can Subscribe • View layer to Dispatch actions • Single Store for the Entire Application • Data manipulation logic moves out of store to Reducers Reducer • Pure JS Functions • No External calls • Can combine multiple reducers • A function that specifies how the state changes in response to an Action. • Reducer does NOT modify the state. It returns the NEW State. Redux Core Concepts 1. One way Data Flow 2. No Dispatcher compared to Flux 3. Immutable Store Available for React & Angular View Action State Dispatcher Reducer R R R Store Middleware Middleware Middleware • Handles External calls • Multiple Middleware's can be chained. (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 80 UI Development – Angular / Amexio2 • Angular Basics • Amexio Components Intro • Amexio API & Examples • Layouts and Themes • Charts and Dashboards • Angular Routing, Data Binding • Concepts • Business Use • Migration from v1.x to 2.x Functional Reactive Programming1 • Examples • Comparison • Workshop Examples with Rx 2 Additional Topics – If Time permits

More Related Content

PPTX
Micro services Architecture
byAraf Karsh Hamid
 
PPSX
Microservices Architecture - Cloud Native Apps
byAraf Karsh Hamid
 
PPTX
Microservices Architecture & Testing Strategies
byAraf Karsh Hamid
 
PPSX
Microservices, Containers, Kubernetes, Kafka, Kanban
byAraf Karsh Hamid
 
PPSX
Microservices Architecture, Monolith Migration Patterns
byAraf Karsh Hamid
 
PPSX
Agile, User Stories, Domain Driven Design
byAraf Karsh Hamid
 
PPSX
Event Sourcing & CQRS, Kafka, Rabbit MQ
byAraf Karsh Hamid
 
PDF
Event Storming and Saga
byAraf Karsh Hamid
 
Micro services Architecture
byAraf Karsh Hamid
 
Microservices Architecture - Cloud Native Apps
byAraf Karsh Hamid
 
Microservices Architecture & Testing Strategies
byAraf Karsh Hamid
 
Microservices, Containers, Kubernetes, Kafka, Kanban
byAraf Karsh Hamid
 
Microservices Architecture, Monolith Migration Patterns
byAraf Karsh Hamid
 
Agile, User Stories, Domain Driven Design
byAraf Karsh Hamid
 
Event Sourcing & CQRS, Kafka, Rabbit MQ
byAraf Karsh Hamid
 
Event Storming and Saga
byAraf Karsh Hamid
 

What's hot

PPTX
Microservices Part 3 Service Mesh and Kafka
byAraf Karsh Hamid
 
PDF
Why Microservice
byKelvin Yeung
 
PPSX
Cloud Architecture - Multi Cloud, Edge, On-Premise
byAraf Karsh Hamid
 
PPSX
Service Mesh - Observability
byAraf Karsh Hamid
 
PPTX
Microservices Architecture Part 2 Event Sourcing and Saga
byAraf Karsh Hamid
 
PPSX
Containers Docker Kind Kubernetes Istio
byAraf Karsh Hamid
 
PPTX
Docker Kubernetes Istio
byAraf Karsh Hamid
 
PDF
Design patterns for microservice architecture
byThe Software House
 
PPSX
Domain Driven Design
byAraf Karsh Hamid
 
PPSX
Big Data Redis Mongodb Dynamodb Sharding
byAraf Karsh Hamid
 
PPSX
Elastic-Engineering
byAraf Karsh Hamid
 
PPSX
Microservices Testing Strategies JUnit Cucumber Mockito Pact
byAraf Karsh Hamid
 
PPTX
Introduction to microservices
byPaulo Gandra de Sousa
 
PPSX
CI-CD Jenkins, GitHub Actions, Tekton
byAraf Karsh Hamid
 
PDF
Introduction to Event-Driven Architecture
bySolace
 
PDF
Best Practices with Azure Kubernetes Services
byQAware GmbH
 
PDF
ArgoCD Meetup PPT final.pdf
byamanmakwana3
 
PPTX
GitOps w/argocd
byJean-Philippe Bélanger
 
PDF
Kubernetes Architecture | Understanding Kubernetes Components | Kubernetes Tu...
byEdureka!
 
PPTX
Hashicorp Vault Open Source vs Enterprise
byStenio Ferreira
 
Microservices Part 3 Service Mesh and Kafka
byAraf Karsh Hamid
 
Why Microservice
byKelvin Yeung
 
Cloud Architecture - Multi Cloud, Edge, On-Premise
byAraf Karsh Hamid
 
Service Mesh - Observability
byAraf Karsh Hamid
 
Microservices Architecture Part 2 Event Sourcing and Saga
byAraf Karsh Hamid
 
Containers Docker Kind Kubernetes Istio
byAraf Karsh Hamid
 
Docker Kubernetes Istio
byAraf Karsh Hamid
 
Design patterns for microservice architecture
byThe Software House
 
Domain Driven Design
byAraf Karsh Hamid
 
Big Data Redis Mongodb Dynamodb Sharding
byAraf Karsh Hamid
 
Elastic-Engineering
byAraf Karsh Hamid
 
Microservices Testing Strategies JUnit Cucumber Mockito Pact
byAraf Karsh Hamid
 
Introduction to microservices
byPaulo Gandra de Sousa
 
CI-CD Jenkins, GitHub Actions, Tekton
byAraf Karsh Hamid
 
Introduction to Event-Driven Architecture
bySolace
 
Best Practices with Azure Kubernetes Services
byQAware GmbH
 
ArgoCD Meetup PPT final.pdf
byamanmakwana3
 
GitOps w/argocd
byJean-Philippe Bélanger
 
Kubernetes Architecture | Understanding Kubernetes Components | Kubernetes Tu...
byEdureka!
 
Hashicorp Vault Open Source vs Enterprise
byStenio Ferreira
 

Similar to Microservices Architecture - Bangkok 2018

PPSX
Microservices Docker Kubernetes Istio Kanban DevOps SRE
byAraf Karsh Hamid
 
PPTX
Microservices Architecture & Testing Strategies
byAraf Karsh Hamid
 
PPTX
Introduction to microservices
byAnil Allewar
 
PDF
Microservices for Application Modernisation
byAjay Kumar Uppal
 
PDF
Practical Microservice Architecture (edition 2022).pdf
byAhmed Misbah
 
PPTX
Microservice intro
byramesh_sharma
 
PDF
MicroServices-Part-1.pdf
bychanhluc2112
 
PDF
Microservices Interview Questions and Answers PDF By ScholarHat
byScholarhat
 
PDF
Building microservices on azure
byVaibhav Gujral
 
PDF
A Guide on What Are Microservices: Pros, Cons, Use Cases, and More
bySimform
 
PDF
Introduction to Microservices Architecture - SECCOMP 2020
byRodrigo Antonialli
 
PDF
Introduction to Microservices
byYury Kisliak
 
PPTX
Software Architectures, Week 3 - Microservice-based Architectures
byAngelos Kapsimanis
 
PDF
20141210 - Microservice Container
byJamie (Taka) Wang
 
PPTX
Microservices why?
bySascha Düpre
 
PPTX
From Monolithic applications to Microservices
bykedarpethe37
 
PPTX
Think Big - Build Small
byIraklis Alexopoulos
 
PDF
About Microservices
bySalvatore Cordiano
 
PPTX
Microservices: Lessons from the Trenches
byGregory Beamer
 
PPTX
Pragmatic Microservices
byRandy Shoup
 
Microservices Docker Kubernetes Istio Kanban DevOps SRE
byAraf Karsh Hamid
 
Microservices Architecture & Testing Strategies
byAraf Karsh Hamid
 
Introduction to microservices
byAnil Allewar
 
Microservices for Application Modernisation
byAjay Kumar Uppal
 
Practical Microservice Architecture (edition 2022).pdf
byAhmed Misbah
 
Microservice intro
byramesh_sharma
 
MicroServices-Part-1.pdf
bychanhluc2112
 
Microservices Interview Questions and Answers PDF By ScholarHat
byScholarhat
 
Building microservices on azure
byVaibhav Gujral
 
A Guide on What Are Microservices: Pros, Cons, Use Cases, and More
bySimform
 
Introduction to Microservices Architecture - SECCOMP 2020
byRodrigo Antonialli
 
Introduction to Microservices
byYury Kisliak
 
Software Architectures, Week 3 - Microservice-based Architectures
byAngelos Kapsimanis
 
20141210 - Microservice Container
byJamie (Taka) Wang
 
Microservices why?
bySascha Düpre
 
From Monolithic applications to Microservices
bykedarpethe37
 
Think Big - Build Small
byIraklis Alexopoulos
 
About Microservices
bySalvatore Cordiano
 
Microservices: Lessons from the Trenches
byGregory Beamer
 
Pragmatic Microservices
byRandy Shoup
 

More from Araf Karsh Hamid

PPSX
Microservices, DevOps & SRE
byAraf Karsh Hamid
 
PPSX
Docker Kubernetes Istio
byAraf Karsh Hamid
 
PPSX
Apache Flink, AWS Kinesis, Analytics
byAraf Karsh Hamid
 
PPTX
Domain Driven Design
byAraf Karsh Hamid
 
PPSX
Zero-Trust SASE DevSecOps
byAraf Karsh Hamid
 
PPSX
Blockchain HyperLedger Fabric Internals - Clavent
byAraf Karsh Hamid
 
PPTX
Blockchain Intro to Hyperledger Fabric
byAraf Karsh Hamid
 
PPTX
Blockchain - HyperLedger Fabric
byAraf Karsh Hamid
 
PPTX
Microservices Part 4: Functional Reactive Programming
byAraf Karsh Hamid
 
PPTX
Blockchain Hyper Ledger Fabric : Bangkok Conference
byAraf Karsh Hamid
 
Microservices, DevOps & SRE
byAraf Karsh Hamid
 
Docker Kubernetes Istio
byAraf Karsh Hamid
 
Apache Flink, AWS Kinesis, Analytics
byAraf Karsh Hamid
 
Domain Driven Design
byAraf Karsh Hamid
 
Zero-Trust SASE DevSecOps
byAraf Karsh Hamid
 
Blockchain HyperLedger Fabric Internals - Clavent
byAraf Karsh Hamid
 
Blockchain Intro to Hyperledger Fabric
byAraf Karsh Hamid
 
Blockchain - HyperLedger Fabric
byAraf Karsh Hamid
 
Microservices Part 4: Functional Reactive Programming
byAraf Karsh Hamid
 
Blockchain Hyper Ledger Fabric : Bangkok Conference
byAraf Karsh Hamid
 

Recently uploaded

PDF
Unlocking the Power of Salesforce Architecture: Frameworks for Effective Solu...
byvarsha30tiwari
 
PDF
ElyriaSoftware — Powering the Future with Blockchain Innovation
byElyria Software
 
PPTX
Cloud-and-AI-Platform-FY26-Partner-Playbook.pptx
byiuiuiuiu1
 
PDF
Day 2 - Network Security ~ 2nd Sight Lab ~ Cloud Security Class ~ 2020
by2nd Sight Lab
 
PDF
Decoding the DNA: The Digital Networks Act, the Open Internet, and IP interco...
byCSUC - Consorci de Serveis Universitaris de Catalunya
 
PDF
Security Technologys: Access Control, Firewall, VPN
byShielaLasala
 
PDF
Usage Control for Process Discovery through a Trusted Execution Environment
byValerioGoretti
 
PPTX
AI's Impact on Cybersecurity - Challenges and Opportunities
byYasir Naveed Riaz
 
PDF
DevFest El Jadida 2025 - Product Thinking
byElmehdi AMLOU
 
PPTX
AI in Cybersecurity: Digital Defense by Yasir Naveed Riaz
byYasir Naveed Riaz
 
PDF
TrustArc Webinar - Looking Ahead: The 2026 Privacy Landscape
byTrustArc
 
PPTX
Cybersecurity Best Practices - Step by Step guidelines
byYasir Naveed Riaz
 
PDF
Unser Jahresrückblick – MarvelClient in 2025
bypanagenda
 
PDF
Eredità digitale sugli smartphone: cosa resta di noi nei dispositivi mobili
bySpeck&Tech
 
DOCX
iRobot Post‑Mortem and Alternative Paths - Discussion Document for Boards and...
byDave Litwiller
 
PPTX
Conversational Agents – Building Intelligent Assistants [Virtual Hands-on Wor...
byUiPathCommunity
 
PPTX
Coded Agents – with UiPath SDK + LangGraph [Virtual Hands-on Workshop]
byUiPathCommunity
 
PDF
Is It Possible to Have Wi-Fi Without an Internet Provider
bySidra Jefferi
 
PPTX
cybercrime in Information security .pptx
byismaeelsahib032
 
PPTX
Kanban India 2025 | Daksh Gupta | Modeling the Models, Generative AI & Kanban
byLeanKanbanIndia
 
Unlocking the Power of Salesforce Architecture: Frameworks for Effective Solu...
byvarsha30tiwari
 
ElyriaSoftware — Powering the Future with Blockchain Innovation
byElyria Software
 
Cloud-and-AI-Platform-FY26-Partner-Playbook.pptx
byiuiuiuiu1
 
Day 2 - Network Security ~ 2nd Sight Lab ~ Cloud Security Class ~ 2020
by2nd Sight Lab
 
Decoding the DNA: The Digital Networks Act, the Open Internet, and IP interco...
byCSUC - Consorci de Serveis Universitaris de Catalunya
 
Security Technologys: Access Control, Firewall, VPN
byShielaLasala
 
Usage Control for Process Discovery through a Trusted Execution Environment
byValerioGoretti
 
AI's Impact on Cybersecurity - Challenges and Opportunities
byYasir Naveed Riaz
 
DevFest El Jadida 2025 - Product Thinking
byElmehdi AMLOU
 
AI in Cybersecurity: Digital Defense by Yasir Naveed Riaz
byYasir Naveed Riaz
 
TrustArc Webinar - Looking Ahead: The 2026 Privacy Landscape
byTrustArc
 
Cybersecurity Best Practices - Step by Step guidelines
byYasir Naveed Riaz
 
Unser Jahresrückblick – MarvelClient in 2025
bypanagenda
 
Eredità digitale sugli smartphone: cosa resta di noi nei dispositivi mobili
bySpeck&Tech
 
iRobot Post‑Mortem and Alternative Paths - Discussion Document for Boards and...
byDave Litwiller
 
Conversational Agents – Building Intelligent Assistants [Virtual Hands-on Wor...
byUiPathCommunity
 
Coded Agents – with UiPath SDK + LangGraph [Virtual Hands-on Workshop]
byUiPathCommunity
 
Is It Possible to Have Wi-Fi Without an Internet Provider
bySidra Jefferi
 
cybercrime in Information security .pptx
byismaeelsahib032
 
Kanban India 2025 | Daksh Gupta | Modeling the Models, Generative AI & Kanban
byLeanKanbanIndia
 

Microservices Architecture - Bangkok 2018

  • 1.
    ARAF KARSH HAMID Co-Founder/ CTO MetaMagic Global Inc., NJ, USA @arafkarsh arafkarsh Microservices Architecture Introduction World DevOps Summit Bangkok, October 26, 2018 Hilton, Sukhumvit, Bangkok http://www.metamagicglobal.com
  • 2.
    Pioneers in MicroservicesImplementation 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 2 New Entrants
  • 3.
    * For ITServices : They can do one more project of same size with ZERO COST in Platform Licensing (Based on 20 developer pack USD $50K per month for 3 months License cost = $150K) 311/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
  • 4.
    Agenda 11/17/2018 4 • Whatare Microservices? • When Should I use them? • What is the right size for a Microservice? • Why is Microservices better than Monoliths? • 12 Factor Apps Methodology • Infrastructure Architecture Overview & Infrastructure Architecture1 • Capability Centric Design • Domain Driven Design • Hexagonal Architecture • Event Sourcing & CQRS • Functional Reactive Programming Software Architecture and Design2 • Microservices Scalability • CAP Theorem • ACID Vs BASE • Distributed Transactions • Eventual Consistency: SAGA Pattern • Scalability Lessons from EBay Scalability3 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA • Microservices Testing Strategy • Testing Anti Patterns • Testing Scenarios / Tools • Chaos Engineering • Behavior Driven Development Testing Strategies4 21 25 9 9
  • 5.
    What are Microservices? 11/17/2018(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 5 The microservice architectural style is an approach to developing • A single application as a suite of small services, • Each running in its own process and • Communicating with lightweight mechanisms, often an HTTP resource API. • These services are built around business capabilities and • Independently deployable by fully automated deployment machinery. • There is a bare minimum of centralized management of these services, • Which may be written in different programming languages and • Use different data storage technologies. - James Lewis and Martin Fowler 1 Source: https://www.martinfowler.com/microservices/
  • 6.
    Microservices Characteristics 6 1 By JamesLewis and Martin Fowler We can scale our operation independently, maintain unparalleled system availability, and introduce new services quickly without the need for massive reconfiguration. — Werner Vogels, CTO, Amazon Web Services Modularity ... is to a technological economy what the division of labor is to a manufacturing one. W. Brian Arthur, author of e Nature of Technology The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Alan Kay, 1998 email to the Squeak-dev list (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA Components via Services Organized around Business Capabilities Products NOT Projects Smart Endpoints & Dumb Pipes Decentralized Governance & Data Management Infrastructure Automation Design for Failure Evolutionary Design
  • 7.
    What is theright size for a Microservice? 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 7 1 • Rather than the size what matters is the Business Function / Domain of the service. • One Microservice may have half a dozen entities and other a couple of dozen entities. What’s more important is the role Microservices plays. • Bounded Context from DDD helps you to decompose a large multi domain Monolith into a Microservice for each Bounded Context. • Focusing on User stories will help you clearly define the boundaries of the Business Domain.
  • 8.
    Microservices System DesignModel Service (Micro) Process & Tools CultureOrganization Solution (Macro) 11/17/2018 8 Service: Focuses on a specific Business Capability Process & Tools: Development, Code Deployment, Maintenance and Product Management Culture: A Shared set of values, beliefs by everyone. Ubiquitous Language in DDD is an important aspect of Culture. Organization: Structure, Direction of Authority, Granularity, Composition of Teams. Solution: Coordinate all inputs and outputs of multiple services. Macro level view of the system allows the designer to focus more on desirable system behavior. 1 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA All these concept of System Design will be explained in detailed in Section 2 Software Architecture & Design Marc Stickdorn, author of This is Service Design Thinking
  • 9.
    When should Iuse them (Microservices)? 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 9 1 • Strong Module Boundaries: Microservices reinforce modular structure, which is particularly important for larger teams. • Independent Deployment: Simple services are easier to deploy, and since they are autonomous, are less likely to cause system failures when they go wrong. • Technology Diversity: With microservices you can mix multiple languages, development frameworks and data- storage technologies. When you have What’s the Cost Distribution: Distributed systems are harder to program, since remote calls are slow and are always at risk of failure. Eventual Consistency: Maintaining strong consistency is extremely difficult for a distributed system, which means everyone has to manage eventual consistency. Operational Complexity: You need a mature operations team to manage lots of services, which are being redeployed regularly. Source: https://www.martinfowler.com/microservices/
  • 10.
    Why is Microservicesbetter than Monoliths? 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 10 1 1. A monolith is built as a Large Single Unit and usually composed of the following 1. A Database (Typically RDBMS) 2. Backend Code (In Java – war/ear file) 3. Frontend Code (HTML5 / JSP / ASP) 2. Any feature addition requires the entire unit to be deployed. 3. When we need to scale we need to have Multiple copies of the entire App. 4. Entire App in Single Technology Stack. • Small autonomous services that work together. • Loosely coupled with Bounded Context. • It’s a natural consequence of applying SRP at Architecture level. • Asynchronous Microservices SRP = Single Responsibility Pattern
  • 11.
    Microservices Architecture 11/17/2018 (C)COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 11 1 • API Gateway • Service Discovery • Config Service • Event Bus / Streams • Service Mesh • Hexagonal Architecture • Domain Driven Design • Event Sourcing & CQRS • Functional Reactive Programming Infrastructure Architecture
  • 12.
    11/17/201812 Monolithic vs. MicroServices Example Traditional Monolithic App using Single Technology Stack Micro Services with Multiple Technology Stack This 3 tier model is obsolete now. Source: Gartner Market Guide for Application Platforms Nov 23, 2016 Event Stream API Gateway (Zuul Edge Server) Load Balancer (Ribbon) Circuit Breaker (Hystrix) Service Discovery (Eureka) Load Balancer (Ribbon) Circuit Breaker (Hystrix) Load Balancer (Ribbon) Circuit Breaker (Hystrix) UI Layer Web Services Business Logic Database Layer Micro Service 4 EE 7 Inventory UI Layer Web Services Business Logic Database Layer Micro Service 1 Customer SE 8 UI Layer Web Services Business Logic Database Layer Micro Service 3 ShoppingCart UI Layer Web Services Business Logic Database Layer Micro Service 2 Order 1 UI Layer WS BL DL Database ShoppingCart Order Customer Inventory (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
  • 13.
    11/17/2018 13 SOA vs. MicroServices Example Traditional Monolithic App with SOA Micro Services with Multiple Technology Stack Event Stream UI Layer Web Services Business Logic Database Layer Micro Service 1 Customer SE 8 UI Layer Web Services Business Logic Database Layer Micro Service 3 ShoppingCart UI Layer Web Services Business Logic Database Layer Micro Service 2 Order 1 API Gateway Load Balancer Circuit Breaker Service Discovery Load Balancer Circuit Breaker Load Balancer Circuit Breaker UI Layer Database ShoppingCart Order Customer Inventory Enterprise Service Bus Messaging REST / SOAP HTTP MOM JMS ODBC / JDBC Translation Web Services XML WSDL Addressing Security Registry Management Producers Shared Database Consumers3rd Party Apps (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA Smart Pipes Lot of Business logic resides in the Pipe
  • 14.
    11/17/2018 (C) COPYRIGHTMETAMAGIC GLOBAL INC., NEW JERSEY, USA 14 1 • Authentication and Security: identifying authentication requirements for each resource. • Dynamic Routing: dynamically routing requests to different backend.. • Stress Testing: gradually increasing the traffic. • Load Shedding: allocating capacity for each type of request and dropping requests. • Insights and Monitoring: tracking meaningful data and statistics. • Static Response handling: building some responses directly. • Multi region Resiliency: routing requests across AWS regions. Source: https://dzone.com/articles/spring-cloud-netflix-zuul-edge-serverapi-gatewayga • Hystrix (CB) is used to wrap calls to our origins, which allows us to shed and prioritize traffic when issues occur. • Ribbon (LB) is our client for all outbound requests from Zuul, which provides detailed information into network performance and errors, as well as handles software load balancing for even load distribution. • Turbine aggregates fine-grained metrics in real-time so that we can quickly observe and react to problems. • Archaius handles configuration and gives the ability to dynamically change properties. API Gateway Other Services
  • 15.
    11/17/2018 (C) COPYRIGHTMETAMAGIC GLOBAL INC., NEW JERSEY, USA 15 1 # Name * Who Uses Pros Cons 1 Media Type Versioning Accept: Application/vnd.api.article+xml; version=1.0 Med GitHub • Version Directly @ resource level • Preserve URI • Close to RESTful Specs • Harder to Test • Distort HTTP Headers purpose • Tools required for testing 2 Custom Headers Versioning X-API-Version: 2. Med Microsoft • Preservers URI • Harder to Test • Tools required for testing 3 URI Versioning api.example.com/v1/resource High Google Twitter Amazon • Most common method • Versions can be explored using Browser • Easy to use • Disrupts RESTful Compliance. URI should represent resource and not versions 4 Domain Versioning apiv1.example.com/resource Low Facebook • Same as are URI Versioning • Same as URI Versioning 5 Request Parameter Versioning GET /something/?version=0.1 High Pivotal NetFlix • Similar to URI versioning • It can get messy 6 Date Versioning First request saves the date. Low Clearbit • New APIs can be shipped without changing the end points • Complex to implement • Traceability is difficult. API Versioning
  • 16.
    Service Mesh –Sidecar Design Pattern 17-11-2018 16 CB – Circuit Breaker LB – Load Balancer SD – Service Discovery Microservice Process1Process2 Service Mesh Control Plane Service Discovery Routing Rules Control Plane will have all the rules for Routing and Service Discovery. Local Service Mesh will download the rules from the Control pane will have a local copy. Service Discovery Calls Service Mesh Calls Customer Microservice Application Localhost calls http://localhost/order/processOrder Router Network Stack LBCB SD ServiceMesh Sidecar UI Layer Web Services Business Logic Order Microservice Application Localhost calls http://localhost/payment/processPayment Router Network Stack LBCB SD ServiceMesh Sidecar UI Layer Web Services Business Logic Data Plane 1
  • 17.
    Service Mesh –Traffic Control 17-11-2018 17 API Gateway End User Business Logic Service Mesh Sidecar Customer Service Mesh Control Plane Admin Traffic Rules Traffic Control rules can be applied for • different Microservices versions • Re Routing the request to debugging system to analyze the problem in real time. • Smooth migration path Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Order v1.0 Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Order v2.0 Service Cluster 1
  • 18.
    Micro Services DeploymentModel Micro Services with Multiple Technology Stack Event Stream Users Service Discovery (Eureka) Config Server (Spring) API (Zuul) Gateway UI Layer Web Services Business Logic Database Layer Micro Service 2 ShoppingCart SE 8 LB = Ribbon CB = Hystrix LB = Ribbon CB = Hystrix UI Layer Web Services Business Logic Database Layer Product SE 8 Micro Service 1 With 4 node cluster LB = Ribbon CB = Hystrix UI Layer Web Services Business Logic Database Layer Order SE 8 Micro Service 3 With 2 node Cluster LB = Ribbon CB = Hystrix UI Layer Web Services Business Logic Database Layer Customer Micro Service 4 With 2 node cluster HTTP Server All UI Code is bundled Virtual Private Network 1
  • 19.
    Pros 1. Adds Complexity 2.Skillset shortage 3. Confusion on getting the right size 4. Team need to manage end-to-end of the Service (From UI to Backend to Running in Production). 11/17/2018 19 1. Robust 2. Scalable 3. Testable (Local) 4. Easy to Change and Replace 5. Easy to Deploy 6. Technology Agnostic Cons Microservices Pros and Cons1 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
  • 20.
    Summary – MicroServices Intro 17-11-2018 20 SOA Martin Fowler – Micro Services Architecture https://martinfowler.com/articles/microservices.html Dzone – SOA vs Micro Services : https://dzone.com/articles/microservices-vs-soa-2 1 Key Features 1. Small in size 2. Messaging–enabled 3. Bounded by contexts 4. Autonomously developed 5. Independently deployable 6. Decentralized 7. Language–agnostic 8. Built and released with automated processes Micro Service Micro Service Micro Service Micro Service Micro Service Micro Service Micro Service Micro Service Microservice is not SOA.
  • 21.
    12 Factor AppMethodology 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 21 1 4 Backing Services Treat Backing services like DB, Cache as attached resources 5 Build, Release, Run Separate Build and Run Stages 6 Process Execute App as One or more Stateless Process 7 Port Binding Export Services with Specific Port Binding 8 Concurrency Scale out via the process Model 9 Disposability Maximize robustness with fast startup and graceful exit 10 Dev / Prod Parity Keep Development, Staging and Production as similar as possible 11 Logs Treat logs as Event Streams 12 Admin Process Run Admin Tasks as one of Process Source:https://12factor.net/ Factors Description 1 Codebase One Code base tracked in revision control 2 Dependencies Explicitly declare dependencies 3 Configuration Configuration driven Apps
  • 22.
    11/17/2018 (C) COPYRIGHTMETAMAGIC GLOBAL INC., NEW JERSEY, USA 22 • Business Solution & Process • Capability Centric Design • Domain Driven Design • Strategic Design • Tactical Design • Hexagonal Architecture • Event Sourcing & CQRS • ES and CQRS • Event Sourcing Example • Functional Reactive Programming • 4 Building Blocks of RxJava • Observable and Observer Design Pattern Microservices Architecture & Design2 It’s not necessary that you need to use all these patterns. You will be using these based on your technical requirement
  • 23.
    Business Solution &Business Process 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 23  Business Solution focuses the entire Journey of the User which can run across multiple Micro Services.  Business Solution comprises a set of Business Processes.  A specific Micro Service functionality will be focused on a Business Process / Concern Business Solution: Customer Dining Experience Order PaymentFood Menu KitchenDining Browse Menu Order Dinner Dinner Served Get Bill Make Payment 2
  • 24.
    Capability Centric Design 11/17/201824 Vertically sliced Product Team Business Centric Development • Focus on Business Capabilities • Entire team is aligned towards Business Capability. • From Specs to Operations – The team handles the entire spectrum of Software development. • Every vertical will have it’s own Code Pipeline Front-End-Team Back-End-Team Database-Team In a typical Monolithic way the team is divided based on technology / skill set rather than business functions. This leads to not only bottlenecks but also lack of understanding of the Business Domain. QA / QC Team Front-End Back-End Database Business Capability 1 QA/QCTeam Front-End Back-End Database Business Capability 2 QA/QCTeam Front-End Back-End Database Business Capability 3 QA/QCTeam 2
  • 25.
    11/17/2018 (C) COPYRIGHTMETAMAGIC GLOBAL INC., NEW JERSEY, USA 25 Domain Driven Design • Strategic Design • Tactical Design
  • 26.
    Bounded Context –Strategic Design 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 26 2 • Bounded Context is a Specific Business Process / Concern. • Components / Modules inside the Bounded Context are context specific. • Multiple Bounded Contexts are linked using Context Mapping. • One Team assigned to a Bounded Context. • Each Bounded Context will have it’s own Source Code Repository. • When the Bounded Context is being developed as a key strategic initiative of your organization, it’s called the Core Domain. • Within a Bounded Context the team must have same language called Ubiquitous language for Spoken and for Design / Code Implementation.
  • 27.
    DDD: Bounded Context– Strategic Design 11/17/2018 27 An App User’s Journey can run across multiple Bounded Context / Micro Services. User Journey X Bounded Context Bounded Context Bounded Context Dinning Order Reservation Tables Recipes Raw Materials Frozen Semi Cooked Appetizer Veg Appetizer Non Veg Soft Drinks Main Course Non Veg Main Course Veg Hot Drinks Desserts Steward Chef Menu uses uses Dinning Order Reservation Tables Recipes Raw Materials Frozen Semi Cooked Appetizer Veg Appetizer Non Veg Soft Drinks Main Course Non Veg Main Course Veg Hot Drinks Desserts Steward Chef Menu uses uses UnderstandingBoundedContext(DDD)ofaRestaurantApp Dinning Context Kitchen Context Menu Context Source: Domain-Driven Design Reference by Eric Evans 2 Areas of the domain treated independently Discovered as you assess requirements and build language
  • 28.
    17 November 201828 Ubiquitous Language Vocabulary shared by all involved parties Used in all forms of spoken / written communication Ubiquitous Language Domain Expert Analyst Developers QA Design Docs Test Cases Code Restaurant Context – Food Item : Eg. Food Item (Navrathnakurma) can have different meaning or properties depends on the context. • In the Menu Context it’s a Veg Dish. • In the Kitchen Context it’s is recipe. • And in the Dining Context it will have more info related to user feed back etc. 2 DDD: Ubiquitous Language: Strategic Design As an Restaurant Owner I want to know who my Customers are So that I can serve them better Role-Feature-Reason Matrix BDD – Behavior Driven Development Given Customer John Doe exists When Customer orders food Then Assign customer preferences as Veg or Non Veg customer BDD Construct
  • 29.
    DDD : ContextMap – Strategic Design 17November2018 29 Source: Domain-Driven Design Reference by Eric Evans 2 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA Context Map defines the relationship of Bounded Contexts
  • 30.
    11/17/2018 30 Hexagonal Architecture Ports& Adapters The layer between the Adapter and the Domain is identified as the Ports layer. The Domain is inside the port, adapters for external entities are on the outside of the port. The notion of a “port” invokes the OS idea that any device that adheres to a known protocol can be plugged into a port. Similarly many adapters may use the Ports. Source : http://alistair.cockburn.us/Hexagonal+architecture https://skillsmatter.com/skillscasts/5744-decoupling-from-asp-net-hexagonal-architectures-in-net Services for UI Ports File system Database Order Tracking JPA Repository Implementation Adapters OrderProcessing Domain Service (Business Rules) Implementation Domain Models Domain Layer Order Data Validation OrderService REST Service Implementation OrderProcessing Interface p Order Tracking Repository Interface p A A External Apps A A A Others A A OrderService Interface p Web Services Data Store Use Case Boundary Bounded Context A (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA • Reduces Technical Debt • Dependency Injection • Auto Wiring 2
  • 31.
    Shopping Portal Modules– Code Packaging 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 31 Auth Products Cart OrderCustomer Domain Layer • Models • Repo • Services • Factories Adapters • Repo • Services • Web Services Domain Layer • Models • Repo • Services • Factories Adapters • Repo • Services • Web Services Domain Layer • Models • Repo • Services • Factories Adapters • Repo • Services • Web Services Packaging Structure Bounded Context Implementation (Repositories, Business Services, Web Services) 1 Domain Models (Entities, Value Objects, DTOs) (Repositories, Business Services, Web Services) Entity Factories Interfaces (Ports)
  • 32.
    Domain Driven Design– Tactical Design 11/17/2018 32 Source: Domain-Driven Design Reference by Eric Evans (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 2
  • 33.
    DDD: Understanding AggregateRoot 33 Order Customer Shipping Address Aggregate Root Line Item Line Item Line Item * Payment Strategy Credit Card Cash Bank Transfer Source: Martin Fowler : Aggregate Root • An aggregate will have one of its component objects be the aggregate root. Any references from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as a whole. • Aggregates are the basic element of transfer of data storage - you request to load or save whole aggregates. Transactions should not cross aggregate boundaries. • Aggregates are sometimes confused with collection classes (lists, maps, etc.). • Aggregates are domain concepts (order, clinic visit, playlist), while collections are generic. An aggregate will often contain multiple collections, together with simple fields. 125 Domain Driven Design 2 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
  • 34.
    Shopping Portal 11/17/2018 (C)COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 34 Order ModuleModels Value Object • Currency • Item Value • Order Status • Payment Type • Record State • Audit Log Entity • Order (Aggregate Root) • Order Item • Shipping Address • Payment DTO • Order • Order Item • Shipping Address • Payment Domain Layer Adapters • Order Repository • Order Service • Order Web Service • Order Query Web Service • Shipping Address Web Service • Payment Web Service Adapters Consists of Actual Implementation of the Ports like Database Access, Web Services API etc. Converters are used to convert an Enum value to a proper Integer value in the Database. For Example Order Status Complete is mapped to integer value 100 in the database. Services / Ports • Order Repository • Order Service • Order Web Service Utils • Order Factory • Order Status Converter • Record State Converter • Order Query Web Service • Shipping Address Web Service • Payment Web Service
  • 35.
    DDD – Summary 11/17/2018(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 35 2 More on this in Event Sourcing & CQRS Section. 1. Bounded Context 2. Ubiquitous Language 3. Context Map Strategic Design 1. Aggregate Root 2. Value Object 3. Domain Events 4. Repository Pattern 5. Factory Tactical Design
  • 36.
    11/17/2018 (C) COPYRIGHTMETAMAGIC GLOBAL INC., NEW JERSEY, USA 36 CRUD / CQRS & Event Sourcing A brief introduction, more in Part 2 of the Series Event Storming and SAGA
  • 37.
    CRUD and CQRS 11/17/201837 Presentation Services Business Logic Data Access Data Store UpdatesQueries Traditional CRUD Architecture Source: https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs https://blogs.msdn.microsoft.com/maarten_mullender/2004/07/23/crud-only-when-you-can-afford-it-revisite • A mismatch between the read and write representations of the data. • It risks data contention when records are locked in the data store in a collaborative domain, where multiple actors operate in parallel on the same set of data. These risks increase as the complexity and throughput of the system grows. • It can make managing security and permissions more complex because each entity is subject to both read and write operations, which might expose data in the wrong context. CRUD Disadvantages (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 2
  • 38.
    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). • CQRS should be used along with Event Sourcing. 11/17/2018 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 38 MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx | Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html CQS : Bertrand Meyer Axon Framework For Java Java Axon Framework Resource : http://www.axonframework.org Greg Young (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 2
  • 39.
    Event Sourcing Intro 11/17/201839 Standard CRUD Operations – Customer Profile – Aggregate Root Profile Created Title Updated New Address added Derived Notes Removed Time T1 T2 T4T3 Event Sourcing and Derived Aggregate Root Commands 1. Create Profile 2. Update Title 3. Add Address 4. Delete Notes 2 Events 1. Profile Created Event 2. Title Updated Event 3. Address Added Event 4. Notes Deleted Event 3 Current State of the Customer Profile 4 Event store Single Source of Truth Greg Young 2
  • 40.
    Restaurant Dining –Event Sourcing and CQRS 11/17/2018 40 Order Payment • Add Drinks • Add Food • Update Food Commands • Open Table • Add Juice • Add Soda • Add Appetizer 1 • Add Appetizer 2 • Serve Drinks • Prepare Food • Serve Food Events • Drinks Added • Food Added • Food Updated • Food Discontinued • Table Opened • Juice Added • Soda Added • Appetizer 1 Added • Appetizer 2 Added • Juice Served • Soda Served • Appetizer Served • Food Prepared • Food Served • Prepare Bill • Process Payment • Bill Prepared • Payment Processed • Payment Approved • Payment Declined • Cash Paid 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. Microservices • Dinning Order • Billable Order Customer Journey thru Dinning Processes Processes Food Menu KitchenDining • Remove Soda • Add Food 1 • Add Food 2 • Place Order • Close Table • Remove Soda • Food 1 Added • Food 2 Added • Order Placed • Table Closed ES Aggregate 3 2 4 1 The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles. 2
  • 41.
    Use Case :Shopping Portal – Event Sourcing / CQRS 11/17/2018 41 Catalogue Shopping Cart Order Payment • Search Products • Add Products • Update Products Commands • Add to Cart • Remove Item • Update Quantity Customer • Process Order • Select Address • Select Delivery Mode Events • Product Added • Product Updated • Product Discontinued • Item Added • Item Removed / Discontinued • Item Updated • Order Initiated • Address Selected • Delivery Mode Selected • Order Created • Proceed for Payment • Confirm Order for Payment • Cancel Order • Payment Initiated • Order Cancelled • Order Confirmed • OTP Send • Payment Approved • Payment Declined Commands are End-User interaction with the App and based on the commands (Actions) Events are created. These Events includes both Domain Events and Integration Events. Event Sourced Aggregates will be derived using Domain Events. Each Micro Service will have its own separate Database. Depends on the scalability requirement each of the Micro Service can be scaled separately. For Example. Catalogue can be on a 50 node cluster compared to Customer Micro Service. Microservices • Customer • Shop.. Cart • Order Customer Journey thru Shopping Process The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles. 3 2 ES Aggregate 4 2
  • 42.
    Summary – EventSourcing and CQRS 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 42 2 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.
  • 43.
    11/17/2018 (C) COPYRIGHTMETAMAGIC GLOBAL INC., NEW JERSEY, USA 43 Functional Reactive Programming
  • 44.
    Functional Reactive Programming 11/17/201844 ResilientElastic Message – Driven 1. A responsive, maintainable & Extensible application is the goal. 2. A responsive application is both scalable (Elastic) and resilient. 3. Responsiveness is impossible to achieve without both scalability and resilience. 4. A Message-Driven architecture is the foundation of scalable, resilient, and ultimately responsive systems. Value Means Form Principles What it means? Responsive thus React to users demand Resilient thus React to errors and failures Elastic thus React to load Message-Driven thus React to events and messages Source: http://reactivex.io/ Responsive Maintainable Extensible (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 2
  • 45.
    4 Building Blocksof RxJava 17 November 2018 45 Source of Data Stream [ Sender ]Observable1 Listens for emitted values [ Receiver ]Observer2 2 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA Source: http://reactivex.io/ Schedulers3 Schedulers are used to manage and control concurrency. 1. observeOn: Thread Observable is executed 2. subscribeOn: Thread subscribe is executed 4 Operators Content Filtering Time Filtering Transformation Operators that let you Transform, Combine, Manipulate, and work with the sequence of items emitted by Observables
  • 46.
    Observable / ObserverDesign Pattern 17 November 2018 46 • Allows for Concurrent Operations: the observer does not need to block while waiting for the observable to emit values • Observer waits to receive values when the observable is ready to emit them • Based on push rather than pull 1 & 2Building Block Source: http://reactivex.io/RxJava/javadoc/index.html?rx/Observable.html 2 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
  • 47.
    What’s missing fromGOF Observer Pattern 17 November 2018 47 1 Building Block Source:http://reactivex.io/intro.html 1. The ability for the producer to signal to the consumer that there is no more data available (a foreach loop on an Iterable completes and returns normally in such a case; an Observable calls its observer’s onComplete method) 2. The ability for the producer to signal to the consumer that an error has occurred (an Iterable throws an exception if an error takes place during iteration; an Observable calls its observer’s onError method) 3. Multiple Thread Implementations and hiding those details. 4. Dozens of Operators to handle data. 2 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
  • 48.
    Compare Iterable Vs.Observable 17 November 2018 48 Observable is the asynchronous / push dual to the synchronous pull Iterable • Composable: Easily chained together or combined • Flexible: Can be used to emit: • A scalar value (network result) • Sequence (items in a list) • Infinite streams (weather sensor) • Free from callback hell: Easy to transform one asynchronous stream into another Observables are: Event Iterable (Pull) Observable (Push) Retrieve Data T next() onNext(T) Discover Error throws Exception onError (Exception) Complete !hasNext() onComplete() 1Building Block Source: http://reactivex.io/RxJava/javadoc/index.html?rx/Observable.html 2 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
  • 49.
    Comparison : Iterable/ Streams / Observable 17 November 2018 49 1Building Block First Class Visitor (Consumer) Serial Operations Parallel Streams (10x Speed) Still On Next, On Complete and On Error are Serial Operations Completely Asynchronous Operations Java 8 – Blocking CallJava 6 – Blocking Call Rx Java - Freedom 2 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA Source Code: https://github.com/meta-magic/rxjava
  • 50.
    17 November 201850 Functional Reactive Programming : Design Patterns Single Component Pattern A Component shall do ONLY one thing, But do it in FULL. Single Responsibility Principle By DeMarco : Structured Analysis & System Specification (Yourdon, New York, 1979) Let-It-Crash Pattern Prefer a FULL component restart to complex internal failure handling. Candea & Fox: Crash-Only Software (USENIX HotOS IX, 2003) Popularized by Netflix Chaos Monkey. Erlang Philosophy Saga Pattern Divide long-lived distributed transactions into quick local ones with compensating actions for recovery. Pet Helland: Life Beyond Distributed Transactions CIDR 2007 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 2
  • 51.
    Summary – FunctionalReactive Programming 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 51 2 1. A responsive, maintainable & Extensible application is the goal. 2. A responsive application is both scalable (Elastic) and resilient. 3. Responsiveness is impossible to achieve without both scalability and resilience. 4. A Message-Driven architecture is the foundation of scalable, resilient, and ultimately responsive systems.
  • 52.
    11/17/2018 (C) COPYRIGHTMETAMAGIC GLOBAL INC., NEW JERSEY, USA 52 • Microservice Scalability • CAP Theorem • ACID vs BASE • Distributed Transactions : 2 Phase Commit • SAGA Design Pattern • Scalability Lessons from EBay Scalability3
  • 53.
    Scale Cube andMicro Services 17-11-2018 53 1. Y Axis Scaling – Functional Decomposition : Business Function as a Service 2. Z Axis Scaling – Database Partitioning : Avoid locks by Database Sharding 3. X Axis Scaling – Cloning of Individual Services for Specific Service Scalability 3 Source: The NewStack. Based on the Art of Scalability by By Martin Abbot & Michael Fisher
  • 54.
    CAP Theorem by EricAllen Brewer 17November2018 54 Pick Any 2!! Say NO to 2 Phase Commit  Source: http://en.wikipedia.org/wiki/Eric_Brewer_(scientist) CAP 12 years later: How the “Rules have changed” : http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed “In a network subject to communication failures, it is impossible for any web service to implement an atomic read / write shared memory that guarantees a response to every request.” 3
  • 55.
    ACID vs BASE 11/17/2018(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 55 3 Atomic • All operations in a transaction succeed or every operation is rolled back. Consistent • On the completion of a transaction, the database is structurally sound. Isolated • Transactions do not contend with one another. Contentious access to data is moderated by the database so that transactions appear to run sequentially. Durable • The results of applying a transaction are permanent, even in the presence of failures. Basic Availability • The database appears to work most of the time. Soft-state • Stores don’t have to be write-consistent, nor do different replicas have to be mutually consistent all the time. Eventual consistency • Stores exhibit consistency at some later point (e.g., lazily at read time).
  • 56.
    Distributed Transactions :2 Phase Commit 2 PC or not 2 PC, Wherefore Art Thou XA? 17November2018 56 How does 2PC impact scalability? • Transactions are committed in two phases. • This involves communicating with every database (XA Resources) involved to determine if the transaction will commit in the first phase. • During the second phase each database is asked to complete the commit. • While all of this coordination is going on, locks in all of the data sources are being held. • The longer duration locks create the risk of higher contention. • Additionally, the two phases require more database processing time than a single phase commit. • The result is lower overall TPS in the system. Transaction Manager XA Resources Request to Prepare Commit Prepared Prepare Phase Commit PhaseDone Source : Pat Helland (Amazon) : Life Beyond Distributed Transactions Distributed Computing : http://dancres.github.io/Pages/ Solution : Resilient System • Event Based • Design for failure • Asynchronous Recovery • Make all operations idempotent. • Each DB operation is a 1 PC 3 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
  • 57.
    SAGA Design Patterninstead of 2PC 11/17/2018 57 Long Lived Transactions (LLTs) hold on to DB resources for relatively long periods of time, significantly delaying the termination of shorter and more common transactions. Source: SAGAS (1987) Hector Garcia Molina / Kenneth Salem, Dept. of Computer Science, Princeton University, NJ, USA T1 T2 Tn Local Transactions C1 C2 Cn-1 Compensating Transaction Divide long–lived, distributed transactions into quick local ones with compensating actions for recovery. Travel : Flight Ticket & Hotel Booking Example BASE (Basic Availability, Soft State, Eventual Consistency) Room ReservedT1 Room PaymentT2 Seat ReservedT3 Ticket PaymentT4 Cancelled Room Reservation C1 Cancelled Room Payment C2 Cancelled Ticket Reservation C3 3
  • 58.
    Scalability Best Practices: Lessons from Best Practices Highlights #1 Partition By Function • Decouple the Unrelated Functionalities. • Selling functionality is served by one set of applications, bidding by another, search by yet another. • 16,000 App Servers in 220 different pools • 1000 logical databases, 400 physical hosts #2 Split Horizontally • Break the workload into manageable units. • eBay’s interactions are stateless by design • All App Servers are treated equal and none retains any transactional state • Data Partitioning based on specific requirements #3 Avoid Distributed Transactions • 2 Phase Commit is a pessimistic approach comes with a big COST • CAP Theorem (Consistency, Availability, Partition Tolerance). Apply any two at any point in time. • @ eBay No Distributed Transactions of any kind and NO 2 Phase Commit. #4 Decouple Functions Asynchronously • If Component A calls component B synchronously, then they are tightly coupled. For such systems to scale A you need to scale B also. • If Asynchronous A can move forward irrespective of the state of B • SEDA (Staged Event Driven Architecture) #5 Move Processing to Asynchronous Flow • Move as much processing towards Asynchronous side • Anything that can wait should wait #6 Virtualize at All Levels • Virtualize everything. eBay created their on O/R layer for abstraction #7 Cache Appropriately • Cache Slow changing, read-mostly data, meta data, configuration and static data. 17November2018 58 Source: http://www.infoq.com/articles/ebay-scalability-best-practices 3 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
  • 59.
    11/17/2018 59 Design Patternsare solutions to general problems that software developers faced during software development. Design Patterns3 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
  • 60.
    Scalability Summary 11/17/2018 60 1.Scale Cube Scaling in All 3 Axis 1. Functional Decomposition 2. Database Partitioning 3. Cloning Services 2. Eventual Consistency 3. SAGA for Distributed Transaction (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
  • 61.
    11/17/2018 (C) COPYRIGHTMETAMAGIC GLOBAL INC., NEW JERSEY, USA 61 • Microservices Testing Strategies • Testing Anti Patterns • Testing Scenarios / Tools • Chaos Engineering • Behavior Driven Development Microservices Testing Strategies4
  • 62.
    Microservices Testing Strategies 11/17/2018(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 62 Ubiquitous Language Domain Expert Analyst Developers QA Design Docs Test Cases Code E2E Testing Integration Testing Contract Testing Component Testing Unit Testing Number of Tests Speed Cost Time 4 Mike Cohen’s Testing Pyramid Test Pyramid: https://martinfowler.com/bliki/TestPyramid.html 70% 20% 10%
  • 63.
    Other Testing Strategiesor Anti Patterns 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 63 Inverted Pyramid / Ice Cream Cone Strategy Unit Testing Integration Testing End 2 End Testing Hour Glass Strategy 70% 20% 10% 45% 45% 10% 4
  • 64.
    Microservices Testing Strategy 11/17/2018(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 64 Unit Testing A unit test exercises the smallest piece of testable software in the application to determine whether it behaves as expected. Source: https://martinfowler.com/articles/microservice-testing/#agenda Component Testing A component test limits the scope of the exercised software to a portion of the system under test, manipulating the system through internal code interfaces and using test doubles to isolate the code under test from other components. Integration Testing An integration test verifies the communication paths and interactions between components to detect interface defects Integration Contract Testing An Integration Contract test is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service. End 2 End Testing An end-to-end test verifies that a system meets external requirements and achieves its goals, testing the entire system, from end to end 4 Say NO to End 2 End Tests - Mike Walker April 22, 2015. Google Test Blog
  • 65.
    Testing ToolsMicroservices TestingScenarios / Tools 65 Contract Testing Scope Integration Testing Verifies the communication paths and interactions between components to detect interface defects Contract Testing It is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service. Payment Mock IntegrationContractTestingScope Test Double Montebank Cart Component Testing Unit Testing IntegrationTestingScope Order REST / HTTP or Events / Kafka Item ID, Quantity, Address.. Mock Order Component Testing A component test limits the scope of the exercised software to a portion of the system under test. 4 Order Payment Unit Testing Firewall Integration Testing Scope REST / HTTP Payment Sandbox Component Testing
  • 66.
    Chaos Engineering –Load / Stress / Performance 11/17/2018 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 66 4 Chaos Monkey Randomly disables production instances Chaos Kong Similar to Chaos Monkey, simulates an outage of an entire Amazon availability zone. Doctor Monkey Checks CPU load, Memory usage and removes it from network if the health is bad. Janitor Monkey Search for unused resources and disposes them. Compliance Monkey Finds instances that don’t adhere to best-practices and shuts them down. Latency Money Induces Artificial delays Security Monkey Is an extension of Compliance Monkey. Find security vulnerabilities and terminates offending instances. Source: https://github.com/Netflix/SimianArmy/wikiSource: http://principlesofchaos.org/
  • 67.
    Behavior Driven Development 11/17/2018(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 67 4 Source: https://dannorth.net/introducing-bdd/ As an insurance Broker I want to know who my Gold Customers are So that I sell more Given Customer John Doe exists When he buys insurance ABC for $1000 USD Then He becomes a Gold Customer BDD Construct Role-Feature-Reason Matrix As a Customer I want to withdraw Cash from ATM So that I don’t have to wait in line at the bank Given The account is in Credit AND the Card is Valid AND the dispenser contains Cash BDD Construct Role-Feature-Reason Matrix When The Customer requests Cash Then Ensure that the Account is debited AND Ensure cash is dispensed AND ensure that Card is returned.
  • 68.
    Features of BDD 11/17/2018(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 68 4 • Focus on Behavior of the System rather than tests. • Collaboration between Business Stake holders, Analysts, Developers, QA. • Ubiquitous Language • Driven By Business Value • Extends Test Driven Development Source: https://cucumber.io/ Cucumber merges specification and test documentation into one cohesive whole.
  • 69.
    Microservices Architecture Summary 11/17/2018(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 69 • API Gateway • Service Discovery • Service Mesh • Event Streams Infrastructure Architecture1 • Capability Centric Design • Domain Driven Design • Event Sourcing & CQRS • Functional Reactive Programming Software Architecture and Design2 • Microservices Scalability • CAP Theorem • Distributed Transactions • SAGA Design Pattern • Scalability Lessons from EBay Scalability3 • Microservices Testing Strategy • Testing Anti-Patterns • Testing Scenarios / Tools • Behavior Driven Development Testing Strategies4
  • 70.
    70 Araf Karsh Hamid: Co-Founder / CTO araf.karsh@metamagic.in USA: +1 (973) 969-2921 India: +91.999.545.8627 Skype / LinkedIn / Twitter / Slideshare : arafkarsh http://www.slideshare.net/arafkarsh https://www.linkedin.com/in/arafkarsh/ http://www.arafkarsh.com/ DREAM | AUTOMATE | EMPOWER
  • 71.
    References 11/17/2018 71 1. Lewis,James, and Martin Fowler. “Microservices: A Definition of This New Architectural Term”, March 25, 2014. 2. Miller, Matt. “Innovate or Die: The Rise of Microservices”. e Wall Street Journal, October 5, 2015. 3. Newman, Sam. Building Microservices. O’Reilly Media, 2015. 4. Alagarasan, Vijay. “Seven Microservices Anti-patterns”, August 24, 2015. 5. Cockcroft, Adrian. “State of the Art in Microservices”, December 4, 2014. 6. Fowler, Martin. “Microservice Prerequisites”, August 28, 2014. 7. Fowler, Martin. “Microservice Tradeoffs”, July 1, 2015. 8. Humble, Jez. “Four Principles of Low-Risk Software Release”, February 16, 2012. 9. Zuul Edge Server, Ketan Gote, May 22, 2017 10. Ribbon, Hysterix using Spring Feign, Ketan Gote, May 22, 2017 11. Eureka Server with Spring Cloud, Ketan Gote, May 22, 2017 12. Apache Kafka, A Distributed Streaming Platform, Ketan Gote, May 20, 2017 13. Functional Reactive Programming, Araf Karsh Hamid, August 7, 2016 14. Enterprise Software Architectures, Araf Karsh Hamid, July 30, 2016 15. Docker and Linux Containers, Araf Karsh Hamid, April 28, 2015 4
  • 72.
    References 11/17/2018 (C) COPYRIGHTMETAMAGIC GLOBAL INC., NEW JERSEY, USA 72 Domain Driven Design 16. Oct 27, 2012 What I have learned about DDD Since the book. By Eric Evans 17. Mar 19, 2013 Domain Driven Design By Eric Evans 18. May 16, 2015 Microsoft Ignite: Domain Driven Design for the Database Driven Mind 19. Jun 02, 2015 Applied DDD in Java EE 7 and Open Source World 20. Aug 23, 2016 Domain Driven Design the Good Parts By Jimmy Bogard 21. Sep 22, 2016 GOTO 2015 – DDD & REST Domain Driven API’s for the Web. By Oliver Gierke 22. Jan 24, 2017 Spring Developer – Developing Micro Services with Aggregates. By Chris Richardson 23. May 17. 2017 DEVOXX – The Art of Discovering Bounded Contexts. By Nick Tune Event Sourcing and CQRS 23. Nov 13, 2014 GOTO 2014 – Event Sourcing. By Greg Young 24. Mar 22, 2016 Spring Developer – Building Micro Services with Event Sourcing and CQRS 25. Apr 15, 2016 YOW! Nights – Event Sourcing. By Martin Fowler 26. May 08, 2017 When Micro Services Meet Event Sourcing. By Vinicius Gomes 4
  • 73.
    References 11/17/2018 73 27. MSDN– Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx 28. Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html 29. Udi Dahan : CQRS – http://www.udidahan.com/2009/12/09/clarified-cqrs/ 30. Greg Young : CQRS - https://www.youtube.com/watch?v=JHGkaShoyNs 31. Bertrand Meyer – CQS - http://en.wikipedia.org/wiki/Bertrand_Meyer 32. CQS : http://en.wikipedia.org/wiki/Command–query_separation 33. CAP Theorem : http://en.wikipedia.org/wiki/CAP_theorem 34. CAP Theorem : http://www.julianbrowne.com/article/viewer/brewers-cap-theorem 35. CAP 12 years how the rules have changed 36. EBay Scalability Best Practices : http://www.infoq.com/articles/ebay-scalability-best-practices 37. Pat Helland (Amazon) : Life beyond distributed transactions 38. Stanford University: Rx https://www.youtube.com/watch?v=y9xudo3C1Cw 39. Princeton University: SAGAS (1987) Hector Garcia Molina / Kenneth Salem 40. Rx Observable : https://dzone.com/articles/using-rx-java-observable 4
  • 74.
    References – MicroServices – Videos 41. Martin Fowler – Micro Services : https://www.youtube.com/watch?v=2yko4TbC8cI&feature=youtu.be&t=15m53s 42. GOTO 2016 – Microservices at NetFlix Scale: Principles, Tradeoffs & Lessons Learned. By R Meshenberg 43. Mastering Chaos – A NetFlix Guide to Microservices. By Josh Evans 44. GOTO 2015 – Challenges Implementing Micro Services By Fred George 45. GOTO 2016 – From Monolith to Microservices at Zalando. By Rodrigue Scaefer 46. GOTO 2015 – Microservices @ Spotify. By Kevin Goldsmith 47. Modelling Microservices @ Spotify : https://www.youtube.com/watch?v=7XDA044tl8k 48. GOTO 2015 – DDD & Microservices: At last, Some Boundaries By Eric Evans 49. GOTO 2016 – What I wish I had known before Scaling Uber to 1000 Services. By Matt Ranney 50. DDD Europe – Tackling Complexity in the Heart of Software By Eric Evans, April 11, 2016 51. AWS re:Invent 2016 – From Monolithic to Microservices: Evolving Architecture Patterns. By Emerson L, Gilt D. Chiles 52. AWS 2017 – An overview of designing Microservices based Applications on AWS. By Peter Dalbhanjan 53. GOTO Jun, 2017 – Effective Microservices in a Data Centric World. By Randy Shoup. 54. GOTO July, 2017 – The Seven (more) Deadly Sins of Microservices. By Daniel Bryant 55. Sept, 2017 – Airbnb, From Monolith to Microservices: How to scale your Architecture. By Melanie Cubula 56. GOTO Sept, 2017 – Rethinking Microservices with Stateful Streams. By Ben Stopford. 57. GOTO 2017 – Microservices without Servers. By Glynn Bird. 11/17/2018 74 4
  • 75.
    11/17/2018 (C) COPYRIGHTMETAMAGIC GLOBAL INC., NEW JERSEY, USA 75 Simoorg : LinkedIn’s own failure inducer framework. It was designed to be easy to extend and most of the important components are plug‐ gable. Pumba : A chaos testing and network emulation tool for Docker. Chaos Lemur : Self-hostable application to randomly destroy virtual machines in a BOSH- managed environment, as an aid to resilience testing of high-availability systems. Chaos Lambda : Randomly terminate AWS ASG instances during business hours. Blockade : Docker-based utility for testing network failures and partitions in distributed applications. Chaos-http-proxy : Introduces failures into HTTP requests via a proxy server. Monkey-ops : Monkey-Ops is a simple service implemented in Go, which is deployed into an OpenShift V3.X and generates some chaos within it. Monkey-Ops seeks some OpenShift components like Pods or DeploymentConfigs and randomly terminates them. Chaos Dingo : Chaos Dingo currently supports performing operations on Azure VMs and VMSS deployed to an Azure Resource Manager-based resource group. Tugbot : Testing in Production (TiP) framework for Docker. Testing tools
  • 76.
    UI Design Patterns 11/17/2018 (C) COPYRIGHTMETAMAGIC GLOBAL INC., NEW JERSEY, USA 76
  • 77.
    UI DesignPatterns MVC/ MVP/MVVM 77 View Controller Model Passes calls To Fire Events Manipulates • The Controller is responsible to process incoming requests. It receives input from users via the View, then process the user's data with the help of Model and passing the results back to the View. • Typically, it acts as the coordinator between the View and the Model. • The Presenter is responsible for handling all UI events on behalf of the view. This receive input from users via the View, then process the user's data with the help of Model and passing the results back to the View. • Unlike view and controller, view and presenter are completely decoupled from each other’s and communicate to each other’s by an interface. Also, presenter does not manage the incoming request traffic as controller. • Supports two-way data binding between View and ViewModel. View ViewModel Model Passes calls To Manipulates Updates Fire Events • The View Model is responsible for exposing methods, commands, and other properties that helps to maintain the state of the view, manipulate the model as the result of actions on the view, and trigger events in the view itself. • There is many-to-one relationship between View and ViewModel means many View can be mapped to one ViewModel. • Supports two-way data binding between View and ViewModel. View Presenter Model Passes calls To Fire Events Manipulates Updates1 1 1 * Model View Controller Model View Presenter Model View ViewModel
  • 78.
    UI Design Patterns Flux/ Redux ViewDispatcher Every action is sent to all Stores via callbacks the stores register with the Dispatcher Store Action Action 1 * Controller-Views • Listens to Store changes • Emit Actions to Dispatcher Dispatcher • Single Dispatcher per Application • Manages the Data Flow View to Model • Receives Actions and dispatch them to Stores Stores • Contains state for a Domain (Vs. Specific Component) • In Charge of modifying the Data • Inform the views when the Data is changed by emitting the Changed Event. Flux Core Concepts 1. One way Data Flow 2. No Event Chaining 3. Entire App State is resolved in store before Views Update 4. Data Manipulation ONLY happen in one place (Store). Actions • Simple JS Objects • Contains Name of the Action and Data (Payload) • Action represent something that has happened. • Has No Business Logic (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
  • 79.
    UI Design PatternsRedux Actions • Simple JS Objects • Contains Name of the Action and Data (Payload) • Has NO Business Logic • Action represent something that has happened. Store • Multiple View layers can Subscribe • View layer to Dispatch actions • Single Store for the Entire Application • Data manipulation logic moves out of store to Reducers Reducer • Pure JS Functions • No External calls • Can combine multiple reducers • A function that specifies how the state changes in response to an Action. • Reducer does NOT modify the state. It returns the NEW State. Redux Core Concepts 1. One way Data Flow 2. No Dispatcher compared to Flux 3. Immutable Store Available for React & Angular View Action State Dispatcher Reducer R R R Store Middleware Middleware Middleware • Handles External calls • Multiple Middleware's can be chained. (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
  • 80.
    11/17/2018 (C) COPYRIGHTMETAMAGIC GLOBAL INC., NEW JERSEY, USA 80 UI Development – Angular / Amexio2 • Angular Basics • Amexio Components Intro • Amexio API & Examples • Layouts and Themes • Charts and Dashboards • Angular Routing, Data Binding • Concepts • Business Use • Migration from v1.x to 2.x Functional Reactive Programming1 • Examples • Comparison • Workshop Examples with Rx 2 Additional Topics – If Time permits

Editor's Notes

  • #4 https://www.forrester.com/report/Application+Modernization+Service+By+Microservice/-/E-RES122550 https://www.forrester.com/report/Microservices+And+External+APIs+Underpin+Digital+Business/-/E-RES137951 e(l(44)/3) = 3.5
  • #5 MASA = Mesh App and Service Architecture
  • #13 https://dzone.com/articles/microservices-vs-soa-2
  • #14 https://dzone.com/articles/microservices-vs-soa-2
  • #16 https://dzone.com/articles/api-versioning-methods-a-brief-reference-1?fromrel=true https://docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/APIUsage.html
  • #17 https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/
  • #29 http://www.infoq.com/articles/ddd-contextmapping http://www.slideshare.net/aca_it/modularity-ddd?from_action=save
  • #33 http://domainlanguage.com/ddd/patterns/DDD_Reference_2011-01-31.pdf http://www.infoq.com/interviews/domain-driven-design-eric-evans
  • #34 http://martinfowler.com/bliki/DDD_Aggregate.html Effective Aggregate Design By Vaughn Vernon Part 1 : http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf Part 2 : http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_2.pdf Part 3 : http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_3.pdf Video Part 2 : https://vimeo.com/33708293
  • #38 Source : https://blogs.msdn.microsoft.com/maarten_mullender/2004/07/23/crud-only-when-you-can-afford-it-revisited/I t often means that there's a mismatch between the read and write representations of the data, such as additional columns or properties that must be updated correctly even though they aren't required as part of an operation. It risks data contention when records are locked in the data store in a collaborative domain, where multiple actors operate in parallel on the same set of data. Or update conflicts caused by concurrent updates when optimistic locking is used. These risks increase as the complexity and throughput of the system grows. In addition, the traditional approach can have a negative effect on performance due to load on the data store and data access layer, and the complexity of queries required to retrieve information. It can make managing security and permissions more complex because each entity is subject to both read and write operations, which might expose data in the wrong context.
  • #39 Source: MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html Udi Dahan : CQRS – http://www.udidahan.com/2009/12/09/clarified-cqrs/ Greg Young : CQRS - https://www.youtube.com/watch?v=JHGkaShoyNs Bertrand Meyer – CQS - http://en.wikipedia.org/wiki/Bertrand_Meyer http://en.wikipedia.org/wiki/Command–query_separation https://skillsmatter.com/courses/345-greg-youngs-cqrs-domain-events-event-sourcing-and-how-to-apply-ddd
  • #45 http://reactivex.io/ http://techblog.netflix.com/2013/01/reactive-programming-at-netflix.html http://reactivex.io/learnrx/ Download the API: https://github.com/ReactiveX/RxJava http://mvnrepository.com/artifact/io.reactivex/rxjava/1.1.0 http://blog.danlew.net/2014/09/15/grokking-rxjava-part-1/ https://realm.io/ http://blog.reactiveprogramming.org/ What is Reactive Programming? https://medium.com/reactive-programming/what-is-reactive-programming-bc9fa7f4a7fc#.57mt1ieow What is Functional Reactive Programming? https://www.bignerdranch.com/blog/what-is-functional-reactive-programming/ Reactive Programming Patterns with Java 8 Features https://www.youtube.com/watch?v=tiJEL3oiHIY Going Reactive with Java 8 https://www.youtube.com/watch?v=y-8sHHbMks4 Reactive Programming for Java Developers https://www.youtube.com/watch?v=fz31sbwOYq8 http://www.slideshare.net/rickbwarren/building-scalable-stateless-applications-with-rx-java?related=1
  • #46 Stanford Unv: Rx https://www.youtube.com/watch?v=y9xudo3C1Cw https://dzone.com/articles/using-rx-java-observable https://github.com/Betterment/DaggerStarter http://www.grahamlea.com/2014/07/rxjava-threading-examples/ RxJava in Different Flavours http://instil.co/2014/08/05/rxjava-in-different-flavours-of-java/ https://github.com/Netflix/RxJava https://github.com/Netflix/RxJava/wiki http://www.infoq.com/author/Erik-Meijer React conference http://www.youtube.com/playlist?list=PLSD48HvrE7-Z1stQ1vIIBumB0wK0s8llY Cat picture taken from http://www.teckler.com/en/Rapunzel
  • #47 http://reactivex.io/documentation/observable.html
  • #48 http://reactivex.io/documentation/observable.html
  • #49 RxJava API Docs : http://reactivex.io/RxJava/javadoc/
  • #50 http://reactivex.io/documentation/observable.html
  • #51 ACID (atomicity, consistency, isolation, and durability) BASE is a family of styles that include basic availability, soft state, and eventual consistency
  • #55 http://en.wikipedia.org/wiki/CAP_theorem http://www.julianbrowne.com/article/viewer/brewers-cap-theorem http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
  • #57 Pat Helland (Amazon) : Life beyond distributed transactions… http://adrianmarriott.net/logosroot/papers/LifeBeyondTxns.pdf
  • #58 BASE is a family of styles that include basic availability, soft state, and eventual consistency
  • #59 http://www.infoq.com/articles/ebay-scalability-best-practices
  • #63  https://martinfowler.com/bliki/TestPyramid.html
  • #64 https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html
  • #65 https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html https://martinfowler.com/bliki/TestPyramid.html
  • #66 http://selenide.org/ http://www.mbtest.org/ https://junit.org/junit5/ http://site.mockito.org/ https://docs.pact.io/implementation_guides https://www.telepresence.io/ https://www.slideshare.net/PierreVincent3/consumerdriven-contracts-avoid-microservices-integration-hell-mucon-london-nov-2016
  • #67 https://medium.com/netflix-techblog/the-netflix-simian-army-16e57fbab116