Building ApplicaJons for the Cloud: The Wrong, the Right, the Solid Way

University  of  Stu/gart   Universitätsstr.  38   70569  Stu/gart   Germany   Phone    +49-­‐711-­‐685  88470   Fax  +49-­‐711-­‐685  88472  

Prof.  Dr.  Frank  Leymann  

InsJtute  of  Architecture  of  ApplicaJon  Systems   [email protected]­‐stu/gart.de  

Building  ApplicaJons  for  the  Cloud:  

The  Wrong,  the  Right,  the  Solid  Way  

2  

Moving  Images  

(The  Wrong  Way)  

Sample  Applica-on  

Web Server Account Management (EJBs) Account DBMS GUI Rendering (Browser) Marketing Campaigns (Assemblies) … Marketing CMS … DBMS Account DB Marketing DB … DB

JEE Server .Net App Server … App Server

GUI Handling (Servlets)

PresentaJon  

Layer  

Data  Access  

Layer  

Business  Logic  

Layer  

©  Frank  Leymann   4  

Packaging  in  a  Virtual  Machine  

   

n

 

Now,  you  package  the  

whole  applicaJon  into  a  

single  virtual  machine  and  

move  it  to  the  cloud  

n

 

Customers  start  using  it  

from  their  browsers  

n

 

They  like  it,  and  more  and  

more  are  using  it  J  

n

 

Thus,  you  need  to  scale!  

Web Server Account Management (EJBs) Account DBMS GUI Rendering (Browser) Marketing Campains (.Net Assemblies)) … Marketing CMA … DBMS Account DB MarketingD B … DB JEE App Server .Net App Server … App Server

GUI Handling (Servlets) GUI Rendering (Browser) GUI Rendering (Browser) GUI Rendering (Browser) GUI Rendering (Browser)

Scaling  Based  on  VMs  

n

 

You  instanJate  a  second  VM  

containing  your  applicaJon  in  the  

cloud  

n

 

Thus,  your  customers  are  happy!  

n

 

But,  what  about  you?  

n 

How  many  licenses  of  App  Servers,  DBMS,  

CMS,…  do  you  have  to  pay?  

n 

For  example,  if  the  customers  use  the  

Account  features  mostly,  why  do  you  

replicate  the  MarkeJng  stack  and  pay  for  the  

corresponding  licenses?  

n 

What  about  your  Account  DB  geeng  out  

of  sync?  

n 

Storage  is  associated  with  single  VM,  but  

updates  need  to  be  synchronized  across  VMs  

to  result  in  consistent  data  

©  Frank  Leymann   6  

Solving  Scaling  Related  Problems:  First  Step  

   

n

 

You  package  the  different  

stacks  of  your  applicaJons  

into  separate  VMs  

n

 

You  persist  your  data  in  

storage  features  of  the  

cloud  (“Data  as  a  Service”)  

n 

Data  can  then  be  shared  

when  scaling  out  

n

 

This  enables  replicaJon  of  

individual  stacks  for  scaling  

n 

Avoiding  the  problems  

indicated  before  (licensing,  

data  consistency,…)  

Web Server Account Management (EJBs) Account DBMS GUI Rendering (Browser) Marketing Campains (.Net Assemblies)) … Marketing CMA … DBMS Account DB MarketingD B … DB

JEE App Server .Net App Server … App Server GUI Handling (Servlets) GUI Rendering (Browser) GUI Rendering (Browser) GUI Rendering (Browser) GUI Rendering (Browser)

Scaling  Related  Problems:  Further  Granularity  Issues  

n 

When  a  parJcular  stack  is  

under  high  request  load,  

it  can  be  scaled  by  

starJng  mulJple  

instances  of  the  

corresponding  VMs  

n 

Data  is  shared  between  

these  VMs  because  

database  content  is  

stored  in  storage  features  

of  IaaS  

n 

But  maybe  the  underlying  

DBMS  can  sustain  the  

load  generated  by  many  

App  Servers?  

n 

I.e.  license  cost  can  be  

reduced,  etc  

Web Server Account Management (EJBs) Account DBMS GUI Rendering (Browser) Marketing Campains (.Net Assemblies)) … Marketing CMA … DBMS Account DB MarketingD_B … DB JEE App Server .Net App Server … App Server

GUI Handling (Servlets) GUI Rendering (Browser) GUI Rendering (Browser) GUI Rendering (Browser) GUI Rendering (Browser) Account Management (EJBs) Account DBMS JEE App Server

Be/er  scaling  of   the  “Account  Stack”  

©  Frank  Leymann   8  

Proper  Granularity  for  Scaling  

   

n

 

You  package  

“appropriate”  

components  of  your  

applicaJon  in  separate  

VMs  so  that  they  can  

scale  independently  

n

 

Now  mulJple  VMs  

containing  the  App  

Server  can  use  the  

same  DBMS  

n

 

But  the  DBMS  in  the  

separate  machine  

needs  maintenance  

n

 

Do  you  want  to  do  it  

by  yourself?  

Web Server Account Management (EJBs) GUI Rendering (Browser) Marketing Campains (.Net Assemblies)) … Marketing CMA … DBMS Account DB MarketingD_B … DB

JEE App Server .Net App Server … App Server GUI Handling (Servlets) GUI Rendering (Browser) GUI Rendering (Browser) GUI Rendering (Browser) GUI Rendering (Browser) Account Management (EJBs) Account DBMS JEE App Server

Consequences  of  Proper  Granularity  

n

 

Next  step  is  to  

consider  features  

provided  by  the  cloud  

environment  that  may  

subsJtute  components  

of  your  VMs  

n

 

For  example,  DBMS,    

App  Server  

n 

E.g.  Amazon  SimpleDB,  

Google  AppEngine,…  

Web Server Account Management (EJBs) GUI Rendering (Browser) Marketing Campains (.Net Assemblies)) … Marketing CMA DBMS Account DB MarketingD_B … DB

.Net App Server

… App Server GUI Handling (Servlets) GUI Rendering (Browser) GUI Rendering (Browser) GUI Rendering (Browser) GUI Rendering (Browser) Account Management (EJBs) DBMS JEE App Server

©  Frank  Leymann   10  

Towards  “Cloud  Na-ve”  

   

n

 

Next,  elasJcity  (i.e.  

on-­‐demand  scale-­‐in  &  

scale-­‐out)  requires…  

n

 

Loose  coupling  of  

components  

n

 

AutomaJc  start/stop  

of  instances  of  

components  

n

 

Stateless  components  

n

 

…  

Web Server GUI Rendering (Browser) Marketing Campains (.Net Assemblies)) Marketing CMA DBMS Account DB MarketingD_B … DB

.Net App Server

… App Server GUI Handling (Servlets) GUI Rendering (Browser) GUI Rendering (Browser) GUI Rendering (Browser) GUI Rendering (Browser) DBMS JEE App Server

PaaS PaaS Account Management (EJBs) Account Management (EJBs) IaaS …

©  Frank  Leymann   12  

“Cloud  Na-ve”  -­‐  Sketch  

   

n

 

Your  applicaJon  

finally  became  

n

 

Clusterable  

n

 

ElasJc  

n

 

…

 

Web Server GUI Rendering (Browser) Marketing Campains (.Net Assemblies)) Marketing CMA DBMS Account DB MarketingD_B … DB

.Net App Server

… App Server GUI Handling (Servlets) GUI Rendering (Browser) GUI Rendering (Browser) GUI Rendering (Browser) GUI Rendering (Browser) DBMS JEE App Server

PaaS Account Management (EJBs) Account Management (EJBs) IaaS … Queing PaaS

14  

How  to  Get  to  the  Best  Way:  

A  Glimpse  at  Cloud  Pa/erns  

Na-ve  Cloud  Applica-on  Proper-es  -­‐  Exploiter  View  

n

 

Clusterability  

n

 

ElasJcity  

n

 

MulJ-­‐Tenancy  

n

 

Pay-­‐per-­‐Use  

n

 

Self-­‐Service  

©  Frank  Leymann   16  

?

Clusterability  

n

 

ApplicaJon  must  be  implemented  as  a  distribute  

applicaJon  

n

 

ApplicaJon  consist  of  several  types  of  components  

each  of  which  can  be  instanJated  mulJple  Jmes,  

run  concurrently  and  are  loosely  coupled  

n

 

Consequences:  

n

 

Instances  of  a  type  of  component  may  run  on  different  

machines  

Elas-city  

n

 

The  applicaJon  (more  precisely:  any  of  its  

components)  should  be  able  to  scale  up  and  to  

scale  down  –  dependent  on  actual  load  

n

 

Consequences:  

n

 

ApplicaJon  should  be  stateless  

n

 

A  separate  “watchdog”  starts  and  stops  instances  of  the  

applicaJons  component  dynamically  

n 

Watchdog  is  steered  by  policies  that  specify  condiJons  under  

©  Frank  Leymann   18  

Mul--­‐Tenancy  

n

 

ApplicaJon  should  be  able  to  support  isolated  

tenants  

n

 

ApplicaJon  should  be  able  to  exploit  mulJ-­‐tenant  

middleware  

n

 

Note:  MulJ-­‐tenancy  does  not  mean  isolaJon  by  

associaJng  each  tenant  with  a  separate  copy  of  the  

applicaJon  stack  in  one  or  more  dedicated  virtual  

machines  (!)  

Pay-­‐per-­‐Use  

n

 

This  is  enabled  by  granular  metering  and  billing  

n

 

The  actual  use  of  each  component  within  the  applicaJon  

stack  must  be  able  to  be  monitored,  tracked,  metered,…  

n

 

Tenant  pays  for  use  of  applicaJon  funcJons,  not  for  

provisioning,  reservaJon,…  of  resources  required  

by  the  applicaJon  

©  Frank  Leymann   20  

Self-­‐Service  

n

 

Each  tenant  can  provision,  manage,…  “his”  

applicaJon  on  its  own,  whenever  he  decides  to  do  

so  

n

 

No  separate  administraJve  staff  (at  cloud  provider)  is  

needed  to  the  set  the  applicaJon  up,  configure  it,  run  it,  

manage  it  

n

 

Self-­‐Service  applies  to  each  component  of  the  

applicaJon  (including  plaporm,  infrastructure,…)  

n

 

Otherwise,  there  wouldn’t  be  real  improvements  in  

IDEAL  Principle:    

Na-ve  Cloud  Applica-on  Proper-es  -­‐    Architects  View  

D

istribution: applications are decomposed to…

… use multiple cloud resources

… support the fact that clouds are large globally distributed systems

E

lasticity: applications can be scaled out dynamically

Scale out: performance increase through addition of resources Scale up: performance increase by increasing resource capabilities

?

L

oose Coupling: influence of application components is limited

Example: failures should not impact other components Example: addition / removal of components is simplified

I

solated State: most of the application is stateless with respect to:

Session State: state of the communication with the application Application State: data handled by the application

(detailed Notion of State later)

A

utomated Management: runtime tasks have to be handled quickly

Example: exploitation of pay-per-use by changing resource numbers Example: resiliency by reacting to resource failures

22  

Topology  and  OrchestraJon  

(The  Right  Way)  

What  We  Understood  So  Far  

n

 

So,  your  applicaJon  is  

componenJzed  

n

 

You  specify  all  middleware  

and  infrastructure  the  

applicaJon  needs  

n

 

You  specify  all  relaJons  

between  these  pieces  and  

what  the  nature  of  that  

relaJons  are  

n

 

You  specified  the  

topology

 

of  the  applicaJon  

Web Server GUI Rendering (Browser) Marketing Campains (.Net Assemblies)) Marketing CMA DBMS Account DB MarketingD_B … DB .Net App Server … App Server

GUI Handling (Servlets) GUI Rendering (Browser) GUI Rendering (Browser) GUI Rendering (Browser) GUI Rendering (Browser) DBMS JEE App Server Account Management (EJBs) Account Management (EJBs) …

©  Frank  Leymann   24  

Imagine…  

n

 

…that  you  have  a  nice  applicaJon  that  you  want  to  be  

able  to  be  hosted  in  different  clouds  

n

 

Why  do  you  want  that?  

n

 

Because  you  don’t  want  to  be  locked  into  the  plaporm  of  a  

single  cloud  provider,  or  

n

 

Because  you  start  in  your  own  private  cloud  and  want  to  be  

able  to  move  it  to  public  cloud  or  to  some  community  

cloud  or  to  hybrid  cloud  

What  are  the  Technical  Problems?  

n

 

No  interoperable  descripJon  exists  of  what  your  

applicaJon  is  and  what  it  requires  

n

 

Another  provider  might  not  have  a  clue  how  to  install,  

deploy,  run  &  manage  your  applicaJon  

n

 

Deep  detailed  skills  about  the  applicaJon  and  its  

underlying  stack  is  needed  that  “arbitrary”  providers  

typically  don’t  have  

©  Frank  Leymann   26  

We  Need  a  Standard  to  Describe  Cloud  Applica-ons  

A  language  (“metamodel”)  to  specify  

n

 

the  building  blocks  of  your  applicaJon  

n

 

the  management  funcJons  these  

building  blocks  offer  to  be  managed  

n

 

the  relaJons  between  these  building  blocks  

n

 

the  procedures  to  follow  in  order  to  manage  

your  applicaJon  as  a  whole  

Node   Types   Rel.ship   Types   Plans   Topology   (Template)   (C loud)   Se rv ic e   Te m plate  

The  Graphical  Representa-on  of  This  Language  

Pro

perJ

es

 

In

te

rfac

es

 

Topology  Template  

type  for  

Node  Type  

RelaJonship  

Template  

Service  Template  

Node  Types  

Plans  

type  for  

Pro

perJ

es

  RelaJonship  Type  

RelaJonship  Types  

_In

te

rfac

es

 

Requirement  Types  

Capability  Types  

Node  

Template  

©  Frank  Leymann   28  

…and  More  Colorful…  

…and  With  Angular  Brackets…  

 

<DefiniJons  id="xs:ID”  name="xs:string”?  targetNamespace="xs:anyURI">            <Extensions/>?        <Import  />*      <Types/>?      (    <ServiceTemplate/>      |  <NodeType/>      |  <NodeTypeImplementaJon/>      |  <RelaJonshipType/>      |  <RelaJonshipTypeImplementaJon/>      |  <RequirementType/>      |  <CapabilityType/      |  <ArJfactType/>      |  <ArJfactTemplate/>      |  <PolicyType/>      |  <PolicyTemplate/>      )  +     </DefiniJons>    

©  Frank  Leymann   30  

Sample:  SugarCRM  Topology  Template  

VM-­‐Apache   (VirtualMachine)   OS-­‐Apache   (OperaJngSystem)   ApacheWebServer   (ApacheWebServer)   SugarCRM  App   (SugarCrmApp)   PHP  Module   (PhpModule)   HostedOn   HostedOn   HostedOn   HostedOn   DependsOn   VM-­‐MySQL   (VirtualMachine)   OS-­‐MySQL   (OperaJngSystem)   MySQL   (MySQL)   SugarCRM  DB   (SugarCrmDb)   HostedOn   HostedOn   HostedOn   ConnectsTo   Web  Tier   (Tier)   HostedOn   DB  Tier   (Tier)   HostedOn  

©  Frank  Leymann   32  

How  Plans  and  Nodes  Fit  Together  

n 

Task  of  a  plan  refers  to  interface  of  a  topology  node  

 

 

n 

Topology  node  specifies  all  interfaces  offered  to  

manage  it  

n 

Interface  is  bound  to  a  concrete  implementaJon  

n 

ImplementaJon  already  available  at  providers  side,  or  

n 

ImplementaJon  is  copied  from  CSAR  (Cloud  Service  

ARchive),  or  

n 

A  standardized  Cloud  Interface  (Iaas,  PaaS,  SaaS)  is  

used,  or  ...  

MySQL  

…

Create  DB   Tier  

…

…

Script   -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐     -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐     -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐     -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐     -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐   …refers to… …bound to…

Defini-ons  File:  Overall  Structure  

 

<DefiniJons  id="xs:ID”  name="xs:string”?  targetNamespace="xs:anyURI">            <Extensions/>?        <Import  />*      <Types/>?      (    <ServiceTemplate/>      |  <NodeType/>      |  <NodeTypeImplementaJon/>      |  <RelaJonshipType/>      |  <RelaJonshipTypeImplementaJon/>      |  <RequirementType/>      |  <CapabilityType/      |  <ArJfactType/>      |  <ArJfactTemplate/>      |  <PolicyType/>      |  <PolicyTemplate/>      )  +     </DefiniJons>    

©  Frank  Leymann   34  

Node  Type:  Overall  Structure  

   

     <NodeType  name="xs:NCName"  targetNamespace="xs:anyURI"?  

                                                 abstract="yes|no"?  final="yes|no"?>+  

 

           <Tags/>?  

           <DerivedFrom  nodeTypeRef="QName"/>?  

           <ProperJesDefiniJon  element="Qname"?    

                 type="QName"?/>?  

           <RequirementDefiniJons/>?  

           <CapabilityDefiniJons/>?  

           <InstanceStates/>?  

           <Interfaces/>?  

     </NodeType>  

     

Node  Type  

Example:  Node  Types  

<DefiniJons  id="MyDefiniJons"  name="My  DefiniJons"  

                         targetNamespace="h/p://www.example.com/sample">        <NodeType  name="Project">          <ProperJesDefiniJon  element="ProjectProperJes"/>          <InstanceStates>              <InstanceState  state="www.example.com/acJve"/>              <InstanceState  state="www.example.com/onHold"/>          </InstanceStates>          <Interfaces>              <Interface  name="ProjectInterface">                    <OperaJon  name="CreateProject">                      <InputParameters>  

                       <InputParamter  name="ProjectName"  type="xs:string"/>                          <InputParamter  name="Owner"  type="xs:string"/>  

                       <InputParamter  name="AccountID"  type="xs:string"/>                      </InputParameters>                  </OperaJon>                </Interface>          </Interfaces>      </NodeType>   </DefiniJons>  

©  Frank  Leymann   36  

Ar-fact  Types  

<ArJfactType  name="xs:NCName"  

                           targetNamespace="xs:anyURI"?  

                           abstract="yes|no"?  

                           final="yes|no"?>  

   

   <Tags>  

       <Tag  name="xs:string"  value="xs:string"/>  +  

   </Tags>  ?  

   

   <DerivedFrom  typeRef="xs:QName"/>  ?  

   

   <ProperJesDefiniJon  element="xs:QName"?  type="xs:QName"?/>  ?  

         

</ArJfactType>  

Invariant  properJes;  

Example:  Ar-fact  Types  

<DefiniJons  id="MyArJfacts"  name="My  ArJfacts"  

   targetNamespace="h/p://www.example.com/SampleArJfacts"      xmlns:ba="h/p://www.example.com/BaseArJfactTypes"      xmlns:map="h/p://www.example.com/SampleArJfactProperJes>            <Import  importType="h/p://docs.oasis-­‐open.org/tosca/ns/2011/12"                      namespace="h/p://www.example.com/BaseArJfactTypes"/>          <Import  importType="h/p://www.w3.org/2001/XMLSchema"                      namespace="h/p://www.example.com/SampleArJfactProperJes"/>          <ArJfactType  name="RPMPackage">          <DerivedFrom  typeRef="ba:OSPackage"/>          <ProperJesDefiniJon  element="map:RPMPackageProperJes"/>      </ArJfactType>       </DefiniJons>  

©  Frank  Leymann   38  

Ar-fact  Templates  

<ArJfactTemplate  id="xs:ID"  name="xs:string"?  type="xs:QName">          <ProperJes>          XML  fragment      </ProperJes>  ?          <PropertyConstraints>          <PropertyConstraint  property="xs:string"                                                  constraintType="xs:anyURI">  +              constraint  ?          </PropertyConstraint>      </PropertyConstraints>  ?          <ArJfactReferences>          <ArJfactReference  reference="xs:anyURI">              (    <Include  pa/ern="xs:string"/>              |  <Exclude  pa/ern="xs:string"/>    )*          </ArJfactReference>  +      </ArJfactReferences>  ?       </ArJfactTemplate>   Variant  properJes;  

e.g.  directory  where  to  store   the  arJfact  

RelaJve  URI  is  interpreted  as   pointer  into  CSAR;  

Absolute  URI  specifies  where   to  get  the  arJfact  

Can  be  used  to  define  which  files   are  collected  in  case  the  a/ribute   “references”  points  to  a  complete   directory  (e.g.  in  the  CSAR)  

Example:  Ar-fact  Templates  

<DefiniJons  id="MyArJfacts"  name="My  ArJfacts"  

   targetNamespace="h/p://www.example.com/SampleArJfacts"      xmlns:ba="h/p://www.example.com/BaseArJfactTypes">            <Import  importType="h/p://docs.oasis-­‐open.org/tosca/ns/2011/12"                      namespace="h/p://www.example.com/BaseArJfactTypes"/>          <ArJfactTemplate  id="MyInstallable"                                          name="My  installable"                                          type="ba:ZipFile">          <ArJfactReferences>              <ArJfactReference  reference="files/MyInstallable.zip"/>          </ArJfactReferences>      </ArJfactTemplate>       </DefiniJons>  

©  Frank  Leymann   40  

Node  Type  Implementa-ons  

<NodeTypeImplementaJon  name="xs:NCName"    

                 targetNamespace="xs:anyURI"?  

                 nodeType="xs:QName"  abstract="yes|no"?    final="yes|no"?>  

     

   <Tags/>  ?  

   

   <DerivedFrom  nodeTypeImplementaJonRef="xs:QName"/>  ?  

   

   <RequiredContainerFeatures>  

       <RequiredContainerFeature  feature="xs:anyURI"/>  +  

   </RequiredContainerFeatures>  ?  

   

   <ImplementaJonArJfacts/>  ?  

   

   <DeploymentArJfacts/>  ?  

   

</NodeTypeImplementaJon>  

Implementa-on  Ar-facts  

n

 

When  a  node  type  implementaJon  

is  imported,  its  implementaJon  

arJfacts  are  deployed  

n 

From  that  Jme  on,  the  operaJons  of  

the  node  types  can  be  used  in  the  

parJcular  environment  

n

 

Now,  tasks  of  the  plans  can  be  

bound  to  the  implementaJon  of  

the  operaJons  in  this  environment  

n 

I.e.  plans  are  bound  to  the  

environment  (as  usual)  in  which  they  

are  execuJng  

Node   Type  

…

Task   in  Plan  

…

_…

Script   -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐     -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐     -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐     -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐     -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐   …refers to… …bound to… ImplArtifacts Script   -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐     -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐     -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐     -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐     -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐   JAR   -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐     -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐     -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐     -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐     -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  -­‐  REST  API   (reference)   deploy

©  Frank  Leymann   42  

Rela-onship  Types  

   <RelaJonshipType  name="xs:NCName"                                          targetNamespace="xs:anyURI"?                                          abstract="yes|no"?                                          final="yes|no"?>  +              <DerivedFrom  typeRef="xs:QName"/>  ?      

       <ProperJesDefiniJon  element="xs:QName"?  type="xs:QName"?/>  ?              <InstanceStates>              <InstanceState  state="xs:anyURI">  +          </InstanceStates>  ?              <SourceInterfaces…/>?                <TargetInterfaces…/>?                <ValidSource  typeRef="xs:QName"/>  ?                <ValidTarget  typeRef="xs:QName"/>  ?          </RelaJonshipType>  

Rela-onship  Type  

NodeType  or  Requirement  Type   NodeType  or  Capability  Type  

Composi-on  of  Service  Templates  

Node   Template   Node   Template   Service Template 1 Service Template 2 can subst itute Boundary  DefiniJons  

©  Frank  Leymann   44  

Boundary  Defini-ons:  Overall  Structure  

 <BoundaryDefiniJons>          <ProperJes>              XML  fragment              <PropertyMappings/>  ?          </ProperJes>  ?          <PropertyConstraints/>  ?          <Requirements/>  ?          <CapabiliJes/>  ?          <Policies/>  ?            <Interfaces>              <Interface  name="xs:NCName">                  <OperaJon  name="xs:NCName">  

                   (  <NodeOperaJon  nodeRef="xs:IDREF"                                                        interfaceName="xs:anyURI"                                                        operaJonName="xs:NCName"/>  

                   |  <RelaJonshipOperaJon  rela-onshipRef="xs:IDREF"                                                                        interfaceName="xs:anyURI"  

                                                                     operaJonName="xs:NCName"/>                      |  <Plan  planRef="xs:IDREF"/>  

                   )  

               </OperaJon>  +              </Interface>  +          </Interfaces>  ?    

Plans  

<Plans>      <Plan  id="ID"                  name="string"?                  planType="anyURI"                  languageUsed="anyURI”>              <PreCondiJon  expressionLanguage="anyURI">?                    condiCon            </PreCondiJon>          <InputParameters>  

                 <InputParameter  name="xs:string"  type="xs:string"                                                    required="yes|no"?/>  +  

             </InputParameters>  ?                  <OutputParameters>  

                 <OutputParameter  name="xs:string"  type="xs:string"                                                      required="yes|no"?/>  +  

             </OutputParameters>  ?  

         (  <PlanModel>    actual  plan  </PlanModel>            |  

           <PlanModelReference  reference="anyURI"/>    )        </Plan>+        

</Plans>  

©  Frank  Leymann   46  

Example:  Plans  

<Plans>  

   

   <Plan  id="DeployApplicaJon"  

               name="Sample  ApplicaJon  Build  Plan"                  planType=  

                   "h/p://www.example.org/STE/PlanTypes/BuildPlan"                  languageUsed="h/p://www.omg.org/spec/BPMN/2.0/">      

         <PreCondiJon  expressionLanguage="www.my.com/text">?                    Run  only  if  funding  is  available  

         </PreCondiJon>      

       <PlanModel>  

           <process  name="DeployNewApplicaJon"  id="p1">                  <task  id="t1"  name="CreateAccount"/>  

               <task  id="t2"  name="AcquireNetworkAddresses"                              isSequenJal="false"  

                           loopDataInput="t2Input.LoopCounter"/>  

               <sequenceFlow  id="s1"  targetRef="t2"  sourceRef="t1"/>                  ...              </process>          </PlanModel>       ...         ...        <Plan  id="RemoveApplicaJon"                  planType=                  "h/p://www.example.org/STE/PlanTypes/TerminaJoPlan"                  languageUsed=                    "h/p://docs.oasis-­‐open.org/wsbpel/…/executable">          <PlanModelReference  reference="prj:RemoveApp"/>        </Plan>       </Plans>  

Cloud  Service  Archive  (CSAR)  

Cloud  Service  Archive  

Service  Template   Deployment  Ar-facts  

OVF   -­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐   OVF   OVF   Scripts   Workflows   Images  

How  ...  

With  ...  

Cloud  Service  Archive  (CSAR)  as  self-­‐contained  packaging  

format  for  Cloud  Services,  including  a  Service  Template  with  

Management  Plans,  and  arJfacts  supporJng  the  Service  

©  Frank  Leymann   48  

Refined  &  Colorful  View  on  CSARs  

How  ...

 

-­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐   -­‐-­‐-­‐-­‐  

OVF  

OVF  

OVF  

With  ...

 

Scripts   Workflows   EAR  (EJBs,…)   BPEL  

The  images  of  the   middleware  (DB2,   Websphere,…)   required  to  run  the   applicaJon  

The  business  logic  of   the  applicaJon,  e.g.   EJBs,  JSPs,  JPEG,…   The  business  

processes  of  the   applicaJon  (BPEL,   BPMN,  Human   Tasks,…)  

(ExisJng)  scripts  used   by  task  of  plans  to   manage  the  cloud   applicaJon  

(ExisJng)  workflows  used  by   subprocess-­‐tasks  of  plans  

©  Frank  Leymann   50  

A  Sample  Topology  

CustomerDB  

(RDB)  

MyDBMS  

(RDBMS)  

MyBlockStore  

(BlockStore)  

CustomerDB_on_MyDBMS  

(RDB_HostedOn_RDMBS)  

MyBlockStore_For_MyDBMS  

(BlockStore_For_RDBMS)  

Allocate()  

Install()  

A/ach()  

...And  Its  

Declara0ve

 Processing  

n

 

In  a  declaraJve  mode  of  

processing,  the  environment  

does  understand  the  specific  

processing  requirements  of  all  

types  

n 

Node  types  

n 

RelaJonship  types  

n 

...  

n

 

It  further  understands  the  

dependencies  of  all  these  types  

n 

E.g.  that  hosted_on  relaJonships  

must  be  processed  before  

connected_to  relaJonships

 

CustomerDB   (RDB)   MyDBMS   (RDBMS)   MyBlockStore   (BlockStore)   CustomerDB_on_MyDBMS   (RDB_HostedOn_RDMBS)   MyBlockStore_For_MyDBMS   (BlockStore_For_RDBMS)   Allocate()   Install()   A/ach()  

PRO:  For  provisioning  and  decommissioning,  no  plans  need  to  be  specified  

©  Frank  Leymann   52  

A  Sample  Topology  With  Plans  

CustomerDB   (RDB)   MyDBMS   (RDBMS)   MyBlockStore   (BlockStore)   CustomerDB_on_MyDBMS   (RDB_HostedOn_RDMBS)   MyBlockStore_For_MyDBMS   (BlockStore_For_RDBMS)   Allocate()   Install()   A/ach()   Get  

Storage   DBMS  Install   Storage  A/ach  

...  

CustomerDB   (RDB)   MyDBMS   (RDBMS)   MyBlockStore   (BlockStore)   CustomerDB_on_MyDBMS   (RDB_HostedOn_RDMBS)   MyBlockStore_For_MyDBMS   (BlockStore_For_RDBMS)   Allocate()   Install()   A/ach()   Get  

Storage   DBMS  Install   Storage  A/ach  

...  

Build  Plan  

...And  Its  

Impera0ve

 Processing  

n

 

In  a  imperaJve  mode  of  

processing,  the  environment  

is  not  dependent  on  a  

precise  interpretaJon  of  the  

types

 

n

 

All  that  interpretaJon  is  

done  by  plans  

PRO:  No  precise  definiJon  of  all  types,  their  processing,  their  behavior,…  needed    

54  

OpenTOSCA:  

CreaJon  and  modeling  of  TOSCA  applicaJons,  including  graphical  

modeling  of  topologies  and  management  plans.  Exported  as  Cloud  

Service  Archive  (CSAR)  for  TOSCA  runJme.  

©  Frank  Leymann   56  

TOSCA  runJme  &  middleware  

Processes  CSARs,  runs  plans,  manages  state,  …  

Offering  the  deployed  CSARs  to  the  

end  user  for  easy  instanJaJon  

Container

Self-Service

58  

Cloud  CompuJng  Pa/erns  

(The  Solid  Way)  

1

Christoph Fehling · Frank Leymann · Ralph Retter · Walter Schupeck · Peter Arbitter

Cloud Computing Patterns

Fundamentals to Design, Build, and Manage Cloud Applications

Cloud Computing

Patterns

Christoph Fehling  Frank Leymann

Ralph Retter · Walter Schupeck

Peter Arbitter

Computer Science Cloud C omputing P att erns

Fundamentals to Design, Build,

and Manage Cloud Applications

Th is book provides CIOs, soft ware architects, project managers, developers, and cloud strategy initiatives with a set of archi-tectural patterns that off er nuggets of advice on how to achieve common cloud computing-related goals. Th e cloud computing patterns capture knowledge and experience in an abstract format that is independent of concrete vendor products. Readers are provided with a toolbox to structure cloud computing strategies and design cloud application architectures. By using this book cloud-native applications can be implemented and best suited cloud vendors and tooling for individual usage scenarios can be selected. Th e cloud computing patterns off er a unique blend of academic knowledge and practical experience due to the mix of authors. Academic knowledge is brought in by Christoph Fehling and Professor Dr. Frank Leymann who work on cloud research at the University of Stuttgart. Practical experience in building cloud applications, selecting cloud vendors, and designing enterprise architecture as a cloud customer is brought in by Dr. Ralph Retter who works as an IT architect at T Systems, Walter Schupeck, who works as a Technology Manager in the fi eld of Enterprise Architecture at Daimler AG, and Peter Arbitter, the former head of T Systems’ cloud architecture and IT portfolio team and now working for Microsoft .

Voices on Cloud Computing Patterns

Cloud computing is especially benefi cial for large companies such as Daimler AG. Prerequisite is a thorough analysis of its impact on the existing applications and the IT architectures. During our collaborative research with the University of Stuttgart, we identifi ed a vendor-neutral and structured approach to describe properties of cloud off erings and requirements on cloud environments. Th e resulting Cloud Computing Patterns have profoundly impacted our corporate IT strategy regarding the adoption of cloud computing. Th ey help our architects, project managers and developers in the refi nement of architectural guidelines and communicate requirements to our integration partners and soft ware suppliers.

Dr. Michael Gorriz – CIO Daimler AG

Ever since 2005 T-Systems has provided a fl exible and reliable cloud platform with its “Dynamic Services”. Today these cloud services cover a huge variety of corporate applications, especially enterprise resource planning, business intelligence, video, voice communication, collaboration, messaging and mobility services. Th e book was written by senior cloud pioneers shar-ing their technology foresight combinshar-ing essential information and practical experiences. Th is valuable compilation helps both practitioners and clients to really understand which new types of services are readily available, how they really work and importantly how to benefi t from the cloud.

Dr. Marcus Hacke – Senior Vice President, T-Systems International GmbH

Th is book provides a conceptual framework and very timely guidance for people and organizations building applications for the cloud. Patterns are a proven approach to building robust and sustainable applications and systems. Th e authors adapt and extend it to cloud computing, drawing on their own experience and deep contributions to the fi eld. Each pattern includes an extensive discussion of the state of the art, with implementation considerations and practical examples that the reader can apply to their own projects.

By capturing our collective knowledge about building good cloud applications and by providing a format to integrate new insights, this book provides an important tool not just for individual practitioners and teams, but for the cloud computing community at large.

Kristof Kloeckner – General Manager, Rational Soft ware, IBM Soft ware Group

9 783709 115671 I SBN 978 - 3 - 7091 - 1567 - 1 Fe hlin g · L eym an n Rett er · S chupeck · Arbitt er

©  Frank  Leymann   60  

Cloud  Compu-ng  Fundamentals  

StaCc  

Workload   Workload  Periodic   Once-­‐in-­‐a-­‐lifeCme  Workload   Unpredictable  Workload   ConCnuously  Changing   Workload   Infrastructure  

as  a  Service     as  a  Service  PlaOorm   as  a  Service  SoPware  

Public  

Cloud  Offering  Pakerns  

ElasCc  

Infrastructure   PlaOorm  ElasCc   Node-­‐based  Availability   Environment-­‐based  Availability  

Hypervisor   ExecuCon  

Environment   Map  Reduce  

Block  

Storage   Storage  Blob   RelaConal  Database   Key-­‐value  Storage   Consistency  Strict   Consistency  Eventual  

©  Frank  Leymann   62  

Cloud  Applica-on  Architecture  Pakerns  

Loose  

Coupling   ApplicaCon  Distributed   Component  Stateful     Component  Stateless   User  Interface  Component   Component  Processing  

Batch  Processing  

Component   Data  Access  Component   Abstractor  Data   Idempotent  Processor   TransacCon-­‐based  Processor  

Timeout-­‐based   Message   Processor  

MulC-­‐component  

Image   Component  Shared   Tenant-­‐isolated  Component   Component  Dedicated   Access  Component  Restricted  Data   Message  Mover  

ApplicaCon  

Cloud  Applica-on  Management  Pakerns  

Provider  

Adapter   ConfiguraCon  Managed   Manager  ElasCcity   Load  Balancer  ElasCc   ElasCc  Queue   Watchdog  

ElasCcity   Management   Process   Feature  Flag   Management   Process   Update   TransiCon   Process   Standby   Pooling   Process   Resiliency   Management   Process  

©  Frank  Leymann   64  

Composite  Cloud  Applica-on  Pakerns  

Two-­‐Tier  Cloud  

ApplicaCon   Three-­‐Tier  Cloud  ApplicaCon   buCon  Network  Content  Distri-­‐  

Hybrid  

User  Interface   Processing  Hybrid   Hybrid  Data   Backup  Hybrid   Backend  Hybrid   ApplicaCon  Hybrid   FuncCons   Hybrid  MulCmedia  

Web  ApplicaCon   Development  Hybrid   Environment  

Pakern  Languages  

(s,g,…)  

(s’,g’,…)  

(s”,g”,…)  

s:  SemanJcs   g:  Goal    

P

₆  

P

₅  

P

₇  

P

₄  

P

₃  

P

₂  

P

₁   ...   ...   ...   ...   ...  

©  Frank  Leymann   66  

Research:  Pakerns  and  Associated  Solu-ons  

…  

S

₁  

S

₂  

S

_m  

(c

₁₁

,…,c

_1n(1)

)  

P  

(c

₂₁

,…,c

_2n(2)

)  

(c

_m1

,…,c

_mn(m)

)  

Solu-on  Paths  (“Yes,  there  is  a  naming  conflict”  

L

)

 

(s,g,…)  

(s’,g’,…)  

(s”,g”,…)  

P

₆  

P

₅  

P

₇  

P

₄  

P

₃  

P

₂  

P

₁   ...   ...   ...   ...   ...  

©  Frank  Leymann   68  

Research:  Solu-on  Aggrega-on  

⊕

 

???  

SoluJon  Path  

Aggregated  SoluJon  

(c,…)  

(c’,…)  

P

 

P’

 

Aggrega-on  Operator  

n

 

An  AggregaJon  Operator  

combines  solu-ons  on  the  

level  of  Solu-on  

n

 

Each  pa/ern  language  has  specific  Aggrega-on  

Operators  

n

 

Pa/ern  Language  of  a  specific  domain    

à

 AggregaJon  Operators  

combine  concrete  ar-facts  

of  

this  specific  domain  

n

 

Example  

n 

An  AggregaJon  Operator  of  a  pa/ern  language  dealing  with  

so•ware  design  pa/erns  may  simply  combine  programming  code  

©  Frank  Leymann   70  

n

 

AggregaJon  depends  on  

PrecondiCons

 and  

PostcondiCons  of  SoluJons  

n

 

PrecondiJons  and  PostcondiJons  may  define  

func-onal  and  non-­‐func-onal  dependencies  

between  SoluJons  

precondiJons    

postcondiJons  

Approach:  Precondi-ons  and  Postcondi-ons  

P’

  (s,g,…)  

P’’

 

S

₂

 

S

₅

 

precondiJons     postcondiJons  

⊕

 

✔

 

✔

 

Scenario  

n

 

We  plan  to  migrate  an  applica-on  to  a  cloud  

environment  

n

 

Then  we  want  to  elas-cally  scale  the  applicaJon  

based  on  actual  workloads  and  load  balance  between  

the  instances  

Data  Center  

Load  Balancer  

AppX  

AppX  

AppX  

AppX  

Req  _{Req  Req  Req  Req}  

©  Frank  Leymann   72  

Scenario  

n

 

First  of  all  we  use  the  Forklim  Migra-on  Pa/ern  to  

migrate  our  AppX  to  the  cloud  

n

 

Then  this  pa/ern  points  us  to  the  Elas-city  

Management  Process  Pa/ern  which  tells  us  how  to  

scale  and  load  balance  between  several  instances  of  

AppX  

©  Frank  Leymann   73  

⊕

 

sc={PHP  will  be     scaled  

,…}   sc={WAR  will  be    

deployed  on     Azure  

,…}  

sc={WAR  will  be     deployed  on     Beanst.  ,…}  

Scenario:  Management  Planlets  

Forkli•  MigraJon

 

ElasJcity  Management  

_Process  

SI

_1.1

 

SI

_1.2

 

SI

_2.1

 

SI

_2.2

 

sc={WAR  will  be     scaled  

,…}   precondiJon:    

WAR  file  

postcondiJon:    

WAR  on  Azure  

 

precondiJon:    

WAR  file  

postcondiJon:    

WAR  on  Elas-c   Beanstalk  

 

precondiJon:    

WAR  on  Elas-c     Beanstalk  

postcondiJon:    

WAR  is  scaled  

  precondiJon:     ...   postcondiJon:     ...     Management     Planlets  

✔

 

✔

 

Aggregated   (s,g,…)  

⊕

 

74  

Summary  

n

 

Capturing  images  of  an  applicaJon  and  bursJng  it  to  

the  cloud  is  the  wrong  way  

n

 

You  loose  most  benefits  of  the  cloud  

n

 

Re-­‐factoring  your  applicaJon  into  components  

explicitly  specifying  its  use  of  middleware  and  

infrastructure  (“topology”)  as  well  as  its  management  

behavior  (“orchestraJon”)  is  the  write  way  

n

 

There  are  standards  that  ensure  that  an  applicaJon  

can  be  run  in  mulJple  cloud  environments  

n

 

Cloud  CompuJng  Pa/erns  guide  a  proper  structuring  

76