@arafkarsh arafkarsh Architecting & Building Apps a tech presentorial Combination of presentation & tutorial AI / ML Generative AI LLMs, RAG 6+ Years Microservices Blockchain 8 Years Cloud Computing 8 Years Network & Security 8 Years Distributed Computing ARAF KARSH HAMID Co-Founder / CTO MetaMagic Global Inc., NJ, USA @arafkarsh arafkarsh DevOps? USER STORIES / AGILE ARCHITECTURE & DESIGN TESTING AUTOMATION SITE RELIABILITY ENGINEERING DEVSECOPS PLAYBOOK Why do we need 

@arafkarsh arafkarsh 2 No, Cloud Native Architecture is not mandatory for DevOps, but it complements and enhances DevOps practices. Here's how: DevOps Without Cloud Native: 1. You can implement DevOps in traditional or on- premise environments. 2. Tools like Jenkins, GitLab CI/CD, Ansible, and Puppet work well even without cloud-native technologies. 3. The core principles of CI/CD, collaboration, and automation can be applied to any infrastructure. 1. Scan the QR Code to see the complete ChatGPT Conversation 2. Click the “Open QR Code” grey button Is Cloud Native Architecture Mandatory for DevOps? 

@arafkarsh arafkarsh Development & Operations 3 Development Team Agility Operations Team Stability Developers Keep throwing releases over the wall and get pushed back by the operations team. Silo 2 Silo 1 Silo 1.1 Silo 1.2 Silo 1.3 

@arafkarsh arafkarsh DevOps 4 DevOps isn’t simply a process or a different approach to development — it’s a culture change. And a major part of a DevOps culture is collaboration. Source: https://www.atlassian.com/devops/what-is-devops/history-of-devops Patrick Debois Andrew C Shafer Coined the Term in 2009 DevOps 

@arafkarsh arafkarsh DevSecOps 5 DevSecOps is a culture and philosophy that must be practiced across the organization, realized through the unification of a set of Software development (Dev), Security (Sec) and Operations (Ops) personnel into a singular team. Source: Page 17. US DoD Enterprise DevSecOps 2.0 Fundamentals 

@arafkarsh arafkarsh 6 Benefits of Cloud Native for DevOps: • Scalability: Cloud-native platforms (e.g., Kubernetes) provide dynamic scaling, which aligns with DevOps goals of handling demand efficiently. • Resilience: Microservices architecture and containerization improve fault tolerance, simplifying deployments. • Speed: Cloud-native environments reduce the time to provision resources, enabling faster iterations. • Observability: Tools like Prometheus and Grafana, often used in cloud-native systems, provide real-time monitoring for DevOps teams. Trade-offs Without Cloud Native: • Traditional monolithic systems might face challenges like slower deployments and less flexibility. • Manual provisioning of infrastructure can slow down CI/CD pipelines. 1. Scan the QR Code to see the complete ChatGPT Conversation 2. Click the “Open QR Code” grey button 

@arafkarsh arafkarsh 7 FIRST Conclusion: o While DevOps doesn't mandate cloud- native architecture, the two are highly synergistic. o Cloud-native principles like microservices, containers, and orchestration are designed to support agile, iterative development and deployment, which are central to DevOps. o However, the fundamental practices of DevOps can be implemented regardless of the underlying infrastructure. F 1. Scan the QR Code to see the complete ChatGPT Conversation 2. Click the “Open QR Code” grey button 

@arafkarsh arafkarsh 8 LAST Conclusion: o While modularization in a monolithic architecture can help to some extent, without independent repositories, code-level isolation, and deployable artifacts, the challenges of tight coupling and regression testing make true continuous delivery difficult. o For long-term scalability and faster incremental delivery, adopting Cloud Native Architecture patterns (e.g., microservices, containers, orchestration) becomes necessary. o In short: You can start with modularization, but for true independence and continuous delivery at scale, a transition to Cloud Native patterns is almost inevitable. L 1. Scan the QR Code to see the complete ChatGPT Conversation 2. Click the “Open QR Code” grey button 

@arafkarsh arafkarsh 9 Moral of the Story Your perspectives can change when you analyze more data (including ChatGPT) In short: You can start with modularization, but for true independence and continuous delivery at scale, a transition to Cloud Native patterns is almost inevitable. No, Cloud Native Architecture is not mandatory for DevOps, but it complements and enhances DevOps practices. Is Cloud Native Architecture Mandatory for DevOps? In the beginning Last Conclusion 1. Scan the QR Code to see the complete ChatGPT Conversation 2. Click the “Open QR Code” grey button 

@arafkarsh arafkarsh Management Pipeline Automation Design / Develop SpecOps Workflow - SDLC 10 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 • Containers • Orchestration • Serverless • Traffic Routing • Security (mTLS, JWT) • Policies (Network / Security • Observability Infra Code • Feature Code • Configs Source Code Specs 

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

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

@arafkarsh arafkarsh DevOps Best Practices o Shift Left – CI/CD Automation o Infrastructure as a Code o Stages of DevOps Delivery Pipeline o Observability 13 

@arafkarsh arafkarsh CALMS Framework 14 CALMS is both a framework for evaluating an organization’s readiness to adopt DevOps practices and a lens for measuring progress throughout a DevOps transformation. The term, coined by Jez Humble—co-author of The DevOps Handbook—represents five key pillars: Jez Humble Culture, Automation, Lean, Measurement, Sharing. ChatGPT Explanation on CALMS Framework 

@arafkarsh arafkarsh 15 Source: https://cloud.google.com/resources/devops/state-of-devops DORA – DevOps Research & Assessment 

@arafkarsh arafkarsh 16 Our Goal Source: https://cloud.google.com/resources/devops/state-of-devops 

@arafkarsh arafkarsh How CALMS and DORA Relates 17 Aspect CALMS Framework DORA (DevOps Research & Assessment) Origin Coined by Jez Humble (co-author of The DevOps Handbook) Research by Nicole Forsgren, Jez Humble, Gene Kim, later at Google Cloud Purpose A holistic framework to assess DevOps adoption across people, process, and tech A data-driven measurement system to evaluate software delivery performance Focus Philosophy, culture, and practices Hard performance outcomes (metrics) Key Dimensions Culture, Automation, Lean, Measurement, Sharing 4 Metrics: Deployment Frequency, Lead Time, MTTR, Change Failure Rate Measurement Style Qualitative maturity model (e.g., “How collaborative is our culture?”) Quantitative metrics (numbers and benchmarks) Scope Broad (people, process, tech, organizational behavior) Narrow and precise (delivery performance & reliability) Usage Used as a lens for transformation and maturity assessments Used as a benchmark and to track improvements over time Analogy Like a compass: tells you if you’re moving in the right direction Like a fitness tracker: shows your vital signs and performance benchmarks 

@arafkarsh arafkarsh DevOps Adoption Journey – CALMS + DORA 18 o Vision & Awareness (CALMS as Compass) o Build shared understanding: Culture, Automation, Lean, Measurement, Sharing. o Assessment & Baseline o Use CALMS to spot strengths/weaknesses. o Capture baseline DORA metrics (Deployments, Lead Time, MTTR, Failure Rate). o Targeted Improvements o Drive culture change, automate pipelines, adopt lean practices. o Validate progress via DORA metrics. o Continuous Feedback o Shorten feedback loops with monitoring, postmortems, and shared learnings. o Scaling & Embedding o Spread DevOps practices across teams and products. o Reinforce CALMS as cultural DNA. o Benchmarking Performance (DORA as Scoreboard) o Compare against Elite/High/Medium/Low benchmarks. o Use metrics to sustain long-term excellence. 

@arafkarsh arafkarsh 5 DevOps Principles – CALMS Framework 19 Source: https://www.atlassian.com/devops/frameworks/calms-framework DevOps isn’t a process, or a different approach to development. It’s a culture change. DevOps culture is collaboration. Build, Test, Deploy, and Provisioning automation are typical starting points for teams. Another major contribution of DevOps is “configuration as code.” Developers strive to create modular, composable applications because they are more reliable and maintainable. CULTURE AUTOMATION LEAN MEASUREMENT SHARING Continuous Improvement with Canary Releases and A/B Testing Continuous Improvement requires Data to measure the changes Sharing responsibility, success, failure goes a long way toward bridging that divide between Dev and Ops. You built it, You run it. 

@arafkarsh arafkarsh Implementing CALMS – DevOps Principles 20 Capability Centric Design Reduce Organization Silos CULTURE Leverage Tooling & Automation Tests, CI/CD Pipeline & Container Orchestration AUTOMATION Implement Gradual Change Microservices Architecture & Agile: Kanban LEAN Measure Everything Service Mesh: Observability MEASUREMENT Accept Failure as Normal Design for Failure SHARING ✓ Share Ownership ✓ SLOs & Blameless PM ✓ Canary Deployment, A/B Testing ✓ Automate this years Job ✓ Measure toil & reliability Source: https://www.atlassian.com/devops/frameworks/calms-framework 

@arafkarsh arafkarsh Culture: Business Capability Centric Design 21 Business Centric Development • Focus on Business Capabilities • Entire team is aligned towards Business Capability. • From Specs to Operations – The team handles the entire spectrum of Software development. • Every vertical will have its own Code Pipeline, Build Pipeline Front-End-Team Back-End-Team Database-Team In a typical Monolithic way, the team is divided based on technology/skill set rather than business functions, leading to bottlenecks and a lack of understanding of the Business Domain. QA Team QA = Quality Assurance PO = Product Owner Vertically sliced Product Team Front-End Back-End Database Business Capability 1 QA PO Ops Front-End Back-End Database Business Capability 2 QA PO Ops Front-End Back-End Database Business Capability - n QA PO Ops 

@arafkarsh arafkarsh Culture: From Project Based Activity Oriented To Product Based Outcome Oriented Source: Sriram Narayan– https://martinfowler.com/bliki/BusinessCapabilityCentric.html 22 Traditional corporate IT organizations operate in an activity-oriented manner where they fund projects with set time-spans. Organizations that are outcome-oriented align better with business outcomes, but project-based funding undermines long- term effectiveness. Basing funding on products centered around long-term business capabilities creates stable teams that are aligned with business needs. Outcome-oriented thinking compels business capability centered organizations to consider more than just delivering the scope, which is where we want to be. Project based Product based Activity Oriented Outcome Oriented Business Capability Centric 

@arafkarsh arafkarsh Production Environment Continuous Monitoring Fully Automated Continuous Deployment Automation: Shift Left – Operational Concerns 23 • Operations Concerns move earlier in software delivery life cycle, towards development. • The Goal is to enable Developers and QC Team to Develop and Test the software that behave like Production System in fully automated way. Development Environment Build Build Build Test Environment Continuous Integration Unit Testing Component Testing Contract Testing Integration Testing Continuous Testing Shift Left moves operations earlier in development cycle. Stage Environment Acceptance Testing Pull Request / Merge Continuous Delivery GitOps – CD/CD 

@arafkarsh arafkarsh Automation: Test Automation Tools 24 Testing Tools Contract Testing Scope Integration Testing Verifies the communication paths and interactions between components to detect interface defects Contract Testing It is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service. Payment Mock Integration Contract Testing Scope Test Double Montebank Cart Component Testing Unit Testing Integration Testing Scope Order REST / HTTP or Events / Kafka Item ID, Quantity, Address.. Mock Order Component Testing A component test limits the scope of the exercised software to a portion of the system under test. Order Payment Unit Testing Firewall Integration Testing Scope REST / HTTP Payment Sandbox Component Testing U 

@arafkarsh arafkarsh Automation: Infrastructure as a Code 25 • Infrastructure as a Code is a critical capability for DevOps • This helps the organizations to establish a fully automated pipeline for Continuous Delivery. • Infra as a Code is a software defined environment to manage the following: • Network Topologies, Roles, Relationship, Network Policies • Deployment Models, Workloads, Workload Policies & Behaviors. • Autoscaling (up & down) of the workloads 

@arafkarsh arafkarsh Automation: Stages of DevOps Pipeline 26 Build Design Develop Test Deploy Ops Specs Agile DevOps Go Live Support Specs / Design / Development CI/CD and Tests Automation Operations 

@arafkarsh arafkarsh 27 Lean: /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, 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 Generates Token (JWT) “A/B Testing and Canary Deployment are complementary practices: Canary Deployment ensures stability and performance, while A/B Testing optimizes user experience and effectiveness.” 

@arafkarsh arafkarsh Lean: Deployment Models: Kubernetes Gateway API 28 /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 Measure: Pillars of Observability 29 Immutable records of discrete events that happen over time Logs/events Numbers describing a particular process or activity measured over intervals of time Metrics Data that shows, for each invocation of each downstream service, which instance was called, which method within that instance was invoked, how the request performed, and what the results were Traces Source: A Beginners guide to Observability by Splunk 

@arafkarsh arafkarsh Share: Full Stack Teams 30 QA = Quality Assurance PO = Product Owner Vertically sliced Product Team Front-End Back-End Database Business Capability 1 QA PO Ops Front-End Back-End Database Business Capability 2 QA PO Ops Front-End Back-End Database Business Capability - n QA PO Ops • Breaking Silos: Collaboration between Development and Operations eliminates traditional barriers, encouraging shared ownership of responsibilities. • Philosophy of Accountability: Netflix’s “You Build It, You Run It” embodies the principle of shared accountability, ensuring teams are responsible for their code in production. • Blameless Culture: Failures are not treated as opportunities for blame but as learning moments, fostering trust and resilience. • Acceptance of Failure: Recognizing that failures are inevitable in complex distributed systems shifts focus to recovery rather than avoidance. • Emphasis on Rapid Recovery: The priority is on minimizing downtime and ensuring swift resolution when issues arise, reflecting a culture of continuous improvement. 

@arafkarsh arafkarsh Key Takeaways 31 o CALMS is the North Star: guiding what to change. o DORA is the scoreboard: proving if change works. 

@arafkarsh arafkarsh DevSecOps Playbook 32 

@arafkarsh arafkarsh DevSecOps 33 DevSecOps is a culture and philosophy that must be practiced across the organization, realized through the unification of a set of Software development (Dev), Security (Sec) and Operations (Ops) personnel into a singular team. Source: Page 17. US DoD Enterprise DevSecOps 2.0 Fundamentals 

@arafkarsh arafkarsh DevSecOps 34 Source: https://www.atlassian.com/devops/devops-tools/devsecops-tools 

@arafkarsh arafkarsh 6 DevSecOps Playbook 35 1 Adopt a DevSecOps Culture 2 Adopt Infrastructure as Code 3 Adopt Containerized Microservices 4 Adopt a Capability Model, not a Maturity Model 5 Drive Continuous Improvement through Key Capabilities Establish a Software Factory 7 Define a meaningful DevSecOps pipeline 8 Adapt an Agile Acquisition Policy for Software 9 Tirelessly Pursue Cyber Resilience 10 Shift Left: Operational Test & Eval Source: US DoD DevSecOps Fundamentals Playbook 

@arafkarsh arafkarsh Adopt a DevSecOps Culture 36 1 Key Cultural Practices 1. Stakeholder transparency and visibility. 2. Complete transparency across team members in real- time. 3. All project resources easily accessible to the entire team; not everyone needs commit privileges. 4. Adopt and embrace ChatOps as the communication backbone for the DevSecOps team. 5. All technical staff should be concerned with, and have a say in, baked-in security. Source: US DoD DevSecOps Fundamentals Playbook. Page 4 

@arafkarsh arafkarsh Adopt Infrastructure as Code 37 2 Key Advantages 1. IT infrastructure supports and enables change, rather than being an obstacle or a constraint. 2. Mitigates drift between environments by leveraging automation and push- button deployment. 3. Enforces change management through GitOps with multiple approvers, as needed. 4. Environmental changes are routine and fully automated, pivoting staff to focus on other tasks. 5. Quicker recovery from failures, rather than assuming failure can be completely prevented. 6. Empowers a continuous improvement ecosystem rather than “big bang” one and done activities. Source: US DoD DevSecOps Fundamentals Playbook. Page 5 

@arafkarsh arafkarsh 38 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 Layered Architecture Domain Driven Design Capability Centric Design Kafka Messaging / Streams / Connect Epics / User Stories / MVP Data Mesh / K8s/Kafka Clusters / Infra Patterns Containers / Kubernetes / Mesh Terraform Bulkhead, Circuit Breaker, Green / Blue Deployment Microservices Characteristics / Cloud Native Architecture Adopt Containerized Microservices 3 

@arafkarsh arafkarsh Adopt a Capability Model, not a Maturity Model 39 Feature Capability Model Maturity Model Focus Describes what can be done (capabilities). Describes how well it is done (performance). Purpose Define or build functional capabilities. Assess and improve process performance. Outcome Roadmap for capability implementation. Evolutionary progression through levels. Example ITSM processes in place. CMMI levels achieved in those processes. 4 Source: US DoD DevSecOps Fundamentals Playbook. Page 7 Google’s DORA research program advocates that rather than use a maturity model, research shows that a capability model is a better way to both encourage and measure performance improvement • Capabilities: • Incident Management • Problem Management • Change Management • Release Management • Goal: Define the necessary processes and tools to establish effective service delivery. • Maturity Levels: • Level 1: Initial (ad hoc, chaotic) • Level 2: Managed (basic project management) • Level 3: Defined (standardized processes) • Level 4: Quantitatively Managed (metrics-driven) • Level 5: Optimizing (continuous improvement) • Goal: Assess and improve the maturity of their software development processes. 

@arafkarsh arafkarsh Drive Continuous Improvement through Key Capabilities 40 5 Source: US DoD DevSecOps Fundamentals Playbook. Page 8 Architecture 1. Use Loosely Coupled Architecture 2. Architect for Empowered Teams Culture 1. Adopt a Likert scale survey to measure cultural change progress 2. Encourage and support continuous learning initiatives 3. Support and Facilitate Collaboration among and between teams 4. Provide resources and tools that make work meaningful 5. Support or Embody transformational leadership 24 There are 24 Key that drive improvements across both DevSecOps and the Organization 5 Classified into 5 Categories 1. Culture 2. Architecture 3. Product & Process 4. Continuous Delivery 5. Lean Management & Monitoring 

@arafkarsh arafkarsh Drive Continuous Improvement through Key Capabilities 41 5 Continuous Delivery 1. Use a Source Code Repo for all production Artifacts 2. Use Trunk based development methods 3. Shift Left on Security 4. Implement Test Automation 5. Implement Continuous Integration 6. Support Test Data Management 7. Implement Continuous Delivery 8. Automate the Deployment Process Source: US DoD DevSecOps Fundamentals Playbook. Page 8 Product and Process 1. Gather and Implement Customer Feedback 2. Make the flow of work visible through the value stream 3. Work in small batches 4. Foster and enable team experimentation Lean Management & Monitoring 1. Have a lightweight change approval process 2. Monitor across applications & infrastructure too inform business decisions 3. Check System Health periodically 4. Improve Processes and Manage work with WIP 5. Visualize work to Monitor quality and communicate throughout 

@arafkarsh arafkarsh Establish a Software Factory 42 6 Source: US DoD DevSecOps Fundamentals Playbook. Page 9 • Define CI/CD Processes and Tasks • Select Tools • Operate & Maintain the Software Factory • Monitor the Tools and Processes • Gather Feedback for Improvement • Build the Software Factory • Automate the Workflows • Verify the Tool Integrations • Test the Pipeline Workflows 

@arafkarsh arafkarsh Define a meaningful DevSecOps pipeline 43 7 Source: US DoD DevSecOps Fundamentals Playbook. Page 10 

@arafkarsh arafkarsh Adapt an Agile Acquisition Policy for Software 44 8 • Establishes the Software Acquisition Pathway as the preferred path for acquisition and development of software-intensive systems. • Simplifies the acquisition model to enable continuous integration and delivery of software capability on timelines relevant to the warfighter / end user. • Establishes business decision artifacts to manage risk and enable successful software acquisition and development. Source: US DoD DevSecOps Fundamentals Playbook. Page 11 

@arafkarsh arafkarsh Tirelessly Pursue Cyber Resilience 45 9 • Cyber Resilience is “the ability to anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or compromises on the systems that include cyber resources.” • Cybersecurity touches each of the eight phases of the DevSecOps lifecycle, and the various control gates serve as Go/No-Go decision points. • Al pipelines must use these control gates to ensure that cybersecurity is both “baked in” and transparently identified • Moving to DevSecOps includes moving towards a Continuous Authorization to Operate (cATO) for an application developed using DevSecOps processes, including a software factory with a CI/CD pipeline. Source: US DoD DevSecOps Fundamentals Playbook. Page 12 

@arafkarsh arafkarsh Shift Left: Operational Test & Eval 46 10 Common Testing Categories 1. Unit and Functional Testing. 2. Integration Testing. 3. Performance Testing. 4. Interoperability Testing. 5. Deployment Testing (normally conducted in a staging environment). 6. Operational Testing (normally conducted in a production environment). 7. Static Application Security Testing (SAST). 8. Dynamic Application Security Testing (DAST). 9. Interactive Application Security testing (IAST). 10. Runtime Application Self-Protection (RASP). Source: US DoD DevSecOps Fundamentals Playbook. Page 13 

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

@arafkarsh arafkarsh How to achieve DevSecOps? Design Thinking / Lean Startup / Agile / Stories 1 Architecture & Design 2 Test Automation Chaos Engineering 3 DevSecOps DevOps / SRE 4 48 

@arafkarsh arafkarsh 0 Setting up the Context o Traditional Development & Operations o DevOps Concept o DevSecOps Concept o Application Modernization o Stages of Software Delivery Pipeline 49 

@arafkarsh arafkarsh Application Modernization – 3 Transformations 50 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 51 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 52 Source: Page 16 US DoD Enterprise DevSecOps 2.0 Fundamentals 

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

@arafkarsh arafkarsh Developer Journey 54 Agile Scrum (4-6 Weeks) 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 Requirement Specs Microservices Domain Driven Design Event Sourcing and CQRS Scrum / Kanban (1-5 Days) Mandatory Infrastructure Design Patterns CI DevOps Event Streaming / Replicated Logs SQL NoSQL CD Container Orchestrator Service Mesh Themes, Epics, Stories, Acceptance Criteria 

@arafkarsh arafkarsh Stages of Software Delivery Pipeline 55 Source: Sanjeev Sharma, IBM, DevOps for Dummies Application Release Management Development Build Package Repository Test Environment Stage Environment Production Environment Application Deployment Automation Cloud Provisioning mvn repository npm repository Docker hub 

@arafkarsh arafkarsh Specs, Architecture, Design, Packaging 56 EPIC Bounded Context Micro Service Pod User Stories MVP Domain Driven Design Service Architecture Container Orchestration Design Thinking Lean Startup Agile (Kanban) CI/CD/CD, DevSecOps Specs Deploy Design / Develop Code Process Test Automation Code, Infra Code, Continuous Integration, Continuous Delivery, Continuous Deployment DFD L1 Data Flow Diagrams 

@arafkarsh arafkarsh Management Pipeline Automation Design / Develop SpecOps Workflow - SDLC 57 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 • Containers • Orchestration • Serverless • Traffic Routing • Security (mTLS, JWT) • Policies (Network / Security • Observability Infra Code • Feature Code • Configs Source Code Specs 

@arafkarsh arafkarsh Software Specs • Design Thinking / Lean Startup • User Stories • Agile - Scrum / Kanban 58 1 

@arafkarsh arafkarsh Three Mindsets of Product Development 59 Design Thinking Lean Agile Source: Jonny Schneider, Thought Works Explore the Problem Build the right things Build the things right Hypothesis Validation New Business Requirements Product Evolutions Agile MVP 

@arafkarsh arafkarsh Discovery Vs. Delivery 60 Increasing level of Evidence of Value Increasing level of Effort Developing a product without finding evidence of its value is a waste of time and resources. Observe & Interact Protypes Explainer Videos Landing Pages Concierge MVP Wizard of OZ MVP Beta Release Product Launch Design Thinking Lean Agile Explore the Problem Build the right things Build the things right If You are NOT doing these Then this is waste Single Customer Example Amazon had Human Book Reviewers before they automated it Example Dropbox: Customer interests went up from 5K to 70K 

@arafkarsh arafkarsh Agile Values 61 INDIVIDUALS AND INTERACTIONS OVER PROCESSESS AND TOOLS WORKING SOFTWARE COMPREHENSIVE DOCUMENTATION OVER CUSTOMER COLLABORATION OVER CONTRACT NEGOTIATION RESPONDING TO CHANGE OVER FOLLOWING A PLAN Source: Agile Manifesto - https://www.scrumalliance.org/resources/agile-manifesto 

@arafkarsh arafkarsh Kanban vs. Scrum 62 Kanban Scrum Roles & Responsibilities No prescribed roles Pre-defined roles of Scrum master, Product owner and team member Delivery Timelines Continuous Delivery (Daily/Hourly) Time boxed sprints (2-4 Weeks) Delegation & Prioritization Work is pulled through the system (single piece flow) Work is pulled through the system in batches (the sprint backlog) Modifications Changes can be made at any time No changes allowed mid-sprint Measurement of Productivity Cycle time Velocity When to Use? More appropriate in operational environments with a high degree of variability in priority More appropriate in situations where work can be prioritized in batches that can be left alone Source: https://leankit.com/learn/kanban/kanban-vs-scrum/ 

@arafkarsh arafkarsh Benefits of Kanban 63 • Shorter cycle times can deliver features faster. • Responsiveness to Change: • When priorities change very frequently, Kanban is ideal. • Balancing demand against throughput guarantees that most the customer-centric features are always being worked. • Requires fewer organization / room set-up changes to get started • Reducing waste and removing activities that don’t add value to the team/department/organization • Rapid feedback loops improve the chances of more motivated, empowered and higher-performing team members 

@arafkarsh arafkarsh User Stories • User Stories • Behavior Driven Design • Writing Good Stories • Estimate and Planning • Case Study 64 Theme Epic User Story Sprint 

@arafkarsh arafkarsh ShopEasy – eCommerce Portal 65 Theme Epic User Story Sprint ShopEasy – eCommerce Application 1. Customer Management 2. Search Product 3. Catalogue 4. Shopping Cart 5. Order Processing 6. Payments 2. Search Product Release 1 1. Global Search Release 2 1. Search by Brand 2. Search by Price Range Release 3 1. Search by Model 2. Search by Rating Stories 1. Global Search 2. Search by Brand 3. Search by Price Range 4. Search by Model 5. Search by Rating 

@arafkarsh arafkarsh Behavior Driven Development 66 Source: https://dannorth.net/introducing-bdd/ As an insurance Broker I want to know who my Gold Customers are So that I sell more Given Customer John Doe exists When he buys insurance ABC for $1000 USD Then He becomes a Gold Customer BDD Construct Role-Feature-Reason Matrix As a Customer I want to withdraw Cash from ATM So that I don’t have to wait in line at the bank Given The account is in Credit AND the Card is Valid AND the dispenser contains Cash BDD Construct Role-Feature-Reason Matrix When The Customer requests Cash Then Ensure that the Account is debited AND Ensure cash is dispensed AND ensure that Card is returned. 

@arafkarsh arafkarsh Epic – Customer 67 As a Consumer I want to register eCommerce Portal So that I can buy products Role-Feature-Reason Matrix User Story – 1 : Registration BDD Acceptance Criteria – 1: Save User Given The fields First Name, Last Name, DOB Address, Email Address, Phone No. When User enters values in the fields First Name, Last Name, DOB Address, Email Address, Phone No. Then If the following fields contains values First Name, Last Name, Address, Email Address and Phone No. AND Age is greater than 18 Save the Data. BDD Acceptance Criteria – 2 : Generate Password Given User Info Available When Email Address is a valid email Then Generate the password AND Send mail with user email address as login id the URL of the portal AND Send Password in a separate email address. AND Store data on mail status as mail send or failed. BDD Acceptance Criteria – 3 : Resend Mail Given User Registration mail status is available When The Mail status is failed. Then Send the mail again AND stored the attempt number. 

@arafkarsh arafkarsh User Journey / Story Map & Release Cycles 68 Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment Catalogue Shopping Cart Order Payment Customer View Product Search User Journey Search by Price Image Gallery Update Qty Use UPI R2 Global Search Product Details Add to Cart Delete Item Select Address Confirm Order Pay Credit Card Make Payment R1 Registration Minimum Viable Product Scrum Sprint Cycle Search by Price Image Gallery Update Qty Use UPI Kanban Cycle: Each of the Story can be released without waiting for other stories to be completed resulting in Shorter Releases as all the stories are independent! 

@arafkarsh arafkarsh Specs Summary 69 o Design Thinking / Lean Startup o Agile (Kanban) o Epics / User Stories o User Journey / Story Map o Minimum Viable Product 

@arafkarsh arafkarsh Architecture & Design • Capability Centric Design • Domain Driven Design • Event Sourcing & CQRS • Microservices Architecture 70 2 

@arafkarsh arafkarsh Business Capability Centric Design 71 Business Centric Development • Focus on Business Capabilities • Entire team is aligned towards Business Capability. • From Specs to Operations – The team handles the entire spectrum of Software development. • Every vertical will have its own Code Pipeline, Build Pipeline Front-End-Team Back-End-Team Database-Team In a typical Monolithic way, the team is divided based on technology/skill set rather than business functions, leading to bottlenecks and a lack of understanding of the Business Domain. QA Team QA = Quality Assurance PO = Product Owner Vertically sliced Product Team Front-End Back-End Database Business Capability 1 QA PO Ops Front-End Back-End Database Business Capability 2 QA PO Ops Front-End Back-End Database Business Capability - n QA PO Ops 

@arafkarsh arafkarsh Domain Driven Design – Tactical Design 72 Source: Domain-Driven Design Reference by Eric Evans 

@arafkarsh arafkarsh Event Sourcing Intro 73 Standard CRUD Operations – Customer Profile – Aggregate Root Profile Address Title Profile Created Profile Address New Title Title Updated Profile New Address New Title New Address added Derived Profile Address Notes Notes Removed Time T1 T2 T4 T3 Event Sourcing and Derived Aggregate Root Commands 1. Create Profile 2. Update Title 3. Add Address 4. Delete Notes 2 Events 1. Profile Created Event 2. Title Updated Event 3. Address Added Event 4. Notes Deleted Event 3 Profile Address New Title Current State of the Customer Profile 4 Event store Single Source of Truth Greg Young 

@arafkarsh arafkarsh Mind Shift : From Object Modeling to Process Modeling 74 Developers with Strong Object Modeling experience will have trouble making Events a first-class citizen. • How do I start Event Sourcing? • Where do I Start on Event Sourcing / CQRS? The Key is: 1. App User’s Journey 2. Business Process 3. Ubiquitous Language – DDD 4. Capability Centric Design 5. Outcome Oriented The Best tool to define your process and its tasks. How do you define your End User’s Journey & Business Process? • Think It • Build It • Run IT 

@arafkarsh arafkarsh 75 Process • Define your Business Processes. Eg. Various aspects of Order Processing in an E-Commerce Site, Movie Ticket Booking, Patient visit in Hospital. 1 Commands • Define the Commands (End-User interaction with your App) to execute the Process. Eg. Add Item to Cart is a Command. 2 Event Sourced Aggregate • Current state of the Aggregate is always derived from the Event Store. Eg. Shopping Cart, Order etc. This will be part of the Rich Domain Model (Bounded Context) of the Micro Service. 4 Projections • Projections focuses on the View perspective of the Application. As the Read & Write are different Models, you can have different Projections based on your View perspective. 5 Write Data Read Data Events • Commands generates the Events to be stored in Event Store. Eg. Item Added Event (in the Shopping Cart). 3 Event Storming – Concept 

@arafkarsh arafkarsh Summary: User Journey / CCD / DDD / Event Sourcing & CQRS 76 User Journey Bounded Context 1 Bounded Context 2 Bounded Context 3 1. Bounded Contexts 2. Entity 3. Value Objects 4. Aggregate Roots 5. Domain Events 6. Repository 7. Service 8. Factory Process 1 Commands 2 Projections 5 ES Aggregate 4 Events 3 Event Sourcing & CQRS Domain Expert Analyst Architect QA Design Docs Test Cases Code Developers Domain Driven Design Ubiquitous Language Core Domain Sub Domain Generic Domain Vertically sliced Product Team FE BE DB Business Capability 1 QA Team PO FE BE DB Business Capability 2 QA Team PO FE BE DB Business Capability n QA Team PO 

@arafkarsh arafkarsh Cloud Native Architecture 77 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 Layered Architecture Domain Driven Design Capability Centric Design Kafka Messaging / Streams / Connect Epics / User Stories / MVP Data Mesh / K8s/Kafka Clusters / Infra Patterns Containers / Kubernetes / Mesh Terraform Bulkhead, Circuit Breaker, Green / Blue Deployment Microservices Characteristics 

@arafkarsh arafkarsh 78 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 Architecture Summary 79 o Capability Centric Design o Domain Driven Design o Event Sourcing and CQRS o Microservices Architecture (Cloud Native Architecture) 

@arafkarsh arafkarsh Test Automation • Microservices Testing strategies • Chaos engineering • Behavior driven development 80 3 

@arafkarsh arafkarsh Microservices Testing Strategies 81 Ubiquitous Language Domain Expert Analyst Developers QA Design Docs Test Cases Code E2E Testing Integration Testing Contract Testing Component Testing Unit Testing Number of Tests Speed Cost Time Mike Cohen’s Testing Pyramid Test Pyramid: https://martinfowler.com/bliki/TestPyramid.html 70% 20% 10% 

@arafkarsh arafkarsh Microservices Testing Strategy 82 Unit Testing A unit test exercises the smallest piece of testable software in the application to determine whether it behaves as expected. Source: https://martinfowler.com/articles/microservice-testing/#agenda Component Testing A component test limits the scope of the exercised software to a portion of the system under test, manipulating the system through internal code interfaces and using test doubles to isolate the code under test from other components. Integration Testing An integration test verifies the communication paths and interactions between components to detect interface defects Integration Contract Testing An Integration Contract test is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service. End 2 End Testing An end-to-end test verifies that a system meets external requirements and achieves its goals, testing the entire system, from end to end Say NO to End 2 End Tests - Mike Walker April 22, 2015. Google Test Blog 

@arafkarsh arafkarsh Microservices Testing Scenarios / Tools 83 Testing Tools Contract Testing Scope Integration Testing Verifies the communication paths and interactions between components to detect interface defects Contract Testing It is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service. Payment Mock Integration Contract Testing Scope Test Double Montebank Cart Component Testing Unit Testing Integration Testing Scope Order REST / HTTP or Events / Kafka Item ID, Quantity, Address.. Mock Order Component Testing A component test limits the scope of the exercised software to a portion of the system under test. Order Payment Unit Testing Firewall Integration Testing Scope REST / HTTP Payment Sandbox Component Testing U 

@arafkarsh arafkarsh Shift Right – Chaos Engineering 84 Cloud Chaos Monkey Randomly disables production instances Chaos Kong Similar to Chaos Monkey, simulates an outage of an entire Amazon availability zone. Doctor Monkey Kubernetes Checks CPU load, Memory usage and removes it from network if the health is bad. Janitor Monkey Kubernetes Search for unused resources and disposes them. Conformity Monkey Finds instances that don’t adhere to best- practices and shuts them down. Latency Money Service Mesh Induces Artificial delays Security Monkey Is an extension of Compliance Monkey. Find security vulnerabilities and terminates offending instances. Source: https://github.com/Netflix/SimianArmy/wiki Source: http://principlesofchaos.org/ Production Testing – Load / Stress / Performance 

@arafkarsh arafkarsh Testing Strategy Summary 85 1. Unit Testing A unit test exercises the smallest piece of testable software. 2. Component Testing A component test limits the scope of the exercised software to a portion of the system under test. 3. Contract Testing It is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service 4. Integration Testing It verifies the communication paths and interactions between components to detect interface defects. 

@arafkarsh arafkarsh DevOps & SRE • DevOps • SRE • Best Practices • Case Studies 86 4 SRE: Site Reliability Engineering 

@arafkarsh arafkarsh DevOps – Lean thinking 87 Source: Sanjeev Sharma, IBM, DevOps for Dummies Systems of Records: Critical Enterprise transactions and these Apps doesn’t require frequent changes. Systems of Engagement: With introduction of Rich Web Apps and Mobiles Apps, Systems of Records were augmented by Systems of Engagements. Customers directly engage with these Apps and these Apps requires Rapid Releases. DevOps Return on Investment 1. Enhanced Customer Experience 2. Increased Capacity to Innovate 3. Faster time to value 

@arafkarsh arafkarsh DevSecOps 88 Source: https://www.atlassian.com/devops/devops-tools/devsecops-tools 

@arafkarsh arafkarsh DevSecOps Manifesto 89 Source: https://www.devsecops.org/ 1. Leaning in over Always Saying “No” 2. Data & Security Science over Fear, Uncertainty and Doubt 3. Open Contribution & Collaboration over Security-Only Requirements 4. Consumable Security Services with APIs over Mandated Security Controls & Paperwork 5. Business Driven Security Scores over Rubber Stamp Security 6. Red & Blue Team Exploit Testing over Relying on Scans & Theoretical Vulnerabilities 7. 24x7 Proactive Security Monitoring overreacting after being Informed of an Incident 8. Shared Threat Intelligence over Keeping Info to Ourselves 9. Compliance Operations over Clipboards & Checklists 

@arafkarsh arafkarsh 5 DevOps Principles – CALMS Framework 90 Source: https://www.atlassian.com/devops/frameworks/calms-framework DevOps isn’t a process, or a different approach to development. It’s a culture change. DevOps culture is collaboration. Build, Test, Deploy, and Provisioning automation are typical starting points for teams. Another major contribution of DevOps is “configuration as code.” Developers strive to create modular, composable applications because they are more reliable and maintainable. CULTURE AUTOMATION LEAN MEASUREMENT SHARING Continuous Improvement with Canary Releases and A/B Testing Continuous Improvement requires Data to measure the changes Sharing responsibility, success, failure goes a long way toward bridging that divide between Dev and Ops. You built it, You run it. 

@arafkarsh arafkarsh Implementing CALMS – DevOps Principles 91 Capability Centric Design Reduce Organization Silos CULTURE Leverage Tooling & Automation Tests, CI/CD Pipeline & Container Orchestration AUTOMATION Implement Gradual Change Microservices Architecture & Agile: Kanban LEAN Measure Everything Service Mesh: Observability MEASUREMENT Accept Failure as Normal Design for Failure SHARING Source: IBM DevOps Vs. SRE https://www.youtube.com/watch?v=KCzNd3StIoU Google: https://www.youtube.com/watch?v=uTEL8Ff1Zvk 

@arafkarsh arafkarsh class SRE implements DevOps – CALMS 92 Capability Centric Design Reduce Organization Silos CULTURE Leverage Tooling & Automation Tests, CI/CD Pipeline & Container Orchestration AUTOMATION Implement Gradual Change Microservices Architecture & Agile: Kanban LEAN Measure Everything Service Mesh: Observability MEASUREMENT Accept Failure as Normal Design for Failure SHARING ✓ Share Ownership ✓ SLOs & Blameless PM ✓ Canary Deployment, A/B Testing ✓ Automate this years Job ✓ Measure toil & reliability 

@arafkarsh arafkarsh SRE – Concept 93 ❑ Bridge the Gap between Development & Operations ❑ Developers want to ship features as fast as possible ❑ Operations want stability in Production ❑ Empower the Software Developers to own the operations of Applications in Production. ❑ Site Reliability Engineers spend 50% of their time in Operations. ❑ SRE has a deep understanding of the application, the code, how it runs, is configured and how it will scale. ❑ They monitor and manage the support apart from the development activities. Source: https://stackify.com/site-reliability-engineering/ - https://www.redhat.com/en/topics/devops/what-is-sre 

@arafkarsh arafkarsh SRE – Responsibilities 94 ❑ Proactively monitor and review application performance ❑ Handle on-call and emergency support ❑ Ensure software has good logging and diagnostics ❑ Create and maintain operational runbooks ❑ Help triage escalated support tickets ❑ Work on feature requests, defects and other development tasks ❑ Contribute to overall product roadmap Source: https://stackify.com/site-reliability-engineering/ - https://www.redhat.com/en/topics/devops/what-is-sre 

@arafkarsh arafkarsh Benefits of DevOps 95 ✓ Velocity o Agile / Kanban, o Capability Centric Design o Domain Driven Design o Event Sourcing & CQRS o Microservices Architecture Code Build Manage Learn Idea ✓ Quality o Test Automation o Build Pipeline Automation o Continuous Integration o Continuous Delivery o Continuous Deployment o Observability People Process Tools 

@arafkarsh arafkarsh DevSecOps o Zero Trust o NIST 800-207 Architecture o Service Mesh o US DoD Enterprise DevSecOps 2.0 Playbook 96 

@arafkarsh arafkarsh Perimeter Security Vs. Zero Trust 97 Zero Trust Security Model Classic Security Model Perimeter Security • Location Based (External / Internal) • Anyone inside the network is always trusted. • Based on Layered Security Never Trust, Always Verify 1 Implement Least Privilege 2 (Always) Assume Breach 3 Forrester's John Kindervag 2010: No More Chewy Centers: Introducing The Zero Trust Model Of Information Security Inspired from Jericho Forum Commandments v1.2 May 2007 Source: Microsoft: Jericho & Modern Security Restrict everything to a secure Network Zero Trust Protect Assets anywhere with Central Policy 

@arafkarsh arafkarsh NIST 800-207: Zero Trust Architecture 98 Source: NIST SP 800-207:Zero Trust Architecture https://csrc.nist.gov/publications/detail/sp/800-207/final A User, An Application, or a Device – Operating on (or with) a Computer System which has access to an Enterprise Resource Subject Is an Application, Document, Data, Database, Workload that’s under the Enterprise Control protected by the Zero Trust System Resource Policy Enforcement Point Policy Engine Policy Administrator Policy Decision Point Control Plane Data Plane Resource Subject User App Device UnTrusted Trusted CDM System GRC System Threat Intelligence Activity Logs Data Access Policy PKI IAM SIEM 1 2 3 

@arafkarsh arafkarsh Zero Trust : Service Mesh / Istio 99 Source: https://istio.io/docs/concepts/security/ 

@arafkarsh arafkarsh 6 DevSecOps Summary 100 1 Adopt a DevSecOps Culture 2 Adopt Infrastructure as Code 3 Adopt Containerized Microservices 4 Adopt a Capability Model, not a Maturity Model 5 Drive Continuous Improvement through Key Capabilities Establish a Software Factory 7 Define a meaningful DevSecOps pipeline 8 Adapt an Agile Acquisition Policy for Software 9 Tirelessly Pursue Cyber Resilience 10 Shift Left: Operational Test & Eval Source: US DoD DevSecOps Fundamentals Playbook 

@arafkarsh arafkarsh DevOps Case Studies • NetFlix • Spotify 101 

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

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

@arafkarsh arafkarsh 104 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 105 Slides: https://speakerdeck.com/arafkarsh Blogs https://arafkarsh.medium.com/ Web: https://arafkarsh.com/ Source: https://github.com/arafkarsh github.com 

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