1. T-Systems ODCA Service Orchestration with TOSCA PoCT-Systems, T-Labs, FZI strictly confidential, confidential, internal, public 9/26/2014 1

2. Agenda9/26/2014 2 Brief PoC Overview Q&A General Comments & Recommendations 3. PoC Overview 4. 9/26/2014 4AbstractIn context of machine level service orchestration: Define an application stack Package the Application stack using TOSCA Trigger the deployment/un-deployment of the application to/from a targetplatformThereby determine: General capabilities and specificity of TOSCA Opportunities, shortfalls and challenges when using TOSCA for ServiceOrchestration Current level of industry tools which support TOSCA General acceptance levels in the industry for TOSCA as a standard 5. The objective of our workInvestigate the capabilities and maturity of TOSCA specification in the context ofdesigning and deploying Cloud applications through a Proof of Concept project. Explore the available solutions and/or build the necessary components for deploying anapplication using TOSCAProject duration: 6 monthsFunded and coordinated by T-SystemsTestbed provided by Telekom Innovation Laboratories Openstack infrastructure for the resources Opscode Chef server for configuration management5 6. Motivation6Cloud portability The ability of cloud computing users to move their data or applications between cloudenvironments at low cost and minimal disruption. Migrate a fully-stopped Virtual Machine (VM) instance from one provider to another.Interoperability The ability of two or more systems or components to exchange information and to use theinformation that has been exchangedCloud interoperability => Cloud portabilityConflicting or absent cloud interoperability standards result in: Vendor/technology lock-in Deployment inflexibility Increased cost for ongoing development and lifecycle management/migrations 7. Current State-of-the-ArtStandards (are) adopted by cloud providers -> developers create their applicationsindependently of specific platform environments TOSCA (more details in following slide), HEAT, CAMPIntermediation: An intermediate layer (exists) that decouples application development fromspecific platform APIs E.g. mOSAIC, PaaS Semantic Interoperability Framework (PSIF), SimpleCloudOrchestration: Technologies (manage the deployment) of applications, management ofresources (Software Defined Infrastructure) etc. E.g. Chef, PuppetIaaS: Interoperability between hypervisors (is well supported) E.g. OVF White Paper, T-Systems Telekom Innovation Laboratories, FZI, Intel, Virtual Machine Interoperability Usage Model -Open Data Center Alliance7 8. OASIS TOSCATopology and Orchestration Specification for Cloud Applications Aims to leverage portability of application layer services between various Cloud environments XML-based language describes application topologies and management proceduresDefinitions all the necessary Nodes and Relationships, their interfaces and properties must be defined. Apart from the abstractdefinitions, the implementation of each entity is specified.Service Template this is the structure of the Cloud application presented as a Topology Template. Apart from the overallarchitecture of the topology, the manageability of it is defined through the Plans section.Plans are defined as process models, i.e. a workflow of one or more steps. The TOSCA specification relies on existing languageslike Business Process Modelling Notation (BPMN) or Business Process Execution language (BPEL).Topology TemplateVersion 1, 25 November 2013Version 2 is ongoingNodeTemplateRelationshipTemplateService TemplateNode Types{ }InterfacesPropertiesNode TypeRelationship Types{ }PlansInterfacesPropertiesRelationship Type8 9. PoC ScenarioHigh Level Process1. Application Developercreates a new TOSCA-compliantApplication Topology2. Define the application deployment/un-deploymentplan using BPMN language3. Use the provided tools to upload theTOSCA file and initiate the deployment(Pre-defined TOSCA typesand artifacts might be used)9ApplicationTopology DefinitionDeploymentprocess (TOSCAPlan) definitionUpload TOSCA xmlfile to TOSCAContainerTrigger deploymentprocess againstPlans engineVM node creationand softwareinstallation 10. Use case definition10Basic 3-tier application Load balancer HA Proxy Web application on application server Tomcat server Database - MySQLDemoWebApplicationApplicationServerApplicationServerDemoWebApplicationDatabase ServerLoad Balancer 11. Modeling the application topology with TOSCA11TypesNode Types RelationshipTypesNode TypesImplRelationshipTypes ImplService TemplatePlans 12. Node Types for Use Case12NodeTypesVirtualMachineOSDatabaseWebServerOpenStackVMLinuxUbuntu12.04SQLMySQLServerLoadBalancerApacheTomcatServerHAProxym1.smallflavorRelationshipTypeCommu-nicationHostedOnSoftwareDemoWeb App 13. Node Type Implementations13Node TypeImplementationDemoWebAppMySQLServer ImplApacheTomcatServer ImplApache Tomcat InstallationArtifactDemoWebApp DeployArtifactMySQL Installation ArtifactHA Proxy InstallationArtifactHA ProxyImplDeployment Artifact Deployment Artifact Deployment Artifact Deployment Artifact 14. Relationship Types14RelationshipSoftware hostedon OSCommunicationOS hosted on VMUbuntu12.04hosted onM1.smallHosted OnRemoWebAppCommunicateMySQLHA ProxyCommunicateApache TomcatTypeHA Proxyhosted onUbuntu12.04DemoWebApphosted onApache TomcatMySQLhosted onUbuntu12.04Apache Tomcathosted onUbuntu12.04 15. Topology Template15Ubuntu12.04MySQLServerHAProxym1.smallflavorUbuntu12.04m1.smallflavorHostedOnHostedOnDemoWebAppHostedOnApacheTomcAaptacheTomcatHostedOn HostedOnHostedOnDemoWebAppUbuntu12.04m1.smallflavorHostedOnUbuntu12.04m1.smallflavor 16. Use case implementation constraints & assumptionsThe use case application must be decomposed into three elements: Software components Operating system Virtual MachineTOSCA allows inheritance within the Node Type definition sectionOnly the Software Node Types have an implementation (Node Type implementation),and therefore Artifacts which include the Chef roles and recipesThe description of the infrastructure is realized through TOSCA Relationships(HostedOn, communicate)The deployment plan of the use case is written in BPMN language (Intalio Design) The Application Developer must use the Intalio Design tool to generate the necessary deploymentplan. (Now Winery)16 17. TOSCA Container ArchitectureTelekom Cloud TestbedApache TomcatIntalio BPMSDeployment ProcessStart EventInterruptingService TaskEnd EventInterruptingTOSCAContainerWeb ServiceOpenStack Cloud EnvironmentNovaComputeServiceOpscode Chef ServerSOAP Message FlowStart BPMN Process(Intalio Editor)WSDLCloud UserFull TOSCADocumentKnifeOpenStack InstancesJAX-WSCookbooksRecipesRolesTOSCA Planin BPMN(XML)QuantumNetworkService17TOSCAserver create cmdBootstrap roles& recipesdeploy node 18. Intermediary, domain specific data model18 19. Evaluation10 successful deployment runs Avg of 17 minutes 25 secondsMajor effort is focused on definingSoftware installationsSequential deployment is necessary to guarantee that Chef recipes can beapplied correctlyCloud Formation experiment Average deployment time of 14 minutes 13 seconds Deletion time of 1:30 minutes The deployment time savings in these experiments may root from the use of hosted services19 20. Findings on TOSCA v1.01. Limited resources available to effectively explain all the entities and concepts defined in TOSCA. The Specification document20lacks information when presenting new concepts.2. The available TOSCA examples are at high level, and do not present a complete Cloud deployment scenario. Someimplementation examples for a complete basic application should be provided, to guide potential developers in using theframework.3. Based on the available resources, it appears that one application topology can be described in many different ways (bydefining different types or levels of NodeTemplates, RelationshipTemplates etc.) = very open and nonspecific for enablinginteroperability. No suggested mapping between TOSCA entities (e.g. Node Types) and cloud resources availablea) There are multiple ways to express certain propertiesb) Limited available examples and supported documentationc) No suggested API or architecture for a TOSCA ContainerI. Every provider is left to implement his own systemII. Different interpretation of the schema (in combination with previous)4. Additional documentation relating to guidelines and technical recommendations when adopting the TOSCA framework wouldbe extremely helpful.a) Data Model & Reference Modelb) TOSCA Container description 21. OpenTOSCACloudCycle Project from University of Stuttgart IaaS Group[http://www.iaas.uni-stuttgart.de/OpenTOSCA]1. OpenTOSCA Container (TOSCA runtime)2. Winery (TOSCA Modeling Tool)[http://winery.opentosca.org/winery/relationshiptypeimplementations/]3. Released September 20134. Current version 1.1 [http://files.opentosca.de/v1.1/]5. Limited full market support of TOSCA, no validation beyond XML schema validation6. Cannot restart containers7. No support is provided21 22. Thank youQuestions?Ryan Skippryan.skipp@t-systems.co.za