Why do we need DevOps?

DevOps bridges the gap between development (Dev) and operations (Ops) teams to address challenges in traditional software delivery approaches. Here are the key reasons DevOps is essential:
1. Faster Delivery:
• DevOps automates processes, enabling continuous integration and continuous deployment (CI/CD), which reduces the time to market.
• Teams can respond to business and customer needs more quickly.
2. Improved Collaboration:
• By fostering a culture of shared responsibility, DevOps eliminates silos between development and operations teams.
• Collaboration improves problem-solving and innovation.
3. Enhanced Quality:
• Automated testing and monitoring ensure that code changes are thoroughly vetted before deployment, reducing bugs and failures in production.
4. Scalability:
• DevOps practices like infrastructure as code (IaC) enable dynamic scaling of resources to meet demand.
• This is critical for modern applications with fluctuating workloads.
5. Resilience and Reliability:
• Continuous monitoring, automated rollback mechanisms, and quick feedback loops improve system uptime and reduce the impact of failures.
6. Cost Efficiency:
• Automation reduces manual tasks, minimizing human error and optimizing resource usage.
• Efficient processes lower operational costs.
7. Customer Satisfaction:
• Frequent and reliable releases mean faster delivery of new features and quick resolution of issues, improving the end-user experience.

Transcript

1. @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 DevOps? USER STORIES / AGILE ARCHITECTURE & DESIGN TESTING AUTOMATION SITE RELIABILITY ENGINEERING DEVSECOPS PLAYBOOK Why do we need
2. @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?
3. @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
4. @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
5. @arafkarsh arafkarsh 5 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
6. @arafkarsh arafkarsh 6 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
7. @arafkarsh arafkarsh 7 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
8. @arafkarsh arafkarsh 8 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
9. @arafkarsh arafkarsh Management Pipeline Automation Design / Develop SpecOps Workflow - SDLC 9 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
10. @arafkarsh arafkarsh Modernization Journey towards Cloud Native Apps 10 Source: Page 16 US DoD Enterprise DevSecOps 2.0 Fundamentals
11. @arafkarsh arafkarsh Modernization Journey towards Cloud Native Apps 11 Source: Page 16 US DoD Enterprise DevSecOps 2.0 Fundamentals
12. @arafkarsh arafkarsh DevOps Best Practices o Shift Left – CI/CD Automation o Infrastructure as a Code o Stages of DevOps Delivery Pipeline o Observability 12
13. @arafkarsh arafkarsh 5 DevOps Principles – CALMS Framework 13 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.
14. @arafkarsh arafkarsh Implementing CALMS – DevOps Principles 14 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
15. @arafkarsh arafkarsh Culture: Business Capability Centric Design 15 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
16. @arafkarsh arafkarsh Production Environment Continuous Monitoring Fully Automated Continuous Deployment Automation: Shift Left – Operational Concerns 16 • 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
17. @arafkarsh arafkarsh Automation: Stages of DevOps Pipeline 17 Build Design Develop Test Deploy Ops Specs Agile DevOps Go Live Support Specs / Design / Development CI/CD and Tests Automation Operations
18. @arafkarsh arafkarsh Automation: Infrastructure as a Code 18 • 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
19. @arafkarsh arafkarsh 19 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.”
20. @arafkarsh arafkarsh Measure: Pillars of Observability 20 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
21. @arafkarsh arafkarsh Share: Full Stack Teams 21 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.
22. @arafkarsh arafkarsh DevSecOps Playbook 22
23. @arafkarsh arafkarsh DevSecOps 23 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
24. @arafkarsh arafkarsh DevSecOps 24 Source: https://www.atlassian.com/devops/devops-tools/devsecops-tools
25. @arafkarsh arafkarsh 6 DevSecOps Playbook 25 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
26. @arafkarsh arafkarsh Adopt a DevSecOps Culture 26 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
27. @arafkarsh arafkarsh Adopt Infrastructure as Code 27 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
28. @arafkarsh arafkarsh 28 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
29. @arafkarsh arafkarsh Adopt a Capability Model, not a Maturity Model 29 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.
30. @arafkarsh arafkarsh Drive Continuous Improvement through Key Capabilities 30 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
31. @arafkarsh arafkarsh Drive Continuous Improvement through Key Capabilities 31 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
32. @arafkarsh arafkarsh Establish a Software Factory 32 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
33. @arafkarsh arafkarsh Define a meaningful DevSecOps pipeline 33 7 Source: US DoD DevSecOps Fundamentals Playbook. Page 10
34. @arafkarsh arafkarsh Adapt an Agile Acquisition Policy for Software 34 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
35. @arafkarsh arafkarsh Tirelessly Pursue Cyber Resilience 35 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
36. @arafkarsh arafkarsh Shift Left: Operational Test & Eval 36 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
37. @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. 37
38. @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 38
39. @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 39
40. @arafkarsh arafkarsh Application Modernization – 3 Transformations 40 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
41. @arafkarsh arafkarsh Application Modernization – 3 Transformations 41 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
42. @arafkarsh arafkarsh Modernization Journey towards Cloud Native Apps 42 Source: Page 16 US DoD Enterprise DevSecOps 2.0 Fundamentals
43. @arafkarsh arafkarsh Modernization Journey towards Cloud Native Apps 43 Source: Page 16 US DoD Enterprise DevSecOps 2.0 Fundamentals
44. @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 44 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/CD Container Orchestrator Service Mesh
45. @arafkarsh arafkarsh Stages of Software Delivery Pipeline 45 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
46. @arafkarsh arafkarsh Specs, Architecture, Design, Packaging 46 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
47. @arafkarsh arafkarsh Management Pipeline Automation Design / Develop SpecOps Workflow - SDLC 47 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
48. @arafkarsh arafkarsh Software Specs • Design Thinking / Lean Startup • User Stories • Agile - Scrum / Kanban 48 1
49. @arafkarsh arafkarsh Three Mindsets of Product Development 49 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
50. @arafkarsh arafkarsh Discovery Vs. Delivery 50 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
51. @arafkarsh arafkarsh Agile Values 51 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
52. @arafkarsh arafkarsh Kanban vs. Scrum 52 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/
53. @arafkarsh arafkarsh Benefits of Kanban 53 • 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
54. @arafkarsh arafkarsh User Stories • User Stories • Behavior Driven Design • Writing Good Stories • Estimate and Planning • Case Study 54 Theme Epic User Story Sprint
55. @arafkarsh arafkarsh ShopEasy – eCommerce Portal 55 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
56. @arafkarsh arafkarsh Behavior Driven Development 56 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.
57. @arafkarsh arafkarsh Epic – Customer 57 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.
58. @arafkarsh arafkarsh User Journey / Story Map & Release Cycles 58 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!
59. @arafkarsh arafkarsh Specs Summary 59 o Design Thinking / Lean Startup o Agile (Kanban) o Epics / User Stories o User Journey / Story Map o Minimum Viable Product
60. @arafkarsh arafkarsh Architecture & Design • Capability Centric Design • Domain Driven Design • Event Sourcing & CQRS • Microservices Architecture 60 2
61. @arafkarsh arafkarsh Business Capability Centric Design 61 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
62. @arafkarsh arafkarsh Domain Driven Design – Tactical Design 62 Source: Domain-Driven Design Reference by Eric Evans
63. @arafkarsh arafkarsh Event Sourcing Intro 63 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
64. @arafkarsh arafkarsh Mind Shift : From Object Modeling to Process Modeling 64 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
65. @arafkarsh arafkarsh 65 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
66. @arafkarsh arafkarsh Summary: User Journey / CCD / DDD / Event Sourcing & CQRS 66 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
67. @arafkarsh arafkarsh Cloud Native Architecture 67 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
68. @arafkarsh arafkarsh 68 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
69. @arafkarsh arafkarsh Architecture Summary 69 o Capability Centric Design o Domain Driven Design o Event Sourcing and CQRS o Microservices Architecture (Cloud Native Architecture)
70. @arafkarsh arafkarsh Test Automation • Microservices Testing strategies • Chaos engineering • Behavior driven development 70 3
71. @arafkarsh arafkarsh Microservices Testing Strategies 71 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%
72. @arafkarsh arafkarsh Microservices Testing Strategy 72 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
73. @arafkarsh arafkarsh Microservices Testing Scenarios / Tools 73 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
74. @arafkarsh arafkarsh Shift Right – Chaos Engineering 74 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
75. @arafkarsh arafkarsh Testing Strategy Summary 75 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.
76. @arafkarsh arafkarsh DevOps & SRE • DevOps • SRE • Best Practices • Case Studies 76 4 SRE: Site Reliability Engineering
77. @arafkarsh arafkarsh DevOps – Lean thinking 77 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
78. @arafkarsh arafkarsh DevSecOps 78 Source: https://www.atlassian.com/devops/devops-tools/devsecops-tools
79. @arafkarsh arafkarsh DevSecOps Manifesto 79 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
80. @arafkarsh arafkarsh 5 DevOps Principles – CALMS Framework 80 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.
81. @arafkarsh arafkarsh Implementing CALMS – DevOps Principles 81 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
82. @arafkarsh arafkarsh class SRE implements DevOps – CALMS 82 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
83. @arafkarsh arafkarsh SRE – Concept 83 ❑ 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
84. @arafkarsh arafkarsh SRE – Responsibilities 84 ❑ 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
85. @arafkarsh arafkarsh Benefits of DevOps 85 ✓ 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
86. @arafkarsh arafkarsh DevSecOps o Zero Trust o NIST 800-207 Architecture o Service Mesh o US DoD Enterprise DevSecOps 2.0 Playbook 86
87. @arafkarsh arafkarsh Perimeter Security Vs. Zero Trust 87 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
88. @arafkarsh arafkarsh NIST 800-207: Zero Trust Architecture 88 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
89. @arafkarsh arafkarsh Zero Trust : Service Mesh / Istio 89 Source: https://istio.io/docs/concepts/security/
90. @arafkarsh arafkarsh 6 DevSecOps Summary 90 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
91. @arafkarsh arafkarsh DevOps Case Studies • NetFlix • Spotify 91
92. @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. 92
93. @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 93
94. @arafkarsh arafkarsh 94 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
95. @arafkarsh arafkarsh 95 Slides: https://speakerdeck.com/arafkarsh Blogs https://arafkarsh.medium.com/ Web: https://arafkarsh.com/ Source: https://github.com/arafkarsh github.com
96. @arafkarsh arafkarsh 96 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