Is force.com from Salesforce replacing five layers of tech that startups struggle with?

I was responsible for development of a Patient Relationship Management system on SalesForce. A decision to use SalesForce as the development platform can kill a company for several reasons: 1) SalesForce may arbitrarily refuse to "approve" the required security review for the application, or may take many months to complete the security review (you can't sell your product until you pass review) 2) SalesForce is a giant monolith of proprietary technology, 3) it is is "org"-based (like having closed, on-premise systems in the cloud) - "orgs" don't play well with other "orgs", 4) you are limited to whatever their platform supports which can be extremely limiting depending upon what you are trying to do, 5) difficulty integrating with other systems (or if you do forget about the security review!) Today there are more modern, well-accepted technology stacks hosted platforms like AWS, Joyent, Heroku, etc. which provide many of the benefits of the SalesForce platform without the many disadvantages serious drawbacks which at best may cripple your development efforts and at worst will kill your product before it even gets started. And it is very expensive. SalesForce sales people are ruthless and you are totally at their mercy

John you absolutely CAN run a Tomcat app on an Apache deployment in an Azure VM.  But then you have to manage the Apache server.  and if you create an AMI of Starter.com on AWS you cannot just re-deploy that AMI into Azure VMs.  You have to do as the MSFT documentation says -


create a virtual machine that has a JDK already installed.remotely log in to your virtual machine.install a Java application server on your virtual machine.create an endpoint for your virtual machine.open a port in the firewall for your application server.

This is the point about the tradeoff being management of a server stack.  The same applies to MySQL instances - you have to instantiate and manage the server. 

So you can move your app to various instances but you are creating new VMs as you go.  That's not really smooth migration.

as you point out, the only way you can do this is by avoiding any of the Service based APIs.  This does give you migrability but it also imposes a fairly high NIH opEx cost.    For example because we opted to deeply integrate with Azure - since MSFT is about as likely to go away as Amazon or Google - my SQL management consists of a weekly autoscheduled set of scripts being run to update the internal table statistics and checking the security logs for any attack threats and to make sure we are still well within our autoscale parameters.  This takes all of 5 minutes

my backup is automatic geo-distributed to the other side of the country into an offline store (to minimize hack attacks).    So my net OpEx costs for managing my database are much lower than yours I suspect.

And I absolutely agree with you that this balance between OpEx, future roadmaps, and portability and ITS associated costs is very much the role of the CTO.

My approach is different than yours.   I have seen wave after wave of technology sweep by - and platform independence has always come at both a functional, development, and opEx cost that I have rarely seen justified vs the cost savings of integrating with a major platform.    The best examples of this I can give you is the number of folks who did very well by betting on Windows and then iPhones, vs those trying to build to "write once run anywhere" code bases..

But that's a CTO's judgement call.  And our jobs and our bonuses and our compensation ride on this.  I have nothing against OSS - we use it where it saves us money - but I personally avoid the fear of Vendor Lockin.  Its only been an issue when your vendor is highly custom,  when its as broad a platform as Facebook - its actually rather costly NOT to leverage the connectivity.

This is also where Enterprise Architecture principles come into play (something I've written more than half a dozen whitepapers on).   The key to EA is to look at both your Business Goals and roadmaps  and the technology implementations and roadmaps that are being used to act on those business goals and roadmaps.   And to proactively identify where future divergences might occur and to plan for them. 

But its important to include in that, the costs of what that divergence might impose vs. the costs you incur currently by preparing for an unknown set of divergences that may never happen

In reply to Karl Schulmeister, I have had no problems running Starter Ignite on AWS, and since you can host a Tomcat App on Azure I don't get the "quite clearly will not work on Azure VM" comment.

Windows Azure PaaS has been around for years.  It offers all of these in a vetted form.

Our solution https://ClearRoadmap.com  runs 100% on Azure....  We do not manage ANY VM images.  none.   We use a PaaS compute instances, blob and SQL store, LDAP, Authentication, GraphAPi, Connectivity and sendmail integrated via the Marketplace SaaS interface

Two words: Vendor Lockin

I think pretty much no startup uses the "old model." Also, I seriously doubt that any startup would buy into force.com unless they were committed to salesforce.com add-ons. This is precisely why salesforce.com bought Heroku.

+Vijay Goel. It is about PaaS in general, but using Force.com as the most prominent example.
I am not pitching Force.com. We found it was too expensive to use for our SMB customers. Though the pricing works better for Enterprise.
We do use salesforce.com as our CRM (not Force.com), and as part of our solutions we integrate with salesforce.com ( also MS Dynamics CRM and SugarCRM).

+Michael Brill.  I see Force.com as a very good platform for some specific scenarios. If you are targeting mid-to-large enterprises and you dont have a strong go-to-market strategy. Force.com will reduce dev time and increase quality as well as take you to market rapidly.  But i would also seriously consider +Richard Vann's comments above. There is much good and bad in these decisions.

Is your comment generally on PAAS or on the Force platform specifically?