Salesforce.com’s Apex: Benioff’s Handcuffs for On Demand
When I first read of the Apex rumor, (Salesforce.com’s new “on demand programming language and platform”) over at Salesforcewatch.com, I started monitoring some of the various blogs and sites I regularly read for related news. I was hoping to find some tidbits of information that aren’t part of Salesforce.com’s marketing spiel. After Salesforce’s official Apex announcement, I found an excellent article that Dan Farber wrote about his discussion on Apex with Salesforce.com co-founder Parker Harris.
Harris discussed Apex in various contexts, defining it as a language with syntax that is a hybrid of SQL-esque style statements mixed with Java, and that the learning curve should not be a problem, allowing developers to quickly build on-demand applications. This sounds enticing and definitely has a lot of “wow factor” fluff associated with it. But once we get past all of this rhetoric, what substance are we left with? What trade-offs are we required to make? The answer is as easy as looking at the history of the industry.
As an industry, we’ve struggled hard and continue to struggle against being “held down” or “locked in”. The ramifications of requiring that an entity or development firm be veritably tied to another are massive, and quite frankly, the proposition sucks. Granted, working with a company like Salesforce.com gives a vendor exposure to a large customer base. This has an inherent value associated with it, but what about long term strategy and what about risk? Harris describes the language as new and powerful, but never mentions lock-in and limiting. We’ve reached a day in age where the advent and proposition of SOA allows use to start forgetting about implementation details and to focus on solving problems, not working around vendor lock in. We have a plethora of languages and implementation platforms that are very good at what they do, and are very open. We know Sun has promised to fully open-source Java giving the community control over much of its definition. Microsoft has published an open specification for the .NET platform and for C#, allowing developers to build new languages for a powerful platform, or build .NET implementations from scratch, such as Mono for Linux. As a whole, the industry is moving more toward interoperability and openness, where reinventing the wheel and building difficult to break proprietary locks is looked at as both silly from technological and strategic standpoints. Why then, has Salesforce.com opted to peddle proprietary nonsense as their on-demand platform and language? Because Benioff wants to handcuff vendors, preventing them from ever leaving. After all, watching AppExchange’s “application” count only go up through the blocking attrition by making it expensive to decouple your business from Salesforce.com is quite nice…
Apex, based on the description, seems like an evolution of SAP’s ABAP Objects (Advanced Business Application Programming Objects) language and NetWeaver, only evolved for on-demand and some quasi-OOP platform. While I appreciate Apex’s resemblance to Java, its still proprietary, just like ABAP and NetWeaver. While SAP touted ABAP as the end-all app development language and NetWeaver as the premiere platform for building business applications, we know full well that your general purpose technologies and languages as a whole have trumped things like NetWeaver time and time again. Granted, NetWeaver lets you use Java through some tight “hooks” to NetWeaver if you don’t want to ABAP, but your still “hooked.” NetWeaver and ABAP are not “mainstream” (how often do you see Digg/Slashdot/Red Herring articles on powerful applications or companies built on NetWeaver?). Apex presents the same proposition as NetWeaver: build your applications using Salesforce.com’s proprietary stack and you get to NOT have the flexibility of easily moving from Salesforce.com to another platform, of NOT being able to use for-sale and open source libraries in your applications, and having the pleasure of existing within Apex’s limitations. We’re in a day in age where we do not need YAPL (Yet Another Proprietary Language) or YAPP (Yet Another Proprietary Platform). I can’t imagine that Apex will be well accepted by the mainstream because of its lack of openness, flexibility, and overall stink-of-Salesforce aroma that surrounds its essence.
This makes me question Salesforce.com’s motivation. Why not embrace the many, many (and maybe one more ‘many’) well built technologies as the core implementation proposition to your vendors? Why provide something that is proprietary and less powerful, all while reinventing the wheel; according to Harris, they haven’t quite figured out debugging yet and have yet to come up with a way for vendors to build a UI because they “…need to build a pretty radical UI layer “. Excellent, I can’t wait for Apex UI Super Duper Extreme, the language for “on demand UI development”. My take on it: (1) Marc Benioff wants to keep the vendor close by making it expensive to build on and strategically unfeasible to leave the Apex platform and (2) they already have plenty of time and money invested on their own internal platform, which wasn’t originally designed for public use, and have retrofitted it to be a general purpose platform. Number (2) is very reasonable and any company would have done the same. We don’t need a specialized stack for on-demand. The power of on-demand and SaaS as a distribution model can be realized with the knowledge and technologies we have. The notion that a specialized “language” knock-off is needed to facilitate on-demand is absurd. The full power of on-demand can be provided without it, through a platform that embraces current technology.
*Gasp* Imagine if you could write an application using your existing knowledge set and a well accepted technology stack and still deliver it through a platform, on demand with oodles of multi-tenancy, single instance, high availability fun?! Nah, that could never happen…well, at least not until someone steps up to the plate…
Update: As per Mr. Joseph’s comment, I have removed the following sentence from the post:
I doubt a big Apex movement will be started on Sourceforge, seeing as how becoming a Salesforce partner developer costs more than an XBox 360
Mr. Kingsley pointed out that there is no fee for being a developer. After some research at some other sources, it is only for “certifying” the application that a vendor is required to pay a $10,000 fee.
Related Posts
Tags
Share This
You’re confusing an option for a constraint. It would be handcuffs if no other form of development was available. You can continue to use our API and build apps on your platform of choice. New features, like outbound messaging, where an event inside Salesforce can trigger an external web servicec, where built almost exclusively for developers who want to do this.
However, there are a number of developers who don’t want to do that. If you don’t want to host your code on your own server and just want us to run it, now there is an option to do so. There are also performance and stability advantages to doing that.
To correct some of the other misinformation in your post: It costs nothing to become a Salesforce.com developer. The developer edition is free. Listing the app you develop on the AppExchange directory is free.
Kingsley,
Thank you for the comment and the correction on the cost of being a developer. It only costs to certify an AppExchange application, not develop or list.
Respectfully, while Apex presents an option, it also poses a constraint for the reasons mentioned. Obviously, the fact that people can choose to build an Apex app makes it an option, so the statement is vacuous. When you say you can “build apps on your platform of choice” you automatically invalidate one of the things that Benioff highlighted many times: you don’t need hardware, or staff, etc. So while you can build on your own platform (Ruby, Java, whatever), it is a severely crippled vision when compared to the supposed promise offered by Apex.
The same performance advantages and ability to run code on platform infrastructure could still have been given to developers if Salesforce chose to build a platform on an existing technology stack.
Zoho has a service called Zoho Creator. It is an online application creator. You can create applications interactively in the GUI and it also has a scripting (query integrated) language called Deluge.
http://zohocreator.com
http://zohocreator.com/help/deluge/index.html
Hi Sinclair,
I just posted on Apex on my salesforce.com blog. Apex and the API are equal ways to develop on our platform. An Apex instruction invokes the exact same code that the SOAP API invokes, less the transport related overhead.
“you don’t need hardware, or staff, etc.” – Don’t need is not the same as can’t have. We have a great web services API, and Apex can’t do anything that the API can do. There is no crippling of anything. Just another option, which some people find convenient.
Hi Sinclair:
Per your post, and specifically “This makes me question Salesforce.com’s motivation. Why not embrace the many, many (and maybe one more ‘many’) well built technologies as the core implementation proposition to your vendors?”
The answer is simple – those technologies are not multi-tenant. Apex isn’t just a language – its the execution context to run code on demand and in multi-tenant model. You are using a software frame to analyze a web model, which I don’t think does either your argument or the model justice. (There is a presentation other related technical info avaiable here – http://www.salesforce.com/landing/apex.jsp)
IMHO, the question of openness in a Web world has nothing to with language syntax – it has to do with access. What matters is not what language you express something in, but that the app is available to others via public APIs that follow will known standards. On the consumer Web (where most of these precedents form), the examples would be things like MySpace limiting the ability to embed components in its site or the debate between photo sharing sites accessing each others APIs to allow migration. (And of course all Apex packages can be automatically made available as SOAP Web services.)
Regards,
Adam
Hi Adam,
I want to respond from the bottom up on your post. I do agree with your definition of openness and hope the post doesn’t allude to otherwise; following those standards are key to ensuring everyone’s well-being in the jungle we call the Web.
Implementation plays an important role when attempting to define a consumable Web entity because it is the first working scope for an implementing engineer. The openness comes into play when attempting to work with entities outside this scope, hence standards like SOAP. Apex’s proprietary, non standard nature would require that an implementor tightly couple itself to Salesforce. May I ask what happens if I spend a 1000 or so man hours on an Apex application, and some tens of thousands of dollars paying engineers, and after 6 months on the platform I don’t like it or am dissatisfied? Can I uproot my Apex code and plop it elsewhere? No, I cannot. I would have to port. So my options would be spend more time and money, or just deal with my dissatisfaction. Neither of these are reasonable and equate to laying down sword and shield in battle. If the platform was founded on some well accepted sub-layer, this wouldn’t be an issue.
With regards to “The answer is simple – those technologies are not multi-tenant”, well, I’m not quite sure what to make of it. Most technology stacks (Java, .NET, etc.) could be used to build a natively multi-tenant platform even though they themselves are void of the notion. For example, your statement is equivalent to saying that “.NET is not computing grid capable”. While true, it has been used to build grid computing platforms that are very, very powerful (check out http://www.alchemi.net) and don’t have a “specialized” language. So not being multi-tenant seems irrelavent based on my understanding of that benefit of Apex.
Thanks for adding to the debate, I was interested in reading your take. Take care.
I think SF’s targeting two things: more complex applications and eventually in-house deployement for big companies. More here:http://roman-rytov.typepad.com/miles/2006/10/whatwho_salesfo.html
We know that the lockin is bad for everyone(of course not the owner of the platform) and we also know that we dont need a YAPL. Is there any other platform which doesnt pose this threat? Are there atleast lesser evils?
Thanks,
Arun.PC
Hi Arun,
Thanks for commenting. Currently, the only viable alternative is to piece together custom code with various SaaS components available by providers. The problem is, this still requires a lot of effort. However, it does avoid sub-layer lock-in (no new programming languages, stacks, etc.) since some of these components use industry standard sub-layers. http://www.saasshowplace.com/ has an enablement category with some examples.
As an aside, the platform we are working on alleviates many of the issues discussed, so the best alternative is yet to come;-)
APEX & Visual Force (as the on-demand GUI has been implemented) applications DEFINITELY mean a lock-in in terms of the platform… but … what is wrong with it??
The choice of any platform implicates a lock-in, whether you decide to use .NET, PHP, Java or whatever technology … you will always lock yourself in. The fact you can swap your java machine, .NET machine or whatever infrastructure or another, does not mean you’re not locked in to the technology.
In other words: a .NET application will never run without te appropriate MS licenses….unless you consider mono an option for your business critical software (cough)