With Salesforce.com and VMware’s recent announcement of the “world’s first Enterprise Java cloud” comes another opportunity to re-assess how we build, deploy and run our Java code in the cloud. Having built both Java and Force.com (Apex) applications for many years now it’s exciting to see the two coming closer together. The ability to use Java’s Enterprise capabilities in the form of Spring Integration and Spring Batch will certainly add a whole new dimension to the way Force.com applications can be built and extended. Couple this with Salesforce.com’s upcoming Visual Process Manager and you could have a real-time business process engine, BPEL-as-a-service anyone?
So there are plenty of good reasons for looking at using VMforce especially considering the huge benefits of leveraging the Force.com infrastructure as well as Force.com’s “built-in services and components like identity and security, workflow, reporting and analytics, search, web services API, mobile device deployment, and more” but with all this power there must surely be a few caveats. A few that come to mind are:
- Limits and Quotas – If you’ve developed with Force.com you’ll know about Governor Limits, or for Google App Engine Quotas, what limits or quotas will VMforce place on your application? There will probably be the usual Force.com limits but with your Java app running on VMForce you’ll have to ensure you’re playing nicely with others.
- Running Costs – Force.com generally requires licenses to use (apart from the free edition) and no doubt VMforce will some sort of billing model (hopefully cents per hour), what will all of this cost? From one, to hundred, to a thousand users…the license plus pay-per-hour calculation may start to get complicated.
- Maintenance and Upgrades – Planned maintenance releases still need to occur on the Force.com platform which currently means occasional times where Force.com is unavailable. VMforce’s underlying SpringSource TC servers would need upgrades as well over time although it’s easy to see how they could manage this seamlessly. Hopefully this situation improves by the time VMforce is released as any unavailability can be hard to explain to users.
When VMforce does officially release, we’ll have some answers and be able to factor in these caveats into a decision, although the potential benefits should still outweigh the costs.
Interestingly SpringSource’s Cloud Foundry called themselves “The Enterprise Java Cloud” a while ago so it a bit confusing. It looks like Cloud Foundry lives at a slightly lower level of platform/infrastructure-as-a-service level than VMforce, uses MySQL as its database and has a pay-as-you-go model on top of Amazon’s Elastic Compute Cloud. Again it’s not clear what limits and costs apply with Cloud Foundry, and technically they are quite similar so a number of non-technical preferences would come into play here. More choice is generally a good thing though!
