Channel Insider 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, 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 story’s 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, 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, Harris co-founded Left Coast Software, a Java consulting firm.

Apex has been compared to Java, and maybe that’s not accurate. But if not, how is Apex different? And why wouldn’t a developer just use Java?

What’s different about Apex is that it’s an on-demand programming language. By that I mean that if you’re using our sales force automation [software] you obviously can get up and running, and you don’t have to buy the hardware. The same thing is true with Apex: If you’re a developer you can start programming.

What’s different about Apex is it’s running in the database, basically (it’s actually running on application servers) … And one of the key things you can do with Apex that you can’t do with Web services is you can have transactional control of that database. …

But the other thing, in terms of a language, is it’s 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.

Click here to read more about the introduction of Apex and why customers say they are excited.

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, let’s 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 [] platform was watching this group struggling to create this quoting application and he’s 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. That’s really where Apex comes in; Apex is like the PL/SQL that we’re using to write the platform …

[Immediately] once this release is out, we’re going to start using [it] for internal projects in development as well as in our IT group. We’re going to build an e-commerce platform, like a PayPal for our partner community. It’s 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 didn’t 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. We’re 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 that’s not really our goal. Our goal is to have a platform where this [] community can actually run their businesses with these applications.

Guru Jakob Nielsen offers advice on designing applications for usability. Click here to watch the video.

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 we’re 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 they’re going to say, ‘Well, I have Java and I have this platform.’ It doesn’t mean that you can’t write Java too. You can still write code—like we’re going to release a Java tool kit to build UIs in AJAX [Asynchronous JavaScript and XML] but that works with our platform and that’s open-source JavaScript…

NetSuite has an on-demand programming language. How is Apex different?

NetSuite does have a language. My understanding is that it’s 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 you’re importing data. It’s a part of that core piece of that service—you’ve 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, it’s going to skip that [code] because you’re not using the UI. That’s a very important distinction because if you’re writing business rules, you want those rules to fire regardless of how the data’s being accessed or manipulated. There aren’t really any other multi-tenant languages out there.

Can you define what you mean by multi-tenant programming language?

Sure. So with multi-tenancy we’re using a single Oracle database and single code base that runs everybody. Actually we separate by geography. When you think about running code, we’re running code in that multi-tenancy, meaning that our application servers that service up those API requests, those Web requests, are also running code. That’s extremely important because … when I upgrade the service, I’m 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 you’re going to have issues with upgradability. You’re 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”? 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 that’s fundamental to everything we do, and that’s 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. We’ve hired one of the top people from eBay, who ran their service … Then [ is also] putting out there, to say we stand behind it and let us show you our availability and transaction numbers.

So all I can say is we’re putting the information out there and we’re proving our reliability every day. We have deep conversations with anyone who wants to talk to us about what we’re 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 don’t 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 that’s 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 [ 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. It’s when people need to collaborate in the enterprise where our value is huge. So to me it’s really database-backed applications—anywhere you’re 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 you’re doing with CRM (customer relationship management)?

They’re very complementary … If you look at how our customers use our service, they’re all using the platform. Everyone is using something differently. Deutsche Bank tied our service into their back-end systems to transfer money around. So they’re leveraging our platform to make our CRM work effectively in their company—that’s really why the platform evolved.

When we started the company we consciously said we’re not going to build a platform and then decide what we’re going to do with it. We said we’re going to build CRM applications, and then the platform evolved out of that. … We’re a CRM company and we’re going to evolve over time to be a platform company, but we’re 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 you’re 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 it’s 50 percent. So we’re 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 we’re going to keep building ourselves on Apex, and we’re 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 don’t expose something that we regret … where it makes it much more difficult for me to guarantee upgradability. We’re very careful about that. That’s why we’ve talked about this language for a long time, and it’s taken us this long to feel comfortable internally…

Then there’s 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 we’ll 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—there’s 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. It’s all about intelligent reaction. Let something out, listen, react and iterate from there.

Check out’s for the latest news, reviews and analysis in programming environments and developer tools.