SHRI VISHNU ENGINEERING COLLEGE FOR WOMEN: BHIMAVARAM

(AUTONOMOUS)
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CLOUD COMPUTING
UNIT – V

1. Serverless computing/ Function-as-a-Service(Faas)

 Serverless computing architecture
 Public cloud serverless platforms
 Open-source serverless platforms
2. IoT, Edge and Fog Computing
 Introduction
 IoT applications
 Cloud-Centric IoT
 Edge and Fog Computing
3. DevOps and Dynamic Deployment on the Cloud
 Software Development Life Cycle
 Agile Methodology
 Devops
 Infrastructure-As-Code(IaC)
 TOSCA
4. Quantum Cloud Computing
 Quantum Computing
 Quantum Cloud Computing
 Quantum Cloud Computing Services

DEPT OF CSE / SVECW/MNR Page 1

 Serverless computing/ Function-as-a-Service(Faas)
Problem with containers: Containers simplify deployment by bundling code, runtime, and
dependencies, but still require developers to:

 Set resource allocations (CPU, memory).

 Manage networking and scaling.
 Handle infrastructure concerns.

Shift in focus: Businesses want developers to focus on business logic, not infrastructure.

What is Serverless Computing?

 Serverless ≠ No Servers
 Servers still exist, but cloud providers handle them automatically.
Developers only write functions, and the platform manages provisioning, scaling, and fault
tolerance.
 Functions as a Service (FaaS) is the most popular serverless model.

How FaaS Works

1. Developers write functions in high-level languages.

2. Functions are event-driven (triggered by HTTP requests, database updates, file uploads,
etc.).
3. Provider automatically:
o Allocates resources (stateless containers).
o Runs and scales the function on demand.
o Terminates containers after execution.
4. Billing: Only pay for actual execution time, not idle resources (unlike VMs or traditional
containers).

Advantages of Serverless / FaaS

 Cost efficiency → No payment for idle CPU/memory.

 Scalability → Auto-scaling based on demand.
 Agility & faster time-to-market → Focus on logic, not ops.
 Fault tolerance built-in → Provider ensures reliability.
 Ideal for event-driven apps → APIs, microservices, IoT, data pipelines.

Market Growth

 Serverless computing market projected to reach $36.84 billion by 2028,

with a CAGR of 21.71% due to:
o Lower operational costs.
o Faster setup & reduced complexity.
o Expanding use cases (serverless runtimes & serverless databases).

Evolution & Key Platforms

 2014: AWS Lambda (first commercial FaaS platform, inspired by OpenLambda project).
 2016 onwards: Major cloud vendors joined:

DEPT OF CSE / SVECW/MNR Page 2

 o Microsoft Azure Functions
o Google Cloud Functions
o IBM OpenWhisk
 Open-source projects: OpenWhisk, OpenFaaS, Kubeless, etc.

Serverless Computing Architecture:

This figure represents serverless as an event-driven system.

1. Event Sources

 HTTP Requests (via API Gateway)

 Message Queues
 Object Storage Notifications (e.g., file upload in S3)
 Other Events (e.g., DB updates, monitoring triggers)

2. Event Queues

 Incoming events are placed into queues.

 Queues handle request entry and exit ensuring reliability and ordering.

3. Dispatcher

 Core scheduler of the system.

 Responsibilities:
o Maps events to the right function worker.
o Ensures load balancing.
o Monitors workloads.
o Auto-scales workers up/down depending on demand.

4. Function Workers

 Stateless containers where actual user-defined code (functions) run.

 Each worker runs only for the execution duration.
 Once completed, resources are freed.

DEPT OF CSE / SVECW/MNR Page 3

Serverless Platforms & Communities:

Public Cloud Serverless Platforms (FaaS)

Public cloud serverless frameworks provide a fully managed, end-to-end environment where
developers only need to focus on writing functions (business logic).
The cloud provider takes care of:

 Infrastructure provisioning
 Automatic scaling
 Deployment & monitoring
 Fault tolerance
 Billing only for actual execution time

These platforms are widely used because they eliminate the operational burden on developers.

1. AWS Lambda

 Pioneer in serverless computing (first widely adopted FaaS platform).

 Supports multiple languages: Python, [Link], Java, Go, C#, Ruby, etc.
 Integrates tightly with AWS services (S3, DynamoDB, API Gateway, CloudWatch).
 Use cases: Event-driven apps, real-time data processing, IoT, backend APIs.
 Billing: Based on request count and execution time (ms granularity).

2. IBM Cloud Functions

 Based on Apache OpenWhisk (open-source FaaS project).

 Supports [Link], Python, Java, Swift, PHP, Go, Ruby.
 Strong in event-driven integration with IBM Cloud services and third-party APIs.
 Focus on enterprise adoption with flexibility and open-source support.
 Use cases: Data pipelines, IoT, cognitive computing (AI/ML integration).

3. Google Cloud Functions

 Google’s FaaS offering, deeply integrated with Google Cloud ecosystem.

 Supports [Link], Python, Go, Java, .NET, Ruby, PHP.
 Strong integration with Firebase (for mobile/web apps), Pub/Sub, BigQuery, and AI/ML
services.
 Use cases: Mobile app backends, real-time analytics, chatbots, APIs.
 Billing: Pay only for invocation, compute time, and memory used.

DEPT OF CSE / SVECW/MNR Page 4

4. Microsoft Azure Functions

 Launch: Introduced by Microsoft Azure in 2016 as part of its serverless ecosystem.

 Type: Event-driven Function-as-a-Service (FaaS) platform.
 Core Idea: Run code triggered by events (HTTP requests, message queues, timers, file
uploads, etc.) without provisioning or managing infrastructure.
 Language support: C#, JavaScript, F#, Java, PowerShell, Python
 Triggers & Bindings:
o Rich integration with Azure services (Blob Storage, Cosmos DB, Event Hub,
Service Bus).
o Bindings simplify connecting functions to event sources and outputs.
 Auto-scaling:
o Functions scale automatically based on event load.
 Pricing Model:
o Billing granularity: Per-second resource consumption + number of executions.
o Free tier:
 1 million invocations/month free.
 400,000 GB-seconds/month free.
o After free quota:
 $0.20 per 1 million executions.
 $0.000016 per GB-second of memory consumption.

 Use Cases: Real-time data processing, Backend APIs and microservices, IoT data ingestion,
Scheduled/automated tasks, Chatbots and event-driven workflows.

OpenFaaS (Open-Source Serverless Platform):

 Created by: Alex Ellis, later expanded into a community-driven project.
 Approach: Functions are packaged as Docker or OCI images, so developers can write in
any language.
 Deployment Flexibility: Can run on:
o Kubernetes (K8s)
o Docker Swarm
o On-premises, Cloud, or Edge (IoT)

Key Features

1. Language Templates
o Pre-built Dockerfile templates for different languages (from OpenFaaS template
store).
o Developers just plug in their business logic.
2. Scalability
o Supports auto-scaling based on:
 Requests per second (RPS)
 Concurrency
 CPU usage
o Defined using YAML templates and managed via FaaS CLI.
3. Invocation Types
o Synchronous → Immediate execution + HTTP response.
o Asynchronous → Handled via NATS Streaming Queue.
 Gateway instantly responds with HTTP 202/204 Accepted.

DEPT OF CSE / SVECW/MNR Page 5

 
Function executes later in the background.
4. Monitoring & Metrics
o Uses Prometheus to collect metrics (invocations, latency, execution time).
o Alert Manager works with Prometheus to trigger scale-up/scale-down actions.
5. Function Management
o CRUD operations: Create, Update, Delete, Invoke functions.
o Managed via OpenFaaS Gateway (CLI, UI, or REST).
6. Commercial Editions
o Community Edition → Free, hobby/personal use.
o Standard Edition → Production-ready workloads.
o Enterprise Edition → Advanced enterprise features & support.

OpenFaaS Architecture Components:

Flow of Events:

1. External Event Sources (HTTP requests, message queues, etc.) → Sent to OpenFaaS
Gateway.
2. Gateway:
o Handles both sync & async requests.
o For async: passes requests to NATS Streaming Queue.
o Issues CRUD commands to Resource Provider.
3. Resource Provider:
o Deploys/updates function replicas on Kubernetes / Docker Swarm / Cloud cluster.
4. Prometheus:
o Pulls performance metrics from the Gateway.
o Supports monitoring & auto-scaling.
5. Alert Manager:
o Works with Prometheus to trigger scale actions.
6. Function Workers (fn()):
o Run stateless functions encapsulated in Docker/OCI containers.

Apache OpenWhisk:

 It is a Open-source serverless computing platform.

 Dynamically executes functions (actions) in response to events (triggers) at any scale.

DEPT OF CSE / SVECW/MNR Page 6

  Uses Docker containers for packaging, deployment, and scaling.

 Runs on local servers, Cloud, Kubernetes, OpenShift, and Docker Compose.

 Supported Languages: Go, Java, .NET, PHP, Python, Ruby, Scala, Swift, Rust.
 Developers can also use custom runtimes via Docker images.

Core Concepts in OpenWhisk

1. Actions
o Functions written by developers in any supported language.
o Encapsulate the business logic.
o Executed inside Docker containers when triggered.
2. Triggers
o Event channels that listen for incoming events.
o Example: A trigger might fire when a message arrives in a queue, or when an HTTP
request is received.
3. Rules
o Bind Triggers → Actions.
o Define conditions under which a trigger invokes an action.
o Example: A rule may execute an action when a temperature event > 37°C is
received.
4. Feeds (Event Sources)
o External services or data sources that produce events.
o Examples:
 Message Queues (RabbitMQ, Kafka)
 Databases (Cloudant, etc.)
 Notifications (push messages, alarms)
 Messaging apps (Slack, chatbots)
 Web sources (RSS feeds)
5. Packages
o Pre-built connectors to integrate with external services.
o Community-driven (e.g., Apache Kafka, Cloudant DB, push notifications).

Example (IoT Sensor with RabbitMQ)

 Event Source: RabbitMQ queue “temp” receives sensor data.

 Trigger: Fires when temperature > 37°C.
 Rule: Binds trigger to an action.
 Action: Function processes the data (e.g., send alert, store in DB).

DEPT OF CSE / SVECW/MNR Page 7

 IoT, Edge and Fog Computing
Introduction:
What is a “Thing” in IoT?

 In the Internet of Things (IoT), a thing is any physical object that:

1. Has sensing capability (collects data from its environment).
2. Has processing capability (can analyze/process data locally or remotely).
3. Has actuating capability (can take action based on data/commands).
4. Is connected to the Internet (wired/wireless).
 Examples of IoT Things:
o A gift box with an RFID tag → enables logistics tracking.
o A farm animal with a biochip transponder → health monitoring.
o A person with a heart monitor implant → real-time medical tracking.
o An automobile with built-in sensors → predictive maintenance, navigation, safety.

Why is IoT so Important?

1. Massive Growth of Devices

o Today: Already more connected devices than people.
o By 2030: Estimated 19+ billion IoT devices (Cisco prediction).
2. Huge Economic Impact
o IoT applications market projected to reach trillions of dollars by 2025.
3. Applications Across Domains
o Smart Cities → energy-efficient buildings, waste management, smart grids.
o Transportation → connected cars, traffic monitoring, autonomous vehicles.
o Healthcare → remote patient monitoring, wearable health trackers.
o Agriculture → smart farming, soil & crop monitoring.
o Industry (IIoT) → predictive maintenance, automation, robotics.

IoT Applications:

DEPT OF CSE / SVECW/MNR Page 8

1. Smart Home

 Connected appliances: ACs, heaters, refrigerators, microwaves.

 Use cases:
o Home automation → control lighting, climate, appliances remotely.
o Ambient Assisted Living (AAL) → continuous health monitoring for
elderly/disabled (falls, seizures).
o Home security → access control, video surveillance, alarms.
o Real-time entertainment systems.

2. Smart City

 Connected utilities: smart water, gas, electricity meters → auto-billing & energy
management.
 Traffic systems: real-time monitoring, auto-adjusting signals, smart routing.
 Smart parking: automated availability detection.
 Smart public transportation: connected buses/trains.
 Future potential: autonomous vehicles integrating with traffic systems.

3. Smart Healthcare (IoMT)

 Devices: heart rate monitors, BP monitors, wristbands, smart beds.

 Use cases:
o Remote patient monitoring.
o Cloud-based data analysis for emergency alerts.
o Elderly care integrated with smart home systems.
o COVID-19 case study → home-hospital monitoring when hospitals were
overloaded.

4. Smart Factory & Industrial IoT (IIoT)

 Human-robot collaboration: FMCW radars, sensors for worker safety.

 Connected production line: real-time monitoring of manufacturing.
 Connected warehouse & logistics: track shipments, optimize supply chain.
 Benefits: predictive maintenance, production optimization, faster market response.

5. Smart Agriculture

 Sensors: temperature, humidity, soil moisture, rainfall, pest detection.

 Use cases:
o Precision irrigation (automated water/fertilizer control).
o Drones → pest monitoring & pesticide spraying.
o Connected livestock, plants, equipment.
o Improved productivity & reduced costs.

6. Environmental Protection

 Air, water, soil monitoring via sensors.

 Use cases:
o Coral reef monitoring (e.g., Great Barrier Reef with buoys).
o Early-warning systems for earthquakes & tsunamis.

DEPT OF CSE / SVECW/MNR Page 9

 o Wildlife tracking & habitat monitoring.

7. Smartphone-Based IoT Applications

 Built-in sensors: accelerometer, gyroscope.

 Use cases:
o Activity recognition (walking, sitting, running).
o Fitness/health tracking → heart rate, oxygen saturation, sleep patterns.
o Integration with wearables & healthcare apps.

Cloud-Centric IoT (CloT):

Cloud-Centric IoT is a model where:

 Sensor data is collected from IoT devices (things).

 Sent to the cloud for storage, processing, and analysis.
 Control signals are sent back from the cloud → to devices/actuators → to take necessary
actions.

Example:

 A seminar room device measures temperature, CO₂, humidity, and occupancy.

 Data → sent to cloud → analyzed.
 Algorithm decides → "open window/door for fresh air."
 Control signals sent back to actuators → doors/windows open.

Layers of Cloud-Centric IoT:

1. Sensing & Smart Devices Layer

 Things = IoT devices with sensors + actuators.

 Examples: wristbands, smart fridges, smart cars.
 Sensors: detect physical changes (motion, temperature, light).
o Example: LDR sensor → resistance changes with light intensity.

DEPT OF CSE / SVECW/MNR Page 10

  Actuators: perform actions (open/close doors, switch lights, pump water, adjust AC).
 Microcontrollers for prototyping:
o Raspberry Pi → full computer, supports HDMI, USB, GPIO, good for environment
monitoring & robotics.
o Arduino → smaller, with ADC (analog-to-digital conversion), good for sensor
interfacing, programmed in C/C++.

2. Gateway / Connectivity Layer

 Collects sensor data → forwards to cloud.

 Sends cloud commands → to actuators.
 Communication protocols:
o Short-range: Wi-Fi, Bluetooth, BLE, NFC, RFID.
o Medium-range: ZigBee, Z-Wave, 6LoWPAN (mesh networking).
o Long-range: LPWAN (LoRaWAN, Sigfox) → low-power, long-distance, secure.
o Wired: Ethernet with TCP/IP.
 Smartphones as gateways:
o Built-in CPU, memory, GPS, accelerometer, gyroscope, camera.
o Used in fitness/healthcare IoT (e.g., step counting, heart rate, SpO₂).
o Can connect to cloud via 4G/5G.
o Supports mobile cloud computing:
 Task delegation (invoke services via middleware).
 Mobile code offloading (send heavy tasks like image recognition to cloud).

3. Cloud Layer

 Stores & processes massive IoT data (zettabytes).

 Protocols for data exchange:
o HTTP, MQTT, XMPP, CoAP, AMQP.
 Data processing:
o Big Data Analytics → Hadoop, Aneka, Spark.
o Streaming Analytics → Kafka, Apache Storm, Spark Streaming.
 Applications:
o Predictive analytics (e.g., collision prediction in connected vehicles).
o Medical emergency prediction (IoMT remote patient monitoring).
 Output:
o Control signals sent back → gateways → IoT devices.

Edge and Fog Computing in IoT:

Limitations of CloT (Cloud Centric IoT):

1. Massive Data Volume

o Billions of IoT devices → zettabytes of data.
o Example: Self-driving car generates GBs of data per second (route, speed, sensors,
real-time video, weather, etc.).
2. High Network Load
o Sending raw data from all devices → cloud → back = heavy network congestion.
3. High Latency
o Cloud processing + internet transmission causes delays.

DEPT OF CSE / SVECW/MNR Page 11

 o Real-time apps (e.g., connected vehicles) require millisecond response, which
cloud cannot guarantee.
4. Mobility Issues
o Devices like cars may lose network connectivity, making cloud-only solutions
unreliable.
5. Privacy & Security Concerns
o Some regulations prohibit sensitive data (e.g., healthcare) from leaving national
borders.
o Cloud-only model may violate privacy rules.

Solution → Edge & Fog Computing

1. Fog Computing (coined by CISCO)

 Pushes computation closer to the devices, at the edge of the network, not always in distant
cloud.
 Example: Routers, gateways, base stations, or local servers perform analytics before sending
data to the cloud.

2. Edge Computing

 Takes computation directly to the IoT devices themselves (sensors, actuators,

microcontrollers).
 Example: A smart car’s onboard computer analyzes real-time sensor & camera data
without waiting for cloud.

Benefits of Edge & Fog Computing

 ✅ Reduced Latency – Faster response (ms-level).

 ✅ Reduced Bandwidth Usage – Only filtered/processed data sent to cloud.
 ✅ Reliability – Works even with weak/no internet connection.
 ✅ Privacy & Compliance – Sensitive data stays local.
 ✅ Real-time Decision Making – Self-driving cars, smart healthcare, industrial IoT.

Example Scenarios

 Self-driving cars → Local processing for navigation & obstacle detection.

 Smart healthcare → Local hospital/fog node processing to comply with privacy rules.
 Industrial IoT → Local fog nodes ensure millisecond-level safety monitoring.

DEPT OF CSE / SVECW/MNR Page 12

Hierarchical Fog Computing Architecture:

It illustrates how computing resources are distributed across multiple layers — from the edge of the
network (IoT devices) to the centralized cloud.

1. Edge Nodes (IoT Devices)”

 Location: Closest to the physical world — sensors, actuators, smart appliances, and
vehicles.
 Function: Collect raw data from the environment (e.g., temperature, speed, health stats).
 Processing Capability: Usually limited.
o Some devices like connected vehicles have onboard processing for immediate
actions (e.g., tire pressure warning).
 Example: Smart thermostat, wearable health monitor, or RFID-tagged package.

2. Gateway Devices:

 Location: Between edge nodes and fog nodes.

 Function:
o Aggregate data from multiple edge nodes.
o Preprocess or filter sensor data before sending it upstream.
o Send control commands back to the devices.
 Processing Capability: Moderate (higher than edge nodes).
 Example: Roadside Unit (RSU) managing traffic cameras and connected cars.

3. Fog Nodes:

 Location: Distributed between the edge and the cloud — can exist in local routers, base
stations, or micro data centers.
 Function:
o Provide local computing, storage, and networking closer to the data source.

DEPT OF CSE / SVECW/MNR Page 13

 o Enable real-time analytics and decision-making without sending all data to the
cloud.
o Can be geo-distributed (spread across different regions).
 Devices Acting as Fog Nodes:
o Network switches, routers, gateways, laptops, micro data centers, UAVs, or private
clouds.
 Example Use Case: Smart traffic systems processing vehicle and pedestrian data locally to
prevent accidents.

4. Cloud Data Center:

 Location: Centralized, often far from the data source.

 Function:
o Handles large-scale data analytics, long-term storage, and historical analysis.
o Supports resource-intensive computations that cannot be done at the fog layer.
 Example: Nationwide weather forecasting, smart city planning, or large-scale pattern
recognition.

Aneka-Based Edge and Fog Computing:

Aneka enables distributed, scalable processing across different computing layers — Edge, Fog, and
Cloud — making it ideal for IoT and real-time analytics.

The architecture in the figure has three main layers:

1. Edge Computing Layer:

Handles data acquisition and initial processing near the sensors — closest to the physical
environment.

Key Components:

DEPT OF CSE / SVECW/MNR Page 14

  Sensor Modules: CO₂ sensor, temperature sensor, ECG sensor, etc.
 Edge Gateway: Collects and aggregates sensor data.

Functions:

 Capture data from various IoT sensors (e.g., environmental, medical, industrial).
 Perform lightweight preprocessing:
o Data compression
o Aggregation
o Filtering or summarizing
 Transmit the preprocessed data to the Fog layer (Aneka Master node) using communication
protocols like MQTT or HTTP.

Example:

 An ECG sensor records a patient’s heartbeat and sends compressed, aggregated data to the
fog layer for real-time health analysis.

2. Fog Computing Layer:

Acts as the intermediate processing layer — provides low-latency data handling and local
intelligence.

Key Components:

 Aneka Master:
o Central control component at the fog layer.
o Configured with:
 Cloud Connector Service (connects to cloud)
 Resource Provisioning Service
 Data Managing Service
o Receives processing requests from edge gateways.
 Aneka Workers (Fog Servers):
o Execute the data processing logic received from Aneka Master.
o Each worker runs:
 Data Processing Service
 Resource Monitoring Service

Functions:

 Collect requests from edge gateways.

 Distribute tasks to worker nodes for execution.
 Perform predictive analytics or real-time event processing.
 If extra resources are needed, Aneka Master uses the Cloud Connector to pull resources
from the cloud layer.

Programming Support:

 Developers can use Aneka SDK/APIs such as:

o Task API
o Thread API

DEPT OF CSE / SVECW/MNR Page 15

 o MapReduce API
to define the logic that runs on workers.

Example:

 In a smart factory, fog nodes perform predictive maintenance by analyzing sensor data
from machines to detect anomalies early.

3. Cloud Computing Layer:

Provides scalable storage, heavy processing, and long-term analytics.

Key Components:

 Aneka Cloud Master and Workers on LAN-connected desktops or VMs.

Functions:

 Handle large-scale or batch processing tasks.

 Store processed data from fog nodes.
 Provide results to dashboards or actuate business processes.
 Serve as an on-demand extension of the fog layer — extra computing power is provisioned
here when needed.

Example:

 Store historical ECG data for long-term analysis or machine learning model training.

Typical Use Cases of Aneka Fog Clouds

1. Soil Monitoring System – real-time analysis for agriculture.

2. CO₂ Monitoring – air quality tracking in smart buildings.
3. Object Detection in Video Streams – e.g., identifying whether a person wears a mask at
airports.
4. Industrial Safety Monitoring – detecting unsafe conditions or absence of protective gear.
5. Predictive Maintenance – in manufacturing or networking environments.
6. ECG Data Analysis – real-time health monitoring and alerts.

EdgeLens: Deep Learning-Based Object Detection in Integrated Fog and Cloud

Environments:

EdgeLens is a framework designed to deploy deep learning (DL) applications — such as object
detection — in fog-cloud environments.
It aims to:

 Reduce latency (delay in response),

 Maintain high accuracy,
 Balance network bandwidth, power consumption, and computational load.

This is particularly useful for IoT applications like real-time surveillance, industrial monitoring, or
autonomous vehicles — where fast decisions are crucial.

DEPT OF CSE / SVECW/MNR Page 16

(a) Edge Layer

 Component: Gateway Device (User’s mobile phone)

 Functions:
o Acts as a data source and gateway.
o Captures images using its built-in camera.
o Sends the captured image data (object detection request) to the Aneka Master node
located at the fog layer.
o Displays the final detection results (output) received back from the fog/cloud.

(b) Fog Computing Layer

 Location: Melbourne, Australia

 Components:
o Aneka Master Node (Dell XPS 13)
o Aneka Worker Node (Dell Latitude)
 Functions:
o Aneka Master:
 Receives the image data from the user’s mobile gateway.
 Submits the task to available worker nodes (local or remote).
 Executes YOLO-based deep learning application
(aneka_yolo_data_processing.exe).
 Aggregates and returns results to the user.
o Aneka Worker:
 Performs local data processing and inference.
 Handles requests for nearby devices, reducing latency.
 Goal: Provide fast, near-edge processing for quick response.

(c) Cloud Computing Layer (Azure Cloud)

 Location: Distributed across two zones:

o Victoria, Australia
o Virginia, US
 Components:
o Two Aneka Worker Nodes hosted in Azure Cloud.
 Functions:
o Provide additional computational power for deep learning tasks when fog
resources are insufficient.
o Handle batch or large-scale processing.
o Ensure scalability and high availability across geographically distant nodes.

DEPT OF CSE / SVECW/MNR Page 17

Data Flow:

1. User captures an image using the mobile gateway device.

2. The image is sent to the Aneka Master in the fog layer (Melbourne).
3. The Aneka Master distributes the task to:
o Local Fog Worker (for low latency)
o Or Cloud Workers in Azure (for high accuracy or heavier tasks).
4. The YOLO-based object detection model (aneka_yolo_data_processing.exe) runs on these
nodes.
5. Processed results (detected objects) are sent back to the mobile device.

EdgeLens Framework Highlights

 Flexibility: Dynamically balances computation between fog and cloud layers.

 Adaptability: Can prioritize either low latency (fog-first mode) or high accuracy (cloud-
first mode).
 Performance Parameters Evaluated:
o Accuracy
o Response time
o Jitter (delay variation)
o Bandwidth usage
o Power consumption

How It Works (Step-by-Step):

1. User captures image using a mobile phone (Edge device).

2. Image is sent to the Aneka Master at the Fog Layer.
3. Aneka Master either:
o Processes it locally (low latency), or
o Sends it to the Azure Cloud (for complex processing).
4. The YOLO deep learning model detects objects (e.g., car, person, mask).
5. Processed image with labels and boxes is returned to the mobile phone.

Example:
Input: A street photo with people and vehicles.
Output: Same image returned to phone showing boxes labeled “Person,” “Car,” etc., with
confidence levels.

DEPT OF CSE / SVECW/MNR Page 18

 DevOps and Dynamic Deployment on the Cloud

 DevOps = Development + Operations

 It’s a software development approach that promotes collaboration between:
o Developers (who build software) and
o Operations teams (who deploy and manage it).
 Introduced by Patrick Debois in 2009, DevOps focuses on:
o Continuous communication and teamwork
o Automation of repetitive tasks
o Faster and more reliable software delivery

Key Principles of DevOps

✅ Collaboration – Developers and IT operations work as one team

✅ Automation – Build, test, deploy, and monitor automatically
✅ Continuous Integration (CI) – Regularly merging and testing new code changes
✅ Continuous Delivery/Deployment (CD) – Automatically deploying tested code to production
✅ Monitoring and Feedback – Constantly observing performance and user feedback for
improvements

Traditional Software Development Life Cycle (SDLC):

Traditionally, software was developed using the Waterfall model, which follows sequential
phases:

DEPT OF CSE / SVECW/MNR Page 19

 Phase Purpose Description
Understand what the Gather, study, and document system
1. Requirement Analysis
customer needs requirements
Define software architecture, hardware
2. System Design Plan the solution
needs, and interfaces
3. Implementation Developers write code in small units
Build the product
(Coding) (modules)
Combine modules and test the entire
4. Integration and Testing Verify correctness
system
Install or release the product for customer
5. Deployment/Operation Deliver the software
use
Fix issues, improve features, and release
6. Maintenance Keep it running smoothly
patches

Agile Methodology:
 The Waterfall model was not flexible — once planning was done, customers couldn’t give
feedback until the end.
 To fix this, the Agile model was created.

What is Agile?

Agile is a way of developing software step by step (in short cycles called iterations or sprints)
so that customers can see progress early and suggest changes anytime.

Key Ideas

 Work is done in small parts (not all at once).

 Customer is involved all the time.
 Feedback is taken after every small part.
 Changes can be made easily.
 Working software is delivered quickly and regularly.

Benefits
 Flexible and easy to change
 Keeps customers happy
 Delivers working software faster
 Improves quality with regular testing and feedback

Agile vs Waterfall
Feature Waterfall Agile
Process Step-by-step Repeated cycles
Customer Involved only at start & end Involved always
Flexibility Hard to change Easy to change

DEPT OF CSE / SVECW/MNR Page 20

 Feature Waterfall Agile
Delivery At the end After every cycle
DevOps:
While the Agile methodology is effective for software development, it can still lead to
configuration mismatches between the testing and production environments. This happens
because, in Agile, development and testing are mainly done on the developer’s system with
continuous customer involvement.

However, since the process is limited to the developer’s environment, problems may occur during
deployment, and the development and operations teams often continue to work in separate silos.

DevOps bridges this gap by ensuring continuous collaboration and integration between the
development and operations teams. It involves all stakeholders throughout the process, making it
an evolution of the Agile model.

Definition:
DevOps is a cultural and professional movement that emphasizes communication, collaboration,
and integration between software developers and IT operations professionals.

DevOps Pipeline Phases

1. Plan
o Collect requirements and feedback from stakeholders.
o Create a product roadmap and break it into smaller, manageable tasks.
2. Code
o Developers write and manage the source code for features and fixes.
o Version control systems like Git are used for collaboration.
3. Build
o The code is compiled and built automatically after being committed.
o Automated tools run unit, integration, and end-to-end tests to detect issues early.
4. Test
o The build is deployed to a staging environment using Infrastructure as Code
(IaC).
o Both manual and automated tests ensure system correctness.
5. Release
o After successful testing, the build is approved for production.
o Release can be manual or automated, depending on organizational policy.
6. Deploy

DEPT OF CSE / SVECW/MNR Page 21

 o The tested build is deployed to the production environment.
o IaC ensures consistent setup between test and production environments.
7. Operate
o The operations team maintains smooth system performance.
o Systems scale automatically based on load, and customer feedback is collected.
8. Monitor
o Continuous monitoring of performance, errors, and user behavior.
o Insights from monitoring feed back into the planning phase, completing the loop.

Infrastructure-as-Code (IaC):
Infrastructure-as-Code (IaC) is an essential part of DevOps and CI/CD (Continuous
Integration/Continuous Deployment) practices.

Traditionally, developers or system administrators had to manually set up and manage servers,
operating systems, storage, and other infrastructure components whenever a new version of an
application was deployed.
With the rise of cloud computing, applications now use many virtual machines and containers,
making manual setup complex and time-consuming.

IaC proposes that infrastructure should be managed and provisioned using code, not manual
processes.

 Developers create templates that define the configuration and specifications of the required
infrastructure (e.g., servers, databases, network settings).
 These templates ensure that the same environment is created every time — eliminating
configuration mismatches.
 Orchestrators (automation tools) read these templates to automatically set up and configure
both hardware and software.
 The templates are stored in version control systems (like Git) along with the application’s
source code.

Benefits of IaC:

 Consistency: Identical environments can be reproduced anytime.

 Automation: Reduces manual effort and human error.
 Scalability: Easily scale resources up or down as needed.
 Versioning: Track and manage changes in infrastructure like application code.
 Modularity: Infrastructure components can be divided into smaller modules and reused.

Popular IaC Tools:

1. Chef

 Language: Written in Ruby and Erlang.

 Configuration Style: Uses a domain-specific language (DSL) in Ruby; configurations are
called “recipes.”
 Function: Recipes define how to configure servers, applications (like Apache or MySQL),
and integrate with cloud platforms such as AWS, Azure, GCP, and OpenStack.
 Purpose: Automates provisioning and configuration of both on-premise and cloud servers.

DEPT OF CSE / SVECW/MNR Page 22

2. Puppet

 Language: Uses its own declarative language or Ruby DSL.

 Configuration Files: Called “Puppet manifests.”
 Approach: Follows Model-Driven Architecture (MDA) — defines what the system
should look like, not how to achieve it.
 Function: Automates provisioning, configuration, and management of infrastructure
across data centers and clouds.
 Use Case: Ideal for maintaining large-scale server infrastructures consistently.

3. Ansible

 Design: Agentless — does not require software installation on target machines.

 Communication: Uses SSH (for Unix/Linux) or Windows Remote Management for
remote setup.
 Configuration Language: Uses YAML, a simple, human-readable format.
 Configuration Files: The full system configuration is called an “inventory.”
 Function: Handles provisioning, configuration management, and deployment of
applications.
 Special Feature: Uses a JSON-based protocol for communication between the control
machine and nodes.

4. Terraform

 Developer: Created by HashiCorp.

 Configuration Language: Uses HashiCorp Configuration Language (HCL) or JSON.
 Function: Defines and manages data center infrastructure across multiple cloud
providers (AWS, Azure, GCP, IBM Cloud, OpenStack).
 Concept: Uses “providers” to manage external resources and define the desired final state
of infrastructure.
 Unique Feature: Enables multi-cloud deployment and infrastructure versioning.

TOSCA (Topology and Orchestration Specification for Cloud Applications):

One of the main challenges in cloud computing is vendor lock-in — when applications depend on
specific cloud services (like AWS EC2 or S3), making it difficult to migrate to another cloud
provider (like Google Cloud or Azure).

To overcome this, TOSCA, developed by OASIS, provides a standardized way to describe,

deploy, and manage cloud applications across multiple platforms.

It enables portability and interoperability — allowing applications to be moved between different

clouds without reconfiguration.

Definition

TOSCA (Topology and Orchestration Specification for Cloud Applications) is a standard that
defines how to model, deploy, and manage cloud applications and their infrastructure in a vendor-
independent way.

DEPT OF CSE / SVECW/MNR Page 23

Purpose and Advantages

 Avoids vendor lock-in by supporting multiple cloud platforms.

 Describes both the application and its supporting infrastructure (servers, networks,
storage, etc.).
 Allows automatic deployment and management of applications.
 Provides interoperability and portability for cloud services.

Key Building Blocks

1. Nodes

 Represent infrastructure or software components.

 Examples: servers, virtual machines, networks, web servers, databases, etc.
 Each node defines its properties, capabilities, and requirements.

2. Relationships

 Define how nodes are connected or depend on each other.

 Examples:
o HostedOn – A web server hosted on a virtual machine.
o ConnectsTo – A web server connects to a database.
o DependsOn, BindsTo, DeployedOn, etc.

Quantum Cloud Computing

Quantum Computing:
 Solves complex problems faster than classical computers.
 Crucial for:
o Machine Learning
o Finance & Optimization
o Drug Discovery
o Chemical & Physical Simulations
Notion of Bit vs. Qubit:

DEPT OF CSE / SVECW/MNR Page 24

Classical Bit

 Bit has only two states:

o 1 (on, represented by an upward arrow)
o 0 (off, represented by a downward arrow)
 This is binary and deterministic.

Quantum Bit (Qubit)

 Qubit can exist in a superposition of both 0 and 1 simultaneously:

o Represented mathematically as:

∣Ψ⟩=α∣0⟩+β∣1⟩

o Where α\alphaα and β\betaβ are complex numbers and:

∣α∣2+∣β∣2=1

 This enables parallelism in quantum computation, a key advantage over classical bits.

Notion of Superposition and Entanglement:

Superposition

 A single qubit in a superposition can be:

∣Ψ⟩=21(∣0⟩+∣1⟩)

 This means the qubit is simultaneously in both 0 and 1 states.

 It is a core concept that allows quantum computers to process many possibilities at once.

Entanglement

 Two qubits can become entangled, meaning the state of one qubit depends on the other:
o Example:

DEPT OF CSE / SVECW/MNR Page 25

 ∣Ψ⟩=21(∣00⟩+∣11⟩)

 Measurement of one immediately determines the state of the other, even if they are far apart.
 This non-local correlation enables quantum speed-up in computation and communication.

Feature Classical Computer (Bit) Quantum Computer (Qubit)

Unit of info Bit (0 or 1) Qubit (0, 1, or both)
Speed Sequential Parallel (due to superposition)
State Representation Deterministic Probabilistic (α
Linking Independent Entangled states
Errors Rare Sensitive to decoherence

Quantum Cloud Computing:

Quantum Cloud Computing allows organizations, researchers, and developers to access quantum
computing resources over the cloud instead of owning expensive quantum hardware.

Quantum principles are applied in a distributed cloud environment, enabling users to run
quantum algorithms on-demand through cloud services.

Why Quantum Cloud?

 Quantum computers are complex and costly — often as large as a car and require special
cooling systems.
 Cloud access eliminates the need for physical ownership and provides scalable, pay-as-
you-go quantum resources.

Examples and Technologies

 IBM Cloud: Offers 127-qubit quantum computing service. Users can directly run quantum
workloads.
 Rigetti Computing: Provides a quantum-first cloud platform integrating quantum and
classical systems.
o Uses Quil SDK to develop and execute quantum programs on simulators or real
processors.
 QuDot85: Introduced QuDotNets — a patented technology that simulates quantum
computers on normal (commodity) hardware.
o Released a QuDot Virtual Machine (VM) for running quantum bytecode.
 iQuantum by CLOUDS Lab: A simulator for modeling quantum computing in edge–
cloud environments.

Market Growth

 The global quantum cloud market is projected to grow from $798 million (2023) to
$4,063 million (2028).
 CAGR: 38.5% — indicating rapid expansion and adoption.

DEPT OF CSE / SVECW/MNR Page 26

Quantum Cloud Computing Services:
1. IBM Quantum Cloud

 Started: 2016
 Overview: IBM pioneered commercial quantum cloud services, now offering >100-qubit
systems accessible globally.
 Locations: Includes Mumbai, Brisbane, Kyiv, etc.
 Access Models:
o Free tier – for learning and experiments
o Pay-as-you-go and Premium plans – for advanced workloads
 Tools & Platform:
o Qiskit: Open-source SDK for building and running quantum circuits
o Qiskit Runtime: Allows execution on real IBM quantum systems
 Features:
o Advanced runtime compilation
o Error suppression and error mitigation
o Scalable and feasible quantum software solutions

2. AWS Braket

 Started: Around 2020

 Service Name: Amazon Braket
 Purpose: Enables researchers and developers to design, simulate, and run quantum
algorithms on both simulated and real hardware.
 Regions: US-East (N. Virginia), US-West (Oregon), US-West (N. California)
 Support: Amazon Quantum Solutions Lab provides expert assistance and research
guidance.
 Pricing Model:
o Per-shot fee: Each quantum execution
o Per-task fee: Sequence of repeated shots
o Example: For IonQ Harmony QPU → $0.03 per task and $0.01 per shot

3. Microsoft Azure Quantum

 Service Name: Azure Quantum

 Features:
o Integrated Copilot chatbot for coding assistance and explanation
o Hybrid quantum computing: Combines classical + quantum processing
o Quantum SDKs: Supports Q#, Qiskit, and Cirq
o Write once, run anywhere: Code can run on multiple quantum hardware platforms
o Offers optimization services, simulators, and emulators
 Access:
o Free to start via Jupyter Notebooks
o Cloud-based workspace ecosystem for developing and deploying algorithms

DEPT OF CSE / SVECW/MNR Page 27