PPT Summarised

16 November 2024
16:30

Project Triple Constraints

• Scope
• Time
• Cost

Three-Sphere Model for Systems Management

In any project, there are two sides.

Client side controls the: cost, time, functionality
Tech side controls the: people, process, technology

Software Engineering is about managing the client side and defining the tech side while
managing risk.

SDLC Phases
Boehm's First Law
Errors are most frequent during requirements and design activities and are more
expensive the later they are removed.

Incremental Model of SD

Rapid Application Development Model

Iterative Model

Spiral Model = Iterative + Waterfall Model

Agile Model = Iterative + Incremental Model

Roadmap and Story Mapping
A high-level visual plan that aligns themes, initiatives, and epics over a timeline.

User Story Workflow

INVEST Model by Bill Wake

Criteria for Estimating a User Story is based on

• Complexity
• Effort
 • Risk & Uncertainty
• Dependencies
• Testability & Validation
• Team familiarity and Skill level
Story Pointing for Estimation
Fibonacci Series

User Story Prioritisation

Can be done through..
• MoSCoW Method
• Value vs Effort Matrix

Splitting User Stories

 • Vertical Slices - Vertical splitting involves breaking down a user story into
smaller stories that each deliver a complete slice of functionality from end to
end. Each split provides a usable feature that can be tested and potentially
released.
• Horizontal Slices - Horizontal splitting involves breaking down a user story by
layers of the application, such as the front-end, back-end, or database. Each split
focuses on a specific technical layer rather than delivering a complete feature.

Technical Debt
the cost of additional work that results from prioritizing speed over quality in software
development. Technical debt can occur when:
• Developers take shortcuts to meet deadlines
• Teams rush to release new features
• Developers don't reorganize code to reflect their understanding of new features
• Developers don't test code before releasing it
• Developers don't document code
• Developers don't implement tools with a business case
• Developers install hardware without proper cable or port markings
Types of Technical Debt

Quality Assurance

Test-Driven Development vs Business-Driven Development

Plan-Do-Check-Act Cycle
Automated Testing

Unit Testing
Tests individual components or units of code in isolation to ensure they work as
expected.
• Data Flow Testing
o Focuses on the flow of data across variables to identify issues like
uninitialized variables or incorrect data usage.
• Branch Coverage
 o Ensures every decision point (if/else, switch) in the code executes at least
once.
• Control Flow Testing
o Analyzes the execution path of the program.
• Statement Coverage
o Ensures every line of code runs at least once.

Integration Testing
Tests how different modules or components interact with each other.
• Incremental Testing
o Integrates modules step-by-step and tests interactions after each
addition.
• Non-Incremental Testing
o Combines all modules at once and tests the entire system.

System Testing
Tests the complete system to ensure it meets requirements.
• End-to-End Testing
o Validates the complete workflow from start to finish.
• Sanity Testing
o Quick checks on major functionality after minor changes.
• Smoke Testing
o Initial testing to check if the build is stable.
• Black Box Testing
o Tests system functionality without looking at the code
• Monkey Testing
o Random inputs to check system stability.

User Acceptance Testing (UAT)

Validates the system against business requirements, ensuring it works for end users.
• Alpha Testing
 o Conducted in a controlled environment by internal teams or stakeholders.
• Beta Testing
o Conducted by a limited group of external users.
• Operational Acceptance Testing (OAT)
o Checks operational aspects like backup, recovery, and support readiness.

Performance Testing
Evaluates the system's responsiveness and stability under different conditions.
• Load Testing
o Measures performance under expected user loads.
• Stress Testing
o Tests system behavior under extreme load.
• Spike Testing
o Sudden, extreme load changes to observe stability.
• Endurance Testing
o Long-duration testing to check stability over time.
• Scalability Testing
o Measures system’s ability to scale resources.

Security Testing
Ensures the system is protected from vulnerabilities and threats.
• Vulnerability Testing
o Identifies system weaknesses that attackers could exploit.
• Penetration Testing
o Simulates real-world attacks to identify security gaps.
• Security Configuration Testing
o Ensures the system’s security settings are correctly implemented.

Usability Testing
Tests how easily end-users can use the application.
• Cross-Browser Testing
 o Verifies functionality across different browsers.
• Exploratory Testing
o Performed without predefined test cases to identify usability issues.

Compatibility Testing
Ensures the application works across different environments, devices, or
systems.
• Operating System Compatibility
o Test a desktop app on Windows, macOS, and Linux.
• Device Compatibility
o Verify that a mobile app functions on Android and iOS devices.
• Network Compatibility
o Test a web app’s performance on 4G, 5G, and Wi-Fi connections.

Sprint Cycle vs Release Cycle

The sprint cycle is the period in which the team completes selected backlog
items, while the release cycle focuses on delivering finished product
increments to users.
Scaling in Agile - Source

Scrum of Scrums
Technique used to coordinate the work of multiple Scrum teams working on the
same/related projects. Each daily scrum within a sub-team ends by designating
one member as an “ambassador” to participate in a daily meeting with
ambassadors from other teams, called the Scrum of Scrums.

Purpose:
o Make cross-team collaboration easier in case of complex projects involving large
teams.
o Enhance team productivity in individual Scrum teams.
o Make prioritising tasks easier through collaborative discussions.
o Solve problems that arise during the course of the development.
o Keep the deliverables of the project on track.
o Gives a clear picture of the path taken by the team to achieve the goal to all
members.
o Ensure that the work of one Scrum team isn't a hindrance to other teams.
o Combine the productive output of multiple teams effectively into a single entity.
Use Case:
Scenario: A mid-sized software development company with multiple Scrum teams
working on different components of a large product.
Use Case: The company wants to maintain the simplicity of Scrum while ensuring
effective coordination and communication across teams. Scrum of Scrums
meetings help identify and resolve dependencies and impediments that affect
multiple teams, ensuring smooth progress.

SAFe - Scaled Agile Framework : Prescriptive Approach

Combines Lean, Agile, and DevOps principles.
SAFe provides guidance at all levels of software development: Team, Program,
LargeScale Solution (Value Stream), and Portfolio, so as to align enterprise-level
strategies with the team working on a solution.
In a general Agile framework, there is a Scrum and Kanban team that comprises a
development team, scrum master, and product owner. Such a framework works
when there are 2-3 teams with 5-9 team members.
When the number of teams extends (say there are 10 teams), a single product
owner and a scrum master for a team are not sufficient enough to manage
requirements and facilitate the teams. To handle multiple teams at a larger scale,
there is a program layer in the SAFe framework. The program layer has roles like
Product Manager who provides guidelines to all the product owners working for
individual teams. Then, there are Release Train Engineers who act like chief
impediment officers for all the teams. A System Architect defines, communicates,
and shares an architectural and technical vision for the Agile Release Train (ART).
At a large stream level, there is a value stream engineer to manage Agile Release
Trains (ARTs), a Solution Manager to define vision and roadmap for the solution,
and a Solution Architect for the technical and architectural vision of the solution
under development.
Moving up, at the portfolio level there are epic owners and enterprise architects
who define the base for a portfolio of solutions. For this, a Portfolio Kanban is used
that defines an MVP of the solution, a lean business case, and starts
implementation on approval. An enterprise architect works across value streams
and programs to help provide the strategic technical direction that can optimize
portfolio outcomes. The enterprise architect often may act as an epic owner for
enabler epics.

SAFe is a prescriptive framework. It organizes and structures how software

development activities should be performed and in what order.

Use Case:
Scenario: A large enterprise with multiple departments and teams working on
complex, interdependent projects.
Use Case: The organization needs a structured approach to scale Agile practices
across the entire enterprise. SAFe provides comprehensive guidance at the team,
program, and portfolio levels, integrating Lean, Agile, and DevOps principles to
deliver high-quality products efficiently.
LeSS - Large Scale Scrum
It focuses on maintaining a single product backlog, a single product owner, a signle
Definition of Done, and synchronized sprints across all teams.

Each sprint starts with Sprint Planning1 wherein team members along with the
product owner divides their product backlog items. This is followed by Sprint
Planning2 wherein the team discusses their strategies for feature development.

In LeSS, coordination amongst the teams is the responsibility of the teams itself
and there are no assigned coordinators for it. These teams coordinate through
scrum meetings which include product owners, scrum masters, and rotating
representatives from each team.

Depending upon how large the team is, there are two LeSS frameworks available
for adoption:
LeSS: Up to eight teams (of eight members each)
LeSS Huge: Up to a few thousand members on one product

Use Case:
Scenario: A growing tech startup with several Scrum teams working on a single
product.
Use Case: The startup wants to scale its Scrum practices without adding significant
complexity. LeSS allows them to maintain a single product backlog and
synchronize sprints across all teams, ensuring alignment and collaboration while
staying true to Scrum principles.

DaD - Disciplined Agile Delivery : Gola-Driven Approach

allows teams to choose the best practices and strategies for their specific context.
DaD is a hybrid approach to software development that extends the strategies
from various Agile frameworks- Kanban, LeSS, Lean development, Extreme
Programming, Agile Modeling, etc.
DaD provides contextual advice regarding viable alternatives and trade-offs that
address the different situations and problems one may find himself in. By
describing what works, what doesn’t, and why, Disciplined Agile Delivery
increases the possibility of adopting strategies that will work to deal with a
situation.
There are 10 roles that a DaD project has. While five of them are primary, five are
secondary. The primary roles will occur, regardless of the scale that a project has;
while the secondary roles are added to the primary roles as the demand or
scalability expands.
 Use Case:
Scenario: A consulting firm that delivers customized software solutions to various
clients with different needs.
Use Case: The firm requires a flexible framework that can be tailored to different
project contexts. DaD provides a goal-driven approach, allowing teams to choose
the best practices from Scrum, Lean, and Kanban, covering the entire delivery
lifecycle from inception to transition.

Comparison

Aspect Scrum of Scrums SAFe (Scaled Agile LeSS (Large-Scale DaD (Disciplined
Framework) Scrum) Agile Delivery)

Purpose Coordinate multiple Scale Agile across Scale Scrum with Comprehensive Agile
Scrum teams large enterprises minimal changes delivery framework

Key Focus Coordination and Structured guidance Simplicity and Flexibility and goal-
communication at multiple levels synchronization driven approach

Implementation Simple, minimal Complex, requires Simple, minimal Flexible, integrates

changes to Scrum significant training additional roles various practices

Roles Scrum Master, Team Multiple roles (e.g., Scrum Master, Various roles based
Representatives Release Train Product Owner, on context
Engineer) Teams
Artifacts Scrum Artifacts Additional artifacts Scrum Artifacts Various artifacts
(Product Backlog, (e.g., Program based on context
Sprint Backlog) Backlog)

Meetings Daily Scrum of Multiple levels of Sprint Planning, Various meetings

Scrums planning and review Review, Retrospective based on context

Scalability Suitable for small to Suitable for large Suitable for medium Suitable for various
medium-sized groups enterprises to large groups organizational sizes

Complexity Low High Low to Medium Medium

Training Minimal Extensive Moderate Moderate

Required

Best For Organizations already Large enterprises Organizations Organizations

using Scrum needing structured wanting to scale needing a flexible
scaling Scrum framework

Requirements Engineering and Designing

Business Requirements Document (BRD)

How to Create:
o Gather Business Requirements
◦ Conduct workshops, interviews, and surveys with stakeholders.
◦ Use tools like brainstorming, fishbone diagrams, or mind mapping.
o Identify Stakeholders
◦ Map out key stakeholders and their expectations.
◦ Define Stakeholder Roles using the RACI Matrix (Responsible,
Accountable, Consulted, Informed)
o Define Business Objectives
◦ Clearly outline what the business wants to achieve (SMART goals).
o Document Scope
◦ Define what is included and excluded in the project.
Create High-Level Requirements
◦ Outline major features or processes that meet business objectives.
o Define Success Metrics
◦ Use measurable KPIs to evaluate success.

Software Requirements Specification (SRS)

Components:
o Functional Requirements - Specific Features
o Non-functional Requirements - Performance, Security, Scalability
o System Architecture and Design Constraints
o Data Models and Interactions
o Acceptance Criteria

How to Create:
o Input from BRD
◦ Translate business-level goals into detailed software specifications.
o Define Functional Requirements
◦ Use user stories, use cases, or functional decomposition to list the system
features.
 ◦ Use Use Case Modelling to break down functional requirements into
specific use cases
o Detail Non-Functional Requirements
◦ Address performance, reliability, scalability, and security aspects.
o Specify System Behaviour
◦ Create diagrams (ERDs, UMLs, flowcharts) to represent interactions.
◦ Use UML (Unified Modelling Language) to visualise system interactions
and workflows
o Include Acceptance Criteria
◦ Define testable conditions to ensure the software meets requirements.
o Review and Validate
◦ Collaborate with stakeholders for validation.
Note:
All requirements in SRS must be traced back to BRD

Functional Requirements Specification (SRS)

Components:
o Functional Requirements
o Use Case Scenarios
o System Interfaces
o User Interface (UI) Requirements
o Data Requirements
o Acceptance Criteria
 Requirement Gathering Tools
• Brainstorming
• Fishbone Diagram
• Mind Mapping

System Architecture

Monolithic Arch
In a monolithic architecture, all components of the application are tightly
integrated into a single, cohesive unit. This means that the user interface, business
logic, and data access layers are all part of one codebase.
• Advantages:
Simplicity: Easier to develop, test, and deploy as a single unit.
Performance: Can be more efficient in terms of performance since all components
are in one process.
• Disadvantages:
Scalability: Difficult to scale individual components independently.
 Maintenance: As the application grows, it becomes harder to manage and update.

Client-Server Arch
This architecture divides system functions between servers and client devices.
Clients request services and resources from servers, which process these requests
and return the appropriate responses.
• Advantages:
Centralized Control: Easier to manage and secure data centrally on the server.
Scalability: Servers can be scaled independently to handle more clients.
• Disadvantages:
Dependency: Clients are dependent on the server's availability and performance.
Complexity: Requires network communication, which can introduce latency and
complexity.

Service-Oriented Arch
SOA is a design pattern where components are modular and expose functionalities
through services. These services communicate over a network using protocols like
SOAP or REST.
• Advantages:
Reusability: Services can be reused across different applications.
Interoperability: Services can be developed in different languages and
technologies.
• Disadvantages:
Overhead: Communication between services can introduce overhead.
Complexity: Managing and orchestrating multiple services can be complex.

MicroServices Arch
In a microservices architecture, a system is composed of small, independent
services that communicate via APIs. Each service is responsible for a specific
business function and can be developed, deployed, and scaled independently.
• Advantages:
Scalability: Individual services can be scaled independently based on demand.
 Flexibility: Teams can develop and deploy services independently, using different
technologies if needed.
• Disadvantages:
Complexity: Managing a large number of services can be challenging.
Communication Overhead: Inter-service communication can introduce latency and
complexity.

Kanban
Kanban is a visual workflow management method used to optimize and manage
work processes. Originating from lean manufacturing, it helps teams visualize
their work, limit work-in-progress (WIP), and maximize efficiency.
Kanban Practices

1. Visualize the Workflow: Use a Kanban board to represent the workflow stages
and tasks.
2. Limit Work-in-Progress (WIP): Set limits on the number of tasks in each stage to
prevent overloading.
3. Manage Flow: Monitor and manage the flow of tasks through the workflow to
ensure smooth progress.
4. Make Process Policies Explicit: Clearly define and communicate the rules and
policies governing the workflow.
5. Implement Feedback Loops: Regularly review and adjust the process based on
feedback and performance metrics.
6. Improve Collaboratively, Evolve Experimentally: Continuously improve the
process through collaboration and experimentation.

Kanban Board
 A Kanban board is a visual tool used to implement Kanban practices. It typically
includes the following elements:

1. Columns: Represent different stages of the workflow (e.g., To Do, In Progress,

Done).
2. Cards: Represent individual tasks or work items. Each card contains details
about the task.
3. WIP Limits: Indicate the maximum number of tasks allowed in each column to
prevent bottlenecks.
4. Swimlanes: Horizontal rows that categorize tasks by type, priority, or team.
 Kanban Metrics
o Lead and Cycle Time
Cycle Time = Work in Progress/Throughput
Cycle Time = Time between starting and finishing a task

o Flow Efficiency

FE = Actual Working time/Total Cycle Time

When to use Kanban?

Projects requiring flexibility, like maintenance or bug fixes.
◦ Microsoft adopted Kanban for bug tracking and saw productivity improvements.
Workflows with continuous delivery needs.
◦ Help desks using Kanban ensure tickets are resolved without overloading
agents.

ScrumBan
 Scrumban is a hybrid Agile methodology that combines elements of Scrum and
Kanban. It leverages the structured framework of Scrum with the flexibility and
continuous flow principles of Kanban. Scrumban is designed to help teams
transition from Scrum to Kanban or to provide a more flexible approach to
managing work.

• Benefits of Scrumban Over Scrum and Kanban

Flexibility:
Over Scrum: Scrumban allows for more flexibility in planning and execution.
Unlike Scrum's fixed-length sprints, Scrumban uses a continuous flow approach,
making it easier to adapt to changing priorities.
Over Kanban: Scrumban incorporates some of Scrum's structured elements, such
as regular review and planning meetings, which can provide more structure than
pure Kanban.

Improved Workflow Management:

Over Scrum: Scrumban uses Kanban's visual boards and WIP limits to manage
workflow more effectively, reducing bottlenecks and improving efficiency.
Over Kanban: Scrumban retains Scrum's roles and ceremonies, which can help
maintain team discipline and focus.

Enhanced Planning and Review:

Over Scrum: Scrumban allows for more dynamic planning, as tasks are pulled into
the workflow as needed rather than being planned at the start of a sprint.
 Over Kanban: Scrumban includes regular planning and review meetings, which can
help teams stay aligned and continuously improve.

• Where Scrumban is Used

Transitioning Teams: Teams transitioning from Scrum to Kanban often use
Scrumban to gradually adopt Kanban practices while retaining some familiar
Scrum elements.
Maintenance and Support Teams: Teams that handle unpredictable and varying
workloads, such as IT support or maintenance teams, benefit from Scrumban's
flexibility and continuous flow.
Project-Based Work: Teams working on projects with evolving requirements and
priorities can use Scrumban to balance structure and adaptability.

DevOps and CI/CD

DevOps
DevOps is a software development methodology that accelerates the delivery
of higher-quality applications and services by combining and automating the
work of software development, and IT operations teams. The goal of DevOps
is to shorten the software development lifecycle and deliver high-quality
software continuously.

Key Principles of DevOps

1. Collaboration: Encourages close cooperation between development and
operations teams to improve efficiency and reduce silos.
2. Automation: Automates repetitive tasks such as testing, deployment, and
monitoring to increase speed and reduce errors.
3. Continuous Integration (CI): Developers frequently integrate code into a
shared repository, where automated builds and tests are run.
4. Continuous Delivery (CD): Ensures that code changes are automatically
prepared for a release to production, enabling frequent and reliable
deployments.
5. Monitoring and Logging: Continuously monitors applications and
infrastructure to detect issues early and ensure performance and reliability.
6. Infrastructure as Code (IaC): Manages and provisions computing infrastructure
through machine-readable configuration files, rather than physical hardware
configuration.

Benefits of DevOps
o Faster Time to Market: Accelerates the development and deployment process,
allowing for quicker delivery of new features and updates.
o Improved Quality: Automated testing and continuous integration help catch bugs
early, leading to more reliable software.
o Enhanced Collaboration: Breaks down barriers between development and
operations teams, fostering a culture of shared responsibility.
o Scalability: Enables efficient scaling of applications and infrastructure to meet
changing demands.
o Increased Efficiency: Automation of repetitive tasks reduces manual effort and
frees up time for more strategic work.

DevOps Development
 DevOps development approach as the combination of three main principles
1. The principle of flow: Developing flow/systems thinking
a. ◦ Making smaller batches
b. ◦ Taking on fewer tasks and eliminating waste
c. ◦ Ensuring visibility and transparency
d. ◦ Automating processes
2. The principle of feedback: Amplifying feedback loops
a. ◦ Solving the smallest problems as soon as possible
b. ◦ Minimizing quality control issues
c. ◦ Analyzing and learning from mistakes
3. The principle of continuous Learning: Developing a culture of continuous
learning
◦ Encouraging and supporting initiatives
◦ Keeping daily processes relevant, effective, and up-to-date
◦ Preparing for failure

When to Use DevOps

o Frequent Releases: When your organization needs to release software updates
frequently and reliably, DevOps practices can streamline the process and reduce
time to market.
o High Collaboration: If your development and operations teams need to work
closely together, DevOps fosters better communication and collaboration.
o Continuous Improvement: When your organization values continuous
improvement and feedback, DevOps practices like continuous integration and
continuous delivery (CI/CD) can help.
o Scalability: If your application needs to scale rapidly to meet changing demands,
DevOps practices can automate and optimize scaling processes.
o Automation: When there are many repetitive tasks that can be automated,
DevOps tools can increase efficiency and reduce human error.

When Not to Use DevOps

o Stable, Infrequent Releases: If your software does not require frequent
updates and is stable, the overhead of implementing DevOps might not be
justified.
o Regulated Environments: In highly regulated industries where changes need
extensive validation and approval, the rapid changes encouraged by DevOps
might not be suitable.
o Legacy Systems: If your organization relies heavily on legacy systems that are
difficult to automate or integrate with modern DevOps tools, the transition might
be challenging.
o Lack of DevOps Culture: If your organization is not ready to embrace the
cultural shift required for DevOps, such as collaboration and shared
responsibility, it might not be the right time to implement it.
o Resource Constraints: If your organization lacks the necessary resources (time,
budget, skilled personnel) to implement and maintain DevOps practices, it might
be better to wait until these resources are available

Deployment and its Types

Recreate Deployment
In a recreate deployment, the existing version of the application is completely
shut down before the new version is deployed.

Process: Stop the old version -> Deploy the new version -> Start the new
version.
Use Case: Suitable for applications where downtime is acceptable and the
deployment process is simple

Rolling Dep
Rolling deployment gradually replaces instances of the old version with the
new version without downtime.
Process: Deploy the new version to a subset of instances -> Gradually replace
all instances -> Ensure all instances run the new version.
Use Case: Ideal for applications requiring high availability, as it minimizes
downtime.

Blue-Green Dep
Blue-green deployment involves maintaining two identical environments
(blue and green). One environment runs the current version, while the other
is used to deploy the new version.

Process: Deploy the new version to the idle environment -> Switch traffic to
the new environment -> The old environment becomes idle.
Use Case: Useful for minimizing downtime and ensuring a quick rollback if
needed.

Canary Dep
Canary deployment releases the new version to a small subset of users before
rolling it out to the entire user base.
Process: Deploy the new version to a small group -> Monitor performance
and feedback -> Gradually increase the user base.
Use Case: Effective for testing new features and ensuring stability before full
deployment.

A/B Testing Dep

A/B testing deployment involves running two versions of the application
simultaneously to compare performance and user response.

Process: Deploy both versions (A and B) -> Direct traffic to both versions ->
Collect and analyze data -> Decide which version performs better.
Use Case: Useful for experimenting with new features and optimizing user
experience based on real-world data.

Shadow Dep
Shadow deployment involves deploying the new version alongside the old
version without exposing it to users. The new version processes real user
requests in the background for testing purposes.
 Process: Deploy the new version in shadow mode -> Route real traffic to both
versions -> Compare outputs without affecting users.
Use Case: Ideal for testing new features and performance under real-world
conditions without impacting the user experience.

Comparison

CI/CD Benefits
o Faster Deployment
o Improved Quality
o Better Collaboration
o Reliable Deployments
o Rapid Feedback

Containers and Dockers

4 Phases of Cloud Adoption

1. Opportunistic: Private Server
2. Cloud-First: Upload all data to cloud while also maintaining private Server. Cloud
Enabled
3. All-In: Get rid of the privets server and optimize for cloud only. Cloud optimized
4. Cloud-Native: Build on the cloud, through clouds, for cloud

MicroServices
A microservice is a tightly scoped, strongly encapsulated, loosely coupled,
independently deployable, and independently scalable application
component.
Three core objectives
◦ Development agility
◦ Deployment flexibility
◦ Precise scalability

APIs (Application Programming Interfaces)

APIs are sets of rules and protocols that allow different software applications
to communicate with each other. They define the methods and data formats
that applications can use to request and exchange information.

Where and Why APIs Are Used

o Integration: APIs enable different systems and applications to work together. For
example, a payment gateway API allows an e-commerce site to process payments
without building its own payment processing system.
o Automation: APIs can automate tasks by allowing applications to interact
programmatically. For instance, a marketing platform might use an API to
automatically post updates to social media.
o Data Access: APIs provide access to data and services. For example, a weather
app uses an API to fetch current weather data from a weather service.
o Extensibility: APIs allow developers to extend the functionality of an application.
For example, plugins and extensions for web browsers often use APIs to interact
with the browser.

Example of API Usage

Example: Google Maps API
 Scenario: A travel website wants to display maps and location information to
its users.
How It Works: The travel website uses the Google Maps API to embed
interactive maps on its pages. The API allows the website to request map
data, display locations, and provide directions.
Why It's Used: Using the Google Maps API saves the travel website from
having to develop its own mapping solution. It leverages Google's robust and
reliable mapping service, providing a better user experience.
How APIs Work
Request: An application sends a request to the API endpoint, specifying the
desired action (e.g., fetching data, updating information).
Processing: The API processes the request, interacting with the underlying
system or database.
Response: The API returns a response to the application

Containers
Containers are isolated units that package an application and all its
dependencies, including libraries, binaries, and configuration files. This
ensures that the application runs the same way regardless of where it is
deployed.
Containerization is a lightweight form of virtualization that involves
encapsulating an application and its dependencies into a container. This
container can run consistently across different computing environments,
from a developer's laptop to a production server.

Key Concepts
o Container Engine: A container engine, such as Docker, is used to create, manage,
and run containers. It provides the necessary tools and runtime environment for
containers.
o Images: A container image is a lightweight, standalone, and executable package
that includes everything needed to run a piece of software. Images are used to
create containers.
o Orchestration: Tools like Kubernetes are used to manage and orchestrate
multiple containers, ensuring they work together seamlessly, scale efficiently,
and recover from failures.
Benefits of Containerization
o Consistency: Containers ensure that applications run consistently across
different environments, reducing the "it works on my machine" problem.
o Isolation: Containers provide process and resource isolation, which enhances
security and stability by preventing conflicts between applications.
o Portability: Containers can be easily moved between different environments,
such as development, testing, and production, without modification.
o Scalability: Containers can be quickly scaled up or down to handle varying
loads, making them ideal for microservices architectures.
o Efficiency: Containers are lightweight and use fewer resources compared to
traditional virtual machines, as they share the host system's kernel.

Common Use Cases

o Microservices: Containerization is often used to deploy microservices, where
each service runs in its own container, allowing for independent scaling and
updates.
o DevOps: Containers are integral to DevOps practices, enabling continuous
integration and continuous deployment (CI/CD) pipelines.
o Cloud Computing: Containers are widely used in cloud environments to deploy
applications in a scalable and efficient manner.
Example Tools
o Docker: A popular containerization platform that simplifies the creation,
deployment, and management of containers.
o Kubernetes: An open-source container orchestration platform that automates
the deployment, scaling, and management of containerized applications.

Containers vs Virtual Machines

Containers and virtual machines (VMs) are both technologies used to create
isolated environments for running applications, but they differ significantly
in their architecture and use cases. Here's a comparison:
Attribute/Platform Containers Virtual Machines

Architecture • Lightweight • Heavyweight

• Isolation • Strong Isolation
• Dependencies • Own OS

Performance • High Efficiency • High Resource Req

• Low Startup Time • Long Startup Time

Portability • Consistent • Consistent

• Portable • Low Portability

Use Case • MicroServices • Legacy Apps

• DevOps • High Security/ Regulated Environment
• Cloud-Native • Precise Resource Allocation

Containers
Architecture:

Lightweight: Containers share the host operating system's kernel and run as
isolated processes.
Isolation: Provides process and resource isolation using namespaces and
control groups (cgroups).
Dependencies: Packages the application and its dependencies, but not the
entire operating system.
Performance:

Efficiency: Containers are more efficient and have lower overhead because
they share the host OS kernel.
Startup Time: Containers start up quickly, often in seconds.
Portability:
Consistency: Containers ensure that applications run consistently across
different environments.
Portability: Easily portable across different environments, such as
development, testing, and production.
Use Cases:

Microservices: Ideal for deploying microservices architectures.

DevOps: Integral to CI/CD pipelines and DevOps practices.
Cloud-Native Applications: Widely used in cloud environments for scalable
and efficient deployments.
Virtual Machines (VMs)
Architecture:

Heavyweight: VMs include a full operating system along with the application
and its dependencies.
Isolation: Provides strong isolation by running on a hypervisor, which
virtualizes the hardware.
Dependencies: Each VM includes its own OS, which can be different from the
host OS.
Performance:

Efficiency: VMs have higher overhead due to the need to virtualize hardware
and run a full OS.
Startup Time: VMs take longer to start, often in minutes.
Portability:

Consistency: VMs provide consistent environments but are less portable due
to their larger size.
Portability: VMs can be moved between hypervisors, but the process is more
complex compared to containers.
Use Cases:
 Legacy Applications: Suitable for running legacy applications that require a
specific OS.
Isolation: Provides strong isolation for applications with high security
requirements.
Resource Allocation: Useful for scenarios where precise resource allocation
and isolation are needed.
Summary
Containers: Lightweight, efficient, and portable. Ideal for modern, cloud-
native applications and microservices.
VMs: Heavyweight, with strong isolation and resource allocation. Suitable for
legacy applications and scenarios requiring full OS environments

DevSecOps
Ensuring that the project is secure by design and not just by verification from a
penetration test undertaken postpartum. It is an approach that integrates security
practices into every phase of the software development lifecycle.

Key Principles of DevSecOps

o Shift Left Security: Incorporates security early in the development process,
starting from the planning phase.
o Automation: Uses automated tools to perform security checks and tests
continuously throughout the development lifecycle.
o Collaboration: Encourages collaboration between development, security, and
operations teams to identify and address security issues promptly.
o Continuous Monitoring: Implements continuous monitoring to detect and
respond to security threats in real-time.
Where DevSecOps Is Used
o Agile and DevOps Environments: DevSecOps is commonly used in Agile and
DevOps environments where rapid development and deployment cycles are the
norm. Integrating security into these processes helps ensure that security is not
compromised in the rush to deliver software quickly.
o Cloud-Native Applications: In cloud-native applications, where infrastructure
and applications are highly dynamic, DevSecOps practices help maintain security
across diverse and rapidly changing environments.
o Highly Regulated Industries: Industries such as finance, healthcare, and
government, which have stringent security and compliance requirements,
benefit from DevSecOps by ensuring that security is built into every stage of the
development process.
 Why DevSecOps Is Important
o Proactive Security: By integrating security early and continuously, DevSecOps
helps identify and fix vulnerabilities before they become critical issues.
o Faster Time to Market: Automating security checks and integrating them into the
CI/CD pipeline reduces the time needed for security reviews, allowing for faster
releases.
o Cost Efficiency: Addressing security issues early in the development process is
less costly than fixing them after deployment.
o Improved Collaboration: DevSecOps fosters a culture of shared responsibility for
security, improving collaboration between development, security, and
operations teams.

Example of DevSecOps in Action

Scenario: A financial services company is developing a new online banking
application.

Implementation: The company adopts DevSecOps practices by integrating

security tools into their CI/CD pipeline. Automated security tests are run on
every code commit, and security vulnerabilities are addressed immediately.
Benefits: This approach ensures that the application is secure from the start,
reduces the risk of security breaches, and allows the company to comply with
regulatory requirements more efficiently.

Security Testing Methods

o SAST (Static Application Security Testing)
Delves into your code (without actually executing it)to pinpoint
vulnerabilities and weaknesses proactively.
o DAST (Dynamic Application Security Testing)
Emulating real-world hacking attempts, helps uncover gaps and
vulnerabilities in your application's defenses.
o IAST (Interactive Application Security Testing)
IAST combines SAST's and DAST's strengths. It employs software
instrumentation, either actively or passively, to monitor application
performance and security.
o RASP (Runtime Application Self-Protection)
RASP leverages real-time data from your application to detect and counteract
attacks as they occur autonomously, without the need for manual
intervention.