Eclipse Zone is brought to you in partnership with:

Ian is the Director of Marketing for the Eclipse Foundation and live in Ottawa, Canada. Ian is a DZone MVB and is not an employee of DZone and has posted 171 posts at DZone. You can read more from them at their website. View Full User Profile

A Tools Platform for Cloud Computing

10.31.2008
| 5480 views |
  • submit to reddit

Earlier this week Tim O’Reilly published one of those famous ‘O”Reillian’ essays that I think people we reference over the years, called ‘Web 2.0 and Cloud Computing‘. O’Reilly breaks down the cloud computing landscape into three categories: 1) utility computing, 2) platform as a service, and 3) cloud based end-user applications.

In the essay, Tim discusses the importance of nurturing a developer ecosystem:

“to the extent that developers become committed to the platform, there is the possibility of the kind of developer ecosystem advantages that once accrued to Microsoft.”


and

“The key question at this level remains: are there advantages to developers in one of these platforms from other developers being on the same platform?”


For obvious reasons, I am a big believer in the power of creating a strong developer ecosystem and the key is having tools to make it easy for developers to develop and deploy applications.

At the same time, I’ve noticed a consistent trend towards Eclipse-based tooling for different clouds. For example salesforce.com just announced the release of their Eclipse-based force.com IDE, you can use Eclipse-based PyDev with Google App Engine, Aptana Cloud provides some interesting tools for cloud computing, Cloud Studio allows you to deploy OSGi apps to EC2 and even Microsoft is talking about provide Eclipse plugins for Azure. I am probably missing other examples, so feel free to leave a comment with other Eclipse based cloud tools.

This got me thinking about the possibility of creating a common tools platform for cloud computing. Imagine a platform that provides the core services for developing and deploying cloud applications. Cloud specific providers could then extend these services for their specific cloud.

Very similar to what the Eclipse Web Tools (WTP) project has done for creating Java EE applications. Eclipse WTP provides a common set of wizards and then each Java app server provides a plugin that extends WTP for their specific Java server. Or even how the embedded runtime operating system market has embraced the Eclipse CDT project as a common C/C++ IDE. Each RTOS vendor takes CDT but then extends it with platform specific plugins.

It seems like a common platform would help accelerate a cloud computing tools chain and developer ecosystem. Cloud providers would benefit from a consistent platform for their tools; instead of developing plugins for different tools providers. Cloud tool producers would benefit from leveraging core/commodity services that allow them to differentiate on value add features and potentially target multiple cloud providers. Sounds like a good strategy for a cross-industry collaboration at Eclipse.

I guess an exception to doing this at Eclipse might be that Eclipse is perceived as Java centric and Cloud Computing appears to be a lot more than Java; actually Java doesn’t seem to be front of mind for lots of the clouds. In fact, I think Eclipse support for multiple languages, like AJAX, PHP, Ruby, Python makes it an even better option for a cloud tools platform. Cloud computing is multi-language, so the cloud tools platform will have to be language agnostic.

The final questions is who would lead such a project at Eclipse. That is a good question and I don’t have a clear anwser. However, if past experience is an indicator it will probably be a cloud provider that really understand developer ecosystems or a cloud tools provider that want to have a first mover advantage.

So what do you think? Does a tools platform for cloud computing have a future?

 

From http://ianskerrett.wordpress.com 

 

Published at DZone with permission of Ian Skerrett, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)