Just in Time Clouds: Enabling Highly-Elastic Public Clouds over Low Scale
Amortized Resources
Rostand Costa
1,2, Francisco Brasileiro
1 1Federal University of Campina Grande Systems and Computing Department
Distributed Systems Lab
Av. Aprígio Veloso, 882 - Bloco CO – Bodocongó Campina Grande, Paraíba, Brazil
{rostand.costa, fubica}@lsd.ufcg.edu.br
Guido Lemos de Souza Filho
2, Dênio Mariz Sousa
2 2Federal University of Paraíba, UFPB Informatics Department Digital Video Applications Lab
Campus I - Cidade Universitária João Pessoa, Paraíba, Brazil
{guido, denio}@lavid.ufpb.br
Abstract
In this paper, we address the problem of capacity plan-ning for the provision of cloud data centers. Inspired by the
Toyota's Just in Time (JiT) philosophy, we propose an alter-native approach to assemble the computational infrastruc-ture of a cloud computing provider using resources whose costs have already been absorbed by the core businesses that use them. We introduce the concept of Just in Time Clouds, whose providers only allocate resources when they are demanded and only for the duration that they are needed by their clients. This obviates the necessity of antic-ipating capacity planning, and rules out the costs associated to both the over-provisioning and the under-provisioning of resources. A JiT cloud provider is able to offer cloud com-puting with more competitive prices and in a much more elastic way, since it is based on the discovery, recovery and resale of idle resources already amortized by other busi-nesses and no upfront investment in infrastructure is re-quired. We discuss particular scenarios of use for this ap-proach that give evidences of its suitability for the case of applications that can be executed over “spot” instances of a best-effort infrastruture-as-a-service provider.
1 Introduction
Cloud computing is an evolving paradigm that portrays computing as a product that can be purchased conveniently and on-demand by the clients, in a pay-per-use basis, and that can be rapidly provisioned and released by service pro-viders. Moreover, clients enjoy elasticity, as they can easily scale up and down their service consumption, in a virtually unlimited way. From the client’s perspective, the cloud computing model allows them to apply to their Information Technology (IT) investments the same principles of the Toyota Production System (TPS) [1]. Created by Toyota in the 50´s, the philosophy “Just in Time” (JiT) is based on a very simple idea: "what is needed, when it is needed, and in
the amount needed".
Cloud computing providers, in turn, do not have the same facility when assembling their infrastructure, and need to deal with the complexity and risks associated with long-term capacity planning. Indeed, a key difference of the cloud computing model, when compared to the traditional para-digm based on the local provisioning of the computing in-frastructure by the client is that the costs associated to both the over-provisioning and the under-provisioning of the infrastructure are moved from the clients’ shoulders to those of the cloud computing providers [2]. Thus, the challenge for the providers is to maintain the quality of service nego-tiated with the client, at the same time that the operational
costs are kept low enough to make their businesses profita-ble.
The intrinsic liability of the cloud providers to fulfill the commitments kept with customers that have acquired their services and the necessity to attend spikes in demand are normally addressed by means of maintaining capacity sur-plus and limiting to a reasonable value the amount of service that each client can demand at a time [3]. On the other hand, costs are reduced by relying on the advantages that the economy of scale can give to them. For instance, the con-centration of their structure in large, dedicated and centra-lized data centers, and the sharing of physical resources through virtualization are key strategies to effectively offer services in a much more economical way. Their competi-tiveness is also based on the ability of performing a statistic-al multiplexing of vstatistic-alleys and peaks in the simultaneous use of resources by a large number of clients. Another advan-tage is the level of automation achieved by the cloud pro-viders that, among other things, allow them to substantially reduce their staff vs servers ratio. Additionally, providers may increase the utilization of their services by offering a portfolio of services with different pricing models [4].
Despite the facilities and advantages offered by the cloud computing paradigm, there still are obstacles to its adoption by some customers, at least in the short term [5]. Lack of a standard service provision API, difficulties in adapting applications for the architecture adopted by the selected provider, inappropriate levels of security, privacy and control currently available, strategic and commercial risks that are not fully covered by the SLAs offered, and legal and regulatory restrictions are some of the main causes that prevent these customers from using the services offered by cloud computing providers.
Of course, part of these potential customers may still benefit from the cloud computing paradigm by adopting the same technologies and strategies used by cloud computing providers in order to reduce the Total Cost of Ownership (TCO) [6] of their own IT infrastructures. This is particular-ly suitable for customers with a large IT infrastructure that can benefit from similar economies of scale. The term
pri-vate clouds1, in opposition to the public infrastructure oper-ated by cloud computing providers, has been used to de-scribe this kind of infrastructure. Nevertheless, no matter whether they use a private cloud approach or not, these customers continue to maintain their own computing
re-1
There is a controversy that emerged in the latest edition of Interop, over the term Private Cloud. The providers of public clouds insist that cloud computing, by definition, implies in the existence of an external vendor specialized in providing IT services, usually with a differentiated pricing model. The private clouds would actually be fully virtualized data centers. This distinction is irrele-vant to this paper, and we will use the term private clouds for the sake of sim-plicity.
sources and need to do capacity planning, usually having to bear the burden of maintaining excess resources to support their demand peaks. This implies in the existence of idle resources, but whose costs of acquisition and operation have already been covered by the core businesses that use them.
From the scale standpoint, computational resource own-ers that have surplus of amortized resources can be broadly classified into two main categories: those with sufficient surplus capacity to be able to act as providers of public cloud computing, offering their idle resources to others, and those without sufficient spare resources that could allow them to profitably sell their excess capacity. In this paper we are interested in the latter category of resource owners, which we name low scale amortized resource owners. Note that this class includes the entire spectrum of scale imme-diately smaller than those that could profitably sell their surplus passing through small data centers, and going down to individual servers, desktops and even non-conventional computing resources.
The low scale amortized resources we consider will normally be scattered and owned (or at least operated) by a large number of individuals and/or organizations. Also, they have a main usage that is not related to processing work-loads of a public cloud built atop of them. Thus, the service they originally support should already compensate the costs incurred in acquiring and operating the resource. Therefore, the cost of using any spare computing capacity in these resources is substantially lower than the cost of using com-puting capacity of resources that are solely acquired and maintained to support cloud infrastructure provisioning. Organized in a production chain following the Just in Time philosophy, holders of amortized resources could act as suppliers of a particular type of cloud data centers, which we name JiT Data Centers. Such data centers can be assembled by providers only when requested by customers and exactly in the conditions required. Note that what we are proposing is not akin to other specialized cloud providers that build their services atop Infrastructure-as-a-Service providers and therefore do not need to deploy infrastructure of their own (e.g. rightscale.com [7]). The service the proposed interve-nient broker offers is exactly the same provided by tradi-tional public cloud providers, thus, it does not make sense to buy service from the latter and sell the same service without adding any value to it. By discovering, recovering and resel-ling spare resources whose costs have already been amor-tized, the intervenient broker is also able to operate under the Just in Time philosophy, decreasing its risks and, conse-quently, its cost of operation, at the same time that it avoids upfront investments in infrastructure. Moreover, this allows very large amounts of resources to be commissioned to a single client for a relatively short amount of time and later decommissioned, without imposing any extra costs to the JiT Cloud Provider.
The remainder of the paper is organized as follows. In Section 2 we discuss in more detail the economics aspects involved in the operation of cloud data centers. Next, in Section 3, we formalize the concept of low scale amortized
resources. In Section 4, we present Just in Time Clouds, an alternative approach for assembling a computational infra-structure to support cloud computing based on amortized resources. Possible scenarios for operating such systems are discussed in Section 5. Related work is surveyed in Section 6. Finally, we present our concluding remarks in Section 7.
2 Cloud Economics
2.1
Cost Challenges
There is an expectation that public cloud providers can offer services at competitive prices and still make money. However, building cloud infrastructures requires enormous initial investments and involves high operational costs. As show in [8], the required investments include the costs of: purchasing servers, including hardware and software (45% of the total cost); setting up the infrastructure, including cooling and power distribution (25%); commissioning net-work resources such as rented or owned links and equipment (15%); and electricity consumption (15%). Figure 1 illu-strates this distribution.
Figure 1: Cost distribution for data centers
Li et al. present a further detailed discussion about the costs involved with the ownership and management of cloud data centers and how they compose the associated TCO. In Li et al.'s approach [9], the four main groups of cost afore-mentioned are expanded into eight classifications and, in addition to capital cost, it also includes costs related to the operation of the data center. They are: Servers, Software,
Networking, Support and Maintenance, Power, Cooling,
Facilities and Real State costs. The final data center TCO is obtained through the sum of these eight cost components.
In addition to TCO, which addresses the cost of the data center itself, the Utilization Cost (UC) corresponds to the cost associated only with the resources being effectively used by customers, taking into account the elastic utilization supported. Considering virtualization as a standard among providers, the framework assumes that a virtual machine (VM) is the basic unit of consumption in cloud data centers and proposes the VM Density metric, which represents the amount of virtual machines supported per physical server. Thus, the cost on the total amount of potential VM (TVM =
VM Density x physical servers) is independent of the level 45% 15% 25% 15% Servers Network Infrastructure Power
of use and is included in the TCO, while the cost associated with the VM actually in use (1 to TVM) is captured by UC.
In situations of high idleness in the data center, the UC may not be representative of the real TCO. The estimated range of use for conventional servers is 5-20% [2]. This low average level of CPU utilization is supported by a study conducted with 5,000 servers for six months [10]. With the adoption of virtualization, the average utilization may reach 35% (38% for Google) [11]. In the case of cloud providers, there is little available information about utilization level, but it is estimated that Amazon had 40.000 servers in Au-gust 2009 with a target of 75% utilization [12]. On the other hand, the idle potential on virtualized servers can reach 65% in private data centers.
A special feature of Li et al.´s framework is the adoption of an Amortizable Rate Parameter, obtained by applying a depreciation period and the cost of money on the values of each investment or expenditure so that they can be reflected in shorter time intervals such as one hour of use, for exam-ple. Amortization of the TCO of cloud data centers must be made with the proceeds from the sale of resources. Then each VM in use on a server in a specified period of time must amortize the costs over the same period, of all possible VM (VM Density) on the same server. Thus, there is a bal-ance point in which the amounts of VM that are in use over-come the total costs. Above that, the provider is operating profitably. The unused VM in this case is the stock availa-bility of the cloud, since it represents the product marketed as such by the provider - their sale (or not) impacts directly on business results and in their own amortization.
Among the proposals to reduce the costs of cloud data centers that start to emerge [8][13][14], we can cite: a) har-monization and optimal placement among super and micro data centers; b) network agility to dynamically grow and shrink resources to meet demand; c) resilience in geo-diverse micro data centers level, working mirrored but without power generators or UPS; and, mainly, d) increase server utilization: servers should be engaged in revenue production.
2.2
The (Un)limited Elasticity
The theoretical unlimited elasticity that is associated with cloud computing services would potentially allow the customer to freely decide whether to use 1 resource for 1,000 hours or 1,000 resources for 1 hour, paying the same price in both cases. Of course, this level of flexibility places insurmountable challenges for the capacity planning that needs to be done by cloud computing providers. Thus, in practice, the elasticity allowed is limited by a maximum number of instances that can be simultaneously acquired by any given customer. Current providers allow only a few virtual machines to be automatically instantiated. For larger systems, off-line negotiation is required [15].
The ability to simultaneously instantiate a large number of resources for a relatively short period of time is a crucial requirement for an increasingly popular class of
applica-tions, called high throughput computing (HTC) applications [16].
Although very flexible and simple to set up, achieving extremely high-throughput computing in cloud infrastruc-tures is not possible, considering the available implementa-tions. In particular, none of the current providers are able to accept the instantiation of a system with thousands of virtual machines for the short period of time required to run a typi-cal HTC application. The Belle II Monte Carlo [15], for instance, requires 20,000 to 120,000 cores for the execution of a three-month workload.
Dealing with the demands of extremely high scalability of HTC applications or even with flash crowds [17], when a very large number of users simultaneously access an instan-taneously popular Web site, is not a trivial task. To handle these workloads, cloud providers would probably face utili-zation levels of their structures even smaller than those ex-perienced today, with strong impact on their profitability. Yet, there is a whole range of applications that are not well served by the service currently provided by cloud computing providers.
In the next section, we present a different category of idle resources: those that have their costs covered regardless of their utilization level; we then argue that these can pro-vide the basis for the provision of cloud computing services target to this underserved audience.
3 Low Scale Amortized Resources
3.1 Definition
We say that a resource is amortized if its fixed costs are fully covered, over time, by the original purpose for which it was acquired, considering both the periods of full operation and idleness. In other words, a resource is said amortized if its TCO does not vary (or varies little) due to its utilization rate.
The concept of amortized resource proposed here is ra-ther common and present in several contexts. We can cite as an example, a renowned restaurant that opens only for din-ner on certain days of the week. In spite of being scheduled to open in a few moments, the capacity of its structure should be sufficient to tolerate (and take advantage) the peak demand that these few periods represent. The entire opera-tion of the restaurant, therefore, must be sustained by the profits earned in the windows of time during which the structure is being fully utilized. In this example, concepts like exclusivity and prestige can support charging higher prices that allow the sustainability of the business, despite the fact is that the lounge, kitchen, equipments and fixtures of the restaurant, although necessary and adequate in quanti-ty to support an extreme demand are not fully exploited.
Of course, depending on the context, there may be stra-tegic or technical limitations that prevent any attempt to maximize the utilization level of amortized resources. In the restaurant example, the specialization of the equipments might restrict their potential use for other purposes. Like-wise, the adoption of initiatives that could boost sales in
other schedules, such as reduced prices and the use of sim-plified menus may be incompatible with the exclusivity model adopted.
Such limitations, however, occur on a smaller scale with computational resources whose application and use are po-tentially more generic and flexible. Recent advances in the techniques for virtualization, automation and management of computational resources also increased the potential for reusing and sharing them in a widely connected world.
Our approach considers that part of the computational resources used to support various business operations fall into the category of amortized resources, representing a capacity provisioned and available for periods of high de-mand, but remaining idle during most of their time. For such resources already amortized, any possibility of utilization in moments of idleness, even for a purpose other than that originally specified, can lead to additional profit or at least to the reduction of its TCO.
We do not consider, in this approach, the idle computa-tional resources of a public cloud or a commercial data cen-ter to be amortized resources, since in both cases the amor-tization of the costs associated with their resources depends crucially on the sales of these resources. On the other hand, the computational resources installed and not used to sup-port the operation of a large chain store or a large bank are resources genuinely amortized. The subtle difference is that selling such computer resources is not the main activity of the bank, which derives its earnings through other ways.
3.2
Model
The calculation of the potential surplus should take into consideration the historical peak demand for short and long term that allows the creation of a comfortable safety margin for operation of the original business. Let C be the total capacity of computing resources installed in the environ-ment E to support the business B. The appropriate value for
C is obtained by means of capacity planning that considers the operational and strategic needs of the business for a certain period of time.
The level of use of E is the fraction of C consumed by the operation of the business B, refered to as u. Due to the specific dynamics of each context, u can vary depending on the time and ut represents the maximum utilization (load peak anticipated) of C at time t.
The amortized surplus S over E at the moment t, denoted as ࡿ࢚, is obtained by applying to C the complement of the
percentile of actual use in t:
ܵ௧= ܥ × (1 − ݑ௧) (1)
Hence, St is a fraction of existing and amortized capacity
C of environment E at the time t and may be used for a specific duration for a purpose other than B. This relation-ship is illustrated in Figure 2.
Figure 2: Surplus of amortized resources
In this work, we are focusing in contexts where the amount of available amortized resources (St )does not reach a magnitude M that allows their owner to act as a public cloud computing provider, i.e. they are low scale amortized
resources. In the following sections, we present an approach in which a third party acts as a binding agent to allow differ-ent contexts where low scale amortized resources can offer together public clouds of magnitude at least as large as M in a federated way.
4 Just in Time Clouds
Our proposal addresses an alternative to build computa-tional infrastructure to support cloud computing which is not based on traditional capacity planning. Inspired by the Toyota's Just in Time Philosophy (JiT) [1], we introduce the concept of Just in Time Clouds for representing a new ser-vice category in which the provider allocates resources only when demanded and until there is use for them. Built upon the amortized resources from a supply chain, JiT Clouds may represent an attractive alternative for many types of clients and applications both in price and in scalability.
4.1
JiT Providers and JiT Data Centers
In our approach, the Just in Time Provider is a public cloud computing provider that instead of assembling and maintaining a structure of data centers for supporting its own service makes use of a federation of low scaleamor-tized resources already existing into private contexts. Unlike proxies of conventional providers of cloud computing (e.g. rightscale.com), a Just in Time Provider does not represent any public cloud provider, but acts as a legitimate and fully autonomous provider that takes advantage of resources that would be irretrievably wasted without its intervention.
A JiT Provider adds value by offering cloud computing without needing to take care of capacity planning, but simp-ly discovering, recovering and reselling resources already amortized and idle. The advantage is to decrease its risk and operational cost, as no large investments in infrastructure are made. Moreover, scalability is only limited by the capacity of the provider to assemble a large enough supply chain of idle resources. The user of the cloud, in turn, benefits from potentially lower costs, as the traditional providers need to
0 10 20 30 40 50 60 70 80 90 100 1 2 3 4 5 6 7 8 9 10 U ti liz a ti o n (% ) Time Capacity Surplus Utilization Level
embed the risks, costs and investments in their prices, as well as access to a potentially much more scalable service.
The resources to be operated by the JiT Provider may come from sources as diverse as a single-tenant of a virtua-lized data center with excess capacity maintained to support peak demands from its own business (as it is speculated that was the motivation for the emergence of Amazon's AWS), and users of a TV network federated by the broadcaster, that frank the use of their set-top-boxes [18].
Each resource pool amortized over a given environment represents an abstraction called Just in Time Data Center (JiT DC). Each JiT DC brings some amount of resources with certain characteristics and capabilities, called JiT
Re-sources, which must be raised and finely graded by the JiT Provider. Depending on the type, a JiT Resource can be appropriately specialized as, for example, a JiT VM to represent a specific virtual machine within a specific JiT DC. Among the general characteristics of a JiT DC, there is the level of service supported by its resources and conditions negotiated or arbitrated by the owner for its use. A Just in
Time Cloud (Figure 3) consists of the set of JiT DC incorpo-rated and coordinated by the JiT Provider for provision of public cloud services to third parties.
Figure 3: Composition of a JiT Cloud
The JiT Resources that are integrating in JiT Data
Cen-ters can be classified into dedicated, when they are fully allocated for use by the JiT Provider for a certain period of time, and non-dedicated, when their assignment is partial, being shared in an opportunistic fashion, and with the possi-bility of being reclaimed by their corresponding owners without any prior warning. In the first case, there are reser-vation and levels of availability traded. In the second case, the resources are volatile and can suffer from failures or relocation at any time. In both cases, the provider needs to deal with migration issues and take into account the neces-sary time to commission and decommission the resources.
4.2
Implementation Challenges
The concept of Just in Time Clouds proposed here can be considered as an alternative to the standard model of centralized data centers adopted in public and private clouds nowadays. When considering the use of heterogeneous amortized resources, with different settings and levels of service, some current assumptions for the construction of cloud infrastructures tend to not be fully applicable. Thus, some concerns that are not present in the deployment of traditional cloud data centers need to be considered for
as-sembling and operating JiT Data Centers to construct a JiT Cloud.
One of the main requirements is the ability to perform a proper partitioning of amortized resources between the priority operation of the core business of the owner of the resources and the utilization of the idle capacity by the JiT Provider. This coexistence in practice means maintaining two logical pools of resources built on the same physical resources. The first logical pool consists of the resources of
C represented by the maximum utilization expected for each
period of time t, namely ut . The second pool is formed by the amortized resources available, St.
This segregation can be fully supported by the technolo-gies currently available and the dynamics for the transition of resources between the two pools can be made operational through mechanisms of prioritization. Moreover, although the standardization/interoperation (or commoditization) is a constraint on cloud computing today, some initiatives are starting to emerge in the search of ways to fill this gap [19].
Other aspects also need to be analyzed. What are the architectural requirements for building JiT Clouds? How to control the resources in each JiT DC? What classes of appli-cations are best suited for JiT Clouds? How to ensure scala-bility and availascala-bility for the JiT Cloud based on heteroge-neous JiT DC? Which mechanisms for provisioning and reallocation of resources are needed? Is the overhead of control and coordination effort involved acceptable? What are the applicable business models that reconcile the attrac-tiveness of service to customers with the motivation for the suppliers together with the profitability of JiT Provider?
Some of these issues will be addressed in the next sec-tion for particular scenarios.
5 Possible Scenaries of Use
JiT Clouds can be assembled over resources with levels of granularity distributed by the entire spectrum of low scale amortized resources. One of the missions of the JiT Provider is to discover and explore the potential of available re-sources aligning them with the needs of customer applica-tions. Depending on their characteristics and granularity, resources amortized may provide different levels of service and scalability. The level of QoS offered by a JiT DC is totally dependent on the level of QoS supported by the re-sources used.
When resources are concentrated in data centers and their granularity is located closer to the top of the magnitude that limits low scale amortized resources, the QoS levels offered are consistent with the traditional providers of cloud computing. Thus, JiT Data Centers based on such resources can be used to host applications traditionally supported by cloud computing.
On the other side of the scale spectrum, when the amor-tized resources are fine-grained and distributed, they need to be grouped and coordinated by the JiT Provider for their exploitation. These resources can be conventional ones, represented by the common facilities and processing devic-es, and non-conventional ondevic-es, including PDA, mobile Amortized Pool B Amortized Pool C
Amortized Pool A
Private Data Center
Digital TV
Receivers Mobile Devices
Ju st in T im e C lo u d
Just in Time Data Center A
Just in Time Data Center B
Just in Time Data Center C
phones and Digital TV receivers. All these non-conventional devices are equipped with reasonably powerful processors and fairly large memory, allowing them to support the ex-ecution of applications. However, as these devices are typi-cally non-dedicated and volatile resources, the JiT DC based on them are likely to be less reliable than one that is built over private resources. Nevertheless, there are enough evi-dences that there are clients willing to use such best-effort service: for one side, the mere existence of the AWS spot-instance is a good indication of this; on the other side, the abundance of e-Science and industrial HTC applications, which are amenable to be executed in cloud environments with QoS equivalent to that provided by AWS spot in-stances, provide further evidence that a highly-scalable cloud computing service is very useful.
In this session, we focus on the use of non-conventional resources for supporting the operation of a JiT Cloud that is able to provide the high scalability required by HTC appli-cation. This setting is particularly interesting because these applications are short-lived, and normally require an enorm-ous amount of resources at once – this is most challenging scenario for traditional providers. On the other hand, they require a less strong quality of service from the cloud com-puting provider.
5.1
Building JiT Data Centers on Demand
In order to build a JiT Data Center capable of meeting the requirements of HTC applications (high scalable and short-lived infrastructures), it is necessary to provide a way to access a potentially enormous quantity of processors, send to all of them programs and possibly data, remotely trigger the execution of the code staged, gather the results produced, and finally release the allocated resources so that other applications can use them. The question is then, where to find dozens of millions of available processors and to configure them accordingly and instantaneously for the use in JiT Clouds? Moreover, how to perform this difficult task with minimum delay?In a previous work, we proposed OddCI [20], a novel ar-chitecture for generic Distributed Computing Infrastructures (DCI) that can be instantiated on demand to be, at the same time, flexible and highly-scalable. The characteristics of fast setup, fast initialization and fast dismantle of customized DCI supported by both dedicated and shared underlying infrastructures, allows OddCI to be an alternative to create instantaneous JiT Data Centers. For that, we consider a special category of amortized devices, namely those that may be organized as a broadcast network. A broadcast net-work has the potential to access simultaneously all the con-nected devices that can be coordinated to accomplish some action. By transmitting a piece of software through the broadcast channel to be loaded simultaneously and indis-tinctly by all processors embedded in the devices connected at a given time, it is possible to build, in a very fast2 and controlled way, a JiT DC, capable of running HTC
applica-2
In fact, how fast the software will be uploaded depends on the size of the software footprint and on the capacity of the broadcast channel.
tions in general, and bag-of-tasks (BoT) [21] applications in particular.
A noticeable characteristic of this approach is that, diffe-rently from any other alternative for distributed computing, no previous identification and registering procedures are, necessarily, required for the amortized resources. Put simp-ly, the OddCI instance does not exist until it is requested and activated through the broadcast channel.
Costa et al. have discussed in detail how an OddCI sys-tem can be instantiated over a traditional Digital TV net-work (OddCI-DTV). They have shown how the software needed can be developed on top of the existing technologies used for DTV, in particular the middleware technologies that follow the standards established for Digital TV [20].
The performance evaluation of the OddCI-DTV system considered the efficiency of the system, and the performance that it can yield to different classes of HTC applications. It was shown that as the suitability3 of the application grows, so does the efficiency of the system. Moreover, even for applications with very low suitability, an appropriate selec-tion of parameters may be enough to yield very high effi-ciency for most practical applications.
5.2
Performance of Non-Conventional Devices
One of the great unknowns about cloud computing pro-viders is what level of performance IT organizations will actually get when adopting this model. However, in the wake of debates about the merits of public versus private cloud computing models, real performance benchmarks begin to replace philosophical discussion.One of these initiatives is CloudSleuth [22], a new free service for monitoring cloud applications sponsored by Compuware. CloudSleuth uses the Gomez Performance Network (GPN) to measure the performance of an identical and simple target application running on several cloud ser-vice providers. The GPN tools and techniques are used to run test transactions on the deployed applications and moni-tor the response time and availability gathering data from more than 140,000 points of presence on the Web. The ben-chmarking results for the standard test (accessing a site with two pages) are presented in a continuously updated view of the performance on both Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS) providers. The service also offers the ability to monitor private applications.
Another study about the performance of cloud compu-ting was also sponsored by a tescompu-ting and monitoring compa-ny - Neustar/Webmetrics [23]. Conducted by the Bitcur-rent’s team [24], the benchmarking evaluated the network throughput (download of a small and a large image) in five cloud computing platforms, and also conducted tests with CPU-intensive tasks and I/O intensive tasks. The complete results of the benchmarking are consolidated in a report [25]. Table I presents a summary of these results.
3
This is measured as the ratio between the amount of data that needs to be transferred and the average processing time of the tasks that comprise a given HTC application.
Table I: Bitcurrent´s Cloud Benchmarking Results
To assess the actual processing power of unconventional devices, we performed the same tests of CPU (1,000,000 sin and sum operations) and I/O (sequential search for a record in a 500,000-record file with 128MB of size) on Digital TV receivers (set top boxes) and cell phones. We have imple-mented and tested the applications in low and high-end devices from each category. The results are consolidated in Table II (average in seconds with confidence level of 95% and maximum error of 2%).
Table II: Non-Conventional Devices Benchmarking
As can be seen, the unconventional devices performed similar or superior to conventional IaaS and PaaS platforms, specially for the CPU test. This can be explained by the powerful processors present in these devices and the fact that they are dedicated to processing the tests.
Although the tests have been conducted considering that the devices were idle, we also tested the Digital TV receiv-ers during their normal operation (when the user is watching TV). The performance loss observed was 33% for low-end Digital TV receiver (STB based on STI Microeletronics processor ST7109 with 32MB of memory flash and 256 MB of RAM) and 15% for a top Digital TV receiver (STB based on Intel processor CE 3100 with 1.06 GHz and 256 MB of RAM), but the results remained compatible with those found in cloud providers.
Despite the fact that tests of network latency of sites were not applicable in our case, we also performed the two download tests proposed by the Bitcurrent’s benchmarking in cell phones to evaluate how these devices handle data transfer. The average was 0.27s to download the small pic-ture (1x1 pixel) and 14.24s for the big one (2 Mbytes) in low-end cell phone (Nokia 5530). Again, unconventional devices perform at levels equivalent or close to those of resources provided by conventional cloud computing pro-viders.
The huge amount of existing non-conventional devices and their processing capacity indicates that it is possible to assemble powerful and highly elastic cloud structures to meet specific demands.
5.3
Market Perspective
There are several challenges involved with the use of re-sources with very low granularity owned by individuals to build clouds. The failure of companies (e.g. Distributed.net [26]) that try to sell (and not donate, as in the case of
Volun-tary Computing initiatives like SETI@Home [27] and others [28][29]) suggests that there is a marketing component that must be considered in the use of very small grains. One of the obstacles is the transactional cost involved in the identi-fication, ticketing and valuation of a very large amount of transactions related to a too large number of small suppliers. In addition to control costs faced by the service provider, there are the operational costs of carrying out the actual remuneration of suppliers who can, in most cases, supplant the payment amount itself. There is also the fact that the gains earned by the owners of individual resources can be very small or negligible and serve as disincentives for par-ticipation.
Together, these factors impose limits on the bottom of the scale of amortized resources that may be utilized. However, in specific scenarios, the grain can be as small as possible. This is the case when there is a "glue service" that absorbs or amortizes also the transactional cost. In the case of non-conventional devices like Digital TV receivers and mobile phones, they can be grouped and coordinated at an appropri-ate scale by TV station and telephone system operators, respectively. Incentive measures already existing in these contexts, as well as channels of billing and charging can be fully reused, reducing or eliminating the transactional cost of the JiT Provider. For instance, in the case of the JiT Cloud based on STB, the STB owner can be rewarded in the form of pay-per-view credits, representing a reward with higher added value than the payment of very small amounts of money. By purchasing bulk lots of pay-per-view credits, the JiT Provider increases sales of TV station operators, helping in covering the return of the structure of the network TV.
6 Related Work
The RESERVOIR Project [30] presents an architecture that allows providers of cloud infrastructure to dynamically partner with each other to create a virtually infinite pool of resources. Its model for Federated Cloud Computing is based in the separation between the functional roles of ser-vice providers and infrastructure providers, where the latter can lease resources dynamically and transparently to the former. However, unlike JiT Clouds, the infrastructure pro-viders must keep dedicated resources to meet the demands of service providers.
The InterClouds [31] approach addresses the problem of cloud provisioning using a market-driven federation of clouds for resource leasing. Based on intermediation via an Exchange Market, Cloud Brokers organize the relationship between service consumers and Cloud Coordinators in dis-tributed cloud environments. However, gaps in integration and interoperability between cloud providers limit its via-bility.
Experiences like Ad hoc cloud [32] that allow partial vir-tualization of non-dedicated hardware, and Nebulas [33], based in distributed voluntary resources, confirm the possi-bility of using general-purpose resources with very small granularity for building JiT Clouds.
Test Salesforce Google Rackspace Amazon Terremark 1-pixel GIF 0.11 0.25 0.18 0.23 0.23
2-MByte GIF 0.50 1.97 3.25 4.41 5.00
CPU Test 8.13 1.63 2.16 10.03 3.75
IO Test 6.26 2.03 3.33 19.46 12.35
Public PaaS/IaaS Services (in seconds)
Test ST 7109 CE3100 Nokia 5530 Nokia E72
CPU Test 2.55 0.19 4.28 2.95
IO Test 12.90 1.48 48.22 64.11
Nano Data Centers (NaDa) [34] aims at enabling a dis-tributed hosting edge infrastructure for data storage and content distribution. As JiT Clouds, NaDa is also based on unused resources but with more specific purposes. The two main applications envisioned for NanodataCenters are vid-eo-on-demand and multiplayer games.
7 Conclusion
We address the problem of capacity planning for the provision of cloud data centers by obviating the costs and risks associated with both the over-provision and under-provision of resources. Inspired by the Toyota’s Just in Time philosophy we propose an alternative approach to build highly-elastic computational infrastructures for sup-porting cloud computing by using existing low scale amor-tized resources.
We introduce the concept of Just in Time Clouds (JiT Clouds) as a new service category in which the provider allocates resources only when they are demanded and for the duration they are needed. The added value is to offer public cloud computing with more competitive prices since it is based on the discovery, recovery and resale of idle resources already amortized by other business. Moreover, since no infrastructure needs to be permanently acquired, much high scalability can be reached in practice.
The advantage to the provider is the decreasing of risk and cost of operation and avoiding initial investment in infrastructure, which are common costs of traditional pro-viders, hence directly benefiting the user of the cloud. The advantage to the resource suppliers themselves is the ability to obtain additional profit with the idle time of assets whose costs are already absorbed by the purpose of their core busi-ness.
Acknowledgment
The authors wish to thank the staff of Embedded (www.embedded.ufcg.edu.br), LAVID (www.lavid.ufpb.br), and Dynavideo (www.dynavideo.com.br) for their valuable help with the STB and cell phones experiments. Francisco Brasileiro is a CNPq/Brazil researcher (grant 309033/2007-1).
References
[1] Just in Time. Toyota Production System (TPS).
http://www2.toyota.co.jp/en/vision/production_system/just.html [2] M. Armbrust, A. Fox, R. Griffith et al. "Above the Clouds: A
Berkeley View of Cloud computing." Technical Report No. UCB/EECS-2009-28, University of California. February 2009. [3] Amazon Web Services. http://aws.amazon.com.
[4] Amazon EC2 Spot Instances. http://aws.amazon.com/ec2/spot-instances/
[5] B. Golden. “The Case Against Cloud Computing”. Available in
http://www.cio.com/article/477473/The_Case_Against_Cloud_Comp uting_Part_One. 2009.
[6] L. Mieritz, B. Kirwin. "Defining Gartner Total Cost of Ownership".
Gartner Group. 2005. Available in
http://www.gartner.com/DisplayDocument?id=487157&ref=g_ [7] Rightscale Cloud Management Platform. http://www.rightscale.com.
[8] A. Greenberg, J. Hamilton, D.A. Maltz. "The Cost of a Cloud: Research Problem in Data Center Networks". In ACM SIGCOMM CCR. January 2009.
[9] X. Li, Y. Li, T. Liu, J. Qiu, F. Wang. “The Method and Tool of Cost Analysis for Cloud Computing”. In IEEE International Conference on Cloud Computing (CLOUD-II 2009). September 2009.
[10] L. A. Barroso, U. Hlzle. “The case for energy-proportional computing.” IEEE Computer, 40, December 2007.
[11] K. Stanoevska-Slabeva, T. Wozniak. “Cloud Basics – An Introduction to Cloud Computing”. Grid and Cloud Computing, 2010 – Springer. [12] "Amazon’s EC2 Generating 220M+ Annually".
http://cloudscaling.com/blog/cloud-computing/amazons-ec2-generating-220m-annually.
[13] C. D. Patel, A.J. Shah. “Cost Model for Planning, Development and Operation of a Data Center”. - Hewlett-Packard Laboratories Technical Report – Citeseer. June 2005.
[14] The Green Grid. URL http://www.thegreengrid.org.
[15] M..Sevior, T. Fifield and N. Katayama. "Belle monte-carlo production on the Amazon EC2 cloud," Journal of Physics: Conference Series. Volume 219, Part 1, 2010.
[16] M. Litzkow, M. Livny, M. Mutka. “Condor - a hunter of idle workstations. In: Proc. 8th Int'l Conf. Distributed Computing Systems. 1988.
[17] J. Jung, B. Krishnamurthy, M. Rabinovich. "Flash Crowds and Denial of Service Attacks: Characterization and Implications for CDNs and Web Sites". In Proceedings of the 11th International Conference on World Wide Web. May, 2002.
[18] Batista, C.E.C.F. et al. “TVGrid: A Grid Architecture to use the idle resources on a Digital TV network”. In Proceedings of the Seventh IEEE International Symposium on Cluster Computing and the Grid (The Latin America Grid Workshop) – Rio de Janeiro, p. 823-828, 2007.
[19] Open Stack Open Source Cloud Computing Software.
http://www.openstack.org.
[20] R. Costa, F. Brasileiro, G.L. de Souza Filho, and D.M. Sousa, "OddCI: on-demand distributed computing infrastructure." In Proceedings of the 2nd Workshop on Many-Task Computing on Grids and Supercomputers. November, 2009).
[21] W. Cirne, D. Paranhos, L. Costa, E. Santos-Neto, F. Brasileiro, J. Sauvé, F. Alves, C. Osthoff, C. Silveira, Running Bag-of-Tasks Applications on Computational Grids: The MyGrid Approach, Proceedings of the ICCP'2003 - International Conference on Parallel Processing, 2003.
[22] The CloudSleuth Mission. http://www.cloudsleuth.net [23] Neustar Webmetrics. http://www.webmetrics.com/ [24] Bitcurrent. http://www.bitcurrent.com/
[25] Bitcurrent Team. “The performance of clouds”. Available in http://www.webmetrics.com/landingpage/bitcurrentcloud2/index.html [26] M. May. "Idle Computing Resources as Micro-Currencies - Bartering
CPU Time for Online Content". Citeseer. WebNet, 1999 .
[27] D. P. Anderson, et al, “SETI@Home An Experiment in Public-Resource Computing,” Communications of the ACM Archive, vol. 45(11), pp. 56—61, November 2002.
[28] Folding@home Distributed Computing, http://folding.stanford.edu [29] FightAIDS@home, http://fightaidsathome.scripps.edu.
[30] The Reservoir Project. http://www.reservoir-fp7.eu/
[31] R. Buyya, R. Ranjan, R. N. Calheiros. “InterCloud: Utility-Oriented Federation of Cloud Computing Environments for Scaling of Application Services". Springer eBook. May 2010.
[32] G Kirby, A Dearle, A Macdonald, A Fernandes. "An Approach to Ad hoc Cloud Computing". Technical report:arxiv 1002.4738. Feb, 2010. [33] A. Chandra, J. Weissman. "Nebulas: Using Distributed Voluntary
Resources to Build Clouds". Usenix.org. Proceedings of HotCloud, 2009.
