Microservices Migration Strategies

@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 Microservices Monolithic Migration Containers / Kubernetes Infrastructure Design Patterns Building Cloud Native Apps Microservices Architecture Series Part 6 of 15

@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 Slides are color coded based on the
topic colors. Microservices Architecture 1 Monolithic to Microservices Migration 2 Intro to Containers & Kubernetes 3 Infrastructure Design Patterns 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 5

@arafkarsh arafkarsh Package Structure 6 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 Codebase 7 Source: https://github.com/arafkarsh/ms-quickstart

@arafkarsh arafkarsh MICROSERVICES • Concepts • When should you use
microservices? • What’s the right size? • ARCHITECTURE (INFRATRUCTURE AND SOFTWRE) 8 1

@arafkarsh arafkarsh 9 Source: https://cloud.google.com/kubernetes-engine/kubernetes-comic/

@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 10 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 11 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
12 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 13 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 14 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 15 Source:
Page 16 US DoD Enterprise DevSecOps 2.0 Fundamentals

@arafkarsh arafkarsh Pioneers in Microservices Implementation 16 New Entrants

@arafkarsh arafkarsh 17 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 18 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 Microservices definition 19 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 Microservices Characteristics 20 We can scale our operation
independently, maintain unparalleled system availability, and introduce new services quickly without the need for massive reconfiguration. — Werner Vogels, CTO, Amazon Web Services Modularity ... is to a technological economy what the division of labor is to a manufacturing one. W. Brian Arthur, author of e Nature of Technology The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Alan Kay, 1998 email to the Squeak-dev list Components via Services Organized around Business Capabilities Products NOT Projects Smart Endpoints & Dumb Pipes Decentralized Governance & Data Management Infrastructure Automation via IaC Design for Failure Evolutionary Design Source: US DoD DevSecOps Fundamentals Playbook. Page 6

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

@arafkarsh arafkarsh 25 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 26 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 27 Shopping Portal /Web App /Authentication /product /review
API Gateway Nodes Firewall Web App Pod Web App 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

@arafkarsh arafkarsh 28 Shopping Portal /Customer /Shopping Cart /Order Load
Balancer API Gateway Nodes Firewall Order Pod Order Pod Order Pod Order Service N4 N3 MySQL DB Users Payment Pod Payment Pod Payment Service N4 N3 Cart Pod Cart Pod Cart Pod Cart Service N1 N2 N2 Redis DB Services will process requests only if the token is valid External Payment Service Routing based on Layer 3 (IP), 4 (TCP) and 7 ((HTTP) Customer Pod Customer Pod Customer Service N1 N2 Redis DB

@arafkarsh arafkarsh Software Network Stack Vs Network Stack 29 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 30 Source: https://cloud.google.com/kubernetes-engine/kubernetes-comic/ Each one of the Microservices
can now be • Debugged, • Updated, and • Deployed individually without the whole Project coming to a standstill. An important step on the path to • Continuous Integration and • Continuous Delivery.

@arafkarsh arafkarsh Scale Cube and Microservices 33 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 34 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 35 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 Catalogues of Microservices 36 System Z Model From
Spotify • Different types of Components Z Supports • Libraries • Data Pipelines • Views in the client • Data Store • Service

@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). 37 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 Monolithic > Microservices • Forrester Research • Modernization
journey • Assess and classify your app portfolio • Plan and prioritize 38 2

@arafkarsh arafkarsh Conway’s Law 39 Any Organization that designs a
system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

@arafkarsh arafkarsh * For IT Services : They can do
one more project of same size with ZERO COST in Platform Licensing (Based on 20 developer pack USD $50K per month for 3 months License cost = $150K) 40

@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] Development QA / QC Ops 41 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 Modernization Journey 42 ✓ 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 43 ✓
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 44 ❑ 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 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 45 • 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
46 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 47 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
48 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 49 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 50 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 51 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 52 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 53 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 54 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 55 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 56 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
57 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 58 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 59 /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 Canary 50% = v1 50% = v2 Scenario 3 A/B Testing 0% = v1 100% = v2 Scenario 4 Blue Green

@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 60 • 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 61 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 Discovering Microservices Principles…. 62 Components via Services Organized
around Business Capabilities Products NOT Projects Smart Endpoints & Dumb Pipes Decentralized Governance & Data Management Infrastructure Automation Design for Failure Evolutionary Design What did we Learn Today?

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

@arafkarsh arafkarsh RESTful Guidelines 65 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 66 Search All
Products Search Products By Catalogue ID Search Products By Catalogue ID & Product ID

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

@arafkarsh arafkarsh 68 # 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 69 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 Containers & Kubernetes • Docker containers • Kubernetes
– container orchestration • ISTIO – Traffic management / network policies 70 3

@arafkarsh arafkarsh 71 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 What’s a Container? 72 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 Docker containers are Linux Containers CGROUPS NAME SPACES
Copy on Write DOCKER CONTAINER 73 • 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 74 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 75 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 Docker Images in the Github Workshop 76 Ubuntu
JRE 8 JRE 11 Tomcat 8 Tomcat 9 My App 1 Tomcat 9 My App 3 Spring Boot My App 4 From Ubuntu Build My Ubuntu From My Ubuntu Build My JRE8 From My Ubuntu Build My JRE11 From My JRE 11 Build My Boot From My Boot Build My App 4 From My JRE8 Build My TC8 From My TC8 Build My App 1 My App 2 Source: https://github.com/meta-magic/kubernetes_workshop

@arafkarsh arafkarsh CRI Daemon CRI Client How Container Works…. 77
$ 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 Kubernetes Key Concepts 78 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 79 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 80 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 81 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 82 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 83 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 Deployment Models: Kubernetes Gateway API 84 /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 85 /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 86 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 86 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 # 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 87            

@arafkarsh arafkarsh Kubernetes Gateway API Vs Istio 88 Feature Gateway
API Istio Traffic Mirroring Supported Advanced Traffic Splitting Supported Advanced Circuit Breaking Not supported Fully supported Advanced Fault Injection Limited Supports conditional injection mTLS & Security Limited Fully supported       

@arafkarsh arafkarsh K8s Network Policies L3/L4 89 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 90 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 91 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 BPF / XDP (eXpress Data Path) 92 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) 93 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 94 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 Container & Kubernetes Summary 95 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 Infrastructure Design Patterns • API Gateway • Load
balancer • Service discovery • Circuit breaker • Service Aggregator • Let-it crash pattern 98 4

@arafkarsh arafkarsh API Gateway Design Pattern – Software Stack 99
UI Layer WS BL DL Database Shopping Cart Order Customer Product Firewall Users API Gateway Load Balancer Circuit Breaker UI Layer Web Services Business Logic Database Layer Product SE MySQL DB Product Microservice With 4 node cluster Load Balancer Circuit Breaker UI Layer Web Services Business Logic Database Layer Customer Redis DB Customer Microservice With 2 node cluster Users Access the Monolithic App Directly API Gateway (Reverse Proxy Server) routes the traffic to appropriate Microservices (Load Balancers)

@arafkarsh arafkarsh API Gateway – Kubernetes Implementation 100 /customer /product
/cart /order API Gateway Ingress Deployment / Replica / Pod Nodes Kubernetes Objects Firewall Customer Pod Customer Pod Customer Pod Customer Service N1 N2 N2 EndPoints Product Pod Product Pod Product Pod Product Service N4 N3 MySQL DB EndPoints Review Pod Review Pod Review Pod Review Service N4 N3 N1 Service Call Kube DNS EndPoints Internal Load Balancers Users Routing based on Layer 3,4 and 7 Redis DB Mongo DB Load Balancer

@arafkarsh arafkarsh 101 API Gateway – Kubernetes / Istio /customer
/product /auth /order API Gateway Virtual Service Deployment / Replica / Pod Nodes Load Balancer Firewall P M C 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 101 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

@arafkarsh arafkarsh Load Balancer Design Pattern 102 Firewall Users API
Gateway Load Balancer Circuit Breaker UI Layer Web Services Business Logic Database Layer Product SE MySQL DB Product Microservice With 4 node cluster Load Balancer CB = Hystrix UI Layer Web Services Business Logic Database Layer Customer Redis DB Customer Microservice With 2 node cluster API Gateway (Reverse Proxy Server) routes the traffic to appropriate Microservices (Load Balancers) Load Balancer Rules 1. Round Robin 2. Based on Availability 3. Based on Response Time

@arafkarsh arafkarsh Ingress Load Balancer – Kubernetes Model 103 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 Service Discovery – NetFlix Network Stack Model 104
Firewall Users API Gateway Load Balancer Circuit Breaker Product MySQL DB Product Microservice With 4 node cluster Load Balancer Circuit Breaker UI Layer Web Services Business Logic Database Layer Customer Redis DB Customer Microservice With 2 node cluster • In this model Developers write the code in every Microservice to register with NetFlix Eureka Service Discovery Server. • Load Balancers and API Gateway also registers with Service Discovery. • Service Discovery will inform the Load Balancers about the instance details (IP Addresses). Service Discovery

@arafkarsh arafkarsh Ingress Service Discovery – Kubernetes Model 105 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 106 /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 107 /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 108 Play Count Discography Albums

@arafkarsh arafkarsh Service Aggregator Pattern 109 /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 Config Store – Spring Config Server 110 Firewall
Users API Gateway Load Balancer Circuit Breaker Product MySQL DB Product Microservice With 4 node cluster Load Balancer Circuit Breaker UI Layer Web Services Business Logic Database Layer Customer Redis DB Customer Microservice With 2 node cluster • In this model Developers write the code in every Microservice to download the required configuration from a Central server (Ex. Spring Config Server for the Java World). • This creates an explicit dependency order in which service to come up will be critical. Config Server

@arafkarsh arafkarsh Service Mesh – Sidecar Design Pattern 111 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 Shopping Portal 112 /ui /productms /auth /order Gateway
Virtual Service Deployment / Replica / Pod Nodes Load Balancer Kubernetes Objects Firewall P M C 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 Istio Sidecar - Envoy Istio Objects

@arafkarsh arafkarsh Let-it-Crash Design Pattern – Erlang Philosophy 113 •
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 114 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 115 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 116 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 119 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 120 Design Patterns are solutions to general problems
that software developers faced during software development. Design Patterns

@arafkarsh arafkarsh 121 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

@arafkarsh arafkarsh 122 Source: https://github.com/arafkarsh Web: https://arafkarsh.com/ Slides: https://speakerdeck.com/arafkarsh

@arafkarsh arafkarsh 123 http://www.slideshare.net/arafkarsh

@arafkarsh arafkarsh References 124 1. July 15, 2015 – Agile
is Dead : GoTo 2015 By Dave Thomas 2. Apr 7, 2016 - Agile Project Management with Kanban | Eric Brechner | Talks at Google 3. Sep 27, 2017 - Scrum vs Kanban - Two Agile Teams Go Head-to-Head 4. Feb 17, 2019 - Lean vs Agile vs Design Thinking 5. Dec 17, 2020 - Scrum vs Kanban | Differences & Similarities Between Scrum & Kanban 6. Feb 24, 2021 - Agile Methodology Tutorial for Beginners | Jira Tutorial | Agile Methodology Explained. Agile Methodologies

@arafkarsh arafkarsh References 125 1. Vmware: What is Cloud Architecture?
2. Redhat: What is Cloud Architecture? 3. Cloud Computing Architecture 4. Cloud Adoption Essentials: 5. Google: Hybrid and Multi Cloud 6. IBM: Hybrid Cloud Architecture Intro 7. IBM: Hybrid Cloud Architecture: Part 1 8. IBM: Hybrid Cloud Architecture: Part 2 9. Cloud Computing Basics: IaaS, PaaS, SaaS 1. IBM: IaaS Explained 2. IBM: PaaS Explained 3. IBM: SaaS Explained 4. IBM: FaaS Explained 5. IBM: What is Hypervisor? Cloud Architecture

@arafkarsh arafkarsh References 126 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 127 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 128 Domain Driven Design 1. Oct 27,
2012 What I have learned about DDD Since the book. By Eric Evans 2. Mar 19, 2013 Domain Driven Design By Eric Evans 3. Jun 02, 2015 Applied DDD in Java EE 7 and Open Source World 4. Aug 23, 2016 Domain Driven Design the Good Parts By Jimmy Bogard 5. Sep 22, 2016 GOTO 2015 – DDD & REST Domain Driven API’s for the Web. By Oliver Gierke 6. Jan 24, 2017 Spring Developer – Developing Micro Services with Aggregates. By Chris Richardson 7. May 17. 2017 DEVOXX – The Art of Discovering Bounded Contexts. By Nick Tune 8. Dec 21, 2019 What is DDD - Eric Evans - DDD Europe 2019. By Eric Evans 9. Oct 2, 2020 - Bounded Contexts - Eric Evans - DDD Europe 2020. By. Eric Evans 10. Oct 2, 2020 - DDD By Example - Paul Rayner - DDD Europe 2020. By Paul Rayner

@arafkarsh arafkarsh References 129 Event Sourcing and CQRS 1. IBM:
Event Driven Architecture – Mar 21, 2021 2. Martin Fowler: Event Driven Architecture – GOTO 2017 3. Greg Young: A Decade of DDD, Event Sourcing & CQRS – April 11, 2016 4. Nov 13, 2014 GOTO 2014 – Event Sourcing. By Greg Young 5. Mar 22, 2016 Building Micro Services with Event Sourcing and CQRS 6. Apr 15, 2016 YOW! Nights – Event Sourcing. By Martin Fowler 7. May 08, 2017 When Micro Services Meet Event Sourcing. By Vinicius Gomes

@arafkarsh arafkarsh References 130 Kafka 1. Understanding Kafka 2. Understanding
RabbitMQ 3. IBM: Apache Kafka – Sept 18, 2020 4. Confluent: Apache Kafka Fundamentals – April 25, 2020 5. Confluent: How Kafka Works – Aug 25, 2020 6. Confluent: How to integrate Kafka into your environment – Aug 25, 2020 7. Kafka Streams – Sept 4, 2021 8. Kafka: Processing Streaming Data with KSQL – Jul 16, 2018 9. Kafka: Processing Streaming Data with KSQL – Nov 28, 2019

@arafkarsh arafkarsh References 131 Databases: Big Data / Cloud Databases
1. Google: How to Choose the right database? 2. AWS: Choosing the right Database 3. IBM: NoSQL Vs. SQL 4. A Guide to NoSQL Databases 5. How does NoSQL Databases Work? 6. What is Better? SQL or NoSQL? 7. What is DBaaS? 8. NoSQL Concepts 9. Key Value Databases 10. Document Databases 11. Jun 29, 2012 – Google I/O 2012 - SQL vs NoSQL: Battle of the Backends 12. Feb 19, 2013 - Introduction to NoSQL • Martin Fowler • GOTO 2012 13. Jul 25, 2018 - SQL vs NoSQL or MySQL vs MongoDB 14. Oct 30, 2020 - Column vs Row Oriented Databases Explained 15. Dec 9, 2020 - How do NoSQL databases work? Simply Explained! 1. Graph Databases 2. Column Databases 3. Row Vs. Column Oriented Databases 4. Database Indexing Explained 5. MongoDB Indexing 6. AWS: DynamoDB Global Indexing 7. AWS: DynamoDB Local Indexing 8. Google Cloud Spanner 9. AWS: DynamoDB Design Patterns 10. Cloud Provider Database Comparisons 11. CockroachDB: When to use a Cloud DB?

@arafkarsh arafkarsh References 132 Docker / Kubernetes / Istio 1.
IBM: Virtual Machines and Containers 2. IBM: What is a Hypervisor? 3. IBM: Docker Vs. Kubernetes 4. IBM: Containerization Explained 5. IBM: Kubernetes Explained 6. IBM: Kubernetes Ingress in 5 Minutes 7. Microsoft: How Service Mesh works in Kubernetes 8. IBM: Istio Service Mesh Explained 9. IBM: Kubernetes and OpenShift 10. IBM: Kubernetes Operators 11. 10 Consideration for Kubernetes Deployments Istio – Metrics 1. Istio – Metrics 2. Monitoring Istio Mesh with Grafana 3. Visualize your Istio Service Mesh 4. Security and Monitoring with Istio 5. Observing Services using Prometheus, Grafana, Kiali 6. Istio Cookbook: Kiali Recipe 7. Kubernetes: Open Telemetry 8. Open Telemetry 9. How Prometheus works 10. IBM: Observability vs. Monitoring

@arafkarsh arafkarsh References 133 1. Feb 6, 2020 – An
introduction to TDD 2. Aug 14, 2019 – Component Software Testing 3. May 30, 2020 – What is Component Testing? 4. Apr 23, 2013 – Component Test By Martin Fowler 5. Jan 12, 2011 – Contract Testing By Martin Fowler 6. Jan 16, 2018 – Integration Testing By Martin Fowler 7. Testing Strategies in Microservices Architecture 8. Practical Test Pyramid By Ham Vocke Testing – TDD / BDD

@arafkarsh arafkarsh 134 1. Simoorg : LinkedIn’s own failure inducer
framework. It was designed to be easy to extend and most of the important components are plug‐ gable. 2. Pumba : A chaos testing and network emulation tool for Docker. 3. Chaos Lemur : Self-hostable application to randomly destroy virtual machines in a BOSH- managed environment, as an aid to resilience testing of high-availability systems. 4. Chaos Lambda : Randomly terminate AWS ASG instances during business hours. 5. Blockade : Docker-based utility for testing network failures and partitions in distributed applications. 6. Chaos-http-proxy : Introduces failures into HTTP requests via a proxy server. 7. Monkey-ops : Monkey-Ops is a simple service implemented in Go, which is deployed into an OpenShift V3.X and generates some chaos within it. Monkey-Ops seeks some OpenShift components like Pods or Deployment Configs and randomly terminates them. 8. Chaos Dingo : Chaos Dingo currently supports performing operations on Azure VMs and VMSS deployed to an Azure Resource Manager-based resource group. 9. Tugbot : Testing in Production (TiP) framework for Docker. Testing tools

@arafkarsh arafkarsh References 135 CI / CD 1. What is
Continuous Integration? 2. What is Continuous Delivery? 3. CI / CD Pipeline 4. What is CI / CD Pipeline? 5. CI / CD Explained 6. CI / CD Pipeline using Java Example Part 1 7. CI / CD Pipeline using Ansible Part 2 8. Declarative Pipeline vs Scripted Pipeline 9. Complete Jenkins Pipeline Tutorial 10. Common Pipeline Mistakes 11. CI / CD for a Docker Application

@arafkarsh arafkarsh References 136 DevOps 1. IBM: What is DevOps?
2. IBM: Cloud Native DevOps Explained 3. IBM: Application Transformation 4. IBM: Virtualization Explained 5. What is DevOps? Easy Way 6. DevOps?! How to become a DevOps Engineer??? 7. Amazon: https://www.youtube.com/watch?v=mBU3AJ3j1rg 8. NetFlix: https://www.youtube.com/watch?v=UTKIT6STSVM 9. DevOps and SRE: https://www.youtube.com/watch?v=uTEL8Ff1Zvk 10. SLI, SLO, SLA : https://www.youtube.com/watch?v=tEylFyxbDLE 11. DevOps and SRE : Risks and Budgets : https://www.youtube.com/watch?v=y2ILKr8kCJU 12. SRE @ Google: https://www.youtube.com/watch?v=d2wn_E1jxn4

@arafkarsh arafkarsh References 137 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

@arafkarsh arafkarsh References 138 16. MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx 17.
Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html 18. Udi Dahan : CQRS – http://www.udidahan.com/2009/12/09/clarified-cqrs/ 19. Greg Young : CQRS - https://www.youtube.com/watch?v=JHGkaShoyNs 20. Bertrand Meyer – CQS - http://en.wikipedia.org/wiki/Bertrand_Meyer 21. CQS : http://en.wikipedia.org/wiki/Command–query_separation 22. CAP Theorem : http://en.wikipedia.org/wiki/CAP_theorem 23. CAP Theorem : http://www.julianbrowne.com/article/viewer/brewers-cap-theorem 24. CAP 12 years how the rules have changed 25. EBay Scalability Best Practices : http://www.infoq.com/articles/ebay-scalability-best-practices 26. Pat Helland (Amazon) : Life beyond distributed transactions 27. Stanford University: Rx https://www.youtube.com/watch?v=y9xudo3C1Cw 28. Princeton University: SAGAS (1987) Hector Garcia Molina / Kenneth Salem 29. Rx Observable : https://dzone.com/articles/using-rx-java-observable

Microservices Migration Strategies

Microservices Migration Strategies

More Decks by Araf Karsh Hamid

Other Decks in Technology

Featured

Transcript