Migration of an on-premise application to the Cloud ...gersch/ESOCC13-extended_version.pdf · an on-premise application to the Cloud and what are the consequences of the migration

Migration of an on-premise application to theCloud: Experience report?

Pavel Rabetski and Gerardo Schneider

Chalmers | University of Gothenburg, Sweden

Abstract. The promise of an easy and cost efficient way of hosting ap-plications, with dynamic scaling and geographical distribution possibili-ties, makes the Cloud very attractive to many organizations. However, astoday it is still not clear how and when cloud computing should be used.Developers very often write applications in a way that does not really fita cloud environment, and in some cases without taking into account howquality attributes (like performance, security or portability) are affected.There is a clear need of further studies on how existing systems should beplugged into the Cloud and what are the consequences of the migration.In this paper we share our experience and observations from adoptingcloud computing for an on-premise enterprise application in a contextof a small software company. Besides reporting on the migration of anexisting software system to the Cloud, we present experimental resultsconcerning a comparative evaluation (w.r.t. performance and cost) of thebehavior of the original system both on-premise and on the the Cloud,considering different scenarios in the Cloud. In addition we present asummary of the opportunities and challenges identified for a migrationto the Cloud, as well as a comparative study of the biggest cloud plat-forms.

1 INTRODUCTION

Cloud computing refers to a utility-based provisioning of virtualized computa-tional resources over the Internet. Even though computing as a utility is not anew concept [22], it has only recently become commercially available due to newtechnological shifts in virtualization, distributed computing and communicationtechnologies. From a long-held dream cloud computing has turned into a newpromising trend of the IT industry that is about to change the way compu-tational resources and software are designed and purchased. Bottery et al [3]believes that the emergence of cloud computing will fundamentally transformthe economics of the multi-billion dollar software industry. Market-research firmIDC estimates the market for public cloud products and services growing to $42billion by 2012 [16], while strategy consulting firm AMI-Partners predicts thatsmall business spending on cloud computing will hit $100 billion by 2014 [12].

Despite such promising predictions, there is a big confusion among poten-tial adopters as cloud computing is not mature enough. Indeed, it is not clear

? Extended version of the paper submitted to ESOCC’13.

2 Migration of an on-premise application to the Cloud: Experience report

what cloud computing is and when it is convenient to use it [1]. According tothe Gartner report [6], cloud computing will become the preferred option forapplication development only around 2015, despite initial growth. Moreover, thelack of standards and keen competition on the new market has led to the varietyof idiosyncratic cloud platforms. Cloud giants like Amazon, Google, Microsoft,and SalesForce are trying to establish their rules and promote their franchise.Choosing a proper cloud provider additionally complicates the migration plan-ning, especially for smaller companies that do not have resources for extensiveresearch on cloud computing. Our aim here is to contribute to the understandingof how and when to use the cloud, helping to reduce confusion among potentialadopters by providing some guidelines regarding migration of existing applica-tions to the Cloud.

The main objective of this work is to analyze what does it means to migratean on-premise application to the Cloud and what are the consequences of themigration. We perform our study on a specific industrial case study described indetail later in the paper. Our main contributions are:

1. A detailed study of the advantages and the disadvantages of cloud com-puting, and the effects of migration of an on-premise application into thecloud;

2. An evaluation of existing public cloud platforms in order to make a rationalchoice of a specific one suitable for our purposes;

3. The migration of an industrial enterprise web application to the Cloud;4. The performance of experiments on the cloud version of our application.

Based on our experimental results we draw conclusions on the consequencesof the migration and provide suggestions on how to extrapolate our experienceto other similar software systems.

The rest of the paper is organized as follows: Section 2 gives necessary back-ground information. Section 7 presents a brief overview of the related work.Section 3 describes the opportunities and the challenges of cloud computing.Section 4 evaluates existing cloud implementations. Section 5 describes the mi-gration of an industrial enterprise system to the chosen cloud provider. Section6 describes performed experiments and the results. Section 8 summarizes theresults and suggests future research direction.

2 BACKGROUND

In this section we give a definition of cloud computing along with its key char-acteristics. In addition, we describe existing cloud classifications depending onthe deployment type and provided capabilities.

2.1 Cloud computing

Cloud computing usually refers to a utility-based provisioning of computationalresources over the Internet. Widely used analogies to explain cloud computing

Migration of an on-premise application to the Cloud: Experience report 3

are electricity and water supply systems. Like the Cloud, they provide centralizedresources that are accessible for everyone. Also, in the Cloud you only pay forwhat you have used. And finally, it is usually consumed by those who havedifficulties to produce necessary resources by themselves or just do not want todo that.

Despite the description by analogy, it is difficult to give a unique and precisedefinition. One of the main ambiguities to define cloud computing is the fact thatit is still evolving and taking its shape. The definitions proposed in the cloudcomputing community are often focused on different perspectives and do nothave common baselines. Analyzing existing sources in order to identify commoncharacteristics, Vaquero et al [28] observed that there is no clear and completedefinition in the literature. Nevertheless, the authors proposed three features thatmost closely describe cloud computing: scalability, pay-as-you-go utility model ,and virtualization, and gave the following definition [28]:

“Clouds are a large pool of easily usable and accessible virtualized re-sources (such as hardware, development platforms and/or services). Theseresources can be dynamically reconfigured to adjust to a variable load(scale), allowing also for an optimum resource utilization. This pool ofresources is typically exploited by a pay-per-use model in which guaran-tees are offered by the Infrastructure Provider by means of customizedSLAs.”

This definition, similar to other descriptions (see for instance [8]), reveals themain cloud characteristics:

– Virtualization (abstracted infrastructure). Cloud computing became possiblethrough a new evolution of virtualization. Virtualization enables dynamic in-frastructure utilization, resource sharing, isolation and security. In contrastto a standard model when processing takes place on specific hardware de-fined in advance, applications do not have any static computing place in avirtualized cloud environment. Resources are allocated dynamically depend-ing on the demand. Thus, customers do not know the exact place and thetype of hardware their applications are running on. Cloud providers can onlyguarantee minimum performance or storage capacity for the customer.

– A pay-per-use model. This is the key characteristic of cloud computing eco-nomics. All resources in the Cloud are available on a utility basis, meaningthat users are charged based on the quantity consumed by them. This modelallows entering the market with no upfront investments into own hardwareinfrastructure.

– On-demand access. On-demand access means that resources like CPU timeor storage can be provisioned automatically when needed without any extramanagement effort.

– Elastic scalability. Elastic scaling signifies that computational resources, usedby the application, can be dynamically scaled up or down. In other words,virtualized hardware resources can be resized easily and rapidly on demand.


It makes a utility model even more attractive, because consumers use onlywhat they really need.

– Resource pooling. Computing resources of the provider are shared acrossmultiple users. Different resources are pooled in a multi-tenant way so thatthey can be dynamically assigned and reassigned to serve consumers’ needs.

– Network access. Everything in the Cloud is connected via the network. End-users access services via the Internet, developers deploy and monitor appli-cations in the same way, communication between different services in theCloud occurs through the network. Cloud computing platforms usually pro-vide REST-based APIs to their services.

– Usability. Normally cloud computing platforms provide a simple externallymanaged environment to hide deployment and operating details from theuser. Cloud computing systems provide APIs to interact with the environ-ment, which simplifies the development.

2.2 Classifications of the Cloud

There are two widely used cloud computing classifications. The first one describesfour cloud types depending on the deployment location:

– Public clouds. Public or external clouds are traditional clouds where re-sources are dynamically provisioned via the Internet by the off-site third-party providers. These resources are publically available to everyone. Cloudconsumers are charged depending on the quantity used. Examples are Mi-crosoft Azure1, Google App Engine2, and Amazon Web Services3.

– Private clouds. Private clouds usually refer to the emulation of a cloud com-puting environment on private infrastructure. Since users still have to buyhardware and operating equipment, private clouds are often criticized [11,20]. Many companies try this type of cloud to verify their software locallybefore deploying it to public cloud.

– Community clouds. Community clouds are cloud environments establishedacross several organizations. They can be managed by the organizationsthemselves or by third-parties, and may be installed either on- or off-premise.

– Hybrid clouds. This term refers to a composition of two or more clouds, in-cluding private clouds and public clouds. This model can be used for differentpurposes. For example, archiving or replicating local data in the public cloud,or dealing with peak loads when the on-premise system uses the public cloudcapacity only when needed.

The second classification is a widely used cloud ontology describing threecloud models depending on the provided capabilities [30]: i) Infrastructure as aService (IaaS), ii) Platform as a Service (PaaS), and iii) Software as a Service(SaaS). It is also called a cloud stack (Fig. 1) because they are somehow typically

1 http://www.microsoft.com/windowsazure/2 http://code.google.com/appengine/3 http://aws.amazon.com/


Fig. 1. Cloud stack

built on top of each other. They can exist independently or may co-exist. Dueto the lack of standardization it is not very clear where lies the exact boundariesbetween the components of the cloud stack.

– IaaS. The infrastructure layer represents fundamental resources that are thebasis for the upper layers. It is very similar to a regular virtual server hosting.IaaS is built directly on the hardware, providing virtualized resources (e.g.storing and processing capacities) as a service. These resources can be split,dynamically resized and assigned to consumers depending on their demand.In the most common scenario, the consumers are the platform (PaaS) orapplication (SaaS) layers that use these resources to build new cloud soft-ware environments or applications. IaaS is sometimes subcategorized intocomputational resources, data storage, and communication [30]. Examplesof public IaaS providers are Amazon Web Services and GoGrid4.

– PaaS. The platform layer provides a higher level software platform with ex-tended services where other systems can run. This layer is usually built ontop of IaaS. It delivers a programming-language-level environment with aset of language-integrated APIs for implementing and deploying SaaS ap-plications, which makes PaaS very comfortable and clear for developers. Inaddition to that, the platform layer usually has built-in scaling, load balanc-ing, and numerous services for communication, authentication, caching, etc.It further speeds up development, deployment and configuration processesbecause programmers can focus more on the core logic. Microsoft Azure andGoogle App Engine are examples of PaaS.

– SaaS. The services exposed in this layer represent alternatives to locallyrunning end-user applications. They are usually interesting for a wide mar-ket, compared to IaaS or PaaS. Services in this layer can be built on top ofPaaS or IaaS. They can also be composed from other services available inthe Cloud. The application layer provides interfaces for thin or thick clientslike web browsers or smart phones. Normally SaaS applications are accessed

4 http://www.gogrid.com/


through web-portals for some fee. Microsoft Office365 or Gmail are examplesof software as a service. The SaaS model has proven to be attractive to bothproviders and consumers [30].

Fig. 2. IT-capacity allocation: (a) on-premise, (b) in the Cloud. Taken fromhttp://msdn.microsoft.com/library/windowsazure

3 ADVANTAGES AND CHALLENGES OF CLOUDCOMPUTING

Despite an initial enthusiasm towards adopting cloud computing, based on itsinnumerable advantages, it has been recognized that it is not yet as maturea technology as to be widely used as expected. Decision makers need a clearunderstanding of the advantages and the challenges of cloud computing in orderto make a rational decision whether or not to migrate an existing application.In this section we summarize the information collected from different sources[3][16][1][21][4][15][29][10][25][9][7], adding our own reflection, on the advantagesand disadvantages of cloud computing. The first part of the section focuses onthe benefits, and the second part describes its challenges.

3.1 Advantages of cloud computing

No upfront investments Companies usually have to create their own datacenters to reliably support large software systems. In addition to hardware forcomputing, networking and storing data, these centers require cooling systems,uninterruptible power supplies (UPS), and other expensive equipment. Hard-ware and equipment should be purchased and installed in advance to fulfill the


Fig. 3. Application stack for: (a) standard packaged software, (b) IaaS, (c) PaaS, (d)SaaS. Taken from http://msdn.microsoft.com/library/windowsazure

expected system load. Furthermore, experienced personnel are needed to man-age data centers. Cloud computing eliminates most of these upfront investments.Companies can simply host their applications on cloud providers’ data centers,paying only for consumed resources. This model is especially attractive for star-tups or small organizations because it can significantly reduce time to market.

On-demand capacity On-premise installations often struggle with differentload patterns. Some patterns can be predicted while others cannot. An exam-ple of a predictable pattern is an enterprise service that is under the load onlyduring working hours. A news service, however, meets a heavy traffic after break-ing events that are difficult to forecast. A lack of capacity can result in a badcustomer experience, while surplus hardware is an inefficient capital allocation.According to statistics, corporate servers are usually more than 80% underuti-lized [1]. Fig. 2(a) shows that IT-capacity for on-premise systems is allocatedin advance to meet the predicted load. However, the actual load can be lower(which means that hardware is underutilized) or higher (which means that thesystem is starving). Cloud computing provides a much more flexible model ofcapacity provisioning, when the resources dedicated to the application can bescaled up or down within minutes (see Fig. 2(b)). Consequently, the users areable to consume the minimum required capacity at any time. This makes a cloudutility model even more financially attractive.

Focus on core application The application stack for standard packagedsoftware consists of many components beyond the application itself, including


networking, storage, servers, operating system, middleware, and runtime (seeFig. 3(a)). Usually, system providers manage the whole stack, which involvesan additional configuration and management effort. Cloud computing reducesthis overhead, so companies can be more focused on their primary applications.Fig. 3(b) shows the application stack for IaaS. , IaaS providers take care ofnetworking, storage, servers, and virtualization, while IaaS users are responsi-ble only for OS, middleware, runtime, data and their applications. PaaS furthernarrows down vendors’ focus to data and applications only. Finally, SaaS com-pletely abstracts end-users from all listed components, providing the necessaryservice available anytime from everywhere on the Internet.

Potential for more sales SaaS applications are more attractive to end-userscompared to regular on-premise systems. Desktop or server installations usuallyrequire expensive powerful machines, in-house IT expertise, and technical per-sonnel, while SaaS applications basically need only a web browser. Furthermore,cloud applications do not require any installation or regular updates. Anotheradvantage of SaaS applications is that they usually have a pay-for-use licensingmodel [1], unlike on-premise commercial products. This model can potentiallybring new customers (such as smaller organizations), because they face muchlower financial commitments. And finally, the Cloud capacity opens new pos-sibilities for high-performance computing (HPC) applications. Since the use ofone CPU during 1000 hours costs the same as the use of 1000 CPUs during onehour, applications can execute hundreds or thousands more tasks in parallel.

Easier customer maintenance Usually on-premise packages are distributedacross many customers. Independent software vendors (ISV) have to work withevery customer personally, when it comes to installation assistance, upgrading,and handling issues. ISVs often do not have access to a customer environment,which makes it even more difficult. The maintenance overhead grows with thenumber of users. In contrast to that, cloud platforms allow centralized accessto applications. Service providers can easily deploy their applications, deliveringupdates for all customers simultaneously without any down time. This model alsoeliminates the need of supporting older product versions. Moreover, developersalways have unimpeded access to the necessary information stored in the Cloud.

Platform-provided features Cloud providers apply their knowledge and ex-perience to build their platforms. They use different techniques to address secu-rity, availability, and performance issues. For example, high availability is usuallyachieved through data redundancy and health monitoring. Cloud providers tryto make data replicas independent (including energy, connectivity and hard-ware independence). So the application keeps running even in case of a naturaldisaster. Additionally, cloud providers offer geographical data distribution andContent Delivery Network (CDN) services, which decreases latencies and resultsin a better end-user experience. The same level of global data distribution and


redundancy would be very expensive or even impossible to achieve by indepen-dent software vendors. Many more features and integrated services are offeredin a cost efficient way by public cloud providers.

3.2 Adoption challenges

Security and privacy Security and privacy are the most discussed issues ofcloud computing. Even though security is improved through data centralizationand security-oriented components [14], there is still a concern regarding sensitiveinformation stored in the Cloud. Since users do not fully control their data theyhave to trust cloud providers in securing it. Also, the risk of a data leakage on theway to the Cloud brings new challenges regarding secure transportation. VPN orencrypted data tunneling between the local machine and a cloud environment arepossible solutions. Private cloud installations were partly motivated by securityand privacy concerns.

Availability Another cloud adoption issue is availability. Even though cloudproviders offer a high level of availability through SLAs, outages do occur incloud platforms. There are two types of outages: a permanent and a temporaryoutage. The first one means that the cloud provider goes out of business. Atemporary outage means service unavailability during a relatively short periodof time like several hours. The biggest cloud providers have experienced severalserious outages for the past several years [24]. There are some precautions thatcloud consumers can take to mitigate the risk. For example, they can use theCloud for non-critical systems, keep on-premise backups, and set up a servicelevel agreement. In general, large cloud providers are usually more reliable thansmall ones.

Performance There are also some performance implications when adoptingcloud computing. Virtualization and resource sharing lead to performance un-predictability, especially for I/O resources. Cloud platforms should guarantee afair resource distribution across the applications running on the same machine.Unlike on-premise systems that can keep their code and data in the same runtimeenvironment, cloud components communicate via the network. Since users can-not control the exact deployment location, application components are usuallyspread across many servers. This results in higher latencies and bandwidth limi-tations. Performance can become a serious problem, especially when the numberof requests and the amount of data increase. Cloud platforms often provide spe-cial caching mechanisms and CDN services that can partly compensate theseissues.

Compliance requirements Many enterprises, especially in the US, are regu-lated by government policies regarding data security and disclosure, like Sarbanes-Oxley Act for corporate accounting data and Health Insurance Portability and


Accountability Act (HIPPA) for people’s healthcare insurance data. Most ofthese rules do not consider cloud services [15], so it is unclear whether or notcloud computing services violate the regulations. We will not analyze those is-sues in this paper though we believe it is an important aspect to be taken intoaccount when adopting the Cloud.

Vendor lock-in Commercial cloud platforms have idiosyncratic implementa-tions which imply different supported programming languages, IDEs, tools, op-erating systems, integrated services, APIs and unique persistent storages. Cloudplatforms have poor interoperability and integration possibilities, so applicationsbecome sticky to the provider they are designed for. It makes difficult to designapplications that can be easily plugged into several cloud platforms or deployedon-premise and in the Cloud at the same time.

Multi-tenancy Traditional on-premise software packages can usually be cus-tomized in various ways because they are installed for each customer separately.In contrast to that, SaaS applications are multi-tenant, meaning that a singlecopy of software is shared by all users. Customization of cloud systems is thusvery limited and requires an extra development effort.

Technological restrictions Cloud platforms have different technological re-strictions that complicate the application migration. It can be runtime envi-ronment restrictions or a limited set of supported languages, frameworks anddata storages. For example, .NET applications cannot run on AppEngine, sinceit supports only Java, Python and Go runtime environments. Also, MicrosoftAzure does not support any operating system other than Windows. Technolog-ical limitations might require a significant or a complete system reimplementa-tion. Legacy systems are usually subject to the risk. Moving these systems to acloud environment is likely to be expensive due to a large number of requiredchanges.

Licensing A regular software licensing model for commercial software does notmatch cloud computing because licenses commonly restrict the computers onwhich the software can run. It brings ambiguities when using supporting com-mercial software for SaaS applications. Confusing licensing terms and conditionsis one of the biggest obstacle for adopting the Cloud, especially for large or-ganizations [9]. Even if a cloud-enabling system does not use any supportingsoftware, the system itself might not have a proper licensing model. Softwarevendors need to reconsider the way they charge for their products in order tosell in the Cloud.

4 PUBLIC CLOUD PLATFORMS

Once software vendors have decided to adopt cloud computing, the next step is tochoose a suitable cloud platform. In this section we describe three major public


cloud platforms, namely, Amazon AWS, Microsoft Azure and Google AppEngine.We emphasize properties that are likely to affect the decision on which oneto adopt, including supported languages and frameworks, runtime environmentrestrictions, platform-provided services and features, and pricing models.

4.1 Amazon Web Services

Amazon Web Services (AWS) represents a set of online services that form to-gether a cloud computing platform. Amazon has built large-scale, reliable andefficient IT infrastructure where customers can host their applications. CurrentlyAmazon has data centers in five regions: US East (Northern Virginia), US West(Northern California), EU (Ireland), Asia Pacific (Singapore), and Asia Pacific(Tokyo). Besides REST based APIs, AWS has recently released a set of directlanguage-integrated APIs to access the cloud services.

Compute services. Amazon Elastic Compute Cloud (EC2) service allowsrenting virtual machines to run custom applications on Amazon’s data centers.Virtual machines, or instances, work as virtual private servers. Instances havedifferent CPU resources, available memory, local storage space, and I/O perfor-mance, depending on the instance size. The consumers are free to choose anysize and deployment region for their virtual machines. In order to instantiate avirtual machine, a user should boot Amazon Machine Image (AMI) that containsan operating system with the required middleware and configuration settings. Itis possible to create custom AMIs or choose available preconfigured images. EC2is very flexible and supports many operating systems and middlewares, and anydevelopment platform or programming framework.

EC2 does not have built-in scaling. The users can manually change the num-ber of instances through administration console or provided APIs. Another pos-sibility is to use Auto Scaling service. Auto Scaling can scale applications up ordown dynamically without an extra management effort.

Storage services. AWS offers various durable and scalable storages for dif-ferent purposes.

Simple Storage Service (S3) provides primary data storage for any type andamount of data. Data is stored in special buckets that can be located in a specifiedregion to reduce latencies or cost. Moreover, AWS has a content delivery servicefor even better data distribution. The provided authentication mechanism allowsthe protection of sensitive information. Also, S3 has built-in redundancy support,including Reduced Redundancy Storage (RRS) service at a lower price.

Amazon SimpleDB is another service used for storing and querying over non-relational semi-structured data. This storage service has a built-in replication,indexing and performance tuning features. HTTPS endpoints ensure a secure,encrypted communication with this service.

Developers can take advantage of Amazon Relational Database Service (RDS)to set up and operate a relational database in the Cloud. RDS provides capa-bilities similar to ordinary databases. In addition to that, it has an automaticreplication and backup support. However, developers can still install standardOracle Database or Microsoft SQL Server on EC2 instances.


Other services. There are many other helpful AWS services for networking,monitoring and controlling, messaging, etc. They can significantly enhance anapplication development and hosting.

Simple Queue Service (SQS) and Simple Notification Service (SNS) are exam-ples of messaging services. They offer reliable communication capabilities amongapplication components and end-users, enabling message-driven and event-drivenworkflows for large distributed systems. Elastic Load Balancer (ELB) is anotheruseful service. It can balance a load for EC2 instances even when the applicationdynamically scales up or down. ELB can be configured in many ways includingsticky load balancing, which means the user is stick to a particular EC2 instance.

CloudWatch is a very powerful monitoring service provided by Amazon. Be-sides a possibility to track applications, developers and system administratorscan configure systems behavior using CloudWatch. For example, applicationscan be scaled in a scheduled manner or according to certain metrics like CPUutilization. Moreover, CloudWatch can monitor application health and boot newinstances in case a failure is detected.

Pricing model and Service Level Agreements. The pricing model forAWS is quite complex. EC2 compute is billed per active instance hours. Theprice depends on the type and configuration. The users can optionally reserveinstances. In this case they get a reduced hourly rate but have to pay in advance.Data storage is charged per GB per month. Data transfer is charged per GB inand GB out. Usually the price is lower within the same region and free withinthe same Availability Zone. Also, there are additional costs per transaction forsome services. Prices vary across different regions.

AWS service level agreements guarantee 99.95% availability of EC2 service,99.999999999% durability and 99.99% availability of S3 storage, and 99.99%durability and 99.99% availability of RRS. Availability time is calculated for oneyear period. More detailed information about the pricing model and SLAs isavailable on the official web site.

4.2 Google AppEngine

Google AppEngine is a PaaS offering for developing and hosting web applicationson Google-managed infrastructure. One of the biggest advantages of AppEngineis Google’s technologies and services available for custom applications. Develop-ers can use standard language-integrated APIs to access most of these services. Aset of SDKs and an Eclipse plugin enable full local development support. SDKscan simulate AppEngine environment on a local machine.

Compute services. AppEngine provides a secure environment where ap-plications can be deployed. It currently supports Java, Python and Go run-time environments. Each environment provides standard protocols and commontechnologies for a web application development. However, regular AppEngineinstances have many limitations. For example, access to other computers on theInternet is allowed only through the provided URL fetch and email services;there is a write protection for a local file system; code can be executed only inresponse to a web request or a task; request has a 30 second limit. Along with


Fig. 4. Microsoft Azure Platform products and components Taken fromhttp://msdn.microsoft.com/library/windowsazure

a regular instance, developers can use Backends. The Backend is an AppEngineinstance running in the background. It is more flexible than a regular instance(e.g. it has a higher computational capacity limit and no request deadlines). Ap-pEngine takes care of load balancing and scaling. Applications are scaled basedon the load while data is scaled based on the size.

Storage services. AppEngine offers several options to manipulate data. TheDatastore is used for non-relational data with high read and query performance,auto scaling and transaction support. Unlike relational databases, it supports”schemaless” entities with properties. Datastore offers two types of storage withdifferent availability and consistency.

The Blobstore is another storage service. Developers should use the Blobstorefor large data objects. These objects stored in Blobstore are called blobs. Blobsare usually created by uploading a file through an HTTP request.

Other services. There are other useful services available for developers inAppEngine. Scheduled Tasks and Task Queues are used to perform tasks outsideof the web request. These tasks can be performed according to a configured sched-ule on a daily or hourly basis; or directly when they are added. The Memcache isa cache service that allows building high performance scalable web applications.Memcache represents a distributed in-memory data cache in front of or in placeof persistent storage. Additionally, AppEngine has a nice built-in monitoringsupport. Developers can check collected information for up to 30 days in AdminConsole.


Pricing model and Service Level Agreements. Google AppEngine isfree for the users up to a certain level of consumed resources. But in general,resources like CPU, storage and bandwidth are billed based on the consumedamount similar to AWS. However, compute services charge per CPU circles andnot “per deployment hour”. Since developers do not have a full control over theapplication scale, Google AppEngine has a preconfigured cost limit of the appli-cation. SLA is currently only in a draft version that offers 99.95% availability ofcustom applications. If Google fails to fulfill SLA, customers receive credits forfuture AppEngine usage.

4.3 Microsoft Azure

Microsoft Azure is a relatively new PaaS offering in the cloud market. It has datacenters in six areas: North and Central America, North and West Europe, Eastand Southeast Asia. Azure platform consists of Compute, Networking, Storageand Identity services. Fig. 4 shows a detailed view of the cloud services withineach category. Microsoft Azure provides SDKs and tools for VS2010 to enhancelocal development. SDKs can emulate a cloud environment on a local machinewhere developers can run, test and debug applications before moving to thepublic cloud. Azure extensively uses present Microsoft tools and technologieslike ASP.NET, .NET MVC, ADO.NET, Visual Studio IDE, and Microsoft SQL.So developers can levarage existing experience to migrate or develop cloud ap-plications for Microsoft Azure.

Compute services. Azure Compute provides a special execution environ-ment for hosted services. Services can be built from different roles. Each rolerepresents a component with unique functionality running inside a virtual server.Azure supports three types of role: Web Role, Worker Role and Virtual MachineRole.

The Web Role is intended to run frontend web applications. It has precon-figured Internet Information Services (IIS) 7. IIS7 simplifies the hosting of ap-plications based on web technologies like ASP.NET or WCF. It is also possibleto run unmanaged code of virtually all languages including Java or PHP.

The Worker Role serves for more general purposes. It is designed to run avariety of code mostly to perform long running tasks or background processingfor a Web Role. For example, a Web Role can be used for uploading images whilea Worker Role does image processing.

The Virtual Machine Role is designed to run user-customized OS images,giving more control over the runtime environment. However, Azure supportsonly Windows Server 2008 R2 operating system. In contrast to Web and Workerroles that are running inside a virtual machine, VM roles are actually virtualmachines. VM Role is useful when moving entire on-premise Windows Serverapplications to Windows Azure.

Any hosted service is usually represented by a combination of different roles.Roles can communicate with each other directly or by using Storage Services.It is possible to use different capacities for different role instances, since everyrole runs in its own virtual machine. Table 1 shows five compute instance sizes


Instance Size CPU Memory Storage I/O Per-formance

Extra Small 1 GHz 768 MB 20 GB LowSmall 1.6 GHz 1.75 GB 225 GB ModerateMediuml 2x1.6 GHz 3.5 GB 490 GB HighLarge 4x1.6 GHz 7 GB 1000 GB HighExtra Large 8x1.6 GHz 14 GB 2040 GB High

Table 1. Microsoft Azure Compute instances

provided by Microsoft Azure. Each compute instance represents a virtual serverwith a guaranteed amount of available resources.

Vertical scaling means changing the size of a compute instance. Horizontalscaling means changing the number of instances. Whereas vertical scaling islimited, horizontal scaling represents the true power of cloud computing. Azureallows dealing with any load pattern in a cost efficient way using dynamic scaling.However, dynamic scaling for roles is not automatic. Service provider has tochange the number of role instances manually in the management portal orprogrammatically by using provided APIs.

Microsoft Azure has a built-in load balancer. It distributes the load acrossWeb Roles to achieve better performance. Furthermore, the platform is con-stantly monitoring roles to provide a high level of availability. If any instancefails, a new one is reinitialized automatically. Moreover, applications have nodown time during upgrades. Microsoft suggests having at least two instances ofeach role to achieve offered availability.

Storage services. Azure Storage provides scalable, persistent, durable stor-age in the Cloud. It is exposed as a REST-based service. Data stored in AzureStorage can be accessed from Azure Compute or from anywhere on the Internetthrough HTTP. The users can configure access policies using built-in authenti-cation. There are four storage abstractions supported by Azure Storage: BlobStorage, Table Storage, Queue Storage, and Windows Azure Drive.

The Blob storage is unstructured storage that resembles a regular file system.It provides an interface for storing any named file along with its metadata. Itsupports a hierarchical structure, similar to a file system. File size as well as thenumber of files are not limited.

The Azure Drive represents a durable NTFS-formatted virtual hard drive(VHD) that uses Blobs as underlying storages, where data is located persistently.This storage can significantly simplify the migration of existing applications,because it allows simple NTFS API calls from the code. However, Azure Drivecan be mounted by only one role at a time. Furthermore, it cannot be accessedfrom outside of Azure environment, meaning that users cannot access its datadirectly over HTTP.

The Table Storage is used for structured or semi-structured data. It providesefficient mechanisms for storing and querying over this data. However, TableStorage should not be mixed up with a relational database. In a simple way, a


table is a set of entities with properties. Entities are similar to table rows, whileproperties are similar to table columns. Entities can have different propertieswithin one table because it has no defined schema.

The Queue Storage is a special storage that is used to organize an asyn-chronous, loose coupled workflow among roles. Roles can exchange text messagesthat are stored in Queues. One Queue can be used by several roles and vice versa.Queue Storage also provides a special delivery mechanism to guarantee high re-liability. If any role fails to process a message, the message is recreated in theQueue.

Azure Storage scalability model allows manipulating huge data amounts withfast concurrent access. Frequently used data is cached in memory to meet densetraffic needs. Moreover, data is partitioned across many physical nodes to dis-tribute the load. Tables are partitioned based on the PartitionKey property, andBlobs are partitioned according to their hierarchical structure.

The SQL Azure represents a robust relational database provided as a cloudservice. It has rich management, monitoring and reporting capabilities. SQLAzure Databases are automatically partitioned across many nodes to distributethe load. Furthermore, SQL Azure supports bi-directional synchronization anddata sharing among multiple cloud and on-premise databases. From the devel-opment perspective, SQL Azure is almost identical to a regular Microsoft SQLServer.

All data in Azure storages is replicated three times to achieve high availabilityand fault tolerance. Data replicas are distributed across different fault domains.If one of the replicas breaks, it is automatically recreated from a healthy one.Windows Azure also takes care of data consistency across replicas.

Other services. Most of the additional services provided by Microsoft Azureenhance network-related performance of cloud applications or simplify the mi-gration of existing on-premise solutions to the platform.

The AppFabric Cache represents a distributed in-memory cache for WindowsAzure applications. The Cache size can be dynamically configured on demand.Furthermore, the same cache model can be used for both on-premises and cloudapplications. AppFabric Cache can dramatically reduce application latencies. Itcan be used as a session state provider or a regular storage cache layer.

The Content Delivery Network (CDN) service allows distributing Blob orlocal content across many more locations, providing minimum latencies andmaximum data scale. CDN can significantly improve application throughput.However, only public content can be used in CDN. Also, it is highly discom-mended for volatile or dynamic data.

The Access Control service enables an easy authentication mechanism. Itsupports standard identity providers including Active Directory, Window LiveID, Facebook, etc.

Pricing model and Service Level Agreements. The pricing model of Mi-crosoft Azure is similar to other cloud offerings. The users pay only for consumedresources without any upfront investments. Though, different subscriptions arepossible. Compute services are charged according to the VM instance size on


hourly basis. Compute hours is the amount of clock hours the application is de-ployed (regardless CPU utilization). Both staging and production deploymentsare counted. Storage services are charged per GB/month and a number of trans-actions. Storage capacity is calculated as average space used by Blob, Table,Queue, and Driver storages during the billing period. That means 30 GB usedonly for one day is billed as 1GB/month. More information with the detaileddescription of standard rates is available in Appendix A.

Microsoft offers a set of SLAs for services including Windows Azure Com-pute, Windows Azure Storage, Windows Azure CDN, etc. Most service levelagreements guaranty minimum service availability and, in some cases, perfor-mance. Availability of compute services is 99.95%, of storage services 99.9%. Ifthese rules are violated, customers receive service credits in compensation.

4.4 Summary of the comparison

Cloud platforms are unique in many ways. They not only represent differentlayers of the cloud stack, but also have specific services and provided features.Consequently, their suitability for performing the migration of existing applica-tions into the Cloud differs in various ways.

AWS is similar to a virtual private hosting where users can control almostthe entire software stack. It gives great flexibility for developers, but makes itdifficult to offer automatic scalability, load balancing and failover [1]. Neverthe-less, AWS has a variety of integrated services for that. A web service interfacemakes Amazon’s offering really platform and language independent. With itslevel of flexibility and interoperability, AWS is suitable for the majority of ex-isting applications.

Google AppEngine offers a high level domain-specific platform, targetingtraditional web applications. AppEngine looks much like a cloud applicationframework. It allows automatic load balancing, elasticity and integration withother Google services, but puts applications into a very restricted environment.AppEngine is a good choice for building new applications, but the migration ofexisting systems is likely to require significant re-implementations.

Microsoft Azure intermediates between AppEngine and AWS. It resembles alower lever application framework, providing a language-independent managedruntime with certain possibilities to control the environment. Weak points ofAzure are the lack of monitoring capabilities and no built-in scaling support.Thus, the users have to purchase external tool/services or develop their own.In general, Azure fits well for the systems based on Microsoft technologies andtools. A consistent development experience is an additional advantage in thiscase.

Despite numerous differences, cloud platforms have certain affinity. All theobserved cloud providers have well-developed core services for computing andstorage. They offer highly scalable and available persistent data storages wheredata is automatically replicated and partitioned. Additionally, the platformshave special messaging services that help to organize asynchronous lose-coupledworkflow. Service level agreements are quite weak. In most cases they offer only


availability of the service. None of the providers compensates business losses ifthe agreement is breached.

Cloud-enabled systems are likely to have similar cost and performance acrossthe platforms [17][18] though there are some important differences. For example,Microsoft Azure tends to be slightly more expensive but it shows considerablybetter I/O performance. Also, the scaling speed differs across platforms. Theaverage time to provision an additional instance is about ten minutes in Azure,and only about one minute in AWS. However, it is highly dependent on theconfiguration (e.g. Windows OS boots much slower than Linux OS).

5 CASE STUDY: MIGRATING EXISTING SYSTEMTO THE CLOUD

In this section we describe the migration of an enterprise system to the Cloud.We follow the migration process provided in [27], presenting the most relevantinformation here. First, we describe the current system implementation with ashort background about the company. Then, we describe the new cloud archi-tecture for the migrated application along with identified compatibility issues.We also suggest several system improvements to further leverage the cloud en-vironment. And finally, we outline concerns about the new architecture.

5.1 Current DC implementation

InformaIT company InformaIT is a small ISV that focuses on document man-agement systems. Most of the systems are based on Microsoft technologies, sodevelopers have rich experience in .NET framework, Visual Studio developmentenvironment, SQL Server database system, and Windows Server OS. Being aninnovative company, InformaIT is very interested in modern technology and ITtrends. Cloud computing is also in the area of interest.

The Document Comparison system (DC) was selected as a candidate for themigration. DC is a small web-based enterprise solution that enhances documentmanagement processes. The main purpose is to provide a fast and easy wayto compare textual and graphical content of different digital documents. Thefollowing section gives a detailed description of the system and its architecture.

DC architecture The system is implemented using Microsoft .NET 2.0 frame-work and various programming languages including server-side C# and C++,and client-side JavaScript. DC contains five main components: i) frontend webapplication, ii) backend engine, iii) distributed cache, iv) database, and v) sharedfile store (see Fig. 5).

The frontend is a simple ASP.NET web application running under IIS onWindows OS. It provides web interfaces for end-users, so they can upload digitaldocuments, change configuration settings, analyze the result, and generate re-ports. The frontend extensively uses ASP.NET session state to track processed


Fig. 5. DC components

information and a current user status. The client-side JavaScript reduces theload on the server and improves usability.

The backend is implemented as a Windows service (also .NET based). Itperforms long running computational tasks e.g. the rasterization of digital doc-uments. A special commercial library is used to fasten this process. The libraryaccesses the files via regular file system API. It also requires the registration ofa COM component.

The file store serves as a shared storage for system components. It keepspersistent data and organizes asynchronous communication between the frontendand the backend. The frontend stores uploaded documents and creates XML taskfiles there. An XML task file describes a job unit for the backend. The backendis checking for new XML task files, and then stores rendered images in thecorresponding location. The file system also contains some custom configurationfiles that are shared among all users of the installation.

The cache layer keeps frequently used data, which increases the performanceof the system. For example, the frontend stores user session state there.

The database contains user personal information. This information is neededfor authorization and authentication. The frontend uses the database mostlyduring login and logout procedures. Unlike many document management sys-tems, DC is not database-centric. The amount of data is quite small and thisdata is used infrequently.

Deployment model DC is deployed on servers located in the data centers ofcustomer organizations. This means customers have to take care of the infras-tructure, and have technical personnel to maintain it. The amount of requiredhardware depends on the amount and the complexity of processing data. A singleserver is usually enough for small companies, while big organizations need sev-eral machines to run the system. DC also requires preinstalled Windows Server2003/2008 with Microsoft SQL Server.


Fig. 6. On-premise distributed deployment model of DC

Fig. 7. Cloud deployment model of DC


An on-premise distributed deployment model of DC is shown in Fig. 6.ASP.NET applications are composed into a Web Server Farm. They store fre-quently used data in a distributed cache that is usually located on a separateserver. Backend engines are deployed separately as well. They require more pow-erful servers for heavy computations. A customer can choose the number of fron-tend and backend servers to achieve the required performance. A shared networkfolder plays the role of persistent file storage. Microsoft SQL Server is used as adatabase. Since it does not require much space and heavy querying, the databasecan be installed on a shared server. Usually end-users are also located in the sameenvironment where the system is running

This on-premise deployment model gives several advantages. First, it keepsdata and code physically close. It results in very low latencies and no bandwidthlimitations. Second, sensitive data never goes outside the organization, whichprovides a high level of security. In some cases when users need to access thesystem outside the organization, a VPN connection is established to keep thetransferred data protected.

Organizations are charged per installation depending on the number of users.There are different types of licenses available, including a personal license and aconcurrent license.

Motivation for the migration There are several disadvantages of runningDC on-premise in a customer environment. We briefly discuss here some of thesedisadvantages, as well as the benefits of migrating the application to the Cloud.

The biggest opportunity is the potential for more sales. DC is currently ori-ented to big and medium organizations that have enough resources, own infras-tructure, and technical personnel to install and run the system. Furthermore, thelicense cost is quite high. Potential customers such as small companies cannotafford DC, facing too big financial commitments. Some of them would like to usethe system inconstantly and pay only for the amount of compared data. SaaSversion of DC can bring the product to such customers.

One more cloud computing advantage is easer installation and upgrade pro-cedures. The system is now distributed across many customers. InformaIT has toconvince each customer to replace an on-premises package and then assist dur-ing the actual upgrading. Some customers still run older versions of the system,which brings an additional support overhead. The simple maintenance model ofcloud computing will help to distribute resources more efficiently, leading to costsavings and business agility.

Also current dedicated and VP5 servers cannot be scaled dynamically, re-maining underutilized most of the time. Moreover, the deployment location isstatic, so remote customers experience very high latencies when trying the ap-plication. Being a small company, InformaIT cannot achieve the same globalscale and global reach as in the Cloud by expanding own infrastructure. Cloudcomputing enables these possibilities in a cost efficient way with no upfrontcommitments.

5 Virtual Private Server


So we have developed cloud DC prototype in order to examine systems be-havior in the Cloud. Meanwhile, InformaIT wanted to keep an on-premise DCversion and investigate the possibility to deploy into both environments withminimum changes.

5.2 Suggested cloud DC architecture

There are many ways to migrate the system to the cloud environment. Develop-ers usually face a range of alternatives when implementing cloud-based systems.In this section we describe the chosen approach for our case and discuss differ-ent alternatives that can affect cost, architectural qualities, and the amount ofrequired changes.

Choosing a cloud provider The first step when moving an on-premise ap-plication to the Cloud is to choose a proper cloud provider. A properly chosencloud provider can significantly decrease the effort and the cost of the migration.We have already examined three major cloud providers in section 4. Based onour finding we can conclude that Google AppEngine is the worst candidate forDC because it does not support .NET applications, while Amazon AWS andMicrosoft Azure both fit for the migration quite well. After further analysis weprefer Windows Azure to Amazon AWS for several reasons: i) it requires lessconfiguration effort, ii) it has a faster deployment model, and iii) it allows con-sistent development experience for applications that are well-versed in Microsofttechnologies.

Cloud DC architecture Once we have chosen a public cloud provider, weneed to show how existing architectural components are mapped to abstractionsprovided by the platform. In our case this platform is Microsoft Azure.

The frontend. Azure Web Role is an obvious choice for our ASP.NETfrontend. Web Role has a preconfigured IIS and a built-in load balancer for webapplications. Still, there are some limitations to keep in mind. For example, theAzure load balancer is not sticky, meaning that two requests from the same usercan be processed by different Web Role instances. Also, Web Role supports onlyIIS 7.0 and requires .NET 3.5/4.0.

The backend engine. The backend maps to a Worker Role, since it suitsperfectly for long running background tasks. It is worth noting that roles do nothave administrative privileges in the environment. It restricts the execution oftasks that change OS configuration e.g. registration of a COM component orchanging OS registry.

The distributed cache. Microsoft Azure has only one service for dis-tributed cache so far, AppFabric Cache. Alternatively, cached data can be storedin either SQL Azure or regular Azure Storage. As we have explained in section4, AppFabric Cache is considered to have better performance compared to thealternatives. However, it is quite expensive and limited in size (4GB maximum).


We choose AppFabric Cache under the assumption that the size of data storedin cache will be significantly reduced. Otherwise we suggest using Table Storage.

The database. On-premise DC version uses a Microsoft SQL Server database.We find SQL Azure as a perfect cloud alternative. In most cases switching toSQL Azure is as simple as changing the connection string. In [13] it is arguedthat SQL Azure can become a bottleneck for systems that concurrently operatelarge amounts of data. However, it is not the case for DC.

The file store. We have found out that the local file storage is not persistentand cannot be shared with other roles. All data stored locally gets lost if therole dies. The only persistent option for Azure applications is Azure Storage.We suggest using Queue Storage messages instead of XML task files and BlobStorage for the rest of the files shared among roles. This approach leverages thecloud platform as much as possible. First, all data are automatically replicatedand scaled. Second, Azure Storage can be accessed directly via REST calls,reducing the load on the frontend. Last but not least, Queue Storage provides abuilt-in reliable communication mechanism.

There is another alternative for the file store: Azure Drive that representsa VHD located in Blob Storage. This persistent drive can actually be sharedwith other roles using a Server Message Block protocol (SMB)6. The advantageof using Azure Drive is that it supports a regular file system API, eliminatingany code modifications. However, the drive becomes unavailable if the role thatmounted this drive dies. Also, it can store maximum 1TB of data, limitingscalability of the system. Moreover, stored data cannot be reached from outsidevia REST API.

We prefer the first option because it has easier deployment procedure, canscale without complexity, and provides higher availability.

Fig. 7 presents a proposed deployment model of the system in the Cloud. DCoffloads the complexity to Azure services, taking advantage of built-in efficientdata partitioning and replication, global scale and global reach, applicationshealth monitoring and load balancing.

Identified compatibility issues Even though Microsoft Azure fits well forthe migration of DC, we have identified some compatibility issues that requirechanges in the current implementation. These issues are described in Table 2.

In what follows, we recommend some design modifications in order to tunesystem performance, increase portability, and make the migration as smooth aspossible.

Separate data layer from business logic layer. As stated earlier, InformaITwants the system to be easily portable across both environments. However,this is not easy to achieve because of the need to switch from regular filesystem API to Azure Storage API. We suggest separating a data access layerfrom a business logic layer in order to increase portability. In other words,instead of using APIs directly, a business logic layer calls a data access layer

6 http://technet.microsoft.com/en-us/library/cc734393


Compatibility issue Required modification

Current solution uses .NET2.0 and VS2005 that arenot supported by MicrosoftAzure. The platform usesthe latest product versions.

The system should be mi-grated to .NET 3.5/4.0 andVS2010. This modification isquite simple due to full back-wards compatibility of .NET4.0 and 2.0.

The system cannot registerCOM components directlyfrom code due to environ-ment limitations.

There are some workaroundsthat allow using COMcomponents for Azure ap-plications: Registration-FreeCOM [26] and role startupscripts. We suggest usingstartup scripts because it isthe easiest solution.

A local folder cannot beshared across Azure roles.Furthermore, suggestedBlob Storage and QueueStorage have APIs that arenot compatible with regularfile APIs currently used byDC.

Change the code for access-ing data in the file stor-age to use Blob Storage andQueue Storage APIs. Sincecommercial libraries cannotbe changed, required filesshould anyway be stored lo-cally every time before pro-cessing. Azure Drive is an al-ternative solution that elim-inates these changes.

Standard ASP.NET sessionstate modes do not suitAzure environment. Eventhough In-Process mode (lo-cal in-memory session statestorage) is an option for oneWeb Role instance, it is use-less for several roles becauseof a non-sticky load bal-ancer.

The system needs dis-tributed session storage inorder to scale. We suggestusing AppFabric Cache (oroptionally Table Storage).Microsoft Azure offers aneasy way of using thesestorages as custom sessionstorage providers.

Table 2. Identified compatibility issues


interface. This loose coupling allows using regular file system or Azure Stor-age depending on the deployment environment (see Fig. 8).

Become as stateless as possible. Large amount of cached data will not onlydegrade the performance but also increase the cost. An additional 1GB ofAppFabric cache costs around 100$, which is 1000 times more than AzureStorage cost. The bigger the session size, the more time required to serialize/de-serialize it. DC currently stores megabytes of data per a session, which is abig overhead. We suggest reducing the amount of cached data, making DC asstateless as possible. This suggestion can be applied for any web applicationthat extensively uses session data. Abuse of session is a bad design for cloudapplications.

Extensively use logging. Logging is very important for cloud applications,since debugging is impossible in the cloud environment. Logging helps de-velopers to trace the behavior of the system and determine the reason ofsystem failures. Furthermore it might be useful for identifying the level ofresource utilization or just collecting statistical information.

Fig. 8. DC design to increase portability

InformaIT concerns InformaIT still has some concerns regarding new cloudarchitecture.

First, there is a performance concern. Unlike an on-premise deployment, acloud environment entails higher latencies, because all components communicateover the network. This might be particularly harmful when frequently storingand retrieving session data. Another potential bottleneck is CPU performance.Heavy algorithms used in DC system consume a lot of CPU resources. We need toexamine the application’s behavior in the cloud in order to make a final decisionupon the feasibility of cloud adoption.

A second concern is the cost of the application, because it is not really trans-parent in the Cloud. The price model is based on different metrics that aredifficult to measure for all system components in common. InformaIT would liketo have at least approximate cost estimation for DC running on Microsoft Azureplatform.


It would also be interesting to see how a deployment location can affectlatencies and bandwidth, because InformaIT is interested to leverage this cloudplatform advantage.

In the next section we investigate the above concerns by doing performanceexperiments and cost estimations.

Fig. 9. Page rendering time comparison for cloud and on-premise environments

6 EXPERIMENTS

In this section we present experiments concerning cost and performance of run-ning the DC application on the Cloud (under different conditions), and we com-pare those results the on-premise implementation of DC. We are not concernedhere with other issues as security and privacy.

In what follows we describe the environment these experiments are per-formed. Experiments and measurements are done for North Europe deploymentlocation of Microsoft Azure. This is the geographically closest location to theclient testing environment located in Sweden (Gothenburg). All Azure computeinstances have a small size, which provides 1.75 GB memory, 225 GB localdisk space, moderate I/O performance, and CPU performance equivalent to one1.6GHz core. We use small instances as a part of Azure free trial subscription,which gives necessary resources to perform our experiments for no fees. Test-ing on the client side is executed in a non-virtualized environment, external tothe Cloud, with a direct connection to the Internet via a high-speed wired Eth-ernet. However, the cloud deployment location and the client environment arechanged for some experiments. All experiments are performed at least 100 timesto confirm that the results are stable.

6.1 Performance

As we identified earlier, a cloud environment entails increased latencies and un-known hardware underneath. Therefore, DC can have the following performance


bottlenecks in the Cloud: the execution of heavy computational tasks (like dig-ital document rendering) that require efficient hardware; and session handlingthat is latency sensitive. These operations represent the highest risk when mov-ing DC to the cloud environment, because they might lead to significant systemperformance degradation.

Fig. 10. Page rendering time in the Cloud

Page rendering time We use “seconds per page” metric for measuring pagerendering speed. This is a natural metric that represents the time required tocreate an image from a digital document page. To suggest a page standard, wehave analyzed a production set of documents and classified two main types:1. Textual documents with little graphic. They usually contain many (up to 40)

A4 format pages that are rendered fast. We refer to this type as A4 page.2. Graphical documents with little text. They usually contain one or two A3-

A2 format pages that are rendered considerably slower. We refer to this typeas A3 page.

We pick up one A3 page and one A4 page for our experiments. The size of theA3 page is 25Kb, with a 495Kb corresponding rendered image. The size of A4page is 2Mb, with a 1.4Mb corresponding image.

The rendering library gets regular file system paths as input parameters.Since the original on-premise system keeps all documents in a regular file system,it calls this library directly. However, as we described in section 6.2, cloud DCuses Azure Storage. This requires some pre-processing and post-processing stepsto render a page:1. Download a required document from Blob Storage to local file storage.2. Call the rendering library.3. Upload rendered images to Blob Storage.4. Cleanup local storage.


So the total rendering time in the Cloud can be decomposed into these foursteps. Fig. 10 illustrates the observed time for A3 and A4 pages in the cloudenvironment.

As shown in Fig. 10, pre-processing and post-processing steps for A3 pagetake about 0.5 seconds, which is only 3% of the total time (16.7 seconds). ForA4 page these steps take 0.28 seconds, which is 13% of the total time (2.15seconds). Cleaning local storage takes less than 1ms in both cases, so we canignore this value. It is worth noting that downloading time is much shorterfor A4 page, while uploading time is almost the same in both cases. This isbecause the difference in size between documents is much bigger than betweenoutput images. Anyway, library execution takes overwhelming majority of thetime (more than 87%). This means CPU performance is still the most importantfactor for page rendering in the Cloud.

As the next step, we compare page rendering time for cloud and on-premiseDC versions. For a cloud version we use a small Azure compute instance (thathas CPU performance equivalent to 1.6GHz), while on-premise installations haveCore2Duo P7350 2.0GHz M x86 (laptop), Core2Duo E7500 2.93GHz x86 (work-station), Core i3 540 3.07GHz x64 (dedicated local server). Fig. 9 illustrates theresults of our experiments. We have observed notably worse performance of oneDC instance in the Cloud rather than on the dedicated server with powerfulIntel Core i3 CPU (16.1 seconds compared to 4.9 seconds to render A3 page).This means the system needs about three times more instances of the backendengine in the Cloud to achieve the same throughput.

Session storing/retrieving time In this section we compare on-premise andcloud DC session handling performance and also test two alternatives in Azureplatform. For on-premise installation we evaluate standard ASP.NET in-processand state server modes. In-process mode stores session state data in memory,while state server mode uses a special process (separate from the ASP.NETworker process) for it. For cloud installation we evaluate AppFabric Cache, and acustom session handler that uses Azure Table. Session handling is very importantfor the frontend ASP.NET application, because it retrieves and stores sessiondata on every page load as a part of the ASP.NET application lifecycle 7.

After putting an object into session, we measure the time it takes to loadand save the session when handling an http request. We perform this experimentagainst different storages and different object sizes: 1Kb, 1Mb, and 10Mb (as-suming that session should not exceed 10Mb). Every object contains randomlygenerated binary data. It is worth noting that serialization time depends on thenumber of objects stored in session. In our case there is only one object. Wealso use the local Web server for state server mode, while a remote Web serverwould considerably increase session handling time. Experiment observations arepresented in Table 3.

As we can see in Table 3, on-premise DC requires significantly less time forsession handling compared to the cloud installation. In-process mode is obvi-

7 http://msdn.microsoft.com/enus/library/bb470252.aspx


On-premise DC installation Cloud DC installation

Sessionsize

In-process Stateserver

AppFabricCache

TableStorage

1 Kb 0.0/0.0 0.0/0.0 0.004/0.0080.094/0.113

1 Mb 0.0/0.0 0.008/0.009 0.098/0.1430.292/0.548

10 Mb 0.0/0.0 0.161/0.173 0.435/0.5831.167/1.861

Table 3. Storing/retrieving time for session data

ously the fastest. Since all data is kept in memory, the application needs tostore and retrieve only a pointer to the memory location. However, when data isstored in another location like AppFabric Cache, it should also be serialized andde-serialized accordingly. We have observed that AppFabric Cache shows con-siderably better performance than Table Storage, especially for small amountsof data. It is approximately 3 times faster for 1Mb and 10Mb cases, and 17times faster for 1Kb case (4/8ms compared to 94/113ms). Consequently, DCcan have close to on-premise performance in the Cloud when operating smallerdata amounts (kilobytes) stored in AppFabric Cache. Table Storage increasesresponse time by 1.167+1.861, that is approximatively 3 seconds, when storing10Mb of data in session. On the other hand, it is much cheaper and has nocapacity limits. Table Storage also shows a lower correlation between the timeand session size. Apparently, this is caused by HTTP latencies to transfer thedata.

Fig. 11. Page response time decomposition

Response time In this section we test response time of the frontend webapplication against different deployment locations and different scale. We try toreflect the actual time from the end-user perspective, because perceived responsetime dictates user-friendliness of the service. For our case response time includesthe latency to send a request from a client, the time to redirect the request by a


load balancer (if there are several role instances), the time to process it by theapplication, and the latency to get a response back from the server (see Fig. 11).Even though these factors depend on network locality and traffic congestion, themain purpose is to show the difference in response time depending on differentconditions. In our experiments these variable conditions are deployment location,number of role instances (scale), and load. In order to measure response timepurely for a Web Role, we use a stateless .aspx page that does not include anyexternal factors like session handling or document page rendering.

The first experiment evaluates page response time for a different numberof role instances. The page makes some calculations and then generates dy-namic output content. This dynamic data is needed to ensure that the page isnot cached by any CDN service or in the client environment. We perform theexperiment with a variable number of simulated clients accessing the service con-currently. In order to measure response time, we use Visual Studio 2010 LoadTest 8 based on a Web Test that simply requests the page. All testing is donefrom outside the Cloud. We run the Load Test for a period of five minutes andperform it many times to confirm that the results are stable.

Fig. 12 shows the observed response time for both single instance and dualinstance setups with an increasing number of concurrent users. Page time startsat about 80 ms for both cases and then glows linearly with different angularcoefficients. Results show that an additional role instance decreases responsetime, especially for a heavy load. For 250 concurrent users a dual instance setupperforms 400ms faster than a single instance setup.

The main goal of the second experiment is to show the difference in responsetime across different deployment locations. To do so, we execute Visual Studio2010 Web Test that uploads a document to DC that is running in the cloudenvironment. This scenario reflects latency and bandwidth in a better way. Wehave picked up three random files of different sizes from the production doc-ument set: 0.28Mb, 1.25Mb, and 5.13Mb. The experiment is executed for twodeployment locations: North America and North Europe, with testing performedin Sweden (Gothenburg). We repeat the experiment multiple times to confirmthat the results are stable. The observed response time is presented on Fig. 13.

All three cases show approximately twice faster uploading time for NorthEurope zone compared to North America zone. The biggest file (5.13 MB) isuploaded to the first zone for 10 seconds, while the second zone requires almost24 seconds. Consequently, a proper deployment location can significantly improveuser experience by reducing interaction latencies.

6.2 Cost

In this section we estimate the cost of DC in the Cloud. For this purpose wemodel three real life scenarios that describe how cloud DC can be used. The costfor every scenario is estimated based on the Microsoft Azure pricing model.

8 http://msdn.microsoft.com/en-us/library/ee923688.aspx


Fig. 12. Cloud DC page response time

Fig. 13. Response time for file uploading

Fig. 14. Cost distribution for Scenario 1


Service Used capacity Cost permonth ($)

Compute In-stance

3 small instances(2160 hours)

259

Relationaldatabase

1 GB 9.99

Storage 100 GB 15

Storage trans-actions

1000k transac-tions

1

Data transfer 200 GB 30

Total: 314.99 (214.99)Table 4. DC estimated cost for Scenario 1

Scenario 1: demo installation In Scenario 1 cloud-enabled DC is used asa demo installation. We have estimated the load and required capacities basedon the statistics from current VP servers with demo installations. According toour estimations, we need three small compute instances: one for a Web Roleand two for Worker Roles. The system needs a storage capacity of 100 GB andtwice more (200 GB) for the outgoing traffic. We perform all calculations for a30 days period which is equivalent to one month. So we totally need 30*24*3 =2160 compute hours that costs 2160*0.12 = 259 US dollars. Data storage costs100*0.15=15$; outgoing traffic is 200*0.15 = 30$; 1 million transactions costonly 1$; and 1 GB SQL Azure is 9.99$. The overall cost is presented in Table 4.Fig. 14 shows the cost distribution among different services. The total cost inbrackets represents an upfront payment case (using a subscription). For moreinformation see the official Microsoft Azure page.




Compute In-stance

11 small instances(7920 hours)

950

Relationaldatabase

1 GB 9.99

Storage 500 GB 75


5000k transac-tions

5


AppFabricCache

512 MB 75


Scenario 2: production installation without scaling In Scenario 2 DC isused as a production installation with throughput equivalent to one dedicatedserver (without elastic scale). For this scenario we require DC to show the samethroughout as the on-premise installation that is running on a server with Core i3540 3.07GHz x64 processor, 500 GB available local storage and 4GB of memory.It uses three out of four cores for the Backend and the rest one for the Frontend.As we observed earlier, the backend engine shows three times worse performancein the Cloud. That means we need nine small compute instances for the Backend.The frontend application requires two small compute instances, since we donot expect big performance degradation for the ASP.NET application. We alsoinclude 512Mb AppFabric Cache. The cost calculation is the same as for theprevious case. Table 5 presents the total cost for this scenario, and Fig. 15illustrates the cost distribution.




Compute In-stance

3-11 small in-stances (3920hours)

470

Relationaldatabase

1 GB 9.99

Storage 500 GB 75


5000k transac-tions

5


AppFabricCache

0-512 MB 55


Scenario 3: production installation with scaling In Scenario 3 DC is usedas a production installation with throughput equivalent to one dedicated server(using elastic scale). In this scenario we use the same capacities as in Scenario 2,but leveraging cloud elastic scalability. We assume DC has a typical enterprisesystem load pattern: high load during working hours (10 hours from 8AM to6 PM) and almost no load during the rest time. That means we can scale oursystem down when the load is very low. We scale it down to three small instanceslike in Scenario 1 to keep the system available. Also, the cache service is notneeded when we have one Web Role. Assuming that there are 22 working daysduring a month we will need 30*24*3 + 22*10*8 = 3920 hours. The first termmeans that we need 3 instances all the time, and the second term means that weadd 8 more instances during high load periods. The cache will cost 75*(22/30)= 55. However, using elasticity does not affect storage and outgoing traffic. Theestimated cost is presented in Table 6. Fig. 16 shows the cost distribution amongdifferent services.

Based on our estimations we can conclude that compute services dominatein all scenarios. It makes up 82%, 75%, and 61% of the total cost for Scenario1, 2, and 3 accordingly. On the other hand, storage transactions have the leastcost. SQL Azure also has a small cost share: 1% for Scenario 2 and 3 and 3% forScenario 1. However, this is because DC is not database centric. We found thatthe cost of DC can drop by 40 percent (764.99$ compared to 1264.99$) whenleveraging elastic scalability. Even though choosing a proper scaling strategy ispretty straightforward for enterprise applications like ours, it might not be sotrivial for other systems.

7 RELATED WORK

Some work have been presented on the benefits, challenges, and consequences ofadopting the Cloud. Armbrust et al [1] described their vision of cloud computing,


emphasizing elasticity as an important economic benefit. Motahari-Nezhad etal [21] added that cloud computing significantly reduced upfront commitmentsand potentially reduced operational and maintenance costs are also importantbenefits of cloud computing from business prospective. Chappel [4] elaboratedon different opportunities that cloud computing brings to ISV, including thepotential for more sales and easier customer upgrades. Kim et al [15] madeand extensive research on cloud computing issues, emphasizing security andavailability as the most challenging ones. Security and privacy seems to be oneof the mostly discussed obstacles for cloud computing adoption [5][29].

Various papers evaluated existing cloud implementations. Rimal et al [24]made a comparative technical study of cloud providers and suggested taxonomyfor identifying similarities and differences among them. Later, Louridas [19] dis-cussed the migration of applications to the Cloud, examining key features ofcloud offerings based on the taxonomy from [24]. Li et al [17][18] suggested a setof metrics related to application performance and cost in a cloud environment,comparing cloud providers based on these metrics. The authors concluded thatnone of the cloud providers is clearly superior, even though they observed diverseperformance and cost across different platforms.

However, we have not observed many publications on the consequences ofthe migration that would include for example cost, performance, or securitycomparison. Tran et al [27] provided a simple cost estimation model for cloudapplications, based on the identified influential cost factors. Babar et al [2] sharedexperiences and observations regarding the migration of an existing system to acloud environment, which also included some guidelines and suggestions. Still,none of the papers compared system behavior before and after the migration (orchoosing different migration strategies), like we do in this paper.

8 Conclusion

In this paper we have taken an in-depth look at the current state of cloudcomputing. This technology is not mature yet, which brings difficulties in givingdefinitions and making classifications. Nevertheless, pay-as-you-go utility model,scalability and virtualization can be emphasized as the main cloud computingcharacteristics. Cloud computing is evolving and taking its shape rapidly, whichis also reflected on cloud platforms dynamic.

Apart from cloud computing in general, we have made an extensive researchon the opportunities and the challenges of cloud adoption. We have found thatcloud computing enables a cost-efficient way of hosting highly available and geo-graphically distributed applications that can de dynamically scaled based on thedemand. On the other hand, cloud computing brings some challenges, includ-ing security, privacy, availability, and performance. Many of these challenges arecurrently being solved, and they will increasingly be mitigated along with cloudcomputing maturing.

Furthermore, we have evaluated three leading IaaS and PaaS providers: Ama-zon AWS, Microsoft Azure, and Google AppEngine. Our findings support the


argument that existing cloud implementations are idiosyncratic. We concludethat Amazon AWS is the most flexible platform that suites the widest range ofapplications, while Google AppEngine has the most limitations that are likelyto complicate the migration. Microsoft Azure is an intermediate platform, par-ticularly suitable for systems that are well-versed in Microsoft technologies.

Finally, we have implemented a cloud version of the on-premise enterprise ap-plication DC for Microsoft Azure platform. High DC compatibility with Azureand easy deployment were the main reasons for choosing this platform. The ap-plication cloud prototype was used to evaluate the performance and the cost ofthe system in a cloud environment. We have investigated the behavior of DCagainst different deployment locations, testing materials, scale and load. Ourfinding helped InformaIT to make a final decision regarding cloud adoption.Together with partners from InformaIT we have concluded that DC cloud im-plementation is feasible. We also found the estimated cost reasonable, especiallywhen the system is dynamically scaled based on the load.

Extrapolation of the results To our best knowledge there is no a uniquemetric that defines how well an application fits a cloud environment. The deci-sion should be made separately for every system, based on the tradeoff betweenadvantages and challenges. Existing systems are likely to face more challengesthan new applications, due to the technological constraints of cloud platforms.In general, existing systems that are based on service oriented architecture witha focus on statelessness and low coupling fit the Cloud pretty well. Still, appli-cations might require certain changes before being able to fully leverage a cloudenvironment. These changes are usually caused by environment limitations orthe singularity of cloud storages.

Based on our observations, the cloud version of a system is likely to showworse performance because of higher latencies and inferior computing hardwareunderneath. In order to tune system performance, we suggest eliminating unnec-essary transfers between different system components, meaning both the amountof data and the number of calls. In particular, web applications should reduce theamount of data stored in session or become completely stateless; data intensiveapplications should also consider using local cache to store frequently used data.HPC applications will usually require more CPU cores (compute instances) inthe Cloud to show the same throughput. Thus, such applications are likely tobe costly.

Last but not least, we suggest leveraging dynamic scalability in order to re-duce the cost of a cloud application. This is especially important for systemswith a changeable load. For example, enterprise application should scale up onlyduring working hours; university web sites should scale up during applicationperiods. However, monitoring is necessary when the load does not have a par-ticular pattern. Furthermore, it might be ambiguous what metrics are the mostrelevant to monitor.


Future work We have discussed many questions regarding the migration ofapplications to the Cloud. Still, there are some concerns of running applicationsin the cloud environment that we have not investigated. For example, we didnot evaluate security, privacy, and availability of cloud-enabled services. Also,we did not test the scalability of cloud persistent storages.

Furthermore, it would be interesting to examine application behavior in othercloud platforms, like Amazon AWS, also fitting our case. Moreover, the resultsobserved across different cloud environments could be analyzed and comparedgiving more comprehensive knowledge about the consequences of the migration.

We would also like to continue examining the DC system in the cloud en-vironment in order to compare the estimated and the real costs. In addition tothat, load and performance will be monitored so that we can suggest a betterscaling strategy for DC.

Acknowledgements The research presented here is based on an industrialmaster thesis made at the University of Gothenburg while the first author wasworking at the software company InformaIT [23].

References

1. M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. Katz, A. Konwinski, G. Lee,D. Patterson, A. Rabkin, I. Stoica, and M. Zaharia. A view of cloud computing.Commun. ACM, 53:50–58, apr 2010.

2. M. A. Babar and M. A. Chauhan. A tale of migration to cloud computing for shar-ing experiences and observations. In Proceedings of the 2nd International Workshopon Software Engineering for Cloud Computing, SECLOUD ’11, pages 50–56, NewYork, NY, USA, 2011. ACM.

3. P. Botteri, D. Cowan, B. Deeter, A. Fisher, D. Garg, B. Goodman, J. Levine,G. Messiana, A. Sarin, and S. Tavel. Bessemer’s top 10 laws of cloud computingand saas, 2010.

4. D. Chappell. Windows azure and isvs: A guide for decision makers, Jul 2009.5. R. Chow, P. Golle, M. Jakobsson, E. Shi, J. Staddon, R. Masuoka, and J. Molina.

Controlling data in the cloud: outsourcing computation without outsourcing con-trol. In Proceedings of the 2009 ACM workshop on Cloud computing security,CCSW ’09, pages 85–90, New York, NY, USA, 2009. ACM.

6. M. Driver. Cloud application infrastructure technologies need seven years to ma-ture. Research report, Gartner Inc., Stamford, USA, 2008.

7. D. Durkee. Why cloud computing will never be free. Queue, 8:20–29, 2010.8. J. Geelan. Twenty one experts define cloud computing, 2010.9. B. Glick. It leaders are ready for the cloud – but are their suppliers?, 2011.

10. B. Golden. The case against cloud computing, Jan 2009.11. G. Haff. Just don’t call them private clouds, 2009.12. A. R. Hichkey. Smb cloud spending to approach $100 billion by 2014, 2010.13. Z. Hill, J. Li, M. Mao, A. Ruiz-Alvarez, and M. Humphrey. Early observations on

the performance of windows azure. In Proceedings of the 19th ACM InternationalSymposium on High Performance Distributed Computing, HPDC ’10, pages 367–376, New York, NY, USA, 2010. ACM.


14. J. Hughes. Encrypted storage and key management for the cloud, 2009.15. W. Kim, S. D. Kim, E. Lee, and S. Lee. Adoption issues for cloud computing. In

Proceedings of the 11th International Conference on Information Integration andWeb-based Applications & Services, iiWAS ’09, pages 3–6, New York, NY, USA,2009. ACM.

16. N. Leavitt. Is cloud computing really ready for prime time? Computer, 42(1):15–20,2009.

17. A. Li, X. Yang, S. Kandula, and M. Zhang. Cloudcmp: comparing public cloudproviders. In Proceedings of the 10th annual conference on Internet measurement,IMC’10, pages 1–14, New York, NY, USA, 2010. ACM.

18. A. Li, X. Yang, S. Kandula, and M. Zhang. Comparing public-cloud providers.Internet Computing, 15:50–53, 2011.

19. P. Louridas. Up in the air: Moving your applications to the cloud. Software, IEEE,27:6–10, 2010.

20. A. C. Murray. There is no such thing as a private cloud, 2009.21. H. M. Nezhad, B. Stephenson, and S. Singhal. Outsourcing business to cloud

computing services: Opportunities and challenges. Technical report HPL-2009-23,HP Laboratories, 2009.

22. D. F. Parkhill. The Challenge of the Computer Utility. Addison-Wesley, US, 1966.23. P. Rabetski. Migration of an on-premise application to the cloud. Master’s the-

sis, Software Engineering and Management, Department of Computer Science andEngineering, University of Gothenburg, Gothenburg, Sweden, 2011.

24. B. Rimal, E. Choi, and I. Lumb. A taxonomy and survey of cloud computingsystems. In Fifth International Joint Conference on INC, IMS, and IDC, pages44–51. IEEE, 2009.

25. R. Sean. Cloud optimization – expanding capabilities, while aligning computingand business needs: A framework for making business decisions about cloud com-puting, Jun 2010.

26. D. Templin. Simplify app deployment with clickonce and registration-free com,2005.

27. V. Tran, K. Keung, A. Liu, and A. Fekete. Application migration to cloud: ataxonomy of critical factors. In Proceedings of the 2nd International Workshopon Software Engineering for Cloud Computing, SECLOUD ’11, pages 22–28, NewYork, NY, USA, 2011. ACM.

28. L. M. Vaquero, L. Rodero-Merino, J. Caceres, and M. Lindner. A break in theclouds: towards a cloud definition. SIGCOMM Comput. Commun. Rev., 39:50–55,Dec. 2009.

29. M. Vouk. Cloud computing : Issues, research and implementations. In Proceedingsof the 30th International Conference on Information Technology Interfaces, pages31–40. IEEE, 2008.

30. L. Youseff, M. Butrico, and D. da Silva. Toward a unified ontology of cloud com-puting. In Grid Computing Environments Workshop (GCE’08), pages 1–10. IEEE,Nov 2008.

Documents

Migration of an on-premise application to the Cloud ...gersch/ESOCC13-extended_version.pdf · an on-premise application to the Cloud and what are the consequences of the migration