Desirable technical characteristics of PaaS
by William (@vambenepe on Twitter)PaaS can most dramatically improve the IT experience in four areas:
- Hosting/operations efficiency
- Application-centric management
- Development productivity
- Security
To do so, there are technical characteristics that PaaS frameworks should eventually exhibit. These are not 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 are.
Here is a rough and unorganized list of the desirable characteristics (meta-capabilities) of PaaS Cloud containers:
- An application component model that supports deployment/configuration across all PaaS container types.
- Explicit interactions/invocations between application components (resilient connections between component: infrastructure-level retry/reroute)
- Uniform and consistent request tracking across all components. Ability to intercept component-to-component communication.
- Short-term (or externally persisted) state so that all instances can be quickly redirected out of any one node.
- Subset of platform management interface exposed to consumer, along with out of the box application management. Application metrics consolidated at application level rather than node level.
- Consistent, model-based application management interface across all container types. Hooks for component code to provide its manageability in the same framework.
- Minimal footprint of any container node for limited patching requirements.
- Assistance for debugging platform-hosted code (see this entry).
- No encroachment of container technology on application contract (e.g. no forced URL structure).
- Application uniformly scalable to the limit of the underlying hardware (no imposed partitioning).
- Shared authentication / authorization / auditing across containers.
- Minimum contract/interface exposed by each container.
- Governance of application services, aligned (in model/protocols) with the container management interfaces.
- [UPDATE: need to add metering+billing as William Louth pointed out in a comment]
This applies across the board to public, private and hybrid PaaS. The distinctions between these delivery models are real but at a different level. The important thing is that the PaaS administrator is different from the application administrator in all cases. On the other hand, most of these technical characteristics are not achievable for lower-level Cloud resources (like virtual hosts and low-level storage) which is why the IaaS form of Cloud leaves the Cloud promise only partially fulfilled.
Related posts:
- Enumeration of PaaS container types
- Cloud platform patching conundrum: PaaS has it much worse than IaaS and SaaS
- The necessity of PaaS: Will Microsoft be the Singapore of Cloud Computing?
- PaaS portability challenges and the VMforce example
- PaaS as the path to MDA?
- Is Business Process Execution the killer app for PaaS?
Follow @vambenepe on Twitter.
November 10th, 2009 at 5:12 am
You seem to be ignoring billing and resource metering (note: metering != billing) which is required by one or more services in support of the “cloud” like qualities hinted at including scalability, reliability and work migration. The container needs to expose runtime resource meters. The cloud services interactions need to expose metering usage. All in a uniform way and correlated with component activity work flows – with flows having multiple cost (chargeback) structures supporting billing/metering from multiple perspectives both operational & non-operational.
November 10th, 2009 at 9:02 am
[...] next post will list desired characteristics of the PaaS environment (meta-capabilities that go across all the [...]
November 10th, 2009 at 12:00 pm
William Louth: you’re right, metering+billing should also be there. Oversight on my part. I like the way AWS has been thinking out of the box about different ways to charge users, including ways that map directly to the consumed resources.
April 22nd, 2010 at 10:37 am
[...] Cloud Frameworks will need to go through the equivalent of all the other stages. First, the IaaS APIs will get more optimized and capable (stage 2). Then, at stage 3, we will focus on higher-level, more productive abstraction layers (generally referred to as PaaS) at which point we should expect a thousand different approaches to bloom, and several of them to survive. I will not hazard a guess as to what stage 4 will look like (here is my guess for stage 3, in two parts). [...]