I think that this is an excellent view of scalability using components known to many Java developers. Another point is the fact that everything is open source and that goes hand in hand with the community's demands.

Great!

Writing flexible code with Spring has been clearly evident in the last 5 years, but what persisted was the runtime environments (or Middleware) that had a high implementation complexity for addressing Scalability. It is exciting to see that so far as Java developers are concerned, the Middleware dissolves into the Cloud and its complexity disappears from the eyes of the developer via Spring and vSphere.
This is a great step towards paving the way for increasing efficiency of deployment and management of Java workloads at runtime.

The portability argument appeals to me. "Enhanced portability between target environments has always been a key benefit of Spring" is indeed a very true statement that could indeed prove to be very valuable in the cloud.

Erwin

Great news!

However, the above post, I am wondering how does VMForce compares to SpringSource Cloud Foundry.
I can list some differences, but it might be interesting to have a dedicated post about that.

This is a great start for java developers who want to reuse their skillset in the cloud era. But 2 questions on portability:
- Will this be stateless architecture i.e. will it restrict your app development to a certain style?
- Does it use Force.com db i.e. should we use SOQL/SOSL style in JPA queries?

If both of them are true, can we actually port spring apps running in enterprise to cloud? Or do they have to manage 2 versions?

At the outset vmforce will benefit vmware by providing their Java developers instant access to cloud services. Also vmforce will benefit salesforce.com by increasing adoption of Force.com platform among Java community. From developers perspective I believe today’s announcement is a ground breaking one that is a win-win for both salesforce.com and vmware.

However today’s announcement is short on details around business deployment scenarios and pricing models. I hope today’s announcement is just an incremental step towards a much larger strategy on open cloud infrastructure that addresses some concerns around cloud computing like security and scalability for enterprises.

Currently salesforce.com lacks support for private clouds for enterprises and only supports public clouds through its hosting services. Majority of enterprise customers will be reluctant to migrate to public clouds until concerns around security are addressed. Industry market trends point to migration towards “private/managed” clouds by enterprise customers in the next 3-5 years time-frame. I hope salesforce.com will announce products or partner with companies like vmware to fill this gap. In addition current public cloud deployments models have some limitations on scalability and performance front. While multi-tenancy is good from h/w utilization perspective, due to the inherent sharing model it is not ideal for compute intensive and complex data processing applications. Until this limitation is addressed few enterprises will be willing to migrate to public clouds.

I hope trailblazers like salesforce.com and vmware will address these limitations around public clouds soon. On a final note we seem to have a new “— as a service” acronym pop up every other day. Unless each and every one of these services is tied to “customer value proposition” we will just end up with technical jargon that only confuses the end customer.

@Rod Johnson:

Completely agree Rod! from what I have seen you have done a nice job (in contrast with GAE)of maintaining optimal portability while also integrating Spring into the Salesforce platform.

Good Work! Seems like a great deal for VMWare, Salesforce, and the the Spring Developer community!

am specifically curious about the support for Grails & GORM deployments into this new environment, do we know if there will be support for deploying Grails applications into VMforce?

What is the value proposition vs Iaas such as Amazon EC2 running on their AWS packages?

Dear @Curious,

What part of this do you not comprehend and why?

It is pretty much as you state it; the combination of the VMWare/SpringSource technology stack (most importantly for developers the Spring Framework itself) and the SalesForce.com cloud and its attendant services, API etc.

Simply stated, and grossly (and maybe erronously) oversimplifying it, this effectively means that the vast number of (Enterprise) Java developers that use the Spring Framework in order to develop applications can now (portably) take those skills (and code) onto the Salesforce.com cloud and develop new Spring based applications that incorporate Salesforce.com services.

i.e it combines the strengths of Spring with those of the Saleforce.com cloud.

It is also worthwhile noting that the subsequent announcement of the partnership between VMWare/SpringSource and Google will also allow Enterprise Spring developers to avail themselves of similar benefits from the Google AppEngine Cloud and GWT.

value proposition: VMWare & Spring Framework technologies and Salesforce.com & GAE cloud services and deployments.

I think that's about as simple as it can get, hope that helps.

Just wanted to check how the following is handled
1. What measures exist to ensure that there are no security hazards and scalability killers? Is there some kind of code review that would need to be done and issues addressed before deployment?
2. How would operations etc be counted as for governor limits enforcement? How are licenses managed?
3. Are there any restrictions in terms of using JDBC/Hibernate for the persistence tier?
4. What restrictions exist in terms of usage of Java API like spawning new threads, serial I/O, Web Services, etc

Isn't Microsoft developing something similar?