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: salesforce.com apex