Am I confused or can I lump together "cloud" computing with Grid computing?

In which case did Sun not "set the pace" as the first mainstream vendor offering "cloud" services to the masses : http://www.theregister.co.uk/2006/03/21/sun_fires_grid/

To me thats a comparable offering to Amazon or Googles offering or am I misunderstanding the definition of "cloud" computing?

Sun definitely did a lot of the early work, but Grid offerings tend to require specific programmatic methods that are not easy to use. Amazon basically took all the hard work of HPC and wrapped it in an API for your enjoyment.

Sun should rule the Cloud, but so far its like a phantom limb.

Sun has an open source cloud API project called Project Caroline at http://www.projectcaroline.net/ - it can be hosted by anyone, and they plan to support a variety of languages including Java and Ruby (JRuby?). It's feasible to host a Caroline system at Amazon and another on your own machines - thus using the exact same cloud API for all your deployments. Nice huh?

If I were to create a cloud service for Java it would be based on OSGi.

The Eclipse Foundation has already built what is needed to automatically build and deploy OSGi-based applications.

There are Java-based Map/Reduce frameworks and databases, Hadoop, HBase, BigData.

Someone just needs to add functionality to track/bill deployments and they got themselves a cloud service.

Dave,

I am not sure what you are getting at, I guess i came away thinking that even though you don't want to pre-announce your "stealth" start-up, you should give the reader a bigger picture of what you are getting at. It is obvious that you have something in mind that would alleviate some of the deployment and configuration problems associated with the cloud, as i assume your project is not to try and create a new programming language for the cloud. I think you should be more explicit about the concept, and not get too stressed about someone stealing the idea.

I am surprised that you think that enterprises will hold-off on mainstream application deployment in the cloud. I would think that is still up in the air. I mean it is a safe bet that with all the investment in licenses, it will take some time to move away from that model, especially as Oracle completely dominates IT enterprise spending. But the pain is there. Customers are sick of IT's complexity not matching the returns. With standardized interfaces, the cloud could mark an inflection point, and spending would just move completely in the direction of simplified deployment, whether that is Google's cloud or the customer's cloud.

I guess I hope that El Reg gives you a platform to write a couple more articles, and i think you should be explicit about the issues that are being faced by customers, not vendors. You have a decent perspective, coming from the (albeit open source) licensing middleware market, and this should help in explaining the cloud market. I would be very eager to read another article from you that really described the cloud issue, and what are the pieces that need to be addressed to get it going. I wouldn't be surprised if you found it valuable to your start-up to get some feedback from readers on your argument.

I guess what i am saying is that this is a good start, but you should really flesh this article out, and really give some full detail about what the hell you are actually trying to say. Again, you probably have funding, first-to-market advantages are over-rated, and you need feedback, so take a chance, and try and describe better what it is that your new effort is focusing on, as that will be a more compelling piece about the cloud...

Python is more than adequate.

Java is for multimedia TV isn't it, can you just imagine if someone wanted to do an entire project in Java, is it even possible? :)

You know what I think is so wrong about Java, is that it is a clunky badly designed language that ran from one position to another, claiming things that were true of many other languages, but trying to make out it was a Java thing, it just wasn't. Go4 can suck my cheesy bell end :)

A marketed language, and look at it; walking disaster and possible main candidate for the global economic meltdown. The odd thing is people not in the know just lap it up. It is a horrible dirty little thing, sucks all the joy out of coding and creates monstrosities of Frankensteinal proportion.

Cloud computing sounds great. You provision your own hardware for the baseline load and send the spikes into the cloud. Problem is, Amazon and Google don't feel like home. Businesses customize their network, their load balancers, their storage system, their OS, their DB, and their software utilities. Moving into the "cloud" means spending a lot of effort eliminating your dependencies on an environment that has been maturing for years. Assuming you get all of that done, you're faced with the same problem all over again with your data. Your data is over there; it's not available in the 2ms you've come to expect on your datacenter LAN. Do you now maintain one codebase for the generic cloud and one for your own tuned systems? The solutions to all of these cloud problems, plus the rates for renting space in the cloud, can make improving the performance of your local systems the easy alternative.

Cloud computing could fail because a generic environment isn't what businesses can use. Virtualization needs to be taken to the extreme - to the level of the entire datacenter.

You write, "The cloud is still relatively virgin territory with effectively two vendors - Amazon and Google - setting the pace and defining the way people think about it." This ignores the Force.com platform as a service (PaaS) of salesforce.com, which provides on-demand access to hundreds of applications from several hundred partner companies -- in addition to the applications built and offered by salesforce.com itself.

You also write, "deployment is defined by two approaches: virtual machine images like Amazon EC2 (known as Amazon Machine Images or AMI), and direct code deployment..." -- but Force.com defines a third model, giving developers the rapid time to market that's provided by a high-leverage API running in an environment that treats all customizations as platform metadata. This allows those customizations (data, workflows, custom logic, and user interface) to move forward transparently when the platform itself is improved. It's a difference that makes a difference: the CEO of ERP vendor CODA plc has estimated that his company saved "at least two years in elapsed time and at least 25 man-years of development time" by building its latest offering as a Force.com application.

I've spent the last several years working with Java and the last time I checked it was a language, not an OS. That said, Java is one of several excellent languages for cloud computing, not least because of the write once, run anywhere approach.

Cloud computing may, or may not, also be grid - I think these terms are getting confused. Cloud computing is simply running your (web) applications on infrastructure provided by somebody else, in essense a specialised kind of virtual hosting, while grid computing is more about maximising the usage of an existing hardware investment by deploying applications designed to run across many (non-identical) nodes is a seamless fashion. Grids do not need to be internet based or even exposed to the internet at all, although the best example of grid computing, BOINC (runs seti@home and folding@home), is.

The down side of a single language 'code and deploy' environment however is that by definition you need to be able to do everything in the language of your, ok, their, choice which in my experience is simply not possible.

If that were possible, integration and deployment of non-cloud applications would be a whole lot easier in the first place and people would be more willing to run their own systems. Java certainly goes a long way to simplifying integration but even nowI still see Java apps being stiched together with cron jobs, ad-hoc shell scripts and other tricks designed to keep costs down - and not always because it can't be done in J2EE, but also because it is cheaper and quicker to put together something else.

The advantage I see to the Amazon approach is that you essentially get a virtual server, and while that means that deployment and configuration are more involved, it also means that you have more flexibility on how to deploy and configure and the tricks you'd use in your own dedicated environment will still work.

Overall the main issue I see with putting applications in the cloud is that, for a business, web applications tend to be surrounded with secondary applications and utilities that need to interact with the online ones to support end-to-end business processes. Restricting cloud applications to a language runtime only will make it harder to achieve tight integration with the resultant danger that the technical platform starts to drive the business processes rather than the other way round.

That would be a big step backwards because it is only in in recent years that the technical restrictions of available platforms and languages stopped dictating business processes. I don't want a return to the days when I had to explain to an IT director that the business process is great but the technical platform can't support it.

I can't help thinking that you have no experience of Java in the real world. Neither do I think you can blame a programming language for the financial ills of the world unless of course you were hoping that systems would crash under load, thus preventing the trades that have sent stock markets around the world tasking a dive...

Multimedia TV is just the latest place that Java has visited. J2ME for mobile phones is probably the the most-deployed language runtime ever, and is very good at what it does. Java is also very prevelant in the data centre because its fundamental tenet of managing memory for the develop mean that it doesn't crash like C and C++ do. It is not so ideal for small web sites that don't need to scale, however, and that is where Perl, Python et al are able to outscore it and there's no harm in that at all. I run both Java and non-Java web sites and can appreciate the strengths and weaknesses of the variouslanguages.

I suggest you keep your misinformed comments for the tabloid websites, too many IT professionals use this site for you to get away with such a public display of ignorance.

In theory, Java is a very nice technology; however, theory and practice seldom align. The problem with Java is that Sun Microsystems is the sole guardian of the the technology and quite frankly, they have ineptly managed it.

Although I am not a fan of Microsoft either, at least I trust them to remain on course with commitment to a technology and an API. I do not trust Sun. My estimation is that Sun is a Microsoft "wanabee" that doesn't know how to be. Sun then ends up floundering about while trying, and this manifests itself in their technology. For months they will publish the source and API to a technology (ie: JSTD) that inspires programmers to invest effort into extending it, and when the technology begins to gain headway the project moves up their corporate bureaucracy and ends up in their legal department that has not a clue where to go with it from there. The source code becomes no longer available and thus kills projects begun by programmers who were depending on it. Control of the technology sits in corporate for about a year, the project stagnates and eventually goes no where. Everyone who made any sort of commitment to it goes no where too.

I could go on about their dropping or changing of Java APIs such that dependent software is just left in the ditch, or their poor political miss-handlings that stunted its growth from the get go.

Alas, I don't think Sun has figured out how to make a return on their Java investment. Until that is clear and you feel cozy secure in Java's future, I would treat the whole platform with caution.