@arafkarsh arafkarsh Architecting & Building Apps a tech presentorial Combination of presentation & tutorial ARAF KARSH HAMID Co-Founder / CTO MetaMagic Global Inc., NJ, USA @arafkarsh arafkarsh AI / ML Generative AI LLMs, RAG 6+ Years Microservices Blockchain 8 Years Cloud Computing 8 Years Network & Security 8 Years Distributed Computing 1 Solutions Architecture To Build Cloud Native Apps Using Composable Enterprise Architecture To Manage SpecOps: From Specs to Ops Introduction to 15 Part Series

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

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

@arafkarsh arafkarsh BPB Building Cloud Native Apps 4

@arafkarsh arafkarsh Topics 5 1. Understanding the Context 2. Software Architecture 3. Case Study: Viewpoints & Views 4. Case Study: Perspectives 5. Solutions Architect

@arafkarsh arafkarsh Understanding the Context • From Specs to Ops • Application Modernization • Enterprise Architecture • Solutions Architect • What Architect Need to do? 6 1

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

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

@arafkarsh arafkarsh Enterprise Architecture 9 Business Architecture: Describes the organization's business processes, functions, and capabilities. Data Architecture: Describes the organization's data structures, data flows, and data storage. Application Architecture: Describes the organization's software applications and their interconnections. Technology Architecture: Describes the organization's software applications and their interconnections. Security Architecture: Describes the organization's security policies, procedures, and controls. The benefits of EA include: 1. Improved alignment between business and technology. 2. Increased efficiency and effectiveness of business processes. 3. Reduced complexity and cost of technology infrastructure. 4. Better management of technology risks. 5. Increased agility and ability to respond to changing business needs.

@arafkarsh arafkarsh Solutions Architecture 10 High-Level Blueprint of a System that defines Structure of its components. Behaviour Relationship It describes how the system will be Designed Developed Deployed It may include specifications for Hardware / Software Data Security Ops

@arafkarsh arafkarsh 11 Solutions Architecture Global Teams 5 Global Compliance 6 Business Requirements End User Requirements Infrastructure Requirements Budget Project Timelines 1. Non-Functional 2. Functional 1 2 3 4 0 Technology Selection Solution Implementation Solution Maintenance 7 8 9

@arafkarsh arafkarsh 12 Role A software architect should be responsible for making high-level design choices, defining technical standards, and guiding the overall software architecture. Technical Expertise Ensure that the software architect has a strong technical background, with deep knowledge of software engineering principles, design patterns, and best practices Leadership & Communication A software architect should have strong leadership and communication skills. They should be able to work closely with various stakeholders, including project managers, developers, and clients, to clearly communicate architectural decisions and their rationale. Collaboration The software architect should be open to receiving input from others, while also proactively sharing their knowledge and expertise. Adaptability A good software architect should be adaptable and open to change, recognizing that requirements and technologies may evolve over time. They should be able to reassess and update the architecture as needed. Continuous Learning A software architect should stay up-to-date with the latest trends, technologies, and best practices in the software industry. To Summarize… What Architect need to do?

@arafkarsh arafkarsh Software Architecture • System Context Design, Data Flow Diagram Level 0,1,2 Diagrams • 4+1 Architecture View of Software • ISO/IEC/IEEE 42010:2011 & 42010:2022 • View, Viewpoints & Perspectives • Non-Functional Requirements 13 2

@arafkarsh arafkarsh From Object Modeling to Process Modeling 14 Developers with Strong Object Modelling will experience a big Mind Shift to transition to Process based modelling with Events. 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 Business Solution & Business Process 15 ❑ Business Solution focuses on the entire Journey of the User, which can run across multiple Microservices. ❑ Business Solution comprises a set of Business Processes. ❑ A specific Microservice functionality will be focused on a Business Process / Concern. ❑ Business Processes can be divided further into Business Functions.

@arafkarsh arafkarsh Case Study: Healthcare App 16 Theme / Initiative Epic User Story Sprint Healthcare / We Care 1. Patient 2. Healthcare Staff 3. Appointments 4. Diagnosis 5. Lab 6. Pharmacy 7. Auth 4. Diagnosis Release 1 1. Pre-Checkup 2. Search Medical History 3. Diagnosis & Prescription Release 2 1. Prescribe for Lab Tests Stories 1. Pre-Checkup 2. Search Medical History 3. Diagnosis & Prescription 4. Prescribe for Lab Tests

@arafkarsh arafkarsh User Journey with Story Map & Release Cycles 17 1. Register 3. Make Appointment 4. Diagnosis & Prescription 6. Get Medicine 5. Lab Tests Health Staff Appointment Pharmacy Lab Diagnosis 2. Search & Select Doctor Patient User Journey Minimum Viable Product Upload Medical Docs Add Doctor / Nurse Cancel Appointment R2 Lab Tests View Medical History Duty Calendar R3 Reschedule Register Search Doctor Available Dates Book Appointment Medical History Check Verify Prescription Pack Medicines R1 Pre-Checkup Diagnosis & Prescription Appointment Upload Results Schedule Duty Time Make Payment Share Medical Docs R4 Appointment Calendar Make Payment View Appointments Email SMS

@arafkarsh arafkarsh System Context Diagrams Data Flow Diagrams • Data Flow Diagrams L0, L1, L2 Diagrams • Compare Data Flow Diagrams and Flow Charts 18

@arafkarsh arafkarsh Components of Data Flow Diagram 19 Entity Process Output Data Store External Entity Process Output Data Flow Data Store • A Data Flow Diagram (DFD) is a visual representation that illustrates the data flow within a system. • It depicts how data enters, leaves, and is stored within the system. • A DFD provides a comprehensive description of the data flow throughout the system. • DFD was highlighted in the book “Structured Design” by Ed Yourdon and Larry Constantine in the 1970s

@arafkarsh arafkarsh 5 Main methods of Notations used in DFD 20 External Entity Process Store Data Flow Yourdon + De Marco SSADM Chris Gane & Trish Sarson <> Unified <> Duplicate Entity Entity 1 3 2 4 5 Structured Systems Analysis and Design Method, UK 1980 Structured Design Mid-1970s Late1970s Mid-1990s. UML doesn’t have DFD. It has Activity Diagrams

@arafkarsh arafkarsh Levels of Data Flow Diagram 21 0-level DFD / System Context Design: It represents the entire system as a single bubble and provides an overall picture of the system. 0 Business Solution 1-level DFD: It represents the main Processes of the system and how they interact with each other. 1 Business Process 2-level DFD: It represents the sub-processes within each Main Process of the system and how they interact with each other. 2 Business Function

@arafkarsh arafkarsh Data Flow Diagram – Rules 22 Entity 1 Patient Entity 2 Doctor Data can not flow between two Entities. • Data flow must be between Entity and Process or Process & Entity. • Multiple Data flows are allowed between Entity and Process. Patient DB Diagnosis DB Data can not flow between two Data Stores. • Data flow must be between Process & Data Stores or Vice versa. • Data can flow from 1 Data Store to multiple Processes. Patient DB Data can not flow directly from Entity to Data Stores. • A Process must process Data Flow from an Entity before going to the Data Store and vice versa. Entity 1 Patient Diagnosis Process In Out A Process must have at least 1 input and 1 output data flow. • Every process must have input data flow to process the data and an output data flow for the processed data.

@arafkarsh arafkarsh Data Flow Diagram Rules 23 In Out A Data Store must have at least 1 input and 1 output data flow. • Every Data Store must have input data flow to Store the data and an output data flow for the Retrieved data. Diagnosis DB Diagnosis Process A Process must be linked to at least 1 Data Store • All the Processes in the system must be linked to at least 1 data store. Diagnosis DB Two Data Flows can not cross each other.

@arafkarsh arafkarsh How to create a System Context Diagram 24 Step 1: Establish the initial boundary by identifying the product or project you want to contextualize and placing it in a circle at the center of your diagram. Also, identify the roles and processes that should go inside this boundary. Step 2: Identify all external Entities or Agents and list them around your initial boundary. Place entities with similar functions close to each other. Step 3: Determine data flows by ascertaining what data, services, or processes each external entity can expect from the main product and vice versa. Assign a data flow to each external entity until all have been accounted for. Step 4: Complete your context diagram by reviewing it and verifying the accuracy of each element. Delete any external entities that have no interactions with your product, correct any misplaced entities within the project’s scope, and ensure no missing agents or flows.

@arafkarsh arafkarsh System Context Diagram / Data Flow Diagram – L0 25 • System Context Diagram or Level 0. • An abstraction view • Shows the system as a single process with its relationship to external entities. • It represents the entire system as a single bubble with input and output data indicated by incoming/outgoing arrows.

@arafkarsh arafkarsh Data Flow Diagram – L1 26 • The L0 Context diagram is decomposed into multiple bubbles / processes. • Highlight the system's primary functions and • Break down the high-level process of 0-level DFD into subprocesses.

@arafkarsh arafkarsh Data Flow Diagram – L2 27 • The L1 Data Flow Diagram is decomposed into multiple bubbles / processes. • Highlights the details of that Specific Business Process. • It also shows the data stores associated with that Sub Process.

@arafkarsh arafkarsh Drawbacks of Data Flow Diagrams 28 1. Limited to Data Flow: DFDs are primarily focused on the data flow within a system and may not capture other aspects of the system, such as user interfaces or hardware components. 2. May Oversimplify the System: DFDs may oversimplify the system by focusing only on the data flow and ignoring other important aspects of the system. This can lead to an incomplete understanding of the system and its functions. 3. May Not Be Able to Represent Complex Systems: DFDs may be unable to represent complex systems with many processes and data effectively flowing. This can lead to a confusing or cluttered diagram. 4. May Not Account for Error Handling or Exceptions: DFDs may not account for error handling or exceptions in the system. This can lead to a diagram that does not accurately represent the system’s actual behavior. 5. May Not Capture the Dynamic Nature of the System: DFDs may not be able to capture the dynamic nature of the system, where processes and data flows can change over time. This can lead to an outdated or inaccurate diagram as the system evolves. 6. May Not Be Useful for Implementation: DFDs may not be useful for implementation, as they may not capture the necessary details required for actual implementation of the system.

@arafkarsh arafkarsh Benefits of Data Flow Diagrams 29 1. Clarifying System Boundaries: SCDs provide a clear and concise view of the system and its interactions with external entities. It helps stakeholders understand the scope and boundaries of the system and identify areas for improvement or further development. 2. Effective Communication: SCDs visually represent the system and its relationships with external entities. It helps stakeholders communicate and collaborate effectively by providing a shared understanding of the system and its components. 3. Identifying Dependencies and Interactions: SCDs help identify the dependencies and interactions between the system and external entities. It helps stakeholders understand the impact of external factors on the system and vice versa. 4. Easy to Understand: SCDs are easy to understand and interpret, even for non-technical stakeholders. It helps stakeholders from different backgrounds and disciplines to have a common understanding of the system. 5. Saves Time and Effort: SCDs can save time and effort in the system development process by providing a starting point for more detailed analysis and design activities. It helps to identify areas that require further investigation and those that can be ignored. 6. Reduced Complexity: SCDs simplify complex systems by breaking them into manageable components. It helps stakeholders understand the system's complexity and identify areas for simplification.

@arafkarsh arafkarsh Best Practices 30 1. Start with a context diagram: Begin by creating a context diagram that shows the system as a single process and all external entities that interact with it. 2. Use consistent naming conventions: Use consistent naming conventions for all processes, data flows, data stores, and external entities. This helps to ensure that everyone who reads the diagram can understand it. 3. Avoid crossing data flow lines: Do not cross data flow lines in a DFD, as this can make it challenging to understand the data flow. 4. Keep it simple: DFDs should be simple and easy to understand. Avoid overcomplicating the diagram by including unnecessary detail or information. 5. Group related processes together: Group related processes in the diagram to make understanding the relationships between them more manageable. 6. Include clear labels and annotations: Include clear labels and annotations in the DFD to help readers understand the different components and their relationships. 7. Verify the diagram's accuracy: Verify the DFD’s accuracy by reviewing it with stakeholders, comparing it to other system documentation, and testing it against real-world scenarios.

@arafkarsh arafkarsh Software Architecture 4+1 Architecture View Model ISO/IEC/IEEE 42010:2011 & 2022 Views, Viewpoints & Perspectives 31

@arafkarsh arafkarsh 4+1 Architecture View Model in Software 32 Logical View Process View Development View Physical View Use Cases Software Philippe Kruchten: Inventor of the 4+1 Architectural View Model Class & State Diagrams Systems Functionality Systems Runtime Behavior Sequence, Communication, Activity Component Diagram Developers Perspective Deployment Diagram Implementation View Deployment View System Engineers Perspective Use Case Diagram Product Owner Perspective IEEE, November 1995 Architectural Blueprints – The 4+1 View Model of Software Architecture

@arafkarsh arafkarsh 4+1 Architecture View Model in Software 33 View Logical Process Development Physical Scenarios Components Class Task Module Subsystem Node Step Scripts Connectors Association Inheritance Containment Rendezvous Message Broadcast RPC, etc. Dependencies LAN WAN Bus Containers Class Category Process Subsystem (Library) Physical Subsystem Web Stakeholders End-User System Designer, Integrator Developer Manager System Engineer Product Owner End User Developer Concerns Functionality Behavior Performance Availability Fault Tolerance Organization Scalability Performance Availability Fault Tolerance Understand-ability UML Diagrams Class & State Sequence Communication Activity Component Deployment Use Case IEEE, November 1995: Architectural Blueprints – The 4+1 View Model of Software Architecture

@arafkarsh arafkarsh 34 ISO/IEC/IEEE 42010-2011 Standard Source: https://www.iso.org/standard/50508.html Only for Architecture Descriptions of Software & Systems

@arafkarsh arafkarsh ISO/IEC/IEEE 42010-2011 Standard 35 1. Architecture: The fundamental organization of a system, its components, relationships, and the principles governing its design and evolution. 2. Architecture Description (AD): A collection of artifacts that documents an architecture, including its rationale, decisions, and constraints. 3. Stakeholder: Stakeholders are individuals, groups, or organizations holding Concerns for the System of Interest. Ex., client, owner, user, consumer, supplier, designer, maintainer, auditor, CEO, certification authority, and architect. 4. Concern: Examples of concerns are (system) purpose, functionality, structure, behavior, cost, supportability, safety, and interoperability. Source: https://www.iso.org/standard/50508.html

@arafkarsh arafkarsh ISO/IEC/IEEE 42010-2011 Standard 36 5. Architecture Viewpoint: A perspective from which the system's architecture is considered, addressing a specific set of stakeholder concerns. 6. Architecture View: A representation of a system from the perspective of a specific viewpoint applied to a particular system. 7. Architecture Model: A Collection of Model Kinds that represents the Architecture of the system OR any other representations; for Ex, a textual description of the system’s architecture could also serve as an Architecture Model, outlining the key components and their interactions in a narrative format. 8. Model Kind: It represents a specific UML Diagram like a Component diagram, Sequence diagram, Activity diagram, etc., OR ER Diagrams, DFD – Data Flow Diagrams, BPMN – Business Process Model Annotation. Source: https://www.iso.org/standard/50508.html

@arafkarsh arafkarsh ISO/IEC/IEEE 42010-2011 Standard 37 9. Architecture Rationale refers to the reasoning, justification, and decision- making process behind the design choices in a system's architecture. It captures the trade-offs, constraints, assumptions, and stakeholder concerns influencing the architectural decision. Ex. Choice of a specific NoSQL database to handle variety in data or velocity. 10. Correspondence Rule is a relationship that connects elements in different Architecture Models or between Architecture Models and other artifacts in the architecture description, for Ex. In a web application, an Architecture Model may depict functional requirements with a UML Use Case Diagram and other display system components using a UML Component Diagram. Correspondence Rules link use cases to corresponding components, ensuring traceability and consistency between requirements and system structure. Source: https://www.iso.org/standard/50508.html

@arafkarsh arafkarsh ISO/IEC/IEEE 42010-2011 Standard 38 11. Correspondence: Correspondence embodies Correspondence Rules in architecture descriptions, representing relationships between elements in different Architecture Models or artifacts. It maintains consistency, traceability, and coherence, helping stakeholders understand and analyze various aspects of the system. Ex. The Correspondence would be the actual links or mappings between the use cases in the functional requirements model and the components in the system structure model, as established by the Correspondence Rule. Source: https://www.iso.org/standard/50508.html

@arafkarsh arafkarsh 39 ISO/IEC/IEEE 42010-2022 Standard Source: https://www.iso.org/standard/74393.html Only for Architecture Descriptions of any entity of interest, including software, systems, enterprises, systems of systems, families of systems, products (goods or services), product lines, service lines, technologies and business domains.

@arafkarsh arafkarsh 40 ISO/IEC/IEEE 42010-2022 Standard 1. Entity of Interest: An entity of interest is a system, product, or service that is being architected. It is the object of the architecture description. 2. Stakeholder Perspective: It is a point of view or way of thinking about an entity of interest. It is a way of framing the architecture description to focus on the concerns of a particular stakeholder group. Ex. Customer Perspective, Developer Perspective, Manager Perspective. 3. Architecture Aspect is a particular concern or focus area of architecture. For example, an architectural aspect of an e-commerce application might be the user experience, the functional requirements, or the technical implementation. The Aspect will be reflected in an Architecture View. 4. A View component is part of an architecture description focusing on a particular architectural aspect. For example, a view component for the user experience of an e- commerce application might be a use case diagram that shows how users can interact with the system.

@arafkarsh arafkarsh ISO/IEC/IEEE 42010-2022 Standard 41 View Component (2022) Architecture Model (2011) 1 A view component is part of an Architecture Description (AD) focusing on a particular architectural aspect. An architecture model is a representation of the architecture of an entity of interest. 2 View components can be used to communicate the architecture of an Entity of Interest to specific stakeholders. Architecture models can be used to communicate the architecture of a System of Interest to all stakeholders. 3 View components can be used to focus on the concerns of particular stakeholders. Architecture models can be used to show the entire architecture of an entity of interest. 4 View components can be used to show how the different parts of the architecture fit together from a particular perspective. Architecture models can be used to show how the different parts of the architecture fit together.

@arafkarsh arafkarsh ISO/IEC/IEEE 42010-2022 Standard 42 Architecture Aspect User Experience Functional Requirements Technical Implementation Security Performance Scalability Model Kind Structural Model Behavioral Model Functional Model Data Model Performance Model Security Model Architecture View Is reflected In Architecture Viewpoint Governs View Component Use Case Diagram Wireframe Class, State Diagram Activity Diagram Sequence Diagram Data Flow Diagram Governs

@arafkarsh arafkarsh 43 ISO/IEC/IEEE 42010-2011 Standard ISO/IEC/IEEE 42010-2022 Standard

@arafkarsh arafkarsh View 44 Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives. Pearson Education India. • A view represents all (or part of) an architecture— • A way to document its architecturally significant features according to a related set of concerns. • A view captures a description of one or more of the architectural structures of the system. • Architects use views to explain the system’s architectural structure to stakeholders and demonstrate that the architecture will meet their concerns. • A view comprises a set of tangible architectural products, such as principles and models; the complete set of architectural views forms the AD (Architectural Description).

@arafkarsh arafkarsh Viewpoints 45 • It guides the process of creating a particular type of view. Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives. Pearson Education India. • Defines the concerns addressed by the view and the approach for creating and describing that aspect of the architecture.

@arafkarsh arafkarsh Perspectives 46 Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives. Pearson Education India. • Guides the design process so that the system will exhibit one or more essential qualities. • Considered Comparable to a viewpoint but for a related set of quality properties rather than a type of architectural structure. • It results in changes to the architectural views (i.e., the system’s structures) rather than creating new structures. We also use perspectives to capture common problems and pitfalls and identify solutions.

@arafkarsh arafkarsh 47 Viewpoints Functional Viewpoint Information Viewpoint Concurrency Viewpoint Development Viewpoint Deployment Viewpoint Operational Viewpoint Context Viewpoint Describes the relationships, dependencies, and interactions between the system and its environment (the people, systems, and external entities with which it interacts). Functional, Information, Concurrency Viewpoints characterize the fundamental organization of the system. The Development viewpoint exists to support the system’s construction. Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives. Pearson Education India. The Deployment & Operational viewpoints characterize the system once in its live environment. Use Case Diagram Class, ER Diagram Activity, Sequence Diagram Component Diagram Deployment Diagram System Context Diagram Level 0, 1 Network Infrastructure Diagram

@arafkarsh arafkarsh 48 Viewpoints are connected to Software Design Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives. Pearson Education India.

@arafkarsh arafkarsh Most important Views for Typical Systems 49 Viewpoints OLTP Information System Calculation Service / Middleware DSS / MIS System High Volume Web Site Enterprise Package Context High Low High Medium Medium Functional High High Low High High Information Medium Low High Medium Medium Concurrency Low High Low Medium Varies Development High High Low High High Deployment High High High High High Operational Varies Low Medium Medium High Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives. Pearson Education India.

@arafkarsh arafkarsh Architecture Perspectives 50 An architectural perspective is a • collection of architectural activities, tactics, and guidelines • used to ensure that a system exhibits a particular set of related quality properties • that require consideration across several of the system’s architectural views. Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives. Pearson Education India. The issues addressed by perspectives are often referred to as cross- cutting concerns or nonfunctional requirements of the architecture.

@arafkarsh arafkarsh 51 Functional Viewpoint Information Viewpoint Concurrency Viewpoint Development Viewpoint Deployment Viewpoint Operational Viewpoint Context Viewpoint Security Perspective Performance Perspective Availability Perspective Usability Perspective Accessibility Perspective Location Perspective Regulation Perspective Evolution Perspective Internationalization Perspective

@arafkarsh arafkarsh Architecture Perspectives 52 Viewpoints Security Performance & Scalability Availability & Resilience Evolution Context Medium Low Low Medium Functional Medium Medium Low High Information Medium Medium Low High Concurrency Low High Medium Medium Development Medium Low Low High Deployment High High High Low Operational Medium Low Medium Low Perspectives Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives. Pearson Education India.

@arafkarsh arafkarsh Perspective Catalog 53 Perspective Desired Quality Accessibility The ability of the system to be used by people with disabilities. Availability & Resilience The ability of the system to be wholly or partly operational as and when required to handle failures that could affect system availability effectively. Evolution The ability of the system to be flexible in the face of the inevitable change that all systems experience after deployment is balanced against the costs of providing such flexibility. Inter- nationalization The ability of the system to be independent of any particular language, country, or cultural group. Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives. Pearson Education India.

@arafkarsh arafkarsh Perspective Catalog 54 Perspective Desired Quality Location The ability of the system to overcome problems brought about by the absolute location of its elements and the distances between them Performance & Scalability The ability of the system to predictably execute within its mandated performance profile and to handle increased processing volumes in the future if required. Regulation The ability of the system to conform to local and international laws, quasi- legal regulations, company policies, and other rules and standards. Security The ability of the system to reliably control, monitor, and audit who can perform what actions on which resources and the ability to detect and recover from security breaches. Usability The ease with which people who interact with the system can work effectively. Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives. Pearson Education India.

@arafkarsh arafkarsh Most Important Perspectives for a Typical System 55 Perspectives OLTP Information System Calculation Service / Middleware DSS / MIS System High Volume Web Site Enterprise Package Accessibility Varies Low High High High Availability & Resilience Varies High Medium High Medium Evolution Varies Low High Varies Medium Internationalizati on Varies Low Varies High Varies Location Varies Low Low High Varies Performance & Scalability Varies High Varies High Varies Regulation Varies Low Varies Varies Varies Security Varies Low Medium High High Usability Medium Low Low High Medium Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives. Pearson Education India.

@arafkarsh arafkarsh 56 Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives. Pearson Education India. To Summarize… • Architectural Elements • Architecture • Architectural Description • Views • Viewpoints • Perspectives

@arafkarsh arafkarsh 57 Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives. Pearson Education India. Architects Role

@arafkarsh arafkarsh Viewpoints on Views 1. Case study: eCommerce App 2. Case Study: Healthcare App 58 3

@arafkarsh arafkarsh Case Study: eCommerce App 59 1. Context 5. Development 6. Deployment 7. Operational 2. Functional 3. Information 4. Concurrency

@arafkarsh arafkarsh 1. Context Viewpoint 60 Type Details Diagrams Used System Context Design – Level 0 (L0), Level 1 (L1) Stakeholders Business Owners, Developers, System Administrators, IT Support Staff, Software Architects The Context Viewpoint focuses on the relationships and interactions between the eCommerce system and its external entities. It helps stakeholders understand the system's boundaries and its place within the larger context. L0 System Context Diagram It provides a high-level overview of the eCommerce system and its external entities. The system is depicted as a single "black box" with no internal structure details. • Customers • Business Owners • Payment Gateway • Shipping Service • Inventory System L1 System Context Diagram Decomposes the eCommerce system into its primary components or subsystems, providing more detail about its architecture. Customer Service Product Service Cart Service Order Processing Payment Integration Shipping Integration

@arafkarsh arafkarsh 2. Functional Viewpoint 61 Type Details Diagrams Used Use Case Diagram, Story Maps Stakeholders Customers, Business Owners The Functional Viewpoint addresses the system’s functional requirements and services. The Use Case Diagram illustrates user interactions, • such as browsing products, • adding items to the cart, • managing user accounts, • and completing purchases. This viewpoint is essential for understanding the system's features and capabilities from an end-user perspective.

@arafkarsh arafkarsh 3. Information Viewpoint 62 Type Details Diagrams Used Class, Entity-Relationship (ER) Diagram Stakeholders Developers, Business Owner The Informational Viewpoint focuses on the organization, storage, and retrieval of data within the system. The ER Diagram depicts the relationships between entities like • products, • customers, • orders, and • categories. This viewpoint helps stakeholders understand how data is modeled, managed, and accessed in the eCommerce application. There is a big difference in Entity modeling when building Microservice based architecture.

@arafkarsh arafkarsh 4. Concurrency Viewpoint 63 Type Details Diagrams Used Sequence or Activity Diagram Stakeholders Developers, System Administrators Viewpoint addresses how the system manages multiple simultaneous user requests and handles concurrency-related aspects. The Sequence or Activity Diagram illustrates the flow of control and data between components involved in processing multiple user requests, such as the • frontend, • backend services, and • the database. This viewpoint helps stakeholders understand the system's ability to handle concurrent requests and potential bottlenecks or synchronization issues.

@arafkarsh arafkarsh 5. Development Viewpoint 64 Type Details Diagrams Used Component Diagram, Package Diagram Stakeholders Developers, Software Architects • The Development Viewpoint focuses on the system's organization into modules, components, dependencies, and interactions. • The Component Diagram or Package Diagram represents the structure of the software, showing how different components, such as the front end, backend services, and database, work together. • This viewpoint is crucial for developers and architects working on the system, as it helps them understand the codebase organization and component relationships.

@arafkarsh arafkarsh 6. Deployment Viewpoint 65 Type Details Diagrams Used Deployment Diagram Stakeholders System Administrators, IT Support Staff, DevOps (SRE) Engineers The Deployment Viewpoint addresses the system's deployment and runtime environment. The Deployment Diagram depicts the distribution of the application components across • servers, networks, and other infrastructure elements, • such as load balancers, firewalls, and storage devices. This viewpoint helps stakeholders understand how the system is deployed and operates in a production environment.

@arafkarsh arafkarsh 7. Operational Viewpoint: Infrastructure and Platform 66 Type Details Diagrams Used Network Topology Diagram, Infrastructure Diagram Stakeholders System Administrators, IT Support Staff, DevOps (SRE) Engineers • The Infrastructure and Platform View focuses on the system's underlying infrastructure, such as the hardware, operating systems, middleware, and third-party services that support the eCommerce application. • It represents the relationships between these elements, helping stakeholders understand the dependencies and requirements of the system and ensuring the necessary resources are available for its operation.

@arafkarsh arafkarsh 7. Operational Viewpoint: Monitoring & Management 67 Type Details Diagrams Used Dashboard Mockups, Graphs, Visualizations Stakeholders System Administrators, IT Support Staff, DevOps (SRE) Engineers • The Monitoring and Management View deals with the monitoring, management, and maintenance aspects of the system. • This view may include dashboard mockups, graphs, and other visualizations representing monitoring tools, performance metrics, log analysis, backup and recovery procedures, and other operational aspects. This viewpoint helps stakeholders understand how to keep the system healthy.

@arafkarsh arafkarsh Case Study: Healthcare App 68 1. Context 5. Development 6. Deployment 7. Operational 2. Functional 3. Information 4. Concurrency

@arafkarsh arafkarsh 1. Context Viewpoint 69 Type Details Diagrams Used System Context Design – Level 0 (L0), Level 1 (L1) Stakeholders Business Executives, Regulatory Authorities, End-Users This viewpoint shows how the healthcare app interacts with its environment. It illustrates relationships with external entities like healthcare providers, patients, and external systems. L0 System Context Diagram It provides a high-level overview of the Healthcare system and its external entities. The system is depicted as a single "black box" with no internal structure details. • Patient • Nurse • Doctor • Lab • Pharmacy L1 System Context Diagram Decomposes the Healthcare system into its primary components or subsystems, providing more detail about its architecture. Onboarding Process Appointment Process Diagnosis Process Lab Process Pharmacy Process

@arafkarsh arafkarsh 2. Functional Viewpoint 70 Type Details Diagrams Used Use Case Diagram, Story Maps Stakeholders Business Analysts, Development Team, User Experience Designers Focuses on the functionality provided by the healthcare app, breaking down the system into its main functionalities like Patient Management, Appointments, and Pharmacy Services. Actors 1. Patient 2. Healthcare Staff 3. Pharmacy Staff 4. Lab Technician 5. Admin Use Cases 1. Patient Registration (Onboarding) 2. Book Appointment (Appointments/Schedules) 3. View Medical Records (Patient) 4. Diagnose Patient (Diagnosis) 5. Prescribe Medication (Pharmacy) 6. Request Lab Test (Lab Process) 7. View Lab Results (Lab Process) 8. Cancel Appointment (Appointments/Schedules) Use Case Diagram: • Actors would be shown as stick figures. • Use cases would be represented as ovals. • Lines connecting actors to use cases represent interactions.

@arafkarsh arafkarsh 3. Information Viewpoint 71 Type Details Diagrams Used Class, Entity-Relationship (ER) Diagram Stakeholders Database Administrators, Backend Developers, Compliance Officers Describes the information the app manages, such as patient records, appointment schedules, and lab results, and how these pieces of information relate to each other. The ER Diagram depicts the relationships between entities like: This viewpoint helps stakeholders understand how data is modeled, managed, and accessed in the Healthcare application. Entity Attributes Patient Patient_ID (Primary Key), Name, Birthdate, Gender, Contact Healthcare Staff Staff_ID (Primary Key), Name, Position, Department Pharmacy Pharmacy_ID (Primary Key), Name, Location Lab Lab_ID (Primary Key), Name, Location Appointment Appointment_ID (Primary Key), Patient_ID (Foreign Key), Staff_ID (Foreign Key), Date, Time, Status Diagnosis Diagnosis_ID (Primary Key), Patient_ID (Foreign Key), Staff_ID (Foreign Key), Details Lab Process LabProcess_ID (Primary Key), Lab_ID (Foreign Key), Diagnosis_ID (Foreign Key), Results Pharmacy Process PharmacyProcess_ID (Primary Key), Pharmacy_ID (Foreign Key), Diagnosis_ID (Foreign Key), Medication There is a big difference in Entity modeling when building Microservice based architecture.

@arafkarsh arafkarsh 4. Concurrency Viewpoint 72 Type Details Diagrams Used Sequence / State Transition / Activity Diagrams Stakeholders Developers, Quality Assurance, System Architects Viewpoint addresses how the system manages multiple simultaneous user requests and handles concurrency-related aspects. The Sequence or Activity Diagram illustrates the flow of control and data between components involved in processing multiple user requests, such as the • frontend, • backend services, and • the database. Deals with system states and transitions, focusing on how tasks are performed concurrently within the app, such as simultaneous access to patient records or appointment scheduling.

@arafkarsh arafkarsh 5. Development Viewpoint 73 Type Details Diagrams Used Component Diagram, Package Diagram Stakeholders Developers, Software Architects • The Development Viewpoint focuses on the system's organization into modules, components, dependencies, and interactions. • The Component Diagram or Package Diagram represents the structure of the software, showing how different components, such as the front end, backend services, and database, work together. • Offers a high-level view of how the app's software components are organized and how they interact, helpful in understanding the software engineering aspects.

@arafkarsh arafkarsh 6. Deployment Viewpoint 74 Type Details Diagrams Used Deployment Diagram Stakeholders System Administrators, IT Support Staff, DevOps (SRE) Engineers The Deployment Viewpoint outlines how the healthcare app’s components will be distributed across hardware and shows how these elements are connected. The Deployment Diagram depicts the distribution of the application components across • servers, networks, and other infrastructure elements, • such as load balancers, firewalls, and storage devices. This viewpoint helps stakeholders understand how the system is deployed and operates in a production environment.

@arafkarsh arafkarsh 7. Operational Viewpoint: Infrastructure and Platform 75 Type Details Diagrams Used Network Topology Diagram, Infrastructure Diagram Stakeholders System Administrators, IT Support Staff, DevOps (SRE) Engineers • The Infrastructure and Platform View focuses on the system's underlying infrastructure, such as the hardware, operating systems, middleware, and third-party services that support the eCommerce application. • It represents the relationships between these elements, helping stakeholders understand the dependencies and requirements of the system and ensuring the necessary resources are available for its operation.

@arafkarsh arafkarsh 7. Operational Viewpoint: Monitoring & Management 76 Type Details Diagrams Used Dashboard Mockups, Graphs, Visualizations Stakeholders System Administrators, IT Support Staff, DevOps (SRE) Engineers • The Monitoring and Management View deals with the monitoring, management, and maintenance aspects of the system. • This view may include dashboard mockups, graphs, and other visualizations representing monitoring tools, performance metrics, log analysis, backup and recovery procedures, and other operational aspects. This viewpoint helps stakeholders understand how to keep the system healthy.

@arafkarsh arafkarsh Perspectives on Viewpoints Case Study: eCommerce App • Security • Performance • Availability 77 4 • Usability • Accessibility • Evolution • Internationalization • Regulation • Location

@arafkarsh arafkarsh 1. Security Perspective 78 Viewpoint Perspectives 1 Functional Ensure that the system supports secure user authentication, authorization, and access control mechanisms. 2 Informational Ensure data protection through encryption, secure storage, and data integrity measures. 3 Concurrency Address potential security vulnerabilities related to concurrent access and processing, such as race conditions or denial-of-service attacks. 4 Development Incorporate secure coding practices, vulnerability scanning, and security testing throughout the development process. 5 Deployment Implement secure network configurations, firewalls, and other security measures to protect the system's infrastructure. 6 Operational Monitor and manage security incidents, perform regular security audits, and establish incident response procedures.

@arafkarsh arafkarsh 2. Performance Perspective 79 Viewpoint Perspectives 1 Functional Optimize the performance of critical user interactions, such as browsing products or completing purchases. 2 Informational Design efficient data structures, indexes, and queries to minimize latency and maximize throughput. 3 Concurrency Implement efficient concurrency control mechanisms, such as caching or load balancing, to handle a high volume of user requests. 4 Development Use performance profiling, benchmarking, and optimization techniques during the development process. 5 Deployment Deploy the system on appropriately sized and configured hardware with sufficient resources to meet performance requirements. 6 Operational Monitor and manage system performance, identifying bottlenecks and implementing performance improvement measures as needed.

@arafkarsh arafkarsh 3. Availability Perspective 80 Viewpoint Perspectives 1 Functional Implement fault-tolerant features and graceful degradation mechanisms for critical user interactions. 2 Informational Ensure data redundancy, backup, and recovery mechanisms are in place to protect against data loss and minimize downtime. 3 Concurrency Implement measures to handle load spikes and prevent resource contention, ensuring the system remains responsive under varying loads. 4 Development Incorporate resilience and fault-tolerance principles into the system's design and development process. 5 Deployment Design a highly available infrastructure using techniques such as redundancy, replication, or failover, to minimize the impact of failures. 6 Operational Establish monitoring, incident management, and maintenance procedures to quickly detect, diagnose, and recover from failures.

@arafkarsh arafkarsh 4. Usability Perspective 81 Viewpoint Perspectives 1 Functional Design user interactions, such as browsing products or completing purchases, with user-friendly interfaces and workflows. 2 Informational Organize and display information in a clear, concise, and easily understandable format. 3 Development Incorporate user-centered design principles and user feedback into the development process. 4 Operational Monitor and manage user feedback, and usability issues, and implement improvements as needed.

@arafkarsh arafkarsh 5. Accessibility Perspective 82 Viewpoint Perspectives 1 Functional Implement accessible features, such as keyboard navigation, screen reader support, and alternative text for images. 2 Informational Design information presentation to be easily perceivable and understandable by users with various abilities, such as using appropriate text sizes, contrasts, and clear language. 3 Development Incorporate accessibility guidelines, such as the Web Content Accessibility Guidelines (WCAG), into the development process. 4 Operational Monitor and manage accessibility issues, user feedback, and implement improvements to ensure ongoing accessibility.

@arafkarsh arafkarsh 6. Evolution Perspective 83 Viewpoint Perspectives 1 Functional Design modular and extensible features that can accommodate new requirements or changes in user needs. 2 Informational Design flexible data structures and storage mechanisms that can evolve as the system's information needs change. 3 Concurrency Implement scalable concurrency mechanisms to support the system's growth and changing performance requirements. 4 Development Adopt agile development practices, version control, and continuous integration and deployment to enable iterative development and evolution. 5 Deployment Design a flexible and adaptable deployment architecture that can accommodate changes in infrastructure and technology. 6 Operational Monitor and manage the system's evolution, including changes to requirements, technologies, and the environment, to ensure its ongoing relevance and effectiveness.

@arafkarsh arafkarsh 7. Internationalization Perspective 84 Viewpoint Perspectives 1 Functional Implement support for multiple languages, currencies, and date/time formats in user interfaces and interactions. 2 Informational Design data structures and storage mechanisms for international character sets, language-specific sorting, and searching rules. 3 Development Incorporate internationalization frameworks and libraries into the development process to simplify localization and adaptation to different regions. 4 Operational Monitor and manage the system's performance and user experience in different countries and languages, adapting as necessary.

@arafkarsh arafkarsh 8. Regulation Perspective 85 Viewpoint Perspectives 1 Functional Implement features that address regulatory requirements, such as privacy controls, data protection, and age restrictions. 2 Informational Design data handling and storage mechanisms that comply with data protection regulations, such as GDPR (General Data Protection Regulation) or CCPA (California Consumer Protection Act). 3 Development Ensure the system's infrastructure and third-party services adhere to relevant regulations and standards. 4 Operational Establish processes for monitoring and managing regulatory compliance, including audits, risk assessments, and incident management.

@arafkarsh arafkarsh 9. Location Perspective 86 Viewpoint Perspectives 1 Functional Design user interactions that account for varying network conditions, such as latency or bandwidth limitations, to ensure a responsive user experience. 2 Concurrency Implement load balancing, caching, and content delivery mechanisms that optimize the system's performance in different locations. 3 Deployment Deploy the system's infrastructure and services in geographically distributed data centers or cloud regions to minimize latency and improve user experience. 4 Operational Monitor and manage the system's performance and user experience in different locations, adjusting infrastructure and configurations to optimize performance.

@arafkarsh arafkarsh Solutions Architect 1. Business Requirements 2. End User Requirements 3. Infra Requirements 87 5 4. Project Timelines 5. Global Teams 6. Global Compliance 7. Technology Selection 8. Solution Implementation 9. Solution Maintenance

@arafkarsh arafkarsh 88 Solutions Architecture Global Teams 5 Global Compliance 6 Business Requirements End User Requirements Infrastructure Requirements Budget Project Timelines 1. Functional 2. Non- Functional 1 2 3 4 0 Technology Selection Solution Implementation Solution Maintenance 7 8 9

@arafkarsh arafkarsh 89 1 2 3 4 5 6 7 8 9 Let us dive into these sections

@arafkarsh arafkarsh Requirements o Functional Requirements o Non-Functional Requirements 90 1 2

@arafkarsh arafkarsh Functional Requirements – Epics / Stories 91 Theme / Initiative 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 1

@arafkarsh arafkarsh Functional Requirements: User Story 92 Role-Feature-Reason Matrix Story Card These three elements (WHO, WHAT, WHY) are the building blocks of User stories. Element Example Role WHO: As an e-Commerce Retailer Feature WHAT: I want to know who my Gold Customers are Reason WHY: So that I sell more Element Definition WHO: Establishes the user or users or another service. WHAT: Describes the Activity – Key Axis of the Story. What the user does in the story. WHY: This describes the purpose of the story. Source: User Story A Pragmatic View, Page 9. Published 0ct 19, 2019 User stories are NOT 1. IEEE 830 Software Specs 2. Use Cases Use Cases are a combination of User Story and Acceptance Criteria 3. Scenarios 1

@arafkarsh arafkarsh Functional Requirement: Acceptance Criteria / BDD 93 Source: https://dannorth.net/introducing-bdd/ Given Customer John Doe exists When he buys products ABC for $1000 USD Then He becomes a Gold Customer BDD Construct Acceptance Criteria The definition of Done – As per Scrum These three elements (GIVEN WHEN THEN) are the building blocks of Acceptance Criteria. Typical SDLC Life Cycle Analyst Specifies the Use Case Developer Developer builds software based on Specific Usage scenarios with respect to the Use Case Tester Tester builds test cased based on Use Case Scenarios and finds issues. The Gaps identified in this process is filled up by linking the User Stories with Acceptance Criteria. 1 BDD – Behaviour Driven Development

@arafkarsh arafkarsh End User Requirements 94 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! Microservices / User Journey / Story Map & Release Cycles 2

@arafkarsh arafkarsh Non-Functional Requirements 95 Disaster Recovery Business Continuity Security & Compliances Application Performance Load & Scalability High Availability 1 2 3 4 5 6 1

@arafkarsh arafkarsh Non-Functional Requirements 96 As a system administrator, I want the system to automatically switch to a backup data centre in the event of a failure, So that services are restored quickly and data loss is minimised. Role-Feature-Reason Matrix User Story - 1: Disaster Recovery BDD Acceptance Criteria – 1: Failure Given a major data centre failure When the system detects the failure Then it must automatically failover to a secondary data centre with minimal service disruption. BDD Acceptance Criteria – 2 : RPO / RTO Given the system has failed over to a secondary data centre, When recovery processes are initiated, Then The Recovery Point Objective (RPO) must not exceed 5 minutes AND the Recovery Time Objective (RTO) must not exceed 30 minutes. BDD Acceptance Criteria – 3 : Resend Mail Given a data recovery process, When data is restored, Then data loss must not exceed the last 5 minutes of data prior to the disruption. 1 More NFR Examples: https://speakerdeck.com/arafkarsh/agile-user-stories-domain-driven-design

@arafkarsh arafkarsh Infrastructure o Hypervisors / Virtual Machines / Containers o Container Orchestration o Cloud X as a Service o Hybrid / Multi-Cloud o SDN / Zero Trust / Service Mesh 97 3

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

@arafkarsh arafkarsh Compare Type 1 and Type 2 Hypervisor 99 Feature Type 1 Hypervisor Type 2 Hypervisor Base Platform Bare-metal Host OS Performance High Lower Security Higher (due to isolation) Lower Resource Efficiency High Moderate to Low Use Case Enterprise, Data Centers Development, Testing Examples VMware ESXi, Xen VMware Workstation, VirtualBox 3

@arafkarsh arafkarsh Deployment – Updates and rollbacks, Canary Release D ReplicaSet – Self Healing, Scalability, Desired State R Worker Node 1 Master Node (Control Plane) Kubernetes Architecture 100 POD POD itself is a Linux Container, Docker container will run inside the POD. PODs with single or multiple containers (Sidecar Pattern) will share Cgroup, Volumes, Namespaces of the POD. (Cgroup / Namespaces) Scheduler Controller Manager Using yaml or json declare the desired state of the app. State is stored in the Cluster store. Self healing is done by Kubernetes using watch loops if the desired state is changed. POD POD POD BE 1.2 10.1.2.34 BE 1.2 10.1.2.35 BE 1.2 10.1.2.36 BE 15.1.2.100 DNS: a.b.com 1.2 Service Pod IP Address is dynamic, communication should be based on Service, which will have routable IP and DNS Name. Labels (BE, 1.2) play a critical role in ReplicaSet, Deployment, & Services etc. Cluster Store etcd Key Value Store Pod Pod Pod Label Selector selects pods based on the Labels. Label Selector Label Selector Label Selector Node Controller End Point Controller Deployment Controller Pod Controller …. Labels Internet Firewall K8s Virtual Cluster Cloud Controller For the cloud providers to manage nodes, services, routes, volumes etc. Kubelet Node Manager Container Runtime Interface Port 10255 gRPC ProtoBuf Kube-Proxy Network Proxy TCP / UDP Forwarding IPTABLES / IPVS Allows multiple implementation of containers from v1.7 RESTful yaml / json $ kubectl …. Port 443 API Server Pod IP ...34 ...35 ...36 EP • Declarative Model • Desired State Key Aspects N1 N2 N3 Namespace 1 N1 N2 N3 Namespace 2 • Pods • ReplicaSet • Deployment • Service • Endpoints • StatefulSet • Namespace • Resource Quota • Limit Range • Persistent Volume Kind Secrets Kind • apiVersion: • kind: • metadata: • spec: Declarative Model • Pod • ReplicaSet • Service • Deployment • Virtual Service • Gateway, SE, DR • Policy, MeshPolicy • RbaConfig • Prometheus, Rule, • ListChekcer … @ @ Annotations Names Cluster IP Node Port Load Balancer External Name @ Ingress 3

@arafkarsh arafkarsh Infrastructure Specs 101 Applications Data Runtime Middleware OS Virtualization Servers Storage Networking On Premise Applications Data Runtime Middleware OS Virtualization Servers Storage Networking IaaS Applications Data Runtime Middleware OS Virtualization Servers Storage Networking SaaS Customer Managed Cloud Provider Managed Applications Data Runtime Middleware OS Virtualization Servers Storage Networking PaaS Applications Data Container K8s OS Virtualization Servers Storage Networking PaaS Applications Data Container K8s / Knative OS Virtualization Servers Storage Networking FaaS 3

@arafkarsh arafkarsh Infrastructure: Distributed Cloud / Multi Cloud 102 Clouds Public Cloud On Premise Edge Network K8s K8s K8s Cloud On-Prem Edge DevOps o Consistent Environment o Auto Scale Across Env DevOps o Portable Workloads o AI/ML Across All Environment DevSecOps o Governance o Security Policies o Network Policies Private Cloud Technology Stack o Containers o Kubernetes o Service Mesh 3

@arafkarsh arafkarsh Analytics: Apache Flink Architecture 103 3

@arafkarsh arafkarsh SDN Architecture Software Defined Network 104 Control Plane Management Plane Data Plane Southbound APIs Northbound APIs Security Controller QoS MPLS… Routing • OpenFlow • SNMP • NetConf RESTful or Java APIs Business Applications Network Elements Controller Application Layer Control Layer Infrastructure Layer East – West APIs Multiple Controllers to avoid Single Point of Failure vRouter vSwitch vFirewall SDN Appliance – vEdge. vController vManage 3

@arafkarsh arafkarsh 105 Mana SD-WAN Edge Appliances Routers MPLS DIA DSL 4G/5G Branch Remote Data Center Branch Cloud Branch • Zero Touch Provisioning • On-Premise or Cloud • Physical or Virtual Data Plane vSmart Controllers • Routing and Security Policies • Horizontal Scaling Control Plane vManage • Single Pane of Glass • RBAC and APIs • Monitoring / Troubleshooting Management Plane Cisco SD-WAN (Viptela) Architecture vEdge vEdge vAnalytics • Carrier Performance • Bandwidth Forecasting • Machine Learning Analytics Plane SD-WAN Fabric vEdge Cloud Overlay Network Source: Cisco SD-WAN Getting Started Guide Cloud / On-Premise vBond 3

@arafkarsh arafkarsh Perimeter Security Vs. Zero Trust 106 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 3

@arafkarsh arafkarsh NIST 800-207: Zero Trust Architecture 107 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 3

@arafkarsh arafkarsh Traditional VPN Vs. Zero Trust 108 Enterprise VPN User System VPN Client User App VPN Server IAM WAN WAN Split Tunnel Optional Resource = Data, Documents, Apps, Services, Files etc. Relies on Shared secret and/or Shared root of Trust If Split tunneling is enabled only traffic to Enterprise will be tunneled. Zero Trust User System Agent PEP User App PEP Encrypted Tunnel Normal Traffic LAN IAM PDP PEP PEP • Dynamically adjust the Context • Multiple Entry Points • Support Remote and On Premise Resource Resource Resource Resource 3

@arafkarsh arafkarsh Cisco SD-Access 109 Source: Cisco SDA Enabling Intent based Networking, 2nd Edition – Page 20 o Software- Defined Access is the industry’s first intent- based net working. o An intent- based network treats the network as a single system that provides the translation and validation of the business intent (or goals) into the network and returns actionable insights. 3

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

@arafkarsh arafkarsh Service Mesh: Istio – Security Architecture 111 Source: https://istio.io/docs/concepts/security/ 3

@arafkarsh arafkarsh Product / Team o Delivery Model o Process o Timelines 112 4 5

@arafkarsh arafkarsh Product Discovery 113 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 4

@arafkarsh arafkarsh Project Timelines 114 Kanban Preparation Requirements Design Development Testing Release 1 Day – 1 Weeks Cycle Scrum 4-6 Weeks (Max) Cycle 1 or 2 Weeks Cycle also allowed 4

@arafkarsh arafkarsh Project Timelines: Kanban Board 115 Backlog Done Work breakdown Active Done To Do List A Backlog item is broken down to tasks and each Task should NOT take more than 1-3 days at max. It’s a good practice to keep all the tasks of similar size. Tasks are assigned to respective team members. 4 Work In Progress Active Done Track Task blocked due to Dependency. Once the dependent Task is ready the blocked task will be moved to Active State Max items in WIP must be 1.4x of total Resources

@arafkarsh arafkarsh Global Teams: Business Capability Centric Design 116 Business Centric Development • Focus on Business Capabilities • The 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. This leads to not only bottlenecks but also 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 5

@arafkarsh arafkarsh Management Pipeline Automation Architecture Global Teams: Engineering Pods 117 Build Design Develop Test Stage Production Specs Cloud Manager Cloud Architect Cloud Sr. Engineer Cloud Engineers Product Owner Elastic Engineering Pod 2-6 Engineers Customer 1-3 Engineers 5

@arafkarsh arafkarsh Roles & Responsibilities and Tech Stack 118 Category Role Type Responsibilities Tech Stack 1 Customer Product Owner External • Complete Product Vision • Specifications (User Stories, Acceptance Criteria) • User Stories • BDD – Acceptance Criteria 2 Engineering Pod Cloud Manager / Analyst Internal • Analyst & Specifications (User Stories, Acceptance Criteria) • Feature Management in Production & Focused on Outcome • Scrum Master & Team Management • Design Thinking • Lean Startup • Agile (Kanban) 3 Engineering Pod Cloud Architect Internal • Technology Stack, Mentor / Guiding Team on Technology • Data Models and Interface Definitions (Hexagonal Architecture) • Research & Coding (Feature and Infra Code) • Mentoring the team • Code Reviews (Functional / Infra Codes) • Deeper Understanding of Infra Stack • Event-Driven Architecture • Domain Driven Design • Data Flow Diagrams • Microservices Architecture • Data Mesh, Polyglot DB / Lang • Terraform, K8s, Service Mesh 4 Engineering Pod Cloud Sr. Engineer Internal • Mentor / Guiding Team on Technology • Product Development / Testing / Deployment • All the above • DevSecOps 5 Engineering Pod Cloud Engineer / SRE Internal • Feature Coding (Open API Specs) • Feature Test Cases (Unit, Component, Contract, Integration) • Infra Coding (Infra, Security, Network) • Build Pipeline Automation • All the above • DevSecOps 6 Engineering Pod Cloud Network / Security Lead External • Define Network Policies • Define Security Policies • Review Infra Code for Network & Security Policies • Terraform / Kubernetes • Zero Trust / Service Mesh • DevSecOps 7 Engineering Pod Cloud User Experience Lead External • Usability Guidelines • Data Flow Guidelines • Human-Computer Interface • Material Design Guidelines 5

@arafkarsh arafkarsh Compliance o Global Compliance o GDPR / PCI-DSS / HIPAA o FHIR 119 6

@arafkarsh arafkarsh Global Compliance 120 6 • General Data Protection Regulation • The GDPR aims to give individuals greater control over their personal data, and to ensure that organizations that collect, use, and store personal data do so in a transparent, secure, and lawful manner. It applies to all organizations that process personal data of individuals in the EU and EEA (European Economic Area), regardless of where the organization is based. • Payment Card Industry – Data Security Standard • PCI-DSS is a set of 12 requirements that cover various aspects of data security, including maintaining a secure network, protecting cardholder data, regularly monitoring and testing security systems, and maintaining an information security policy. Compliance Examples from Personal Data, Payment Industry & Health • Health Insurance Portability and Accountability Act • A US federal law that sets the standards for protecting sensitive patient health information. • HIPAA compliance applies to all entities that handle protected health information (PHI), including healthcare providers, insurance companies, business associates, and other entities that have access to PHI.

@arafkarsh arafkarsh FHIR – Fast Healthcare Interoperability Resources 121 6 The first draft was published in 2011 by HL7 (Health Level Seven International) Founded in 1987 FHIR is designed to be easier to implement and more expressive than previous HL7 versions. It's a next-generation standard that leverages the latest web standards and applies a more modern, resource-oriented approach. Components: • Resources: Basic building blocks in FHIR, representing healthcare concepts like patients, medications, and devices. • RESTful API: Enables access to FHIR resources over standard web protocols. Advantages: • Built for the modern web • JSON and XML formats • High level of granularity Use Cases: • Data exchange in mobile health, cloud communications, EHR-based data sharing • Real-time integration • It is also useful for analytics and machine learning applications in healthcare

@arafkarsh arafkarsh FHIR Global Adoption 122 FHIR is increasingly being adopted worldwide, not just in the United States. Various countries have FHIR implementations for national healthcare systems, including: 1. United States: Through programs like the 21st Century Cures Act, FHIR is part of the mandate for healthcare interoperability. 2. United Kingdom: NHS (National Health Service) has been moving towards FHIR for its digital services. 3. Australia: The Australian Digital Health Agency supports FHIR as a part of its National API strategy. 4. Canada: Infoway, which drives digital health in Canada, has FHIR-based services. 5. Other Countries: Many countries are adopting or considering FHIR for their healthcare systems. 6

@arafkarsh arafkarsh FHIR Data Models: Patient, Observation 123 6

@arafkarsh arafkarsh FHIR Data Models: Condition 124 6 • clinicalStatus: Describes the current status of the condition, whether it's active, in remission, etc. • verificationStatus: Indicates whether the condition is confirmed, provisional, differential, etc. • code: Specifies the type of condition or diagnosis using a standardized coding system like SNOMED CT. • subject: Refers to the patient who has the condition. • onsetDateTime: The date when the condition was first noticed or diagnosed. • recordedDate: The date when this record of the condition was created. • asserter: Refers to the healthcare provider who made the diagnosis. This resource would be extremely useful for healthcare providers to track the status of various conditions over time, and it would be an essential component in any clinical decision support system or electronic health record (EHR) system.

@arafkarsh arafkarsh FHIR Data Models: Medication, Device 125 6

@arafkarsh arafkarsh FHIR Data Models: Practitioner 126 6

@arafkarsh arafkarsh Technology Selection o Technology Selection o Backend Tech Stack o Frontend Tech Stack 127 7

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

@arafkarsh arafkarsh Technology Selection: Backend 129 7 • MongoDB: Document Database – Shopping Cart • Complex Schema (JSON) • Supports Schema Changes • Schema Extensions • Redis DB: Key Value Database – Customer, Shipping Service • Supports Schema Changes • Schema Extensions • Geo Location based on Address • Location based Features (Latitude/Longitude) • Kafka Distributed Logs (Scalable & Resilient) • Pub / Sub (Highly Scalable) • Streaming Data • Change Data Capture (CDC) • Kubernetes – Container Orchestration • Container Management • API Gateway & Traffic Routing • Network Policies • Docker – Containers • Microservice Packaging • Write Once, Deploy Anywhere • Dev / Staging / Production Parity • Istio – Service Mesh • Observability • Advanced Traffic Routing • Security: Defense in Depth • Policies: Security & Network

@arafkarsh arafkarsh Technology Selection: Front End 130 # Features Native Apps Cross Platform Hybrid Progressive Web Apps 1 Build Using Android or iOS SDK Different Programming Languages Compiled Native Platform JS, HTML, CSS Bundled as a Web App and Runs in a Web Container inside the Browser (Web View) A Web App Running with a link to run as Smart Device App and works inside a Web Browser 2 Performance High Medium Low Low 3 Code Base Multiple Codebase Single Codebase Build differently Single Codebase Single Codebase 4 Cost High Medium Medium Low 5 Hardware Support Full Limited - Additional Coding is required in some cases Bluetooth, NFC, AR/VR etc. Limited - Additional Coding is required in some cases Bluetooth, NFC, AR/VR etc. Limited - Additional Coding is required in some cases Bluetooth, NFC, AR/VR etc. 6 UX High Medium Medium Medium 7 Languages Swift for iOS Java for Android Dart for Flutter JS for React Native C# for Xamarin JS, HTML, CSS JS, HTML, CSS 8 Tools iOS SDK Android SDK Google: Flutter Facebook: React Native Microsoft: Xamarin Apache Cordova, Ionic 7

@arafkarsh arafkarsh What is Apache Flink 131 Stateful Computations over Data Streams Batch Processing Process Static & historic Data Data Stream Processing Realtime Results from Data Streams Event Driven Applications Data Driven Actions and Services Instead of Spark + Hadoop 7

@arafkarsh arafkarsh Use Case: Periodic ETL vs Streaming CTL 132 Traditional Periodic ETL • External Tool Periodically triggers ETL Batch Job Batch Processing Process Static & historic Data Data Stream Processing Realtime Results from Data Streams Continuous Streaming Data Pipeline • Ingestion with Low Latency • No Artificial Boundaries Streaming App Ingest Append Real Time Events Event Logs Batch Process Module Read Write Transactional Data Extract, Transform, Load Capture, Transform, Load State Source: GoTo: Intro to Stateful Stream Processing – Robert Metzger 7

@arafkarsh arafkarsh Use Case: Data Analytics 133 • Great for Ad-Hoc Queries • Queries changes faster than data Batch Analytics Stream Analytics Ingest K-V Data Store Real Time Events Batch Analytics Read Write Recorded Events • High Performance Low Latency Result • Data Changes faster than Queries Analytics App State State Update Source: GoTo: Intro to Stateful Stream Processing – Robert Metzger 7

@arafkarsh arafkarsh Use Case: Event Driven Application 134 • Compute & Data Tier Architecture • React to Process Events • State is stored in (Remote) Database Traditional Application Design Event Driven Application • High Performance Low Latency Result • Data Changes faster than Queries Application Read Write Events Trigger Action Ingest Real Time Events Application State Append Periodically write asynchronous checkpoints in Remote Database Event Logs Event Logs Trigger Action Source: GoTo: Intro to Stateful Stream Processing – Robert Metzger 7

@arafkarsh arafkarsh Cloud: Amazon Web Services o Infra: IAM / VPC / Route 53 / EC2 / S3 / RDS o Security: WAF / Shield / Guard Duty / Inspector o DevOps and Build Process o Container Orchestration o Monitoring & Logging 135 7

@arafkarsh arafkarsh AWS IAM – Identity & Access Management 136 Key Components: • Users: Represents a person or service. • Groups: A collection of users. • Policies: Defines permissions. • Roles: Defines a set of permissions for making AWS service requests. Security Perspective: • Granular permission control • Multi-Factor Authentication (MFA) IAM lets you manage access to AWS services and resources securely. 7 Source: AWS IAM: https://aws.amazon.com/iam/

@arafkarsh arafkarsh AWS VPC – Virtual Private Cloud 137 Key Components: • Subnets: Range of IP addresses in your VPC. • Route Tables: Set of rules for traffic routing. • Internet Gateways: Enable access to the internet. Security Perspective: • Isolation of resources • Network Access Control Lists (ACLs) • Security Groups VPC lets you provision an isolated section of the AWS Cloud where you can launch resources in a virtual network. Source: AWS VPC: https://aws.amazon.com/vpc/ 7

@arafkarsh arafkarsh AWS Route 53: DNS Service 138 7 Generic Features: • Domain Registration: Register domain names. • DNS Routing: Translate domain names to IP addresses. Source: AWS Route 53: https://aws.amazon.com/route53/ Amazon Route 53 is a scalable domain name system (DNS) service.

@arafkarsh arafkarsh AWS EC2 – Elastic Compute Cloud 139 Amazon EC2 provides scalable computing capacity in the AWS cloud. It allows you to run virtual machines, known as instances. Generic Features: • Instance Types: Variety of instances for different workload requirements. • Elastic Load Balancer: Distributes incoming traffic across instances. • Auto-Scaling: Automatically adjusts computing capacity. Source: AWS EC2: https://aws.amazon.com/ec2/ Run cloud-native and enterprise applications Amazon EC2 delivers secure, reliable, high- performance, and cost- effective compute infrastructure to meet demanding business needs. Scale for HPC applications Access the on-demand infrastructure and capacity you need to run HPC applications faster and cost- effectively. Develop for Apple platforms Build, test, and sign on- demand macOS workloads. Access environments in minutes, dynamically scale capacity as needed, and benefit from AWS’s pay-as- you-go pricing. Train and deploy ML applications Amazon EC2 delivers the broadest choice of compute, networking (up to 400 Gbps), and storage services purpose-built to optimize price performance for ML projects. Use Cases 7

@arafkarsh arafkarsh AWS S3: Simple Storage Service 140 Amazon S3 provides scalable object storage. Generic Features: • Storage Classes: Different classes for various use-cases (Standard, Intelligent-Tiering, One Zone, Glacier). • Data Lifecycle Management: Automated rules to move data between storage classes. Source: AWS S3: https://aws.amazon.com/s3/ 7

@arafkarsh arafkarsh AWS RDS 141 • Managed Databases: Supports multiple database engines like MySQL, PostgreSQL, and SQL Server. • High Availability: Offers Multi-AZ deployments. • Scalability: Read replicas and automatic vertical scaling. • Backup: Automated backups and manual snapshots. • Monitoring: Integrated with CloudWatch. Source: AWS RDS: https://aws.amazon.com/rds/# 7

@arafkarsh arafkarsh AWS WAF: Web Application Firewall 142 Key Components: • Rules: Customizable rules to block, allow, or monitor web requests. • WebACLs: A set of rules acted upon when a request is forwarded. AWS WAF is a web application firewall that helps protect web apps from common web exploits. Security Perspective: • SQL Injection and XSS protection • Rate-based rules to mitigate DDoS attacks Source: AWS WAF: https://aws.amazon.com/waf/ 7

@arafkarsh arafkarsh AWS Shield 143 Key Components: • Shield Standard: Network and transport layer protections. • Shield Advanced: Additional protections against more significant attacks. Security Perspective: • Real-time DDoS attack diagnosis • Protection against infrastructure and application layer attacks AWS Shield is a managed DDoS protection service. Source: AWS Shield: https://aws.amazon.com/shield/ 7

@arafkarsh arafkarsh AWS Guard Duty 144 GuardDuty is a threat detection service that continuously monitors for malicious activity. Key Components: • Findings: Alerts are generated when a potential threat is detected. Security Perspective: • Anomaly detection • Unauthorized access monitoring Source: AWS Guard Duty: https://aws.amazon.com/guardduty/ 7

@arafkarsh arafkarsh AWS Inspector 145 Key Components: • Assessment Targets: Specific AWS resources to assess. • Assessment Templates: Configurations for assessment runs. AWS Inspector is an automated security assessment service to improve security and compliance. Security Perspective: • Vulnerability assessment • Security best practice checks Source: AWS Inspector: https://aws.amazon.com/inspector/ 7

@arafkarsh arafkarsh Analytics: AWS Kinesis – Architecture (Flink) 146 AWS Cloud Kinesis Data Analytics Elastic Kubernetes Service Job Manager Task Manager Task Manager Task Manager S3 Bucket Auto Scaling Zookeeper Cloud Watch Cloud Watch Logs Flink Web UI 7

@arafkarsh arafkarsh AWS DevOps 147 1. AWS CodeCommit: This fully managed source control service hosts Git repositories. It’s similar to GitHub but tightly integrated into the AWS ecosystem. 2. AWS CodeBuild: This build service compiles your code, runs tests, and produces packages ready to deploy. 3. AWS CodeDeploy: This service automates code deployments to any instance, including EC2 instances and servers running on-premises. 4. AWS CodePipeline: This CI/CD service automates your release process’s build, test, and deployment phases. 5. AWS CloudFormation: This IaC service helps you manage resources as code. It lets you define resource stacks using templates. 6. AWS Elastic Beanstalk: This Platform as a Service (PaaS) simplifies deploying and scaling web applications. 7. AWS OpsWorks: This configuration management service uses Chef or Puppet for automation. 8. AWS X-Ray: A distributed tracing service that helps you debug and analyze applications. 7

@arafkarsh arafkarsh AWS Build Process 148 1. Source Control: The first step usually involves committing code to AWS CodeCommit. The repository can be private or public. 2. CI Pipeline: After committing the code, you set up a CI pipeline using AWS CodePipeline. This would usually integrate with AWS CodeBuild for compiling the code and running unit tests. 3. Build Phase: AWS CodeBuild will create a build environment (Docker container or a managed build environment), clone your repository, and then execute the build specifications which are usually defined in a buildspec.yml file. 4. Artifact Storage: Post-build, the artifacts are usually stored in Amazon S3 for future deployments. 5. Deployment: AWS CodeDeploy takes over here. It deploys the build artifacts to EC2 instances, Lambda functions, or even on-prem servers. It can also integrate with Elastic Beanstalk or ECS/EKS for containerized deployments. 6. Monitoring: Once the application is deployed, monitoring and logging come into play using AWS CloudWatch and AWS X-Ray. 7. IaC: Throughout the pipeline, AWS CloudFormation can be used to handle infrastructure as code. 8. Configuration Management: If you need to manage configuration and automate operational tasks, you can integrate AWS OpsWorks into your pipeline. 7

@arafkarsh arafkarsh AWS Stack for Deployment: Containers 149 Feature AWS ECS AWS EKS AWS Fargate Managed Service Yes Yes Yes (Serverless) Orchestration Engine ECS Kubernetes ECS or Kubernetes Ease of Use Easier (Fewer abstractions) Moderate (Kubernetes learning curve) Easiest (Serverless) AWS Integration Deep Moderate Deep (with ECS), Moderate (with EKS) Scalability High High High Resource Optimization Instance Level Node Level Task/Container Level Customizability Moderate High (Kubernetes-based) Limited Data Persistence EFS, EBS EFS, EBS EFS, EBS Networking Features AWS VPC, Service Discovery AWS VPC, Kubernetes Networking AWS VPC, Service Discovery Monitoring Tools CloudWatch, X-Ray CloudWatch, X-Ray, Prometheus CloudWatch, X-Ray Security Features IAM Roles, Security Groups IAM Roles, Kubernetes RBAC IAM Roles, Security Groups Batch Processing ECS Batch Kubernetes Jobs ECS Batch or Kubernetes Jobs Pricing Model Pay for underlying EC2 instances Pay for control plane and worker nodes Pay per vCPU and GB Memory per second 7

@arafkarsh arafkarsh Monitoring & Management 150 Feature AWS CloudWatch AWS X-Ray AWS App Mesh AWS CloudTrail Primary Use-Case Monitoring & Alarming Distributed Tracing Service Mesh (Microservices) Governance & Auditing Data Collection Metrics, Logs, Alarms Request traces Metrics, Request/Response data API Call Logs Integration Broad AWS & Third-party support AWS services & SDKs AWS services & Envoy Proxy Broad AWS & Third-party support Real-Time Monitoring Yes Yes Yes Near Real-Time (Some Latency) Historical Data Yes Partial No Yes (up to 7 years) Granularity High (down to 1-second) Fine-grained trace data Fine-grained routing control Event-Level Anomaly Detection Yes No No No Routing Control No No Yes No Error Analytics Limited Deep (Error rates, latencies) Limited Limited (API Errors) Infrastructure View Yes Partial (Only as part of traces) No (Focused on Service-to- Service) Yes (API-Level) Supported Languages N/A (Infrastructure Level) Java, Node.js, .NET, Go, etc. N/A (Infrastructure Level) N/A (Infrastructure Level) Service Health Dashboard Yes No Partial (through CloudWatch) No Compliance HIPAA, GDPR, etc. HIPAA HIPAA HIPAA, GDPR, etc. Pricing Model Pay-as-you-go Pay-per-trace Pay-per-processed GB of data Pay-per-event Alerts Yes No (But can send trace data to CloudWatch) No (But can integrate with CloudWatch) Yes (via CloudWatch Alarms) 7

@arafkarsh arafkarsh Solution Implementation o Specs, Architecture, Design & Packaging o 15 Factor Methodology o Composable Enterprise Architecture o Event-Driven Architecture o Microservices Architecture o Domain Driven Design 151 8

@arafkarsh arafkarsh Specs, Architecture, Design, Packaging 152 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 8

@arafkarsh arafkarsh 153 12 Factor App Methodology 4 Backing Services Treat Backing services like DB, Cache as attached resources 5 Build, Release, Run Separate Build and Run Stages 6 Process Execute App as One or more Stateless Processes 7 Port Binding Export Services with Specific Port Binding 8 Concurrency Scale out via the process Model 9 Disposability Maximize robustness with fast startup and graceful exit 10 Dev / Staging / Production Parity Keep Development, Staging and Production as similar as possible Checkout the Shift – Left in DevOps (Slide No. 48., Section 9) 11 Logs Treat logs as Event Streams 12 Admin Process Run Admin Tasks as one of Process (Eg. DB Migration, Software upgrades, etc..) Factors Description 1 Codebase One Code base tracked in revision control 2 Dependencies Explicitly declare dependencies 3 Configuration Configuration driven Apps Source: https://12factor.net/ 8

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

@arafkarsh arafkarsh API Architecture Maturity Levels 155 Source: https://www.apiscene.io/lifecycle/7-layers-of-api-architecture-maturity/ • REST & gRPC – API Communication in Microservices: https://www.apiscene.io/lifecycle/rest-grpc-api-communication-in-microservices/ • A Postman API Governance Collection: https://www.apiscene.io/lifecycle/a-postman-api-governance-collection/ • Impact of Distributed Architecture to API Lifecycle: https://www.apiscene.io/lifecycle/what-is-the-impact-of-distributed-architecture-to-api-lifecycle/ • 8

@arafkarsh arafkarsh Composable Enterprise Architecture 156 Source: Gartner: Future of Applications: Delivering the Composable Enterprise | Why does it matter? On Demand Scalability Service & Apps Integrated with Clients & Devices Automated On Demand Services Self Service Options for App & Data MASA Mesh App & Service Architecture Enterprise Data Available, Accessible, & Integrated into Data Flow Delivers > Packaged Business Capabilities 8

@arafkarsh arafkarsh Architecture Styles, Patterns & Design Patterns 157 • Component-based • Client-server • Event-driven • Layered Architecture • Monolithic application • Plug-ins • Publish-subscribe • Service Based • Service-Oriented • Microservices Architecture Style: 1. How to Organize the Code, 2. Creating high-level modules & layers and how they interact each other. Architecture Patterns: A Recurring solution to a recurring problem. Providing the Solution to an Architecture Style. Ex. How a request is processed from the outer layer to inner layer. • Three Tier • Micro Kernel • Model View Controller • Event Sourcing and CQRS • Domain Driven Design Design Patterns: The scope of the Design Patterns is much narrower compared to an Architecture Pattern. It focuses on instantiating an object, and its behaviour of the object. • Adapter • Builder / Factory • Saga • Repository • Aggregate Root Wider Scope Narrow Scope Critical Architectural Styles & Patterns 8

@arafkarsh arafkarsh Event Driven & Pub Sub Architectures 158 Check Out Cart 4. Data Durability (Replication) 5. Ordering Guarantee (Per Partition) Use Partition Key Kafka Producer API Kafka Consumer API Order Topic (Total Partitions 6) Kafka Storage Replicated Logs Kafka Cluster 5 6 7 8 7 8 What will happen to Inventory Instance 7 and 8? As there are only 6 Partitions Kafka can serve ONLY 6 consumers within a partition 1 2 3 4 1 2 3 4 3 4 Service Instances 2 5 1 All the above Consumers will get same orders available in the Order Topic Broadcast Orders to following Consumers Order Consumer Group Inv Consumer Group Multiple Subscriber 1. Highly Scalable 2. Multi Subscriber 3. Loosely Coupled Systems 8

@arafkarsh arafkarsh Cloud-Native Architecture 159 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 / DDD / ES & CQRS Data Mesh / K8s/Kafka Clusters / Infra Patterns Containers / Kubernetes / Mesh Terraform Bulkhead, Circuit Breaker, Green / Blue Deployment Microservices Characteristics 8

@arafkarsh arafkarsh Microservices Architecture 160 /ui /productms /auth /order Gateway Virtual Service Deployment / Replica / Pod Nodes Istio Sidecar - Envoy Load Balancer Kubernetes Objects Istio Objects Firewall P M C Istio Control Plane UI Pod N5 v2 Canary v2 User X = Canary Others = Stable 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 8

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

@arafkarsh arafkarsh Monolithic Data Models across bounded contexts. Source: Patterns, Principles and Practices of DDD – Page 124 This model shows multiple responsibilities of the shared Model – Product. This is a classic example of Big Ball of Mud. 162 8

@arafkarsh arafkarsh Product Model in Different Bounded Context 163 Catalogue Product • Product UUID • Name • Description • SKU • Product Price • Currency • Product Images • Brand • Manufacturer Cart Product • Product UUID • Name • Value • Quantity o Product Model has different attributes in different contexts. So, it avoids storing all the Product info in one place and then sharing that across multiple Bounded Contexts (Microservices). o If you want to change Product details related to Package, then only Order Bounded Context (Microservice) needs to be updated. Order Product • Product UUID • Name • Value • Quantity • Shipping Type • Package Type 8

@arafkarsh arafkarsh 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 164 8

@arafkarsh arafkarsh Event Sourcing Intro 165 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 8

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

@arafkarsh arafkarsh Event Sourcing: Case Study: Patient Diagnosis and Treatment 167 Payment • Register Patient • Search Doctor Commands • Add Patient Info • Add Details • Add BP • Add Diagnosis • Add Prescription Events • Doctor Scheduled • Patient Added • Patient Info Added • Details Added • BP Added • Diagnosis Added • Prescription Added • Add Medicine • Add Bill • Medicine Added • Bill Prepared • Payment Approved • Payment Declined • Cash Paid The patient registers and makes an appointment with the doctor. Patient details and history is recorded. The doctor makes the diagnosis and creates the prescription. The patient buys the medicine from the Pharmacy. A ward appointment is scheduled and disclosed to the ward if a patient needs to be admitted. Once the treatment is over, the patient is discharged from the Hospital. Microservices • Diagnosis • Prescription • Hospital Bill • Discharge Summary Patient Journey thru Treatment Process Registration • Add Doctor • Add Appointment • Add Patient File • Doctor Added • Appointment Added • Patient File Added ES Aggregate 2 4 Processes 1 Doctors Diagnosis Pharmacy Ward Patient • Add Checkup • Add Treatment • Add Food • Add Discharge • Checkup Added • Treatment Added • Food Added • Discharge Added Core Domain Sub Domain Sub Domain Sub Domain Sub Domain Generic Domain Sub Domain 3 8

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

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

@arafkarsh arafkarsh Microservices Testing Strategies 170 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% Ubiquitous Language Domain Expert Analyst Developers QA Design Docs Test Cases Code Architect 8

@arafkarsh arafkarsh Microservices Testing Strategy 171 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 8

@arafkarsh arafkarsh Microservices Testing Scenarios / Tools 172 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 8

@arafkarsh arafkarsh Chaos Engineering – Load / Stress / Performance 173 Chaos Monkey Randomly disables production instances Chaos Kong Similar to Chaos Monkey, simulates an outage of an entire Amazon availability zone. Doctor Monkey Checks CPU load, Memory usage and removes it from network if the health is bad. Janitor Monkey Search for unused resources and disposes them. Compliance Monkey Finds instances that don’t adhere to best-practices and shuts them down. Latency Monkey 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/ 8

@arafkarsh arafkarsh SANS Cloud Security Architecture Principles 174 Source: RSA Conference 2019 – A Cloud Security Architecture workshop. Dave Shackleford Sr. Instructor SANS Institute Think Components Design for Failure Always Think of Feedback Loops Use Different Storages Options Built-In Security at every Layer CENTRALIZATION Focus on Centralization Standards & Automation Design for Elasticity 8

@arafkarsh arafkarsh Solution Maintenance o SDLC: Agile / DevOps o Shift Left o CALMS Framework and SRE o DevSecOps Playbook (US Dept of Defense) 175 9

@arafkarsh arafkarsh SDLC: Agile & DevOps 176 Build Design Develop Test Deploy Ops Specs Agile DevOps Go Live Support Specs / Design / Development CI/CD and Tests Automation Operations 9

@arafkarsh arafkarsh Production Environment Continuous Monitoring Fully Automated Continuous Deployment Shift Left – Operational Concerns 177 • 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 9

@arafkarsh arafkarsh DevOps 178 Source: https://www.atlassian.com/devops/what-is-devops 9

@arafkarsh arafkarsh 5 DevOps Principles – CALMS Framework 179 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. 9

@arafkarsh arafkarsh Implementing CALMS – DevOps Principles 180 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 9

@arafkarsh arafkarsh class SRE implements DevOps – CALMS 181 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 9 SRE – Site Reliability Engineering

@arafkarsh arafkarsh DevSecOps 182 Recommended by US DoD (Dept of Defense) DevSecOps Best Practices Source: Page 17 US DoD Enterprise DevSecOps Fundamentals 9

@arafkarsh arafkarsh 6 DevSecOps Playbook 183 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 9

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