Microservices Docker Kubernetes Istio - Comment
|
Introduction to Microservices Architecture, Docker, Kubernetes, Istio, Testing Strategies for Microservices based Apps. Security Best Practices. Kanban, DevOps, and SRE. Infrastructure Design Patterns - API Gateway - Service Discovery - Load Balancer - Circuit Breaker - Let-it-Crash Pattern Software Design Patterns - Hexagonal Architecture - Domain Driven Design - Event Sourcing and CQRS - Functional Reactive Programming Topics covered: 1. Microservices Architecture Building Cloud Native Apps Design Patterns, Containers, Kubernetes, Istio, Kafka, Saga – Distributed Transactions, Testing, Security, Kanban SRE, DevOps ARAF KARSH HAMID Co-Founder / CTO MetaMagic Global Inc., NJ, USA @arafkarsh arafkarsh 2. 2Slides are color coded based on the topic colors. Microservices Containers & Kubernetes, Kafka 1 Infrastructure Patterns Capability Centric Design DDD / ES & CQRS Reactive Programming 2 Testing Strategies Security Best Practices 3 Agile: Kanban ITSM, DevOps, SRE 4 3. MICROSERVICES • CONCEPTS • WHEN SHOULD YOU USE MICROSERVICES? • WHAT’S THE RIGHT SIZE? • ARCHITECTURE (INFRATRUCTURE AND SOFTWRE) 4/1/2019 3 1 4. 4Source: https://cloud.google.com/kubernetes-engine/kubernetes-comic/ 5. Pioneers in Microservices Implementation 01-04-2019 5 New Entrants 6. 6 100s Microservices 1,000s Releases / Day 10,000s Virtual Machines 100K+ User actions / Second 81 M Customers Globally 1 B Time series Metrics 10 B Hours of video streaming every quarter Source: NetFlix: : https://www.youtube.com/watch?v=UTKIT6STSVM 10s OPs Engineers 0 NOC 0 Data Centers So what do NetFlix think about DevOps? No DevOps Don’t do lot of Process / Procedures Freedom for Developers & be Accountable Trust people you Hire No Controls / Silos / Walls / Fences Ownership – You Build it, You Run it. 7. 7 50M Paid Subscribers 100M Active Users 60 Countries Cross Functional Team Full, End to End ownership of features Autonomous1000+ Microservices Source: https://microcph.dk/media/1024/conference-microcph-2017.pdf 1000+ Tech Employees 120+ Teams 8. Microservices definition 4/1/2019 8 In short, 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. https://martinfowler.com/articles/microservices.html By James Lewis and Martin Fowler Bolo Definition Kya hai? Tell me what’s the definition 9. Microservices Characteristics 9 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 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 10. When should I use them (Microservices)? 01-04-2019 10 • 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/ 11. What is the right size for a Microservice? 01-04-2019 11 • 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. 12. Microservices Architecture / Design Patterns 01-04-2019 12 • API Gateway • Service Discovery • Load Balancer • Config Service • Circuit Breaker • Service Mesh • Event Bus / Streams • Hexagonal Architecture • Domain Driven Design • Event Sourcing & CQRS • Functional Reactive Programming • MVC, MV*, Redux Infrastructure Architecture 13. 13 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 / Queues / Pub-Sub / Storage 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 UI Layer WS BL DL Database ShoppingCart Order Customer Inventory 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) Load Balancer (Ribbon) Circuit Breaker (Hystrix) 12 14. 01-04-2019 14 SOA vs. Microservices Example Traditional Monolithic App with SOA Micro Services with Multiple Technology Stack Event Stream / Queues/ Pub-Sub / Storage 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 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 Smart Pipes Lot of Business logic resides in the Pipe 15. Microservices Deployment Model Microservices with Multiple Technology Stack – Software Stack for Networking Event Stream / Queues / Pub-Sub / Storage 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 01-04-2019 15 16. Shopping Portal – Docker / Kubernetes – Network Stack /ui /productms Load Balancer Ingress Deployment / Replica / Pod NodesKubernetes Objects Firewall UI Pod UI Pod UI Pod UI Service N1 N2 N2 EndPoints Product Pod Product Pod Product Pod Product Service N4 N3 MySQL Pod EndPoints Review Pod Review Pod Review Pod Review Service N4 N3 N1 Service Call Kube DNS EndPoints Internal Load Balancers 16 Users Routing based on Layer 3,4 and 7 17. 17 Source:https://cloud.google.com/kubernetes-engine/kubernetes-comic/ Each one of the Microservices can now be • Debugged, • Updated, and • Deployed individually without the whole Project coming to a standstill. An important step on the path to • Continuous Integration and • Continuous Delivery. 18. 18 Source:https://cloud.google.com/kubernetes-engine/kubernetes-comic/ 19. 19Source: https://cloud.google.com/kubernetes-engine/kubernetes-comic/ 20. 20 12FactorAppMethodology 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 Checkout the Shift – Left in DevOps (Slide 157) 11 Logs Treat logs as Event Streams 12 Admin Process Run Admin Tasks as one of Process (Eg. DB Migration, Software upgrades, etc..) Factors Description 1 Codebase One Code base tracked in revision control 2 Dependencies Explicitly declare dependencies 3 Configuration Configuration driven Apps Source:https://12factor.net/ 21. Catalogues of Microservices 4/1/2019 21 System Z Model From Spotify • Different types of Components Z Supports • Libraries • Data Pipelines • Views in the client • Data Store • Service 22. 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). 01-04-2019 22 1. Robust 2. Scalable 3. Testable (Local) 4. Easy to Change and Replace 5. Easy to Deploy 6. Technology Agnostic Cons Microservices Pros and Cons 23. Monolithic > Microservices • FORRESTER RESEARCH • MODERNIZATION JOURNEY • ASSESS AND CLASSIFY YOUR APP PORTFOLIO • PLAN AND PRIORITIZE 4/1/2019 23 24. Conway’s Law 4/1/2019 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 24 Any Organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. 25. * 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) 2501-04-2019 26. Scale Cube and Micro Services 4/1/2019 26 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 27. Modernization Journey 4/1/2019 27 Start new features as Microservices Incrementally establish the success early. Expose Legacy On-Premise Apps API’s If legacy Apps cant be shifted to Cloud Refactor Monolithic features to Microservices Breakdown and Deploy Feature by Feature Containerize the Microservice Reduce costs, simplifies the operations and consistent environment between Dev, QA and Production Monolith De-commission Plan Incrementally sunset the Monolith Velocity as you transform Increase your Delivery Velocity along the Journey High FuturePresent Low Inspired by a paper from IBM 28. Assess and Classify your App Portfolio 4/1/2019 28 Take inventory of your Apps Classify the Apps based on technology, complexity. Align Apps to your Business Priorities Identify the Apps that are critical for Modernization. Identify Business Modernization Requirements Create a Roadmap with faster go to market strategy Understand the effort and Cost Evaluate all possible Modernization options Container Refactor Expose APIsLift & Shift BusinessValueCostComplexity Product Catalogue Product Review Inventory Shopping Cart Customer Profile Order Management Inspired by a paper from IBM 29. Plan and Prioritize 4/1/2019 29 Complexity Cost Value Score Rank Weightage 35% 25% 40% Customer Med 3 Med 3 Low 1 2.20 7 6 Product Reviews Med 3 High 5 Med 3 3.50 11 3 Product Catalogue Med 3 Med 3 High 5 4.80 11 1 Shopping Cart High 5 Med 3 Med 3 3.70 11 4 Order Very High 7 Med 3 High 5 5.20 15 2 Inventory Very High 7 High 5 Med 3 4.90 15 5 Prioritize Low Priority projects are good test cases but does not bring much business value. Quick Wins Identify a feature / project which has good business value and low in complexity. Project Duration Focus on shorter duration projects with high Business Value. Shopping Portal Features Prioritization Inspired by a paper from IBM 30. Monolithic to Microservices Summary 4/1/2019 30 1. Classify your Apps into Following areas 1. Lift and Shit 2. Containerize 3. Refactor 4. Expose API 2. Prioritize High Business Value Low Technical Complexity 3. Focus on Shorter Duration – From Specs to Operation 31. Containers & Kubernetes • DOCKER CONTAINERS • KUBERNETES – CONTAINER ORCHESTRATION • ISTIO – TRAFFIC MANAGEMENT / NETWORK POLICIES 4/1/2019 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 31 32. Servers / Virtual Machines / Containers Hardware OS BINS / LIB App 1 App 2 App 3 Server Hardware Host OS HYPERVISOR App 1 App 2 App 3 Guest OS BINS / LIB Guest OS BINS / LIB Guest OS BINS / LIB Type 1 Hypervisor Hardware Host OS App 1 App 2 App 3 BINS / LIB BINS / LIB BINS / LIB Container Hardware HYPERVISOR App 1 App 2 App 3 Guest OS BINS / LIB Guest OS BINS / LIB Guest OS BINS / LIB Type 2 Hypervisor01-04-2019 32 33. Docker containers are Linux Containers CGROUPS NAME SPACES Copy on Write DOCKER CONTAINER • Kernel Feature • Groups Processes • Control Resource Allocation • CPU, CPU Sets • Memory • Disk • Block I/O • Images • Not a File System • Not a VHD • Basically a tar file • Has a Hierarchy • Arbitrary Depth • Fits into Docker Registry • The real magic behind containers • It creates barriers between processes • Different Namespaces • PID Namespace • Net Namespace • IPC Namespace • MNT Namespace • Linux Kernel Namespace introduced between kernel 2.6.15 – 2.6.26 docker runlxc-start 33 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/resource_management_guide/ch01 01-04-2019 34. Linux Kernel 34 HOST OS (Ubuntu) Client Docker Daemon Cent OS Alpine Debian LinuxKernel Host Kernel Host Kernel Host Kernel All the containers will have the same Host OS Kernel If you require a specific Kernel version then Host Kernel needs to be updated HOST OS (Windows 10) Client Docker Daemon Nano Server Server Core Nano Server WindowsKernel Host Kernel Host Kernel Host Kernel Windows Kernel 35. Docker DaemonDocker Client How Docker works…. $ docker search …. $ docker build …. $ docker container create .. Docker Hub Images Containers $ docker container run .. $ docker container start .. $ docker container stop .. $ docker container ls .. $ docker push …. $ docker swarm .. 01-04-2019 35 21 34 1. Search for the Container 2. Docker Daemon Sends the request to Hub 3. Downloads the image 4. Run the Container from the image 36. Kubernetes Key Concepts 4/1/2019 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 36 o Declarative Model Infrastructure as a code o Desired State Required state of your App / Microservice o Current State Current State of the App due to error or load factor Pods Replicas Deploy Service 37. Deployment – Updates and rollbacks, Canary Release D ReplicaSet – Self Healing, Scalability, Desired State R Worker Node 1 Master Node (Control Plane) Kubernetes Architecture POD POD itself is a Linux Container, Docker container will run inside the POD. PODs with single or multiple containers (Sidecar Pattern) will share Cgroup, Volumes, Namespaces of the POD. (Cgroup / Namespaces) Scheduler Controller Manager Using yaml or json declare the desired state of the app. State is stored in the Cluster store. Self healing is done by Kubernetes using watch loops if the desired state is changed. POD POD POD BE 1.210.1.2.34 BE 1.210.1.2.35 BE 1.210.1.2.36 BE 15.1.2.100 DNS: a.b.com 1.2 Service Pod IP Address is dynamic, communication should be based on Service which will have routable IP and DNS Name. Labels (BE, 1.2) play a critical role in ReplicaSet, Deployment, & Services etc. Cluster Store etcd Key Value Store Pod Pod Pod Label Selector selects pods based on the Labels. Label Selector Label Selector Label Selector Node Controller End Point Controller Deployment Controller Pod Controller …. Labels Internet Firewall K8s Cluster Cloud Controller For the cloud providers to manage nodes, services, routes, volumes etc. Kubelet Node Manager Container Runtime Interface Port 10255 gRPC ProtoBuf Kube-Proxy Network Proxy TCP / UDP Forwarding IPTABLES / IPVS Allows multiple implementation of containers from v1.7 RESTful yaml / json $ kubectl …. Port 443API Server Pod IP ...34 ...35 ...36EP • Declarative Model • Desired State Key Aspects Namespace1Namespace2 • Pods • ReplicaSet • Deployment • Service • Endpoints • StatefulSet • Namespace • Resource Quota • Limit Range • Persistent Volume Kind Secrets Kind • apiVersion: • kind: • metadata: • spec: Declarative Model • Pod • ReplicaSet • Service • Deployment • Virtual Service • Gateway, SE, DR • Policy, MeshPolicy • RbaConfig • Prometheus, Rule, • ListChekcer … @ @ Annotations Names Cluster IP Node Port Load Balancer External Name @ Ingress 01-04-2019 37 38. Service Mesh – Sidecar Design Pattern 01-04-2019 38 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/api/order/ Router Network Stack LBCB SD ServiceMesh Sidecar UI Layer Web Services Business Logic Order Microservice Application Localhost calls http://localhost/api/payment/ Router Network Stack LBCB SD ServiceMesh Sidecar UI Layer Web Services Business Logic Data Plane 39. Shopping Portal /ui /productms /auth /order Gateway Virtual Service Deployment / Replica / Pod NodesIstio Sidecar - Envoy Load Balancer Kubernetes Objects Istio Objects Firewall P M CIstio Control Plane UI Pod N5v2Canary v2User X = Canary Others = Stable A / B Testing using Canary Deployment v1 UI Pod UI Pod UI Pod UI Service N1 N2 N2 Destination Rule Stable / v1 EndPoints Internal Load Balancers 39 Source:https://github.com/meta-magic/kubernetes_workshop Users Product Pod Product Pod Product Pod Product Service MySQL Pod N4 N3 Destination Rule EndPoints Review Pod Review Pod Review Pod Review Service N1 N4 N3 Service Call Kube DNS EndPoints 40. Shopping Portal /ui /productms /auth /order Gateway Virtual Service Deployment / Replica / Pod NodesIstio Sidecar - Envoy Load Balancer Kubernetes Objects Istio Objects Firewall P M CIstio Control Plane UI Pod N5v2Canary v2 v1 UI Pod UI Pod UI Pod UI Service N1 N2 N2 Destination Rule Stable / v1 EndPoints Internal Load Balancers 40 Source:https://github.com/meta-magic/kubernetes_workshop Users Product Pod Product Pod Product Pod Product Service MySQL Pod N4 N3 Destination Rule EndPoints Review Pod Review Pod Review Pod Review Service N1 N4 N3 Service Call Kube DNS EndPoints Traffic Shifting Canary Deployment 10% = Canary 90% = Stable 41. Shopping Portal /ui /productms /auth /order Gateway Virtual Service Deployment / Replica / Pod NodesIstio Sidecar - Envoy Load Balancer Kubernetes Objects Istio Objects Firewall P M CIstio Control Plane UI Pod N5 v2Canary v2 v1 UI Pod UI Pod UI Pod UI Service N1 N2 N2 Destination Rule Stable / v1 EndPoints Internal Load Balancers 41 Source:https://github.com/meta-magic/kubernetes_workshop Users Product Pod Product Pod Product Pod Product Service MySQL Pod N4 N3 Destination Rule EndPoints Review Pod Review Pod Review Pod Review Service N1 N4 N3 Service Call Kube DNS EndPoints Blue Green Deployment 100% = Stable When you want to shift to v2 Change 100% to Canary 42. Shopping Portal /ui /productms /auth /order Gateway Virtual Service Deployment / Replica / Pod NodesIstio Sidecar - Envoy Load Balancer Kubernetes Objects Istio Objects Firewall P M CIstio Control Plane UI Pod N5 v2Canary v2 v1 UI Pod UI Pod UI Pod UI Service N1 N2 N2 Destination Rule Stable / v1 EndPoints Internal Load Balancers 42 Source:https://github.com/meta-magic/kubernetes_workshop Users Product Pod Product Pod Product Pod Product Service MySQL Pod N4 N3 Destination Rule EndPoints Review Pod Review Pod Review Pod Review Service N1 N4 N3 Service Call Kube DNS EndPoints Mirror Deployment 100% = Stable Mirror = Canary Production Data is mirrored to new release for real-time testing 43. 43 Shopping Portal /ui /productms /auth /order Gateway Virtual Service Deployment / Replica / Pod NodesIstio Sidecar - Envoy Load Balancer Firewall P M CIstio Control PlaneFault Injection MySQL Pod N4 N3 Destination Rule Product Pod Product Pod Product Pod Product Service Service Call Kube DNS EndPoints Internal Load Balancers 43 Source:https://github.com/meta-magic/kubernetes_workshop Fault Injection Delay = 2 Sec Abort = 10% Kubernetes Objects Istio Objects Users Review Pod Review Pod Review Pod Review Service N1 N4 N3EndPoints UI Pod UI Pod UI Pod UI Service N1 N2 N2 Destination Rule v1EndPoints 44. Container & Kubernetes Summary 4/1/2019 44 1. Containers are NOT Virtual Machines 2. Containers are isolated area in the OS kernel 3. Kubernetes – is a Container Orchestration Platform. 4. Kubernetes abstracts the cloud vendor (AWS, Azure, GCP) scalability features. 5. Kubernetes Concepts – Declarative Model, Desired State and Current State. 45. Kafka • CONCEPTS : QUEUES / PUB – SUB / EVENT STREAMING • WHY IS IT DIFFERENT FROM TRADITIONAL MESSAGE QUEUES? • DATA STORAGE / CLUSTER / DURABILITY • PERFORMANCE 4/1/2019 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 45 46. Kafka Core Concepts 01-04-2019 46 Publish & Subscribe Read and write streams of data like a messaging system Process Write scalable stream processing apps that react to events in real- time. Store Store streams of data safely in a distributed, replicated, fault tolerant cluster. 47. Traditional Queue / Pub-Sub Vs. Kafka 01-04-2019 47 0 1 2 3 4 5 6 7 8 9 8 7 9 Consumer 1 Consumer 2 Consumer 3 Queues Data Data can be partitioned for scalability for parallel processing by same type of consumers Pros: Cons: Queues are NOT multi subscribers. Once a Consumer reads the data, its gone from the queue. Ordering of records will be lost in asynchronous parallel processing. 0 1 2 3 4 5 6 7 8 9 9 9 9 Consumer 1 Consumer 2 Consumer 3 Pub – Sub Data Multiple subscribers can get the same data.Pros: Scaling is difficult as every message goes to every subscriber. Cons: Kafka generalizes these two concepts. As with a queue the consumer group allows you to divide up processing over a collection of processes (the members of the consumer group). As with publish-subscribe, Kafka allows you to broadcast messages to multiple consumer groups. 48. Anatomy of a Topic 01-04-2019 48 Source : https://kafka.apache.org/intro • A Topic is a category or feed name to which records are published. • Topics in Kafka are always multi subscriber. • That is, a Topic can have zero, one, or many consumers that subscribe to the data written to it. • Each Partition is an ordered, immutable sequence of records that is continually appended to—a structured commit log. • A Partition is nothing but a directory of Log Files • The records in the partitions are each assigned a sequential id number called the offset that uniquely identifies each record within the partition. 49. 01-04-2019 49 Partition Log Segment • Partition (Kafka’s Storage unit) is Directory of Log Files. • A partition cannot be split across multiple brokers or even multiple disks • Partitions are split into Segments • Segments are two files: 000.log & 000.index • Segments are named by their base offset. The base offset of a segment is an offset greater than offsets in previous segments and less than or equal to offsets in that segment. • Indexes store offsets relative to its segments base offset • Indexes map each offset to their message position in the log and they are used to look up messages. • Purging of data is based on oldest segment and one segment at a time. 0 1 2 3 4 5 6 7 8 9 Partition Data 6 3 0 Segment 0 Segment 3 Segment 6 9 Segment 9 - Active $ tree kafka-logs | head -n 6 kafka-logs |──── SigmaHawk-2 | |──── 00000000006109871597.index | |──── 00000000006109871597.log | |──── 00000000007306321253.index | |──── 00000000007306321253.log Topic / Partition Segment 1 Segment 2 Rel.Offset, Position Offset, Position, Size, Payload 0000.index 0000.log 0 0 0 0 7 ABCDEFG 1 7 1 7 4 ABCD 2 11 2 11 9 ABCDEFGIJ 4 Bytes 4 Bytes 50. 01-04-2019 50 Kafka Cluster – Topics & Partitions • The partitions of the log are distributed over the servers in the Kafka cluster with each server handling data and requests for a share of the partitions. Source : https://kafka.apache.org/intro Broker 1 Leader Broker 2 Follower Broker 3 Follower Broker 4 Follower Broker 5 Leader Partition 1 Partition 0 Topic ABC • Each server acts as a leader for some of its partitions and a follower for others so load is well balanced within the cluster. • Each partition has one server which acts as the "leader" and zero or more servers which act as "followers". 51. 01-04-2019 51 Record Commit Process Broker 1 Leader Topic 1 Broker 2 Follower Producer Consumer 2 2 Commit 3 ack • Each partition is replicated across a configurable number of servers for fault tolerance. • The leader handles all read and write requests for the partition while the followers passively replicate the leader. • If the leader fails, one of the followers will automatically become the new leader.1 Message with Offset 4 777743 Broker 3 Follower Data Durability From Kafka v0.8.0 onwards acks Acknowledgement Description 0 If set to zero then the producer will NOT wait for any acknowledgment from the server at all. The record will be immediately added to the socket buffer and considered sent. No guarantee can be made that the server has received the record in this case, and the retries configuration will not take effect (as the client won't generally know of any failures). The offset given back for each record will always be set to -1. 1 This will mean the leader will write the record to its local log but will respond without awaiting full acknowledgement from all followers. In this case should the leader fail immediately after acknowledging the record but before the followers have replicated it then the record will be lost. All / -1 This means the leader will wait for the full set of in-sync replicas to acknowledge the record. This guarantees that the record will not be lost as long as at least one in-sync replica remains alive. This is the strongest available guarantee. This is equivalent to the acks=-1 setting. Source: https://kafka.apache.org/documentation/#topicconfigs acks Steps 0 1 1 1,3 -1 1,2,3 Producer Configuration 52. 01-04-2019 52 Replication 6 3.2 m1 m2 m3 L(A) m1 m2 F(B) m1 F(C)ISR = (A, B, C) Leader A commits Message m1. Message m2 & m3 not yet committed. 1 m1 m2 F(C) m1 m2 L(B) m1 m2 m3 L(A) ISR = (B,C) A fails and B is the new Leader. B commits m22 m1 m2 m3 L(A) m1 m2 L(B) m4 m5 m1 m2 F(C) m4 m5 ISR = (B,C) B commits new messages m4 and m5 3 m1 m2 L(B) m4 m5 m1 m2 F(C) m4 m5 m1 F(A) ISR = (A, B,C) A comes back, restores to last commit and catches up to latest messages. 4 m1 m2 L(B) m4 m5 m1 m2 F(C) m4 m5 m1 m2 F(A) m4 m5 ISR – In-sync Replica • Instead of majority vote, Kafka dynamically maintains a set of in-sync replicas (ISR) that are caught-up to the leader. • Only members of this set are eligible for election as leader. • A write to a Kafka partition is not considered committed until all in-sync replicas have received the write. • This ISR set is persisted to ZooKeeper whenever it changes. Because of this, any replica in the ISR is eligible to be elected leader. 53. LinkedIn Kafka Cluster 01-04-2019 53 Brokers60 Partitions50K Messages / Second800K MB / Second inbound300 MB / Second Outbound1024 The tuning looks fairly aggressive, but all of the brokers in that cluster have a 90% GC pause time of about 21ms, and they’re doing less than 1 young GC per second. 54. Uber Kafka Cluster 01-04-2019 54 Topics10K+ Events / Second11M Petabytes of Data1PB+ 55. Kafka Summary 4/1/2019 55 1. Combined Best of Queues and Pub / Sub Model. 2. Data Durability 3. Fastest Messaging Infrastructure 4. Streaming capabilities 5. Replication 56. 4/1/2019 56 Architecture & Design Patterns • I N F R A ST R U C T U R E D ES I G N PAT T E R N S • C A PA B I L I T Y C E N T R I C D ES I G N • D O M A I N D R I V E N D ES I G N • E V E N T S O U RC I N G & CQ RS • F U N C T I O NA L R EAC T I V E P RO G R A M M I N G • U I D ES I G N PAT T E R N S • R EST F U L A P I S A N D V E RS I O N I N G 2 57. 4/1/2019 57 Infrastructure Design Patterns • API GATEWAY • LOAD BALANCER • SERVICE DISCOVERY • CIRCUIT BREAKER • SERVICE AGGREGATOR • LET-IT CRASH PATTERN 58. API Gateway Design Pattern 58 UILayer WS BL DL Database Shopping Cart Order Customer Product Firewall Users API Gateway LoadBalancer CircuitBreaker UILayer WebServices BusinessLogic DatabaseLayer Product SE8 Product Microservice With 4 node cluster LoadBalancer CircuitBreaker UILayer WebServices BusinessLogic DatabaseLayer Customer Customer Microservice With 2 node cluster Users Access the Monolithic App Directly API Gateway (Reverse Proxy Server) routes the traffic to appropriate Microservices (Load Balancers) 59. Load Balancer Design Pattern 59 Firewall Users API Gateway Load Balancer CircuitBreaker UILayer WebServices BusinessLogic DatabaseLayer Product SE8 Product Microservice With 4 node cluster Load Balancer CB=Hystrix UILayer WebServices BusinessLogic DatabaseLayer Customer Customer Microservice With 2 node cluster API Gateway (Reverse Proxy Server) routes the traffic to appropriate Microservices (Load Balancers) Load Balancer Rules 1. Round Robin 2. Based on Availability 3. Based on Response Time 60. Service Discovery – NetFlix Network Stack Model 60 Firewall Users API Gateway LoadBalancer CircuitBreaker Product Product Microservice With 4 node cluster LoadBalancer CircuitBreaker UILayer WebServices BusinessLogic DatabaseLayer Customer Customer Microservice With 2 node cluster • In this model Developers write the code in every Microservice to register with NetFlix Eureka Service Discovery Server. • Load Balancers and API Gateway also registers with Service Discovery. • Service Discovery will inform the Load Balancers about the instance details (IP Addresses). Service Discovery 61. Service Discovery – Kubernetes Model Kubernetes Objects Firewall Service Call Kube DNS 61 Users Sports 1 Sports 2 Sports 3 Sports Service N4 N3 N1 EndPoints Internal Load Balancers DB Reverse Proxy Server API Gateway N1 N2 N2Politics 1 Politics 2 Politics 3 Politics Service EndPoints DB Internal Load Balancers Pods Nodes • API Gateway (Reverse Proxy Server) doesn't know the instances (IP Addresses) of News Pod. It knows the IP address of the Services defined for each Microservice (News, Politics, Sports etc.). • Services handles the dynamic IP Addresses of the pods. Services will automatically discover the new Pods based on Labels. Service Definition from Kubernetes Perspective Internal Load Balancers EndPoints News Pod 1 News Pod 2 News Pod 3 News Service N4 N3 N2 Pods Nodes 62. Circuit Breaker Pattern /ui /productms If Product Review is not available Product service will return the product details with a message review not available. Reverse Proxy Server Ingress Deployment / Replica / Pod NodesKubernetes Objects Firewall UI Pod UI Pod UI Pod UI Service N1 N2 N2 EndPoints Product Pod Product Pod Product Pod Product Service N4 N3 MySQL Pod EndPoints Internal Load Balancers 62 Users Routing based on Layer 3,4 and 7 Review Pod Review Pod Review Pod Review Service N4 N3 N1 Service Call Kube DNS EndPoints 63. Service Aggregator Pattern /newservice Reverse Proxy Server Ingress Deployment / Replica / Pod Nodes Kubernetes Objects Firewall Service Call Kube DNS 63 Users Internal Load Balancers EndPoints News Pod News Pod News Pod News Service N4 N3 N2 News Service Portal • News Category wise Microservices • Aggregator Microservice to aggregate all category of news. Auto Scaling • Sports Events (IPL) spikes the traffic for Sports Microservice. • Auto scaling happens for both News and Sports Microservices. N1 N2 N2National National National National Service EndPoints Internal Load Balancers DB N1 N2 N2Politics Politics Politics Politics Service EndPoints DB Sports Sports Sports Sports Service N4 N3 N1 EndPoints Internal Load Balancers DB 64. Music UI 4/1/2019 64 Play Count Discography Albums 65. Service Aggregator Pattern /artist Reverse Proxy Server Ingress Deployment / Replica / Pod Nodes Kubernetes Objects Firewall Service Call Kube DNS 65 Users Internal Load Balancers EndPoints Artist Pod Artist Pod Artist Pod Artist Service N4 N3 N2 Spotify Microservices • Artist Microservice combines all the details from Discography, Play count and Playlists. Auto Scaling • Scaling of Artist and downstream Microservices will automatically scale depends on the load factor. N1 N2 N2Discography Discography Discography Discography Service EndPoints Internal Load Balancers DB N1 N2 N2Play Count Play Count Play Count Play Count Service EndPoints DB Playlist Playlist Playlist Playlist Service N4 N3 N1 EndPoints Internal Load Balancers DB 66. Software Network Stack Vs Network Stack 4/1/2019 66 Pattern Software Stack Java Software Stack .NET Kubernetes 1 API Gateway Zuul Server SteelToe Istio Envoy 2 Service Discovery Eureka Server SteelToe Kube DNS 3 Load Balancer Ribbon Server SteelToe Istio Envoy 4 Circuit Breaker Hysterix SteelToe 5 Config Server Spring Config SteelToe Secrets, Env - K8s Master Web Site https://netflix.github.io/ https://steeltoe.io/ https://kubernetes.io/ Developer need to write code to integrate with the Software Stack (Programming Language Specific. For Ex. Every microservice needs to subscribe to Service Discovery when the Microservice boots up. Service Discovery in Kubernetes is based on the Labels assigned to Pod and Services and its Endpoints (IP Address) are dynamically mapped (DNS) based on the Label. 67. Let-it-Crash Design Pattern – Erlang Philosophy 4/1/2019 67 • The Erlang view of the world is that everything is a process and that processes can interact only by exchanging messages. • A typical Erlang program might have hundreds, thousands, or even millions of processes. • Letting processes crash is central to Erlang. It’s the equivalent of unplugging your router and plugging it back in – as long as you can get back to a known state, this turns out to be a very good strategy. • To make that happen, you build supervision trees. • A supervisor will decide how to deal with a crashed process. It will restart the process, or possibly kill some other processes, or crash and let someone else deal with it. • Two models of concurrency: Shared State Concurrency, & Message Passing Concurrency. The programming world went one way (toward shared state). The Erlang community went the other way. • All languages such as C, Java, C++, and so on, have the notion that there is this stuff called state and that we can change it. The moment you share something you need to bring Mutex a Locking Mechanism. • Erlang has no mutable data structures (that’s not quite true, but it’s true enough). No mutable data structures = No locks. No mutable data structures = Easy to parallelize. 68. Let-it-Crash Design Pattern 4/1/2019 68 1. The idea of Messages as the first class citizens of a system, has been rediscovered by the Event Sourcing / CQRS community, along with a strong focus on domain models. 2. Event Sourced Aggregates are a way to Model the Processes and NOT things. 3. Each component MUST tolerate a crash and restart at any point in time. 4. All interaction between the components must tolerate that peers can crash. This mean ubiquitous use of timeouts and Circuit Breaker. 5. Each component must be strongly encapsulated so that failures are fully contained and cannot spread. 6. All requests sent to a component MUST be self describing as is practical so that processing can resume with a little recovery cost as possible after a restart. 69. Let-it-Crash : Comparison Erlang Vs. Microservices Vs. Monolithic Apps 69 Erlang Philosophy Micro Services Architecture Monolithic Apps (Java, C++, C#, Node JS ...) 1 Perspective Everything is a Process Event Sourced Aggregates are a way to model the Process and NOT things. Things (defined as Objects) and Behaviors 2 Crash Recovery Supervisor will decide how to handle the crashed process Kubernetes Manager monitors all the Pods (Microservices) and its Readiness and Health. K8s terminates the Pod if the health is bad and spawns a new Pod. Circuit Breaker Pattern is used handle the fallback mechanism. Not available. Most of the monolithic Apps are Stateful and Crash Recovery needs to be handled manually and all languages other than Erlang focuses on defensive programming. 3 Concurrency Message Passing Concurrency Domain Events for state changes within a Bounded Context & Integration Events for external Systems. Mostly Shared State Concurrency 4 State Stateless : Mostly Immutable Structures Immutability is handled thru Event Sourcing along with Domain Events and Integration Events. Predominantly Stateful with Mutable structures and Mutex as a Locking Mechanism 5 Citizen Messages Messages are 1st class citizen by Event Sourcing / CQRS pattern with a strong focus on Domain Models Mutable Objects and Strong focus on Domain Models and synchronous communication. 70. Infrastructure Design Patterns Summary 4/1/2019 70 1. API Gateway 2. Service Discovery 3. Load Balancer 4. Circuit Breaker 5. Service Aggregator Pattern 6. Let It Crash Pattern 71. CAPABILITY CENTRIC DESIGN • BUSINESS FUNCTIONS • BUSINESS PROCESS • TEAM STRUCTURE 4/1/2019 71 72. Business Solution & Business Process 4/1/2019 72 - Business Solution focuses the entire Journey of the User which can run across multiple Microservices. - Business Solution comprises a set of Business Processes. - A specific Microservice functionality will be focused on a Business Process / Concern - Business Process can be divided further into Business Functions Business Solution: Customer Dining Experience Order PaymentFood Menu KitchenDining Browse Menu Order Dinner Dinner Served Get Bill Make Payment 73. 4/1/2019 73 Capability Centric Design 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 74. 74 From Project Based Activity Oriented To Product Based Outcome Oriented Source: Sriram Narayan– https://martinfowler.com/bliki/BusinessCapabilityCentric.html 75. Capability Centric Design Summary 4/1/2019 75 1. Business Solutions 2. Business Process 3. Business Capabilities 4. Business Driven Teams (From Specs to Ops) 5. Outcome Oriented instead of Activity Oriented. 76. 4/1/2019 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 76 Software Design Patterns • DOMAIN DRIVEN DESIGN • EVENT SOURCING AND CQRS • FUNCTIONAL REACTIVE PROGRAMMING • DISTRIBUTED TRANSACTIONS • REDUX UI PATTERN • CASE STUDY 77. 4/1/2019 77 Domain Driven Design • STRATEGIC: BOUNDED CONTEXT, UBIQUITOUS LANGUAGE • TACTICAL DESIGN: ENTITIES, AGGREGATE ROOT, VALUE OBJECT, FACTORIES, REPOSITORY, EVENTS, SERVICES • CASE STUDY: SHOPPING PORTAL 78. DDD: Bounded Context – Strategic Design 01-04-2019 78 • 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. 79. DDD: App User’s Journey & Bounded Context 4/1/2019 79 An App User’s Journey can run across multiple Bounded Context / Micro Services. User Journey X Bounded Context Bounded Context Bounded Context User Journey Y 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 80. 4/1/2019 80 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. 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 81. 01-04-2019 81 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 • Reduces Technical Debt • Dependency Injection • Auto Wiring 82. Layered Architecture 01-04-2019 82 • Explicit Domain Models – Isolate your models from UI, Business Logic. • Domain Objects – Free of the Responsibility of displaying themselves or storing themselves or managing App Tasks. • Zero Dependency on Infrastructure, UI and Persistent Layers. • Use Dependency Injection for Loosely Coupled Objects. • All the Code for Domain Model in a Single Layer. • Domain Model should be Rich enough to represent Business Knowledge. Source: DDD Reference by Chris Evans Page 17 83. 4/1/2019 83 Domain Driven Design – Tactical Design Source: Domain-Driven Design Reference by Eric Evans 84. DDD: Understanding Aggregate Root 84 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 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA01-04-2019 85. DDD: Domain Events & Integration Events 01-04-2019 85 1. Domain Events represent something happened in a specific Domain. 2. Domain Events should be used to propagate STATE changes across Multiple Aggregates within the Bounded Context. 3. The purpose of Integration Events is to propagate committed transactions and updates to additional subsystems, whether they are other microservices, Bounded Contexts or even external applications. Source: Domain Events : Design and Implementation – Microsoft Docs – May 26, 2017 Domain Data Behavior Order (Aggregate Root) Data Behavior Address (Value Object) Data Behavior OrderItem (Child) 1 n 1 1 Order Created Domain Event Domain Layer Enforce consistency with other Aggregates Event Handler 1 Event Handler n Create and Publish Integration Event to Event Bus. Example: Order Placed Integration Event can be subscribed by Inventory system to update the Inventory details. Event Handler 2 86. 4/1/2019 86 Shopping Portal Modules – Code Packaging 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) Domain Models (Entities, Value Objects, DTOs) (Repositories, Business Services, Web Services) Entity Factories Interfaces (Ports) 87. 4/1/2019 87 DDD: Use Case Order Module Models 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 Shopping Portal 88. Procedural Design Vs. Domain Driven Design 88 1. Anemic Entity Structure 2. Massive IF Statements 3. Entire Logic resides in Service Layer 4. Type Dependent calculations are done based on conditional checks in Service Layer 4 1 23 Domain Driven Design with Java EE 6 By Adam Bien | Javaworld Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html 89. Polymorphic Business Logic inside a Domain object 01-04-2019 89 Domain Driven Design with Java EE 6 By Adam Bien | Javaworld Computation of the total cost realized inside a rich Persistent Domain Object (PDO) and not inside a service. This simplifies creating very complex business rules. Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html 90. Type Specific Computation in a Sub Class 90 We can change the computation of the shipping cost of a Bulky Item without touching the remaining classes. Its easy to introduce a new Sub Class without affecting the computation of the total cost in the Load Class. Domain Driven Design with Java EE 6 By Adam Bien | Javaworld of Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html 91. Object Construction : Procedural Way Vs. Builder Pattern 91 Procedural Way Builder Pattern Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html Domain Driven Design with Java EE 6 By Adam Bien | Javaworld 92. Domain Driven Design Summary 4/1/2019 92 1. Strategic Patterns 1. Bounded Context 2. Ubiquitous Language 2. Tactical Patterns 1. Aggregate Root 2. Repository 3. Entity and Value Object 4. Domain Events 93. 4/1/2019 93 Event Storming • EVENT SOURCING / CQRS • CASE STUDY: SHOPPING PORTAL • CASE STUDY: RESTAURANT APP • CASE STUDY: MOVIE BOOKING • CASE STUDY: MOVIE STREAMING 94. Mind Shift : From Object Modeling to Process Modeling 4/1/2019 94 Developers with Strong Object Modeling experience will have trouble making Events a first class citizen. • How do I start Event Sourcing? • Where do I Start on Event Sourcing / CQRS? The Key is: 1. App User’s Journey 2. Business Process 3. Ubiquitous Language – DDD 4. Capability Centric Design 5. Outcome Oriented The Best tool to define your process and its tasks. How do you define your End User’s Journey & Business Process? • Think It • Build It • Run IT 95. 95 Process • Define your Business Processes. Eg. Various aspects of Order Processing in an E-Commerce Site, Movie Ticket Booking, Patient visit in Hospital.1 Commands • Define the Commands (End-User interaction with your App) to execute the Process. Eg. Add Item to Cart is a Command.2 Event Sourced Aggregate • Current state of the Aggregate is always derived from the Event Store. Eg. Shopping Cart, Order etc. This will be part of the Rich Domain Model (Bounded Context) of the Micro Service.4 Projections • Projections focuses on the View perspective of the Application. As the Read & Write are different Models, you can have different Projections based on your View perspective. 5 Write Data Read Data Events • Commands generates the Events to be stored in Event Store. Eg. Item Added Event (in the Shopping Cart).3 Event Storming – Concept 96. 4/1/2019 96 Event Sourcing Intro 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 97. 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. 4/1/2019 97 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 98. 4/1/2019 98 Case Study: Restaurant Dining – Event Sourcing and CQRS 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 99. Case Study: Shopping Site – Event Sourcing / CQRS 4/1/2019 99 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 ESA • 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. 2 100. Case Study: Movie Booking – Event Sourcing / CQRS 4/1/2019 100 Order Payment • Search Movies • Add Movies • Update Movies Commands • Select Movie • Select Theatre / Show • Select Tickets • Process Order • Select Food • Food Removed • Skip Food • Process Order Events • Movie Added • Movie Updated • Movie Discontinued • Movie Added • Theatre / Show Added • Tickets Added • Order Initiated • Popcorn Added • Drinks Added • Popcorn Removed • Order Finalized • Proceed for Payment • Confirm Order for Payment • Cancel Order • Payment Initiated • Order Cancelled • Order Confirmed • OTP Send • Payment Approved • Payment Declined Movies Theatres Food Microservices 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. Theatre can be on a 50 node cluster compared to Food Micro Service. ESA • Theatre • Show • Order Customer Journey thru booking Movie Ticket The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles. 101. Case Study: Movie Streaming – Event Sourcing / CQRS 4/1/2019 101 Subscription Payment • Search Movies • Add Movies • Update Movies Commands • Request Streaming • Start Movie Streaming • Pause Movie Streaming • Validate Streaming License • Validate Download License Events • Movie Added • Movie Updated • Movie Discontinued • Streaming Requested • Streaming Started • Streaming Paused • Streaming Done • Streaming Request Accepted • Streaming Request Denied • Subscribe Monthly • Subscribe Annually • Monthly Subscription Added • Yearly Subscription Added • Payment Approved • Payment Declined Discovery Microservices 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. Theatre can be on a 50 node cluster compared to Food Micro Service. ESA • Stream List • Favorite List Customer Journey thru Streaming Movie / TV Show The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles. LicenseStreaming 102. Event Sourcing & CQRS Summary 4/1/2019 102 1. Process Ex. Various aspects of Order Processing in an E-Commerce Site, Movie Ticket Booking, Patient visit in Hospital. 2. Commands End-User interaction with your App) to execute the Process. Eg. Add Item to Cart is a Command. 3. Events Item Added Event (in the Shopping Cart). 4. Event Sourced Aggregate Current state of the Aggregate is always derived from the Event Store. Eg. Shopping Cart 5. Read & Write Separates Databases 103. 4/1/2019 103 Reactive Programming • BUILDING BLOCKS: OBSERVABLE, OBSERVER, SCHEDULER, OPERATOR • COMPARISON: ITERABLE (JAVA 6), STREAMS (JAVA 8), RX JAVA • CASE STUDY: MERGE STREAMS, FILTER, SORT, TAKE 104. 4/1/2019 104 Functional Reactive Programming: 4 Building Blocks of RxJava Source of Data Stream [ Sender ]Observable1 Listens for emitted values [ Receiver ]Observer2 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 105. 4/1/2019 105 Comparison : Iterable / Streams / Observable 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 Source Code: https://github.com/meta-magic/rxjava 106. 4/1/2019 106 Rx 2 Java Operator : Filter / Sort / FlatMap 4Building Block Objective: toSortedList() returns an Observable with a single List containing Fruits. Using FlatMap to Transform Observable to Observable Rx Example 2 SourceCodeGitHub:https://github.com/meta-magic/Rx-Java-2 • Merge • Filter • Sort • Take 107. Functional Reactive Programming Summary 4/1/2019 107 1. Observable Source of the Data Stream 2. Observer Listens to emitted values 3. Scheduler Are used to manage and control and concurrency. 4. Operators Operators that let you Transform, Combine, Manipulate, and work with the sequence of items emitted by Observables 108. 4/1/2019 108 UI DESIGN PATTERNS • TRADITIONAL PATTERNS: MVC, MVP, MVVM • FLUX DESIGN PATTERN • REDUX DESIGN PATTERNS 109. 4/1/2019 109 UI DesignPatterns MVC/ MVP/ MVVM 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. Model View Controller 1 * • 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 ViewModel Model Passes calls To Manipulates Updates Fire Events Model View ViewModel • 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. Model View Presenter View Presenter Model Passes calls To Fire Events Manipulates Updates1 1 110. 4/1/2019 110 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 111. 4/1/2019 111 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. 112. UI Design Pattern Summary 4/1/2019 112 1. MVC 2. MVP 3. MVVM 4. Flux 5. Redux Redux is a much better pattern if you are building complex enterprise applications. 113. 4/1/2019 113 Distributed Transactions • 2 PHASE COMMIT • SAGA DESIGN PATTERN • HANDLING INVARIANTS • FORWARD RECOVERY 114. Distributed Transactions : 2 Phase Commit 2 PC or not 2 PC, Wherefore Art Thou XA? 01April2019 114 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 pha |
|||
| Posted by : peter88 | Post date : 2020-01-06 15:59 | ||
| Category : Technology | Views : 433 | ||
Tags:
microservices architecture,
docker container,
microservices,
istio,
kubernetes,
microservices container
New Comment
