November 22, 2014
 
 
RSSRSS feed

Force.com: Salesforce Moves into the Platform Business

The Platform as a Service Model

  • April 21, 2008
  • By James Turner

One of the more interesting technologies I've been exposed to in the past year is the Force.com platform. Salesforce.com, well known for their Software as a Service CRM product, has taken the expertise they've garnered delivering a high-capacity application to a global market, and used it to offer the underlying infrastructure to application developers.

If you imagine the "Platform as a Service" (PaaS) landscape as a spectrum, you have offerings like Amazon's EC2 at one end. EC2 is essentially a VM-based technology with some scalability infrastructure, but you have to roll everything else yourself, from persistence to failover. In the middle, you have products like Google's App Engine, which allow you to deploy an application with many of the underlying nuts-and-bolts concerns handled by Google, but is still essentially a deployment environment that you hand-code Python with.

Force.com is another creature entirely. The Force.com environment builds onto of the existing Salesforce.com platform, including all the base objects from the CRM application. To this you can add you own custom objects (for object, think "table"). By and large, Force.com objects look and feel like a SQL table, including foreign key relationships. Using custom objects, you can create a schema that represents your application's persistence data in the same way you would traditionally with SQL.

Once you've got your schema set up (either using a web-based UI which is slow, or an Eclipse plug-in which requires you to edit the schema in raw XML), you're ready to pretty up the CRUD screens using the Web UI, and then to add the code that will handle the business logic. You write your server-side code in Apex, which is essentially Java with some semantic sugar to allow you to embed SQL-style queries into the code.

You can hook Apex code up as triggers on database events, or attach them to web pages using VisualForce (a stripped down version of Java Server Faces.) You can also call Apex code externally, because you can trivially turn any Apex class into a collection of web server calls, with an automatically generated WSDL.

You can also consume external web services by consuming a WSDL, which generates an Apex class (much the same as you'd get from WSDL2JAVA in Java.) In addition to the stock CRUD screens Force.com produces for each object, you also get built-in (if somewhat restricted) reporting capabilities. You can also go wild and produce any web UI you want by coding in VisualForce.

Force.com is a totally hosted solution running on the same servers on which Salesforce.com runs. As a result, Salesforce has guaranteed service level agreements and performance targets. You can see the current status of the system at any time by going to trust.salesforce.com.

Sounds great, doesn't it? So what's the catch? Well, the biggest one is the 'governors'. These are restrictions placed on the code to make sure an individual application doesn't drag the shared servers to their knees. For example, you can't do more that 10 different database operations (updates, deletes, inserts, etc) in a single code invocation. This causes you to rethink a lot of traditional "lazy" database coding techniques. Rather than write:

for (Foo f: foos) {
    f.age += 1;
    update f;
}

You'd write:

for (Foo f: foos) {
    f.age += 1;
}
update foos;

This is because the first method would fail if "foos" had more than 10 elements, whereas the second only does a single database operation regardless of the length of "foos". You'd hit other limits though, there's a limit on the maximum number of rows you can operate on in a single database action as well.

Do these limits cause problems? Sure, they do. A lot of energy can be spent making your code as efficient as possible from a database perspective. You may also have to conclude that your application just isn't appropriate for deployment on Force.com. There are workarounds, such as calling one piece of Force.com from another as a web service call, which buys you a fresh set of governor limits, but you always have to have the limits in the back of your mind as you develop.

The other weakness of Force.com is the IDE. Right now, the Eclipse plug-in is primitive but rapidly improvement. There's still a lot of things you can't get into source control, such as screen layouts and internationalization. You also can't single-step or debug the code from the IDE, you're back in the days of printing statements and debug logs.

So, Force.com is essentially a decision to trade worrying about the governors and dealing with a primitive IDE, and in return get most of the infrastructure such as persistence, scalability and failover for free. In my experience, Force.com can dramatically increase development velocity, If you choose wisely which projects to apply it to. You end up mainly spending you cycles thinking about the business logic and integration with other systems, rather than the "glue" holding your application together. If you go in with your eyes open, understanding that you're locking yourself into a platform that you will not be able to easily extract yourself from, Force.com can get you up and running quickly. And because you can get a free three-user Force.com development account for the asking by going to developer.force.com, you don't need to invest a lot of time or effort getting your development environment set up, either.

Platform as a Service may not be for everyone, but with Amazon, Google and Salesforce all offering variations on the concept, it's worth your while to at least check it out and see if it might be a good fit for your next application.

Sitemap | Contact Us