This action might not be possible to undo. Are you sure you want to continue?
Computer Science Department University of Saskatchewan SK S7N 5C9, Canada
In this research paper we look at how to harness Cloud Computing (CC) options pragmatically. CC has yet to mature and gain mass acceptance by the IT industry, but all the beneﬁts 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 application 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 speciﬁc solutions. We have made an amalgamation of previous CC studies, a survey of the diﬀerent CCSPs, and a look at CC management tools.
Cloud Computing, Hybrid Cloud, Architecture, Software Management.
HISTORY AND INTRODUCTION
Cloud Computing (CC) draws elements from diﬀerent systems: Grid Computing, clusters working towards solving a task; Utility Computing, computing resources served as a metered service; and Autonomic Computing, self-managed systems . Wikipedia deﬁnes CC as ”a new supplement, consumption and delivery model for IT services based on the Internet, and it typically involves the provision of dynamically 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 corporations like Amazon and Google to oﬀer their high-end infrastructure to developers. These service providers among others oﬀer their computer and network infrastructure as a utility service with application or Software as a Service
(SaaS), virtual machine instance management or Infrastructure as a Service (IaaS) and development Platform as a Service (PaaS). These services became known as Cloud Computing Services (CCS). Many companies now provide innovative services built on top of the CCSs such as cloud management and monitoring tools. The  paper mentioned three attractive reasons for developing with CCS: short-term usage, low start-up cost, and inﬁnite 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 factors need to be looked at and  formulated how proﬁtable 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 conﬁdence of more CCS users. There are many skeptics of CCS usage, due to the high proﬁle it gets when malicious or unintentional service outages 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 diﬀerent geographic location options like Amazon Web Service (AWS) Regions  for increased up-time, providing a Hybrid Cloud (discussed in 2.2.3) solution to conform with strict policies, and using open solutions like Joyent Smart Platform for code portability. The uniﬁcation 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 traﬃc policies, respectively. As more cloud-based solutions succeed and become the status quo, it will help quiet the skeptics. The technical report  oﬀered 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 eﬀectiveness 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 eﬀective. This view favored large enterprises as opposed to small to medium sized businesses that can not always aﬀord to be tied in with a single vendor, especially if
Figure 1: CCS layers of abstraction.
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 implementation 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 eﬀort for creating and managing your infrastructure. Some CCSPs and third parties attempt to solve this issue by oﬀering simpler interfaces.
vendor policies change. In this paper we adopt a pragmatic approach for deploying 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 appropriately to the cloud and that a cloud-based solution is cost eﬀective based on the formula derived in . 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 significantly alter the cloud deployment decisions and must be looked at on a case by case basis. It is close to impossible to ﬁnd 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 ﬁctional 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.
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 speciﬁc framework (i.e. Google App Engine, Azure Platform, Appcelerator, Rhohub). Custom Web 2.0 and mobile application developers have embraced PaaS due to its ﬂexibility and low-startup investment. Applications 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.
SaaS Development Layer
CLOUD COMPUTING ARCHITECTURE
CCA can be broken down into its visibility and its development service layers. The following subsections explain the advantages the CCS layers provide for the developer and how they are typically used in diﬀerent cloud visibility. We start our discussion with the CCS layers to get a base understanding of what services are available and move on to CCV to see how and where the layers are integrated in the architecture.
SaaS is considered the oldest CCS layer. There are some CCSPs that cross or merge the line between PaaS and SaaS, we therefore deﬁne SaaS as working in a speciﬁc domain; whereas PaaS is more ﬂexible in these terms. When developing 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 Speciﬁc Language (DSL) for the application being developed (i.e. Force.com, LongJump, Yahoo! Pipes). Note that some providers fall under both cases. SaaS development tends to have fast deployment cycles but they are tightly dependent on a provider and domain.
Cloud Computing Visibility
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.
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 diﬀerent services oﬀered by the same CCSP. The main diﬀerences among CCSPs are their pricing structures, cloud
CCV determines how system administrators, developers, and end-users access the CCS being provided. Figure 2 shows the diﬀerent CSV levels with the Conventional (noncloud) Infrastructure included for comparison sake. Each level may contain the diﬀerent 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 Control” is used to describe code portability, platform and data structure ﬂexibility, 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 investment” will be involved in the start-up and production costs such as: personnel with speciﬁc expertise, machine resources, 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.
Public (Hosted) Clouds
Public Cloud visibility is where all three CCS layers are
Figure 3: A simple ﬂow chart of the decision making process. Figure 2: Cloud Computing Visibility Levels. managing a system with multiple provider implementations very diﬃcult. Diﬀerent 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 oﬀering such interoperability management for a lofty price. Much work is required to establish an open cloud interoperability standard, which is currently being spearheaded by Open Grid Forum . 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 oﬀset the over loaded Private Cloud. Another scenario could make use of a Virtual Private Network when oﬀered by the Public Cloud provider to handle sensitive and mission 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. Otherwise only appropriate or safe tasks can be pushed to the Public Cloud, to oﬀset the workload from the Private Cloud.
commonly used. Applications in this visibility may deploy their own services for other applications to consume or consume exist ing services from external sources. This visibility also contains the most CCS products available due to its accessibility atttributes. When deploying to the Public Cloud the application’s time to develop, resources or cost, and custom scope will play a key role in deciding which CCSP and CCS layer to choose.
The only diﬀerence between a Private and a Public Cloud is that its services are only oﬀered 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  an open source IaaS or Aneka  a .NET PaaS. Such tools grant the ability to harness the resources within a network in similar ways that commercial IaaS and PaaS providers accomplish it. Eucalyptus was introduced for the academic research arena and it has been adopted by the industry to create their own internal private clouds. Aneka is similarly deployed as a PaaS but it is market oriented with its built-in pricing and accounting features.
PROBLEM AND METHODOLOGY
A Hybrid Cloud is much like an extended Private Cloud into the public domain , although it can remain completely private. Hybrid Clouds are the most complex cloud solutions due to data consistency concerns across the virtual resources, security protocols involved, and management complexity. Cloud management tools like RightScale, Joyent Cloud Control, and AWS VPC become very useful in maintaining all the types of clouds involved and their server images. However, these tools are not very aﬀordable for small to medium sized companies, the only current alternative is to manage it manually. As pointed out in the  paper, the lack of standards between Cloud Provider APIs makes
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 architectural 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 discuss 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 interoperability 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 infrastructure and choosing a service that is less autonomous.
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 eﬃcient manner. System users: Floor Production Managers, Operators, 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 better stability and performance. Potential cloud-based tools: Eucalyptus IaaS, Aneka PaaS Figure 4: Implementation of the Cloud System Example.
Milestone 2: Parallel Computing of Reports (Hybrid Cloud Solution)
There is a trade oﬀ as between satisfying a system’s requirements 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 application 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 Public 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 system is deployed strictly in a Private Cloud. This is the result of strict policies, reliability, performance, and accessibility 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.
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 outsourced to a Public IaaS provider via a secured network connection it can be economically sound as pointed out in the examples given by . The hosted Private Cloud can create as many instances required to receive the compressed data and process the result in parallel. As long as uploading the data ﬁts the economies of scale then it is a ﬁtting solution. System users: Professional Administrators, Managers, Accountants in the same physical location as the Internal 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 diﬀerent 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.
A CLOUD APPLICATION EXAMPLE
We discuss three milestones for our ﬁctional cloud-based solution, shown in Figure 4. Each milestone outlining the need for a diﬀerent 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 discussed 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 ﬂexibility for future requirements and new technology integrations. The general system speciﬁcation starts oﬀ with a Manufacturing Resource Planning (MRP) software that feeds data to a data storage service within an internal Private Cloud. The second milestone illustrates 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 Public Cloud.
Milestone 3: Website and CRM Integration (SaaS Integration)
Milestone 1: MRP System (Private Cloud Solution)
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 invoicing and ﬁnancial systems (not included in this example). Web services need to be implemented on the Internal Private 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 accessing 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 oﬀered in many diﬀerent ﬂavors by many SaaS and PaaS providers. Oﬀ the shelf solution by SaaS providers like SalesForce.com,
Zoho, or HighRise. Web frameworks by PaaS providers Engine Yard, Google App Engine, or Engine Yard.
CLOUD COMPUTING IMPLEMENTATION CONSIDERATIONS
Cloud-based applications should be built to maximize the current and future potential of the cloud. A detailed discussion 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 ﬂexibility to migrate software components or the entire software from one provider to another. Modularization helps to clearly deﬁne the boundaries of the system’s functionalities, easing the process of software modiﬁcations. Cloud architectures are horizontally scalable in nature. Parallel computing and RESTful  models are also horizontally scalable in nature making them good candidates 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 signiﬁcance than security 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 ﬁnancial lost. For these reasons we look at these attributes when choosing between the CCV levels.
FUTURE CLOUD DEPLOYMENT CONSIDERATIONS
Cloud-based applications like the example give in this paper need to consider many changes that will still emerge in the CC arena. One way or another the application’s maintenance and costs will be impacted by CCS interoperability, better cloud management tools, upgraded telecommunication infrastructures, upcoming thin and mobile client capabilities, and more sophisticated PaaS for higher level development. We outline these factors below. The rise of CCS interoperability will bring more economical and ﬂexible cloud management tools. The  study points to cloud standardization initiatives by the Distributed Management Task Force’s Open Cloud Standards Incubator , Open Cloud Computing Interface Working Group , and Cloud Data Management Interface . 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 applications 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.
The CC arena is in its infancy with a large area for improvement and growth. This research paper provides a pragmatic look at how a cloud-based application is deployed, outlining key considerations to accommodate current attributes and future enhancements of CC. Our discussion points revolving 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 developed on a Public Cloud PaaS or SaaS to lower start-up and maintenance costs. The common implementation recommendations among all cloud applications are code portability and modularity to ease future changes, due to the unformed state of the art. Application deployment decisions will be cut down as cloud interoperability and new technologies emerge.
 Wikipedia. Cloud computing. ”http://en.wikipedia.org/wiki/Cloud Computing”, December 2009.  Michael Armbrust, Armando Fox, Rean Griﬃth, 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.  Amazon web services. ”http://aws.amazon.com/”, Jan 2010.  Darryl Chantry. Mapping applications to the cloud. Technical report, The Architecture Journal, 2009.  Daniel Nurmi, Rich Wolski, Chris Grzegorczyk, Graziano Obertelli, Sunil Soman, Lamia Youseﬀ, and
Dmitrii Zagorodnov. The eucalyptus open-source cloud-computing system. In 9th IEEE/ACM Intl Symposium on Cluster Computing and the Grid, 2009. 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. 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. 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, u 2009. OGF. Open grid forum. ”http://www.ogf.org/”, 1 2010. 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. DMTF. Open cloud standards incubator. ”http://www.dmtf.org/about/cloud-incubator”, February 2010. OGF. Open cloud computing interface. ”http://www.occi-wg.org/”, 1 2010. Essential. Branded services will make smartphones. “http://www.essentialresearch.co.uk/blog/2010/01/brandedservices-will-make-smart-phones/”, February 2010.