Platform-As-A-Service, Chapter 2

Platform-as-a-service -- application development platforms running in clouds -- are entering a new phase of evolution, and not a moment too soon. I've become interested in a new set of products I'm calling "adaptive PaaS" (for lack of a better term) that I think will make the benefits of cloud computing available to a lot more development shops. I'm doing a webinar on this topic May 20th with Appistry's Sam Charrington. I hope you can join the discussion.

As I described in my early reports on PaaS, these products include full development tooling, runtime services, and administration and management tools. While complete, most of these "full PaaS" products are best for new applications, and they incorporate much proprietary technology. Consequence: Many if not most clients are still saying "no" to PaaS for two reasons.

  1. Lock-in: PaaS products lock up your code in a single provider's environment.
  2. Poor fit: Too many PaaS products just aren't strong for core business applications, particularly for rehosting existing applications.

These limitations often prompt developers who want the flexibility of cloud computing to use IaaS platforms like Amazon EC2 instead of PaaS. With IaaS, developers can code in the language and frameworks they choose, reducing lock-in and ensuring a good platform-application fit. As a result, while we see both interest and adoption of software-as-a-service (full applications) and infrastructure-as-a-service (virtual servers, storage, and networks), PaaS is lagging in adoption.

Adaptive PaaS employs a different approach than full PaaS, seeking to adapt applications built in Java, .NET, and other languages to cloud infrastructure, and then manage those applications through change cycles. Adaptive PaaS removes development tools and frameworks from the PaaS stack, and provides only packaging, deployment, distribution management, workload management, and resource virtualization services. Developers use the tools and frameworks supported by the adaptive PaaS platform. Some of the products also provide billing and other application services that developers can call from within their applications.

I call this category "adaptive PaaS" to describe its primary function (adaptation).

  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'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.

Diagram shows elements of an adaptive PaaS product.

The vendors that I've talked with providing adaptive PaaS are:

  1. Appistry -- provides the IQ product line for Java applications.
  2. Apprenda -- provides the SaaSGrid for .NET applications.
  3. IBM -- provides WebSphere Virtual Edition and WebSphere CloudBurst for WebSphere applications.
  4. Oracle -- provides the beginnings of an adaptive PaaS with Oracle Virtual Assembly Builder and JRockit Virtual Edition for Oracle WebLogic applications.
  5. TIBCO -- provides the Silver Suite for Java, .NET, C++, and other applications.

My introductory conversations with Appistry and Apprenda first started me thinking about "PaaS, Chapter 2." I had to account for the value these vendors provide to both internal development shops and ISVs.

Please join us on May 20th for the PaaS, Chapter 2 webinar.


Poor fit due to lack of ACID persistance

Most PaaS in their enthusiasm to be scalable dont provide ACID( Atomicity, Consistency, Isolation, Durability) persistence. This makes building serious biz applications on PaaS a huge challenge. Biz apps are so used to the ACID persistence of the RDBMS that the expect it in the cloud too.

Social apps either skip the ACID requirement or handle it in their custom code. Biz Apps cannot afford non-ACID persistence or afford the custom coding/plumbing.

What are the platforms that provide Biz Apps ready persistence? Are they lock-in free?

If there is clarity on these, the PaaS adoption will see exponential growth. Otherwise, as you have pointed, IaaS plus custom coding is the way to go!

-Balaji S.

ACID -- thank you for your comment

Hi; thank you for your comment about ACID and PaaS. I think support for traditional transactions may indeed be a good "acid test" for PaaS. I've been looking for SQL support as well. How important to you believe support for XA (distributed transactions is to the future of PaaS?

Adaptive PaaS Critical for New and Integrating Legacy Apps

John, at SensorLogic, we've come to the same conclusion, and have built an adaptive PaaS, Cirrus, for asset tracking applications that can be further leveraged for integrating with enterprise apps, e.g. ERP, Supply Management, CRM etc...Asset tracking apps have wide range of use - a simple example is to track pallets of goods from a warehouse to a store shelf. In some cases, shrinkage or missed deliveries cause CPG companies millions of dollars in losses a month. The business case of reducing loss in this instance maps directly to your points about an Adaptive PaaS - developers want to exercise control over the development of an application, and its integration, while being insulated from the complexity of the NxNxN problem associated with devices, network connectivity and hardware. Adaptive PaaS provides flexibility and extensibility throughout the PaaS stack and does provide the option of a private cloud.

Joe Cordo
VP of Marketing, SensorLogic

Can I get a briefing?

Hi Joe! Long time, no talk. Thanks for responding to my blog post. I'd like to learn more about SensorLogic. Would you be willing to arrange a briefing with me through I look forward to it.