Spent the day at the SpringSource S2G forum, basically a one-day conference by Spring Source. It was a good experience for me - a good fit for things that I've got going on or am thinking about these days - and helped clarify for me what the SpringSource guys are trying to do with the proliferation of products I've complained about in the past.

In short, Spring's focus is on improving developer productivity, and to enable portability of applications. The appeal of the original Spring Framework was that it was much simpler and more productive than EJB, and Spring's architecture is designed from the ground up to let you plug in alternative implementations, whether it's the various bits of the presentation layer, persistence layer, transactions, web services, you name it. Roo and Grails are two different approaches, with different use cases, to bring the kind of productivity improvements seen in Rails and similar newcomers to the development platform scene to the Java platform.

STS is really the centrepiece of Spring's efforts to improve developer productivity, both by providing a pre-packaged set of Eclipse plugins to work with Spring applications, and also as a way to tie together the various parts of the Spring portfolio, such as Grails and Roo, and the various operations-side pieces like TC Server, Hyperic, and even the cloud platforms Spring is working on. The presenters at S2G all used STS, which was an effective way of showing how to get the best out of it and the specific technologies being demonstrated.

Rod Johnson's keynote was heavily focused on the cloud, in the wake of the recent announcement of VMforce and discussion of their cloud strategy. Johnson explained how cloud fits into Spring's strategic focus, which goes back to improving developer productivity, and portability of applications. It really does make sense for Spring to make a push into the cloud, since otherwise the Java platform will be left in the dust by Azure in the enterprise space.

The cloud, and PaaS in particular, is about making life easier for developers, and I know that I am certainly in the market for a way to move my J2EE applications into the cloud. At present, the only real option is to roll your own PaaS on top of an IaaS like EC2, which is a lot of work.

So Spring Source's Cloud Foundry, VMforce, and the other offerings that seem to be in the pipeline will really hit the spot. And they do more than just offering an Azure equivalent, but true to the Spring philosophy, they give us alternatives, whether it's different services to host on, or even the option to deploy a PaaS in our own data centre. So we'll have portability, even the capability to deploy our applications across multiple cloud providers simultaneously. I'm sure that the market for helping enterprises create private clouds will be big, even if it's not "pure" Cloud.

There were a number of other points Johnson made about Cloud that really hit the mark with me. I'm definitely keeping an eye on this space.

I've been disappointed to see otherwise switched-on technical groups, and even high-priced 'managed hosting' companies, fail to take advantage of virtualization, even as they spend (and charge) loads of money to migrate physical servers onto virtualized infrastructures such as VMWare.

Moving from an OS running directly on hardware to an OS running on software that pretends to be hardware opens amazing possibilities, akin to the shift from paper to online data management. You're replacing immutable, physical servers with data, which means you can treat your infrastructure the same way you treat any other data - you can automate it, copy it, transfer it, and basically put it at the mercy of anything you can script.

While it's disappointing to see people use virtualization to replicate the experience of hosting on immutable, physical hardware, it's truly appalling to see hosting vendors offer this as a service, and add a premium price on top. It's only more annoying when they call it 'Cloud'.

I've recently seen a tender response from a big name, international hosting provider which basically offers to provide you with a couple of dedicated hardware boxes with ESX installed on them. Reasonable, if not ideal; obviously it's more powerful to have access to a pool of hardware resources that you share with other customers, so you can flex capacity when you need to, but there are reasons why a customer might not want to go this way.

What blew my mind was the way virtual machines on these boxes would be provided. For each VM, you pay a setup fee, and a monthly management fee. These fees are in pretty much the same ballpark as what you would pay for dedicated hardware for each of these VM's. But this company also charges a very hefty fee for each physical ESX box, so you're actually paying quite a bit more for N virtual machines than you would pay for N physical servers.

On top of this, you lose the flexibility that virtualization allows. Need to spin up a new image to prototype some changes to your application configuration? Request a price, get an invoice, raise a PO, pay a setup fee, and commit to three months of paying for the new image. Need to clone a running image to debug a production bug? Similar story. Expand capacity for a few weeks to support a marketing campaign? Implement an upgrade strategy that involves cloning, upgrading, testing, then swapping the clone into production? Even after you've jumped through the budgeting and purchasing hoops, you'll need to send your 'managed' hosting vendor a change request and wait a few days for their engineers to use the virtualization management console for you to carry out each step.

I'm not a Capability Maturity Model kind of guy, but I could see the benefit of having one for virtualization, to help enterprise CIO types understand what they should be demanding from vendors. The lowest level would involve using virtualization to replicate physical hardware, and the next would introduce flexibility in managing instances, supporting the types of use cases I described above. Higher levels of maturity would be more cloud-like, particularly around self service in provisioning images, flexible capacity management, and dynamic provisioning. I see higher levels of capability moving away from Infrastructure as a Service and towards providing a development and deployment platform that abstracts the details of servers, i.e. Platform as a Service.

A virtualization CMM would be grossly abused by marketers, but something like it might provide a few clues, and stomp out the practice of hosting providers offering virtualization without the benefits.

From Richard Waters at the FT, via Nicholas Carr.

According to Microsoft research chief Rick Rashid, around 20 per cent of all the servers sold around the world each year are now being bought by a small handful of internet companies - he named Microsoft, Google, Yahoo and Amazon. That is an amazing statistic, and certainly not one I’d heard before. And this is before cloud computing has really caught on in a big way.

Of course, this figure doesn't really prove a trend, the quote above is too vague. How big is a "small handful", and is this an increased concentration over previous time periods (and what is the time period we're talking about as "now"?) The implication is yes, and it is credible from what we're told about these companies' rapidly growing data centre expansion.

I went to last night's London CloudCamp, which I enjoyed quite a bit. I'm not going to go into pontifications about cloud computing - I think it's a brilliant concept, not mature yet, and an excellent option for online service startups.

A few random notes from the Camp: