Google's Cloud Now Bridges To Your Data Center

[Reuven Cohen]

Interesting announcement from Google yesterday in which they unveiled several new features for their Google App Engine platform. Most notable App Engine now includes supports for Java as well as several java related standards such as the Java Servlet API, JDO and JPA, javax.cache, and javax.mail. When it comes to an Open Cloud, Google seems to be saying action speaks louder then words and I applaud them for this!

I have been lucky enough to be given access to review some of the new App Engine features. For me the inclusion of Java is the least exciting of the new features. The most exciting aspects are the addition of hybrid cloud components that let you use a combination of cloud based resources as well as traditional data center centric resources.

These features include;

• Access to firewalled data: grant policy-controlled access to your data behind the firewall.
• Cron support: schedule tasks like report generation or DB clean-up at an interval of your choosing.
• Database import: move GBs of data easily into your App Engine app. Matching export capabilities are coming soon, hopefully within a month.

The core piece to this hybrid model is the Google Secure Data Connector (SDC) which they describe as a client tool that you can use with Google Apps Premier Edition or Education Edition to connect gadgets, applications, and spreadsheets to data that is protected by a corporate firewall.

SDC forms an encrypted connection between your data and Google Apps. SDC lets you control who in your domain can access which resources using Google Apps.

SDC works with Google Apps to provide data connectivity and enable IT administrators to control the data and services that are accessible in Google Apps. WithSDC, you can build private gadgets, spreadsheets, and applications that interact with your existing corporate systems.

The following illustration shows SDC connection components.

The steps are:

1. Google Apps forwards authorized data requests from users who are within the Google Apps domain to the Google tunnel protocol servers.
2. The tunnel servers validate that a user is authorized to make the request to the specified resource. Google tunnel servers are connected by an encrypted tunnel toSDC, which runs within a company's internal network.
3. The tunnel protocol allows SDC to connect to a Google tunnel server, authenticate, and encrypt the data that flows across the Internet.
4. SDC uses resource rules to validate if a user is authorized to make a request to a specified resource.
5. An optional intranet firewall can be used to provide extra network security.
6. SDC performs a network request to the specified resource or services.
7. The service verifies the signed requests and if the user is authorized, returns the data.

---
Reuven
CCIF Instigator

[tluk...@exnihilum.com]

>> "For me the inclusion of Java is the least exciting of the new features"

Then Reuven, I believe that you may be missing an enormous opportunity for enabling Cloud Portability.

If every Cloud platform had Java VM and .NET CLR support (on top of anything else they wanted to provide) then writing an application that was Portable from Cloud to Cloud could become a no-brainer. Cloud lock-in would then be a matter of choice (i.e. "write it in APEX")

TL

-----Original Message-----
From: "Reuven Cohen" [r...@enomaly.com]
Date: 04/08/2009 11:43 AM
To: cloud...@googlegroups.com
Subject: Re: Google's Cloud Now Bridges To Your Data Center

Interesting announcement from Google yesterday in which they unveiled several new features for their Google App Engine platform. Most notable App Engine now includes supports for Java as well as several java related standards such as the Java Servlet API, JDO and JPA, javax.cache, and javax.mail. When it comes to an Open Cloud, Google seems to be saying action speaks louder then words and I applaud them for this!

I have been lucky enough to be given access to review some of the new App Engine features. For me the inclusion of Java is the least exciting of the new features. The most exciting aspects are the addition of hybrid cloud components that let you use a combination of cloud based resources as well as traditional data center centric resources.

These features include;

Access to firewalled data: grant policy-controlled access to your data behind the firewall.Cron support: schedule tasks like report generation or DB clean-up at an interval of your choosing.Database import: move GBs of data easily into your App Engine app. Matching export capabilities are coming soon, hopefully within a month.The core piece to this hybrid model is the Google Secure Data Connector (SDC) which they describe as a client tool that you can use with Google Apps Premier Edition or Education Edition to connect gadgets, applications, and spreadsheets to data that is protected by a corporate firewall.

SDC forms an encrypted connection between your data and Google Apps. SDC lets you control who in your domain can access which resources using Google Apps.

SDC works with Google Apps to provide data connectivity and enable IT administrators to control the data and services that are accessible in Google Apps. WithSDC, you can build private gadgets, spreadsheets, and applications that interact with your existing corporate systems.

The following illustration shows SDC connection components.

The steps are:
Google Apps forwards authorized data requests from users who are within the Google Apps domain to the Google tunnel protocol servers.The tunnel servers validate that a user is authorized to make the request to the specified resource. Google tunnel servers are connected by an encrypted tunnel toSDC, which runs within a companys internal network. The tunnel protocol allows SDC to connect to a Google tunnel server, authenticate, and encrypt the data that flows across the Internet.SDC uses resource rules to validate if a user is authorized to make a request to a specified resource.An optional intranet firewall can be used to provide extra network security.SDC performs a network request to the specified resource or services.The service verifies the signed requests and if the user is authorized, returns the data.
---
Reuven
CCIF Instigator

[David Bernstein (daberns)]

Hi

 

Great point, of course its not just Java, it’s the bindings set that enable portability.

 

Let me be the first to suggest a Java profile called “Java CE” (or J2CE for the old schoolers)

 

Obviously “Cloud Edition”

 

This would the recipe for portability, Just like J2EE for the enterprise, or J2ME for the embedded device, and would allow for special interfaces “fit for cloud” like, Haddop bindings, distributed/replicated storage, some kind of semi-transactional database, etc

 

Thoughts?

[Reuven Cohen]

Java CE is great idea. I'd love to think this concept through some
more. How could you see this working?


r/c

[Geir Magnusson Jr.]

Hey, a tech-ish discussion.

I agree totally - I think that a managed runtime (I prefer the JVM,
but .NET CLR is fine) is the way to go for application portability.
Further, if we can get decent multi-tenancy w/in the JVM, I'm assuming
we can run the VM closer to the metal and get rid of all this VM
silliness :)

Couple it with decent packaging and lifecycle (e.g. OSGi), then things
get even more interesting...

geir

[tluk...@exnihilum.com]

>> "Thoughts?"

Many! I've been focusing on portability at the application layer since I first came here, and have felt intuitively that virtualization at the application level was the key to reducing, minimizing or eliminating the risk of lock-in for application developers and deserving of more attention than it gets. Most of the attention paid to virtualization (at least in this group so far) has been well below the application layer.

Thanks for taking the time to respond so quickly and thoughtfully. Now, let me see if I can diagram and document my intuition and turn my gut feelings into some concrete work products.

TL

-----Original Message-----
From: "David Bernstein " [dab...@cisco.com]
Date: 04/08/2009 08:13 PM
To: cloud...@googlegroups.com
Subject: RE: Google's Cloud Now Bridges To Your Data Center

Hi

Great point, of course its not just Java, it’s the bindings set that enable portability.

Let me be the first to suggest a Java profile called “Java CE” (or J2CE for the old schoolers)

Obviously “Cloud Edition”

This would the recipe for portability, Just like J2EE for the enterprise, or J2ME for the embedded device, and would allow for special interfaces “fit for cloud” like, Haddop bindings, distributed/replicated storage, some kind of semi-transactional database, etc

Thoughts?


From:cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of tluk...@exnihilum.com
Sent: Wednesday, April 08, 2009 4:58 PM

vciB0q¶

[Bechauf, Michael]

I don't think a set of APIs controlled by one company (Sun) that needs to be licensed from that company would fit my definition of an "open standard". There may be a "community process" and an invitation for public feedback, but that does not change the fact that it is a set of proprietary APIs licensed under commercial terms and under full control by one company.

The "Open Cloud" cannot be controlled by one company, or one individual *). It must be owned and independently operated.

-Michael

PS: *) I am not saying that this is what Sam had in mind, but if one individual attempts to get a trademark, that's not much better than Sun owning the Java trademark

----- Original Message -----
From: cloud...@googlegroups.com <cloud...@googlegroups.com>
To: cloud...@googlegroups.com <cloud...@googlegroups.com>
Sent: Wed Apr 08 20:29:34 2009
Subject: Re: Google's Cloud Now Bridges To Your Data Center

Java CE is great idea. I'd love to think this concept through some
more. How could you see this working?


r/c

On Wed, Apr 8, 2009 at 8:13 PM, David Bernstein (daberns)
<dab...@cisco.com> wrote:

[Bechauf, Michael]

Geir,

you of all people should know that you can't say Java or JVM without immediatly bringing up licensing. Sorry that I killed the purity of the first tech-ish thread on this list in a loooong time ;-)

-Michael

----- Original Message -----
From: cloud...@googlegroups.com <cloud...@googlegroups.com>
To: cloud...@googlegroups.com <cloud...@googlegroups.com>
Sent: Wed Apr 08 20:30:45 2009
Subject: Re: Google's Cloud Now Bridges To Your Data Center

Hey, a tech-ish discussion.

I agree totally - I think that a managed runtime (I prefer the JVM,
but .NET CLR is fine) is the way to go for application portability.
Further, if we can get decent multi-tenancy w/in the JVM, I'm assuming
we can run the VM closer to the metal and get rid of all this VM
silliness :)

Couple it with decent packaging and lifecycle (e.g. OSGi), then things
get even more interesting...

geir

On Apr 8, 2009, at 7:57 PM, tluk...@exnihilum.com wrote:

>

[tluk...@exnihilum.com]

>> "Hey, a tech-ish discussion."

Cool, huh? It is refreshingly different.. ;-)

TL

[Reuven Cohen]

Another thought about the Google Secure Data Connector is that it
makes it way too easy to bypass your DC firewall. This sounds like it
could this be a major security risk. Right off the top of my head I
can think of several unsavory use cases.


r/c

[tluk...@exnihilum.com]

Kahuna Matata, Michael.. it's all good ;-)

Consider what we're discussing as more of an abstract, high-level model. I can run .NET code with Mono, or I can run Java code with Kaffe or Harmony or Classpath. I don't need to involve Microsoft or Sun. We're simply looking at and talking about leveraging virtualization at the application level and not just at the infrastructure level.

TL

-----Original Message-----
From: "Bechauf, Michael" [michael...@sap.com]
Date: 04/08/2009 08:42 PM
To: cloud...@googlegroups.com
Subject: Re: Google's Cloud Now Bridges To Your Data Center

I don't think a set of APIs controlled by one company (Sun) that needs to be licensed from that company would fit my definition of an "open standard". There may be a "community process" and an invitation for public feedback, but that does not change the fact that it is a set of proprietary APIs licensed under commercial terms and under full control by one company.

The "Open Cloud" cannot be controlled by one company, or one individual *). It must be owned and independently operated.

-Michael

PS: *) I am not saying that this is what Sam had in mind, but if one individual attempts to get a trademark, that's not much better than Sun owning the Java trademark

----- Original Message -----
From: cloud...@googlegroups.com <cloud...@googlegroups.com>
To: cloud...@googlegroups.com <cloud...@googlegroups.com>

Sent: Wed Apr 08 20:29:34 2009
Subject: Re: Google's Cloud Now Bridges To Your Data Center

Java CE is great idea. I'd love to think this concept through some
more. How could you see this working?

r/c

On Wed, Apr 8, 2009 at 8:13 PM, David Bernstein (daberns)
<dab...@cisco.com> wrote:
> Hi
>
>
>
> Great point, of course its not just Java, it’s the bindings set that enable
> portability.
>
>
>
> Let me be the first to suggest a Java profile called “Java CE” (or J2CE for
> the old schoolers)
>
>
>
> Obviously “Cloud Edition”
>
>
>
> This would the recipe for portability, Just like J2EE for the enterprise, or
> J2ME for the embedded device, and would allow for special interfaces “fit
> for cloud” like, Haddop bindings, distributed/replicated storage, some kind
> of semi-transactional database, etc
>
>
>
> Thoughts?
>
>
>
>
>
> From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On
> Behalf Of tluk...@exnihilum.com

> Sent: Wednesday, April 08, 2009 4:58 PM
> To: cloud...@googlegroups.com
> Subject: Re: Google's Cloud Now Bridges To Your Data Center
>
>
>

z
dG‰

[David Bernstein (daberns)]

Michael

Let me rephrase my proposal, as your point is well taken

There are a generally accepted set of API's for programming PC like clients, and embedded devices, and enterprise servers. These API's are expressed in several languages, but many of the concepts are common. For example connection pooling and back end database transactions are a common API for server code.

Common practice has, within a language implementation, evolved such that a high degree of portability for the programmer has emerged, irrespective of the vendor/open source of the language runtime and support libraries.

As cloud is a new type of "platform", a common set of API's for common programming metaphors should emerge. For example, in a cloud, filesystem access semantics are different (non Posix compliant). Several database-like paradigms emerge (Hadoop, non-SQL query methods, etc) but they are not like server semantics. Maybe parallel programming API's will come from the grid world (Globus, MPI) into more commonuse as cloud platforms are better at supporting them.

If the community can develop this common API approach, portability will be greatly enhanced cloud to cloud. Also, deployment and container issues are part of this.

In the Java world, the old schoolers would metaphorically "aha" this concept if one were to make up a term called "J2CE - Java 2 Cloud Edition"

David.

[David Bernstein (daberns)]

Not to forget that Netweaver has what my friends tell me is a fine implementation of a Java app server in it J

[Sam Johnston]

Having .Net (Microsoft's Azure) and Java (Google App Engine) platform services available is certainly a good thing that allows for a huge amount of flexibility (think JRuby, Jython, etc.). Adding a language natively to a platform is extremely difficult courtesy security and billing concerns but uploading an interpreter with your app is now easy.

You do have to think different though (sorry Apple) as lots of things change - particularly the database which is at the heart of most interesting web based applications. In the "cloud as an operating environment" paradigm you have a reasonably static number of components (storage, queues, compute, etc.) that can be used to make arbitrarily complex applications. Mapping these to a profile (bearing in mind that Google have done a lot of the work already) would be great for developers and a boon for interoperability.

Idle thought: Native Client, while an interesting idea, is sure to run in to trouble with the approaching army of ARM/MIPS devices (given its x86 roots). A cloud version on the other hand could be very interesting in that it would allow users to upload native code "workloads" and have them run and be billed securely with virtually zero overhead.

As for the "Open Cloud" discussion, I can only suggest to join the list and contribute there as we are genuinely interested in this kind of feedback and won't be rushing to lock in an arbitrary definition. The complaints we anticipate about this are free software advocates claiminig the bar is too low and businesses claiming the bar is too high. We can't please everyone but are pretty sure we can go damn close.

Sam

[Patrick J Kerpan]

We are seeing this with our VPN-Cubed product.  I am still struggling to describe the distinction between constituencies, something like "software centric" teams vs. data center teams.

The former group likes the idea of virtual machines that are basically a router that they can fire up and connect to an EC2 cluster.  The data center guys look at this as potentially a "rogue" router and want the connectivity to go through their official connectivity solution, usually something like a Jupiter Netscreen or Cisco ASA-something. 

We are covering both cases - it is early days, but my sense is the demand might be about split.

[Bechauf, Michael]

On a totally different topic: Sam, do you ever sleep ? It's 4am in the morning in France. Dude, take a rest ! The "Open Cloud" movement needs healthy leaders ;-)

-Michael

---

From: cloud...@googlegroups.com <cloud...@googlegroups.com>
To: cloud...@googlegroups.com <cloud...@googlegroups.com>

Sent: Wed Apr 08 21:13:17 2009

Subject: Re: Google's Cloud Now Bridges To Your Data Center

Having .Net (Microsoft's Azure) and Java (Google App Engine) platform services available is certainly a good thing that allows for a huge amount of flexibility (think JRuby, Jython, etc.). Adding a language natively to a platform is extremely difficult courtesy security and billing concerns but uploading an interpreter with your app is now easy.

You do have to think different though (sorry Apple) as lots of things change - particularly the database which is at the heart of most interesting web based applications. In the "cloud as an operating environment" paradigm you have a reasonably static number of components (storage, queues, compute, etc.) that can be used to make arbitrarily complex applications. Mapping these to a profile (bearing in mind that Google have done a lot of the work already) would be great for developers and a boon for interoperability.

Idle thought: Native Client, while an interesting idea, is sure to run in to trouble with the approaching army of ARM/MIPS devices (given its x86 roots). A cloud version on the other hand could be very interesting in that it would allow users to upload native code "workloads" and have them run and be billed securely with virtually zero overhead.

As for the "Open Cloud" discussion, I can only suggest to join the list and contribute there as we are genuinely interested in this kind of feedback and won't be rushing to lock in an arbitrary definition. The complaints we anticipate about this are free software advocates claiminig the bar is too low and businesses claiming the bar is too high. We can't please everyone but are pretty sure we can go damn close.

Sam

On Thu, Apr 9, 2009 at 2:58 AM, David Bernstein (daberns) <dab...@cisco.com> wrote:

Michael

Let me rephrase my proposal, as your point is well taken

There are a generally accepted set of API's for programming PC like clients, and embedded devices, and enterprise servers. These API's are expressed in several languages, but many of the concepts are common. For example connection pooling and back end database transactions are a common API for server code.

Common practice has, within a language implementation, evolved such that a high degree of portability for the programmer has emerged, irrespective of the vendor/open source of the language runtime and support libraries.

As cloud is a new type of "platform", a common set of API's for common programming metaphors should emerge. For example, in a cloud, filesystem access semantics are different (non Posix compliant). Several database-like paradigms emerge (Hadoop, non-SQL query methods, etc) but they are not like server semantics. Maybe parallel programming API's will come from the grid world (Globus, MPI) into more commonuse as cloud platforms are better at supporting them.

If the community can develop this common API approach, portability will be greatly enhanced cloud to cloud. Also, deployment and container issues are part of this.

In the Java world, the old schoolers would metaphorically "aha" this concept if one were to make up a term called "J2CE - Java 2 Cloud Edition"

David.

-----Original Message-----
From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Bechauf, Michael

Sent: Wednesday, April 08, 2009 5:41 PM
To: cloud...@googlegroups.com
Subject: Re: Google's Cloud Now Bridges To Your Data Center

I don't think a set of APIs controlled by one company (Sun) that needs to be licensed from that company would fit my definition of an "open standard". There may be a "community process" and an invitation for public feedback, but that does not change the fact that it is a set of proprietary APIs licensed under commercial terms and under full control by one company.

The "Open Cloud" cannot be controlled by one company, or one individual *). It must be owned and independently operated.

-Michael

PS: *) I am not saying that this is what Sam had in mind, but if one individual attempts to get a trademark, that's not much better than Sun owning the Java trademark


----- Original Message -----
From: cloud...@googlegroups.com <cloud...@googlegroups.com>
To: cloud...@googlegroups.com <cloud...@googlegroups.com>
Sent: Wed Apr 08 20:29:34 2009

Subject: Re: Google's Cloud Now Bridges To Your Data Center

Java CE is great idea. I'd love to think this concept through some
more. How could you see this working?

r/c

On Wed, Apr 8, 2009 at 8:13 PM, David Bernstein (daberns)
<dab...@cisco.com> wrote:
> Hi
>
>
>
> Great point, of course its not just Java, it’s the bindings set that enable
> portability.
>
>
>
> Let me be the first to suggest a Java profile called “Java CE” (or J2CE for
> the old schoolers)
>
>
>
> Obviously “Cloud Edition”
>
>
>
> This would the recipe for portability, Just like J2EE for the enterprise, or
> J2ME for the embedded device, and would allow for special interfaces “fit
> for cloud” like, Haddop bindings, distributed/replicated storage, some kind
> of semi-transactional database, etc
>
>
>
> Thoughts?
>
>
>
>
>
> From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On
> Behalf Of tluk...@exnihilum.com

> Sent: Wednesday, April 08, 2009 4:58 PM
> To: cloud...@googlegroups.com
> Subject: Re: Google's Cloud Now Bridges To Your Data Center
>
>
>

[Bechauf, Michael]

Yes, that NetWeaver Java Application Server implementation is doing just fine, but unfortunately Sun has the flu (which prompted my comment, because we do not want to see the same level of control of an ecosystem in the Cloud again). And Harmony, well, I better be quiet and let Geir comment ...

I'll shut up now and rather listen to the technical thread. After all, I joined this list to learn something, not just to stand on my soapbox.

-Michael

---

From: cloud...@googlegroups.com <cloud...@googlegroups.com>
To: cloud...@googlegroups.com <cloud...@googlegroups.com>

Sent: Wed Apr 08 21:01:15 2009
Subject: RE: Google's Cloud Now Bridges To Your Data Center

Not to forget that Netweaver has what my friends tell me is a fine implementation of a Java app server in it J

 

From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of tluk...@exnihilum.com
Sent: Wednesday, April 08, 2009 5:54 PM
To: cloud...@googlegroups.com
Subject: Re: Google's Cloud Now Bridges To Your Data Center

 

Kahuna Matata, Michael.. it's all good ;-)

Consider what we're discussing as more of an abstract, high-level model. I can run .NET code with Mono, or I can run Java code with Kaffe or Harmony or Classpath. I don't need to involve Microsoft or Sun. We're simply looking at and talking about leveraging virtualization at the application level and not just at the infrastructure level.

TL


-----Original Message-----
From: "Bechauf, Michael" [michael...@sap.com]

z
dG‰

[Geir Magnusson Jr.]

On Apr 8, 2009, at 8:44 PM, Bechauf, Michael wrote:

> Geir,
>
> you of all people should know that you can't say Java or JVM without
> immediatly bringing up licensing. Sorry that I killed the purity of
> the first tech-ish thread on this list in a loooong time ;-)

Oh, I'm aware. :)

But the Java ecosystem is getting close to a bifurcation point - Sun's
intransigence on the issue of independent implementations is putting
Java in danger overall, and I think it's time we have *serious*
discussions on what to do about it, and I have some ideas.

Even though this is important - lets put this issue aside for now -
and focus on the potential for the technology in this domain.

geir

[Geir Magnusson Jr.]

As a Java old-schooler myself, I wouldn't "a ha" as much as "oh
no..." :)

Why? We're actually seeing the convergence of the platforms (SE, EE,
ME).

On the bottom, ME appears to be less and less relevant as hardware
capability increases - why would I limp along with ME when phones are
showing SE-class capability (e.g. Google G1). And on the top, years
of learning are pushing us to modular capability rather than "full-
stack" collections of APIs - for example OSGi, and the profile work
being done in Java EE.

I also think that it's too early to crown any API winners yet. We
still have no idea what we're doing :)

However, I'm a Java Weenie(tm), and I think that Java is the place to
be in the cloud. (.NET maybe, but only if we can untangle the IP
threats from MSFT). I can run languages such as Python and Ruby (and
run them fast), mix with vast, existing enterprise-class libraries and
legacy code, and leverage very good operational manageability.

geir

[Sam Johnston]

On Thu, Apr 9, 2009 at 1:29 PM, Geir Magnusson Jr. <ge...@pobox.com> wrote:

Why?  We're actually seeing the convergence of the platforms (SE, EE,
ME).

On face value and based on what Google have done to expose AppEngine integration points (e.g. datastore, mail, web requests/responses, etc.) David's idea actually has some merit - that is, the concept of java exposing infinitely scalable cloud services via tried and tested, stable APIs that lots of developers are comfortable with. Convergence trumps specialisation though so from that point of view, like you I'd rather see the various strains culled off (J2ME doesn't make sense any more anyway - an iPhone looks ~= a MacBook to the OS, except for touch).
 

I also think that it's too early to crown any API winners yet.  We
still have no idea what we're doing :)

Some components are shining through as winners - obvious ones being databases, file storage and queues, but even esoteric services like MTurk fill an important role in the ecosystem. I'd like to see a "cloud as the operating environment" poster appear at some point which maps the various functions to existing implementations in $favourite_language.

However, I'm a Java Weenie(tm), and I think that Java  is the place to
be in the cloud.  (.NET maybe, but only if we can untangle the IP
threats from MSFT).  I can run languages such as Python and Ruby (and
run them fast), mix with vast, existing enterprise-class libraries and
legacy code, and leverage very good operational manageability.

I generally agree with this sentiment but would be happier if bare metal were exposed via the cloud equivalent of Native Client - thereby giving users ultimate flexibility in what workloads they can run in the cloud. As a nice bonus the bloated, expensive [to implement and operate] operating system would go the way of the dodo.

Sam

[Geir Magnusson Jr.]

On Apr 9, 2009, at 7:45 AM, Sam Johnston wrote:

> On Thu, Apr 9, 2009 at 1:29 PM, Geir Magnusson Jr. <ge...@pobox.com>
> wrote:
> Why? We're actually seeing the convergence of the platforms (SE, EE,
> ME).
>
> On face value and based on what Google have done to expose AppEngine
> integration points (e.g. datastore, mail, web requests/responses,
> etc.) David's idea actually has some merit - that is, the concept of
> java exposing infinitely scalable cloud services via tried and
> tested, stable APIs that lots of developers are comfortable with.
> Convergence trumps specialisation though so from that point of view,
> like you I'd rather see the various strains culled off (J2ME doesn't
> make sense any more anyway - an iPhone looks ~= a MacBook to the OS,
> except for touch).

Yes, but didn't they just put a JavaMail wrapper around their mail
impl, a JDO/JPA layer on the datastore? These are years-old
technologies. Slapping a "Java CE" label on them makes no sense to
me, since we already have those APIs.

>
> I also think that it's too early to crown any API winners yet. We
> still have no idea what we're doing :)
>
> Some components are shining through as winners - obvious ones being
> databases, file storage and queues, but even esoteric services like
> MTurk fill an important role in the ecosystem. I'd like to see a
> "cloud as the operating environment" poster appear at some point
> which maps the various functions to existing implementations in
> $favourite_language.

These are all things that we use outside of the cloud already. I'm
not sure where the CE label would help.

>
> However, I'm a Java Weenie(tm), and I think that Java is the place to
> be in the cloud. (.NET maybe, but only if we can untangle the IP
> threats from MSFT). I can run languages such as Python and Ruby (and
> run them fast), mix with vast, existing enterprise-class libraries and
> legacy code, and leverage very good operational manageability.
>
> I generally agree with this sentiment but would be happier if bare
> metal were exposed via the cloud equivalent of Native Client -
> thereby giving users ultimate flexibility in what workloads they can
> run in the cloud. As a nice bonus the bloated, expensive [to
> implement and operate] operating system would go the way of the dodo.

Yep.

Traditionally, we see commoditization come from the bottom and chase
innovation up the stack. I don't think it's going to be different in
"cloud" either.

I think that if we were going to push for a managed runtime tailored
for cloud, we should spend some time focused on things like
deployment, manageability, and approaches to multi-tenancy (there
already has been some work done for isolates, e.g. http://java.sun.com/developer/technicalArticles/Programming/mvm/
which I really could have used last year, but there hasn't been much
of a market need for it to drive the research into usable product) -
all "bottom of the stack" stuff, and let the rich froth of "market
evolution" sort out the winners further up.

The beauty of the 10+ years of existing Java APIs (be the good or
bad... JavaMail does fall in "bad" category, but it's what we have) is
that people know them and existing code works with them, and they are
swappable. If you don't like Google's JavaMail impl, just use another
provider. As long as you have network...

geir

[Sam Johnston]

On Thu, Apr 9, 2009 at 3:40 AM, Bechauf, Michael <michael...@sap.com> wrote:

On a totally different topic: Sam, do you ever sleep ? It's 4am in the morning in France. Dude, take a rest ! The "Open Cloud" movement needs healthy leaders ;-)

It's true that I've been burning the midnight oil for two weeks now trying to get the community to coalesce, but who said anything about wanting to lead it?

Au contraire, I wholeheartedly agree with Simon Wardley's suggestion that "the first act of the CCIF governance process should be to ban anyone who wants to lead from the process". I also agree that we "should have an open election of officers with a candidate list and one vote, one person", and that neither myself nor any of the existing leadership should be on that list. Fortunately there are other, far more experienced people waiting in the wings so finding suitable candidates is the least of our worries. Of course by maintaining a death grip on the community and essentially holding it to ransom they leave us few choices.

Anyway, in an attempt to maintain the surprisingly high signal to noise ratio of late I'm going to attach a pretty picture illustrating "cloud computing openness" (given a picture tells a thousand words and all that), showing where we're at right now and the point I think we need to get to. I'd write a song but my brother got the voice in the family...

Sam

[David Bernstein (daberns)]

Hi Everyone

I am not suggesting a "CE" label or even a standardized API. I am simply
saying, that common practice API sets, will enhance cloud portability,
esp if there is an open source Java runtime for clouds that looks like
what Google is doing.. Geir, can you comment on Babble, and if this
could be such a base for an open source implementation of a Java runtime
and appserver that the community could get behind and maybe be a "build
your own" source for AppEngine Java runtime compatibility?

[Gregg Wonderly]

On Apr 8, 2009, at 10:42 AM, Reuven Cohen wrote:

> Interesting announcement from Google yesterday in which they
> unveiled several new features for their Google App Engine platform.
> Most notable App Engine now includes supports for Java as well as
> several java related standards such as the Java Servlet API, JDO and
> JPA, javax.cache, and javax.mail. When it comes to an Open Cloud,
> Google seems to be saying action speaks louder then words and I
> applaud them for this!
>
> I have been lucky enough to be given access to review some of the
> new App Engine features. For me the inclusion of Java is the least
> exciting of the new features.

The fact that Java is support means that Jini can now be used there,
and that opens up all kinds of interworking possibilities. Mobile
code and smart proxies remove a lot of integration and interworking
nightmares by allowing the same API to be visible everywhere, but for
different users to have different implementations, all maintained and
supported centrally; i.e. one copy, one implementation, one time.
This doesn't happen for XML based document exchange...

Gregg Wonderly

[Sam Johnston]

The availability of Java on AppEngine is an absolute boon for cloud platform services - it's just a shame that it's so far limited to the first 10,000 people to jump on it ("lucky enough to be given access to review" my *aaS). Fortunately these quotas tend to move quickly so those of you who missed out should be able to jump on board soon enough. In the mean time I'm chuffed that my Eclipse install can now talk to Amazon, Aptana, Google and Salesforce... anyone else see the pattern here (at least until Bespin et al take over)?

Incidentally Sun have had their "OpenJava" strategy posted at http://www.openjava.org/ for the past two years... seems to cover it in an appropriate level of detail ;)

Sam

[Chris Marino]

Gang,  Java on GAE is severely hobbled, just like Python.  Before anyone gets all excited about moving their apps to GAE, they might want to consider that:
 
  There is no file i/o
  There is no supported relational DB
  The JRE is limited to this whitelist
  Cannot spawn threads
  Cannot make arbitrary network connections.
  Cannot use JNI

There are lot of things you can do without these capabilities. On the other hand, most existing apps use one or more of them.

CM

[tluk...@exnihilum.com]

>> "Sun have had their "OpenJava" strategy posted at http://www.openjava.org/ for the past two years..."
>> "seems to cover it in an appropriate level of detail ;)"

That is too funny, Sam.. has it always been just a blank page?

TL

-----Original Message-----
From: "Sam Johnston" [sa...@samj.net]
Date: 04/10/2009 12:13 PM
To: cloud...@googlegroups.com
Subject: Re: Google's Cloud Now Bridges To Your Data Center

On Fri, Apr 10, 2009 at 5:51 PM, Gregg Wonderly <greg...@gmail.com> wrote:
On Apr 8, 2009, at 10:42 AM, Reuven Cohen wrote:

> Interesting announcement from Google yesterday in which they
> unveiled several new features for their Google App Engine platform.
> Most notable App Engine now includes supports for Java as well as
> several java related standards such as the Java Servlet API, JDO and
> JPA, javax.cache, and javax.mail. When it comes to an Open Cloud,
> Google seems to be saying action speaks louder then words and I
> applaud them for this!
>
> I have been lucky enough to be given access to review some of the
> new App Engine features. For me the inclusion of Java is the least
> exciting of the new features.


The fact that Java is support means that Jini can now be used there,
and that opens up all kinds of interworking possibilities. Mobile
code and smart proxies remove a lot of integration and interworking
nightmares by allowing the same API to be visible everywhere, but for
different users to have different implementations, all maintained and
supported centrally; i.e. one copy, one implementation, one time.

This doesnt happen for XML based document exchange...

The availability of Java on AppEngine is an absolute boon for cloud platform services - its just a shame that its so far limited to the first 10,000 people to jump on it ("lucky enough to be given access to review" my *aaS). Fortunately these quotas tend to move quickly so those of you who missed out should be able to jump on board soon enough. In the mean time Im chuffed that my Eclipse install can now talk to Amazon, Aptana, Google and Salesforce... anyone else see the pattern here (at least until Bespin et al take over)?

[Reuven Cohen]

@TL Brings new meaning to open. On a side note I find it interesting
that Sun hasn't trademarked their use of the "Open Cloud Platform"

@CM, I think the more interesting point is that Google appears to be
taking steps to address a hybrid cloud future. I agree there is a lot
of work yet to be done, but this where the developer community will
probably need to step up. Similar to the AWS ecosystem.

r/c

--

[Sam Johnston]

> That is too funny, Sam.. has it always been just a blank page?

Funny, yes. Actually according to archive.org it turns out there's an interesting history dating back over a decade:

• The Open Source Java Directory (coming soon in 1998, never did)
  
• Ian Davis and Kevin A. Burton (ASF guy?) then created a "site dedicated towards furthing the cause of a fully Open Source Java Virtual Machine (and related technologies)."
• An "Adult Entertainment" site then got hold of it and offered it up for sale, followed by some SEO shop.
• Sun snapped it up a bit over two years ago for their "Open Java Manifesto", which you can still see today :P
  

Reuven: "On a side note"? Seriously, grow up. If you want to discuss the open cloud trademark then present your argument in the appropriate thread/forum rather than sniffing around trying to find flaws and taunting me by taking cheap shots at it. For a 30 year old you're behaving like a child and you've already been told to stay out of trouble.

Sam

[Bechauf, Michael]

Guys, when will it stop ? This is a really interesting discussion, but then the post finishes with this ....

 

Reuven: "On a side note"? Seriously, grow up. If you want to discuss the open cloud trademark then present your argument in the appropriate thread/forum rather than sniffing around trying to find flaws and taunting me by taking cheap shots at it. For a 30 year old you're behaving like a child and you've already been told to stay out of trouble.

 

I know you have an axe to grind with each other. Yes, everybody knows that by now. But can we PLEASE stop these constant accusations and counter-accusations and start to act like a team ?

 

Look: I'm working in a 50,000 people company. Do I get along with everybody ? No, absolutely not. Do I agree with all of the public positions of my employer ? No, even being a VP for a company does not mean that I need to like everything my employer does. But I still stay with the team, because I know that together we can achieve greater goals that will change the industry.

 

If we want to achieve great things together, we need to keep the team together, and this requires a certain culture and restraint in public critismn. I know how it feels to be angry at colleagues, even the ones that deep down I really respect. I'm guilty of writing flame emails as well (I just did so yesterday to a few colleages in the SAP legal community), but they do more damage then good. email is such a horrible vehicle because it's so tempting to quickly express frustrations and emotions that we probably would not even think about saying to each other were we sitting across each other over a meal, beer or whatever your favorite beverage is.

 

So, in the future, would you do me a favor ? Before you engage in accusations and counter-accusations, however justified you think they are, and however angry you are, PLEASE, think for a moment if that person would sit across from you at the table, remind yourself that he/she is a valuable member of your team with whom you want to change the industry. Hold that thought for a moment, and then think whether you still want to write what you wanted to write, especially knowing that you do it in front of 800 people.

 

Thank you for giving this thought a few moments of your consideration.

 

Best,

Michael

 

---

From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Sam Johnston
Sent: Friday, Apr 10, 2009 11:22 AM

[Reuven Cohen]

+1

r/c

[Alexis Richardson]

+1

Happy Easter everyone.

Please can *everyone* now introduce a principle of charity to all CCIF
emails, at least for a few months please. This means "assume the most
charitable interpretation of what your interlocutor is saying". Or if
you prefer "do not assume everyone is out to get you".

No more posturing - please. If you contribute to the list, try if you
can face it, to propose or deliver actionable work.

alexis

[tluk...@exnihilum.com]

>> "Before anyone gets all excited.."

Chris, a couple of thoughts:

First: although the described limitations do present a few immediate challenges, I'm a lifelong subscriber to the "Every problem is an opportunity" POV, and I am already recognizing and thinking about a few.

Second: the situation reminds me in some ways of moving from writing software in a DOS environment - where you could assume that your application had full control over all of the hardware - to writing for Windows. Yeah, you lost the ability to do a few things, but before long you didn't even miss them.

I'm planning to work over the weekend on writing up some thoughts and ideas that I've had regarding (among other things) [1] virtualization at the application level, [2] an approach to gaining Cloud interoperability and portability that shifts some control (burden?) to the Cloud developer rather than relying 100% on "the kindness of strangers" (read: Cloud platform providers and vendors), and [3] overcoming the limitations and restrictions that are imposed on Cloud-based development.

Hopefully some of it will lead to a productive work thread or sub-project within the group.

TL

-----Original Message-----
From: "Chris Marino" [christophe...@gmail.com]
Date: 04/10/2009 01:15 PM
To: cloud...@googlegroups.com
Subject: Re: Google's Cloud Now Bridges To Your Data Center

Gang, Java on GAE is severely hobbled, just like Python. Before anyone gets all excited about moving their apps to GAE, they might want to consider that:

There is no file i/o
There is no supported relational DB
The JRE is limited to this whitelist
Cannot spawn threads
Cannot make arbitrary network connections.
Cannot use JNI

There are lot of things you can do without these capabilities. On the other hand, most existing apps use one or more of them.

CM


On Fri, Apr 10, 2009 at 9:13 AM, Sam Johnston <sa...@samj.net> wrote:

[tluk...@exnihilum.com]

>> "Happy Easter everyone."

Right back at you. Let's try to leverage the Holiday and have a Resurrection of our own in this group!

TL

-----Original Message-----
From: "Alexis Richardson" [alexis.r...@gmail.com]
Date: 04/10/2009 02:53 PM
To: cloud...@googlegroups.com
Subject: Re: Google's Cloud Now Bridges To Your Data Center

> To: cloud...@googlegroups.com
> Subject: Re: Google's Cloud Now Bridges To Your Data Center
>

>> > >> "Sun have had their "OpenJava" strategy posted at
>> > >> http://www.openjava.org/ for the past two years..."
>> > >> "seems to cover it in an appropriate level of detail ;)"
>> >

>> > That is too funny, Sam.. has it always been just a blank page?
>> >
>> > TL
>> >
>> > -----Original Message-----
>> > From: "Sam Johnston" [sa...@samj.net]

>> > Date: 04/10/2009 12:13 PM
>> > To: cloud...@googlegroups.com
>> > Subject: Re: Google's Cloud Now Bridges To Your Data Center
>> >

>> --
>>
>>
>
> >
>

[Sam Johnston]

"+1"? Q.E.D. Reuven: that was as much directed at you as me.

Michael, you justified your flame of your recipient(s) on the basis that they were "do[ing] more damage then good". That's perfectly reasonable justification and it's word for word what I said almost 6 months ago now of mine.

There have been 336 hours in the past two weeks and I have spent very nearly all of them furthering the interests of cloud computing for no personal benefit. Meanwhile, when I was trying to hold this community together Reuven was off having fancy drinks.

That's fine... someone's got to be the public face of cloud computing (and it's not going to be me). However, when I'm working on a very short timeframe to deliver OCCI, spending my company's money defending the "Open Cloud" (from the same individual no less), knowing that the only thing I need from this community is use cases, and then when that same person deftly extinguishes any chance of that being delivered in time (thereby ensuring that I will spend my easter weekend doing it myself), I'm going to be pissed. Especially when they're off doing trademark searches trying to find fault in my work. You would be too.

If anyone (Reuven or otherwise) says something stupid and/or commits a crass act of stupidity, I'm going to call them on it. Every. Single. Time. There is absolutely no problem with this group outside of the leadership of it and if anyone has any ideas about how to fix that then I'm all ears.

Sam

[Bechauf, Michael]

Sam, you have to do what you think you have to do. I can't say more than what I already said. Just this:

 

My point about flames is that those emails are doing more damage than good - not the people. I generally love people, enjoy the interactions with them and try to give them the benefit of the doubt. A lot of things can be worked out when people choose to work together. Yes, people are complicated and have their own interests in mind, but if we as individuals would choose to fight every fight that there is to fight, I don't think we would have seen great human innovations like a car, airplane or computers come to existence. In fact, I believe we would probably still be living in caves.

 

This group needs to include, and not exclude. There can't be any "us" against "them". There can only be a "we".

 

You are a very passionate individual and everybody respects you for your knowledge and eagerness to do the right thing for the community, at all times of day and night, even at your own personal expense. However, I really believe you have got to stop believing that you must defend this community against anybody who you suspect has sinister motives. Yes, there is a lot of evil in the world, and I'd be the first to acknowledge that people can abuse power, but don't just assume - we need to trust a little. Once we start to trust, we learn to tolerate. And with tolerance, we start to work together and accomplish a goal.

 

Closing remark: According to the free online dictionary "Fanaticism" is defined as "excessive intolerance of opposing views". Let's not turn into that.

 

Happy Easter everyone. And no, I'm not a priest, in fact I have not been to church in a long time and my wife is Hindu. Nevertheless, I think there are couple of lessons to be learned, particularly today.

 

Best,

Michael

---

From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Sam Johnston

Sent: Friday, Apr 10, 2009 2:33 PM

[Utpal Datta]

TL

 

you are not completely correct!! There is a "." at the beginning of the page :-)

 

It is funny though, can't deny that. Kinda matches with Sun's strategy (just kidding, SUN folks) :-)

 

[M. David Peterson]

On Fri, Apr 10, 2009 at 3:33 PM, Sam Johnston <sa...@samj.net> wrote:

That's fine... someone's got to be the public face of cloud computing (and it's not going to be me).

Okay, I'll do it. Who should I send my 5x10 Glossy too? ;-)

--
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.d...@3rdandUrban.com | m.d...@amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm | http://broadcast.oreilly.com/m-david-peterson/

[tluk...@exnihilum.com]

>> "Who should I send my 5x10 Glossy too?"

Umm.. this is going to be an international effort.. better make it a valid passport photo.

TL

-----Original Message-----
From: "M. David Peterson" [xmlh...@gmail.com]
Date: 04/10/2009 11:14 PM
To: cloud...@googlegroups.com
Subject: Re: Google's Cloud Now Bridges To Your Data Center

On Fri, Apr 10, 2009 at 3:33 PM, Sam Johnston <sa...@samj.net> wrote:

Thats fine... someones got to be the public face of cloud computing (and its not going to be me).

Okay, Ill do it. Who should I send my 5x10 Glossy too? ;-)

[Sam Johnston]

Michael,

On Sat, Apr 11, 2009 at 12:28 AM, Bechauf, Michael <michael...@sap.com> wrote:

However, I really believe you have got to stop believing that you must defend this community against anybody who you suspect has sinister motives. Yes, there is a lot of evil in the world, and I'd be the first to acknowledge that people can abuse power, but don't just assume - we need to trust a little. Once we start to trust, we learn to tolerate. And with tolerance, we start to work together and accomplish a goal.

I don't act on suspicion - I do my research (as I have done in this case, much of which is shared in confidence) and I can assure you that the time for assuming good faith is long since gone. Intentions aside, I've run out of fingers with which to count bridges critical to the success of CCIF that have been burnt to the ground - in addition to the incumbent vendors who won't touch us now there's other similar organisations like the CSA, important individuals... even the academic community was put out this week after discovering their having been broadly accused by @ruv of plagarising his electricity grid analogy (one that predates him by decades incidentally).

In the words of uncle Larry, "When is this idiocy going to stop?". Ignoring the situation to get down to work is implicitly accepting it which means we'll almost certainly end up living with it, and yet every day I get mails thanking me for representing our interests when those who should be are not. Today's is "I admire your courage in standing up to a lot of the nonsense that's flying around on the CCIF charade parade". An earlier one was: "Just read your excellent post on the farce that has become the CCIF. I was eager in the beginning when I signed up, but it was clear to me from the Google group that these jokers were really only in it for themselves - something that must've been abdundantly clear to everyone else".

Then there's feedback like "I like your style and think your doing some good work making sure the the open in open cloud really is what it says it is" and meanwhile another questions whether I'm being bankrolled because of my choice of $expensive_lawyer (I'm not).

Anyway before anyone jumps to accuse me of a power play, I don't so much care who runs the show (though I can tell you it won't be me), so long as it's not the people who claim to be today. Yesterday's vexatious irritation is pretty close to the last straw for me. One thing for sure is that "we" will find a solution, and one that's inclusive of everyone (just not necessarily in positions of their choosing).

Sam

[M. David Peterson]

On Fri, Apr 10, 2009 at 9:23 PM, tluk...@exnihilum.com <tluk...@exnihilum.com> wrote:

>> "Who should I send my 5x10 Glossy too?"

Umm.. this is going to be an international effort.. better make it a valid passport photo.

Haha! Right on... I'll get right on that ;-)