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).
Pingback: William Vambenepe — Desirable technical characteristics of PaaS
Pingback: William Vambenepe — PaaS as the path to MDA?
Pingback: William Vambenepe — Is Business Process Execution the killer app for PaaS?
Pingback: William Vambenepe — Standards Disconnect at Cloud Connect
Pingback: William Vambenepe — The battle of the Cloud Frameworks: Application Servers redux?