Salesforce.com, Apex and Web 2.0 vendor lock-in

There’s a debate under way about whether the new Apex language from Salesforce.com represents a vendor lock-in. Sinclair Schuller says it does; David Berlind says mostly not. Berlind argues that the lock-in is mitigated since you are not forced to use Apex, but can use the same functionality via SOAP web services. I recently wrote a comment on the same topic for IT Week.

I have mixed feelings on the subject because Apex is such a great idea. To write code that runs on a web server today, you have to go through a procedure that starts with learning a language, whether PHP or Java or C# or Ruby or Perl, along with some kind of web framework. Then you have to figure out how to test and deploy your code to a web server, hopefully giving some consideration to security issues along the way.

With Apex, the process is simplified. Instead of writing an app offline and then working out how to deploy it, you can write the code within a web form and deploy it by clicking a button. If Salesforce.com has done it right, the security risks are much less than with a conventional web app. By the way, you would normally work on a test copy of your live application so you do not have to inflict your buggy work-in-progress on your users. Salesforce.com handles all the difficult choices about which app server to use, and keeping it patched and up-to-date.

It’s possible that Apex and technologies like it may do for web app development what blogging software has done for web content authoring, opening it up to a larger community, and improving productivity for existing skilled professionals.

Although Apex calls the same internal APIs that are exposed through web services, it has the potential for much better performance. Consider the scenario where you want to loop through 100,000 records in code. Doing that with web services will take an age; in fact, that sort of operation is not what web services are designed for. Apex can do it though. The implication is that although you can choose between Apex or Web services, the Web Services choice will not always be viable. Another factor, as I understand it, is that Apex code can be triggered by server-side events, functionality which cannot be replicated through the web services API. The choice which Berlind notes may not be so free after all.

Is Apex lock-in? I think it is. Build your app in Apex, which is a proprietary language, and you will not be able to take it elsewhere without considerable pain and of course porting the code.

That doesn’t make it bad. The industry lives with vendor lock-in. It may still be worth it.

At the same time, this is surely the primary question you have to ask before embarking on a major Salesforce.com deployment. Do you trust Salesforce.com to keep its subscription charges reasonable, its servers running satisfactorily, its technology competitive, now and for the forseeable future? A competitive advantage could transmute into a significant disadvantage if Salesforce.com were to run into problems.

Tags:

3 thoughts on “Salesforce.com, Apex and Web 2.0 vendor lock-in”

  1. Tim,
    You raise some very good points in general about the state of the SaaS enablement (platforms) market. Vendor lock-in is an issue, but it’s not the only issue – as ALL platform providers will have to answer the question from vendors: “What if things change? What’s my exit strategy? Can I even have an exit strategy?”

    When confronted about the lock-in issue with the Apex implementation, the mitigating factors provided by Sf constitute dilution of the need for a platform in the first place. Individual apps can talk to each other via SOAP web services, there’s nothing special or new about that… so, what is Apex then if you’re not utilizing its internals?

    That said, Apex might represent the ‘best yet’ of SaaS platforms. But given that it’s a Spring 07 rollout… there may be one or more better alternatives available by then.

    In any case, thanks for the insightful writing on the topic.

    Cheers, Matt

  2. dont know if you got a trackback

    Thanks – I’ve disabled trackbacks for the moment as I’m not convinced the spam problem is sorted (I had masses of trackback spam on my old blog until I disabled it).

    Tim

Comments are closed.