Platform as a Service and Force.com

I haven’t written much about "Platform as a Service" (PaaS) up to this point but given Salesforce.com’s growing presence the buzz generated from annual user love-in, Dreamforce, this is a good time to talk about PaaS and Salesforce.  According to this article, Gartner predicts that PaaS platforms will grow from $900 million in 2011 to $2.9 billion in 2016, representing a 26.6 percent rise each year.

Although SalesForce.com (SFDC) is best known for its customer relationship management solution delivered as a service via a cloud, force.com is SFDC’s “platform as a service” offering.  By giving their customers a foundational component for sales and also providing an environment that allows customers to add on the pieces that they need while leveraging a common user interface, authentication framework, it accelerates the potential ROI to customers (and revenue streams for SFDC).  This article will review  PaaS, touch on the advantages, and then talk a little more about why PaaS at SFDC is such a powerful combination.  

What is PaaS

Let me review quickly what “platform as a service” (PaaS) is.  PaaS sits one major step up from infrastructure as a service and a step below “software as a service” (SaaS).  Take a look at the graphic to the right.  Starting with IaaS, the vendor owns things like facilities, network, computers, racking, storage, and general management to make the compute and storage factory work.  IaaS customers are responsible for everything above that line in the graphic, like operating system (windows or Linux), middleware and their application software.  PaaS, vendors provide everything within the IaaS section and additional components that  allow a customer to deploy their application code to run.  At the top of the service delivery stack is SaaS, where the vendor is responsible for the whole stack of services to deliver an application (gmail is a good example).

In a PaaS environment, customers don’t have to worry about all of the components in the IaaS layer nor do any of the components in the PaaS layer (app engines, tuning, patching).  Once deployed, many providers make it easy to quickly scale up your application with just a few button clicks.  The app engine middleware could be a generic Java platform supporting J2EE, Microsoft .Net, or a proprietary environment (like force.com).  In addition, PaaS normally supports a persistence layer (think "database") via an abstracted application programming interfaces.  PaaS providers like Amazon provide a simple way to deploy an application and easily upgrade and rollback enhancements.  For example, Amazon customers use  “Elastic Beanstalk” and upgrade their Java, PHP, Python, or .Net applications to a scalable environment without all the hassle of first setting up and configuring all the infrastructure needed to run the applications.  Scaling an application to handle millions of users is not only easy, it can be automated.  AWS also supplies monitoring, e-mail alerts and the ability to get to log files for debugging.

In addition to reaping the benefits of infrastructure as a service, PaaS customers can focus on building applications that utilize a basic service delivery platform without having to set it all up and manage that infrastructure.  PaaS customers take advantage of other reusable and scalable components much like a service oriented architecture (SOA) ecosystem.  The more reusable services available, the less a PaaS customer needs to build.  Examples include payment services, search, reporting, and authentication services.  The PaaS providers I looked at also provided high availability in the form of multi-site deployments.

One of the issues with today’s PaaS deployments is compatibility between PaaS providers.  As long as programmers are utilizing standard application stacks, and don’t use a particular vendor’s proprietary services companies can avoid most of the “lock-in”.  Staying away from proprietary service calls and APIs is going to be difficult because of the lure of the benefits when leveraging existing services rather than deploying and maintaining your own.  Examples are authentication service or payment services.  Smart developers will abstract the usage of payment systems for example in a way that would make it easy to change if need be.

Salesforce.com’s PaaS

Salesforce.com’s platform as a service is called force.com.  The advantage to companies that are existing SFDC customers is that applications built on force.com can easily leverage the existing SFDC user interface, authentication, data from Salesforce CRM, and other services like chatter.

Because force.com applications can utilize CRM data, like customer and lead data, the cost to integrate additional applications is much lower and the user interface is should be consistent. This is handy for companies that are building apps for sales people that will be using salesforce.com on a daily business anyway.  I’m guessing that force.com apps will also be able to leverage data from other SFDC properties, like work.com (social goal-setting and performance review system) and data.com.

Being able to easily integrate with SFDC Chatter is another advantage to using force.com for PaaS.  SFDC chatter is a social collaboration environment with an activity stream much like Facebook but with a twist.  Not only can users follow other users in their company and form groups, users receive notifications in chatter.  Say for example a salesperson was assigned an opportunity, a notice would show up in the user’s chatter stream.  Chatter gives Sales Reps one place to look for notifications and events that are relevant (as opposed to more email being stuffed into their mailbox).  Force.com apps can utilize chatter and place important notifications into a user’s activity stream.  For example, if a demo-hardware scheduling system was built on the force.com platform, it could notify users via chatter when the demo hardware was ready to be picked up or needed to be turned in.  

Because of the integration with existing SFDC capabilities and the ability to utilize data within the Salesforce ecosystem, a cottage industry of application creators for SFDC has emerged.  There are hundreds of applications available in the SFDC “App Exchange” with categories like sales, customer service, marketing, IT, HR, Finance, ERP and collaboration.  For example, “CloudConverter” assists customers in migrating custom application from a Lotus Notes environment to force.com, Timba surveys allows users to quickly create surveys, and TimeTrack is a time tracking tool.  

Traditionally developers who wanted to use the force.com PaaS used a proprietary application programming language called Apex.  Apex is object oriented and very Java like.  Apex includes APIs for interfacing to existing data and leveraging SFDC services, like authentication and storage. Force.com apps should scale well because they run on the same infrastructure that the core SFDC CRM application runs on.  

For mobile, SFDC is also making available a platform for mobile development called “Touch Platform”.  

My main concern with the Apex programming language is that it’s not easily portable from force.com to another provider giving me a feeling that an application is locked in to force.com.Heroku may resolve some of that as Heroku allows deployment of standard Java apps using spring, Hibernate, Tomcat and other technologies.  

Heroku is an example of a pure PaaS vendor with lots of add-ons.  Heroku currently supports Ruby, Node.js, Clojure, Java, Python, and Scala.  It’s hard to tell but from what I gather, force.com and Heroku are coming closer together which makes sense since it’s owned by SFDC and SFDC enterprise customers will be more willing to use technologies in Heroku over Apex if able.

The most likely candidates for SFDC PaaS are existing customers so the proprietary nature may not be as big a downside.  As SFDC continues to grow and offer more services to their clients, the value proposition of using force.com’s PaaS grows as well.  For pure PaaS, AWS offers the most depth of other services of companies I've encountered.

References & Related

1. Exploring Amazon’s Cloud IaaS & PaaS (Cloudrant)
2. Using Amazon’s AWS (Cloudrant)
3. A Primer on Cloud Computing (Cloudrant)
4. Challenges & Risks of Implementing Cloud Computing  (Cloudrant)
5. PaaS Promises Devops in the Cloud (Infoworld)

- Chris Claborne