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).
[...] technical characteristics of a given PaaS container, they are shared characteristics that go across all container types, no matter what the operational capabilities of the containers [...]
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)?
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.
[...] the other hand, you are mapping to something that is higher level than byte code. Depending on what types of PaaS containers you envision, some of the abstractions provided by these containers (e.g. business process [...]
[...] execution engines are useful, as are other core services like storage (here is my proposed list of PaaS container types). I just wanted to bring some attention to business process execution because I think PaaS is the [...]
[...] can tell you that much even if I can’t tell you what the whole will be. I have my ideas about what the whole will look like but it’s just a guess. Anybody who pretends to know is fooling you, themselves, or [...]
[...] I will not hazard a guess as to what stage 4 will look like (here is my guess for stage 3, in two [...]