After Apex was introduced in 2006, Salesforce suffered criticism (misplaced, IMHO) over the fact that it was proprietary. In 2009 it did a partnership with VMware to create a Java-as-a-service proto-PaaS so business logic could be written in Java instead of Apex. This service (VMforce) never worked for a variety of reasons, leaving Salesforce to look for an alternative -- so in early 2011 they bought Heroku. Thats why the first thing Heroku did post acquisition was build Java support.
Turns out this wasn't a great product idea to start (the limitations of externalizing business logic, especially at that time, weren't worth the effort), so the strategic reason for the acquisition was no longer relevant. Years later there were successful integrations that had different value propositions, although those suffered from the constraints described above.
> What was the point of the aquisition? To let it die?
I've seen companies who build on Force.com use it for <we need a standalone application that does X because Force.com can't do it or we have teams that don't know Apex but want to do X> and then integrate it against. They have an interesting (albeit not sure if it ever got fully fleshed out) bi-directional DB sync between SFDC and Heroku Postgres, which to me is the killer app for integration.
Salesforce bought Heroku in the early days of the “Salesforce Platform” product era. I wouldn’t be surprised if Heroku tech underpins a big chunk of the AppExchange developer experience.
There might be less than you would think. Salesforce's security review does not take kindly to having executable portions of your managed package live outside of their stringent security process. That isn't too say it doesn't happen. But you have to make a case for it being critical.
I mean:
> From a strategy POV, for better or worse, Salesforce is not particularly focused on integrated acquired products
> I heard revenue and margins weren't sustainable prior to the acquisition
What was the point of the aquisition? To let it die?