PaaS · Startups

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

Gopi Mattel General Partner. Lifeboat Ventures

March 1st, 2015

As a tech startup just a few years ago, you needed to deal various layers in the development stack: data center, hardware, connectivity, security, operating system, database, language to build an application that can be delivered over the web.

You needed the tech expertise and attendant problems, resources, money and tiime to make this happen, including operations staff.

Today you can replace all of that from In addition you can get a solid installed base to market to.

My question: have startups switched to considering such platforms rather than the old model?

Richard Vann Founder at Cloud Haven

March 1st, 2015

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

Michael Brill Technology startup exec focused on AI-driven products

March 3rd, 2015

We're heading back to a world of vendor lock-in whether we like it or not. Let's say you went all-in with AWS ( and then you want to switch providers. Good luck. And with higher and higher level services (e.g., machine learning, cognitive computing), you're going to have to pick your poison or be at a competitive disadvantage because you have to cobble together your own bits.

Karl Schulmeisters Founder ExStreamVR

March 5th, 2015

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 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 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

Anil Sharma Founder at

March 1st, 2015

As Michael said, unless you are building something around services, consider a platform based on open technology stack.  In PaaS world, consider Heroku (Saleforce) or Cloud Foundry (IBM/ Pivotal). It is not uncommon to assemble your own managed package for cloud. I can comment on a Java based stack, use mysql/ postgres for RDBM, Cassandra for NoSQL, Spring/ Tomcat for web+app tier. For a WEB UI, Query, Backbone, Bootstrap for UI (which you will have to use irrespective of PaaS or own stack). Heroku is a better choice if you want to stick to Ruby, PHP or Scala. Cloud Foundry is as complicated as assembling your own stack. Using your own stack gives a choice of running on a cheaper IaaS (linode, digital ocean). Use Nginx for web server.

John McMahon CEO at Starter Inc.

March 3rd, 2015

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.

What, specifically makes it clearly not suitable for Azure or VM?  Of course it's a Java app, so it's not inclined to run happily on a .NET platform, but then what would the point be in running on .NET, if portability and lack of lock-in is a goal?

So, in fact Starter is running on AWS right now for that matter. I'm also running it under eclipse on Mac OS X locally, and as a linux instance on ... Currently other than S3 for files, nothing really AWS proprietary being used -- it is using RDS which is MySQL, the auto-scaling and load balancing Elastic Beanstalk are nothing that cannot be replicated elsewhere if needed without touching a line of app code. Since we stick to a Java App server currently in a Tomcat instance, we're able to move our apps or various instances to Azure, Heroku, AWS,, Backspace, etc. the list goes on and on.

AppEngine will run it as a Java app -- that said we haven't tested Starter Ignite on there, but would guess it's approximately one day work to have it running. Again, just a straightforward JEE app under Tomcat is pretty portable.

That said, the risk of vendor lock to various point-service APIs is rampant. If you hook into basecamp or fresh books then sure, you would have to rewrite those connectors should you switch vendors. But if you architect well, then that is a finite challenge with a well-defined interface.

The risk with a or AWS on the platform side if you get deeper into proprietary Lambda etc. then switching gets much harder.

These days we also have the "intermediaries" which are claiming the middleware as a service role -- Zapier, IFTTT, and -- personally this is where we put the effort into using REST apis, or perhaps visiting GitHub to find some pre-written code, or using 3rd party Java libraries to connect to Basecamp or SalesForce, or iTunes, or whatever you might need to connect to.

I mean these days you can integrate even with walled gardens like iTunes rather easily:

More risky bets are deep linking into the Facebook graph -- there  is some area I'd keep options open considering the moving target of an API.

Anyway, I feel it is a major part of CTO / Tech CEO job to balance this stuff and knowing your lockin decisions and always having a plan B if you must adapt and move a component or service.  So I've always leaned heavily towards open source and Java/JVM based platforms when possible to at least have alternatives should the need arise.


Karl Schulmeisters Founder ExStreamVR

March 1st, 2015

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

Our solution  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

John McMahon CEO at Starter Inc.

March 3rd, 2015

Two words: Vendor Lockin

This is not a vague, philosophical reason, as others have noted: being locked into any monolithic platform can result in unilateral decisions by the platform vendor killing your product.

All it takes is an API change, a non-approval, or even a competing offering from the platform vendor to destroy months or years of work, and take your business out.

At Starter, we are passionate about building platforms and tools based upon open source standards, open source, and portable platforms.

IF there is a need to integrate with a proprietary service like Facebook, SalesForce, or iTunes, it is done as a connector/plugin... the core server runs on Linux/Tomcat/Java with various front-end clients written in HTML/JS, WordPress, Swift, Java, C#, or whatever makes sense for a responsive front end experience.

With a portable java/linux based backend, you can move the core app to various Cloud providers such as Azure, AWS, Backspace, AppEngine, and even your own data center -- preferably a hybrid of these with some failover capability.

In this day and age, there is a huge trend towards consolidation -- don't be a victim of the whims of a giant vendor, choose portability and open source and you will win.

Michael Brill Technology startup exec focused on AI-driven products

March 1st, 2015

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

Gopi, do you a scenario where is a good platform for a oriented startup?

Gopi Mattel General Partner. Lifeboat Ventures

March 2nd, 2015

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

+Michael Brill.  I see 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. 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.

Vijay MD Founder Chefalytics, Co-owner Bite Catering Couture, Independent consultant (ex-McKinsey)

March 1st, 2015

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

We use heroku (owned by Salesforce).

don't know much about Force specifically but time to figure out the proprietary Apex language and generally poor quality of tech support make me less interested in switching over vs using a API from heroku.

Would love to hear about any specific benefits Of the Force platform specifically valuable.