You are currently browsing the category archive for the ‘VMForce’ category.
Krishnan Subramanian and Ben Kepes have just delivered a needed update on the state of cloud warfare, focusing especially on recent moves by Heroku (where I was earlier today). Krish of CloudAve breaks down the contenders into three main groups:
Traditional (Heroku) Server like a repository. You push. Everything just works.
Packaged (Amazon). Push, but exposed IaaS layer.
Federated (VMWare). Network of clouds, customization in side.
Krish expects federated servers to win out. Although he doesn’t pick any winners, he says Cloud Foundry/VMWare is the front runner at the moment. Folks like Heroku aren’t apparently not competitive for big enterprise apps.
Ben Kepes suggest the division is more like this:
Infrastructure PaaS (Heroku, Amazon). Caters to developers used to working with infrastructure. Customization where you need it.
Application PaaS (Force.com). Just get to the app! Fully managed infrastructure.
He also suggests that these are fairly separate arenas and are diverging.
First of all, I’m more on the Ben Kepes side of things. Basically, how you manage your PaaS offering (hopefully well!) is a distinct issue to how it appears to the world. Architectural decisions are not features. Choosing to expose certain aspects to your users or provide for certain technologies and not others is. However, diversification is frequently not a winning strategy if it ends up with feature bloat — too many features requiring maintenance without necessarily meeting the needs of paying users. What do the users want? I’d guess the main aspects are the following: ease of use, scalability, features, price. The fact that different market segments will weight different aspects differently is a good reason why despite a crowded market there will probably be a lot of contenders for quite some time.
Second, it is worth noting who is not mentioned. Microsoft is still here (albeit not a front runner), but Google and other Ruby cloud folks (Engine Yard) are not highlighted at all. Yikes!
Third, it is worth noting the challenge of the “enterprise,” which most likely still hasn’t moved much if any of its core services into the cloud. Yes, Salesforce is “enterprisy,” but apps are usually extensions of its core CRM functionality, not fully featured “standalone” apps. Who will service them? I think that is still to be determined, and I wouldn’t write off any of the main contenders just yet.
I’ve been bothered for awhile that when you search for advantages for developing on the Force.com Platform one of the first Google results is a thread on a forum listing many perceived disadvantages from a development perspective. Even worse, because of the rapid development of the platform many of the disadvantages listed are no longer correct. In this post I will discuss both advantages and disadvantages relating to development on the Force.com platform.
(1) Quick access to Salesforce’s existing 82,400 company user base ( which has money to spend ) through the AppExchange (only a $300 listing fee).
(2) Piggy back off Salesforce’s powerful existing functionality, including:
– User management and authentication
– Administrative interface
– Reporting and analytics
– Dynamic API
– Toolkits and integrations for other languages and platforms
(3) PaaS offering allows you not to worry about server maintenance or architecture
(4) Governor limits and test code coverage enforce some degree of best practice
(5) Security, both because of code review and because of high degree of control on the platform (see #2)
(6) Java-like syntax speeds learning curve for new developers
(7) Native “Visualforce” elements allow quick and easy information output
(8) Active community. Lots of information out there and active participation from Salesforce staff
(9) Object metadata can be leveraged for powerful functionality
(10) Actively under development (Big things underway with VMForce).
(1) APEX is not a fully featured language
-Lots of things you might wish were there aren’t
– You will have to port them yourself or make outbound webservice calls
(2) Hard to know if you will really make money
– Hard to impossible to find revenue numbers for the AppExchange
– Per-user licensing creates a pretty linear margin on license fees (as opposed to potentially exponential on a metered system like GAE or EC2).
– Data based pricing makes it pricy for folks with lots of data
(3) Debugging can be extraordinarily slow:
– No real debugger
– Places where you don’t even have a debug log (not enabled, in a managed package, reached the limit, or weird errors that don’t leave an entry).
– Unfixed bugs or quirks on the platform that you wouldn’t expect (i.e. undocumented differences between commandLink and commandButton).
(4) Ideaexchange and other reporting tools tend to be admin focused
and geared towards new features, not fixes or better developer tools
(5) Governor limits sometimes make sense, but at other times they can be very difficult and prevent what would be best practice. Very easy to get in a place where you are trapped by a governor limit and very hard to know ahead of time whether or not any given practice you will take there (unless you already have a lot of time playing “dodge the governor limit” ). These are doubly a problem when it comes to test coverage.
(6) Developer tools continue to be somewhat lacking (even though the Force.com IDE runs in Eclipse you can’t use many of the Java focused extensions and build time is slow).
(1) WRONG: There is no namespacing or packaging.
RIGHT: Namespace and packaging exist but are controlled via metadata (and unfortunately do not allow different folders in the Force.com IDE default view).
(2) WRONG: Security model is restrictive
RIGHT: A restrictive security model can be a robust security model. There are layers of complexity and in this case complexity equals customizability and power.
(3) WRONG: Difficult to convert SObjects to JSONObjects
RIGHT: JSONObject implementation makes this fairly simple.
(4) WRONG: Governor limits are terrible
RIGHT: Governor limits makes sense given the Force.com architecture (although they can be limiting and frustrating at times)
(5) WRONG: Support is poor
RIGHT: It is not realistic to expect excellent free developer support and if you want developer-focused support you should be willing to pay for the Premier offering.
Don’t try to develop an enterprise app of significant size or scope on the platform. Even if the OEM pricing looks attractive, there is a good chance you will end up sinking ever deeper in a quagmire of multiplying unexplained buggy behavior and insurmountable governor limits (note: this recommendation may change with VMForce).
Part of the necessity here is understanding where PaaS is today, and the reality is that while PaaS as a service beyond IaaS, while developing rapidly, is not yet a platform ready for development of large enterprise ready apps. It is fine for extensions of existing technology, but be wary if you try for much more than this. This does not reflect poorly on Salesforce.com as they have been pushing the envelope on what is possible with all the force available to them. There are at the moment very many useful and potentially profitable things that can be done with the platform and if you have the time and resources, I strongly suggest doing them (or at least getting your feet wet while waiting for things to develop further).
My informal querying of Force.com developers reveals that with VMForce there are currently more questions than answers. While Salesforce sought immediately to dispel some of the questions that Visualforce/APEX would be left behind, in the fast paced sink or swim world of internet technology, a couple people on a dingy with paddles will soon be overtaken by those with the first available on-board motor.
Which raises the question of just who Salesforce is competing with. Is Salesforce, as the Appirians suggest, simply providing a gilded road into their cloud by allowing greater compatibility with legacy JAVA apps and providing “even hesitant enterprise CIOs” with a place to start? Or is it, as suggested on Javaworld, “an audacious jump to get Salesforce.com away from its ERP roots and into the general-interest cloud territory being staked out by Google and Amazon” ? Perhaps ZDNet has the best discussion of the issues: if Salesforce is truly “embracing the cloud” here, then they “pragmatically trades scalability of a unitary architecture for scalability through a virtualized one,” it also “morphs into a different creature.”
But even here it is not clear what new creature this is (see image). Salesforce can no longer simply compete with Oracle business applications, can it realistically think to match Amazon or Google to be a leader in a PaaS (Platform as Service) race? While it is one thing to take potshots at Microsoft’s failures in this regard (something I’d be all to happy to do myself), it seems clear that Microsoft will not be leading this pack.
While Mike Leach may be right to say that taking a step back may not be such a bad thing, Wes Nolte correctly summarizes the relative strengths of Google’s Web Toolkit in what one might consider Salesforce’s core area of strength and Force201 questions whether or not the 5x statistic regarding development speed holds for more than very short projects. Moreover, it’s been bandied about in various places that the primary venues for soliciting input about changes to Force.com, such as the Salesforce Idea Exchange, respond more closely to the needs of users and admins (who outnumber developers).
How can Salesforce emerge the heavyweight champion in the battle for the Enterprise cloud? I’d recommend the following:
(1) Articulate more clearly the gameplan to the developer community
Mike Leach has a great set of questions which I look forward to seeing the answers to.
(2) Develop a clear resource based pricing model to accompany VMForce, with decreased costs as bandwidth increases
As Wes Nolte also notes, the obvious answer for developers working off of PaaS is resource based pricing, which is clear and transparent in the case of Google and Amazon, but a bit murkier in the case of Salesforce.
(3) Improve developer tools
I’m 110% behind everything articulated by Wes in this article. Number 1 bugaboo: things are slow.
(4) Work off of existing Salesforce strengths
Tight integration between the code/platform and security are musts for many use cases.
(5) Leverage Chatter
Chatter is great, but could be better if, as I articulated at Cloudforce NYC last month, the benefits of social media technology for the enterprise were better articulated. Just how exactly do these technologies improve productivity? While we’re at it, why not extend the Chatter Dev Zone to include formal processes for developer feedback and/or bug tracking?