![\"\"](\"http:\/\/cdn.sendgrid.com\/images\/press\/heroku.jpg?r=1291125435\")
<\/p>\n<\/p>\n
I came into the office this morning to see a tweet that stopped me in my tracks. Salesforce.com is acquiring Heroku for $212m. In cash! Beyond the obvious bubbliciousness of the deal was a cold hard truth about the once and future kingmakers – developer<\/a>s.<\/p>\n You see I didn’t first hear about Heroku from a marketing exec, or a PR person, or an analyst relations professional, I heard it from Tom Insam<\/a>, a super-productive developer I was co-working with a little while before Dopplr<\/a> was acquired by Nokia and airlifted to Berlin. This was very much a Silicon Roundabout story. Tom was all excited about Heroku because he could write code in Ruby on Rails and just deploy it to a server in the sky without needing to consider any implementation or operational details or capacity planning, or anything much. Completely situational.\u00a0 Heroku was basically Rails on a billing engine.<\/p>\n Which brings us to Salesforce.com – which is basically a billing engine across a bunch of servers with some salesforce automation on the side. Obviously Salesforce is a lot more than that, but unlike many other players they always clearly understood that job one in utility computing was billing. Heroku – the same. Salesforce avoids IT to sell to the business, while Heroku avoids IT to sell to developers. The two firms definitely have something in common. While Salesforce has done an oustanding job selling to line of business people, its direct outreach to developers through its Force.com PaaS platform and “Java-like” APEX language has been disappointing so far. Big Difference then- APEX is “Java-like”. Heroku is<\/strong> Ruby.<\/p>\n Another thing Heroku potentially brings is some volume. Salesforce needs to track Amazon economics as a cloud provider, and Heroku runs on Amazon Web Services…. for now.<\/p>\n Heroku is currently spreading its wings, or should I say expanding the portfolio by looking to address the staggering opportunity around serverside Javascript in the shape of node.js. Why should you care about node.js<\/a>? Because every developer in SF is currently going mental for it – its the emerging language for network services and services. Now interestingly enough Joyent recently acquired node.js<\/a> outright, and its lead developer Ryan Dahl. Salesforce.com probably just added $150m to Joyent’s market value… But for now Heroku is all about the Rails.<\/p>\n What about Heroku – I can’t see the obvious evidence for a $212m evaluation in terms of customer success<\/a>– although <\/a>Best Buy<\/a> is a nice name to pick up – but Salesforce is certainly playing an interesting game. Consider that Rails developers don’t much care what the database is, really (beyond MySQL and SQLite). But purchasers want assurance, and salesforce.com just introduced database.com as a backend it claims was designed for multitenancy – with salesforce’s 25bn transactions per quarter as a proof point for scale. So could database.com<\/a> be the backend for Heroku? Why not? Lets developers develop, and business people pay for Quality of Service. Seems reasonable. Of course most apps will be situational and non-relational.<\/p>\n I don’t want to get carried away, and I haven’t even spoken to the parties involved yet, but price notwithstanding the fit makes sense strategically. Salesforce.com has all these services just waiting for developers to target them. Moving to RESTful interfaces was an important step, but the Heroku move radically ratchets up its profile with developers.<\/p>\n Talking of developers, my current office mates Matt<\/a> and James<\/a> tell me the new hotness in Heroku is the addon model for providers<\/a>. This integration platfrom makes its stupidly easy for developers to sell their own services through Heroku. Say you want high volume email for your app – just use Sendgrid<\/a>. No config- it *just works*. Or say you want application performance monitoring from New Relic<\/a>. Again – one click and you’re there. Developers can call operational functionality without talking to ops. This is profound – and very much a marketplace. Its not exactly devops as a platform. Remember XML for config? Well now you can forget it…<\/p>\n