why do we need a plan portability api n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Why Do We Need a (Plan) Portability API? PowerPoint Presentation
Download Presentation
Why Do We Need a (Plan) Portability API?

Loading in 2 Seconds...

play fullscreen
1 / 18

Why Do We Need a (Plan) Portability API? - PowerPoint PPT Presentation


  • 111 Views
  • Uploaded on

Why Do We Need a (Plan) Portability API?. Gerd Breiter Frank Leymann Thomas Spatzier. TOSCA‘s Goal. Provide the ability to create portable descriptions of Cloud applications and their operational behavior The TOSCA Charter says about the latter:

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Why Do We Need a (Plan) Portability API?' - radha


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
why do we need a plan portability api

Why Do We Need a (Plan) Portability API?

Gerd Breiter

Frank Leymann

Thomas Spatzier

tosca s goal
TOSCA‘s Goal
  • Provide the ability to create portable descriptions of Cloud applications and their operational behavior
    • The TOSCA Charter says about the latter:
      • „TOSCA will facilitate this goal by enabling the interoperable description of...the operational behavior of these services (e.g., deploy, patch, shutdown)... TOSCA will also enable the association of that higher-level operational behavior with cloud infrastructure management. “
what is out of scope
What is Out of Scope
  • The charter says explicitly what‘s out of scope:
    • „ ...The interface definitions of a service container. ...“
  • But the proposed (Plan) Portability API is not an interface of the container
  • The (Plan) Portability API is an interface that must be available in a TOSCA environment to allow portable operational behavior of Cloud Applications
  • Thus, the (Plan) Portability API is not functionality to deal with the container itself
  • In this sense, the (Plan) Portability API is in scope
why this problem now
Why This Problem Now?
  • We focused on initial deployment of Cloud applications since starting the TOSCA TC
  • Initial deployment can be done via two very different approaches: the declarative approach and the imperative approach
    • See next…
  • SugarCRM can be deployed in a declarative way
    • But more general operational behavior cannot be derived declaratively
    • Even for SugarCRM, the operational behavior after initial deployment can in general not be derived in a declarative manner
  • In general, operational behavior requires an imperative approach
  • An imperative approach needs explicit access to state information of an already deployed application, as well as state information of its ingredients (instances of node types, relationship types etc).
declarative approach
Declarative Approach
  • Defining the management behavior of a cloud service focuses on description of the desired results
    • Via requirements, capabilities
    • Is dependent on crisply defining semantics of relationship types, lifecycle operations etc
      • E.g. Hosted_OnvsConnects_TovsDepends_On
  • Thus, management actions to be performed will be derived automatically!
    • Orchestrations don't have to be defined explicitly, but the effects otherwise achieved by orchestrations will be achieved implicitly
  • Thus, a declarative approach provides information about what orchestration problem is to be solved
  • This is similar to SQL: You specify WHAT data you need, not HOW to retrieve them (latter is needed for IMS/DB, most OO-DBMS, files,…)
imperative approach
Imperative Approach
  • Defining the management behavior of a cloud service requires specifying each of the steps to be performed in an orchestration as well as the order in which these steps must take place (the plans)
  • Thus, you must explicitly specify how particular orchestration problems (even provisioning or decommissioning) are solved
    • In contrast to specifying what you want as in the declarative approach
    • The use of process languages comes with the advantages of graphical modeling tools for orchestrations, advanced features of robustness, parallelism etc.
    • Note, that using a process language (in contrast to the use of scripting languages, for example) is not the characterizing aspect of an imperative approach but the explicit specification of orchestration is
  • This is similar to IMS/DB, e.g.: You must specify HOW to navigate through hierarchical data structures, HOW to cut out which data,...
declarative approach there is no miracle
Declarative Approach:There is No Miracle 

T

  • Certain management actions can be automatically derived from the topology
    • E.g. plans can be generated, or a generic „topology interpreter“ dynamically derives management action, or...
    • Again, this requires precisely defined semantics of types and interfaces

Derive

From

N1

O

TR

T4

N2

N3

+

T5

T2

+

T1

R‘

R

T6

T3

N4

N5

N6

declarative imperative
Declarative - Imperative
  • Simplicity 
  • No requirement for additional middleware
  • Restricted support of management behavior
  • Only straightforward orchestration features 
  • Hard to support complex topologies
  • Precise definition of semantics required
  • Support of any management behavior
  • Advanced orchestration features
  • Additional skills required
  • Additional middleware required
  • Increased maintenance effort
in practice
In Practice...
  • ...a combination of both approaches is likely
  • Use declarative approach for „straightforward“ management actions like initial deployment, decommissioning
  • Use imparative approach for more complex actions like selective patches, version upgrades, user/license management,...
the key problem behind the api
The Key Problem Behind the API

op

effects

N

  • A step in a plan invokes the operation of a node template
  • This operation has some effects on the real world
    • E.g. allocation of a set of IP Addresses
  • These effects must be known at a later point in time, e.g. within other plans run at a later point in time
  • How can a plan get aware of the effects achieve by former plans that invoked node type operations?

invokes

T

solution first attempt
Solution: First Attempt
  • The operation invoked (to be more precise: the corresponding implementation artifact) gathers all the data it needs to know from proprietary interfaces within the proprietary environment

?

Implementation

Artifact

?

?

?

op

effects

N

invokes

T

suitability of this solution
Suitability of This Solution
  • This solution results in highly complex implementation artifacts!
  • Implementing an operation becomes tightly coupled with a particular environment and the proprietary interfaces offered there
  • Often, an operation requires data about effects produced by several other operations before, i.e. the retrieval of this data becomes significantly complex
  • To simplify the development of implementation artifacts, such logic should be separated (i.e. split out)
solution second attempt
Solution: Second Attempt

op

effects

N

  • Build a plan in such a way that the data required by a node type operation invoked by a task is retrieved by a separate task („pre-Task“)
  • This pre-Task knows where to retrieve the data within a particular environment
    • E.g. from a local CMDB

invokes

pre-T

T

?

suitability of this solution1
Suitability of This Solution
  • This solution results in non-portable plans!
    • The pre-Task accesses proprietary interfaces to retrieve data about former effects of plans
  • Thus, operational behavior of Cloud Applications is not achieved: A conflict with TOSCA goals!
solution third attempt
Solution: Third Attempt

op

effects

N

  • A standardized API (a Plan Portability API) is made available that allows to retrieve effects of former operations
  • The pre-Task is bound to proper functions of this API

invokes

pre-T

T

Plan Portability API

State of Instancesof service templates

suitability of this solution2
Suitability of This Solution
  • The tasks within a plan are no longer dependent on proprietary interfaces to access information of effects of operations
  • Remaining Problem: How is the information about effects achieved made available to the API?
complete solution
Complete Solution

op

effects

N

  • The effects achieved by an operation are often reflected by the return data of the operation
  • Thus, this return data is passed to a post-Task of the task bound to the operation, and this post-Task uses the Plan Portability API to store this data
  • From then on, the effects achieved by an operation is available in the environment in a portable manner!

invokes

pre-T

T

post-T

Plan Portability API

State of Instancesof service templates

summary
Summary
  • The (Plan) Portability API is not an API providing functions of the container itself
    • Thus, it seems to be in scope in compliance with the TOSCA charter
  • Without the (Plan) Portability API portability of operational behavior of Cloud Applications is not given
    • Thus, we will miss the goals set in the TOSCA Charter!
  • The (Plan) Portability API is a necessary and integral aspect of TOSCA