Perspectives on Salesforce.com

The Amazon.com’s Web Services team just announced SimpleDB. This is the newest of their many web services. This is essentially a database in the cloud and sounds very compelling.

What’s very cool about it is that Amazon is eliminating the need to manually manage a schema, allowing developers to manage it through their logic, while Amazon maintains the schema for you on the fly. For example, if you are creating a Customer record, you don’t need to define a City field that’s 50 characters in length and of type text. You just create your record with a bunch of attributes and it happens for you. Amazon will use the existing attribute if it’s used it before. If not, it will create those columns for you on your Customer object. It then indexes all of it for you for easy searching.

The pricing model is pay for what you use and, like their other web services, you have real-time visibility into what you are using and how much you owe them. All in all, it’s quite inexpensive for what you get.

I don’t see this service competing with Salesforce yet, but could compete with Salesforce (Force.com) as an infastructure platform for development in the future. Salesforce is a much more complete package with the UI components all there for you. Amazon’s web services are very raw (it’s just an API) and they rely on the business community to build tools that allow other businesses to develop on the platform. Initially, I see it competing with someone running a MySQL server on their domain. Amazon now has 3 very good web services for the developer: Amazon S3 for file/object storage, Amazon ECC for having virtual server(s), and now SimpleDB for storing more structured data. Using these, you could essentially eliminate a lot of what a web host does and use these services in the cloud and only pay for what you use. Very compelling in principle.

Where I feel that Salesforce could take a page out of Amazon’s book is the pay-for-what-you-use model. As a AppExchange application provider, I oftentimes need a back-end that is not the end customer’s Salesforce org. For example, with Arrowpointe Maps, I use the Salesforce org of the customer as the home for their business data and it’s nice I don’t need to store that anyplace else. However, I also have a MySQL database that houses a lot of the configuration information. I would love to use my Salesforce Org as this back-end. Everything is there for me to do it except that API rate limiting exists and I cannot risk having that limit hit if I am trying to service my customers. MySQL rocks for my purposes, but for future needs like this, I will be looking to Amazon SimpleDb as an option, but I would love to look to Salesforce for this.

Salesforce really needs a pricing scheme that supports an application using Salesforce as THE back-end database. This would be a model with unlimited (or pay-for-what-you-use) API access and a small number of web logins. The web logins would really be used to administer application data, build a schema, configure workflow, etc. 99% of activity would be via the API. It’s essentially the Platform Edition capabilities costed on an API basis rather than a user-basis and without any (or threats of) API rate limiting.