What is "Cloud"?

I partially agree with the message here: IT systems still consists of same building blocks (servers, operating systems, databases, applications) and, technically, Cloud seem rather evolutionary than revolutionary concept. However, I think you should consider Grid Computing and standardization efforts (like The Cloud Computing Interoperability Forum, the Open Cloud Consortium) in the history section for more comprehensive picture. Also, I didn't find any traces of how virtualization techniques relate to Cloud Computing. Is this intentional?

This paper considers Cloud definition and terminology from different angles: It gives partial historical view stressing the importance of outsourcing, contemplates the relation of elasticity and cloud computing, advocates more detailed layer model and inclusion of cloud clients to the layer model. This is the first problem I see in this paper: Too many arguments for one paper, resulting in shallow discussion on each.

Indeed, one can ask why isn't grid computing considered in the history section? Further, if the aim is to provide elaborated and alternative definition of Cloud (see the title!), why aren't previous definitions considered in detail? Mell and Grance, Armbrust et al. and Vaquero et al. consider many other aspects of Cloud Computing: How are they less important than outsourcing and elasticity? The reviewer didn't find layered stack illustration from these sources: In which sources is Cloud Computing presented as three-layer stack?

On the positive side, the arguments seem intuitively valid and relevant. I'd suggest cutting off some slack (e.g. instead of history, focus on outsourcing, and less rattle on MySQL) and elaborating more on what have other said, what are they missing and why is the present view relevant. For instance, advancing the stack model from naive three-layers to refined model with solutions and components is quite natural for both academics and practitioners. Do explain, why is the advancement important and critical.

Here's the other main problem of the paper: the value of elaborated stack model is poorly explained. The authors say that different use cases demand different setups and different setups also occur in competing ecosystems. Neither use case or ecosystems are defined. This makes the reviewer believe that argument on use cases is invalid: you wouldn't use one cloud stack to input data on bugs and another one to retrieve them. Moreover, this makes the reviewer believe the authors are saying that e.g. Microsoft's and Amazon's ecosystems contain different setups, which is quite evident even without elaborated layer model.

The reviewers suggestions in brief: Focus on your main arguments, ground them well and explain the value of your enhancement for both academics and practitioners.

The paper discusses some of the aspects of cloud computing, in particular, outsourcing and elasticity, and also considers and elaborates the layered "as a Service" model.

It remains a bit unclear what is the main focus of the paper. Is it, as the title would suggest, the attempt to provide a definition of the cloud, by considering its different facets (outsourcing and elasticity)? Or is it an attempt to elaborate the layered architectural decomposition of cloud services? Usually, the focus of the paper, along with its contribution, is stated in the introduction section; however, in this paper this section is practically non-existing. I would recommend the authors to select a single (main) focus, and develop the paper further around that focus. Some more detailed comments are below.

Assuming cloud definition as a main focus:

According to the first sentence in the introduction, the paper deals with terminology. It is therefore surprising not to see a review of available cloud computing definitions (though some relevant references are provided). Both the outsourcing and elasticity are relevant and important aspects to consider, but not the only ones: there are also the aspects of resource pooling, on-demand provisioning, etc.

Considering cloud as a form of outsourcing software application platforms seems to be an interesting idea. Still, there are also other forms of outsourcing software applications: recall for instance ASP and managed services, which have little to do with cloud. Is the outsourcing different when ASP and cloud services are compared?

Regarding elasticity: according to NIST definition, it is one of the essential characteristics (whether it is used or not in real scenario is another matter). Without elasticity/scalability, the cloud imho transforms into a legacy ASP world, albeit running on top of virtualized hardware. In other words, I am not convinced that it is _not_ mandatory for the cloud to have the elasticity built-in.

Assuming the layered architectural decomposition of cloud services as a main focus:

The authors revise the traditional IaaS/PaaS/SaaS model by introducing solutions and components to the layers, and by adding a "Computing as a Service" layer. I would suggest the authors to describe explicitly, how the proposed refinement into solutions and components contributes to the state-of-the art decompositions, such as in OpenStack, OpenNebula and Eucalyptus (for IaaS) or CloudFoundry and AppEngine (for PaaS). It would be also useful to emphasize the benefits of having the client side as a layer to the model.

A small comment about PaaS: while it may provide an application development platform, its main function is imho to deploy, execute, and manage (e.g. auto-scale) cloud applications.

Layering, as an architectural pattern, helps structuring the otherwise overly complex system into a set of abstraction levels, often allowing the higher layers to "forget" about the internals of lower ones. It does not demand the availability of "interchangeable" layers. Such interchangeable layers are theoretically possible (once the interfaces between the layers are public), but usually become reality later on, with the appearance of a "dominant design". And by no means the SaaS layer is expected to "contain all possible services needed by humankind".

Editor Decision

Your manuscript has been reviewed and reviewers have suggested revising it prior to publication.

There is still a possibility to revise this in due time to get it accepted for publication in the first peer-reviewed issue of the Communications of Cloud Software journal. To achieve this you need to read carefully the comments of the reviewers and update your manuscript accordingly in two weeks (by December 13th). Especially the used terminology and exclusion of related definitions need to be addressed. Also focusing the paper more would be useful. Please, check also the information for authors section providing useful guidelines for revising the paper.

In case you are not able to revise the manuscript by that date, you a later revision will be reviewed for the second issue.

Looking forward for the updated version by 13.12.

I think we won't be able to restructure this in time for the first issue. Let us know about the deadlines for the second issue.

You are welcome to submit a revised version by January 21st, 2012. That is also the CfP deadline for the second issue.

Editor

Being a reviewer of the originally submitted version, I have found some notable improvements in the new version of the paper – such as the inclusion of the section discussing the characteristics of cloud computing.

Unfortunately, it is still unclear what is the main focus of the paper: either the re-definition of cloud computing as a form of outsourcing or the refinement of the layered cloud computing model. At present, the paper discusses three issues: cloud as outsourcing, cloud properties and especially elasticity, and layers refinement into solutions and components; as a result, alas, none of them is elaborated sufficiently deeply. I would therefore (again) suggest the authors to decide on the major focus, and revise the paper accordingly, as otherwise it seems unclear to me, for whom the paper is written, and what is the main message of the paper.

Two more specific comments:

1. Cloud as outsourcing: Having something outsourced doesn’t immediately mean that it is “someone else’s problem”: you may e.g. still be responsible for managing the software layers run on top of AWS. Furthermore, if the software lifecycle is considered, some of the steps in the lifecycle (e.g. operations) may be “outsourced” to the cloud, while others (implementation, integration) may still be in-sourced. Cloud thus implies outsourcing of some of the software-supported processes, but not necessarily all of them.

2. Layered models. If this is the focus of the paper, you may consider extending section 5 by providing further examples of solutions and components, and arranging them in a certain framework to help the reader understand how these interrelate (you e.g. might consider which of the solutions/components interoperate and which do not, and whether/where the possibilities exist for general solutions/components applicable in multiple “stacks” to emerge). Some further examples were given in the original version of the paper but were removed during the revision; does it indicate that the major focus of the paper is elsewhere?

After receiving updated feedback on the draft we have considered rewriting the paper from the perspective of arguing that outsourcing is the key feature in cloud systems. We think this is the most relevant one of the topics discussed in our original submission. We think the paper deserves to be rewritten from this perspective. However revisiting the paper from this perspective solely is lots of work, and we are not sure when or if we have the resources to go through this. We do not think the material is in its current form suitable for inclusion in Communications of Cloud Software magazine. We wish to thank peer-reviewers for useful feedback on our work.

We need to produce a short article on the topic, as we plan to present the related poster during Yhdistetyt tietojenkäsittelyn päivät (ytp2012). We are planning to recycle some material originally submitted here for that article, as publishing the material in Communications of Cloud Software does not seem to make sense. The reasoning here is that the short article is supposed to match the poster, which is a promise that the material can live up to. We are in a bit of a hurry, as ytp2012 is getting closer pretty fast. Please let us know if there is a problem with recycling the material in the said manner. We would also appreciate a confirmation that this is ok. Thanks on forehand.

For ytp2012 see http://www.cs.helsinki.fi/ytp2012

Editor comments

Using the material published as a (non-peer reviewed) discussion paper in CCS for other purposes is fully allowed following the normal scientific practices. That is, citing the original publications when appropriate as well as including wt least 25% of new material to avoid self-plagiarism. I believe these constraints are not preventing your intended plans.

Thank you for submitting to CCS and you are welcome to submit new papers in the future.

Review process of the submission was finished.