Enumeration of PaaS container types

What do we need from an on-demand application platform for enterprise software? Here is a proposed classification of container types on which you can create/scale/manage applications. Your application is made of modules that run on these containers (e.g. one app may have two “synchronous web request” modules, one “structured data service” module and one “scheduled job” module). All tied together using an application component model that dovetails with the capabilities of the different containers. The proposed containers map to the following capabilities:

  • Synchronous web request processing
  • Long-lived (persisted) process execution with introspectable/declarative flow
  • Event processing
  • Persistence (a few different types: structured vs. buckets/files vs. object cache)
  • Batch/background/scheduled/queued processing
  • Possibly some advanced Web/mobile UI (portals, human task flows…)
  • User management (self-contained or as an abstraction layer for other systems)
  • [UPDATED 2009/11/19: I should have included pluggable protocol/format adapters.]

While new applications may be built to run purely on such a platform, you will not be able to run your IT solely on it anytime in the foreseeable future. So if you are thinking about it from the perspective of the entire universe of virtualization containers needed to support your IT system, you’ll need to add lower-level container types, such as:

  • Guest hosts (typically from hypervisors)
  • Low-level (e.g. block) storage
  • Networking between them

Another way to think about it is that Cloud/Utility computing is about having pools of resources dynamically allocated. There needs to be few enough pools that each pool is large enough and used across enough consumers to derive efficiencies from the act of sharing. But there needs to be enough pool types that applications have a complete infrastructure to run on that lets them abstracts away what is not business logic. This list is an attempt at this middle ground.

This is a classification of containers, not a description. There are many different ways to realize each of them. The synchronous¬† web request processing could look like a servlet engine, a Python handler or a PHP page. The persisted execution could be a BPEL engine or some other state machine definition/execution engine. The structured data interface could look like SQL, XQuery or SPARQL, etc… In addition, more specialized application infrastructure elements (e.g. video streaming, analytics) might enter the picture for some applications.

I hope to see the discussion move beyond “IaaS vs. PaaS” towards talking about more specific container types that are needed/supported by the different virtualization stacks. My application doesn’t care if the file container is considered IaaS or PaaS.

The next post will list desired characteristics of the PaaS environment (meta-capabilities that go across all the container types in the first list but may not be available from the lower-level containers in the second list).


Filed under Application Mgmt, Cloud Computing, Everything, Middleware, PaaS, Utility computing

7 Responses to Enumeration of PaaS container types

  1. Pingback: William Vambenepe — Desirable technical characteristics of PaaS

  2. I am a little bit surprised that you took a rather implementation specific container perspective rather than something a little bit more abstract (in terms of deployment) like services/connectors/buses. I understand the need to partition & classify different workloads but does this need a particular container type itself? Would it not be better to have a single container-service contract that allows discovery (or injection) of internal or external cloud services such of wich might also acts as containers for particular work/activity migration (grid computation service)?

  3. William Louth: both views are valid, it depends on what you’re after. The first two bullets in my follow up post (“an application component model that supports deployment/configuration across all PaaS container types” and “explicit interactions/invocations between application components”) address what you describe and I think they are indeed critical.

    But while “I don’t care about the container, just do what my app needs” is great for the developer, from the POV of the people operating the PaaS framework they need to know exactly what sets of resources they need to provide and the minimal functional contract of each. I am trying to define a PaaS contract that is both useful to the app and manageable/doable for the provider.

  4. Pingback: William Vambenepe — PaaS as the path to MDA?

  5. Pingback: William Vambenepe — Is Business Process Execution the killer app for PaaS?

  6. Pingback: William Vambenepe — Standards Disconnect at Cloud Connect

  7. Pingback: William Vambenepe — The battle of the Cloud Frameworks: Application Servers redux?