eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
SAN FRANCISCO—At its annual Dreamforce conference here, Salesforce.com unveiled a new on-demand programming language and platform called Apex. While eWEEK had previously pieced together information about Apex from conversations with customers and analysts, at the time of storys publication at midnight on Oct. 8 there were still some holes to fill regarding the specifics of the language itself. Parker Harris, co-founder and executive vice president of Technology for Salesforce.com, sat down with eWEEK Senior Writer Renee Boucher Ferguson to discuss the details around Apex. It turns out Apex suits Harris background quite well. Prior to his gig at Salesforce.com, Harris co-founded Left Coast Software, a Java consulting firm.
Apex has been compared to Java, and maybe thats not accurate. But if not, how is Apex different? And why wouldnt a developer just use Java?
Whats different about Apex is that its an on-demand programming language. By that I mean that if youre using our sales force automation [software] you obviously can get up and running, and you dont have to buy the hardware. The same thing is true with Apex: If youre a developer you can start programming.
Whats different about Apex is its running in the database, basically (its actually running on application servers) … And one of the key things you can do with Apex that you cant do with Web services is you can have transactional control of that database. …
But the other thing, in terms of a language, is its really, really easy to use to write the logic, the business logic that needs to happen within the service… You can create these really complex applications really quickly.
How did Apex come about?
Let me tell you a story about why we created this. We really created it for ourselves. The innovation happened because we chose to build PRM [partner relationship management] on our platform, in order to push the platform forward internally. … Then we said, OK, lets build quoting. We tried and we started hitting these obstacles that were very difficult to overcome just using the API. One of those was the transactional control. … One of our architects who writes the [Salesforce.com] platform was watching this group struggling to create this quoting application and hes like, This is crazy. So this architect started to innovate…
We write internally using Java and PL SQL. So we thought if we were going to write our applications on our service we need some similar model. Thats really where Apex comes in; Apex is like the PL/SQL that were using to write the platform …
[Immediately] once this release is out, were going to start using [it] for internal projects in development as well as in our IT group. Were going to build an e-commerce platform, like a PayPal for our partner community. Its going to be completely on our platform—all custom objects, Apex code—and our developers are on fire…
Is your goal to compete against all those major programming languages that are out there?
When we started the company we initially didnt start out to compete against Siebel. We started at the low end and did a low-end service. And it evolved. We did go after low and it grew up. Were not trying to create a platform and go head-to-head with Oracle, or head-to-head with BEA. … It may evolve over time to compete against these other vendors, but thats not really our goal. Our goal is to have a platform where this [Salesforce.com] community can actually run their businesses with these applications.
Is Apex targeted primarily at Salesforce customers, or do you plan to go out to all developers?
We definitely plan to go to all developers and were going to form a group internally to focus on the developer community, to focus on developer evangelism, to get people to understand what [Apex] is. Developers are going to look at it and theyre going to say, Well, I have Java and I have this platform. It doesnt mean that you cant write Java too. You can still write code—like were going to release a Java tool kit to build UIs in AJAX [Asynchronous JavaScript and XML] but that works with our platform and thats open-source JavaScript…
NetSuite has an on-demand programming language. How is Apex different?
NetSuite does have a language. My understanding is that its a client-side language, so you can write JavaScript with their platform. The main thing about Apex is I can write code and that code will run whether you are coming through a Web interface, or the API or youre importing data. Its a part of that core piece of that service—youve added it into the kernel of the service. So however you use the service that same code will run. If I wrote it in client-side JavaScript, it will only run if I am using that user interface. If I use the API, its going to skip that [code] because youre not using the UI. Thats a very important distinction because if youre writing business rules, you want those rules to fire regardless of how the datas being accessed or manipulated. There arent really any other multi-tenant languages out there.
Can you define what you mean by multi-tenant programming language?
Sure. So with multi-tenancy were using a single Oracle database and single code base that runs everybody. Actually we separate by geography. When you think about running code, were running code in that multi-tenancy, meaning that our application servers that service up those API requests, those Web requests, are also running code. Thats extremely important because … when I upgrade the service, Im upgrading the underlying pieces of the service. So everything is supported—the API, the Web request and your code.
Single-tenant hosts codes for you, but youre going to have issues with upgradability. Youre not going to get all the benefits [of multi-tenancy]. When I say multi-tenant what that really means is I accept all the burden of worrying about everything for you. I accept the burden of worrying [that your code] is scalable, secure and upgradable.
Next Page: Could Apex be used to replace “almost everything”?
Could Apex Be Used
to Replace Almost Everything?”>
Salesforce.com had some uptime issues in 2005 that seem to be settled now. But if, as a developer, I am going to rely on you for a hosted infrastructure, why should I not be concerned that there are going to be more uptime issues, particularly with more weight on you as a platform provider?
Obviously thats fundamental to everything we do, and thats why issues earlier in the year were so important for me to address very quickly. If I look at what happened, we moved into a new data center and we were tuning, and then we were scaling off some vertically scaled equipment down to smaller computers and separating things out, and breaking up one of the databases.
A bunch of things have happened since then. Weve hired one of the top people from eBay, who ran their service … Then [Salesforce.com is also] putting Trust.Salesforce.com out there, to say we stand behind it and let us show you our availability and transaction numbers.
So all I can say is were putting the information out there and were proving our reliability every day. We have deep conversations with anyone who wants to talk to us about what were doing to ensure availability going forward, and reliability and scalability.
I think the numbers and the track record stand on their own. And we can certainly explain the issues at the beginning of the year and I dont see them ever happening again. I think the team we have in place can be put against any other team … And we keep getting stronger.
I spoke with a customer yesterday and asked him what he thought he would replace using Apex. He said spreadsheets, access databases and, down the line, homegrown applications. What is your vision of what people will replace in the enterprise with Apex?
I think they could replace almost everything. And thats a big statement. ERP applications, while you could build them on our platform, will probably be the last to go. We use Oracle financials, others use SAP (there are only a few out there), but [Salesforce.com Chief Financial Officer] Steve Cakebread is not going to jump on the next brand-new shiny penny for running our financials as a public company.
That being said, there are tons of spreadsheets flying around in e-mail. Its when people need to collaborate in the enterprise where our value is huge. So to me its really database-backed applications—anywhere youre tracking information and you need that collaboration—those will be the first to go and the easiest to replace.
Is there a point where being a platform company eclipses what youre doing with CRM (customer relationship management)?
Theyre very complementary … If you look at how our customers use our service, theyre all using the platform. Everyone is using something differently. Deutsche Bank tied our service into their back-end systems to transfer money around. So theyre leveraging our platform to make our CRM work effectively in their company—thats really why the platform evolved.
When we started the company we consciously said were not going to build a platform and then decide what were going to do with it. We said were going to build CRM applications, and then the platform evolved out of that. … Were a CRM company and were going to evolve over time to be a platform company, but were not going to leave our customers behind in the process.
So what does that mean, to evolve over time? Is there a point where you say youre not really focusing on applications anymore?
What it means is that next year, 25 percent of my developers are going to build our applications on our platform. And the following year maybe its 50 percent. So were going to continue to create great applications because we want to prove the platform and we want to have people use those applications and be useful. What it means is were going to keep building ourselves on Apex, and were going to keep pushing that platform forward. And the solutions out there will proliferate.
Are there any challenges to this whole platform play?
There are huge challenges. Scalability is a huge challenge. And making sure we dont expose something that we regret … where it makes it much more difficult for me to guarantee upgradability. Were very careful about that. Thats why weve talked about this language for a long time, and its taken us this long to feel comfortable internally…
Then theres a whole bunch of tactical things, like we have to build developer tools, we have to expose APIs so other people can build tools [and] then there are debuggers … Those are huge challenges, so well be careful about how we evolve it … we have to let this out and see what happens with it.
When we let out Web integration links, which are contact-sensitive links—those are very simple technologies—theres not much going on there, but people took those and did wild things with them, things we never expected. When we let Apex out there, what are people going to do? I want to see what they do and start to evolve when I see that. Its all about intelligent reaction. Let something out, listen, react and iterate from there.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.