What are developers interested in when selecting a Platform-as-a-Service? If there’s ready cash at hand, lock-in and “proprietary” is demoted in favor of a quick buck; if the developers are building a general application with a longer time between compile and cash, an open, standard platform is more attractive. That’s the quick take, at least.

We’ve been having discussion more discussions about PaaS dynamics at RedMonk of late as people look at PaaS options (both selling and using). Here, I summarize:

1. The more popular and curious PaaSes
2. Why looking at PaaS is valuable for vendors
3. How RedMonk is starting to see developers evaluate options, early in this field as it is

The PaaSes in Hand

(Above: interview with Issac Roth, CEO of PaaS provider Makara, now owned by RedHat.)

There’s not enough data and (more importantly) history available to make generalizations about broader PaaS adoption. Nonetheless, there’s actually a hefty handful of PaaSes out there:

• Salesforce.com’s Force.com has been around awhile with “more than 150,000 apps” as of April 2010.
• Other Vertical PaaSes like Intuit’s Partner Platform have had a PaaS in their space (here, billing and accounting, pretty important for most businesses).
• Google App Engine – several folks told me there’s around 150,000 apps in there too. Oddly, we don’t hear much about developers using App Engine – totally unscientific and anecdotal, of course.
• Microsoft Azure with over 10,000 “customers” as of June, 2010 – listen at about 2:17 in this recording. Like App Engine, I don’t hear a lot about Azure use from folks I talk with.
• Heroku comes up a lot (100,000+ apps when acquired by Salesforce).
• There’s been several new PaaSes of late: such as CloudBees, VMWare/Spring’s ambitions (e.g., VMforce), RedHat/Makara, and even a node.js service. Also, offerings like Joyent’s SmartPlatform have rolled older hosters into new models

Arguably, Amazon has been offering so many pieces of middleware that they have a “build your own PaaS” stack (a sort of “salad bar”), but I won’t consider them for now. (I haven’t had a chance to check out AWS Beanstalk yet, here’s some early commentary in Quora).

There’s numerous PaaSes I’m leaving out (like Bungee and Morph, probably, and it looks like Oracle has something running around – many of them are collected in my bookmarks) – feel free to add them in the comments below – I’d appreciate it, actually. (E.g., here’s a quick answer by Tweet.)

Why start a PaaS?

Software vendors (esp. middleware vendors) are wise to start figuring out how they can exist in a cloud world, and a Platform-as-a-Service is an attractive option for such vendors for several reasons:

1. It’s available – Getting into the IaaS business is very difficult now, capital intensive, and establishing the differentiation (from Amazon, Rackspace, and others) needed to succeed is difficult. Ultimately, developers want to write applications, not manage cloud infrastructure. As Stephen noted in his predictions piece, while PaaS wasn’t a hot topic in 2010, because of that it’s a huge white space for vendors to get into.
2. It’s what you have – The middleware and application development stack is often what vendors have in spades, so naturally, you want to roll what you have into your future.
3. It’s billable – People will pay to run otherwise free software. Many vendors over the last decade have had to release their middleware and stacks as open source – developers would use little else. Monetizing open source (aside from getting a big company to buy you) in terms that investors want can be difficult. How much “support” and “integration” does the world need for something that they can download for free? Clearly, a fair amount to hear about the revenues and engagements of our clients, but there’s still money on the table if you can wangle how to snatch it. The acceptance of a metered payment method for software (cloud, PaaS, etc.) is a huge hole in the open source company revenue ceiling: it’s way to get people to pay for free software…in theory.
4. Up-sells, market-segmentation – Heroku and AWS provide good examples of the up-sell options for PaaSes. The basic service may be cheap, even not terribly profitable. But because of the ease of integration and speed to purchase, layering in additional services at a cost (of course) is an attractive model. It makes for excellent partner programs as well (read: little effort on the PaaS provider’s part as the partner does most of the work, with a percentage on sales). The potential partner ecosystem for PaaSes (and all cloud-based services, actually) seems like it’d be excellent. You can see where these ad-ons allow you to segment the market as well. It’s not clear that the usual dynamics work the same (slapping the word “enterprise” or “essentials” on something), but the segmenting minded out there should be drooling over the possibilities.

Evaluating PaaSes

(Above: no-PaaS vs. PaaS slide from Microsoft’s PDC 2010.)

All of that context in the chute, here are some observations:

1. Quick cash trumps all – while platforms like Force.com and IPP are not general development platforms, the fact that they bring large, ready customer bases makes them attractive for developers who want to write “quick” plugins and extensions to that platform. If there is a ready market, lock-in concerns are less of a priority. The iTunes App Store, while not a PaaS, is another touch point of otherwise lockin paranoid developers going after the gold instead of the long-term flexibility of an open ecosystem.
2. A ready customer base – for providers like Salesforce, the customer base, customer data, and customer process is an incredibly valuable asset. It’s a market to sell to and “eyeballs” to get in front of that most developers and small teams would be at pains to access. Similar effects are being seen in marketplaces like the Google Apps Marketplace: back in October 2010, RedMonk client MindQuilt said they boosted their trial customer sign-up by 15% when they were featured in the Google Apps Marketplace. Also, check out Bob Warfield’s commentary on the wider value of data for the PaaS vendor.
3. For applications, open is desired – if a developer is working on a general application (the type of things an ISV would traditionally work on, software to sell) the desire for an open platform are high. Much of the fear of lock-in and proprietary technology use comes from the fear that potential business models and revenue will be cut off by that lock-in; or that the technology locked into will hinder future development and cash-flow. A PaaS like Heroku shows the general appeal: while there’s a certain degree of lock-in (having to re-create the stack provided by Heroku and come up with a new deployment process and home, etc.) most of the services offered are standard open source ones. Even if they’re not open, like the Apigee add-on, most components can be rebuilt in another platform.
4. Speed, hassle reduction – for developers, as Heroku has shown, the speed and ease of development and deployment are very attractive reasons to use a PaaS. Developers are giving up the ability to completely customize their stack from the metal up (OS, runtime environment, frameworks, etc.) – they’re giving up the joy of tinkering. In trade, though, a PaaS should make their lives easier: using a PaaS should be much less of a hassle than deploying your own application stack, even on an IaaS provider. (William Vambenepe, as always, has a pragmatic look at the idea that you won’t have to worry about that gorpy stuff anymore in PaaS-land.)
5. Identity and single sign-on – as Facebook Connect and Google ID become more ubiquitous, developers can skip the messy, tedious, and low-value identity sub-systems in their applications. This is an weird, risky piece of lock-in (remember how upset the world was about Microsoft Hailstorm?), but using those identity systems to bootstrap in user’s identities is becoming more widely acceptable.
6. Scaling – scaling up (to meet demand) and down (to control costs) was one of the original promises of cloud computing. For those developers looking to provide widely used, public web, mostly consumer services, building in scaling is a solid requirement (while all of the popular consumer services fall down, they tend to get back up quickly, and they don’t stumble as much as you’d expect). For others (those targeting small scale user bases at much higher per-head price), scaling may not matter a tremendous amount.
7. Cost – the original promise of cloud computing was cheapness. Just as with “free” open source in the days of yore, this can mean different things to different people (read: not as cheap as you originally were lead to believe). The idea of paying metered costs – paying for what you need – is an equally attractive option for development teams that are starting out. As numerous Y Combinator Cultists will say, it costs “nothing” to actually start a software-based venture now because you don’t need to lay out a bunch of cash for equipment ahead of time. Once you’re successful (read: have money either from paying customers or for investors based on a large enough “free” user-base), paying for better infrastructure isn’t so much of a problem. It’s that boot-strapping that matters, and a PaaS that allows for paying very little are attractive. For PaaS providers: consider only making developers pay for the service when it’s in “production” rather than development and testing.

Of course, there are management considerations for using a PaaS as well (optimizing and making better the delivery and use of IT by the business to make money, the pitch goes, as it goes for any piece of technology sold for business). Read Salesforce’s Anshu Sharma’s pitch around VMforce if your enterprise-y cup needs a refill.

Misc. Comments

There’s a few other things to throw out there on the topic:

1. Azure – I look towards Microsoft Azure as one of the biggest PaaSes waiting to happen out there. In theory, there are a tremendous amount of line-of-business .Net applications (low priority, but needed for business to function, and usually more trouble to get rid of than to keep running) out there that, if the migration was easy, would be cheaper to run on Azure than on-premise. So far, I’m not sure if this theory is being pursed or is in the cards. Check out this presentation by Microsoft’s Prashant Ketkar at TechEd 2010 for some of that.
2. Retro-PaaS – People like Ning and ZoHo Creator arguably have PaaSes. Facebook apps can be seen kindasorta as a PaaS as well; Zynga might be the single, biggest PaaS user out there, technically.
3. ISV vs. Service vs. Corporate Use – as mentioned a bit above, when thinking about PaaS use, you need to divide up the type of business the PaaS user is in. Are they developing an application to sell (an ISV), a web/mobile/etc. service for folks to use (a SaaS or more traditional public web application, for consumer, business, or whatever use), or internal applications for use by their organization? Each of these types of developers will have different concerns and PaaS features they’ll want to take advantage of.
4. Apps vs. “crap-apps” – while the number of applications deployed on any given PaaS may be high, the conventional wisdom (an idea which I haven’t verified) is that the vast majority of those are “crap-apps”: applications that aren’t really used by many people, hobbyist apps, and other spaghetti thrown destined to be thrown at a wall instead of eaten.

What’s your take?

While these are observations and theories we’ve come across at RedMonk, I’m curious what your thinking is, dear readers. For those folks selling a PaaS, what makes that model attractive?
If you’ve been evaluating using a PaaS for your software, what have you been encountering? What excites you and worries you?

Disclosure: Microsoft, Salesforce, Intuit, MindQuilt, Joyent, CloudBees, and VMWare are clients, as are other relevant parties, no doubt.