CAMP Platform Component
Canonical Types, etc.
Copyright © 2012 OASIS Open
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
Copyright © 2012 OASIS Open
Overview
• Capability: abstraction
of what’s available on
this platform
• Requirement:
abstraction of what the
application requires
• Template: represents
concrete
configurations or
existing pools
Copyright © 2012 OASIS Open
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
Copyright © 2012 OASIS Open
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
Copyright © 2012 OASIS Open
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 resources
1. 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
Copyright © 2012 OASIS Open
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
Copyright © 2012 OASIS Open
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)
Copyright © 2012 OASIS Open
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
Copyright © 2012 OASIS Open
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)
Copyright © 2012 OASIS Open
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
Copyright © 2012 OASIS Open
Database Platform Component
• Worked example with a Database
Copyright © 2012 OASIS Open
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?
Copyright © 2012 OASIS Open
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
Copyright © 2012 OASIS Open