This afternoon at Deploycon I am moderating a panel: “The Future of PaaS.”

I asked the panelists and others at the conference how they view the future of platform-as-a-service. Here is a smattering of what people had to say:

Pervasive CTO Michael Hoskins set the tone with his keynote. His picture is of a PaaS becoming the means for data-as-service as the age of software comes to an end. The advent of PaaS will mean the transformation of frameworks and complex families of services to simple, stand alone services. Apps will be less written and more assembled from various components. Finding functionality becomes less expensive than writing it from scratch Like fractals, ever higher order data-centric apps can be composed.  Subscriptions will moves from time-based to data/usage based.

In all this means, PaaS will constantly evolve and be highly market driven. We’ll see the blurring of IaaS and PaaS. The power pendulum will continue to swing to apps/users. And does this mean the end of enterprise apps?

Guy Marion, Collabnet:

Marion said they view PaaS as an aspect of managing the application lifecycle. There will be the need to leverage multiple tools and environments. The world is becoming more heterogeneous. It includes being able to orchestrate, abstract and manage visibility as the app comes down the pipeline. Aggregating the data and managing the data in context will be the key factors. The future of PaaS should bring more readily available tools, code and pre-configured databases to make development and deployment easier for developers.

Chuck Freedman, Mashery

“More simplified PaaS database configuration means less dependency on DBAs. Any app that works with a dataset from a traditional content REST platform likely needs to store data in a way respective to that platform. However, there are some common ways data is collected and stored in an app, especially for apps that work with data from well-managed platforms. PaaS services could begin to offer pre-configured or easily adaptable ‘starter’ database configurations so the backend is already setup to handle common data schemes for apps. I can see more universal APIs offered from PaaS providers directly allowing developers to programmatically configure the companion database solution to recognize or adapt to the data set. This should speed development/deployment and make PaaS that much more a valuable service to developers, including many of the 145,000 key-wielding developer in Mashery’s API network.

Another tool set to speed up development and make PaaS more valuable would be feature libraries and plugins. Available in common cloud-hosted backend languages like .Net, PHP, Ruby, for example, these give developers easy access to commonly added social and location features.Similar to how iOS and Android have Facebook, Twitter and Location APIs baked into their mobile frameworks, developers should be able to call similar common features already setup in their respective PaaS cloud service. It could transfer popular reoccurring activity to the infrastructure. This should speed development/deployment and centralize updates to the respective services at the server level.”

Suresh Sambandam, CEO, OrangeScape

My view is:

1. PaaS for enterprises will be different from PaaS for ISVs.

2. Most of the PaaS offerings (Azure, GAE, Openshift, Engine Yard, Heroku and everybody else) that we see today is a big incremental innovation on top of what we already had as “app servers” and “middlewares” in the pre-cloud paradigm. Surely, there is scale related and devops related capabilities and simplification, but in my view that is not sufficient given the potential of what is possible. More specialization and abstraction has to be added to dramatically simplifying things. The best way to view this is instead of thinking “how to make things easier for the existing 5 million (or x million) developers” if that can be framed as “how can we make another 50 million people build apps because of PaaS”. to me that is a exponential innovation. We are not there yet, but that should be the future of PaaS”

Mike Soby, President, Cumulogic:

Soby said Cumulogic sees it as a domain specific PaaS. A PaaS is still about abstracting. As you  continue to abstract, you will abstract languages, frameworks, infrastructures, etc. If you are developing big data apps you will go to a big data PaaS. In the short term, there will be a move from public to private PaaS. Today’s transformation is horizontal. Tomorrow’s will be more vertical in nature.