I encourage you to check out this very provocative blog post by Forrester Research analyst John Rymer over on Forrester.com, in which he describes what he calls “Adaptive PaaS.” John proposes that the ‘usual suspect’ PaaS offerings have failed to meet the needs of mainstream enterprise users for a variety of factors, and that a new generation of PaaS solutions is coming to the fore which offer the efficiencies of PaaS, but without the negatives associated with this initial crop of PaaS offerings. (I will be hosting John for a webinar on this topic next week; Please join us!)

Of particular interest to John is the ability for this new breed of PaaS offerings to help users adapt existing applications, tools, processes and skill-sets to the cloud, thus the name “adaptive.” Quoting John’s blog:

1. Adaptive PaaS adapts conventional application code to the elastic scaling and multitenancy of cloud architectures. Developers don’t have to use special APIs or languages (like salesforce.com’s Apex) to create apps for the cloud. They code as they always have.
2. Adaptive PaaS adapts conventional servers and storage to provide “cloud” services by providing application, database, and/or file virtualization services. Some of the early adopters of adaptive PaaS use the software to implement internal clouds.

The ideas John presents in his post are very complimentary to those expressed in my earlier post, The Essential Characteristics of PaaS. In fact, my post could have been titled the Essential Characteristics of Adaptive PaaS — in that post and the article on which it was based, I strongly allude to a new style of PaaS offering (obvious example being Appistry’s CloudIQ Platform) that doesn’t carry the baggage of the “traditional” PaaS offerings.

I think John is on the right track with “adaptive PaaS” and I’m looking forward to further industry discussion around these important ideas.

Please post your thoughts in the comments and don’t forget to register for the webinar!

This morning, an article I wrote titled “Don’t Pass on PaaS in 2010” was published by eBizQ. The article provides an overview of PaaS for IT practitioners with particular emphasis on addressing the “so what?” question. I encourage you to check it out.

In the article, I present what I propose here as the “Essential Characteristics of Platform-as-a-Service,” with an obvious hat-tip to Peter Mell and Tim Grance’s cloud computing definition for NIST.

The Essential Characteristics of PaaS

1. Runtime Framework: This is the “software stack” aspect of PaaS, and perhaps the aspect that comes first to mind for most people. The PaaS runtime framework executes end-user code according to policies set by the application owner and cloud provider. PaaS runtime frameworks come in many flavors, some based on traditional application runtimes, others based on 4GL and visual programming concepts, and some with pluggable support for multiple application runtimes.
2. Abstraction: Platform-oriented cloud platforms are distinguished by the higher level of abstraction they provide. With IaaS, the focus is on delivering to users “raw” access to physical or virtual infrastructure. In contrast, with PaaS, the focus is on the applications that the cloud must support. Whereas an IaaS cloud gives the user a bunch of virtual machines that must be configured and to which application components must be deployed, a PaaS cloud provides the user a way to deploy her applications into a seemingly limitless pool of computing resources, eliminating the complexity of deployment and infrastructure configuration.
3. Automation: A PaaS environment is a bit like a swan on a pond — graceful and elegant above the water, and paddling its little legs off below the water. The aforementioned abstraction provides the elegant user experience “above the water,” while high levels of automation provide the “paddling” beneath the surface. PaaS environments automate the process of deploying applications to infrastructure, configuring application components, provisioning and configuring supporting technology like load balancers and databases, and managing system change based on policies set by the user.
   While IaaS is known for its ability to shift capital costs to operational costs through outsourcing, only PaaS is able to slash costs across the development, deployment and management aspects of the application lifecycle.
4. Cloud Services: PaaS offerings provide developers and architects with services and APIs that help simplify the job of delivering elastically scalable, highly available cloud applications. These cloud services provide a wide variety of capabilities, and in many instances are key differentiators among competing PaaS offerings.
   Examples of cloud services include services and APIs for distributed caching, queuing and messaging, workload management, file and data storage, user identity, analytics, and more. By providing built-in cloud services, platform offerings eliminate the need to integrate many disparate components and decrease time-to-market for applications on the platform.

I hope to build on these characteristics in future posts. In the mean time, what do you think? Anything you would eliminate? Anything you would add?

Earlier this morning we announced the most important product initiative in our company’s history.  Built on more than seven years of customer experience and product development, Appistry CloudIQ Platform 4.0 is a major advance for enterprises making the move to the cloud.  You can read more in our press release, "Appistry Gives Cloud a Kick in the Apps!"  My fellow Appistry bloggers — Bob, Guerry and Michael — will also be posting about CloudIQ over the next couple of days.

With CloudIQ, we address the 80% of cloud computing that too often gets ignored.  It is this 80% — the application layer — that is the hardest to do.  To paraphrase something our CEO, Kevin Haar, said in this morning’s press release:  It’s one thing to deploy and manage a single application in the cloud; it’s a whole other ball game when you’re an enterprise with entire portfolios of applications you need to launch skyward. (I’ll be addressing the “80%” in a future post.)

That is the reason we’re so excited about our new product, Appistry CloudIQ Manager.  CloudIQ Manager gives enterprises a single point of application management as they migrate applications to public and private clouds.  More on the new features and benefits of CloudIQ Manager can be found here.

Additionally, if you are interested in learning more about the CloudIQ Platform, I encourage you to register for our webinar on Tuesday, March 31, 2009 at 11:00 a.m. PST.

We’re amped about this next step for the Appistry platform and the important role it will play in making cloud computing a reality for the enterprise.

This has come up a lot recently, most recently when Coté tweeted:

@cote: Is the cloud categorization getting down to "apps, platform, and infrastructure"? I keep hearing that divide-up: http://tinyurl.com/4ghj7x

This taxonomy is far from perfect, but I think it does a good job of separating out the different types of clouds out there. Michael Sheehan from GoGrid was one of the first to publicly illustrate the cloud taxonomy with a pyramid (and I think he’s trying to apply for a trademark on it . (Image to the right stolen from Michael!)

As provider of a cloud platform, I am frequently called on to differentiate between cloud platforms and cloud infrastructure. Anyone who has used both Amazon EC2 and Google App Engine groks the difference between these two concepts, so I tend to use those offerings to illustrate the difference.

It’s really all about level of abstraction. And this translates directly to the end-user experience. With cloud infrastructure like Amazon EC2, the central theme is the virtual server. The user is (sometimes painfully) aware of the number and type of servers/virtual machines that they have running and management is done by individually logging in to each server, e.g. via SSH. Note that the user doesn’t know things like the brand and physical location of the servers, nor does the user expect complete or exclusive control of the machine. Those are all things that contribute to making the relationship cloud-like.

On the other hand, consider the end-user experience with App Engine. The central theme is really the application itself.  The user develops their application and with a single invocation of a command-line tool, packages and deploys the application to the cloud. The platform takes care of actually deploying the application to the right machines, based on policy, utilization or whatever. The user never logs into an individual server. The don’t even know at a given point in time how many machines their application is deployed out to. The platform takes care of all of that, plus provides APIs and services to the applications themselves. (Much of this is true for Appistry EAF as well, but the model is very different from App Engine.)

I’ve got some slides I use to elaborate on the distinction between the layers. Please take a look and let me know what you think:

Stephen O’Grady wrote up a nice post back in November called Cloud Types: Fabric vs Instance, where he described the Platform and Infrastructure layers as Fabric and Instance respectively. (Fabric has a nice ring to it, for obvious reasons He has a nice description of each that is worth checking out.

Our partners over at Apptis were kind enough to post video footage from the recent CloudCamp Federal event. At the beginning of the event, each of the sponsors was given the opportunity to present a five-minute “Lightening Talk” on some aspect of cloud computing and where they fit in the big picture. My session is posted below. At the end of the video you’ll have the opportunity to review the other presentations from the event.

The slides are a bit difficult to make out, so I’ve included them below as well.