My discussion about PaaS portability is centered on the portability of that server-side code, the one that responds to the data queries with JSON payloads.

Both matter in the end, though I personally have never been a big fan of running much business logic in the browser. I still live with the (maybe outdated) idea that your app should work w/ JS turned off and that any JS you use should be icing on the cake to make the experience smoother. Just like I used to always back a client-side imagemap with a server-side imagemap back in the days, for the browsers that did not support it client-side… I’m a dinosaur.

I sounds like the definition of “Portability” in the cloud is up for healthy debate

My definition here: http://www.embracingthecloud.com/2009/11/09/WriteOnceRunAnywhereInTheCloud.aspx

Java portability certainly made sense in the client-server era. I’m not so convinced it has same relevance in the cloud.

As usual, you provide an insightful analysis on the announcement. I am glad that you point out the perspective of the user regarding where the infrastructure parts and how they are combined is not really a concern for the application developers. A major philosophy of Force.com is to provide abstracted services appropriate for the application developer, not the systems developer. The goal is to enable focus on the application development tasks, rather than building the necessary infrastructure to get to where they originally want to go without being distracted on their way to building them.

Platform as a Service may come in a variety of flavors. Force.com’s focus is the business application developer. Thus, services are geared to make the necessary tasks easier and provide a built in way to obtain them. This does not prevent people from building their own user and profile management, analytics, or way of dealing with currency, localization, etc. However, should they do that? Why force the developer to write localization code when this can be provided within the platform? This is the platform’s value proposition. The more things that you need to build yourself, the more time you will need to focus on maintaining it and supporting it yourself. This is as error prone and costly as the development team grows to accommodate building these necessary services where you could get the same benefit from the platform directly.

As far as the portability question is concerned, if you look at the presentation, we always start with the “Safe Harbor” statement for future looking announcements. VMforce is going to enable application developers to develop applications utilizing standard Java APIs. The details are going to be forthcoming in the coming months and it is too early to speculate on the details. Note that SFDC typically rolls out a major new feature or extension to platform to select customers and developers in stages to get feedback which drives our platform. We are also a very agile company. We extend the scope of our features and platforms with feedback over time. Thus, it is too early to answer some of the questions in detail or debate about them. However, we are very excited that Java developers will be able to develop Java applications on our platform in the near future.

Yes and no. You’re right that if the dev and deployment tooling is done well, it could be a very nice experience that provides uniformity between private cloud deployment and force.com deployment. With two major caveats:

- use of force.com services is presumably not portable. As the smoothspan blog explains, “take advantage of all those juicy services and it will be hard to back out of that platform, Java or no Java”. And these services are a huge part of the force.com value, as Anshu’s blog illustrates.

- management: once I’ve deployed to force.com will I be able to manage the application using my favorite app mgmt tool in the same way as if it was deployed in my private cloud?

In a way, we now have three levels in the force.com portability equation:

level 1: not portable, can only run on force.com
level 2: portable to other VMWare/SpringSource environments (private cloud or other public PaaS built on the same platform)
level 3: portable to any Spring platform

It will be interesting to see how dev/deploy/mgmt tooling draws a line between level 2 and level 3.

[UPDATED: I've turned this response into a full blog entry.]

As told to me by both Salesforce.com and VMware in an interview, using this service will be very similar to an existing dev shop’s in-house VMware+ SpringSource framework; in fact, the two environments could be used side by side in a fairly seamless fashion. Developers could use VMforce.com to make apps, and bring then back in-house for line of business, or vice versa if they want to use the Force.com tools. At least, that is the promise, since it’s not going to open to the public until later this year.

These are Spring tc machines that are interacted with by the user- the Force.com integrations are add-ons brought into that, then the completed apps “published” to the Force.com portal.

I think that Salesforce has done an excellent job of fudging the announcment to give more weight Force.com involvement, and push Chatter and “Cloud 2″(blech)and what not, but from what I understand, VMforce can be used in a perfectly competent manner to do Java development without bothering with any of the Salesforce.com trinkets, should a user want to do that.

The pricing will be key, of course, in deciding whether users are coming for resources(if cheap) or for channel(if more expensive) and that’s not known yet.