Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Solution Architecture

Solution Architecture

To Build Cloud Native Apps
Using Composable Enterprise Architecture

To Manage
SpecOps: From Specs to Ops

1. Business Requirements
2. End-user Requirements
3. Infrastructure Requirements
4. Project Timelines
5. Global Teams
6. Global Compliance
7. Technology Selection
8. Solution Implementation
9. Solution Maintenance

Araf Karsh Hamid

March 18, 2023
Tweet

More Decks by Araf Karsh Hamid

Other Decks in Technology

Transcript

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

    View Slide

  2. @arafkarsh arafkarsh
    Management
    Pipeline Automation
    Architecture
    SpecOps Workflow - SDLC
    2
    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

    View Slide

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

    View Slide

  4. @arafkarsh arafkarsh
    Enterprise Architecture
    4
    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.

    View Slide

  5. @arafkarsh arafkarsh
    Solutions Architecture
    5
    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

    View Slide

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

    View Slide

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

    View Slide

  8. @arafkarsh arafkarsh
    Non-Functional Requirements
    8
    Disaster
    Recovery
    Business
    Continuity
    Security &
    Compliances
    Application
    Performance
    Load &
    Scalability
    High
    Availability
    1

    View Slide

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

    View Slide

  10. @arafkarsh arafkarsh
    Functional Requirements: User Story
    10
    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

    View Slide

  11. @arafkarsh arafkarsh
    Functional Requirement: Acceptance Criteria / BDD
    11
    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

    View Slide

  12. @arafkarsh arafkarsh
    End User Requirements
    12
    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

    View Slide

  13. @arafkarsh arafkarsh
    Infrastructure: Servers / Virtual Machines / Containers
    13
    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

    View Slide

  14. @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
    14
    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

    View Slide

  15. @arafkarsh arafkarsh
    Infrastructure Specs
    15
    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

    View Slide

  16. @arafkarsh arafkarsh
    Analytics: Apache Flink Architecture
    16
    3

    View Slide

  17. @arafkarsh arafkarsh
    SDN Architecture
    Software Defined Network
    17
    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

    View Slide

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

    View Slide

  19. @arafkarsh arafkarsh
    Traditional VPN Vs. Zero Trust
    19
    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

    View Slide

  20. @arafkarsh arafkarsh
    Cisco SD-Access
    20
    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

    View Slide

  21. @arafkarsh arafkarsh
    Infrastructure: Service Mesh: Istio Security
    21
    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

    View Slide

  22. @arafkarsh arafkarsh
    Infrastructure: Distributed Cloud / Multi Cloud
    22
    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

    View Slide

  23. @arafkarsh arafkarsh
    Product Discovery
    23
    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

    View Slide

  24. @arafkarsh arafkarsh
    Project Timelines
    24
    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

    View Slide

  25. @arafkarsh arafkarsh
    Project Timelines: Kanban Board
    25
    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

    View Slide

  26. @arafkarsh arafkarsh
    Global Teams: Business Capability Centric Design
    26
    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

    View Slide

  27. @arafkarsh arafkarsh
    Management
    Pipeline Automation
    Architecture
    Global Teams: Engineering Pods
    27
    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

    View Slide

  28. @arafkarsh arafkarsh
    Global Teams: Roles & Responsibilities
    28
    Category Role Type Responsibilities
    1 Customer Product Owner External
    • Complete Product Vision
    • Specifications
    2 Engineering Pod
    Cloud Manager /
    Analyst
    Internal
    • Analyst & Specifications (User Stories, Acceptance Criteria)
    • Feature Management in Production & Focused on Outcome
    • Scrum Master & Team Management
    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)
    4 Engineering Pod Cloud Sr. Engineer Internal
    • Mentor / Guiding Team on Technology
    • All the Responsibilities of Cloud Engineer also
    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
    6 Engineering Pod
    Cloud Network /
    Security Lead
    External
    Specialist
    • Define Network Policies
    • Define Security Policies
    • Review Infra Code for Network & Security Policies
    7 Engineering Pod
    Cloud User
    Experience Lead
    External
    Specialist
    • Usability Guidelines
    • Data Flow Guidelines
    5

    View Slide

  29. @arafkarsh arafkarsh
    Global Compliance
    29
    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.

    View Slide

  30. @arafkarsh arafkarsh
    Technology Selection
    30
    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

    View Slide

  31. @arafkarsh arafkarsh
    Technology Selection: Front End
    31
    # 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

    View Slide

  32. @arafkarsh arafkarsh
    Technology Selection: Backend
    32
    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

    View Slide

  33. @arafkarsh arafkarsh
    Analytics: AWS Kinesis – Architecture (Flink)
    33
    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

    View Slide

  34. @arafkarsh arafkarsh
    What is Apache Flink
    34
    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

    View Slide

  35. @arafkarsh arafkarsh
    Use Case: Periodic ETL vs Streaming CTL
    35
    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

    View Slide

  36. @arafkarsh arafkarsh
    Use Case: Data Analytics
    36
    • 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

    View Slide

  37. @arafkarsh arafkarsh
    Use Case: Event Driven Application
    37
    • 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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  41. @arafkarsh arafkarsh
    API Architecture Maturity Levels
    41
    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

    View Slide

  42. @arafkarsh arafkarsh
    Composable Enterprise Architecture
    42
    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

    View Slide

  43. @arafkarsh arafkarsh
    Architecture Styles, Patterns & Design Patterns
    43
    • 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

    View Slide

  44. @arafkarsh arafkarsh
    Event Driven & Pub Sub Architectures
    44
    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

    View Slide

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

    View Slide

  46. @arafkarsh arafkarsh
    Microservices Architecture
    46
    /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

    View Slide

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

    View Slide

  48. @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.
    48
    8

    View Slide

  49. @arafkarsh arafkarsh
    Product Model in Different Bounded Context
    49
    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

    View Slide

  50. @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
    50
    8

    View Slide

  51. @arafkarsh arafkarsh
    Event Sourcing Intro
    51
    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
    Snapshot
    Event store
    Single Source of Truth
    Greg
    Young
    8

    View Slide

  52. @arafkarsh arafkarsh
    Event Sourcing: Case Study: Shopping Site – Event Sourcing / CQRS
    52
    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

    View Slide

  53. @arafkarsh arafkarsh
    Event Sourcing: Case Study: Patient Diagnosis and Treatment
    53
    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

    View Slide

  54. @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
    54
    • 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

    View Slide

  55. @arafkarsh arafkarsh
    Migration Design Patterns: Strangler Fig Pattern
    55
    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

    View Slide

  56. @arafkarsh arafkarsh
    Microservices Testing Strategies
    56
    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

    View Slide

  57. @arafkarsh arafkarsh
    Microservices Testing Strategy
    57
    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

    View Slide

  58. @arafkarsh arafkarsh
    Microservices Testing Scenarios / Tools
    58
    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

    View Slide

  59. @arafkarsh arafkarsh
    Chaos Engineering – Load / Stress / Performance
    59
    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

    View Slide

  60. @arafkarsh arafkarsh
    SANS Cloud Security Architecture Principles
    60
    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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  65. @arafkarsh arafkarsh
    Implementing CALMS – DevOps Principles
    65
    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

    View Slide

  66. @arafkarsh arafkarsh
    class SRE implements DevOps – CALMS
    66
    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

    View Slide

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

    View Slide

  68. @arafkarsh arafkarsh
    6
    DevSecOps Playbook
    68
    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

    View Slide

  69. @arafkarsh arafkarsh 69
    DREAM | AUTOMATE | EMPOWER
    Araf Karsh Hamid :
    India: +91.999.545.8627
    https://speakerdeck.com/arafkarsh
    http://www.slideshare.net/arafkarsh
    https://www.linkedin.com/in/arafkarsh/
    https://www.youtube.com/user/arafkarsh/playlists
    http://www.arafkarsh.com/
    @arafkarsh
    arafkarsh

    View Slide