Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Microservices Architecture - Cloud Native Apps

129 views

Published on

Building Highly Scalable and Resilient Cloud-Native Apps.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Microservices Architecture - Cloud Native Apps

  1. 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. 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. 3. Architecture Styles/Patterns• LAYERED ARCHITECTURE • COMPONENT BASED ARCHITECTURE • SERVICE ORIENTED ARCHITECTURE • SERVICE BASED ARCHITECTURE • MICRO KERNEL BASED ARCHITECTURE • DOMAIN DRIVE DESIGN INTRO • EVENT SOURCING INTRO 1/11/2021 3 0
  4. 4. Layered Architecture UI Layer WS BL DL Database ShoppingCart Order Customer Inventory It was developed by John J. Donovan in Open Environment Corporation (OEC), a tools company he founded in Cambridge, Massachusetts. 3 Tier Architecture Pattern o All the 3 Layers are separated by network and data is transferred by Value. o You can upgrade a layer without worrying about impact on the other layer as long as contract between the layers are intact. o Logic Tier can be further divided into 1. Web Services Layer 2. Business Layer 3. Database Layer https://professordonovan.com/open-environment-corporation
  5. 5. Component Based Architecture 1. Logical Units: Breaking the App into well defined logical units. 2. Communication: Components communicate using a COM/DCOM, EJB, CORBA, RMI and other protocols or standard API contracts. 3. Reusability: A well defined component can be reused and self deployable unit. 4. Maintenance: Easy to change and upgrade the components without affecting the whole system 5. Ease of Development: With well defined API contracts, it’s easy to develop a component to do a specific task without impacting other parts of the system. 6. Ease of Deployment: It is easy to upgrade the existing version of the component with the latest version without impacting other parts of the system (Provided backward compatibility is maintained).
  6. 6. SOA – Service Oriented Architecture 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 Consumers 3rd Party Apps Smart Pipes Lot of Business logic resides in the Pipe Traditional Monolithic App with SOA Service properties 1. It logically represents a business activity with a specified outcome. 2. Each is self-contained. 3. Each Service is a Blackbox to the Service Consumer. 4. A Service can contain other Services too. 5. Service Can be re-used. For Ex Customer Service can be used by multiple Apps.
  7. 7. Service Based Architecture SOA and Microservices based on Service Based Architecture 1. Distributed Computing: Common thing in Service based architecture is distributed computing. 2. Communication: Services communicate using a Remote Access Protocol (SOAP, REST, RMI, JMS, Message Queues, AMQP (Advanced Message Queuing Protocol) 3. Service Contracts are based on XML, JSON, ProtoBuf etc. Contract versioning is key aspect of the contracts and its future evolution. 4. Availability and Responsiveness: Availability ensures that there are no single point of failures and Responsiveness to ensure that the Service Respond in a timely manner. 5. Security: As Services are independent components, it’s important that security and access controls are taken care off. JSON Web Token is a popular standard. 6. Transactions: Transaction management is a Big challenge in Service based Architecture. 2 Phase Commit or Saga Design Patterns are patterns focusing on addressing these challenges.
  8. 8. Micro Kernel Architecture Pattern The microkernel architecture pattern consists of two types of architecture components: 1. a core system and 2. plug-in modules. Application logic is divided between 1. independent plug-in modules 2. and the basic core system, providing 1. extensibility, 2. flexibility, and 3. isolation of application features 4. and custom processing logic Source: https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch03.html
  9. 9. DDD: Bounded Context – Strategic Design 11-01-2021 9 • 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. Domain Driven Design
  10. 10. DDD: App User’s Journey & Bounded Context 1/11/2021 10 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 Domain Driven Design
  11. 11. Domain Driven Design – Tactical Design 1/11/2021 11 Source: Domain-Driven Design Reference by Eric Evans
  12. 12. Event Sourcing Intro 1/11/2021 12 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
  13. 13. 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. 1/11/2021 13 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
  14. 14. Distributed Tx: SAGA Design Pattern instead of 2PC 1/11/2021 14 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
  15. 15. MICROSERVICES • CONCEPTS • WHEN SHOULD YOU USE MICROSERVICES? • WHAT’S THE RIGHT SIZE? • ARCHITECTURE (INFRATRUCTURE AND SOFTWRE) 1/11/2021 15 1
  16. 16. 16Source: https://cloud.google.com/kubernetes-engine/kubernetes-comic/
  17. 17. Pioneers in Microservices Implementation 11-01-2021 17 New Entrants
  18. 18. 18 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.
  19. 19. 19 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
  20. 20. Microservices definition 1/11/2021 20 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
  21. 21. Microservices Characteristics 21 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
  22. 22. When should I use them (Microservices)? 11-01-2021 22 • 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/
  23. 23. What is the right size for a Microservice? 11-01-2021 23 • 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.
  24. 24. Microservices Architecture / Design Patterns 11-01-2021 24 • 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
  25. 25. 25 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 Product 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 Order UI Layer Web Services Business Logic Database Layer Micro Service 2 ShoppingCart UI Layer WS BL DL Database ShoppingCart Order Customer Product 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
  26. 26. 26 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 Order UI Layer Web Services Business Logic Database Layer Micro Service 2 ShoppingCart API Gateway Load Balancer Circuit Breaker Service Discovery Load Balancer Circuit Breaker Load Balancer Circuit Breaker UI Layer Database ShoppingCart Order Customer Product 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
  27. 27. 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 11-01-2021 27
  28. 28. 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 28 Users Routing based on Layer 3,4 and 7
  29. 29. Shopping Portal – Docker / Kubernetes – Network Stack 29 /customer /product /review Load Balancer Ingress Deployment / Replica / Pod Nodes Kubernetes Objects Firewall Customer Pod Customer Pod Customer Pod Customer Service N1 N2 N2 EndPoints Product Pod Product Pod Product Pod Product Service N4 N3 MySQL DB EndPoints Review Pod Review Pod Review Pod Review Service N4 N3 N1 Service Call Kube DNS EndPoints Internal Load Balancers Users Routing based on Layer 3,4 and 7 Redis DB Mongo DB
  30. 30. Software Network Stack Vs Network Stack 1/11/2021 30 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 Istio 5 Config Server Spring Config SteelToe Secrets, Env - K8s Master Web Site https://netflix.github.io/ https://steeltoe.io/ https://kubernetes.io/ The Developer needs 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.
  31. 31. 31 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.
  32. 32. 32 Source:https://cloud.google.com/kubernetes-engine/kubernetes-comic/
  33. 33. 33Source: https://cloud.google.com/kubernetes-engine/kubernetes-comic/
  34. 34. 34 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/
  35. 35. Catalogues of Microservices 1/11/2021 35 System Z Model From Spotify • Different types of Components Z Supports • Libraries • Data Pipelines • Views in the client • Data Store • Service
  36. 36. 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-01-2021 36 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
  37. 37. Monolithic > Microservices • FORRESTER RESEARCH • MODERNIZATION JOURNEY • ASSESS AND CLASSIFY YOUR APP PORTFOLIO • PLAN AND PRIORITIZE 1/11/2021 37
  38. 38. Conway’s Law 1/11/2021 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 38 Any Organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
  39. 39. * 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) 3911-01-2021
  40. 40. Scale Cube and Micro Services 1/11/2021 40 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
  41. 41. Modernization Journey 1/11/2021 41  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
  42. 42. Assess and Classify your App Portfolio 1/11/2021 42  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
  43. 43. Plan and Prioritize 1/11/2021 43 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
  44. 44. Monolithic to Microservices Summary 1/11/2021 44 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
  45. 45. Containers & Kubernetes • DOCKER CONTAINERS • KUBERNETES – CONTAINER ORCHESTRATION • ISTIO – TRAFFIC MANAGEMENT / NETWORK POLICIES 1/11/2021 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 45
  46. 46. 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 Hypervisor11-01-2021 46
  47. 47. 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 47 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/resource_management_guide/ch01 11-01-2021
  48. 48. Linux Kernel 48 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
  49. 49. 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 .. 11-01-2021 49 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
  50. 50. Kubernetes Key Concepts 1/11/2021 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 50 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
  51. 51. 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 11-01-2021 51
  52. 52. 52 Container 1 172.17.3.2 Web Server 8080 Veth: eth0 Container 2 172.17.3.3 Microservice 9002 Veth: eth0 Container 3 172.17.3.4 Microservice 9003 Veth: eth0 Container 4 172.17.3.5 Microservice 9004 Veth: eth0 IP tables rules eth0 10.130.1.101/24 Node 1 Docker0 Bridge 172.17.3.1/16 Veth0 Veth1 Veth2 Veth3 Container 1 172.17.3.2 Web Server 8080 Veth: eth0 Container 2 172.17.3.3 Microservice 9002 Veth: eth0 Container 3 172.17.3.4 Microservice 9003 Veth: eth0 Container 4 172.17.3.5 Microservice 9004 Veth: eth0 IP tables rules eth0 10.130.1.102/24 Node 2 Docker0 Bridge 172.17.3.1/16 Veth0 Veth1 Veth2 Veth3 Docker Networking Vs. Kubernetes Networking Pod 1 172.17.3.2 Web Server 8080 Veth: eth0 Pod 2 172.17.3.3 Microservice 9002 Veth: eth0 Pod 3 172.17.3.4 Microservice 9003 Veth: eth0 Pod 4 172.17.3.5 Microservice 9004 Veth: eth0 IP tables rules eth0 10.130.1.101/24 Node 1 L2 Bridge 172.17.3.1/16 Veth0 Veth1 Veth2 Veth3 Same IP Range. NAT Required Uniq IP Range. netFilter, IP Tables / IPVS. No NAT required 5 Pod 1 172.17.3.6 Web Server 8080 Veth: eth0 Pod 2 172.17.3.7 Microservice 9002 Veth: eth0 Pod 3 172.17.3.8 Microservice 9003 Veth: eth0 Pod 4 172.17.3.9 Microservice 9004 Veth: eth0 IP tables rules eth0 10.130.1.102/24 Node 2 L2 Bridge 172.17.3.1/16 Veth0 Veth1 Veth2 Veth3
  53. 53. Kubernetes Networking 3 Networks 53Source: https://github.com/meta-magic/kubernetes_workshop eth0 10.130.1.102/24 Node 1 veth0 eth0 Pod 1 Container 1 172.17.4.1 eth0 Pod 2 Container 1 172.17.4.2 veth1 eth0 10.130.1.103/24 Node 2 veth1 eth0 Pod 1 Container 1 172.17.5.1 eth0 10.130.1.104/24 Node 3 veth1 eth0 Pod 1 Container 1 172.17.6.1 Service EP EP EP VIP 192.168.1.2/16 1. Physical Network 2. Pod Network 3. Service Network End Points handles dynamic IP Addresses of the Pods selected by a Service based on Pod Labels Virtual IP doesn’t have any physical network card or system attached. 6 Virtual Network - L2 / L3 /Overlay / Cloud
  54. 54. Service Mesh – Sidecar Design Pattern 11-01-2021 54 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
  55. 55. 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 55 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
  56. 56. 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 56 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
  57. 57. 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 57 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
  58. 58. 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 58 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
  59. 59. 59 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 59 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
  60. 60. K8s Network Policies L3/L4 60 Kubernetes blocks the Product UI to access Database or Product Review directly. You can create Network policies across name spaces, services etc., for both incoming (Ingress) and outgoing (Egress) traffic. Product UI Pod Product UI Pod Product UI Pod Product Pod Product Pod Product Pod Review Pod Review Pod Review Pod MySQL Pod Mongo Pod Order UI Pod Order UI Pod Order UI Pod Order Pod Order Pod Order Pod Oracle Pod 7 Blocks Access Blocks Access
  61. 61. Network Security Policy for Microservices 11-01-2021 61 Product Review Microservice Product Microservice 172.27.1.2 L3 / L4 L7 – API GET /live GET /ready GET /reviews/{id} POST /reviews PUT /reviews/{id} DELETE /reviews/{id} GET /reviews/192351 Product review can be accessed ONLY by Product. IP Tables enforces this rule. Exposed Exposed Exposed Exposed Exposed All other method calls are also exposed to Product Microservice. iptables –s 172.27.1.2 -p tcp –dport 80 -j accept 7
  62. 62. Network Security Policy for Microservices 11-01-2021 62 Product Review Microservice Product MicroserviceL3 / L4 L7 – API GET /live GET /ready GET /reviews/{id} POST /reviews PUT /reviews/{id} DELETE /reviews/{id} GET /reviews/192351 Rules are implemented by BPF (Berkeley Packet Filter) at Linux Kernel level. From Product Microservice only GET /reviews/{id} allowed. BPF / XDP performance is much superior to IPVS. Except GET /reviews All other calls are blocked for Product Microservice 7
  63. 63. BPF / XDP (eXpress Data Path) 11-01-2021 63 Network Driver Software StackNetwork Card BPF Regular BPF (Berkeley Packet Filter) mode Network Driver Software StackNetwork Card BPF XDP allows BPF program to run inside the network driver with access to DMA buffer. Berkeley Packet Filters (BPF) provide a powerful tool for intrusion detection analysis. Use BPF filtering to quickly reduce large packet captures to a reduced set of results by filtering based on a specific type of traffic. Source: https://www.ibm.com/support/knowledgecenter/en/SS42VS_7.3.2/com.ibm.qradar.doc/c_forensics_bpf.html 7
  64. 64. XDP (eXpress Data Path) 11-01-2021 64 BPF Program can drop millions packet per second when there is DDoS attack.Network Driver Software StackNetwork Card BPF Drop Stack Network Driver Software StackNetwork Card BPF Drop Stack LB & Tx BPF can perform Load Balancing and transmit out the data to wire again. Source: http://www.brendangregg.com/ebpf.html 7
  65. 65. Kubernetes Container Network Interface 65 Container Runtime Container Network Interface Weave Calico Romana Cilium Flannel Layer 3 BGP BGP Route Reflector Network Policies IP Tables Stores data in Etcd Project Calico Layer 3 VXLAN (No Encryption) IPSec Overlay Network Host-GW (L2) Stores data in Etcd https://coreos.com/ Layer 3 IPSec Network Policies Multi Cloud NW Stores data in Etcd https://www.weave.works/ Layer 3 L3 + BGP & L2 +VXLAN IPSec Network Policies IP Tables Stores data in Etcd https://romana.io/ Layer 3 / 7 BPF / XDP L7 Filtering using BPF Network Policies L2 VXLAN API Aware (HTTP, gRPC, Kafka, Cassandra… ) Multi Cluster Support https://cilium.io/ BPF (Berkeley Packet Filter) – Runs inside the Linux KernelOn-Premise Ingress Load Balancer Mostly Mostly Yes Yes Yes 7
  66. 66. Container & Kubernetes Summary 1/11/2021 66 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.
  67. 67. Kafka • CONCEPTS : QUEUES / PUB – SUB / EVENT STREAMING • WHY IS IT DIFFERENT FROM TRADITIONAL MESSAGE QUEUES? • DATA STORAGE / CLUSTER / DURABILITY • PERFORMANCE 1/11/2021 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 67
  68. 68. Kafka Core Concepts 11-01-2021 68 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.
  69. 69. Traditional Queue / Pub-Sub Vs. Kafka 11-01-2021 69 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.
  70. 70. Anatomy of a Topic 11-01-2021 70 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.
  71. 71. 11-01-2021 71 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
  72. 72. 11-01-2021 72 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".
  73. 73. 11-01-2021 73 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
  74. 74. 11-01-2021 74 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.
  75. 75. LinkedIn Kafka Cluster 11-01-2021 75 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.
  76. 76. Uber Kafka Cluster 11-01-2021 76 Topics10K+ Events / Second11M Petabytes of Data1PB+
  77. 77. Kafka Summary 1/11/2021 77 1. Combined Best of Queues and Pub / Sub Model. 2. Data Durability 3. Fastest Messaging Infrastructure 4. Streaming capabilities 5. Replication
  78. 78. 1/11/2021 78 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
  79. 79. 1/11/2021 79 Infrastructure Design Patterns • API GATEWAY • LOAD BALANCER • SERVICE DISCOVERY • CIRCUIT BREAKER • SERVICE AGGREGATOR • LET-IT CRASH PATTERN
  80. 80. API Gateway Design Pattern – Software Stack UILayer WS BL DL Database Shopping Cart Order Customer Product Firewall Users API Gateway LoadBalancer CircuitBreaker UILayer WebServices BusinessLogic DatabaseLayer Product SE MySQL DB Product Microservice With 4 node cluster LoadBalancer CircuitBreaker UILayer WebServices BusinessLogic DatabaseLayer Customer Redis DB 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)
  81. 81. API Gateway – Kubernetes Implementation /customer /product /cart /order API Gateway Ingress Deployment / Replica / Pod NodesKubernetes Objects Firewall Customer Pod Customer Pod Customer Pod Customer Service N1 N2 N2 EndPoints Product Pod Product Pod Product Pod Product Service N4 N3 MySQL DB EndPoints Review Pod Review Pod Review Pod Review Service N4 N3 N1 Service Call Kube DNS EndPoints Internal Load Balancers Users Routing based on Layer 3,4 and 7 Redis DB Mongo DB Load Balancer
  82. 82. 82 API Gateway – Kubernetes / Istio /customer /product /auth /order API Gateway Virtual Service Deployment / Replica / Pod NodesIstio Sidecar - Envoy Load Balancer Firewall P M CIstio Control Plane MySQL Pod N4 N3 Destination Rule Product Pod Product Pod Product Pod Product Service Service Call Kube DNS EndPoints Internal Load Balancers 82 Kubernetes Objects Istio Objects Users Review Pod Review Pod Review Pod Review Service N1 N4 N3EndPoints Customer Pod Customer Pod Customer Pod Customer Service N1 N2 N2 Destination Rule EndPoints Redis DB Mongo DB
  83. 83. Load Balancer Design Pattern Firewall Users API Gateway Load Balancer CircuitBreaker UILayer WebServices BusinessLogic DatabaseLayer Product SE MySQL DB Product Microservice With 4 node cluster Load Balancer CB=Hystrix UILayer WebServices BusinessLogic DatabaseLayer Customer Redis DB 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
  84. 84. Ingress Load Balancer – Kubernetes Model Kubernetes Objects Firewall Users Product 1 Product 2 Product 3 Product Service N4 N3 N1 EndPoints Internal Load Balancers DB Load Balancer API Gateway N1 N2 N2Customer 1 Customer 2 Customer 3 Customer Service EndPoints DB Internal Load Balancers Pods Nodes • Load Balancer receives the (request) packet from the User and it picks up a Virtual Machine in the Cluster to do the internal Load Balancing. • Kube Proxy using IP Tables redirect the Packet using internal load Balancing rules. • Packet enters Kubernetes Cluster and reaches Node (of that specific Pod) and Node handover the packet to the Pod. /customer /product /cart
  85. 85. Service Discovery – NetFlix Network Stack Model Firewall Users API Gateway LoadBalancer CircuitBreaker Product MySQL DB Product Microservice With 4 node cluster LoadBalancer CircuitBreaker UILayer WebServices BusinessLogic DatabaseLayer Customer Redis DB 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
  86. 86. Ingress Service Discovery – Kubernetes Model Kubernetes Objects Firewall Users Product 1 Product 2 Product 3 Product Service N4 N3 N1 EndPoints Internal Load Balancers DB API Gateway N1 N2 N2Customer 1 Customer 2 Customer 3 Customer 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 (Customer / Product etc.) • Services handles the dynamic IP Addresses of the pods. Services Endpoints will automatically discover the new Pods based on Labels. Service Definition from Kubernetes Perspective /customer /product /cart Service Call Kube DNS
  87. 87. Circuit Breaker Pattern 87 /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 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
  88. 88. Service Aggregator Pattern /newservice Reverse Proxy Server Ingress Deployment / Replica / Pod Nodes Kubernetes Objects Firewall Service Call Kube DNS 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 / NBA) 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
  89. 89. Music UI 1/11/2021 89 Play Count Discography Albums
  90. 90. Service Aggregator Pattern 90 /artist Reverse Proxy Server Ingress Deployment / Replica / Pod Nodes Kubernetes Objects Firewall Service Call Kube DNS 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
  91. 91. Config Store – Spring Config Server Firewall Users API Gateway LoadBalancer CircuitBreaker Product MySQL DB Product Microservice With 4 node cluster LoadBalancer CircuitBreaker UILayer WebServices BusinessLogic DatabaseLayer Customer Redis DB Customer Microservice With 2 node cluster • In this model Developers write the code in every Microservice to download the required configuration from a Central server (Ex. Spring Config Server for the Java World). • This creates an explicit dependency order in which service to come up will be critical. Config Server
  92. 92. Let-it-Crash Design Pattern – Erlang Philosophy 1/11/2021 92 • 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.
  93. 93. Let-it-Crash Design Pattern 1/11/2021 93 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.
  94. 94. Let-it-Crash : Comparison Erlang Vs. Microservices Vs. Monolithic Apps 94 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.
  95. 95. Infrastructure Design Patterns Summary 1/11/2021 95 1. API Gateway 2. Service Discovery 3. Load Balancer 4. Circuit Breaker 5. Service Aggregator Pattern 6. Let It Crash Pattern
  96. 96. CAPABILITY CENTRIC DESIGN • BUSINESS FUNCTIONS • BUSINESS PROCESS • TEAM STRUCTURE 1/11/2021 96
  97. 97. Business Solution & Business Process 1/11/2021 97  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
  98. 98. 1/11/2021 98 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
  99. 99. 99 From Project Based Activity Oriented To Product Based Outcome Oriented Source: Sriram Narayan– https://martinfowler.com/bliki/BusinessCapabilityCentric.html
  100. 100. Capability Centric Design Summary 1/11/2021 100 1. Business Solutions 2. Business Process 3. Business Capabilities 4. Business Driven Teams (From Specs to Ops) 5. Outcome Oriented instead of Activity Oriented.
  101. 101. 1/11/2021 (C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA 101 Software Design Patterns • DOMAIN DRIVEN DESIGN • EVENT SOURCING AND CQRS • FUNCTIONAL REACTIVE PROGRAMMING • DISTRIBUTED TRANSACTIONS • REDUX UI PATTERN • CASE STUDY
  102. 102. 1/11/2021 102 Domain Driven Design • STRATEGIC: BOUNDED CONTEXT, UBIQUITOUS LANGUAGE • TACTICAL DESIGN: ENTITIES, AGGREGATE ROOT, VALUE OBJECT, FACTORIES, REPOSITORY, EVENTS, SERVICES • CASE STUDY: SHOPPING PORTAL
  103. 103. DDD: Bounded Context – Strategic Design 11-01-2021 103 • 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.
  104. 104. DDD: App User’s Journey & Bounded Context 1/11/2021 104 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
  105. 105. 1/11/2021 105 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
  106. 106. 11-01-2021 106 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
  107. 107. Layered Architecture 11-01-2021 107 • 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
  108. 108. 1/11/2021 108 Domain Driven Design – Tactical Design Source: Domain-Driven Design Reference by Eric Evans
  109. 109. DDD: Understanding Aggregate Root 109 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, USA11-01-2021
  110. 110. DDD: Domain Events & Integration Events 11-01-2021 110 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
  111. 111. 1/11/2021 111 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)
  112. 112. 1/11/2021 112 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
  113. 113. Procedural Design Vs. Domain Driven Design 113 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
  114. 114. Polymorphic Business Logic inside a Domain object 11-01-2021 114 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
  115. 115. Type Specific Computation in a Sub Class 115 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
  116. 116. Object Construction : Procedural Way Vs. Builder Pattern 116 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
  117. 117. Domain Driven Design Summary 1/11/2021 117 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
  118. 118. 1/11/2021 118 Event Storming • EVENT SOURCING / CQRS • CASE STUDY: SHOPPING PORTAL • CASE STUDY: RESTAURANT APP • CASE STUDY: MOVIE BOOKING • CASE STUDY: MOVIE STREAMING
  119. 119. Mind Shift : From Object Modeling to Process Modeling 1/11/2021 119 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
  120. 120. 120 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
  121. 121. 1/11/2021 121 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
  122. 122. 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. 1/11/2021 122 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
  123. 123. 1/11/2021 123 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
  124. 124. Case Study: Shopping Site – Event Sourcing / CQRS 1/11/2021 124 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. 2 3 ESA 4
  125. 125. Case Study: Movie Booking – Event Sourcing / CQRS 1/11/2021 125 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.
  126. 126. Case Study: Movie Streaming – Event Sourcing / CQRS 1/11/2021 126 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
  127. 127. Event Sourcing & CQRS Summary 1/11/2021 127 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
  128. 128. 1/11/2021 128 Reactive Programming • BUILDING BLOCKS: OBSERVABLE, OBSERVER, SCHEDULER, OPERATOR • COMPARISON: ITERABLE (JAVA 6), STREAMS (JAVA 8), RX JAVA • CASE STUDY: MERGE STREAMS, FILTER, SORT, TAKE
  129. 129. 1/11/2021 129 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
  130. 130. 1/11/2021 130 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
  131. 131. 131 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 <List> to Observable <Fruit> Rx Example 2 SourceCodeGitHub:https://github.com/meta-magic/Rx-Java-2 • Merge • Filter • Sort • Take
  132. 132. Functional Reactive Programming Summary 1/11/2021 132 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
  133. 133. 1/11/2021 133 UI DESIGN PATTERNS • TRADITIONAL PATTERNS: MVC, MVP, MVVM • FLUX DESIGN PATTERN • REDUX DESIGN PATTERNS
  134. 134. 1/11/2021 134 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
  135. 135. 1/11/2021 135 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
  136. 136. 1/11/2021 136 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.
  137. 137. UI Design Pattern Summary 1/11/2021 137 1. MVC 2. MVP 3. MVVM 4. Flux 5. Redux Redux is a much better pattern if you are building complex enterprise applications.
  138. 138. 1/11/2021 138 Distributed Transactions • 2 PHASE COMMIT • SAGA DESIGN PATTERN • HANDLING INVARIANTS • FORWARD RECOVERY
  139. 139. Distributed Transactions : 2 Phase Commit 2 PC or not 2 PC, Wherefore Art Thou XA? 11January2021 139 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
  140. 140. 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. 140 Source: http://www.infoq.com/articles/ebay-scalability-best-practices
  141. 141. 1/11/2021 141 Distributed Tx: SAGA Design Pattern instead of 2PC 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
  142. 142. SAGA Design Pattern Features 1/11/2021 142 1. Backward Recovery (Rollback) T1 T2 T3 T4 C3 C2 C1 Order Processing, Banking Transactions, Ticket Booking Examples Updating individual scores in a Team Game. 2. Forward Recovery with Save Points T1 (sp) T2 (sp) T3 (sp) • To recover from Hardware Failures, SAGA needs to be persistent. • Save Points are available for both Forward and Backward Recovery. Type Source: SAGAS (1987) Hector Garcia Molina / Kenneth Salem, Dept. of Computer Science, Princeton University, NJ, USA
  143. 143. Handling Invariants – Monolithic to Micro Services 1/11/2021 143 In a typical Monolithic App Customer Credit Limit info and the order processing is part of the same App. Following is a typical pseudo code. Order CreatedT1 Order Microservice Credit ReservedT2 Customer Microservice In Micro Services world with Event Sourcing, it’s a distributed environment. The order is cancelled if the Credit is NOT available. If the Payment Processing is failed then the Credit Reserved is cancelled. Payment MicroservicePayment ProcessedT3 Order Cancelled due to credit unavailability / payment failureC1 Credit Cancelled due to payment failureC2 Begin Transaction If Order Value <= Available Credit Process Order Process Payments End Transaction Monolithic 2 Phase Commit https://en.wikipedia.org/wiki/Invariant_(computer_science)
  144. 144. 1/11/2021 144 Use Case : Restaurant – Forward Recovery Domain The example focuses on the concept of a Restaurant which tracks the visit of an individual or group to the Restaurant. 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. PaymentBillingDining Source: http://cqrs.nu/tutorial/cs/01-design Soda Cancelled Table Opened Juice Ordered Soda Ordered Appetizer Ordered Soup Ordered Food Ordered Juice Served Food Prepared Food Served Appetizer Served Table Closed Aggregate Root : Dinning Order Billed OrderT1 Payment CCT2 Payment CashT3 T1 (sp) T2 (sp) T3 (sp) Event Stream Aggregate Root : Food Bill Transaction doesn't rollback if one payment method is failed. It moves forward to the NEXT one. sp Network ErrorC1 sp
  145. 145. Distributed Transaction Summary 1/11/2021 145 1. 2 Phase Commit Doesn’t scale well in cloud environment 2. SAGA Design Pattern Raise compensating events when the local transaction fails. 3. SAGA Supports Rollbacks & Roll Forwards Critical pattern to address distributed transactions.
  146. 146. 1/11/2021 146 RESTful APIs • STANDARDS • API VERSIONING STANDARDS
  147. 147. 1/11/2021 147 RESTful Guidelines 1. Endpoints as nouns, NOT verbs Ex. /catalogues /orders /catalogues/products and NOT /getProducts/ /updateProducts/ 2. Use plurals Ex. /catalogues/{catalogueId} and NOT /catalogue/{catalogueId} 3. Documenting 4. Paging 5. Use SSL 6. HTTP Methods GET / POST / PUT / DELETE / OPTIONS / HEAD 7. HTTP Status Codes (Effective usage) 8. Versioning Media Type Version GET /account/5555 HTTP/1.1 Accept: application/vnd.catalogues.v1+json URL path version https://domain/v1/catalogues/products
  148. 148. 1/11/2021 148 RESTful Guidelines – Query Examples Search All Products Search Products By Catalogue ID Search Products By Catalogue ID & Product ID
  149. 149. 1/11/2021 149 RESTful Guidelines – Query Examples Two different implementation of same query
  150. 150. 1/11/2021 150 # 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
  151. 151. Functional Reactive Programming Summary 1/11/2021 151 1. 2 Phase Doesn’t scale well in cloud environment 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
  152. 152. 1/11/2021 152 Testing & Security • TESTING STRATEGIES • DOCKER SECURITY PRACTICES • KUBERNETES SECURITY PRACTICES 3
  153. 153. 1/11/2021 153 Testing Strategies • UNIT TESTING • COMPONENT TESTING • INTEGRATION CONTRACT TESTING • INTEGRATION TESTING
  154. 154. 1/11/2021 154 Microservices Testing Strategies 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 Mike Cohen’s Testing Pyramid Test Pyramid: https://martinfowler.com/bliki/TestPyramid.html 70% 20% 10%
  155. 155. 1/11/2021 155 Microservices Testing Strategy 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 Say NO to End 2 End Tests - Mike Walker April 22, 2015. Google Test Blog
  156. 156. 1/11/2021 156 Testing ToolsMicroservices Testing Scenarios / Tools 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. Order Payment Unit Testing Firewall Integration Testing Scope REST / HTTP Payment Sandbox Component Testing
  157. 157. Behavior Driven Development 11-01-2021 157 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.
  158. 158. Features of BDD 11-01-2021 158 • 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.
  159. 159. Testing Strategy Summary 1/11/2021 159 1. Unit Testing A unit test exercises the smallest piece of testable software. 2. Component Testing A component test limits the scope of the exercised software to a portion of the system under test. 3. Contract Testing It is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service 4. Integration Testing It verifies the communication paths and interactions between components to detect interface defects.
  160. 160. 1/11/2021 160 Security Best Practices • DOCKER • KUBERNETES
  161. 161. 1/11/2021 161 Build Small Container Images • Simple Java Web Apps with Ubuntu & Tomcat can have a size of 700 MB • Use Alpine Image as your base Linux OS • Alpine images are 10x smaller than base Ubuntu images • Smaller Image size reduce the Container vulnerabilities. • Ensure that only Runtime Environments are there in your container. For Example your Alpine + Java + Tomcat image should contain only the JRE and NOT JDK. • Log the App output to Container Std out and Std error. 1
  162. 162. 1/11/2021 162 Docker: To Root or Not to Root! • Create Multiple layers of Images • Create a User account • Add Runtime software’s based on the User Account. • Run the App under the user account • This gives added security to the container. • Add Security module SELinux or AppArmour to increase the security, Alpine JRE 8 Tomcat 8 My App 1 2
  163. 163. 1/11/2021 163 Docker: Container Security 1. Secure your HOST OS! Containers runs on Host Kernel. 2. No Runtime software downloads inside the container. Declare the software requirements at the build time itself. 3. Download Docker base images from Authentic site. 4. Limit the resource utilization using Container orchestrators like Kubernetes. 5. Don’t run anything on Super privileged mode. 3
  164. 164. 1/11/2021 164 Kubernetes: Naked Pods • Never use a Naked Pod, that is Pod without any ReplicaSet or Deployments. Naked pods will never get re-scheduled if the Pod goes down. • Never access a Pod directly from another Pod. Always use a Service to access a Pod. • User labels to select the pods { app: myapp, tier: frontend, phase: test, deployment: v3 }. • Never use :latest tag in the image in the production scenario. 4
  165. 165. 1/11/2021 165 Kubernetes: Namespace default Kube system Kube public Kubernetes Cluster• Group your Services / Pods / Traffic Rules based on Specific Namespace. • This helps you apply specific Network Policies for that Namespace with increase in Security and Performance. • Handle specific Resource Allocations for a Namespace. • If you have more than a dozen Microservices then it’s time to bring in Namespaces. Service-Name.Namespace.svc.cluster.local $ kubectl config set-context $(kubectl config current-context) --namespace=your-ns The above command will let you switch the namespace to your namespace (your-ns). 5
  166. 166. 1/11/2021 166 Kubernetes: Pod Health Check • Pod Health check is critical to increase the overall resiliency of the network. • Readiness • Liveness • Ensure that all your Pods have Readiness and Liveness Probes. • Choose the Protocol wisely (HTTP, Command & TCP) 6
  167. 167. 1/11/2021 167 Kubernetes: Resource Utilization • For the Best Quality define the requests and limits for your Pods. • You can set specific resource requests for a Dev Namespace to ensure that developers don’t create pods with a very large resource or a very small resource. • Limit Range can be set to ensure that containers were create with too low resource or too large resource. 7
  168. 168. 1/11/2021 168 Kubernetes: Pod Termination Lifecycle • Make sure that the Application to Handle SIGTERM message. • You can use preStop Hook • Set the terminationGracePeriodSeconds: 60 • Ensure that you clean up the connections or any other artefacts and ready for clean shutdown of the App (Microservice). • If the Container is still running after the grace period, Kubernetes sends a SIGKILL event to shutdown the Pod. 8
  169. 169. 1/11/2021 169 Kubernetes: External Services • There are systems that can be outside the Kubernetes cluster like • Databases or • external services in the cloud. • You can create an Endpoint with Specific IP Address and Port with the same name as Service. • You can create a Service with an External Name (URL) which does a CNAME redirection at the Kernel level. 9
  170. 170. 1/11/2021 170 Kubernetes: Upgrade Cluster • Make sure that the Master behind a Load Balancer. • Upgrade Master • Scale up the Node with an extra Node • Drain the Node and • Upgrade Node • Cluster will be running even if the master is not working. Only Kubectl and any master specific functions will be down until the master is up. 10
  171. 171. 171 OPS • AGILE: KANBAN • ITSM / DEVOPS • SRE 4
  172. 172. 1/11/2021 172 Kanban • BOARDS AND CARDS • KANBAN VS SCRUM • BENEFITS OF KANBAN
  173. 173. 1/11/2021 173 What is Kanban Kanban is a method for managing the creation of products with an emphasis on • continual delivery while • not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively. Kanban is a visual management method that was developed by Hirotaka Takeuchi and Ikujiro Nonaka

×