Fragments from Deploycon

I'll be spending the rest of the week at Cloud Connect Santa Clara (at which I'll be speaking on Wednesday and Thursday). Today was devoted to the Deploycon companion event, which Krishnan Subramanian, Principal Analyst at Rishidot Research, and friends kicked off last year in response to their perception that their wasn't enough specific focus on Platform-as-a-Service (PaaS). 

I'm not really going to report on the event in this post. Probably a #deploycon twitter search is the best place to get an overall sense of what went down. Rather, I'd like to hit on a few topics that piqued my interest or that surfaced questions that I'd like to dig into more deeply in the coming weeks or months. Think of these as, not complete thoughts, but as interlocking fragments and threads that could benefit from further examination and teasing apart.

What is PaaS anyway? (Definitions. Shudder. I Know.)

The thought of revisiting PaaS definitions kicked off exasperated consternation among various panelists and audience members. But bear with me. 

Without turning things into an academic definitional debate, there are some legitimate questions here. What is a PaaS itself as distinct from APIs being consumed? What of something like Kinvey's "backend-as-a-service" for mobile? Is that a mobile PaaS? What of something like Force.com, which analyst Judith Hurwitz describes as a PaaS anchored to a SaaS environment?

My tentative answer to these questions is that a PaaS is a PaaS—something that provides an abstraction for developers—while services (including backend services) are, well, services that a PaaS application can consume. (That said, I'm open to the idea that PaaS environments might be constructed in ways that are optimized for either specific vertical or horizontal (e.g. mobile) application types. 

PaaS doesn't do enough

On the one hand, this was an unsurprisingly PaaS-friendy crowd. And there was little disagreement with the contention that "PaaS is 100% relevant to enterprise IT now," as one person put it.

At the same time (with the caveat that most enterprises aren't really ready to absorb more that today's PaaS today), there's an opportunity to do a lot more. Sinclair Schuller of Apprenda made this point in the vein of making it easier to write cloud-aware applications. Cloud-aware referring to service-oriented, stateless, modular, etc. 

An interesting question to me, apropos backend services and so forth, is how to make it easier to write applications that are more fundamentally based on consuming services from all over. Is this a function of the PaaS or of client-side tooling? I bit of both I suspect although the two are not unrelated to each other. (At a minimum, a PaaS needs to support popular client-side and other tooling as Red Hat's OpenShift does with Eclipse, Jenkins, Maven, and so forth.)

Polyglot? Open?

So last year. OK. That's a bit flip. But even if the details could be debated, there was no one about to stand up on stage and claim such things don't matter. Every PaaS is trending more multi-language and multi-framework (even if they didn't start that way). See my post about OpenShift and polyglot here. And, to whatever degree a given PaaS is actually open, you're sure to find that work in its marketing literature.

Operational models and visibility

I suspect my recent post about PaaS as an abstraction would have been controversial among some panelists throughout the day. From my perspective, part of the value of PaaS is as black-letter abstraction. What's above the line is yours. What's below the line is ours. 

However, to give one example, Carsten Puls of Engine Yard noted that: "At first, customers want to get going. Understanding what's going on under the hood isn't that important. As grows, want more control and go under the hood. Managing that bsalance through lifecycle is important." 

I suspect that part of the disconnect is specifying who the "customer" here is. I'd maintain that for most Web/Java developers, the above-the-hood view is fine throughout the lifecycle. But, if you expand "customer" to mean "the IT organization," all you're really saying is that just having a hosted PaaS isn't enough; you need a private or hybrid PaaS that allows ops to get as far under the covers as needed.

How high level can we make things?

Larry Carvalho asked me if PaaS could make it so business users (not IT) could develop useful applications. I'm a bit skeptical; it's an idea with a generally unsuccessful history. (Unless you count spreadsheets.) But, maybe. To the degree that  we can make services more easily consumable and more easily interconnected. And to the degree that we can package even higher levels of abstraction. Something like OpenShift's cartridge system could possibly evolve into such a mechanism.

Enough for now

All of these thoughts (and more) need more fleshing out. But those were some of my top-of-mind takeaways from the day.