Content on this page requires a newer version of Adobe Flash Player.

Get Adobe Flash player


This article was orginally published by Gerard Briscoe of Department of Media and Communications at the London School of Economics and Political Science and Alexandros Marinos of Department of Computing, Faculty of Engineering & Physical Sciences, University of Surrey. For more information on their work please go to

I. INTRODUCTION The recent development of Cloud Computing provides a [5].

The social paradigms and technologies of Digital Ecosystems, including the community ownership of digital infrastructure, can remedy these concerns. So, Cloud Computing combined with the principles of Digital Ecosystems provides a compelling socio-technical conceptualisation for sustainable distributed computing, utilising the spare resources of networked personal computers to provide the facilities of a virtual data centre to form collectively a Community Cloud.


Cloud Computing is the use of Internet-based technologies for the provision of services [1], originating from the cloud as a metaphor for the Internet, based on how it is depicted in computer network diagrams to abstract the complex infrastructure it conceals [6]. It can be seen as a commercial evolution of the academia-oriented Grid Computing [7], succeeding where Utility Computing struggled [8], [9]. It is being promoted as the cutting edge of scalable web application development [2], in which dynamically scalable and often virtualised resources are provided as a service over the Internet [10], [1], [11], [12], with users having no knowledge of, expertise in, or control over the technology infrastructure of the Cloud supporting them [13]. It currently has significant momentum in two extremes of the web development industry [2], [1]: the consumer web technology incumbents who have resource surpluses in their vast data centres1 , and various consumers and start-ups that do not have access to such computational resources. Cloud Computing conceptually incorporates software-as-a-service (SaaS) [15], Web 2.0 [16] and other technologies with reliance on the Internet, providing common business applications online through web browsers to satisfy the computing needs of users, while the software and data are stored on the servers.


Figure 1. Cloud Computing: Typical configuration when consumers visit an application served by the central Cloud, which is housed in one or more data centres. Green symbolises resource consumption, and yellow resource provision. The role of coordinator for resource provision is designated by red, and is centrally controlled.

Figure 1 shows the typical configuration of Cloud Computing at run-time when consumers visit an application served by the central Cloud, which is housed in one or more data centres. Green symbolises resource consumption, and yellow resource provision. The role of coordinator for resource provision is designated by red, and is centrally controlled. From the figure, it can be seen that coordination and resource provision are centrally controlled, even if the central node is implemented as a distributed grid, which is the usual incarnation of a data centre. Providers, who are also the controllers, are usually companies with other web activities that require large computing resources, and in their efforts to scale their primary businesses they have gained considerable expertise and hardware. For them, Cloud Computing is a way to resell these as a new product while expanding into a new market. Consumers include everyday users, Small and Medium sized Enterprises (SMEs), and ambitious start- ups whose innovation potentially threatens the incumbent


A. Layers of Abstraction

There is a significant buzz [17] around Cloud Comput- ing, but there is little clarity about which offerings actually qualify and their interrelation. The key to resolving this confusion is by realising that the various offerings fall into different levels of abstraction, as shown in Figure 2, aimed at different market segments.

1) Infrastructure as a Service (IaaS) [18]: At the most basic level of the Cloud Computing offerings, there are providers such as Amazon [19] and Mosso [20], who provide machine instances to developers. These instances essentially behave like dedicated servers that are controlled by the developers, who therefore have full responsibility for their operation. So, once a machine reaches its perfor- mance limits, the developers have to manually instantiate another machine and scale their application out to it. This service is intended for developers who can write arbitrary software on top of the infrastructure with only small compromises in their development methodology.

2) Platform as a Service (PaaS) [21]: One level of ab- straction above, services like Google App Engine [22] pro-define the stakeholders and their differing interests. How- ever, actors take on multiple roles, with vendors devel- oping services for the end users, or developers utilising the services of others for their own. Yet, within a Cloud the role of provider, and therefore controller, can only be occupied by a single entity, the vendor.

3) Software as a Service (SaaS) [15]:  At the consumer- facing level are the most popular examples of Cloud Computing, with well-defined applications offering users online resources and storage. This differentiates SaaS from traditional websites or web applications which do not interface with user information (e.g. documents) or do so in a limited manner. Popular examples include Microsoft’s (Windows  Live)  Hotmail, office suites  such  as  Google Docs and Zoho, and online business software such as

To better understand Cloud Computing we can categorise the roles of the various actors. The vendor as resource provider has already been discussed. The appli- cation developers utilise the resources provided, building services for the end users. This separation of roles helps Computing-based solutions is an advantage, when compared to businesses running their own infrastructure, but often overlooked is the co-occurrence of downtime in vendor-driven monocultures. The use of globally decen- tralised data centres for vendor Clouds minimises failure, aiding its adoption. However, when these failures do occur it has a cascade effect, taking down organisations depending on the Cloud. This was illustrated by the Amazon (S3) Cloud outage [28], which took with it several other dependent businesses. So, failures are now system- wide, instead of being partial or localised. Therefore, the efficiencies gained from centralising infrastructure for Cloud Computing will increasingly be at the expense of the Internet’s resilience.

Figure 2. Abstractions of Cloud Computing: There is a significant buzz [17] around Cloud Computing, but there is little clarity about which offerings actually qualify and their interrelation. The key to resolving this confusion is by realising that the various offerings fall into different levels of abstraction, aimed at different market segments.


B. Concerns

The Cloud Computing model is not without concerns, as others have noted [26], [2], and we consider the following as primary:

1) Economics of Failure: The uptime of Cloud Computing-based solutions is an advantage, when compared to businesses running their own infrastructure, but often overlooked is the co-occurrence of downtime in vendor-driven monocultures. The use of globally decen- tralised data centres for vendor Clouds minimises failure, aiding  its  adoption.  However,  when  these  failures  do occur it has a cascade effect, taking down organisations depending on the Cloud. This was illustrated by the Amazon (S3) Cloud outage [28], which took with it several other dependent businesses. So, failures are now system- wide,  instead  of  being  partial  or  localised.  Therefore, the efficiencies gained from centralising infrastructure for Cloud Computing will increasingly be at the expense of the Internet’s resilience.

2) Convenience vs Control: The growing popularity of Cloud Computing comes from its convenience, but also brings vendor control, an issue of ever-increasing concern. For example, Google Apps for in-house e-mail typically provides higher uptime [29], but its failure [30] highlighted the issue of lock-in that comes from depending on vendor Clouds. The even greater concern is the loss of information privacy, with vendors having full access to the resources stored on their Clouds. In particularly sensitive cases of SMEs and start-ups, the provider-consumer relationship that Cloud Computing fosters between the owners of resources and their users could potentially be detrimental, as there is a conflict of interest for the providers. They profit by providing resources to up and coming players, but also wish to maintain dominant positions in their consumer-facing industries.

3) Environmental Impact: The other major concern is the ever-increasing carbon footprint from the exponential growth [3] of the data centres required for Cloud Com- puting. With the industry expected to exceed the airline industry by 2020 [5], this raises sustainability concerns [4]. The industry is being motivated to address the problem by legislation [5], [31], the operational limit of power grids (not being able to power any more servers) [32], and the potential financial benefits [33], [5]. Their primary solution is the use of virtualisation4 to maximise resource utilisation [35], but the problem remains [36], [37]

While these issues are endemic to current Cloud Computing, they are not flaws in the Cloud conceptualisation, but of the vendor provision and implementation of Clouds [22], [19]. There are attempts to address some of these concerns, such as avoiding vendor lock-in through a portability layer between different vendor Clouds, called a meta-Cloud or a Cloud-of-Clouds [38]. While this would avoid vendor lock-in to an extent, it will not alleviate the other concerns raised. Also, there is an open source implementation of the Amazon (EC2) Cloud [19], called Eucalyptus [39], which allows for a data centre to execute code compatible with Amazon’s Cloud, providing private internal Clouds. This would avoid vendor lock-in and provide information privacy, but only for those with their own data centres, and so is not really Cloud Computing (which by definition is to avoid needing one’s own data centre [1]). So, vendor Clouds remain synonymous with Cloud Computing [10], [1], [11], [12], while our response is an alternative model for the Cloud conceptualisation infused with the principles of Digital Ecosystems.


Digital Ecosystems are distributed adaptive open socio- technical systems, with properties of self-organisation, scalability and sustainability, inspired by natural ecosys- tems [40], and are emerging as a novel approach to the catalysis of sustainable regional development driven by SMEs [41]. Digital Ecosystems aim to help local economic actors become active players in globalisation [42], valoris- ing their local culture and vocations, and enabling them to interact and create value networks [43] at the global level. Increasingly this approach, dubbed glocalisation, is being considered a successful strategy of globalisation that preserves regional growth and identity [44], [45], [46], and has been embraced by the mayors and decision-makers of thousands of municipalities [47]. The community focused on the deployment of Digital Ecosystems, REgions for Digital Ecosystems Network (REDEN) [41], is supported by projects such as the Digital Ecosystems Network of regions for (4) DissEmination and Knowledge Deployment (DEN4DEK) [48], a thematic network that aims to share experiences and disseminate all the necessary knowledge that will allow regions to plan an effective deployment of Digital Ecosystems at all levels (economic, social, techni- cal and political) to produce real impacts in the economic activities of European regions through the improvement of SME business environments.

In a traditional market-based economy, made up of sellers and buyers, the parties exchange property [49], while in a new network-based economy, made up of servers and clients, the parties share access to services and experiences [49]. Digital Ecosystems aim to support network-based economies reliant on next-generation ICT that will extend the Service-Oriented Architecture (SOA) concept [50] with the automatic combining of available and applicable services in a scalable architecture, to meet business user requests for applications that facilitate busi- ness processes. Scalable resource provision has yet to be considered in Digital Ecosystems research. Without it Digital Ecosystems risk being subsumed into vendor Clouds at the infrastructure level, while striving for de- centralisation at the service level, which would clearly be incompatible with its principles. So, the realisation of the Digital Ecosystems vision requires a form of Cloud Computing – but within the principle of community-based infrastructure, where individual users share ownership [51].


Community Cloud Computing arises from concerns over the control of vendors in Cloud Computing and the observation that analogous concerns drive Digital Ecosys- tems research. It aspires to combine the principles of Digital Ecosystems with the use cases of Cloud Comput- ing. Replacing vendor Clouds by shaping the underutilised resources of user machines to form a Community Cloud, with nodes potentially taking on all roles, consumer, producer, and most importantly coordinato, as shown in Figure 3.


Figure 3. Community Cloud: Created from shaping the underutilised resources of user machines, with nodes potentially taking on all roles, consumer, producer, and most importantly coordinator. Green symbol- ises resource consumption, yellow resource provision, and red resource coordination and administration.

The conceptualisation of the Community Cloud draws from Cloud Computing [1], Digital Ecosystems [40] and Green Computing [52]. Its a paradigm for Cloud Com- puting in the community, without dependence on Cloud vendors, such as Google, Amazon, or Microsoft.

1) Openness: Removing the dependence on vendors makes the Community Cloud the open equivalent to ven- dor Clouds, and therefore identifies a new dimension in the open versus proprietary struggle [53] that has emerged in code, standards and data, but has not until now been expressed in the realm of hosted services.

2) Community: The Community Cloud is as much a social structure as a technology paradigm [54], because of the community ownership of the infrastructure. This community ownership carries with it a degree of economic scalability, without which there would be diminished com- petition and potential stifling of innovation as risked in vendor Clouds.

3) Graceful Failures: The Community Cloud is not owned or controlled by any one organisation, and therefore not dependent on the lifespan or failure of any one organisation. It will be robust and resilient to failure, and immune to the system-wide cascade failures of vendor Clouds, because of the diversity of its supporting nodes. When occasionally failing it will do so gracefully, non- destructively, and with minimal downtime, as the unaf- fected nodes compensate for the failure.

4) Convenience and Control: The Community Cloud, unlike vendor Clouds, has no inherent conflict between convenience and control, because its community owner- ship provides for democratic distributed control.

5) Environmental Sustainability: The Community Cloud will have a significantly smaller carbon footprint than vendor Clouds, because making use of underutilised user machines will require much less energy than the dedicated data centres required for vendor Clouds. The server farms within data centres are an intensive form of computing resource provision, while the Community Cloud is more organic, growing and shrinking in a symbiotic relationship to support the demands of the community, which in turn supports it.

B. Architecture

The method of materialising the Community Cloud is the distribution of its server functionality amongst a pop- ulation of nodes provided by user machines, shaping their underutilised resources into a virtual data centre. While straightforward in principle, this poses challenges on many different levels, but many are aligned with currently active research topics in Digital Ecosystems.

1) Core Infrastructure: Before proceeding to the re- source exchange and service composition, the nodes will be deployed as isolated virtual machines, forming a fully distributed peer-to-peer network, providing support for distributed identity and coordination.

a) Virtual Machines (VMs): Executing arbitrary code in the machine of a resource-providing user will require a sandbox for the guest code, a VM6 to protect the host. The role of the VM is to make system resources safely available to the Cloud in a measurable manner. Fortunately, feasibility has been shown with heavyweight VMs such as the Java Virtual Machine and Common Language Runtime, and with the lightweight JavaScript VMs present in most modern web browsers. Furthermore, the age [57] of multi-core processors7 has resulted in unused and underutilised cores being commonplace in modern personal computers [59], which lend themselves well to the deployment and background execution of Community Cloud facing VMs.

b) P2P Networking: At this most fundamental level, nodes will have to be interconnected to form a peer-to- peer network. It will have to be specifically engineered to provide high resilience while avoiding single points of control and failure, which would make a decentralised super-peer based control mechanism [60] insufficient. A completely distributed peer-to-peer network is required, immune to super-peer failure.

c) Distributed Identity/Trust: The performing of tasks beyond the networking requires nodes to identify each other and keep historical context. This identification must be performed in a fully distributed manner, which has implications as most identity schemes are based on an identity provider controlling provision. Additionally, trust should be tracked as a multi-dimensional variable, including considerations such as uptime, performance characteristics, and reputation.

2) Resource layer: As the networking infrastructure is now in place, we can discuss the first consumer-facing uses of the virtual data centre of the Community Cloud. At its core, Cloud Computing is about using resources from the Cloud. The Community Cloud will offer the usage experience of Cloud Computing on the platform-as- a-service (PaaS) layer and above. Utility Computing [61] scenarios, such as access to raw storage and computation, will be made available at the PaaS layer. Access to these abstract resources for service deployment will then provide the software-as-a-service (SaaS) layer.

a) Distributed Computation: The field has a long history of successful incarnations in its centrally controlled form. However, Community Cloud Computing will need to take inspiration from Grid Computing [62] to provide distributed coordination of the computational capabilities that nodes offer to the Community Cloud.

b) Distributed Persistence: The Community Cloud will naturally require storage on its participating nodes, taking advantage of the ever-increasing surplus on most personal computers [64]. However, the method of infor- mation storage in the Community Cloud is an issue with multiple aspects. First, information can be file-based or structured. Second, while constant and instant availability can be crucial, there are scenarios in which recall times can be more relaxed. Such varying requirements call for a combination of approaches, including distributed storage [65], distributed databases [66] and key-value stores [23]. Information privacy in the Community Cloud will be provided by the encryption of user information when on remote nodes, only being unencrypted when cached on the user’s node, allowing for the secure and distributed storage of information.

c) Bandwidth Management: The Community Cloud will probably require more bandwidth than vendor Clouds, but can take advantage of the ever-increasing bandwidth and deployment of broadband [67]. Also, peer-to-peer protocols such as BitTorrent have made the distribution of information over networks much less bandwidth-intensive for providers, accomplished by using the downloading peers as repeaters of the information they receive. Commu- nity Cloud Computing will have to adopt such approaches to ensure efficient use of available network bandwidth, to avoid fluctuations or sudden rises in demand (e.g. the Slashdot effect9 ) burdening parts of the network.

d) Community Currency: An important theme in the Community Cloud is the notion of nodes being contribu- tors as well as consumers, which will require a community currency10 (redeemable against resources in the commu- nity) to reward users for offering valued resources. It will also allow for traditional Cloud vendors to participate, by offering their resources to the Community Cloud to gather considerable community currency, which they can then monetise against participants who cannot contribute as much as they consume (i.e. running a community currency deficit). To avoid predicting or hard-coding the relative cost of resources (storage, computation, bandwidth), their prices can fluctuate based on market demand.

3) Service Layer: Cloud Computing can be said to represent a move from service-oriented [50] to service- driven architectures, making services explicitly dependent on other providers instead of building on self-sufficient resource locations. Community Cloud Computing makes this more explicit, breaking down the stand-alone service paradigm, with any service by default being composed of resources contributed by multiple participants. The follow- ing sections describe the core infrastructural services that the Community Cloud needs to provide.

a) Distributed Service Repository: The repository of the Community Cloud must provide persistence, as with traditional service repositories [71], for the pointers to ser- vices and the semantic descriptions of services. To support the absence of principal (service-producing) nodes during service execution, there must also be persistence of the executable code of services. Naturally, the implementation of a distributed service repository is made easier by the availability of the distributed storage infrastructure of the Community Cloud.

b) Remote Service Execution: When a service is needed to fulfil a request, but is not currently instantiated on a suitable node, a copy should be retrieved from the repository and instantiated as needed. This allows for flexible responsiveness and resilience to unpredictable traffic spikes. Nodes are naturally interested in executing services as their purpose is to gather community currency for their users. A developer should note the resource cost of a service in its description, allowing for pre- execution resource budgeting by nodes, and post-execution community currency payments by consumers. It is in a developer’s own interest to mark resource costs correctly, because over-budgeting will burden their users and under- budgeting will cause premature service termination. Additionally, developers could add a subsidy to promote their services. Remote service execution must be secured against potentially compromised nodes, because while unable to access a complete traffic log of the services they execute, they could potentially access the business logic of the services they execute. Otherwise, we would be replacing the vendor looking in problem, with an anyone looking in problem.


Wikipedia suffers from an ever-increasing demand for resources and bandwidth, without a stable revenue source for support [72]. Their current funding model requires a continuous influx of monetary donations for the mainte- nance and expansion of their infrastructure [73], the alter- native being contentious advertising revenues [72], which has caused a long-standing conflict within their community [74]. While it would provide a more scalable funding model, the fear is it would compromise the public’s trust in the content [75]. Alternatively, the Community Cloud could provide a self-sustaining scalable resource provision model without risk of compromising the content, because it would be compatible with their communal nature (unlike their current data centre model), with their user base accomplishing the resource provision they require.

Were Wikipedia to adopt Community Cloud Computing, it would be distributed throughout the Community Cloud alongside other services, which in this context can be as simple as a webpage or as complex as necessary. Participants in the Community Cloud will have a node on their machine, which when active accumulates community currency by providing resources to fulfil service requests from other nodes. These service requests can be as simple as instantiating a simple HTML page or executing a server- side script, the core operations of Wikipedia. Participants can then use their amassed community currency to interact with Wikipedia, performing a search or retrieving a page. More complicated tasks, such as editing a Wikipedia page, will require an update to the distributed storage of the Community Cloud, achieved by transmitting the new datathrough its network of nodes, most likely resulting in an eventual consistency model [76].
We have discussed Wikipedia in the Community Cloud, but the latter is not limited to not-for-profit organisations, being just as beneficial to for-profit businesses. Its or- ganisational model for resource provision moves the cost of service provision to the user base, effectively creating a micro-payment scheme, which dramatically lowers the barrier of entry for innovative start-ups.


We have presented a socio-technical conceptualisation for sustainable distributed computing, the Community Cloud. The Community Cloud is an alternative to Cloud Computing, created from blending its usage scenarios with the principles of Digital Ecosystems. Community Cloud Computing utilises the spare resources of networked personal computers to provide the facilities of data centres, such that the community provides the computing power for the Cloud platform they wish to use. Furthermore, we hope that the Community Cloud will encourage innovation in vendor Clouds, forming a relationship analogous to the creative tension between open source and proprietary software.


We would like to thank for helpful discussions, Georgios Exarchakos, Paul Krause, and Nick Antonopoulos of the university of Surrey, and Jo Stanley of the University of Cambridge. This work was supported by the EU-funded Open Philosophies for Associative Autopoietic Digital Ecosystems (OPAALS) Network of Excellence (NoE), Contract No. FP6/IST-034824.


1 A data centre is a facility, with the necessary security devices and environmental systems (e.g. air conditioning and fire suppression), for housing a server farm, a collection of computer servers that can accomplish server needs far beyond the capability of one machine [14].

2 A distributed storage system for structured data that focuses on scalability, at the expense of the other benefits of relational databases [23], e.g. Google’s BigTable [24] and Amazon’s SimpleDB [25].

3 Uptime is a measure of the time a computer system has been running, i.e. up. It came into use to describe the opposite of downtime, times when a system was not operational [27].

4 Virtualisation is the creation of a virtual version of a resource, such as a server, which can then be stored, migrated, duplicated, and instantiated as needed, improving scalability and work load management [34].

5 A sandbox is a security mechanism for safely running programs, often used to execute untested code, or untrusted programs from unverified third-parties, suppliers and untrusted users [55].

6 A virtual machine is a software implementation of a machine (com- puter) that executes programs like a real machine [56].

7 A multi-core processor is an integrated circuit to which two or more processors have been attached for enhanced performance, reduced power consumption, and more efficient simultaneous processing of multiple tasks [58].

8 The only exception is the recent arrival of Solid-State Drive (SSD) in personal devices, popular for mobile devices because of their lack of moving parts, and whose use is growing as their size and price reach traditional HDD [63].

9 The Slashdot effect, also known as slashdotting, is the phenomenon of a popular website linking to a smaller site, causing the smaller site to slow down or even temporarily close due to the increased traffic [68].

10 In economics, a community currency is a medium (currency) for exchanging goods and services within a community, that is not backed by a central authority (e.g. national government) [69], and which need not be restricted geographically despite sometimes being called a local currency [70].


HTML Comment Box is loading comments...