DRAFT CAMP Platform Component Canonical Types, etc. Copyright © 2012 OASIS Open

DRAFT

CAMP Platform ComponentCanonical Types, etc.

Copyright © 2012 OASIS Open

DRAFT

Agenda• Platform Component Overview• Types of Specialization

• Examples of Platform Component types• What is a “Platform” – points of management

interoperability• Issue: what do we take on as a group?

• Initial 1.0 release• Adding over time


DRAFT

Overview• Capability: abstraction

of what’s available on this platform

• Requirement: abstraction of what the application requires

• Template: represents concrete configurations or existing pools


DRAFT

Overview - Subclassing• Platform Component (PC) resource types are

meant to be specialized by sub-classing (initially) into a class for each type of platform component (service) offered by this platform

• The Platform Component types represent the platform offering - the more types, the richer the platform offering is from the application view

• Examples: DBaaS, MWaaS, IDaaS, firewalls, load balancers


DRAFT

Overview - Parameterization

• Each Platform Component type is then expected to be specialized by parameterization for specific sizes and configurations in one of two ways:– Create a Platform Component directly and supply

the attributes of the resource to get what you need

– Create a Platform Component using an already parameterized Template


DRAFT

Why have multiple ways?

• Platform can be built using virtualization and multi-tenancy at various levels, and this will be reflected in how they need to expose the platform component resources1. VM per “instance” – a machine image is used to

create the component and may be parameterized

2. Multi-tenant platform component – resources “carved out” of existing shared pool


DRAFT

Capability – VM per instance

• Each application gets their own set of VMs running the platform components

• These can be parameterized at the infrastructure level (bigger VM) and service configuration level since it is dedicated

• The Platform Component Capability resource is ideal for representing all these choices as ranges of values that can be mapped to the VM configuration and the software running there


DRAFT

Capability

• Instrumented by the platform• Contains all supported attributes for that type• Contains value ranges for each attribute• Serves as a service “catalog” of supported PCs

on this platform• Application admin can create a PC instance

supplying any/all attributes with any value in the range (no need to first create a template)


DRAFT

Template – multi-tenant PC

• Each Platform Component instance is provided isolation by the component software itself– i.e. DB based on schema, multi-tenant JVM, etc.

• However, some configuration choices and combinations are not possible because the pools of resources are already provisioned

• Thus the Templates can be used to represent each pool’s configuration


DRAFT

Template

• A given platform implementation may not allow all combinations of all values for attributes of a PC, so representing as a Capability is misleading

• A template can always be used to create an instance with attribute values that match what is in the template (modulo resource exhaustion)


DRAFT

Requirement• When building an application “off-platform” –

how do you know what parameterizations of PC are available on the target platform?– You could “import” the capability or templates from

the platform, then link them as dependencies– You can instead express which values of each

attribute are “acceptable” to the application by creating a Requirement

• These are then used to find the best match when the application lands on a given platform


DRAFT

Database Platform Component• Worked example with a Database


DRAFT

What types are part of CAMP?

• ISSUE: Should CAMP include some specific canonical PC types?

• Without these types, how much interoperability is possible?

• How similar are the services such as database that will be offered?– Is it possible to abstract them for commonality of

configuration and metrics yet?


DRAFT

Which PC types first?

• Basic runtime “container” is key if the application admin is expected to use multiple container “instances” to scale out his application– An application depends on its runtime

environment and at a minimum it needs to be billed based on its usage of that container

• Other PC types might be too diverse to standardize around yet


Documents

DRAFT CAMP Platform Component Canonical Types, etc. Copyright © 2012 OASIS Open