Cloud Computing -- Everything As A Service

Abstract

Compute infrastructure hosted by a cloud provider allows an application to scale without limit. The application developer no longer needs to worry about the up-front investment in a server farm provisioned for a worst-case load scenario. However, managing cloud deployments requires a sophisticated framework that can autoscale the infrastructure and guarantee the up-time of running container images. This paper surveys existing research addressing the management and orchestration of cloud deployments as well as the modelling framework to abstract away the low-level details of the host infrastructure. We investigate blockchain distributed ledgers, quantum computing and Internet of Things application stacks to show how they can utilize cloud deployments.

Full text

Cloud Computing — Everything As A Service
Michael Howard
Computer Science Department
Portland State University
Portland, USA
mihoward@pdx.edu
Abstract— Compute infrastructure hosted by a cloud provider
allows an application to scale without limit. The application
developer no longer needs to worry about the up-front investment
in a server farm provisioned for a worst-case load scenario.
However, managing cloud deployments requires a sophisticated
framework that can autoscale the infrastructure and guarantee
the up-time of running container images. This paper surveys
existing research addressing the management and orchestration
of cloud deployments as well as the modelling framework to
abstract away the low-level details of the host infrastructure. We
investigate blockchain distributed ledgers, quantum computing
and Internet of Things application stacks to show how they can
utilize cloud deployments.
Index Terms—cloud computing, kubernetes, infrastructure,
orchestration
I. INTRODUCTION
Cloud computing enables a new method to provision in-
frastructure and deploy software. Compute resources are now
commodities that expand to scale with the software application
requirements. These resources temporarily launch on-demand
from the cloud host and provide the convenience of not need-
ing to pre-purchase and maintain on-premise infrastructure.
However, since the cloud infrastructure is provisioned and
destroyed frequently, there are additional requirements for
system management and security. An ideal approach fully au-
tomates the cloud usage, a new application builds and deploys
easily while immediately launching compute resources to meet
its needs. This paper surveys existing research on the problem
of deploying an application into the cloud environment and
adapting to its changing system needs.
Section II is reviewing the Continuous Integra-
tion/Continuous Deployment (CI/CD) pipeline and the
Tekton framework to drive it. The container images deployed
into the cloud can also enhance their runtime security
through a Trusted Execution Environment (TEE). Section
III introduces the CloudCAMP framework that provides a
graphical modelling environment abstracting the provisioning
and deployment of cloud infrastructure. After provisioning
the cloud infrastructure, the orchestration cluster manages all
running containers. Section IV compares the top orchestration
frameworks: Kubernetes and Docker Swarm.
Next, the survey moves on to how different application types
can manage cloud deployments. In Section V, the application
is a blockchain distributed ledger recording new transactions
coming from Renault cars equipped with Internet of Things
(IoT) devices sending sensor data from a collision. Section VI
discusses a paper focused on the unique needs of quantum-
compute applications in the cloud. The authors’ extend an
existing orchestration specification to create Topology and Or-
chestration Specification for Cloud Applications for Quantum
Computing (TOSCA4QC). Multiple TOSCA4QC case studies
prove the practical feasibility of this new specification. Finally,
Section VII addresses the orchestration of smart IoT systems
with a paper on a framework called Generation and Deploy-
ment of Smart IoT Systems (GeneSIS). It uses a modelling
language to generate the modules needed for the deployment
and dynamic adaption of heterogeneous IoT systems.
II. TRU ST ED EXECUTION ENVIRONMENT
Most cloud providers handle deploying an application into
a cloud environment in an automated fashion. However, the
resulting vendor lock-in is counter-productive to most appli-
cation developers. As a result, the authors of “A Kubernetes
CI/CD Pipeline with Asylo as a Trusted Execution Environ-
ment Abstraction Framework” [1] discuss the benefits of using
a third-party service — Tekton — to configure the triggers and
actions of a Continuous Integration/Continuous Deployment
(CI/CD) pipeline. They also discuss building the runtime
containers with the Asylo framework.
Tekton is a framework that is publicly exposed through a
hosted service. It provides a declarative language to define
each stage of the CI/CD pipeline. These stages run as con-
tainerized tasks within a Kubernetes cluster and each task
listens for its corresponding trigger events. The task executes
the appropriate pipeline run action upon receiving the trigger
event. The task containers perform the following actions:
1) Checkout the source code from source-control manage-
ment.
2) Build the source code binaries.
3) Execute the unit test suite.
4) Build the execution container with Kaniko and using
Asylo as a binary wrapper.
5) Archive the execution container in the Harbor registry.
6) Deploy the execution container into a runtime environ-
ment for functional testing.
7) Promote (deploy) the execution container into other
runtime environments for end-user interaction.
A significant benefit to using Tekton is avoiding locking in
to a specific cloud vendor. Amazon Web Services (AWS) has
its Code Pipeline service and Google Cloud Platform provides
Cloud Build; both are excellent tools for implementing a
arXiv:2206.07094v1 [cs.DC] 25 May 2022

CI/CD pipeline. However, switching between cloud vendors
requires porting all the pipeline configuration and code. The
Tektron framework is vendor-agnostic and easily switches
between cloud deployment targets.
The Asylo framework, mentioned in Item 4 above, provides
a wrapper around the application binaries such that they run
within a Trusted Execution Environment (TEE). Thus, binaries
running within the container image utilize Intel’s Security
Guard Extension (SGX) to encrypt instructions as they page
into memory and then decrypt them as they load in their corre-
sponding processor. This memory-encryption feature prevents
a cloud provider’s system administrator from being able to see
or interfere with instructions once they are loaded into Virtual
Machine memory.
Fig. 1: Build and deploy times for a pipeline ex-
periment as discussed in Mahboob [1]. The exper-
iment builds a container image with and without
Asylo and benchmarks the execution time.
The Asylo wrapper builds into the execution container and
allows the use of SGX instructions, even if the application is
not compiled with the SGX option. Additionally, there is an
emulation flag allowing deployment to Virtual Machines that
do not support SGX. This emulation is useful when testing
the execution container in different environments. Figure 1
shows the performance cost incurred with Asylo during the
benchmark experiments. Deployment time of the execution
container image does not change significantly when including
Asylo; however, the build times did increase by a factor of
65×. Thus, there is a trade-off between slightly increasing
development time and a more secure runtime.
III. CLO UD CAMP PROVISIONING
CloudCAMP is another framework tool, proposed at Van-
derbilt University, that focuses on the management of cloud
deployments. The paper “CloudCAMP: Automating Cloud
Services Deployment & Management” [2] goes into detail
on the authors’ vision of a technology-agnostic framework
that avoids relying on domain expertise of the target cloud
infrastructure.
The framework works on a model-driven approach that
generates Infrastructure as Code (IaC) modules for provision-
ing cloud services. A Graphical User Interface (GUI) allows
editing the model and provides a high level of abstraction
without requiring low-level scripting or cloud vendor domain
knowledge.
CloudCAMP differs from Tekton by focusing on the mod-
elling and deployment of the cloud infrastructure and applica-
tion stack. Tekton implements the pipeline stages for CI/CD.
Fig. 2: The CloudCAMP workflow, shown in
Bhattacharjee [2], describes a typical sequence
starting from the user input to the generation of
provider-specific IaC modules.
It can also potentially trigger cloud infrastructure provisioning
via pre-configured CloudCAMP modules (shown in Figure 2)
that would then host the deployed pipeline container images.
The building blocks in the modelling environment are all the
application components; each connect with exposed endpoints.
These components form the basis of the Domain Specific
Modelling Language (DSML) that drives the CloudCAMP
framework. The WebGME user interface provides a way
to edit DSML. It is a cloud-based framework for DSML
developers that defines their language and create model parsers
for code artifact generators. Each building block in the model
forms a node. Many node types are supported such web,
database and analytics applications. Multiple cloud providers
for each type are also supported such as OpenStack, Amazon
Web Services and Microsoft Azure.
IV. CON TAI NE R ORCHESTRATI ON TO OL S
After the CI/CD pipeline deploys the container images, they
additionally require orchestration on the provisioned cloud
infrastructure. The orchestration monitors as well as manages
the application and system requirements of each running
container image. “A Performance Comparison of Cloud-based
Container Orchestration Tools” [3] provides a review and
comparison of Kubernetes versus Docker Swarm, two of the
top orchestration tools currently in use. The authors conclude
through their benchmark tests that Kubernetes is the more
scalable orchestrator. However, it can introduce as much as
8.3% performance penalty on small-scale systems compared
with Docker alone (no orchestration).
An application spanning multiple containers running over a
cluster of cloud-based worker nodes evaluates and benchmarks
the performance of the container orchestrators. First, running
the container images directly on the worker nodes without any
orchestration determines a baseline. A benchmarking test suite
captures processing times and system utilization metrics. The
two applications in the benchmarking tests are:
1) A Phoronix Test Suite (details in Pan [3]).
2) A Light Detection and Ranging (LiDAR) data process-
ing.
The results in Figure 3 show processing times with container
images running directly on the node and again orchestrated

Fig. 3: Orchestrator overhead as shown in Pan [3].
The graph shows the processing time of a sample
containerized application that is deployed directly,
then again with Docker Swarm and Kubernetes
orchestration.
through Docker Swarm and Kubernetes. The red portion indi-
cates the overhead processing that the orchestrator introduces
and shows Kubernetes with the highest overhead.
V. BLOCKCHAIN DI ST RI BUTED LEDGER
So far, the focus has been on the technology of the de-
velopment pipeline and the provisioning of the hosting cloud
environment. “A Blockchain cloud architecture deployment
for an industrial IoT use case” [4] discusses how a specific
application is using that technology. The authors study the
feasibility of using a cloud Kubernetes environment to host a
blockchain-based, distributed ledger called Hyperledger Saw-
tooth.
The use case for this study involves Renault cars containing
Internet of Things (IoT) devices able to connect to a cloud-
hosted blockchain. Each car sends sensor telemetry data before
and after a collision using a smart contract. The smart contract
enables adding a new blockchain transaction to the ledger.
Renault, insurance companies, mechanics and police can all
access the ledger to determine which car is at fault in the
collision. Figure 4 shows the ecosystem of clients connecting
to the ledger.
Fig. 4: Hyperledger Sawtooth uses blockchains
for automatically declaring accidents in Renault’s
vehicular infrastructure as shown in Gerrits [4].
The Kubernetes cluster used in the study contained six cloud
instances. Within that cluster, blockchain Sawtooth nodes
run independently, each within their own Docker container
image. The number of nodes varies between 4 and 24, while
the commit rate of transactions increased from 5 to 50 per
second. The study concluded that the Sawtooth core itself
was the bottleneck and a newer version fully coded in Rust
and supporting multithreading would provide faster blockchain
commit rates. The cloud infrastructure in the study also proved
to successfully handle the distributed ledger.
VI. QUA NT UM COMPUTING
Another application that can take advantage of cloud de-
ployment is quantum computing. The paper “TOSCA4QC:
Two Modeling Styles for TOSCA to Automate the Deployment
and Orchestration of Quantum Applications” [5] starts by
discussing a technology called Topology and Orchestration
Specification for Cloud Applications (TOSCA) that takes a
declarative approach to deploying classical (non-quantum)
applications.
Quantum applications must deploy for each invocation.
This restriction means deploying only once and not invok-
ing multiple times per deployment, such as with classical
application deployments. To meet this challenge, the au-
thors extend TOSCA to introduce Topology and Orchestration
Specification for Cloud Applications for Quantum Computing
(TOSCA4QC). The new extended standard introduces two
deployment modelling styles:
1) The Software Development Kit (SDK)-specific, which
covers all technical details.
2) The SDK-agnostic, which reflects common modelling
principles known from classical applications while hid-
ing technical details.
Figure 5 shows the GUI and abstract modelling using SDK-
specific style on the left and the SDK-agnostic on the right.
Fig. 5: TOSCA4QC SDK-specific (SDK-S) and
SDK-agnostic (SDK-A) modelling styles as
shown in Wild [5].
The Software Development Kit Agnostic (SDK-A) style
does not provide enough detail to make the model executable
(able to deploy). It follows the common modelling approach
of a classical application. To make it executable, it first
transforms into a Software Development Kit Specific (SDK-
S) model. The TOSCA4QC standard provides an automated
approach to transform the SDK-A model to SDK-S. Thus, the

standard allows modelling of quantum cloud deployments in
a simple and easy to understand format then another, more
complicated format that is also executable.
VII. SMA RT IOT SY ST EM S
Multiple tools have emerged to support the continuous
deployment of cloud-based software systems. However, there
is currently a lack of proper tool support for the continuous
orchestration and deployment of software systems in the IoT
space. “GeneSIS: Continuous Orchestration and Deployment
of Smart IoT Systems” [6] addresses these IoT systems that
may have little or no direct access to the Internet.
The authors of this paper developed a framework called
Generation and Deployment of Smart IoT Systems (GeneSIS)
that allows decentralized processing across heterogeneous IoT
systems. The GeneSIS framework includes:
1) A domain-specific modelling language to model the
orchestration and deployment of a Smart IoT System.
2) The execution engine to drive that orchestration.
Figure 6 shows the authors’ vision of how the GeneSIS
modelling language is sufficient to support the deployment
and dynamic adaption of IoT systems.
Fig. 6: Overall GeneSIS approach as shown in
Ferry [6]. It summarizes modelling the IoT targets
and deploying their software artifacts.
This paper presents how GeneSIS leverages model-driven
techniques and methods to support the continuous deployment
and orchestration of Smart IoT Systems (SIS). The modelling
language supports the deployment of SIS over IoT, edge
and cloud infrastructure in a platform-independent way. The
execution engine provides the mechanism to execute this
deployment and support its dynamic adaption, even if the
device has limited internet access.
VIII. CONCLUSION AND DISCUSSION
The papers in this survey show a new paradigm in soft-
ware development using cloud computing for deployment.
Purchasing cloud compute resources allows the development
and deployment to begin with only provisioning the minimum
resources needed for the best-case system load. Thus, it is cost-
effective compared with building up an on-premise compute
farm that requires up-front budgeting and provisioning to
handle the worst-case system load. Another benefit is the cloud
does not require maintenance as with the compute farm. For
instance, operating system updates incur down-time, which
is avoided in the cloud if purchasing container orchestration
services rather than the virtual machines directly.
The cloud-compute resources are dynamic and therefore
provisioned and destroyed frequently. This on-demand pro-
visioning requires additional management software to con-
trol the system configuration and security. The CloudCAMP
framework allows modelling the cloud infrastructure at a
high level, agnostic of the cloud provider. A container wraps
the software application and encapsulates the runtime envi-
ronment. A Continuous Integration/Continuous Deployment
pipeline automates the building and deployment of the ap-
plication containers. Tekton implements the pipeline while
avoiding locking in to a single cloud vendor. A Trusted Execu-
tion Environment enhances runtime security, implemented by
wrapping the container’s application binaries with the Asylo
framework. Kubernetes orchestrates the container deployment
while introducing a runtime overhead due to its flexible feature
set.
In addition to how cloud computing is implemented, there
are also three application stacks included in the survey. Quan-
tum computing takes advantage of cloud resources through a
new standard called Topology and Orchestration Specification
for Cloud Applications for Quantum Computing. Internet
of Things devices use a framework called Generation and
Deployment of Smart IoT Systems which focuses on limited
or no internet access scenarios. Finally, Renault cars use a
blockchain-based Hyperledger Sawtooth distributed ledger to
record collision event data.
Future research needs to focus on splitting existing applica-
tions into discrete microservices such that they may be easily
containerized. Other areas to include are implementing smart
orchestration such that deployed containers run more robustly
through redundant execution and intelligent routing of network
requests to assist with load balancing. Machine Learning
provides an excellent framework to train the orchestrator on
optimizing the operating parameters and is a logic next step
in the expansion of cloud computing. Everything as a Service
is within reach.
IX. ACK NOWLEDGEMENTS
The author would like to acknowledge the contributions
of Dr. Wu-Chang Feng at Portland State University. His
advisorship, funding and support made this research possible.
REFERENCES
[1] J. Mahboob and J. Coffman, “A Kubernetes CI/CD Pipeline with
Asylo as a Trusted Execution Environment Abstraction Frame-
work” in IEEE 11th Annual Computing and Communication Work-
shop and Conference (CCWC), NV, USA, March 2021, doi:
10.1109/CCWC51732.2021.9376148. Available: https://ieeexplore-ieee-
org.proxy.lib.pdx.edu/stamp/stamp.jsp?tp=&arnumber=9376148&tag=1

[2] A. Bhattacharjee and Y. Barve and A. Gokhale and T. Kuroda, “Cloud-
CAMP: Automating Cloud Services Deployment and Management” ,
April 2019, Available: https://arxiv.org/abs/1904.02184
[3] Y. Pan and I. Chen and F. Brasileiro and G. Jayaputera and R.
Sinnott, “A Performance Comparison of Cloud-Based Container
Orchestration Tools” in 2019 IEEE International Conference
on Big Knowledge (ICBK), Melbourne, Australia, 2019, doi:
10.1109/ICBK.2019.00033. Available: https://ieeexplore-ieee-
org.proxy.lib.pdx.edu/document/8944745
[4] L. Gerrits and E. Kilimou and R. Kromes and L. Faure and F.
Verdier, “A Blockchain cloud architecture deployment for an indus-
trial IoT use case” in 2021 IEEE International Conference on Omni-
Layer Intelligent Systems (COINS), Barcelona, Spain, Aug 2021, doi:
10.1109/COINS51742.2021.9524264. Available: https://ieeexplore-ieee-
org.proxy.lib.pdx.edu/document/9524264
[5] K. Wild and U. Breitenb¨
ucher and L. Harzenetter and F. Leymann
and D. Vietz and M. Zimmermann, “TOSCA4QC: Two Modeling
Styles for TOSCA to Automate the Deployment and Orchestration
of Quantum Applications” in 2020 IEEE 24th International Enter-
prise Distributed Object Computing Conference (EDOC), Eindhoven,
Netherlands, 2020, doi: 10.1109/EDOC49727.2020.00024. Available:
https://ieeexplore-ieee-org.proxy.lib.pdx.edu/document/9233151
[6] N. Ferry and P. Nguyen and H. Song and P. Novac and S. Lavirotte
and J. Tigli and A. Solberg, “GeneSIS: Continuous Orchestration
and Deployment of Smart IoT Systems” in 2019 IEEE 43rd Annual
Computer Software and Applications Conference (COMPSAC), 2019,
doi: 10.1109/COMPSAC.2019.00127 Available: https://ieeexplore-ieee-
org.proxy.lib.pdx.edu/document/8753981