by Craig Lee, OGF President

“Grids” and “clouds” are buzzwords that have come to denote broad concepts and user bases in science and industry. While these concepts have distinct characteristics based on “where they came from”, they are nonetheless strongly related when general distributed computing requirements are considered. At just the very top-level, we can ask the following questions:

Are there sufficient market forces today to make cloud interoperability or portability a reality? In fact, when we say “cloud interoperability” or “portability”, what scope do we actually mean? This could mean interoperability at the virtual machine level, the platform level, the service level, or even the data domain level. When will vendors decide that interoperability will make the market bigger for everyone (rather than maintaining “walled gardens” for their customers)? How long will users have to consider building their own “interoperability layers” to get things to work together?

What user experience do end-users really need and want? Can programming frameworks, problem solving environments, or portals shield users from dynamic provisioning and compute/data affinity/locality performance issues?

Where are the economically viable market segments that will support the development of the necessary tooling and infrastructure? Beyond e-commerce and web site hosting, what are the viable market models for scientific and engineering HPC, civil protection/services, urgent computing, massive data mining, etc.?

How can we manage the dichotomy between concept and implementation? Technical “movements” usually start with a grand vision and concept that are labeled with a buzzword. Over time, however, buzzword labels become inextricably linked and identified with the dominant implementations that are in use. Will tools such as XMPP be viable interoperability vehicles? Will it fair better than the basic web services stack? Will it support the range of economically viable market segments? Are there other options?

By Daniel Field

Many are of the impression that cloud computing is a new phenomenon, invented the other side of the pond and which came as a surprise to the traditional Grid technologies research community.

This is simply not true. Cloud computing is the rebranded, well marketed natural evolution of the ideas that were already being discussed and predicted by the grid community before the cloud entered the radar and took the industry by storm. And before you all jump in with discussions on the technical nuances between the two, let me make clear that I’m talking about the service offered to the end user, ie, the value proposition, and the business model behind the idea.

Whilst the torrent of media attention for all things cloud has undoubtedly cast a shadow over the traditional grid areas, the market analysis of many of these projects anticipated the coming of the cloud, albeit not in its current shape or form.

Grid computing traditionally concentrated on the high performance aspect of parallel computing, and the popular examples given were reams of computers slogging away number crunching financial derivatives or modeling the structures of proteins. However, by 2006 many of the business analysts were already pointing at other aspects of the Grid, such as trust and security, distributed programs running in diverse locations and advanced service level agreement components as enablers of new forms of business models, of collaboration within and between different companies and even of advanced virtual organizations capable of coming together to share resources for a limited time to achieve a specific goal. This is confirmed quite simply by looking at the pilot implementations of the BEinGRID project, many of which leverage these aspects to enable new services or business models.

Later, in early 2007, the analysts commented that the utility computing vision that inspired the original (electricity) Grid analogy back in the day, was starting to come to fruition. The inherent flexibility and decentralized nature of Grid was enabling what was starting to be labeled as Software-as-a-Service.

The CHALLENGERS workshop, dating to that time, concluded:

Grid infrastructure still promises to attract and enable new businesses and radically change the relationships between a customer and its supply chain offering a flexible platform for a global collaboration. Grids lead to competitive advantage through better utilization of heterogeneous, resources by converting them to virtualized services. As a result, such innovative Grid-enabled applications have become offered as “Software as a Service (SaaS)”. (Although this term has been around since at least 2000, it would appear to have met significant mainstream use[1] only around January 2007, see below). The initial success of [the] SaaS model appears based on the supply of the service to new customers: small and medium sized enterprises (SMEs) that could not otherwise have been served profitably.

Reading between the lines, the potential of virtualized resources offered to remote third parties, and of software ran remotely and provided on a pay per use model, was already recognized. Indeed, looking at early FP7 projects, such as SMART LM, (proposed in May 2006) we see an attempt by the community to evolve the world of software and services towards a more flexible approach that encompasses SaaS. (SmartLM handles the licenses as services and works with flexible models like extension, aggregation of licenses and introduces others that make prices become effectively independent of the underlying hardware).

Although, in contrast cloud computing does not exclusively claim a long-tail approach, it IS defined in terms of simplifying the provision for the end user and it seems that cloud has overtaken SaaS in the marketing terminology, an observation backed up the Google Trends image below and the current tendency to describe many of Google’s services as “in the cloud”. Perhaps then, it is fair to say that, if not the conclusion of this change, Cloud computing is at least the most notable manifestation at present of this change in focus of Grid.

So whilst cloud enjoys its lofty position at the peak of the Gartner hype cycle, let’s have a look at some of the reasons why that Cloud eclipsed its bigger brother.

Firstly cloud is defined in terms of user benefits, not what it is or how it works. Indeed, analysis I conducted in February 2009 showed that the first paragraphs of the Wikipedia pages for such terms as Grid computing, distributed computing, high performance computing, parallel computing and utility computing all defined the term in question in reference to the architecture or manner in which the computation is done. Cloud computing, on the other hand, defined itself in terms of delivering “scalable and often virtualized resources … as a service over the Internet. Users need not have knowledge of, expertise in, or control over the technology infrastructure “in the cloud” that supports them”.

Secondly, cloud computing as provided by Amazon was repackaged, rebranded, and extracted from the researchers who built it to be offered as a business service. Although the restricted beta of its first year of life was open only to researchers, it was clear from the outset that this was to be a professional and commercial service.

Thirdly, the cloud revolution was spear-headed by well known and trusted companies. Amazon itself is often credited with being one of the companies that inspired confidence in e-commerce. By being the pioneers of a new wave of commercial services, they instilled a customer confidence in cloud that would have been impossible for a start-up or a spin-off to generate. Additionally, having a mega-infrastructure, like Google and Yahoo! also, they were able to keep up with demand and grow at the market’s pace, not their rate of infrastructure acquisition.

And finally, cloud is so much more catchy than grid! Grid is an alright word, but admittedly somewhat utility. Like utility computing itself, it makes a good analogy to the electricity grid, sure, and a functional word suits a field that describes itself with a technical description, rather than what it does for its customers. But come to cloud, now that’s in a whole new stratosphere! There is an endless source of weather related metaphors and puns to whet the appetites of the wordsmithing marketers. And whilst I hasten to add that something as fickle as a name change is not generally sufficient to make a technology take off, one cannot deny that the marketing buzz that has been created around cloud is nothing short of electric.

So to conclude this post, and without raining on Amazon and co’s parade any further, I ask a final question: What will be the heir to the cloud? Who knows? Perhaps we will need some more blue sky thinking!

With thanks to Csilla Zsigri of The 41 Group for discussion and comments.

[1] Defined as having a search frequency in Google was high enough to register with Google Trends

Technorati Profile

Posted by Rosa M. Badia 13 May 2009

While we already have had quite a bit of discussion about the Grid/Cloud buzz words, I would like to raise your attention on one more of these type of words: multicore. The forecast is to have thousands of  cores in a chip. How will this impact the way we do computing? How will this impact the way we program? How will this impact grid and cloud computing?

With the objective of overcoming the three walls: the memory wall, the power wall and the ILP wall, the current trends in chip fabrication have led to placing more than one processor (from now on, core) in a chip. While manufacturers are now shipping chips with a few cores (at most 4-8 cores), the forecast is to include hundreds or thousands of them in a chip within a few years.  What is more, while now only a few of these chips has an heterogeneous nature with a non traditional memory organization, like the controversial Cell chip, in the future the prediction is to have highly heterogeneous organizations in a chip, with complex memory hierarchies and different type of cores (like accelerators and GPUs).

The community is currently very excited with this new and performant chips, but also aware of the increasing complexity of software development in these platforms. While current programming methodologies can be used with up to 4-8 cores, new methods that enable the parallel execution of applications need to be devised. The pressure cannot be only on the programmers, but also on the programming models that should be able to abstract the underlying architecture, and even more enable, if possible, automatic parallelization and perform the required data transfers between different levels of the memory, all in a very dynamical fashion. Additionally, now more than ever we cannot expect programmers to tune and re-program their applications every time a new architecture appears, and therefore portability or the so called performance portability is a pre-requisite.

Having this in mind, there are several considerations to make with regard to Grid computing. The first is about programming: the principles that guided the research in programming the grid were very close, nor to say identical to the ones described above for multicore chips. The goals of programming models for the grid were: to be able to manage computing environments that are inherently parallel, distributed, heterogeneous and dynamic, both in terms of the resources involved and their performance. While it may be possible to build grid applications using established programming tools, they are not particularly well-suited to effectively manage flexible composition or deal with heterogeneous hierarchies of machines, data and networks with heterogeneous performance. Therefore, the experience of the research performed in the recent years in programming the grid can be applied to multi-core programming. Successful examples of this are environments like ProActive or GRID superscalar (GRIDSs, in the form of their siblings CellSs or SMPSs). Feedback from the groups that have done research on how to program the grid into standards such as OpenMP (with its current movement towards considering parallel tasks) and OpenCL (that considers the heterogeneity of the systems) can be key.

A second consideration is given that compute nodes will be much more powerful in the near future one can think that there would not be (or would be less) need for computational grids as we conceive them now, given that the fat local computing nodes will be enough to satisfy the needs of computing. There are even some voices that maintain that in fact there would be too much computing, and that the problem is to find applications that need it. However, my opinion is that we will continue to have a need for grids. These forthcoming grids will be grids of fatter nodes, but the community will be able to conceive applications that need this computing (we do not have to forget that, for example, some scientific communities that, like expanding gases fit all available space, are always able to consume all available cycles). An important consideration here that supports this idea is the fact that even considering a world with local computers, the data sources and communities will continue to be distributed. Therefore, the need for grids and grid software will remain.

Finally, how multi-cores will impact cloud computing? Similarly to grid computing, cloud computing will be enabled with fatter computing nodes. Also, and this applies also to grid computing, the cloud middleware will have to be adapted to consider the underlying multi-core hardware. Since most of cloud computing technology is based on virtualization, the key here is the enablement of this technology to multicore taking into account that these would be much more complex and heterogeneous. The new multicore platforms enable to host more than one instance of the operating system and the challenge now is how to perform the right dynamic resource management of the virtualized systems to meet the Service Level Agreements established with the end-users.

Thanks to Daniele Lezzi for discussion and comments.

Posted by Adrian Mouat,  01 April 2009

The term “Cloud computing” has a seen an enormous rise in popularity since its inception in 2007. This article highlights the slow retreat of the terms Utility computing and Grid computing against the sudden surge of Cloud computing.

But what exactly is the difference between Cloud computing and Grid computing? A lot of people have written about this, but few have come up with a definitive answer. Of course, this is largely due to the irritating vagueness surrounding the definition of both terms. However, through the rest of this post, I will try to highlight what I consider to be some of the main differences.

A facetious definition could be “Cloud is what the cool Web 2.0 kids use, whilst Grid is for the old academics with their pipes and tweed coats”. However, there is a grain of truth to this – there is an irrefutable overlap between Cloud and Grid computing but a stark difference between people who know what Grid computing is and people who have only heard of Cloud computing.

Both terms centre on the idea of viewing computing power as a service (Grid computing takes its name from an analogy with the electricity grid) supplied by a typically external provider. In both cases the end-user does not want or need to concern themselves with the actual hardware used by the provider. Grid computing aims slightly further than the Cloud by also pursuing the sharing of resources (computational, data or storage) between entities (often across organisational boundaries), whilst hiding the hardware and protocols used from the user.

One of the main drivers to the birth of Cloud computing was the need to scale Web applications up in response to sudden changes in demand – for example to cope with sudden news exposure. These upturns in demand can often be very short-lived, making it uneconomical for companies to purchase enough dedicated hardware to cope with peak demand. The solution provided by Cloud computing vendors such as Amazon EC2 allows on-demand spawning of new servers to almost instantaneously deal with such surges. Grid computing is also designed to deal with the problem of peak demand, but in a slightly different way – it views processing requests as individual tasks to be dealt with on a large computing cluster (or clusters) with a batch job scheduler (for more discussion on this see the RightScale blog). This view stems from the traditional (and largely academic) HPC world where users submit long-running jobs and receive the results hours or even days later.

Another important difference is in terms of implementation: Cloud computing uses virtualization* to achieve a standard on which users can run their applications, whilst Grid attempts to bring heterogeneous platforms (both in terms of OS and hardware) together to solve problems. The use of virtualization allows Cloud computing to sidestep a whole host of issues that Grid computing has to contend with, such as the availability of software libraries on different platforms.

If we accept these as the main differences between Grids and Clouds, what does this mean for the future? Some analysts have argued that Grids are dead and that “Clouds are Grids done properly” or Cloud computing is “the user-friendly version of Grid computing”, but things are not as clear-cut as any of these statements suggest. This is an argument for another post, but consider the following: Is it possible to use Clouds within Grids? What about vice-versa? What about the issues that Grid developers have been grappling for years with (e.g. security, trust, SLAs) – how are they solved in a Cloud computing context?

Thanks to Craig Thomson, Kostas Kavoussanakis and Mike Jackson for discussion and comments.

* See also: Blogs and Discussion: The Open Source and IBM:The stuff of clouds.

Posted by Stefan Wesner 12 March 2009.

After reading and hearing everywhere that “Cloud Computing/Storage/…” is to be the successor of Grid*, I was wondering if one could do “Business Experiments in the Cloud”, similar to the ones we did (and still do) for the EC project BEinGRID – Business Experiments in Grid.

As well as requiring a clear business case for each pilot implementation, the Business Experiments also have to show why a distributed, cross-organizational solution is beneficial and why several service providers are needed. The offered services range from a thin abstraction layer provider (e.g. computing cycles or data storage) up to more complex and sophisticated services (e.g. licensing provider, product database provider) which are more in line with the coarse grained concept expected from a Service Oriented Architecture (SOA) solution.

For many of the delivered services that are not tightly coupled to a specific resource (such as a radio telescope) or internal data stores that cannot exported due to legal constraints, cloud services could be used to realize these services. After all, most services do not care if they are provided using a physical infrastructure or a virtualized one. So from this viewpoint, yes, we could have: Business Experiments in Clouds!

Another key element of many of the experiments is that the collaboration with other companies in a Virtual Organisation (VO) is always a compromise between the potential benefit (e.g. cost savings, integration of additional expertise and information) and the associated risks (e.g. dependency on an externally controlled service, …). The proposed solutions for increasing the certainty of service delivery by: binding providers to Service Level Agreements (SLAs); using semantically enriched service descriptions; and implementing commercial quality security do not really fix the problem. An SLA can be violated (including intentionally); securing the transmission and controlling access does not prevent data being revealed through other channels and semantically described services may still be misleading. So the decision to collaborate is still based on an analysis of the risks versus trust in the service provider.

In some scenarios the trust is based on the obvious common interest of all participating parties in the VO, in others only penalties described in the SLAs provide the confidence that a provider will do its best not to violate the agreements. The SLA might also place constraints on how data must be treated.

This problem has nothing to do with the virtualization of resources, as it should not be seen on this level. The fact that one or more of the service providers may build on top of a cloud infrastructure does not matter. But are current SaaS models ready to support such scenarios?

A frequently mentioned problem of clouds is the lack of appropriate SLAs providing confidence in the provider. I do not think that this is a problem in general. Depending on what you want to be done externally, one needs to make an analysis of risks versus benefits, and for many cases – in particular if the providers are easily replaceable or if no real-time constraints leads to an overall failure in case of a delay – the implied SLA (Quality: Best effort, Penalty: No payment on failure) is sufficient. A typical approach used in Grid solutions is to have local resources and remote resources with standardized interfaces, thus making providers replaceable. This approach can also be applied to clouds (e.g. OpenNebula + Amazon EC2). In my view, the major aspects not addressed by cloud solutions are real collaboration scenarios beyond a consumer and provider relationship. Cloud approaches either provide a virtualized infrastructure or deliver Software (or “Everything”) as a Service (SaaS). The scenarios considered in Business Experiments in Grid always have more than two clear stakeholders in the scenario. In order to realize such scenarios the Cloud/SaaS provider might be part of such a Virtual Organisation, but this would need infrastructure for VO Set-up, potential quick replacement of providers in case of failures and so on, very similar to that found in current Grid technology. So, for this aspect, our hypothetical cloud version of BEinGRID is now more like: Business Experiments in Grids partially delivered by Clouds!

The problems found in many discussions about clouds (e.g. look at Above the clouds) apply in a similar way to collaborative business Grids as realized in many past, or ongoing, service-oriented Grid projects such as BEinGRID, BREIN, IRMOS, NextGrid or Akogrimo. I think combining both worlds using virtualization approaches for the provision of services and aiming for the delivery of complete solutions in a SaaS/XaaS model using clouds with a standardized interface could contribute to the reliability of provided services. The cloud could provide parts of the VO Management elements, such as Creation of Instances on Distributed Hosting Environments as identified on Gridipedia. However, in this case, cloud is not a replacement of Grids, but a replacement of how certain services within a Virtual Organization are provided. The Grid is dead? No! But as Virtual Organizations delivering a collaborative business scenario are far more complex compared to outsourcing scenarios, they are – as of now – mostly used in business to business scenarios and need to justify the increased effort.

So in conclusion, our Business Experiments in Clouds is fine if it is more a client-server relationship we are considering, but in truth we need a Business Experiments in Grids (maybe partially delivered using the cloud) if the target is a collaborative scenario involving many business partners in a non-hierarchical relationship. So, the question is not “Clouds or Grids?” but “How to integrate Grids and Clouds?”.

Notes

*See for example : http://cloudcomputing.sys-con.com/node/771947 and http://www.faz.net/[...]