@arafkarsh arafkarsh Architecting & Building Apps a tech presentorial Combination of presentation & tutorial ARAF KARSH HAMID Co-Founder / CTO MetaMagic Global Inc., NJ, USA @arafkarsh arafkarsh AI / ML Generative AI LLMs, RAG 6+ Years Microservices Blockchain 8 Years Cloud Computing 8 Years Network & Security 8 Years Distributed Computing 1 Cloud-Native Architecture Microservices Monolithic / Legacy Migration Case studies: 7 Business, 9 NFRs Containers / Kubernetes Infrastructure Design Patterns Intro to the 15-Part Series To Build Cloud Native Apps Composable Enterprise Architecture

@arafkarsh arafkarsh 2 Source: https://arafkarsh.medium.com/embracing-cloud-native-a-roadmap-to-innovation-a6b06fe3a9fb Cloud-Native Architecture

@arafkarsh arafkarsh 3 Source: https://arafkarsh.medium.com/embracing-cloud-native-a-roadmap-to-innovation-a6b06fe3a9fb

@arafkarsh arafkarsh 4 My Primary Area of work Cloud-Native Architecture DDD, Event-Driven, Microservices, BDD, Containers, Kubernetes, Service Mesh, DevOps, Data Mesh 1 Blockchain HyperLedger Ethereum CBDC / Tokens / NFT 2 App Security OWASP, Secure SDLC DevSecOps Zero Trust 3 Generative AI LLM, RAG GPT 4o, Gemini, Llama3, Claude 3, PalM2, Gemma, Phi3, Falcon 2, Mistral 4

@arafkarsh arafkarsh 5 Slides are color coded based on the topic colors. Microservices Architecture Cloud-Native Architecture Case Studies 1 Monolithic to Microservices Migration Migration Design Patterns 2 Containers & Kubernetes Service Mesh 3 Infrastructure Design Patterns API Gateway, Service Discovery, Load Balancer, Service Aggregator 4

@arafkarsh arafkarsh 0 Code Setup o SpringBoot 2.7.2 (MVC) / SpringBoot 3.1.0 (WebFlux) o Java 8 for Compile and Java 17 to run o H2 DB or PostgreSQL database 6

@arafkarsh arafkarsh Package Structure 7 Source: https://github.com/arafkarsh Threads / Rx Java 2: https://github.com/arafkarsh/fusion-sky-threads-rx-java Spring WebFlux Reactive Programming: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc Spring MVC & Security: https://github.com/arafkarsh/ms-springboot-272-vanilla

@arafkarsh arafkarsh Github Codebase 8 Source: https://github.com/arafkarsh/ms-quickstart Springboot Examples 1. Kafka 2. Kafka Connect 3. Kafka Stream 4. OWASP Top Vulnerabilities & Fixes 5. Kubernetes 6. Test Automation 7. WebFlux Reactive Programming 8. Gen AI Examples

@arafkarsh arafkarsh Pioneers in Microservices Implementation 9 New Entrants

@arafkarsh arafkarsh 10 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.

@arafkarsh arafkarsh 11 50M Paid Subscribers 100M Active Users 60 Countries Cross Functional Team Full, End to End ownership of features Autonomous 1000+ Microservices Source: https://microcph.dk/media/1024/conference-microcph-2017.pdf 1000+ Tech Employees 120+ Teams

@arafkarsh arafkarsh Cloud-Native Architecture Adoption on the rise 12 Source: ComputerWeekly.com – Mar 18, 2022: https://www.computerweekly.com/news/252518356/Adoption-of-cloud-native-architectures-on-the-rise Research from SlashData (2022) for the Cloud Native Computing Forum (CNCF) has found that the global number of cloud-native developers has grown by one million in the past 12 months to reach 7.1 million. 1.0 7.1 Source: Microsoft – https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/definition With Agile / Scrum / Sprint (2-4 Weeks) and CI/CD pipelines: How do Companies like NetFlix, Uber, and WeChat do 100+ releases per day? Various Cloud Trends: https://www.dbta.com/Editorial/News-Flashes/IT-Experts-Offer-Cloud-Predictions-for-2024-161765.aspx

@arafkarsh arafkarsh MICROSERVICES Cloud-Native Architecture o Concepts o When should you use microservices? o What’s the right size? o Architecture Patterns (Infrastructure & Software) 13 1

@arafkarsh arafkarsh Agile Scrum (4-6 Weeks) Developer Journey Monolithic Domain Driven Design Event Sourcing and CQRS Waterfall Optional Design Patterns Continuous Integration (CI) 6/12 Months Enterprise Service Bus Relational Database [SQL] / NoSQL Development QA / QC Ops 14 Microservices Domain Driven Design Event Sourcing and CQRS Scrum / Kanban (1-5 Days) Mandatory Design Patterns Infrastructure Design Patterns CI DevOps Event Streaming / Replicated Logs SQL NoSQL CD Container Orchestrator Service Mesh

@arafkarsh arafkarsh 15 Microservices Technology Landscape 1999 Commercial Virtual Machine 2003 VM Monitor Hypervisor 2004 Architecture Pattern Domain Driven Design 2006 Cloud Services Amazon AWS 2013 Containers Docker 2014 Container Orchestrator Kubernetes 2005 Architecture Pattern Event Sourcing & CQRS 1995s 2020s 2000s Cloud Native Apps Infrastructure Evolution 1. Virtual Machines 2. Containers 3. Kubernetes (Orchestrator) 4. Istio (Service Mesh) 5. Kafka (Messaging) Architecture Patterns 1. API Gateways / LB 2. Service Discovery 3. Event Driven 4. Service Mesh 5. Domain Driven Design 6. Event Sourcing & CQRS 7. Reactive Programming 8. Distributed Tx 2015 Service Mesh Istio 2011 Messaging Kafka 1998 Architecture Style 3 Tier Architecture 2003 Architecture Style SOA 2020 Service Mesh Open Service Mesh 2007 Linux Kernel cgroups 2008 Cloud Services Google Cloud 2010s 2010 Cloud Services Microsoft Azure 2011 Hybrid Cloud Services RedHat OpenShift 1999 Software Process XP (Agile) 1987 Design Pattern Saga Pattern 2005s 2015s 2004 Software Process Kanban 1985s 2010 Cloud Services OpenStack 2009 PaaS Services Cloud Foundry

@arafkarsh arafkarsh Management Pipeline Automation Architecture SpecOps Workflow - SDLC 16 Green Field Brown Field Domain Driven Design Event Sourcing / CQRS Migration Patterns Strangler Fig, CDC… Build Design Develop Test Stage Ops Cloud • Fault Tolerance • Reliability • Scalability • Traffic Routing • Security • Policies • Observability • Unit Testing • Component • Integration • Contract • Package Repositories • Mvn, npm, docker hub • Infrastructure • Containers • Orchestration • Serverless • Traffic Routing • Security (mTLS, JWT) • Policies (Network / Security • Observability Infra Code • Feature Code • Configs Source Code Specs

@arafkarsh arafkarsh Application Modernization – 3 Transformations 17 Monolithic SOA Microservice Physical Server Virtual Machine Cloud Waterfall Agile DevOps Source: IBM: Application Modernization > https://www.youtube.com/watch?v=RJ3UQSxwGFY Architecture Infrastructure Delivery

@arafkarsh arafkarsh Application Modernization – 3 Transformations 18 Monolithic SOA Microservice Physical Server Virtual Machine Cloud Waterfall Agile DevOps Source: IBM: Application Modernization > https://www.youtube.com/watch?v=RJ3UQSxwGFY Architecture Infrastructure Delivery Modernization 1 2 3

@arafkarsh arafkarsh Modernization Journey towards Cloud Native Apps 19 Source: Page 16 US DoD Enterprise DevSecOps 2.0 Fundamentals

@arafkarsh arafkarsh Modernization Journey towards Cloud Native Apps 20 Source: Page 16 US DoD Enterprise DevSecOps 2.0 Fundamentals

@arafkarsh arafkarsh Cloud-Native Architecture 21 The Cloud Native Computing Foundation provides the official definition: Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. Source: https://www.cncf.io/ Amazon – What is Cloud Native App Development? Google – What is Cloud Native? Microsoft – What is Cloud Native? Source: https://github.com/cncf/toc/ blob/main/DEFINITION.md Oracle – What is Cloud Native? IBM – What is Cloud Native? IEEE – Cloud Native Architecture

@arafkarsh arafkarsh Microservices definition 22 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

@arafkarsh arafkarsh Cloud Native Architecture 23 Components via Services Organized around Business Capabilities Products NOT Projects Smart Endpoints & Dumb Pipes Decentralized Governance & Data Management Infrastructure Automation via IaC Design for Failure Source: US DoD DevSecOps Fundamentals Playbook. Page 6 Layered Architecture Domain Driven Design Capability Centric Design Kafka Messaging / Streams / Connect Data Mesh / K8s / Kafka Clusters Containers / Kubernetes / Mesh Terraform Bulkhead, Circuit Breaker, Green / Blue Deployment Microservices Characteristics Evolutionary Design Epics / User Stories / MVP

@arafkarsh arafkarsh When should I use them (Microservices)? 24 • 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/

@arafkarsh arafkarsh What is the right size for a Microservice? 25 • 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.

@arafkarsh arafkarsh Microservices Architecture / Design Patterns 26 • 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 Software Architecture

@arafkarsh arafkarsh 27 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 Shopping Cart UI Layer Web Services Business Logic Database Layer Micro Service 2 Order UI Layer WS BL DL Database Shopping Cart 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

@arafkarsh arafkarsh 28 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 Shopping Cart UI Layer Web Services Business Logic Database Layer Micro Service 2 Order API Gateway Load Balancer Circuit Breaker Service Discovery Load Balancer Circuit Breaker Load Balancer Circuit Breaker UI Layer Database Shopping Cart 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 Consumers 3rd Party Apps Smart Pipes Lot of Business logic resides in the Pipe

@arafkarsh arafkarsh Technology Selection 29 Microservices with Multiple Technology Stack – Kubernetes (K8s) for Networking Event Stream / Queues / Pub-Sub / Storage / CDC Users API Gateway (K8s/Istio Ingress Controller / Spring Cloud Stack) Web Services Business Logic Database Layer Cart Micro Service Shopping Cart SE 8 Load Balancer Circuit Breaker Load Balancer (K8s Linux IPVS / Spring) Circuit Breaker Web Services Business Logic Database Layer Product SE 17 Product Microservice With 4 node cluster Load Balancer Circuit Breaker Web Services Business Logic Database Layer Customer Customer Microservice With 2 node cluster Virtual Private Network Load Balancer Circuit Breaker Web Services Business Logic Database Layer Order Order Microservice With 2 node Cluster Spring Cloud / Config OR Kubernetes API GW / LB / Service Discovery (DNS) Service Mesh External Load Balancer Angular / React Flutter / React Native HTML 5 / JavaScript Kotlin / Dart / Swift FE: UI Layer FE: Front End BE: Backend BE BE BE BE

@arafkarsh arafkarsh 30 Shopping Portal /Web Ui /Authentication /product /review Mesh – API GW Nodes Firewall Web Ui Pod Web Ui Pod Web App Service N2 N1 Product Pod Product Pod Product Pod Product Service N4 N3 MySQL DB Review Pod Review Pod Review Pod Review Service N4 N3 N1 Users Routing based on Layer 3 (IP), 4 (TCP) and 7 ((HTTP) Mongo DB Mongo DB Auth Pod Auth Pod Auth / Authorize Service N3 N5 MySQL DB Generates Token (JWT) Services will process requests only if the token is valid istiod Istio Control Plane K8s Load Balancer External Load Balancer Kubernetes Objects Istio Objects Istio Sidecar Envoy

@arafkarsh arafkarsh Software Network Stack Vs Network Stack 31 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.

@arafkarsh arafkarsh Scale Cube and Microservices 32 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

@arafkarsh arafkarsh 33 12 Factor App Methodology 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/

@arafkarsh arafkarsh 34 Additional Factors Description 13 API API Driven Contract Driven Development 14 Telemetry Application Monitoring, Domain Specific Telemetry, Health & System Logs 15 Security Authentication & Authorization Implement RBAC (Role Based Access Control) Auth and Authorization Tokens 15 Factor App Methodology

@arafkarsh arafkarsh 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). 35 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

@arafkarsh arafkarsh Case Studies Microservices + Event Sourcing / CQRS 1. E-Commerce Site (Amazon / Flipkart) 2. Movie Streaming (NetFlix) 3. Restaurant Dining (Paragon / Dominos) 4. Movie Ticket Booking (Book My Show) 5. Supply Chain 6. Health Care (Apollo Hospitals) 7. Health Care – Diagnosis – Gen AI 36

@arafkarsh arafkarsh Case Study: Shopping Site – Event Sourcing / CQRS 37 Catalogue Shopping Cart Order Payment • Search Products • Add Products • Update Products Commands • Add to Cart • Remove Item • Update Quantity Customer • Select Address • Select Delivery Mode • Process Order Events • Product Added • Product Updated • Product Discontinued • Item Added • Item Removed / Discontinued • Item Updated • Order Initiated • Address Selected • Delivery Mode Selected • Order Created • Confirm Order for Payment • Proceed for Payment • Cancel Order • Payment Initiated • Order Cancelled • Order Confirmed • OTP Send • Payment Approved • Payment Declined Microservices • Customer • Shopping Cart • Order Customer Journey thru Shopping Process 2 Processes 1 Customers will browse through the Product catalogue to find the products, their ratings and reviews. Once the product is narrowed down the customer will add the product to the shopping cart. Once the customer is ready for the purchase, he/she will start the order processing by selecting the Delivery address, delivery method, and payment option. Once the payment is done customer will get the order tracking details. ES Aggregate 4 Core Domain Sub Domain Sub Domain Sub Domain Generic Domain 3 1 The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles.

@arafkarsh arafkarsh Case Study: Movie Streaming – Event Sourcing / CQRS 38 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 The Customer will search for a specific movie or pick up a new episode from a TV Series from the watch list. Once the streaming request is authorized by the license service, video streaming will start. Customers can pause, fast-forward and restart the movie streaming. Movie streaming will be based on Customer subscription to the service. • 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. License Streaming Processes 1 2 ES Aggregate 4 Core Domain Sub Domain Sub Domain Sub Domain Generic Domain 3 2

@arafkarsh arafkarsh Case Study: Restaurant Dining – Event Sourcing and CQRS 39 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 prepares the food it can then be served. The Bill is prepared when the Table is closed. Microservices • Dinning Order • Billable Order Customer Journey thru Dinning Processes Food Menu Kitchen Dining • 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 2 4 Processes 1 Core Domain Sub Domain Sub Domain Sub Domain Generic Domain 3 3 The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles.

@arafkarsh arafkarsh Case Study: Movie Booking – Event Sourcing / CQRS 40 Order Payment • Search Movies • Add Movies • Update Movies Commands • Select Movie • Select Theatre / Show • Select Seats • Process Order • Select Food • Food Removed • Skip Food • Process Order Events • Movie Added • Movie Updated • Movie Discontinued • Movie Added • Theatre / Show Added • Seats 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 Customers will Search for the Movies after selecting the City. Once the movie is selected, they will identify a theatre check for the show Times and then select the seats. Once the seats are selected then a choice is given to add Snacks after that the Customer will proceed to payments. Once the payment is done then the tickets are confirmed. • 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. Processes 1 2 ES Aggregate 4 Core Domain Sub Domain Sub Domain Sub Domain Generic Domain 3 4

@arafkarsh arafkarsh Case Study: Manufacturing / Supply Chain – Event Sourcing and CQRS 41 • Customer Places Order • Check Status Commands • Validate Order • Check Inventory • Add Stocks • Handle Material Shortage • Validate Supplier Compliance • Place Order • Receive Materials Events • Order Placed • Status Checked • Order Validated • Inventory Checked • Stock Added • Material Shortage Identified • Supplier Compliance Confirmed • Order Placed • Materials Received • Start Manufacturing • Start Quality Control • Issue Quality Certificate • Manufacturing Started • Quality Control engaged • Quality Certificate Issued • Goods Received • Goods Stored • Retrieved Goods • Order Assembled • Order ready for Shipment Microservices • Order • Production Schedule Customer Journey through Order Process • Schedule Production Run • Allocate Resources • Optimize Production Line • Complete Production Run • Production Run Scheduled • Resources Allocated • Production Line optimized • Production Run Completed ES Aggregate 2 4 Processes 1 Core Domain Sub Domain Sub Domain Generic Domain 3 Core Domain Sub Domain Generic Domain Customers place orders, triggering the Order Management to capture and validate them. Inventory Management checks stock and, if necessary, Procurement acquires materials, allowing Production Scheduling to plan and initiate manufacturing. Quality checks are conducted during production, followed by Warehouse Management preparing the order for shipment. Shipping and Logistics manage the dispatch and delivery, while Customer Service confirms delivery and assesses satisfaction, ensuring a seamless end-to-end process. • Receive Goods • Store Goods • Retrieve goods for Order fulfilment • Update Inventory • Prepare Order for shipment • Plan Shipping Route • Ship Order • Deliver Order • Track Shipment • Manage Transportation Assets • Shipping route planned • Order Dispatched • Shipment Tracked • Order Delivered • Transportation Assets Managed • Delivery Confirmation Received • Customer Feedback received Order Management Production Scheduling Inventory Management Procurement Management Quality Control Warehouse Management Shipping & Logistics Customer Service Generic Domain • Confirm Delivery • Follow Service Experience The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles. 5

@arafkarsh arafkarsh Case Study: Health Care App: Patient Diagnosis and Treatment 42 Payment • Register Patient • Search Doctor Commands • Add Patient Info • Add Details • Add BP • Add Diagnosis • Add Prescription Events • Doctor Scheduled • Patient Added • Patient Info Added • Details Added • BP Added • Diagnosis Added • Prescription Added • Add Medicine • Add Bill • Medicine Added • Bill Prepared • Payment Approved • Payment Declined • Cash Paid The patient registers and makes an appointment with the doctor. Patient details and history are recorded. The doctor makes the diagnosis and creates the prescription. The patient buys the medicine from the Pharmacy. If a patient needs to be admitted, then a ward appointment is scheduled and admitted to the ward. Once the treatment is over patient is discharged from the Hospital. Microservices • Diagnosis • Prescription • Hospital Bill • Discharge Summary Patient Journey thru Treatment Process Registration • Add Doctor • Add Appointment • Add Patient File • Doctor Added • Appointment Added • Patient File Added ES Aggregate 2 4 Processes 1 Doctors Diagnosis Pharmacy Ward Patient • Add Checkup • Add Treatment • Add Food • Add Discharge • Checkup Added • Treatment Added • Food Added • Discharge Added Core Domain Sub Domain Sub Domain Sub Domain Sub Domain Generic Domain Sub Domain 3 6 The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles.

@arafkarsh arafkarsh 43 Firewall API Gateway External Load Balancers Gen Ai Case Study: Health Care App User Query Cloud Diagnosis Ai Service Instance 1 Instance 2 Instance 3 Internal Load Balancer DB DB Data Sources 1 Request Routing 2 3 Semantic Search Relevant Info Doc Chunks retrieved For Enhanced Context 4 5 Prompt + Query + Enhanced Context 6 Query RAG Retrieval Augmented Generation Generated Text Response Response json 7 5 Prompt + Query + Enhanced Context 6 Generated Text Response Users Internet Local LLMs Enterprise Secured Network The doctor requests the patient’s diagnosis, lab reports and prescriptions for the last 3 years. Search diagnosis, lab reports and prescriptions Summary of Diagnosis, lab reports & prescriptions for the past 3 years. Request for Diagnosis, Lab and Prescriptions Summary OR Steps 5 & 6 can be used with a Cloud or a Local LLM Kubernetes Cluster 7

@arafkarsh arafkarsh Case Studies Scalability / Security / Innovation Scalability 1. Netflix 2. Uber 3. Airbnb 44 Security 4. Capital One 5. DropBox 6. Slack Innovation 7. Spotify 8. Pinterest 9. Twitter (x.com)

@arafkarsh arafkarsh Scalability 45 Netflix uses a microservices architecture to handle its large user base and frequent updates, leveraging asynchronous communication between services where necessary. User Interaction: o User Interface (UI): Web, mobile, and smart TV apps. o API Gateway: Routes requests to appropriate microservices (e.g., Zuul). o Microservices: o User Service: Manages user accounts and profiles. o Catalogue Service: Handles the retrieval of available movies and shows. o Recommendation Service: Provides personalized content recommendations. o Streaming Service: Manages video streaming to users. o Database: Uses Cassandra, MySQL, and ElasticSearch. o Container Orchestration: Kubernetes for managing containers. 1 o Overview: Migrated from a monolithic to a microservices architecture to handle millions of concurrent users. o Technology: AWS, Microservices, Kubernetes. o Outcome: Achieved independent scaling of services, high availability, and performance. Source: https://netflixtechblog.com/

@arafkarsh arafkarsh Scalability 46 Uber’s architecture heavily relies on microservices and uses Kafka for real-time data streaming to handle the complexities of ride-hailing and logistics. User Interaction: o User Interface (UI): Rider and driver apps. o API Gateway: Manages incoming requests and routes them to microservices. o Microservices: o Ride Management Service: Manages ride requests and matching. o Payment Service: Processes payments. o User Service: Manages user profiles. o Dispatch Service: Manages driver dispatching. o Database: Cassandra, MySQL, Redis. o Event Streaming: Kafka for real-time data streaming between microservices (e.g., ride matching, ETA calculations). o Container Orchestration: Kubernetes for orchestrating containers. 2 o Overview: Transitioned to a microservices architecture to manage its global ride-hailing service. o Technology: Microservices, Docker, Kubernetes, Apache Kafka for real-time data streaming. o Outcome: Enhanced scalability to handle millions of rides per day, improved fault isolation, and faster deployment cycles. Source: https://www.uber.com/en- IN/blog/bangalore/engineering/

@arafkarsh arafkarsh Scalability 47 Airbnb utilizes a microservices architecture to support its scalable platform, with asynchronous communication between services for reliability. User Interaction: o User Interface (UI): Web and mobile apps. o API Gateway: Routes requests to microservices. o Microservices: o Listing Service: Manages property listings. o Booking Service: Handles reservations. o Payment Service: Processes payments. o User Service: Manages user profiles. o Database: PostgreSQL, Redis. o Event Streaming: Kafka for handling asynchronous communication and event sourcing. o Container Orchestration: Kubernetes for managing services. 3 o Overview: Adopted a service-oriented architecture to support its rapidly growing user base and listings. o Technology: AWS, Microservices, Kubernetes, Envoy for service discovery and load balancing. o Outcome: Scaled effectively to handle millions of users and listings, improved system resilience, and agility in deploying new features. Source: https://medium.com/airbnb-engineering

@arafkarsh arafkarsh Security 48 Capital One’s transition to microservices includes robust security practices and uses Kafka for reliable data streaming. User Interaction: o User Interface (UI): Mobile apps and web portals. o API Gateway: Manages secure routing of requests. o Microservices: o Account Service: Manages user accounts. o Transaction Service: Handles transactions. o Fraud Detection Service: Monitors for fraudulent activities. o User Service: Manages authentication and profiles. o Database: Encrypted databases for financial data. o Event Streaming: Kafka for real-time data streaming and processing. o Container Orchestration: Kubernetes for deploying services. 4 o Overview: Migrated to AWS with a strong focus on security. o Technology: Zero-trust security model, AWS IAM, AWS GuardDuty, Kubernetes, Istio. o Outcome: Achieved robust security for cloud operations, continuous threat detection, and secure service-to-service communication. Source: https://medium.com/capital-one-tech

@arafkarsh arafkarsh Security 49 Dropbox’s architecture includes microservices and event streaming for file operations and real-time updates. User Interaction: o User Interface (UI): Web, desktop, and mobile clients. o API Gateway: Routes API calls to microservices. o Microservices: o File Storage Service: Manages file operations. o Sharing Service: Handles file sharing. o Sync Service: Synchronizes files across devices. o User Service: Manages user authentication. o Database: Distributed storage systems, and various databases for metadata. o Event Streaming: Kafka for synchronizing file updates and events. o Container Orchestration: Kubernetes for container management. 5 o Overview: Security is a critical focus to ensure that user data is protected across its distributed storage systems. o Technology: Zero-trust security model, Kubernetes, Istio. o Outcome: Strong encryption and access controls ensure data privacy and security. Microservices and Kubernetes allow Dropbox to scale its services efficiently to handle millions of users. Source: https://dropbox.tech/

@arafkarsh arafkarsh Security 50 Slack uses microservices and event-driven architecture with Kafka to handle real-time messaging and notifications. User Interaction: o User Interface (UI): Desktop, web, and mobile apps. o API Gateway: Manages API traffic. o Microservices: o Messaging Service: Handles message sending and receiving. o Notification Service: Manages notifications. o User Service: Manages user authentication and profiles. o File Storage Service: Manages file uploads and sharing. o Database: Databases for storing messages and files. o Event Streaming: Kafka for real-time message and notification processing. o Container Orchestration: Kubernetes for deploying microservices. 6 o Overview: Slack employs a microservices architecture to support its real-time messaging platform, emphasizing security to protect user communication and data. o Technology: Zero-trust security model, Kubernetes, Service Mesh. Various database technologies for data storage. o Outcome: Encryption and secure API management ensure that user communications are protected. Source: https://slack.engineering/

@arafkarsh arafkarsh Innovation 51 Spotify’s architecture supports its streaming services and recommendations, leveraging Kafka for real-time data processing. User Interaction: o User Interface (UI): Mobile and desktop clients. o API Gateway: Routes requests to microservices. o Microservices: o Music Catalogue Service: Manages music metadata. o Recommendation Service: Provides music recommendations. o User Service: Manages user accounts. o Database: Databases for music metadata, and user data. o Event Streaming: Kafka for real-time data streams and event sourcing. o Container Orchestration: Kubernetes for microservices management. 7 o Overview: Embraced cloud-native principles to enable rapid development and deployment. o Technology: Microservices, Kubernetes, GCP, Spinnaker for continuous delivery. o Outcome: Enabled rapid feature releases, continuous improvement in user experience, and real-time recommendations. Source: https://engineering.atspotify.com/

@arafkarsh arafkarsh Innovation 52 Pinterest uses microservices to manage its image- sharing platform, with Kafka for event streaming and real-time processing. User Interaction: o User Interface (UI): Web and mobile apps. o API Gateway: Routes requests to microservices. o Microservices: o Image Storage Service: Manages image uploads and storage. o Recommendation Service: Provides personalised recommendations. o User Service: Manages user profiles. o Database: Databases for images and user data. o Event Streaming: Kafka for handling image processing and updates. o Container Orchestration: Kubernetes for managing microservices. 8 o Overview: Pinterest leverages a microservices architecture to support its image-sharing platform, enabling rapid feature development and scaling to handle its large user base. o Technology: Microservices, Kubernetes, Jenkins and custom-built tools for continuous integration and delivery. o Outcome: The microservices architecture enables rapid development cycles, allowing Pinterest to quickly release new features and improve the platform. Source: https://medium.com/@Pinterest_Engineering

@arafkarsh arafkarsh Innovation 53 Twitter (x.com) uses microservices for scalability and Kafka for real-time processing of tweets and timelines. User Interaction: o User Interface (UI): Web and mobile apps. o API Gateway: Routes incoming requests. o Microservices: o Tweet Service: Manages tweet creation and storage. o User Management Service: Handles user profiles. o Timeline Service: Generates user timelines. o Database: Databases for tweets and user data. o Event Streaming: Kafka for real-time tweet processing and timeline updates. o Container Orchestration: Kubernetes for service deployment and management. 9 o Overview: Employs a microservices architecture to manage the complexities of its social networking platform. The architecture supports rapid innovation and scalability, enabling Twitter to handle real-time interactions and massive amounts of data. o Technology: Microservices, Kubernetes, Custom- built continuous integration and delivery pipelines. o Outcome: Microservices architecture allows for rapid iteration and deployment of new features, keeping the platform dynamic and user-friendly and handling millions of tweets. Source: https://blog.x.com/engineering/en_us

@arafkarsh arafkarsh Monolithic > Microservices • Modernization journey • Assess and classify your app portfolio • Plan and prioritize • Migration Design Patterns 54 2

@arafkarsh arafkarsh Modernization Journey 55 ✓ 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 Future Present Low Inspired by a paper from IBM

@arafkarsh arafkarsh Assess and Classify your App Portfolio 56 ✓ 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 APIs Lift & Shift Business Value Cost Complexity Product Catalogue Product Review Inventory Shopping Cart Customer Profile Order Management Inspired by a paper from IBM

@arafkarsh arafkarsh Lift and Shift 57 ❑ Rehost: o Moving an On-Premise App without any redesign to the Cloud Service Provider. o Migration can be fast and relatively inexpensive. o However, the OpEx can be on higher side as Application is not using leveraging the Cloud efficiencies. ❑ Quick Savings o Down Jones lowered IT costs by more than 25%. o GE Oil & Gas realized 52% cost savings Source: https://www.netapp.com/knowledge-center/what-is-lift-and-shift/.

@arafkarsh arafkarsh ShopEasy App: User Journey with Story Map 58 Global Search Search by Brand Search by Price Search by Model Product Details Image Gallery Product Reviews User Shopping Experience Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment Catalogue Shopping Cart Order Payment Customer View Product Search User Journey Make Payment Confirm Order Pay Credit Card Pay Debit Card Use PayPal Select Address Registration Add to Cart Update Qty Delete Item UI Layer WS BL DL Database Cart Order Customer Product Monolith Search Payment

@arafkarsh arafkarsh Design Pattern 1 Decomposition Identify the Modules and Boundaries 2 Strangler Fig Product Service (Query Only with Apache Solr) 3 Branch By Abstraction Shopping Cart as Service using Monolithic DB 4 Decorating Collaborator New Shipping Service with Database 5 Change Data Capture Enhance Loyalty Module as a new Service 6 Aggregate API Expose Customer API on Monolith 7 Split Table Product Split into 2 Services as Product Management and Warehouse 8 Change Data Ownership Order Service using Monolithic DB 9 Move Foreign Key to Code Foreign Key in Order (item) with Product Table moved to Order Service Code 10 Strangler Fig Move out Customer Module and decommission the Monolith Shopping Portal Legacy Migration Plan 59 • Prioritize the Modules / Services For Implementation & Deployment Setup Transition Plan UI Layer WS BL DL Database Cart Order Customer Product Monolith

@arafkarsh arafkarsh 1. Decomposition Pattern – Tier 2 : Backend 60 Shopping Portal Monolithic DB Product Catalogue Reviews Product Order Item Shipping Methods Address Payments Inventory Items Category Inventory Event Cart Items Wish List Price Event Category Order Added From Cart uses uses Customer Brand Addresses Cards Shopping Portal Monolithic App 1. Focus on the User Journey 2. Identify the Epics and User Stories 3. Consider each Epic as a Cohesive Unit Epics 1. Customer Management 2. Product Catalogue 3. Shopping Cart 4. Order Management 5. Inventory System Source: Monolith to Microservices By Sam Newman

@arafkarsh arafkarsh 1. Decomposition Pattern 61 An e-Comm App User’s Journey can run across multiple Bounded Context / Microservices. User Journey X Product Catalogue Shopping Cart Order User Journey Y Bounded Context Bounded Context Bounded Context Shopping Portal Monolithic DB Shopping Portal Monolithic App Product Catalogue Reviews Product Order Item Shipping Methods Address Payments Inventory Items Category Inventory Event Cart Items Wish List Price Event Category Order Added From Cart uses uses Customer Brand Addresses Cards Customer Order Cart Product Inventory Source: Monolith to Microservices By Sam Newman

@arafkarsh arafkarsh 1. Decomposition Pattern – Tier 3 : Database 62 An e-Comm App User’s Journey can run across multiple Bounded Context / Microservices. User Journey X Product Catalogue Shopping Cart Order User Journey Y Bounded Context Bounded Context Bounded Context Customer Shopping Portal Monolithic App Product Catalogue Reviews Product Order Item Shipping Methods Address Payments Inventory Items Category Inventory Event Cart Items Wish List Price Event Category Order Added From Cart uses uses Customer Brand Addresses Cards Customer Order Cart Product Inventory Cart Order Product Inventory Source: Monolith to Microservices By Sam Newman

@arafkarsh arafkarsh Plan and Prioritize 63 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

@arafkarsh arafkarsh 2. Strangler Fig Pattern 64 API Gateway / Proxy Web Services Business Logic Database Layer Product Micro Service Product SE 8 UI Layer WS BL DL Database Cart Order Customer Product UI Layer WS BL DL Database Cart Order Customer Product UI Layer WS BL DL Database Cart Order Customer Product Web Services Business Logic Database Layer Product Micro Service Product SE 8 API Gateway / Proxy Step 1 Identity the Module Step 2 Move the Service Step 3 Redirect the Calls to New Service Source: Monolith to Microservices By Sam Newman 1. New Service (Code) 2. Better Search Capabilities Product DB will be used by other modules in Monolithic App Monolith Monolith Monolith Only used for Search Capabilities and Scalability.

@arafkarsh arafkarsh 3. Branch By Abstraction 65 UI Layer WS BL DL Database Cart Order Customer Product Web Services Business Logic Database Layer Cart Service Uses Monolithic DB Cart SE 8 Step 1 Create an Abstraction for Product Module Step 2 Use Abstraction Cart Mono Implements Cart Service UI Layer WS BL DL Database Customer Cart Step 3 Create new Implementation UI Layer WS BL DL Database Customer Cart Web Services Business Logic Database Layer Cart Service Uses Monolithic DB Cart SE 8 Step 4 Switch Implementation UI Layer WS BL DL Database Customer Cart UI Layer WS BL DL Database Customer Step 5 Clean up Web Services Business Logic Database Layer Cart Service Uses Monolithic DB Cart Monolith Monolith Source: Monolith to Microservices By Sam Newman

@arafkarsh arafkarsh 4. Decorating Collaborator Pattern 66 WS BL DL Database Cart Order Customer Product Monolith Request Response Order Proxy Web Services Business Logic Database Layer Shipping Micro Service Shipping Place Order Success / Failed If Success Proceed for Shipping 1. In the Strangler Fig Pattern Proxy did the routing. 2. Order Proxy Sends the data to Shipping Service 3. Eventually Order Proxy will completely migrate to Order Microservice. Source: Monolith to Microservices By Sam Newman Add Shipping Feature integrated Order Module if the Order is finalized. 1. Least number of changes to Monolith 2. Add new feature as new Microservice

@arafkarsh arafkarsh 5. Change Data Capture Pattern 67 WS BL DL Cart Order Customer Product Monolith Transaction Log Insert into Loyalty Values (“ABC”, “123-456-789”, 100) Customer ID Loyalty ID Value ABC 123-456-789 100 On Commit Web Services Business Logic Database Layer Loyalty Micro Service Loyalty 1. Monolithic has basic Loyalty Feature 2. Loyalty Program is further enhanced in a Microservice. Connector Loyalty Topic 3. Initial Data Captured in Monolithic is transferred to Loyalty Microservice. 4. Further feature is developed in Loyalty Service 5. CDC is better than Decorating Collaborator in this Use Case Source: Monolith to Microservices By Sam Newman

@arafkarsh arafkarsh 6. Aggregate Exposing Monolith Pattern 68 WS BL DL Cart Order Customer Product Monolith Web Services Business Logic Database Layer Loyalty Micro Service Loyalty 1. Customer Aggregate is Exposed as Service for all the CRUD handling. 2. As Customer reference (As a Foreign Key) available in multiple modules, Shopping Cart, Order etc. 3. It’s a good idea to keep the Customer As an Aggregate Service in the Monolith. 4. Until all the services are moved out. ID Customer Name Title ABC John Doe CEO API Source: Monolith to Microservices By Sam Newman

@arafkarsh arafkarsh 7. Split Table Patterns 69 WS BL DL Cart Order Customer Product Monolith SKU Item Name Qty ABC iPhone 12 610 DEF iPhone 11 987 GHI iPhone 10 1597 Web Services Business Logic Database Layer Order Micro Service Product Admin Web Services Business Logic Database Layer Order Micro Service Warehouse SKU Item Name ABC iPhone 12 DEF iPhone 11 GHI iPhone 10 SKU Qty ABC 610 DEF 987 GHI 1597 1. Split the Table in the existing Monolithic DB 2. The Module Product Split into Product Admin and Warehouse 3. Each Microservice will has its own Split Table. 4. Make sure that only Soft Delete is allowed in Product table. Source: Monolith to Microservices By Sam Newman

@arafkarsh arafkarsh 8. Change Data Ownership Pattern 70 WS BL DL Cart Order Customer Product Monolith Web Services Business Logic Database Layer Order Micro Service order 1. Order Module Created as a Service as uses Monolith as the Database.. 2. In the Second Iteration Order Service will have its own DB Carved out of Monolith Application 3. Change of Order DB from Monolith to Microservices “Order Service” WS BL DL Cart Customer Product Monolith Web Services Business Logic Database Layer Order Micro Service order Order ID Customer SKU Qty Value 100 John Doe ABC 5 $100 100 John Doe DEF 2 $200 ID Customer SKU Qty Value 100 John Doe ABC 5 $100 100 John Doe DEF 2 $200 Source: Monolith to Microservices By Sam Newman

@arafkarsh arafkarsh 9. Move Foreign Key Relationship to Code Pattern 71 WS BL DL Cart Order Customer Product Monolith 1. SKU in the Order is a Foreign Key to Product Table in the Monolith 2. When Order is Moved as a Separate Service SKU Foreign Key relationship is lost. 3. Move the Foreign Key Relationship into Order Service Code or Embrace Duplication - Copy Item name in Product Table to Order when the Order is created. Web Services Business Logic Database Layer Order Service order ID Customer SKU Qty Value 100 John Doe ABC 5 $100 100 John Doe DEF 2 $200 ID Customer SKU Qty Value 100 John Doe ABC 5 $100 100 John Doe DEF 2 $200 SKU Item Name ABC iPhone 12 DEF iPhone 11 Web Services Business Logic Database Layer Product Admin Service Product Admin SKU Item Name ABC iPhone 12 DEF iPhone 11 Source: Monolith to Microservices By Sam Newman 1. Query the Order 2. Get SKU From Product Admin Service 3. Fetch SKU

@arafkarsh arafkarsh Strangler Fig Pattern 72 API Gateway / Proxy Web Services Business Logic Database Layer Customer Micro Service Customer SE 8 UI Layer WS BL DL Database Cart Order Customer Product UI Layer WS BL DL Database Cart Order Customer Product UI Layer WS BL DL Database Cart Order Customer Product Web Services Business Logic Database Layer Customer Micro Service Customer SE 8 API Gateway / Proxy Step 1 Identity the Module Step 2 Move the Service Step 3 Redirect the Calls to New Service Source: Monolith to Microservices By Sam Newman 1. New Service (Code) 2. Better Search Capabilities Monolith Monolith Monolith • Customer Module the last Module migrated to Microservices • Legacy Shopping Portal App is de-commissioned.

@arafkarsh arafkarsh 10. Parallel Run Pattern 73 /order API Gateway Firewall Order v2 v2 v2 v1 Order v1 Order Service Destination Rule v1 Users Production Data is mirrored to new release for real-time testing Source: Monolith to Microservices By Sam Newman 100% = v1 Mirror = v2 Scenario 1 95% = v1 5% = v2 Scenario 2 100% = v2 Scenario 3

@arafkarsh arafkarsh Design Pattern 1 Decomposition Identify the Modules and Boundaries 2 Strangler Fig Product Service (Query Only with Apache Solr) 3 Branch By Abstraction Shopping Cart as Service using Monolithic DB 4 Decorating Collaborator New Shipping Service with Database 5 Change Data Capture Enhance Loyalty Module as a new Service 6 Aggregate API Expose Customer API on Monolith 7 Split Table Product Split into 2 Services as Product Management and Warehouse 8 Change Data Ownership Order Service using Monolithic DB 9 Move Foreign Key to Code Foreign Key in Order (item) with Product Table moved to Order Service Code 10 Strangler Fig Move out Customer Module and decommission the Monolith Shopping Portal Legacy Migration Plan 74 • Prioritize the Modules / Services For Implementation & Deployment Setup Transition Plan UI Layer WS BL DL Database Cart Order Customer Product Monolith

@arafkarsh arafkarsh Monolithic to Microservices Summary 75 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 Migration Design Patterns 1. Decomposition 2. Strangler Fig Pattern 3. Branch By Abstraction 4. Decorating Collaborator 5. Change Data Capture 6. Aggregate API 7. Split Table 8. Change Data Ownership 9. Move Foreign Key to Code 10. Parallel Run

@arafkarsh arafkarsh Containers & Kubernetes • Docker containers • Kubernetes – container orchestration • ISTIO – Traffic management / network policies 76 3

@arafkarsh arafkarsh 77 Start an Apache Web Server on a Virtual Machine. Start an Apache Web Server running inside a Container on a Virtual Machine. 1 2 Who will WIN the race?

@arafkarsh arafkarsh What’s a Container? 78 Virtual Machine Looks like a Walks like a Runs like a Containers are a Sandbox inside Linux Kernel sharing the kernel with separate Network Stack, Process Stack, IPC Stack etc.

@arafkarsh arafkarsh 79 Servers / Virtual Machines / Containers Hardware Host OS HYPERVISOR App 1 App 1 App 1 Guest OS BINS / LIB Guest OS BINS / LIB Guest OS BINS / LIB Type 2 Hypervisor App 2 App 3 App 2 OS Hardware Desktop / Laptop BINS / LIB App BINS / LIB App Container 1 Container 2 Type 1 Hypervisor Hardware HYPERVISOR App 1 App 1 App 1 Guest OS BINS / LIB Guest OS BINS / LIB Guest OS BINS / LIB App 2 App 3 App 2 Guest OS Hardware Type 1 Hypervisor BINS / LIB App BINS / LIB App BINS / LIB App Container 1 Container 2 Container 3 HYPERVISOR Virtualizes the OS Create Secure Sandboxes in OS Virtualizes the Hardware Creates Virtual Machines Hardware OS BINS / LIB App 1 App 2 App 3 Server Data Center No Virtualization Cloud Elastic Computing Hosted Hypervisor Runs on Bare Metal

@arafkarsh arafkarsh Docker containers are Linux Containers CGROUPS NAME SPACES Copy on Write DOCKER CONTAINER 80 • 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 run lxc-start https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/resource_management_guide/ch01

@arafkarsh arafkarsh Docker Container – Linux and Windows 81 Control Groups cgroups Namespaces Pid, net, ipc, mnt, uts Layer Capabilities Union File Systems: AUFS, btrfs, vfs Control Groups Job Objects Namespaces Object Namespace, Process Table. Networking Layer Capabilities Registry, UFS like extensions Namespaces: Building blocks of the Containers

@arafkarsh arafkarsh Linux Kernel 82 HOST OS (Ubuntu) Client Docker Daemon Cent OS Alpine Debian Linux Kernel 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 Windows Kernel Host Kernel Host Kernel Host Kernel Windows Kernel

@arafkarsh arafkarsh CRI Daemon CRI Client How Container Works…. 83 $ docker search …. $ docker build …. $ docker container create .. Container Registry Images Containers $ docker container run .. $ docker container start .. $ docker container stop .. $ docker container ls .. $ docker push …. $ docker swarm .. 2 1 3 4 1. Search for the Container 2. CRI Daemon Sends the request to Container Registry 3. Downloads the image 4. Run the Container from the image CRI – Container Runtime Interface Amazon Microsoft Google Container Registries Downloads in Layers containerd / CRI-O Podman / Docker Daemon dev prod

@arafkarsh arafkarsh 84 Root Vs. Rootless Containers Feature Root Container Rootless Container Host Privileges Requires root privileges. Runs with non-root user privileges. Security Higher risk of privilege escalation. Safer; limited access to the host system. Networking Full access to host networking. Uses user namespaces (e.g., slirp4netns). Use Cases Advanced features (e.g., device access). General-purpose workloads. Ease of Use Easier setup with root daemon. Slightly more configuration required.

@arafkarsh arafkarsh Distroless Image Size 85 Source: Bellsoft Distroless Images & Security

@arafkarsh arafkarsh Vanilla Service Comparison 86

@arafkarsh arafkarsh Kubernetes Key Concepts 87 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

@arafkarsh arafkarsh Deployment – Updates and rollbacks, Canary Release D ReplicaSet – Self Healing, Scalability, Desired State R Worker Node 1 Master Node (Control Plane) Kubernetes Architecture 88 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.2 10.1.2.34 BE 1.2 10.1.2.35 BE 1.2 10.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 Virtual 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 443 API Server Pod IP ...34 ...35 ...36 EP • Declarative Model • Desired State Key Aspects N1 N2 N3 Namespace 1 N1 N2 N3 Namespace 2 • 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

@arafkarsh arafkarsh Docker Networking Vs. Kubernetes Networking 89 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 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 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

@arafkarsh arafkarsh Kubernetes Networking 3 Networks 90 Source: 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. Virtual Network - L2 / L3 /Overlay / Cloud

@arafkarsh arafkarsh Kubernetes Workload Portability 91 Goals 1. Abstract away Infrastructure Details 2. Decouple the App Deployment from Infrastructure (On-Premise or Cloud) To help Developers 1. Write Once, Run Anywhere (Workload Portability) 2. Avoid Vendor Lock-In Cloud On-Premise

@arafkarsh arafkarsh Traffic Management o Kubernetes Deployment / Testing o Service Mesh – Traffic Routing 92

@arafkarsh arafkarsh Alpha Web App Source: https://github.com/arafkarsh/k8s-quickstart 93

@arafkarsh arafkarsh 94 ShopEZ Portal /cart /order /product /alpha API Gateway Nodes Firewall Product Pod Product Pod Product Pod Product Service N5 N3 MySQL DB Users Routing based on Layer 3 (IP), 4 (TCP) and 7 ((HTTP) Mongo DB Mongo DB MySQL DB Token (JWT) Services will process requests only if the token is valid JWT Token generated after user Authentication Cart Pod Cart Pod Cart Service N2 N1 EndPoints Order Pod Order Pod Order Service N3 N5 EndPoints EndPoints Alpha Pod Alpha Pod Alpha Pod Alpha Service N4 N3 N1 EndPoints Internal LoadBalancer N2

@arafkarsh arafkarsh Specs of the Alpha Example – Ozazo ShopEZ 95 Service Name Image Size # Limit CPU Total CPU Limit Memory Request CPU Total Req CPU Request Memory QoS Alpha 37.8 MB 3 5m 15m 16Mi 5m 15m 12Mi Burstable Product 21.7 MB 3 5m 15m 16Mi 5m 15m 16Mi Guaranteed Cart 21.4 MB 2 5m 10m 16Mi 5m 10m 16Mi Guaranteed order 21.4 MB 2 5m 10m 16Mi 5m 10m 16Mi Guaranteed Total 102 MB 10 20m 50m 160Mi 20m 50m 148M Total Capacity – 10 Instances 5% of a Single Core 160MiB Max Capacity – 1 Instance 0.5%of a Single Core 16MiB 1 MB = 1000 K 1 MiB = 1024 K

@arafkarsh arafkarsh Shopping Portal 96 /ui /productms /auth /order Gateway Virtual Service Deployment / Replica / Pod Nodes Istio Sidecar - Envoy Load Balancer Kubernetes Objects Istio Objects Firewall istiod Istio Control Plane UI Pod N5 v2 Canary v2 User 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 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

@arafkarsh arafkarsh Shopping Portal 97 /ui /productms /auth /order Gateway Virtual Service Deployment / Replica / Pod Nodes Istio Sidecar - Envoy Load Balancer Kubernetes Objects Istio Objects Firewall UI Pod N5 v2 Canary v2 v1 UI Pod UI Pod UI Pod UI Service N1 N2 N2 Destination Rule Stable / v1 EndPoints Internal Load Balancers 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 istiod Istio Control Plane

@arafkarsh arafkarsh Shopping Portal 98 /ui /productms /auth /order Gateway Virtual Service Deployment / Replica / Pod Nodes Load Balancer Kubernetes Objects Firewall UI Pod N5 v2 Canary v2 v1 UI Pod UI Pod UI Pod UI Service N1 N2 N2 Destination Rule Stable / v1 EndPoints Internal Load Balancers 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 Istio Sidecar - Envoy Istio Objects istiod Istio Control Plane

@arafkarsh arafkarsh Shopping Portal 99 /UI /productms /auth /order Gateway Virtual Service Deployment / Replica / Pod Nodes External Load Balancer Kubernetes Objects Firewall UI Pod N5 v2 Canary v2 v1 UI Pod UI Pod UI Pod UI Service N1 N2 N2 Destination Rule Stable / v1 EndPoints Internal Load Balancers 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 Istio Sidecar - Envoy Istio Objects istiod Istio Control Plane

@arafkarsh arafkarsh 100 Shopping Portal /ui /productms /auth /order Gateway Virtual Service Deployment / Replica / Pod Nodes Load Balancer Firewall Fault Injection MySQL Pod N4 N3 Destination Rule Product Pod Product Pod Product Pod Product Service Service Call Kube DNS EndPoints Internal Load Balancers 100 Source: https://github.com/meta-magic/kubernetes_workshop Fault Injection Delay = 2 Sec Abort = 10% Kubernetes Objects Users Review Pod Review Pod Review Pod Review Service N1 N4 N3 EndPoints UI Pod UI Pod UI Pod UI Service N1 N2 N2 Destination Rule v1 EndPoints Istio Sidecar - Envoy Istio Objects istiod Istio Control Plane

@arafkarsh arafkarsh Deployment Models: Kubernetes Gateway API 101 /order Gateway Firewall Order Pod v2 v2 = Green Order Pod v1 Order Service Blue v1 = Blue Users Various Deployment Models from Rolling update to Canary, AB Testing, Blue Green, Shadow, and Feature Flag Deployments. 100% = v1 = v2 Scenario 0 Order Pod v1 Order Pod v1 Order Pod v1 Order Pod v2 Order Pod v2 HTTP Route Rolling / Recreate Deploy v2 v1 Order Service Green 100% = v1 100% = v2 Scenario 4 Shadow Mirror Production Data 0% = v1 100% = v2 Scenario 3 Blue Green Instant Switch to v2 Zero Downtime 50% = v1 50% = v2 Scenario 2 A/B Testing Traffic Split UI Feedback 95% = v1 5% = v2 Scenario 1 Canary Traffic Split Backend Stability Gradual Update or Recreate after terminating old version Overwritten by Advanced Deployment Patterns Istio supports Gateway API with / without Envoy Proxy Chrome = v1 Firefox = v2 Scenario 5 Feature Flag Route using header / Query params Flag can be set for the same version

@arafkarsh arafkarsh Deployment Models: Service Mesh – Istio 102 /order Istio Gateway Order Pod v2 v2 v2 = Green Order Pod v1 Order Service Destination Rule v1 = Blue 100% = v1 = v2 Scenario 0 Order Pod v1 Order Pod v1 Order Pod v1 Order Pod v2 Order Pod v2 Virtual Service Rolling / Recreate Deploy v1 Sidecar - Envoy Istio Objects Various Deployment Models from Rolling update to Canary, AB Testing, Blue Green, Shadow, and Feature Flag Deployments. Gradual Update or Recreate after terminating old version Overwritten by Advanced Deployment Patterns Firewall Users Chrome = v1 Firefox = v2 Scenario 5 Feature Flag Route using header / Query params Flag can be set for the same version 100% = v1 100% = v2 Scenario 4 Shadow Mirror Production Data 0% = v1 100% = v2 Scenario 3 Blue Green Instant Switch to v2 Zero Downtime 50% = v1 50% = v2 Scenario 2 A/B Testing Traffic Split UI Feedback 95% = v1 5% = v2 Scenario 1 Canary Traffic Split Backend Stability

@arafkarsh arafkarsh # Strategy Zero Downtime? Rollback Feasibility Best For 0 Rolling Deployment Yes Slow rollback Continuous updates 0 Recreate Deployment No No rollback Major breaking changes 1 Canary Deployment Yes Instant rollback Risk-controlled rollouts 2 A/B Testing Yes Instant rollback UX/UI improvements 3 Blue-Green Deployment Yes Instant rollback Critical applications 4 Shadow Deployment Yes Slow rollback AI/ML, real-time monitoring 5 Feature Flag Deployment Yes Instant rollback Gradual feature rollouts Compare Deployment Strategies 103            

@arafkarsh arafkarsh Summary – Traffic Routing / Deployment / Testing 104 1. Traffic Routing based on Service Name and other params in the header 2. Internal Load Balancers (Linux IPVS - IP Virtual Service) 3. A/B Testing using Canary Deployment 4. Blue Green Deployment 5. Circuit Breaker Pattern 6. Fault Injection

@arafkarsh arafkarsh Kubernetes Network Security Policy • Kubernetes Network Policy – L3 / L4 • Kubernetes Security Policy for Microservices • Cilium Network / Security Policy • Berkeley Packet Filter (BPF) • Express Data Path (XDP) • Compare: Weave | Calico | Romana | Cilium | Flannel 105

@arafkarsh arafkarsh K8s Network Policies L3/L4 106 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 Blocks Access Blocks Access

@arafkarsh arafkarsh Network Security Policy for Microservices 107 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

@arafkarsh arafkarsh Network Security Policy for Microservices 108 Product Review Microservice Product Microservice L3 / 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

@arafkarsh arafkarsh Cilium Network Policy 109 1. Cilium Network Policy works in sync with Istio in the Kubernetes world. 2. In Docker world Cilium works as a network driver and you can apply the policy using ciliumctl. In the previous example with Kubernetes Network policy you will be allowing access to Product Review from Product Microservice. However, that results in all the API calls of Product Review accessible by the Product Microservice. Now with the New Policy only GET /reviews/{id} is allowed. These Network policy gets executed at Linux Kernel using BPF. Product Microservice can access ONLY GET /reviews from Product Review Microservice User Microservice can access GET /reviews & POST /reviews from Product Review Microservice

@arafkarsh arafkarsh Container & Kubernetes Summary 110 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.

@arafkarsh arafkarsh Istio – Security o Network Security o Peer Authentication o Request Authentication o Authorization Policy 111

@arafkarsh arafkarsh Istio Security 112 Source: https://istio.io/docs/concepts/security/ It provide strong identity, powerful policy, transparent TLS encryption, and authentication, authorization and audit (AAA) tools to protect your services and data. The goals of Istio security are • Security by default: no changes needed for application code and infrastructure • Defense in depth: integrate with existing security systems to provide multiple layers of defense • Zero-trust network: build security solutions on untrusted networks

@arafkarsh arafkarsh Istio Components – Envoy Proxy / Istiod 113 Source: https://istio.io/docs/concepts/security/ Istiod Envoy Proxy

@arafkarsh arafkarsh Authentication Architecture 114 Using peer and request authentication policies, you can specify authentication requirements for workloads receiving requests in an Istio mesh. Upon any policy changes, the new policy is translated to the appropriate configuration telling the PEP how to perform the required authentication mechanisms. Istio sends configurations to the targeted endpoints asynchronously. Istio automatically upgrades all traffic between two PEPs to mutual TLS for peer authentication. If authentication policies disable mutual TLS mode, Istio continues to use plain text between PEPs. PEP = Envoy Proxy Policy Enforcement Point Source: https://istio.io/docs/concepts/security/

@arafkarsh arafkarsh Authorization Architecture 115 The authorization policy enforces access control to the inbound traffic in the server side Envoy proxy. Each Envoy proxy runs an authorization engine that authorizes requests at runtime. When a request comes to the proxy, the authorization engine evaluates the request context against the current authorization policies, and returns the authorization result, either ALLOW or DENY. Source: https://istio.io/docs/concepts/security/

@arafkarsh arafkarsh Envoy & Merbridge Network Controller 116 Product Service Kubernetes Pod Review Service Kubernetes Pod SOCKET SOCKET SOCKET SOCKET SOCKET SOCKET K8s Network Operating System Ethernet eth0 eth0 Ethernet TCP/IP TCP/IP Merbridge Merbridge Node 1 Node 2

@arafkarsh arafkarsh Security Policies o Authorization Policy o Peer Authentication o Request Authentication 117

@arafkarsh arafkarsh Deployments 118

@arafkarsh arafkarsh Service Accounts / Authorization Policy 119

@arafkarsh arafkarsh Peer Authentication for Microservice 120

@arafkarsh arafkarsh Peer Authentication for Mesh / Namespace 121 Mode • STRICT • PERMISSIVE • DISABLED

@arafkarsh arafkarsh Request Authentication 122 • kty: Key type, can be RSA or ECDSA. • e: The exponent for a standard to a public key. • n: The modulus for a standard to a public key. • alg: Specifies the algorithm intended to be used with the key. • kid: The unique identifier for the key.

@arafkarsh arafkarsh Observability o Service Mesh o Kubernetes o FluentD o Prometheus / Grafana / Zipkin / Kiali 123

@arafkarsh arafkarsh Kubernetes Native Monitoring 124 Application Logs (L7 Logs) Container / Pod Logs • Process • System Calls • Network Logs • File System Logs Kubernetes Logs • Network Flow Logs • Audit Logs • DNS Logs Host OS Logs • SSH Logs • OS Audit Logs Cloud Infra Logs App Server /bin Container Runtime Host OS Kubernetes Cloud Hardware Host / K8s Node

@arafkarsh arafkarsh Kubernetes Node 125 eBPF Programs Network Flow Log K-Probe Connection Tracker Linux Kernel Prometheus Envoy Proxy Log Collector FluentD Pods Pods Pods Pods Pods Pods Service Pods Pods Pods Pods Pods Pods Service Namespace Pods Pods Pods Pods Pods Pods Service Namespace Observability Tools Source IP Address & Port Destination IP Address & Port Protocol Adds Bytes and Packet Count to the K-Probe Data for a Connection Adds K8s Meta data like Namespace, Service Name etc Collects System & Service Metrics Tracks the State of TCP / UDP Connections. It can be used as NAT and Stateful Firewall. Routes Traffic, Perform Load Balancing, Applies Policies, handles Secure Communication FluentD runs as a sidecar to collect logs from various sources.

@arafkarsh arafkarsh Data Collection 126 K-Probe Source IP Address, Source Port, Destination IP Address, Destination Port, Protocol NF Log Adds Bytes and Packets count for the above five attributes for a connection Log Collector Adds Kubernetes Meta Data to the above data like Namespace, Service, Pod etc.. Prometheus Collects metrics, System, Service metrics

@arafkarsh arafkarsh Kubernetes Metrics Server 127 Source: https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/ • Metrics Server is a cluster-wide aggregator of resource usage data. • CPU is reported as the average usage, in CPU cores, over a period of time. • Memory is reported as the working set, in bytes, at the instant the metric was collected.

@arafkarsh arafkarsh FluentD 128 1. Elasticsearch: Popular for storing logs that are then visualized via Kibana. 2. Amazon S3: Useful for archiving logs in a cost-effective manner. 3. MongoDB: For storing logs in a NoSQL database. 4. Kafka: Acts as a high-throughput log buffering system. 5. Splunk: For comprehensive log analysis and visualization. 6. HTTP: Send logs to generic HTTP endpoints. 7. Google Cloud Storage: For storing logs on Google's cloud. 8. Datadog: For monitoring and analyzing logs. 9. Hadoop HDFS: For large-scale log storage in Hadoop environments. o FluentD aggregates log data from various sources, including logs from Kubernetes nodes and pods. It then processes and routes this data to multiple outputs. o It fits well with Kubernetes due to its lightweight nature, plugin architecture, and broad support for different types of data sources and sinks.

@arafkarsh arafkarsh Infrastructure Design Patterns • API Gateway • Load balancer • Service discovery • Circuit breaker • Service Aggregator • Let-it crash pattern 129 4

@arafkarsh arafkarsh 130 API Gateway – Kubernetes / Istio /customer /product /auth /order API Gateway Virtual Service Deployment / Replica / Pod Nodes Load Balancer Firewall Istio Control Plane MySQL Pod N4 N3 Destination Rule Product Pod Product Pod Product Pod Product Service Service Call Kube DNS EndPoints Internal Load Balancers 130 Kubernetes Objects Users Review Pod Review Pod Review Pod Review Service N1 N4 N3 EndPoints Customer Pod Customer Pod Customer Pod Customer Service N1 N2 N2 Destination Rule EndPoints Redis DB Mongo DB Istio Sidecar - Envoy Istio Objects istiod Istio Control Plane Routing based on Layer 3,4 and 7

@arafkarsh arafkarsh Ingress Load Balancer – Kubernetes Model 131 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 N2 Customer 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

@arafkarsh arafkarsh Ingress Service Discovery – Kubernetes Model 132 Kubernetes Objects Firewall Users Product 1 Product 2 Product 3 Product Service N4 N3 N1 EndPoints Internal Load Balancers DB API Gateway N1 N2 N2 Customer 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

@arafkarsh arafkarsh Circuit Breaker Pattern 133 /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 Nodes Kubernetes 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

@arafkarsh arafkarsh Service Aggregator Pattern 134 /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 N2 National National National National Service EndPoints Internal Load Balancers DB N1 N2 N2 Politics Politics Politics Politics Service EndPoints DB Sports Sports Sports Sports Service N4 N3 N1 EndPoints Internal Load Balancers DB

@arafkarsh arafkarsh Music UI 135 Play Count Discography Albums

@arafkarsh arafkarsh Service Aggregator Pattern 136 /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 N2 Discography Discography Discography Discography Service EndPoints Internal Load Balancers DB N1 N2 N2 Play Count Play Count Play Count Play Count Service EndPoints DB Playlist Playlist Playlist Playlist Service N4 N3 N1 EndPoints Internal Load Balancers DB

@arafkarsh arafkarsh Service Mesh – Sidecar Design Pattern 137 CB – Circuit Breaker LB – Load Balancer SD – Service Discovery Microservice Process 1 Process 2 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 LB CB SD Service Mesh Sidecar UI Layer Web Services Business Logic Order Microservice Application Localhost calls http://localhost/api/payment/ Router Network Stack LB CB SD Service Mesh Sidecar UI Layer Web Services Business Logic Data Plane

@arafkarsh arafkarsh Let-it-Crash Design Pattern – Erlang Philosophy 138 • 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.

@arafkarsh arafkarsh Let-it-Crash Design Pattern 139 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 means 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.

@arafkarsh arafkarsh Let-it-Crash : Comparison Erlang Vs. Microservices Vs. Monolithic Apps 140 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.

@arafkarsh arafkarsh Infrastructure Design Patterns Summary 141 1. API Gateway 2. Service Discovery 3. Load Balancer 4. Circuit Breaker 5. Side Car Pattern 6. Service Aggregator Pattern 7. Let It Crash Pattern

@arafkarsh arafkarsh Cloud Native Architecture 142 Components via Services Organized around Business Capabilities Products NOT Projects Smart Endpoints & Dumb Pipes Decentralized Governance & Data Management Infrastructure Automation via IaC Design for Failure Source: US DoD DevSecOps Fundamentals Playbook. Page 6 Layered Architecture Domain Driven Design Capability Centric Design Kafka Messaging / Streams / Connect Data Mesh / K8s / Kafka Clusters Containers / Kubernetes / Mesh Terraform Bulkhead, Circuit Breaker, Green / Blue Deployment Microservices Characteristics Evolutionary Design Epics / User Stories / MVP

@arafkarsh arafkarsh 143 Design Patterns are solutions to general problems that software developers faced during software development. Design Patterns

@arafkarsh arafkarsh 144 Thank you DREAM EMPOWER AUTOMATE MOTIVATE India: +91.999.545.8627 https://arafkarsh.medium.com/ https://speakerdeck.com/arafkarsh https://www.linkedin.com/in/arafkarsh/ https://www.youtube.com/user/arafkarsh/playlists http://www.slideshare.net/arafkarsh http://www.arafkarsh.com/ @arafkarsh arafkarsh LinkedIn arafkarsh.com Medium.com Speakerdeck.com

@arafkarsh arafkarsh 145 Slides: https://speakerdeck.com/arafkarsh Blogs https://arafkarsh.medium.com/ Web: https://arafkarsh.com/ Source: https://github.com/arafkarsh

@arafkarsh arafkarsh 146 Slides: https://speakerdeck.com/arafkarsh

@arafkarsh arafkarsh Backup slides o RESTful APIs o Container Hierarchy o BPF / XDP (eXpress Data Path) o Container Network Interface o References 147

@arafkarsh arafkarsh RESTful APIs • Standards • Api versioning standards 148

@arafkarsh arafkarsh RESTful Guidelines 149 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

@arafkarsh arafkarsh RESTful Guidelines – Query Examples 150 Search All Products Search Products By Catalogue ID Search Products By Catalogue ID & Product ID

@arafkarsh arafkarsh RESTful Guidelines – Query Examples 151 Two different implementation of same query

@arafkarsh arafkarsh 152 # 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

@arafkarsh arafkarsh Restful API Summary 153 o Endpoints as Nouns not VERBS o /catalogues, /orders, /products/category o API Versioning o Use the best suited to your environment o Use all the HTTP Verbs o GET, POST, PUT, DELETE

@arafkarsh arafkarsh Container Images Hierarchy 154 Ubuntu Linux Java 17 Java 21 Tomcat 9 Tomcat 10 My App 1 Tomcat 11 My App 3 SpringBoot 3 My App 4 From Ubuntu Build My Ubuntu From My Ubuntu Build My Java 17 From My Ubuntu Build My Java 21 From My Java 21 Build My SpringBoot 3 From My SpringBoot 3 Build My App 4 From My Java 17 Build My TC9 From My TC9 Build My App 1 My App 2

@arafkarsh arafkarsh Container Images Hierarchy 155 Alpine Linux Java 17 Java 21 Tomcat 9 Tomcat 10 My App 1 Tomcat 11 My App 3 SpringBoot 3 My App 4 From Alpine Build My Alpine From My Alpine Build My Java 17 From My Alpine Build My Java 21 From My Java 21 Build My SpringBoot 3 From My SpringBoot 3 Build My App 4 From My Java 17 Build My TC9 From My TC9 Build My App 1 My App 2

@arafkarsh arafkarsh BPF / XDP (eXpress Data Path) 156 Network Driver Software Stack Network Card BPF Regular BPF (Berkeley Packet Filter) mode Network Driver Software Stack Network 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

@arafkarsh arafkarsh XDP (eXpress Data Path) 157 BPF Program can drop millions packet per second when there is DDoS attack. Network Driver Software Stack Network Card BPF Drop Stack Network Driver Software Stack Network 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

@arafkarsh arafkarsh Kubernetes Container Network Interface 158 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 Kernel On-Premise Ingress Load Balancer Mostly Mostly Yes Yes Yes

@arafkarsh arafkarsh References 159 Microservices 1. Microservices Definition by Martin Fowler 2. When to use Microservices By Martin Fowler 3. GoTo: Sep 3, 2020: When to use Microservices By Martin Fowler 4. GoTo: Feb 26, 2020: Monolith Decomposition Pattern 5. Thought Works: Microservices in a Nutshell 6. Microservices Prerequisites 7. What do you mean by Event Driven? 8. Understanding Event Driven Design Patterns for Microservices

@arafkarsh arafkarsh References – Microservices – Videos 160 1. Martin Fowler – Micro Services : https://www.youtube.com/watch?v=2yko4TbC8cI&feature=youtu.be&t=15m53s 2. GOTO 2016 – Microservices at NetFlix Scale: Principles, Tradeoffs & Lessons Learned. By R Meshenberg 3. Mastering Chaos – A NetFlix Guide to Microservices. By Josh Evans 4. GOTO 2015 – Challenges Implementing Micro Services By Fred George 5. GOTO 2016 – From Monolith to Microservices at Zalando. By Rodrigue Scaefer 6. GOTO 2015 – Microservices @ Spotify. By Kevin Goldsmith 7. Modelling Microservices @ Spotify : https://www.youtube.com/watch?v=7XDA044tl8k 8. GOTO 2015 – DDD & Microservices: At last, Some Boundaries By Eric Evans 9. GOTO 2016 – What I wish I had known before Scaling Uber to 1000 Services. By Matt Ranney 10. DDD Europe – Tackling Complexity in the Heart of Software By Eric Evans, April 11, 2016 11. AWS re:Invent 2016 – From Monolithic to Microservices: Evolving Architecture Patterns. By Emerson L, Gilt D. Chiles 12. AWS 2017 – An overview of designing Microservices based Applications on AWS. By Peter Dalbhanjan 13. GOTO Jun, 2017 – Effective Microservices in a Data Centric World. By Randy Shoup. 14. GOTO July, 2017 – The Seven (more) Deadly Sins of Microservices. By Daniel Bryant 15. Sept, 2017 – Airbnb, From Monolith to Microservices: How to scale your Architecture. By Melanie Cubula 16. GOTO Sept, 2017 – Rethinking Microservices with Stateful Streams. By Ben Stopford. 17. GOTO 2017 – Microservices without Servers. By Glynn Bird.

@arafkarsh arafkarsh References 161 1. Lewis, James, and Martin Fowler. “Microservices: A Definition of This New Architectural Term”, March 25, 2014. 2. Miller, Matt. “Innovate or Die: The Rise of Microservices”. e Wall Street Journal, October 5, 2015. 3. Newman, Sam. Building Microservices. O’Reilly Media, 2015. 4. Alagarasan, Vijay. “Seven Microservices Anti-patterns”, August 24, 2015. 5. Cockcroft, Adrian. “State of the Art in Microservices”, December 4, 2014. 6. Fowler, Martin. “Microservice Prerequisites”, August 28, 2014. 7. Fowler, Martin. “Microservice Tradeoffs”, July 1, 2015. 8. Humble, Jez. “Four Principles of Low-Risk Software Release”, February 16, 2012. 9. Zuul Edge Server, Ketan Gote, May 22, 2017 10. Ribbon, Hysterix using Spring Feign, Ketan Gote, May 22, 2017 11. Eureka Server with Spring Cloud, Ketan Gote, May 22, 2017 12. Apache Kafka, A Distributed Streaming Platform, Ketan Gote, May 20, 2017 13. Functional Reactive Programming, Araf Karsh Hamid, August 7, 2016 14. Enterprise Software Architectures, Araf Karsh Hamid, July 30, 2016 15. Docker and Linux Containers, Araf Karsh Hamid, April 28, 2015