[Saga-devel] saga-projects SVN commit 873: /papers/clouds/

[sjha at cct.lsu.edu]

User: sjha
Date: 2009/01/25 08:52 AM

Modified:
 /papers/clouds/
  saga_cloud_interop.tex, saga_data_intensive.bib

Log:
 Additions and refinements to text
   also added reference

File Changes:

Directory: /papers/clouds/
==========================

File [modified]: saga_cloud_interop.tex
Delta lines: +40 -10
===================================================================
--- papers/clouds/saga_cloud_interop.tex	2009-01-25 12:42:45 UTC (rev 872)
+++ papers/clouds/saga_cloud_interop.tex	2009-01-25 14:52:28 UTC (rev 873)
@@ -112,19 +112,27 @@
 \begin{itemize}
 \item Introduce the main concepts: infrastructure independence
   programming models and systems and interoperability,
-\item multiple levels at which interoperability can be implemented,
-  but we prefer/advocate application level interoperability.
+\item Multiple levels~\cite{cloud-ontology} at which interoperability
+  can be implemented, but we prefer/advocate application level
+  interoperability.
 \end{itemize}
 
 Although Clouds are a nascent infrastructure, with the
 force-of-industry behind their development and uptake (and not just
-the hype), their impact can not be ignored.  % Specifically, with the
+the hype), their impact on scientific computing can not be ignored.
+There is a ground swell in interest to adapt these emerging powerful
+infrastructure for large-scale scienctific applications[provide some
+references here].
+% Specifically, with the
 % emergence of Clouds as important distributed computing infrastructure,
 % we need abstractions that can support existing and emerging
 % programming models for Clouds. 
-Inevitably, the unified concept of a Cloud is evolving into different
-flavours and implementations, with distinct underlying system
-interfaces and infrastructure. For example, there are already multiple
+However as with any emerging technology, and inevitably, the unified
+concept of a Cloud is evolving into different flavours and
+implementations, with distinct underlying system interfaces and
+infrastructure. For example, the operating environment of Amazon's
+Cloud (EC2) is somewhat different from that of the Google's Cloud;
+more specifically for the latter, there exist already multiple
 implementations of Google's Bigtable, such as HyberTable, Cassandara,
 HBase. There is bound to be a continued proliferation of such Cloud
 based infrastructure; this is reminiscent of the plethora of grid
@@ -137,6 +145,10 @@
 least disruptive as possible, else it risks engendering technical and
 political horror stories reminiscent of Globus, which became a
 disastrous by-word for everything wrong with the complexity of Grids.
+But a more critical question is how can scientific applications be
+developed so as to utilize as broad a range of distributed systems
+as possible, without vendor lockp-in yet with the flexibility
+and performance that scientific application demand.
 
 Programming Models for Cloud: It is unclear what kind of programming
 models will emerge; this in turn will depend on other things, the
@@ -163,7 +175,10 @@
 % Clouds and Grids and importantly in bridging the gap between the two.
 Any {\it effective} abstraction will be cognizant and provide at least
 the above features, viz., relative compute-data placement,
-application-level patterns and interoperabilty.
+application-level patterns and interoperabilty.  Associated to the
+issue of developing scientific applications for Clouds, is the notion
+of interoperabiltiy, i.e., avoiding vendor lock-in and utilizing
+multiple Clouds...
 
 In Ref~\cite{saga_ccgrid09}, we established the important fact that
 SAGA -- the Simple API for Grid Applications a standard programming
@@ -247,6 +262,11 @@
 interoperabilty. In particular we will provide application-level
 motivation for interoperability.
 
+\jhanote{Mention how we have motivated the need to control
+  relative compute-date placement. This does not really change
+  just because we are using virtualization!}
+
+
 As mentioned, in this paper, we focus on MapReduce, which as is an
 application with multiple homgenous workers (although the data-load
 per worker can vary); however, it is easy to conceive of an
@@ -868,12 +888,22 @@
   Experiment Details}
 
 All this is new technology, hence makes sense to try to list some of
-the challenges we faced.
+the challenges we faced. We need to outline the interesting Cloud
+related challenges we encountered.  Not the low-level SAGA problems,
+but all issues related to making SAGA work on Clouds.
+{\textcolor{blue} Kate and Andre}
 
 \subsubsection*{Programming Models for Clouds}
-Programming Models Discuss affinity: Current Clouds compute-data
-affinity
 
+\jhanote{Mention that Amazon and Eucalyptus although distinct are
+  somewhat similar; a very different beast is Google's AppEngine.  We
+  will in the near future be working towards providing \sagamapreduce
+  via Google's AppEngine}
+
+  Programming Models Discuss affinity: Current Clouds
+  compute-data affinity
+
+
 %Simplicity of Cloud interface:
 
 To a first approximation, interface determines the programming models

File [modified]: saga_data_intensive.bib
Delta lines: +1 -0
===================================================================
--- papers/clouds/saga_data_intensive.bib	2009-01-25 12:42:45 UTC (rev 872)
+++ papers/clouds/saga_data_intensive.bib	2009-01-25 14:52:28 UTC (rev 873)
@@ -6774,3 +6774,4 @@
 
 @misc{pig, note = {PIG, http://hadoop.apache.org/pig/}}
 
+ at misc{cloud-ontology, note = {Towards a Unified Ontology of Cloud Computing, http://www.cs.ucsb.edu/~lyouseff/CCOntology/CloudOntology.pdf}}
\ No newline at end of file