The Java cloud? VMforce – Quick Analysis

The new thing is that force.com now supports an additional runtime, in addition to Apex. That new runtime uses the Java language, with the constraint that it is used via the Spring framework. Which is familiar territory to many developers. That’s it. That’s the VMforce announcement for all practical purposes from a user’s perspective.
–William Vambenepe, Cloud Philosopher-at-Large, Oracle

Later this year, Salesforce will have an additional, more pure-Java friendly way to deliver applications in their cloud. The details of pricing and packaging are to be ironed out and announced later, so there’s no accounting for that. Presumably, it will be cheap-ish, esp. compared to some list price WebSphere install run on-prem with high-end hardware, storage, networking, and death-by-nines ITSM.

For developers, etc.

The key attributes from developers are the ability to use Java instead of Salesforce’s custom APEX language, access to Salesforce’s services, and easier integration and access to the Salesforce customer base.

Spring

Partnering with VMWare to use Spring is an excellent move. It brings in not only the Spring Framework, but the use of Tomcat and one of the strongest actors in the Java world at the moment. There’s still a feel of proprietariness, less than “pure” Java to the platform in the same way that Google AppEngine doesn’t feel exactly the same as an anything goes Java Virtual Machine. You can’t bring your own database, for example, and one wonders what other kinds of restrictions there would be with respect to brining any Java library you wanted – like a Java based database, web server, etc. But, we soothe our tinkering inner-gnome that, perhaps, there are trade-offs to be made, and they may be worth it.

(Indeed, in my recent talks on cloud computing for developers I try to suggest that the simplicity a PaaS brings might be worth it if it speeds up development, allowing you to deliver features more frequently and with less ongoing admin hassle to your users.)

Tools, finishing them out

The attention given to the development tool-chain is impressive and should be a good reference point for others in this area. Heroku is increasingly heralded as a good way of doing cloud development, and key to their setup is a tight integration – like, really tight – between development, deployment, and production. The Heroku way (seems to) shoot simplicity through all that, which makes looks to make it possible. The “dev/ops” shift is a big one to make – like from going to Waterfall to Agile – but so far signs show that it’s not just cowboy-coder-crap.

Throw in some VMforce integration with github and jam in some SaaS helpdesk (hello, Salesforce!), configuration management, and cloud-based dev/test labs…and you’re starting to warm the place up, addressing the “85 percent of [IT] budget just keeping the lights on” that Salesforce’s Anshu Sharma wags a finger at.

PaaS as a plugin framework, keeping partners alive

“In theory what it means for Java developers is that there’s sort of a ready marketplace community for them to develop their applications,” said RedMonk analyst Michael Cote. “Because there is that tighter integration between the Salesforce application and ecosystem, it kind of helps accelerate the market for these [applications].”

Many PaaSes are shaking out to be the new way to write plugins for an existing, large install-base. Of course, Salesfoce will protect its core revenue stream, and without any anti-trust action against Apple, the sky’s the limit when it comes to using fine print to compete on your own platform by shutting out “plugins” (or “apps”) you see as too competitive. That’s always a risk for a PaaS users, but I suspect a manageable one here and in many cases.

Intuit’s Partner Platform is another example of PaaS-as-Plugin, and I think such setups are good all around. As with the Apple App Store, the owner of the PaaS takes a cut, fee, or both, to give developers access to the ready-to-buy channel of users. Microsoft’s platform, Azure, doesn’t seem to fit this mold, but you can see where folks like IBM would take their Live product lines (Lotus and Tivoli) and slap PaaSes on the backend to build out partnering ecosystems.

There’s your “cloud destroys the partner ecosystem” problem solved. Partners just have to learn new tricks, but that’s always been the case.