A plethora of PaaS options

A plethora of PaaS options

Summary: There are five different categories of platform available for building on-demand or SaaS applications, ranging from conventional do-it-yourself server platforms to cloud-based application-builders. Which would you choose to build a killer SaaS application?


About that show of hands. I didn't expect my straw poll at last week's SaaS Summit would produce only two hesitant supporters for Salesforce.com's Force.com platform-as-a-service model out of a room full of two or three hundred ISVs. But this was a conference organized by specialist SaaS hoster OpSource, and even though the OpSource team does a great job of making this an event of interest to the entire industry, you'd still have to expect the attendees would skew towards favoring OpSource's managed hosting model. A similar straw poll at a Force.com event would probably skew in the exact opposite direction in favor of Salesforce.com's more packaged platform. To arrive at any other conclusion is mischievous at best. [Disclosure: Salesforce.com and OpSource are both clients, OpSource funded my travel costs to be at the event.]

What's more, I'd argue that the cloud computing and hosting choices available to people — whether they're ISVs, enterprise developers or business users — are still poorly understood. There's been a veritable explosion of platform-as-a-service choices coming onto the market in the past month or two, and the pace of introductions is accelerating rather than slowing. It'll all settle down eventually, because at the end of the day people tend to coalesce around just one or two dominant providers, or a handful at most. But ISVs perhaps want different choices than enterprises and indeed solution providers. So I think there may be several different categories of platform where we'll see those clusters of long-term dominant players getting established. I'd divide the options into five layers, as set out below. There's also a poll at the end where you can express your preference, and perhaps arrive at a better-sampled (though just as statistically invalid) result than that show of hands ...

  1. Do-it-yourself. The first option is the one that's always been there: you buy your own servers and software (or download open-source code), build your application along with all the infrastructure needed to support it, and run it yourself. This is what Microsoft, Oracle, IBM, Sun, IBM, Progress Software and a number of other established platform software vendors continue to encourage you to do, and it's still what most of the market chooses. But the tide is turning, such that more and more developers are looking at other options.
  2. Managed hosting. This is a bit like the first option, except that someone else runs the infrastructure for you to a greater or lesser extent. You still choose which infrastructure to use, but you get to share the operational burden. At the high end you get offerings like OpSource, which provides a lot of SaaS-specific services around the core hosting, including an integration bus, which the company announced at last week's conference. But you're still in charge in the sense that it's entirely up to you what components you choose to deploy.
  3. Cloud computing. This is a utility computing variation on the previous option. The canonical example of this is Amazon EC2 but other examples are emerging, such as Mosso, the Rackspace venture I recently wrote about, and Joyent. In cloud computing, the provider builds a virtualized infrastructure and you get to install and run your applications on it for a pay-as-you-go price that is directly proportional to the resources your applications use. The provider automatically scales your implementation up and down according to the resources you need at any given time. The main distinction from managed hosting is that some of the choices are made by the provider rather than the customer. They choose how to do the scaling and load balancing, for example, rather than allowing you to specify how it's done. But you still take responsibility for higher-level application infrastructure such as performance tuning, user provisioning and access rights, framing APIs, and so on. I'm giving this option a lot of focus at the moment, and the interplay between virtualization and SaaS forms the topic of a presentation I'll be delivering at ComputerWorld's SaaScon conference in Santa Clara at the end this month.
  4. Cloud IDEs. This layer provides a much more comprehensive application development and deployment environment, with the provider making most of the choices that determine how the application infrastructure operates. The canonical example is Salesforce.com's Force.com platform, but another strong contender that just entered public beta is Bungee Labs, who I'll be writing more about separately. At this layer, you build your application using the platform provider's own on-demand tools and collaborative development environment. The type of application you build isn't constrained, but the infrastructure choices have already been made, so you don't have to worry about them. The trade-off you make is that you're tied to their platform, with no easy way of transferring your application elsewhere if things don't work out.
  5. Cloud application builders. This layer is similar to the previous layer but it's targeted at business-level power users and designers rather than developers. A lot more of the application infrastructure is already provided, the trade-off for which is that it constrains your choices into certain application types. There are dozens of such platforms emerging. Some are web-facing application builders such as Coghead, which this week introduced utility-style pay-as-you-go pricing, and newcomer Rollbase, which debuted last week at the SaaS Summit. Others are online database platforms such as Intuit QuickBase (which I wrote about recently), DabbleDB and DataWeb. Some platforms focus on specific categories of business functionality, such as NetSuite's Business Operating System, which was announced last week, or Daptiv's flexible project management platform.

Each of these layers has its own pluses and minuses. For rapid results, especially when automating business processes and workflow rather than simple data processing, the cloud IDEs and application builders win through. For highly tuned performance that depends on diving deep into the technology stack, you're better off working with one of the lower levels. But don't just take my word for it — express your own opinion and see what other ZDNet readers feel by taking the poll.

[poll id=6]

Topics: Cloud, Browser, Emerging Tech, Enterprise Software

Phil Wainewright

About Phil Wainewright

Since 1998, Phil Wainewright has been a thought leader in cloud computing as a blogger, analyst and consultant.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Apple and Oranges Compliment One Another

    Great piece that gets beneath the oversimplification that often 'clouds' the discussion. ISV needs are definitely different than the enterprise. We are big fans of several platforms including Force.com (http://www.appirio.com/blog/2008/02/may-force.php) and Amazon Web Services. In fact Appirio has even mixed the two - using Amazon to create lower level services that access salesforce.com as if it is a database. This has helped us in scenarios where we are storing information related to customers using our apps inside of salesforce.com. We can then use its platform capabilities to create applications that manage the customer interaction inside of our company (licensing, usage patterns, support, marketing, invoicing, etc.). The point is not this specific scenario, but the concept of combining platform to fit the need. In addition, I do believe that Cloud IDEs can naturally extend into Cloud Application Builders. This is not true for movement between some of your other adjacent levels.
    Narinder Singh
  • RE: A plethora of PaaS options

    Phil, it's partly what I call the need to "build" a "buy" culture in the sw industry...


    too many SW CTOs think it challenges their manhood if they don't develop every piece of the stack...use someone else's platform? Might as well become a corporate CIO -)
    • Manhood or Instinct?

      I agree with you to the extent that reinventing the wheel is rarely a worthwhile thing to do. However, a smart CTO understands that they will be married to whichever platform they choose, and some of the platforms in this article make smart CTOs nervous. As pointed out in the article, using a service like Coghead, Force, or any other environment where mid level technology is being selected for you, will make you dependent on them. They do have advantages though, and also as the article points out, each option has its advantages suited for different types of applications, their uses, and their designers. I would never build a vertical app that I intend to resell in a market on a system like Coghead, but I might use them to build an app for an internal department.
  • RE: A plethora of PaaS options


    As usual a very pertinent summary of SaaS evolutions, which illustrates enough how the IT industry enters its "industrial revolution" with -aaS.

    However I believe you missed one sort of PaaS: its the business integration platform (whether you call it SaaS Integration Platform or Internet Service Bus or whatever). An IT system is not a collection of disconnected components: business softwares and services need to be linked together or integrated. The key point here is that integration is primarily not a technical issue but rather a business one: offering API of any sort is not an answer, its a mean and a minimum requirement for a credible cloud-based offering. You need a business oriented platform that abstract the technical complexity of the cloud based softwares and services, lets you concentrate of defining the business logic orchestrating them, and finally runs that orchestration.

    You could call it the "cloud orchestration platform", providing ubiquituous, business centered and on demand linking between all services and softwares.


    • Cloud orchestration platforms

      Thanks, Matthieu, that's a great point. However I think the class of platform you describe isn't inherently a SaaS platform, and perhaps has characteristics that cut across several of the categories I've outlined.

      Interesting 'cloud orchestration' providers include Serena Software - currently on-premise but moving to SaaS - and JackBe, also on-premise.

      Another class of providers that are relevant to the stack but not necessarily SaaS are the virtualization players.
      phil wainewright
      • Re: Cloud orchestration platforms

        Hello Phil

        I agree it could be see as a type of platform that cuts across several of the categories you outlined, but I don't think it should. My experience is that underestimated orchestration / integration is one of the main failure reason for IT projects (probably second only to change management): during iitil delivery but also when the business logic delivered has to evolve. That's true in traditionnal IT, and it's gonna be even more critical in cloud based IT (-aaS) which will include more softwares and services for a more comprehensive and complex coverage of business needs. And obviously orchestrating SaaS while following a traditionnal model is meaningless from the customer's economics point of view. So imho cloud orchestration should be considered for itself, not only as something spread over seveal PaaS: after all it holds the business logic!

        May I complete your list of "interesting cloud orchestration players" but which are on premise traditionnal players, with a pure SaaS player in SaaS orchestration: RunMyProcess (http://www.runmyprocess.com) (Disclaimer: I'm co-founder of the company).

  • RE: A plethora of PaaS options

    I'm not a fan of putting constraints into whatever it is that limits movement and means virtual lock-in for sure. Still the added values of cloud IDE and application builders can surely sway votes despite that. I think at this point though, cloud computing is pretty simple and makes a lot of sense as it is new devs are the ones actively shopping around especially towards the growing SaaS march ans surely not the established ones.

    Nice list there, Phil!

  • RE: A plethora of PaaS options

    Excellent article, Phil. For the business users we create and integrate solutions for, level 5 Cloud Application tools like QuickBase are their salvation. It lets them have sufficient power and integration capability, with a level of independence to create and enhance many of their own solutions.

    Also, we've found that key applications created in one platform can ususally be re-created (and improved on) in another platform without a prohibitive level of effort.

    Scott Wyatt
  • More on Changing Platforms


    As you asked offline, I'll elaborate on changing PaaS platforms. A main benefit of the Cloud Application Builders *should be* extreme efficiency in building applications (apps), once you know exactly what you want to create.

    We find converting from a sub-optimal SaaS platform to a best-of-breed Cloud Application Builder easier than converting on-premise software. Both situations give you a model for the app, and conversions can require a reasonable 20-30% of the effort or cost of the original app. This includes taking the opportunity to IMPROVE the app during conversion, and often integrating multiple, fragmented apps, rather than just replicating each app in better software.

    As experts in QuickBase we do this all the time with quick time-to-value and good value-to-cost ratio. We'll continue to look for a 'magic converter' but in the interim, if a company didn't choose a best-of-breed platform initially, it can be very reasonable to convert to one (and earlier is better than later).

    Scott Wyatt
    Advantage Integrated Solutions
    • Re; More on Changing Platforms

      Ah, yes, but really aren't you just saying that you've become expert in translating the business logic to your platform of choice, and that it's easier to do that port from another SaaS platform than it is from an on-demand platform. That's not particularly surprising.

      What I thought you were saying was that it's inherently easy for anyone to port their business logic from one SaaS platform to another. I'm not sure that's proven by what you've described here.
      phil wainewright
      • RE: More on Changing Platforms


        Yes, but we can actually use the data and app structure from one platform to re-build the apps in another, so there is more leverage than just having the business logic as a model.

        You're right that true portability between platforms would be valuable and isn't there yet. Maybe the PaaS providers could weigh in on this topic.
  • RE: A plethora of PaaS options

    @Phil - this is a nice taxonomy of the market.

    One interesting aspect you didn't touch on is whether these platforms are open or proprietary.

    Although SaaS development platforms like SalesForce and Coghead have gotten a lot of attention, this marekt has so far been remarkably closed and proprietary. The Platform as a Service leader, SalesForce, has both a draconian hosting policy (host your apps and data anywhere, as long as it???s with us!) but also a proprietary language (who needs Java when you???ve got Apex!?).

  • RE: A plethora of PaaS options

    For Platform as a Service (PaaS) to truly be a "real" tool for developers and companies to want to invest their time and money into it, it needs to be open, letting the developers and designers use whatever languages, tools, servers, etc. they want. This "Open Platform as a Service", (e.g., ModBox www.sullivansoftwaresystems.com/modbox will be the next big thing in the PaaS and SaaS world.
  • RE: A plethora of PaaS options

    Having reviewed the results of pall, obviousely Cloud Application builder is in the lead. I guess this tendency will only acelerate for this layer is intended to satisfy the needs of more wide spread users category.
    We chose TeamDesk (http://www.teamdesk.net) as online database platform for rapid delivery of mission-critical applications.

    Dave Stewart