A Pragmatic Amalgamation of Cloud Computing Visibility
and Services
Flavio Ishii
Computer Science Department
University of Saskatchewan
SK S7N 5C9, Canada
foi822@mail.usask.ca
ABSTRACT
In this research paper we look at how to harness Cloud Com-
puting (CC) options pragmatically. CC has yet to mature
and gain mass acceptance by the IT industry, but all the
benefits it brings with all the options bundled by Cloud
Computing Service Providers (CCSPs) we can be certain
that it will remain the topic of discussion for years to come.
We base our decision process of deploying a cloud appli-
cation on the system properties, usage, resources available,
and policies. We outline the CC options with the Cloud
Computing Visibilities (CCVs) and the Cloud Computing
Service (CCS) development layer(s). We point out some
key factors to trigger discussions among software teams to
pragmatically decide on their specific solutions. We have
made an amalgamation of previous CC studies, a survey of
the different CCSPs, and a look at CC management tools.
Keywords
Cloud Computing, Hybrid Cloud, Architecture, Software
Management.
1. HISTORY AND INTRODUCTION
Cloud Computing (CC) draws elements from different sys-
tems: Grid Computing, clusters working towards solving a
task; Utility Computing, computing resources served as a
metered service; and Autonomic Computing, self-managed
systems [1]. Wikipedia defines CC as ”a new supplement,
consumption and delivery model for IT services based on the
Internet, and it typically involves the provision of dynam-
ically scalable and often virtualized resources as a service
over the Internet.”
The high demand for Web-based software development
of the past decade has given the opportunity for large cor-
porations like Amazon and Google to offer their high-end
infrastructure to developers. These service providers among
others offer their computer and network infrastructure as
a utility service with application or Software as a Service
(SaaS), virtual machine instance management or Infrastruc-
ture as a Service (IaaS) and development Platform as a Ser-
vice (PaaS). These services became known as Cloud Com-
puting Services (CCS). Many companies now provide in-
novative services built on top of the CCSs such as cloud
management and monitoring tools.
The [2] paper mentioned three attractive reasons for de-
veloping with CCS: short-term usage, low start-up cost, and
infinite capacity on demand. Moving to or starting up in
the cloud is considered a risky investment since it embraces
a new architecture, costs, and business model. Many fac-
tors need to be looked at and [2] formulated how profitable
the cloud solution would be based on revenue and usage. It
also provides hints as to improvements that may be coming
in the near future to help gain the confidence of more CCS
users.
There are many skeptics of CCS usage, due to the high
profile it gets when malicious or unintentional service out-
ages occurs, but also due to data storage regulation policy
issues and vendor lock-ins. These issues have been noted
by CCSPs and attempt to resolve it by adding more server
farms in different geographic location options like Amazon
Web Service (AWS) Regions [3] for increased up-time, pro-
viding a Hybrid Cloud (discussed in 2.2.3) solution to con-
form with strict policies, and using open solutions like Joyent
Smart Platform for code portability. The unification and
standardization of CCSPs is a sensitive and active topic
among providers, and it could play a key role in easing the
cloud architecture decision making process.
A number of innovative business models are spearheading
the success of cloud implementations. The most successful
ones provide supportive type services to existing software as
oppose to attempting to create a killer app. RightScale and
3scale are two such businesses that provide tools to manage
cloud instances and cloud traffic policies, respectively. As
more cloud-based solutions succeed and become the status
quo, it will help quiet the skeptics.
The technical report [4] offered an insightful method of
breaking down application and cloud attributes to help map
them to one another. However, being that industry was their
target audience it focussed on cost effectiveness leaving out
some important topics such as code portability and cloud
service interoperability. It also took on the position that of
cloud visibility is irrelevant; suggesting that choosing one
provider with many options is more feasible since it can be
more cost effective. This view favored large enterprises as
opposed to small to medium sized businesses that can not
always afford to be tied in with a single vendor, especially if

Figure 1: CCS layers of abstraction.
vendor policies change.
In this paper we adopt a pragmatic approach for deploy-
ing cloud applications by considering the system and cloud
attributes. Unlike previous work [4, 6] that focus on the
details of whether the application is meant for the cloud or
not, we assume that the application attributes map appro-
priately to the cloud and that a cloud-based solution is cost
effective based on the formula derived in [2]. We take on
a project management role and look at resources available,
resources that will become available, time to market, and
legal and privacy policies. All these attributes can signif-
icantly alter the cloud deployment decisions and must be
looked at on a case by case basis. It is close to impossible to
find an ideal CC Architecture (CCA) and CCSPs, it must
be chosen pragmatically. We demonstrate this by breaking
down the CCA, outlining the Cloud Computing Visibility
(CCV) and CCSs, and later applying a decision process to a
fictional case. We hope the accumulated knowledge found in
this research will equip software managers, developers, and
academic researchers with some guidelines to help choose an
adequate CC solution.
2. CLOUD COMPUTING ARCHITECTURE
CCA can be broken down into its visibility and its de-
velopment service layers. The following subsections explain
the advantages the CCS layers provide for the developer and
how they are typically used in different cloud visibility. We
start our discussion with the CCS layers to get a base un-
derstanding of what services are available and move on to
CCV to see how and where the layers are integrated in the
architecture.
2.1 Cloud Computing Services
We cover the three main types of CCS: Infrastructure as a
Service (IaaS), Platform as a Service (PaaS), and Software
as a Service (SaaS). Figure 1 depicts the CCSs in a stack
of layers of abstraction for a developer, meaning that the
higher the layer the more transparent its complexities are
involving less setup and maintenance work, but it also means
the less control over the environment the developer has. We
discuss these services in terms of a developer’s and system
administrator’s perspective as oppose to how an end-user
would experience it.
2.1.1 IaaS Development Layer
Developers and administrators working on the IaaS layer
can create and manage server images, install any software
and development platform in those images, and integrate
with different services offered by the same CCSP. The main
differences among CCSPs are their pricing structures, cloud
management interfaces, and numerous options. Popular IaaS
providers include AWS EC2, Rackspace Cloud Hosting, and
GoGrid Cloud Hosting. The key advantage for deploying an
application on an IaaS, is the control over the implemen-
tation and the code portability; there is no vendor lock-in
if vendor-related issues arise. The key disadvantage, when
compared to the other CCS layers is the extra effort for cre-
ating and managing your infrastructure. Some CCSPs and
third parties attempt to solve this issue by offering simpler
interfaces.
2.1.2 PaaS Development Layer
The PaaS layer allows a developer to focus only on coding
an application given the development platform, which may
only restrict the developer to a programming language (i.e.
Heroku, Stax, and Joyent Smart Platform) or it may restrict
the developer to a specific framework (i.e. Google App En-
gine, Azure Platform, Appcelerator, Rhohub). Custom Web
2.0 and mobile application developers have embraced PaaS
due to its flexibility and low-startup investment. Applica-
tions deployed on PaaS can also have the characteristic of
high and unpredictable usage spikes. The disadvantage for
PaaS is that vendor lock-in becomes an issue with providers
that have their own proprietary frameworks.
2.1.3 SaaS Development Layer
SaaS is considered the oldest CCS layer. There are some
CCSPs that cross or merge the line between PaaS and SaaS,
we therefore define SaaS as working in a specific domain;
whereas PaaS is more flexible in these terms. When devel-
oping on the SaaS layer either the software already exists
(i.e. Google Apps, Zoho Apps, SalesForce CRM) and we
build on to it using proprietary APIs, or there is a context
and a Domain Specific Language (DSL) for the application
being developed (i.e. Force.com, LongJump, Yahoo! Pipes).
Note that some providers fall under both cases. SaaS devel-
opment tends to have fast deployment cycles but they are
tightly dependent on a provider and domain.
2.2 Cloud Computing Visibility
CCV determines how system administrators, developers,
and end-users access the CCS being provided. Figure 2
shows the different CSV levels with the Conventional (non-
cloud) Infrastructure included for comparison sake. Each
level may contain the different CCS layers described in the
previous sub-sections. The higher the CSV is placed on the
y-axis the more control, usage predictability, and stricter
company policies the CSV will have. The term ”System Con-
trol” is used to describe code portability, platform and data
structure flexibility, and system performance enhancement
and monitoring capabilities. ”Predictable Usage” considers
the number of users, number of processes, and usage spikes.
”Policies” appraises legal policies and security for user or
company data privacy. The farther to the right the CCV is
located on the x-axis of the graph the more ”Resource in-
vestment” will be involved in the start-up and production
costs such as: personnel with specific expertise, machine re-
sources, property fees, and power consumption. Note that
the closer the CCV is to the intersection of both axis the
more autonomous characteristics it will have.
2.2.1 Public (Hosted) Clouds
Public Cloud visibility is where all three CCS layers are

Figure 2: Cloud Computing Visibility Levels.
commonly used. Applications in this visibility may deploy
their own services for other applications to consume or con-
sume exist
ing services from external sources. This visibility also con-
tains the most CCS products available due to its accessibility
atttributes. When deploying to the Public Cloud the appli-
cation’s time to develop, resources or cost, and custom scope
will play a key role in deciding which CCSP and CCS layer
to choose.
2.2.2 Private Cloud
The only difference between a Private and a Public Cloud
is that its services are only offered within a private virtual
network setting. A Private Cloud can be hosted by a CCSP
like AWS Virtual Private Connection (VPC) and Rackspace
Private Hosting or they can be located internally, in the
same premise as the organization utilizing it, for reasons of
performance and legal policies.
An internal Private Cloud is deployed with recent tools
such as Eucalyptus [5] an open source IaaS or Aneka [6] a
.NET PaaS. Such tools grant the ability to harness the re-
sources within a network in similar ways that commercial
IaaS and PaaS providers accomplish it. Eucalyptus was in-
troduced for the academic research arena and it has been
adopted by the industry to create their own internal pri-
vate clouds. Aneka is similarly deployed as a PaaS but it
is market oriented with its built-in pricing and accounting
features.
2.2.3 Hybrid Cloud
A Hybrid Cloud is much like an extended Private Cloud
into the public domain [7], although it can remain com-
pletely private. Hybrid Clouds are the most complex cloud
solutions due to data consistency concerns across the vir-
tual resources, security protocols involved, and management
complexity. Cloud management tools like RightScale, Joyent
Cloud Control, and AWS VPC become very useful in main-
taining all the types of clouds involved and their server im-
ages. However, these tools are not very affordable for small
to medium sized companies, the only current alternative is
to manage it manually. As pointed out in the [8] paper,
the lack of standards between Cloud Provider APIs makes
Figure 3: A simple flow chart of the decision making
process.
managing a system with multiple provider implementations
very difficult. Different APIs would need to be learned and
if changes occurred the system needs to deal with it through
re-factoring or costly re-implementations. Until a proper
Cloud Interoperability standard has been set, new services
may continue to emerge offering such interoperability man-
agement for a lofty price.
Much work is required to establish an open cloud inter-
operability standard, which is currently being spearheaded
by Open Grid Forum [9]. To show how Hybrid Clouds can
provide scalability, a simple scenario can be drawn up where
appropriate tasks are pushed to the Public Cloud in order
to offset the over loaded Private Cloud. Another scenario
could make use of a Virtual Private Network when offered
by the Public Cloud provider to handle sensitive and mis-
sion critical data. If company policies allow for the data
to be hosted in such an environment then the Public Cloud
can basically mirror the Private Cloud functionalities. Oth-
erwise only appropriate or safe tasks can be pushed to the
Public Cloud, to offset the workload from the Private Cloud.
3. PROBLEM AND METHODOLOGY
The remaining of this paper will focus on answering the
following question: Given the system’s attributes, usage
properties, business and management concerns, and data
privacy policies how should a software team cope with the ar-
chitectural decisions of implementing a cloud solution? We
illustrate the main decision process in Figure 3, starting with
the assumption that the application components discussed
in this section map nicely with the cloud, so that focus is
only placed on the cloud-based solution.
Ideally a solution already exists in a Public Cloud as a
service that can be re-used or built on to. If the Public
Cloud can be selected as an option, the next step is to dis-
cuss what CCS layer of abstraction to use (IaaS, PaaS, or
SaaS). Once the service layer has been chosen a CCSP is
decided on. Each provider has their own payment model,
services, management tools and APIs, and if they are not
using another’s infrastructure then they are using their own
server farms. Another decision to consider is how interoper-
ability between the chosen public providers can be done to
cut down on development and management costs.
System usage and requirements pose a lot of constraints,
resulting in the need to control many aspects of the infras-
tructure and choosing a service that is less autonomous.

Figure 4: Implementation of the Cloud System Ex-
ample.
There is a trade off as between satisfying a system’s require-
ments versus how autonomous the system can be, with more
autonomous leaning toward Public Clouds as pointed out in
the discussion for Figure 2 in Section 2.2. Hence, if the appli-
cation is not suited for the Public Cloud then the next step
is to look at whether a Hybrid Cloud solution is feasible.
One of the likely cases for this option is if mission critical or
sensitive data handling application modules can be deployed
in the Private Cloud and other less sensitive modules can be
deployed in Public Cloud. The other likely case is if a Pub-
lic Cloud provider can work in parallel with and provide a
secure virtual network to connect with the Private Cloud, if
there are no strict policies on data handling.
Lastly, if the Hybrid Cloud option is not feasible the sys-
tem is deployed strictly in a Private Cloud. This is the
result of strict policies, reliability, performance, and acces-
sibility requirements forcing the entire system and data to
reside within the physical premise of the organization. The
necessary personnel, machine, and networking resources will
need to be procured to support this solution.
4. A CLOUD APPLICATION EXAMPLE
We discuss three milestones for our fictional cloud-based
solution, shown in Figure 4. Each milestone outlining the
need for a different CCV and/or CCS. The business case is
an up and coming toy manufacturer that needs to manage its
inventory and forecast manufacturing resource needs based
on sales and marketing campaigns. This application is dis-
cussed as an example of how we can develop a cloud solution
that can take advantage of the CCVs discussed in Section
2.2, while maintaining the flexibility for future requirements
and new technology integrations. The general system spec-
ification starts off with a Manufacturing Resource Planning
(MRP) software that feeds data to a data storage service
within an internal Private Cloud. The second milestone il-
lustrates how a Hybrid Cloud solution can deal with intense
processing needs of generating reports. The last milestone
discusses the sales and CRM modules implemented in a Pub-
lic Cloud.
4.1 Milestone 1: MRP System (Private Cloud
Solution)
The MRP system is the core or heartbeat of the company,
without it nothing is produced nor sold. An online presence
is not advantageous for its core functionality due to potential
issues with the host or local ISP network. This component
manages the ever growing manufacturing process, resource
logs, and inventory management in a redundant and efficient
manner. System users: Floor Production Managers, Opera-
tors, and Administrative Professionals in the same physical
location as the Internal Private Cloud. Requirements: High
availability, redundancy, and performance so that services
provided to the manufacturing plant are not disrupted and
the operation is not halted. Portable and modular code so
that new technologies or new machines can be easily ported
and changed. Single-tenant machine infrastructure for bet-
ter stability and performance. Potential cloud-based tools:
Eucalyptus IaaS, Aneka PaaS
4.2 Milestone 2: Parallel Computing of Re-
ports (Hybrid Cloud Solution)
Periodic reports tend to be resource hogs due to the sheer
amount of data it needs to process and the time it takes
to execute on a single machine. If reports are securely out-
sourced to a Public IaaS provider via a secured network
connection it can be economically sound as pointed out in
the examples given by [2]. The hosted Private Cloud can
create as many instances required to receive the compressed
data and process the result in parallel. As long as upload-
ing the data fits the economies of scale then it is a fitting
solution. System users: Professional Administrators, Man-
agers, Accountants in the same physical location as the In-
ternal Private Cloud. Requirements: Secured dedicated line
from hosted Private Cloud IaaS to internal Private Cloud
IaaS. Web services running on the hosted Private Cloud IaaS
to accept requests only from the internal Private Cloud’s
IP. The encryption and decryption is an additional security
measure as it is unsure what type of security standards are
met on different cloud providers. The hybrid management
tool is optional but it is good to have in case complexity rises.
Potential cloud-based tools: Any Public IaaS provider with
a hybrid management tool (i.e. AWS VPC, RightScale) as
an option.
4.3 Milestone 3: Website and CRM Integra-
tion (SaaS Integration)
A sales website and Customer Relations Management (CRM)
tool implemented in a Public Cloud are a must for any
team of sale representatives. The integration of these tools
maps customers to potential or committed sales, maps sales
to manufacturing demands, and maps sales to an invoic-
ing and financial systems (not included in this example).
Web services need to be implemented on the Internal Pri-
vate Cloud to allow sales order creations, inventory checks,
and any other needs that may arise in the future. System
users: Sales representatives, Project Managers, Professional
Administrators, Accountants, and Operations Managers ac-
cessing the system from the Public Cloud. Requirements:
Sale representatives need constant online access to a system
with permissive policies, quick time-to market deployments,
and unpredictable usage spikes in order to reach as many
Web users as possible. Potential cloud-based tools: Website
and CRM deployments are very popular and are offered in
many different flavors by many SaaS and PaaS providers.
Off the shelf solution by SaaS providers like SalesForce.com,
Zoho, or HighRise. Web frameworks by PaaS providers En-
gine Yard, Google App Engine, or Engine Yard.
5. CLOUD COMPUTING IMPLEMENTATION
CONSIDERATIONS
Cloud-based applications should be built to maximize the
current and future potential of the cloud. A detailed discus-
sion on the cloud architecture implementation is not covered
in the above example, but it is important to mention a few
considerations: code portability and modularity, scalability,
data security, availability, and legal policies.
A cloud solution with portable and modular code will ease
the replacement of modules with newer technologies and
the migrating of the system from one provider to another.
Portability provides the flexibility to migrate software com-
ponents or the entire software from one provider to another.
Modularization helps to clearly define the boundaries of the
system’s functionalities, easing the process of software mod-
ifications. Cloud architectures are horizontally scalable in
nature. Parallel computing and RESTful [10] models are
also horizontally scalable in nature making them good can-
didates for cloud-based solutions. These options provide the
means for an extremely scalable system, especially useful in
the case of Public Cloud services with unpredictable usage
spikes.
Data security can be properly deployed on public clouds
via two-way encryption, single-tenant hardware, and secured
private networks. What is of more significance than secu-
rity in public clouds is the availability and legal policies in
regarding data storage and handling. When these concerns
become issues they lead to legal consequences, production
halting, and financial lost. For these reasons we look at
these attributes when choosing between the CCV levels.
6. FUTURE CLOUD DEPLOYMENT CON-
SIDERATIONS
Cloud-based applications like the example give in this pa-
per need to consider many changes that will still emerge in
the CC arena. One way or another the application’s main-
tenance and costs will be impacted by CCS interoperability,
better cloud management tools, upgraded telecommunica-
tion infrastructures, upcoming thin and mobile client capa-
bilities, and more sophisticated PaaS for higher level devel-
opment. We outline these factors below.
The rise of CCS interoperability will bring more econom-
ical and flexible cloud management tools. The [8] study
points to cloud standardization initiatives by the Distributed
Management Task Force’s Open Cloud Standards Incubator
[11], Open Cloud Computing Interface Working Group [12],
and Cloud Data Management Interface [9]. This initiative
will bring capabilities like cloning services across multiple
CCSPs and geographical locations that are autonomously
routed to the client based on context awareness.
Telecommunication infrastructure upgrades will push the
demand for real-time platforms and services that require
higher bandwidth such as video and audio. As more people
sign up for mobile internet we will begin to see more appli-
cations that can make use of cloud architectures with real
time data. CCS consumption by mobile clients is on the
rise with Palm’s WebOS and Rhomobile’s Rhosync making
use of cloud-based synchronization schemes among others.
According to [13] everyday things like travel checks and su-
permarket runs are in demand, this type of mobile usage
has a really large market and considerable growth potential
being such common tasks.
Emerging platforms and languages that are more cloud-
friendly can have a great impact on how developers adopt
the cloud. The rise of server-side JavaScript may play a
significant role in the future of cloud-based platforms, since
JavaScript is a language familiar to all Web developers re-
gardless of what server-side languages they use. Joyent’s
Smart Platform, currently in Beta, is one such contender
that provides developers a JavaScript framework to build
APIs and databases without the need to do any server-side
configuration. Smart Platform is a server-side JavaScript
PaaS, which means any Web developer with no server-side
programming and maintenance experience can now create
full blown Web applications with portable code. Domain
specific languages like SalesForce’s Apex and Yahoo! Pipes
are slowly emerging in the cloud domain. A good question
for a future study would be how DSL can impact CC not
only as a development tool but as a cloud management tool.
7. CONCLUSION
The CC arena is in its infancy with a large area for im-
provement and growth. This research paper provides a prag-
matic look at how a cloud-based application is deployed, out-
lining key considerations to accommodate current attributes
and future enhancements of CC. Our discussion points re-
volving the CCV and CCS help provide a clear decision path
for the abundance of options decision makers are faced with.
The decision process also involves much discussion by the
software team because of its inter-disciplinary nature.
We can derive from our discussions and graphs that cloud
applications handling mission-critical data tend to use a
more complex architecture involving Hybrid and/or Private
Clouds. We can also state that applications requiring online
availability and standard functionalities are prone to be de-
veloped on a Public Cloud PaaS or SaaS to lower start-up
and maintenance costs. The common implementation rec-
ommendations among all cloud applications are code porta-
bility and modularity to ease future changes, due to the un-
formed state of the art. Application deployment decisions
will be cut down as cloud interoperability and new technolo-
gies emerge.
8. REFERENCES
[1] Wikipedia. Cloud computing.
”http://en.wikipedia.org/wiki/Cloud Computing”,
December 2009.
[2] Michael Armbrust, Armando Fox, Rean Griffith,
Anthony D. Joseph, Randy Katz, Andy Konwinski,
Gunho Lee, David Patterson, Ariel Rabkin, Ion
Stoica, and Matei Zaharia. Above the clouds: A
berkeley view of cloud computing. Technical report,
UC Berkeley Reliable Adaptive Distributed Systems
Laboratory, February 2009.
[3] Amazon web services. ”http://aws.amazon.com/”, Jan
2010.
[4] Darryl Chantry. Mapping applications to the cloud.
Technical report, The Architecture Journal, 2009.
[5] Daniel Nurmi, Rich Wolski, Chris Grzegorczyk,
Graziano Obertelli, Sunil Soman, Lamia Youseff, and
 Dmitrii Zagorodnov. The eucalyptus open-source
cloud-computing system. In 9th IEEE/ACM Intl
Symposium on Cluster Computing and the Grid, 2009.
[6] Christian Vecchiola, Xingchen Chu, and Rajkumar
Buyya. Aneka: A software platform for .net-based
cloud computing. Technical Report
GRIDS-TR-2009-4, University of Melbourne,
Australia, May 2009.
[7] James Staten. How to build a hybrid cloud computing
strategy.
”http://www.cio.com/article/493492/How to Build a Hybrid Cloud Computing Strategy”,
May 2009.
[8] Guilherme Sperb Machado, David Hausheer, and
Burkhard Stiller. Considerations on the
interoperability of and between cloud computing
standards. Communication Systems Group CSG,
Department of Informatics IFI, University of Zürich,
2009.
[9] OGF. Open grid forum. ”http://www.ogf.org/”, 1
2010.
[10] Roberto Lucchi, Michel Millot, and Christian Elfers.
Resource oriented architecture and rest. Technical
report, European Commission Joint Research Centre
Institute for Environment and Sustainability, con
terra, 2008.
[11] DMTF. Open cloud standards incubator.
”http://www.dmtf.org/about/cloud-incubator”,
February 2010.
[12] OGF. Open cloud computing interface.
”http://www.occi-wg.org/”, 1 2010.
[13] Essential. Branded services will make smartphones.
“http://www.essentialresearch.co.uk/blog/2010/01/branded-
services-will-make-smart-phones/”, February
2010.