Software defined environments based on TOSCA in IBM cloud implementations
G. Breiter M. Behrendt M. Gupta S. D. Moser R. Schulze I. Sippli T. Spatzier
In recent years, the role of cloud computing in the information technology (IT) industry has been growing steadily, partly because IT developers are becoming empowered to provision, manage, and adjust IT resources through simple application programming interfaces. This enables the easy creation and manipulation of software defined environments consisting of server, storage, network, software, and the supporting management functions. Model-based deployment and management technologies that are based on upcoming standards such as the Topology and Orchestration Specification for Cloud Applications (TOSCA) of the Organization for the Advancement of Structured Information Standards (OASIS) allow for describing models of different kinds of workloads such as topology patterns and management plans. The term Bpattern[ refers to a description of components of a service, e.g., an application or infrastructure, and their relationships. This approach provides a flexible combination of declarative and imperative models of workloads that can be seamlessly integrated with automation frameworks such as Chef for task-level automation as well as management services to drive resource orchestration and optimization. In this paper, we explain how the aforementioned concepts are used as foundational elements of the software defined environment. We use an actual example motivated by a real customer scenario, and we explain the relation to the IBM Cloud Computing Reference Architecture and how it is applied within IBM cloud implementations.
Introduction With the increasing adoption of cloud computing across enterprises, software vendors, and service providers, a growing number of applications are being moved to cloud computing platforms. One of the key challenges in that context is to avoid becoming committed to particular cloud implementation. Freedom of choice is an imperative to avoid such close commitments (often referred to as Bvendor lock-in[), since the quickly evolving cloud market makes it increasingly difficult to predict how cloud providers will refine their strategy with respect to pricing, features being offered, and openness in general.
Digital Object Identifier: 10.1147/JRD.2014.2304772
For instance, many enterprises are in the process of making their middleware stacks and applications available via private clouds. In support of this process, the respective enterprise IT organization typically selects particular cloud management software as the basis for deploying and managing its middleware and applicationsVwhich requires building corresponding application-specific automation logic. To escape lock-in to the selected cloud management software, it is desirable that any extension and customizing work is encoded in a standardized, vendor-neutral way, such that the corresponding artifacts can be also used with any other cloud management software supporting the same standard. In addition, such an approach would allow running software on both private and public cloud
ÓCopyright 2014 by International Business Machines Corporation. Copying in printed form for private use is permitted without payment of royalty provided that (1) each reproduction is done without alteration and (2) the Journal reference and IBM copyright notice are included on the first page. The title and abstract, but no other portions, of this paper may be copied by any means or distributed royalty free without further permission by computer-based and other information-service systems. Permission to republish any other portion of this paper must be obtained from the Editor. 0018-8646/14 B 2014 IBM
IBM J. RES. & DEV.
VOL. 58
NO. 2/3
PAPER 9
MARCH/MAY 2014
G. BREITER ET AL.
9:1
Figure 1 Open cloud architecture: API economy, cloud operating environment, and software defined environment. (API: application programming interface.) Figure adapted from [1], with permission.
deployments without a change while being compliant with the same standard. From the perspective of a software vendor, a similar vendor-neutral approach is desirable. A growing number of software vendors are in the process of enabling their software for being hosted on a cloud. Ideally, a software vendor would like to make that investment only once and use the resulting artifacts across multiple clouds instead of having to implement new ones on a per-cloud basis. The infrastructure hosting such middleware and applications is becoming increasingly software defined, and this kind of infrastructure is also referred to as a Bsoftware defined infrastructure[ (SDI). SDI is defined by virtualization of compute, network, and storage, providing the ability to provision infrastructure through software, e.g., implementing a switch as software instead of relying on physical devices. The combination of SDI, and the orchestration and optimization functionality that allow for deploying and managing software on Btop[ of it, is a so-called Bsoftware defined environment[ (SDE). In addition, software made available via a SDE needs to be composable in support of building new applications on top of it. In that context, composable refers to exposing well-defined, easy-to-use application programming interfaces (APIs) for integrating that software with other services in an incremental and very iterative fashionVwhich means adding and removing capabilities to the application as it evolves. Handling an API of software as a Bfirst-class[ entity that needs to be designed, metered, monetized, etc., such that it is open for reuse by others, is often discussed as the BAPI economy.[ The architectural component that
9:2
G. BREITER ET AL.
supports the incremental composition and operations of new applications by using such APIs is called a Bcloud operating environment.[ These three macro-level trendsVSDE, cloud operating environment, and API economyVare building on top of one another, as illustrated in Figure 1 (also see [1]). In [2], workload optimization and orchestration are explained as Bmap[ping] virtual resources to physical resources and realizing such a mapping in the infrastructure. This mapping, known as placement, is optimized so that the infrastructure is efficiently utilized, and the workload requirements are satisfied.[ Placement is just one optimization; other examples are license management, shortest communication paths between components, or collocation/anti-collocation for high availability. Furthermore, in its broadest sense, orchestration refers to executing various tasks in a coordinated fashion, driven by a central point of control. In the context of SDE, these tasks primarily relate to deploying, configuring and managing (software defined) compute, storage, and network resources. This paper focuses on the workload orchestration aspect of the Bworkload optimization and orchestration[ element depicted in Figure 1. This covers the definition and execution of the deployment and management logic for any cloud-hosted software in a portable fashion, such that it can be applied across different kinds of SDIs. The workload optimization aspects are addressed by [2]. This paper begins by describing the foundational architectural concepts around workload orchestration. This is followed by an introduction of the Topology and Orchestration Specification for Cloud Applications (TOSCA)
IBM J. RES. & DEV.
VOL. 58
NO. 2/3
PAPER 9
MARCH/MAY 2014
standard, which allows for defining workloads in a vendor-neutral way such that they can be applied across various clouds. After that, IBM efforts around workload optimization and orchestration, and TOSCA in particular, are covered. This addresses both packaged cloud management software allowing customers to implement their own cloud and IBM-hosted cloud offerings. The paper concludes with an outlook for how workload optimization, orchestration, and TOSCA are expected to evolve in the future.
Workload orchestration in software defined environments In order to realize Workload Definition, Orchestration, and Optimization (WDOO) in SDEs the fundamental concepts of Model Driven Cloud Service Management are used. Workload in this context is understood as the service, or more precisely the cloud service, delivered by the SDE. A cloud service is an IT service that is delivered in a standardized form on a virtualized Infrastructure in an automated fashion. Therefore, we quickly recap the lifecycle of cloud services as described in [3] and [4] using the fundamental roles defined in the Common Cloud Reference Architecture (CCRA) in [5]. The CCRA defines three main roles typically encountered in any cloud computing environment: the cloud service creator, cloud service provider, and cloud service consumer. Each role can be fulfilled by a single person, a group of people, or an organization. Following the CCRA definitions, the service creator develops cloud services, and the service provider runs those services and provides them to service consumers, which can also be IT systems. According to the CCRA definition, a cloud service represents any type of (IT) capability that the service provider offers to service consumers. In contrast to traditional IT services, cloud services have attributes that are typically associated with cloud computing, such as a pay-per-use model, self-service usage, flexible scaling, scalability, and resource sharing. These fundamental definitions can be applied in exactly the same way to SDEs. The IT services that are offered by an SDE are identical to the cloud services defined by the CCRA. The lifecycle of an SDE hosted and managed IT service, as defined in [3] and [4], has the three phases: definition, deployment and runtime. In the definition phase, the instantiation- and management model of such an IT service is created. The service creator uses tooling to capture all the management knowledge required for that specific IT service in a service template including information about the cloud service’s internal structure along with operational and management aspects to build, manage, and terminate cloud services. In addition, all implementation- and deployment artifacts (scripts, Chef [6] recipes, workflows, images, etc.) are bundled together with the metadata describing the service structure so that finally a fully
IBM J. RES. & DEV.
VOL. 58
NO. 2/3
PAPER 9
MARCH/MAY 2014
self-contained archive is available containing all the technical information needed to create and operate instances of such an IT service. Examples of those services range from simple virtual machines (VMs) to fully scalable n-tiered applications such as SAP, Oracle**, WebSphere* landscapes, or Hadoop** clusters. The tooling to create such archives can be a graphical user interface, allowing the service creator to define the individual building blocks making up the service, then selecting these building blocks from a catalog and graphically linking them together using a well-defined set of relationships to finally define the topological structure of a service. Good examples for those graphical tools are the Virtual Application Builder within the IBM SmartCloud* Orchestrator or the OpenTOSCA/Winery project from Stuttgart University [7, 8]. Another option to create these archives is what we call BInfrastructure as Code.[ This defines a new domain specific programming language that allows a DevOps [9] skilled person to programmatically define the topology of a service, capture and add the operational and management aspects of the service as well as the required implementation- and deployment artifacts finally resulting in an archive with the same information. Project Weaver from IBM Research is a good example for such an approach [10]. DevOps refers to a methodology to bridge the traditional separate departments for development, IT operations, and quality assurance and to combine the different aspects of development and deployment activities to provide an increased rate of production releases from application and business unit stakeholders, realized through a high degree of automation on virtualized infrastructure. The resulting archive itself contains points of variability (PoVs). A PoV in a service archive allows the reuse of technical entities in different business contexts, e.g., a service provider to create different offerings (e.g., Bgold,[ Bsilver,[ and Bbronze[) based on the same service template adding all provider- and offering-specific information such as pricing and other aspects. Finally, the offering is published in a service catalog. In the subscription and instantiation phase, the service consumer browsing the service catalog can select and subscribe to the respective offering. This service consumer does not necessarily have to be a human, in the context of SDE in most cases it will be a cloud application running, for example, in the context of cloud operating environments (CloudOEs) such as the IBM BlueMix environment [11] requesting the instantiation of a specific service from SDE. The consumer customizes the service through points of variability. For example, selecting Bgold,[ Bsilver,[ or Bbronze[ could be equivalent to requesting a developer-, test-, or production instance of the service with well-defined service-level agreements (SLAs). He or she thereby electronically signs a contract and accepts the offering’s terms and conditions. This subscription process
G. BREITER ET AL.
9:3
triggers the creation of a service instance. WDOO aggregates all resources required from software defined compute (SDC), software defined network (SDN), and software defined storage (SDS) and automatically deploys, installs, and configures the service’s necessary pieces. For example, SDN allows for programmatic configuration of network resources such as overlay networks, something that the orchestration layer can leverage. In the lifecycle’s production phase, the WDOO uses management plans to manage the service instance for compliance with the SLAs negotiated at subscription time. For example, the management platform assigns additional resources to the instance when the number of requests is increasing for a service and removes them when the hosted CloudOE application is no longer using the service. The service provider or consumer can also trigger management plans manually or programmatically via an API callVfor example, to backup, upgrade, or restore the service. Finally, when the service consumer decides to end the service or the subscription expires, the service instance terminates, the software is shutdown, the network connections are destroyed, and all the other hardware resources are returned to the freepools handled by SDC, SDN, and SDS. Delivery of a Hadoop service using WDOO Having described these fundamental concepts, we now consider the delivery of a Hadoop service as a concrete example of a service delivered by the SDE. A fraud-detection application running in the BlueMix environment needs a Hadoop service for correlation and log analytics. A service provider running the SDE is offering that service. At the time the fraud-detection application is developed, it only needs an instance of the Hadoop service for a developer to do rapid prototyping. Therefore, this service can be delivered with minimal cost with all the software components running in one VM, using internal network capabilities and local disk storage. After the service is developed, it needs to be tested already including limited testing for scalability, therefore a Bsilver[ environment with limited scaling characteristics is neededVthe Hadoop data nodes are put on separate clustered VMs. As soon as the application goes into production and starts to scale, the Bgold[ version with extended scaling characteristics is needed and finally supporting a full blown highly scaling web application requires the Bplatinum[ version of the Hadoop service. In addition to clustering the individual tiers of the Hadoop application changes to storage and network are introduced when progressing to Bsilver,[ Bgold,[ and Bplatinum.[ In the Bgold[ version, for example, a 10G network is included into the service template, which is replaced by a much faster Remote Direct Memory Access (RDMA) connection in the Bplatinum[ version. Storage changes from local disks to local SSDs (solid-state drives) when progressing from Bsilver[ to Bgold[ and Bplatinum.[
9:4
G. BREITER ET AL.
Of course, Hadoop is only one example of how a service can be delivered through SDE; other examples might be transactional, multi-tier web applications such as WebSphere Commerce and SAP, which can be instantiated and managed simultaneously by a common SDE. Let us now examine the benefits of the suggested approach. Without WDOO, the provider of the fraud-detection application would manually request the specific configuration of compute platform capacity, network, storage, and middleware for each of those configurations. The service provider for the Hadoop platform would then coordinate the individual requests to network, storage, compute administrators to create variable, complex configurations of the infrastructure (e.g., compute LPARs [logical partitions], storage allocation and placement, RDMA, and DNS [domain name system]), then install variable, complex configurations of the Hadoop name and data nodes, security and data access, backup policies, monitoring agents, etc. to finally provide the requested service for each of the configurationsVafter months. After the service instance has been created, the different administration roles of the Hadoop service provider would have to run manual or semi-automated management actions to maintain the requested SLAs of the individual service instance. With WDOO, the Hadoop service provider uses the tooling to create the service definitions, including the automations and PoVs that enable offering a set of standardized service variations of the Hadoop service with different capabilities and SLAs (Bbronze,[ Bsilver,[ Bgold,[ and Bplatinum[). The fraud-detection application then requests such a variation of the standardized service based on cost, development stage, business opportunity, and value. The orchestration uses the service definition based on the chosen service variation and automatically deploys the requested service within hours or minutes. If SLAs of the service are impacted, the optimization component of WDOO will automatically trigger orchestration (using the management plans captured in the service definition) to adjust resources to maintain its SLAs. The service definitions are selectively adapted and continuously evolved in a DevOps environment to offer additional service variations meeting new requirements from the fraud detection application. To enable optimal reuse for these service definitions, WDOO allows for the creation of different software and infrastructure service definitions and binding them together at deployment time of the service. As shown in Figure 2, a set of software and infrastructure definitions can be captured. This can be done through a set of graphical tools, representing the workload definition component of WDOO. At instantiation time, the software patterns are linked to infrastructure patterns based on the chosen service variation. Based on the information contained in the resulting template WDOO automatically orchestrates
IBM J. RES. & DEV.
VOL. 58
NO. 2/3
PAPER 9
MARCH/MAY 2014
Figure 2 Workload Definition, Orchestration, and Optimization (WDOO) enables capturing of the software definitions and infrastructure definitions of services as software and infrastructure patterns.
the deployment and update of the service on a SDI consisting of SDC, SDN, and SDS. WDOO, therefore, enables the rapid and continuous delivery of a diverse set of services. This allows for agility and optimization on a programmable heterogeneous infrastructure while using reusable building blocks. The integration of WDOO with the existing IT management infrastructure of cloud providers has become another topic of research. Based on the support of managed services in IBM Cloud Managed Services, the concept of software defined management service abstraction (SDMSA) has been derived. In a managed SDE, the orchestrations that manage the resources in SDI also need to interact with functions of the cloud provider’s IT service management. For example, a provisioning orchestration has to interact with several management services such as incident/problem/ change system, asset and configuration management, monitoring, discovery, patching, service activation, security compliance, etc. Typically, a service provider in a shared environment has to cater to different customers and needs to use different tools to provide a certain systems management function. For example for one customer, there might be a need to use Zabbix** [12] for monitoring and NetApp** [13] for backup and restore operations, while for a different customer there is a need to use IBM SmartCloud Monitoring for monitoring and IBM Tivoli* Storage Manager for backup
IBM J. RES. & DEV.
VOL. 58
NO. 2/3
PAPER 9
MARCH/MAY 2014
and restore. Furthermore, each customer may have specific requirements to customize the basic processes and behavior of the management service being provided. In order to shield service templates that specify the requirements on the service management as well as the orchestrations and optimizations in the WDOO layer from changes in the underlying systems management tooling that implement the service management functionality, there is a need to introduce SDMSA. SDMSA abstracts out common service management tasks. It offers a common set of APIs that can be invoked by the WDOO layer. The SDMSA may itself invoke APIs from the SDI layer. Open Services for Lifecycle Collaboration (OSLC) [14] and linked data may be used by the SDMSA to exchange data from the underlying management tools. WDOO uses and is fundamentally based on the key architectural constructs and design concepts of TOSCA, which are explained in the following.
Using OASIS TOSCA for workload definition In order to define an exchangeable and portable cloud service model, the TOSCA standard has been defined at OASIS (Organization for the Advancement of Structured Information Standards) [15]. TOSCA enables the standardized description of cloud services, including both the structure of an application (i.e., the ingredients such as
G. BREITER ET AL.
9:5
Figure 3 TOSCA (Topology and Orchestration Specification for Cloud Applications) cloud service archive. (Reproduced, with permission, from [16].)
components/resources and their relations) and the management plans which describe detailed management processes for various scenarios. Thus, a TOSCA service description contains detailed knowledge about the structural and conceptual design of a cloud application, and additionally offers the possibility to add technical expert knowledge through so-called management plans. With the help of TOSCA, one can also package complete solutions as self-contained archives (Cloud Service Archive, CSAR). These archives then contain both the model as well as all artifacts needed to turn the model into an actual service instance, and to manage it after instantiation (Figure 3). The description of a cloud service, or of the provided application, is done through a service template. A service template contains a structural description of the application (the Btopology template[) as well as the management plans. The building blocks for modeling an application, i.e., the possible components and their relations, are described through node types and relationship types. Both define attributes that are configurable through a TOSCA runtime environment, i.e., an orchestration environment that implements support for TOSCA compliant service descriptions. For example, such a configurable attribute could be the IP address under which a server should be reachable. Second, a TOSCA runtime environment can call management operations that are defined by components of
9:6
G. BREITER ET AL.
the service, e.g., starting or stopping a specific component or triggering a backup. Another important aspect of TOSCA is that artifacts that implement the above-mentioned management aspects (so-called implementation artifacts) are packaged as part of the solution, too, and node and relationship types can point to such artifacts. Furthermore, artifacts that are required for the instantiation of a specific component in the service (e.g., installation packages, runtime libraries or VM images) can be present in a CSAR as so-called deployment artifacts. Interpretation and execution of TOSCA models During the TOSCA standardization, two different models for processing TOSCA service descriptions have emerged: declarative processing and imperative processing. In the case of declarative processing, certain use cases (such as the instantiation or the termination of a cloud service) are solely derived from the structural description of the service. For this kind of processing, precisely defined semantics of components and relationships between the components are necessary to ensure that different TOSCA environments will derive the same sequence of management actions based on the application topology. For example, a component A depending on another component B will indicate the sequence in which these components must be instantiated.
IBM J. RES. & DEV.
VOL. 58
NO. 2/3
PAPER 9
MARCH/MAY 2014
Figure 4 TOSCA (Topology and Orchestration Specification for Cloud Applications) model composition for defining workload layers. (arch: kernel architecture; OS: operating system.)
In contrast, in the imperative processing approach all use cases are realized through the execution of management plans, where the sequence of actions is explicitly defined upfront in plans, for example described as process models according to the Business Process Model and Notation (BPMN) 2.0 specification [17]. This approach does not have such a strong dependency on the definition of the semantics of a component or a relationship as the declarative approach, but it relies on the correctness of the created management plans. Aside from the strict separation of these two approaches, one can also think of a hybrid approach, where some use-cases, like the instantiation of the service, are realized through the imperative processing, and other use cases (such as the creation of a backup during the runtime of the service) are implemented through the imperative approach. A more detailed explanation of the internals of a TOSCA engine can be found elsewhere [18]. Defining composable software and infrastructure models with TOSCA TOSCA allows for separating overall deployment models into multiple smaller, reusable models. For example, it is possible to define one model for the software layer of a workload and a separate model (or even multiple alternative models) for infrastructure to host the software. By matching requirements of one model against capabilities provided by another model, smaller building blocks can then be composed into an overall model at deployment time. Alternatively, a software deployment according to a TOSCA
IBM J. RES. & DEV.
VOL. 58
NO. 2/3
PAPER 9
MARCH/MAY 2014
service template can also be done onto an instance of an infrastructure service that has already been deployed based on an infrastructure template providing the requested capabilities. Figure 4 gives an example for a software layer consisting of an application and a database. The said software layer requires an infrastructure layer with compute and storage capabilities. Considering more detail, infrastructure models that might include components such as compute, network, and storage can be described in their own TOSCA service templates. Capabilities of components within these templates (e.g., the capability of a compute node to host software installations) can then be exported by the service template using the concept of Bboundary definitions[ defined in the TOSCA specification that are specified in the description of the service template. Definitions of software layers provided as separate service templates contain single components that express requirements against a hosting infrastructure. For example, a software component might express requirements for a compute resource of a certain hardware architecture having specific performance characteristics. By matching the requirements of all components in a software layer template against exported capabilities of infrastructure templates, the appropriate fit-for-purpose infrastructure can then be selected and deployed dynamically. In cases where multiple alternative infrastructure templates with matching functional capabilities exist, additional nonfunctional capabilities (e.g., scaling or high availability) can be taken into consideration during the matching process.
G. BREITER ET AL.
9:7
TOSCA as an enabler for an ecosystem Having a standard such as TOSCA being driven by multiple large industry players does not guarantee its success. The critical driver for cloud environments based on an open standard is the adoption of the standard in an ecosystem. Such an ecosystem involves multiple components and is fed by different roles. Two mandatory components are stable and widely adopted runtime environments to run TOSCA-based cloud services, as well as tooling to create such services. In addition, a TOSCA marketplace that is comparable to the app stores for mobile devices has to exist. Cloud service creators can then publish their TOSCA archives to such a marketplace, and those archives can be used by cloud service providers and consumers. Components are already evolving in the market. For base infrastructure cloud services, such as network, compute, and storage, OpenStack** is a platform that is gaining more and more momentum in the industry. In addition to that, project Heat is now included as an OpenStack core project within the OpenStack Havana release. Heat provides a pattern engine for software defined blueprints, i.e., orchestration of composite cloud applications. IBM and other industry partners are moving Heat toward adoption of the TOSCA standard to provide an open source runtime for broader community adoption of TOSCA.
Workload definition and orchestration in IBM’s and open source cloud implementations In previous sections, we have shown how TOSCA can be used to describe cloud application workloads and the underpinning resources such as software defined compute, network, or storage in a standardized format. The first product support for version 1.0 of the TOSCA standard has been shipped with the IBM SmartCloud Orchestrator 2.2 product in May 2013. SmartCloud Orchestrator allows for importing TOSCA compliant service templates of cloud applications and for deploying them as virtual applications into the managed virtualized infrastructure. It is also possible to combine separate service templates at deployment time based on requirement- and capability matching. This allows for structuring overall workload definitions into smaller re-usable templates, for example, into templates for the application layer, the middleware layer or the infrastructure layer. In addition, SmartCloud Orchestrator provides support for annotating TOSCA models with policies to express nonfunctional requirements for the different layers of a workload, and for propagating those policies consistently through an overall workload model. Additional enhancements to the TOSCA support, such as integrated tooling for defining custom node types or relationship types have been included in SmartCloud Orchestrator 2.3. SmartCloud Orchestrator is built on top of OpenStack as an infrastructure management layer that provides support for
9:8
G. BREITER ET AL.
software defined compute, network, and storage. With the evolution of project Heat, which is now included as a core project in the OpenStack Havana release, OpenStack is gaining additional capabilities that allow for not only handling base infrastructure resources separately but also for defining reusable patterns of multiple of those resources. Heat in its current form includes rich support for most of OpenStack’s resources [19–20] (Nova compute instance, Cinder volumes, Neutron networks, Swift containers, etc.) and also supports features such as scaling, load balancing, or high-availability to be expressed in templates. While Heat’s original template format is based on Amazon Web Services** (AWS) CloudFormation, IBM and other companies such as Hewlett-Packard, Rackspace, or Red Hat are working on a new template format for Heat Orchestration Templates (HOTs) to replace CloudFormation over time and align with TOSCA as an open standard. The direction to move from CloudFormation to HOT as Heat’s native template formatVa direction that finds unanimous agreement throughout the OpenStack Heat communityVwill bring the following advantages: CloudFormation templates are bound very much to Amazon’s cloud implementation, e.g., by referencing specific resource types such as the Simple Storage Service (S3) and the Simple Queue Service (SQS) that are available on the Amazon cloud but would have to be re-implemented in OpenStack for CloudFormation templates to work properly. HOT in contrast will closely integrate with the OpenStack resource model and therefore provide much better support for those native resources. The same applies to internal orchestration mechanism (e.g., for synchronization), which are very much bound to assumptions on Amazon’s implementation in CloudFormation templates. Another important aspect is that HOT will provide for better modeling capabilities of software components separated (and therefore more flexibly usable) from infrastructure componentsVan aspect that is not addressed in CloudFormation very well (e.g., CloudFormation uses a lot of inline scripting tied to compute resources). Finally, Heat and HOT will provide new features such as requirement- and capability-based composition of reusable templates or the concept of variable resource implementations based on environments, which are not present in CloudFormation. Therefore, the cleaner approach is to clearly define and document the necessary constructs in HOT instead of adding to CloudFormation, potentially in a way that CloudFormation was not designed for. One of the important new features just mentionedVrequirement- and capability-based matching of reusable templatesVas well as better support for nonfunctional requirements being added to HOT will help Heat mature to a solid open source pattern engine for SDI. Using the alignment of HOT and TOSCA, SmartCloud Orchestrator and other products based on IBM’s common
IBM J. RES. & DEV.
VOL. 58
NO. 2/3
PAPER 9
MARCH/MAY 2014
cloud stack can then seamlessly sit on-top of Heat and concentrate on the management of higher layers of overall SDE workloads, while requirements against SDIs can be Bpushed down to[ Heat to instantiate and manage those layers of the workload.
Related work Aside from our work to design a WDOO system using TOSCA, there has also been other work related to automated deployment of cloud services using templates and models. Other model-based approaches that are not restricted to a specific service type have been introduced [21–23]. An approach that is specific to storage services has been discussed previously [24], and an approach more tailored toward network services has been introduced [25].
Conclusion In this paper, we introduced the Open Cloud Architecture, consisting of three layers: API economy, CloudOE, and a SDE. The CloudOE layer allows for iterative composition and operation of applications using various servicesVwhich can be higher-level API-driven services or more infrastructure-oriented services provided by SDE. SDE in turn consists of two main components: WDOO and SDI. This paper focused on the WDOO component, being responsible for delivering and managing services running within an SDE. These services can be defined using TOSCA, which is an OASIS-driven standard for defining IT topologies and management knowledge in a portable manner. We have shown how TOSCA can be used to describe SDE workloads in a holistic way from applications down to a SDI layer. We further explained how overall workload definitions can be split into re-usable templates of software and infrastructure layers and how those templates can be combined dynamically based on the TOSCA concept of requirements and capabilities, as well as policies. We have given a brief insight into IBM’s product support for TOSCA-compliant workload definitions, as well as an alignment with OpenStack as an open source infrastructure management layer. We have also provided a short overview of Heat, which is evolving as a pattern engine as part of OpenStack, and we have outlined how Heat can address pattern-based SDI management in a WDOO environment. *Trademark, service mark, or registered trademark of International Business Machines Corporation in the United States, other countries, or both. **Trademark, service mark, or registered trademark of Oracle Corporation, Apache Software Foundation, Zabbix SIA, NetApp, Inc., OpenStack Foundation, or Amazon Web Services in the United States, other countries, or both.
IBM J. RES. & DEV.
VOL. 58
NO. 2/3
PAPER 9
MARCH/MAY 2014
References 1. A. Diaz and C. Ferris, IBM’s Open Cloud Architecture. [Online]. Available: http://www.ibm.com/developerworks/cloud/library/ cl-open-architecture/ 2. W. C. Arnold, D. J. Arroyo, W. Segmuller, M. Spreitzer, M. Steinder, and A. N. Tantawi, BWorkload orchestration and optimization for software defined environments,[ IBM J. Res. & Dev., vol. 58, no. 2/3, Paper 11, 2014 (this issue). 3. G. Breiter and M. Behrendt, BLifecycle and characteristics of services in the world of cloud computing,[ IBM J. Res. & Dev., vol. 53, no. 4, pp. 3:1–3:8, 2009, Paper 3. 4. T. Binz, G. Breiter, F. Leymann, and T. Spatzier, BPortable cloud services using TOSCA,[ IEEE Internet Comput., vol. 16, no. 3, pp. 80–85, Jun. 2012. 5. M. Behrendt, B. Glasner, P. Kopp, R. Dieckmann, G. Breiter, S. Pappe, H. Kreger, and A. Arsanjani, IBM Cloud Computing Reference Architecture, Feb. 2011, Open Group submission. [Online]. Available: www.opengroup.org/cloudcomputing/ uploads/40/23840/CCRA.IBMSubmission.02282011.doc 6. Opscode Chef. [Online]. Available: http://www.opscode.com/chef/ 7. OpenTosca. [Online]. Available: http://www.iaas.uni-stuttgart.de/ OpenTOSCA/indexE.php 8. Winery. [Online]. Available: http://www.eclipse.org/proposals/soa. winery/ 9. IBM Corporation, Armonk, NY, USA, DevOpsVContinuous delivery of software-driven innovation. [Online]. Available: http://www.ibm.com/ibm/devops/us/en/ 10. IBM Corporation, Armonk, NY, USA, Weaver. [Online]. Available: http://ibmresearchnews.blogspot.com/2012/05/ simpler-tools-for-more-complex-systems.html 11. IBM Corporation, Armonk, NY, USA, IBM SmartCloud Application Services. [Online]. Available: http://www.bluemix.net 12. Zabbix. [Online]. Available: http://www.zabbix.com 13. NetApp. [Online]. Available: http://www.netapp.com 14. Open Service for Lifecycle Collaboration. [Online]. Available: http://open-services.net/ 15. OASIS Topology and Orchestration Specification for Cloud Applications Version 1.0. [Online]. Available: http://docs. oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.pdf 16. OASIS TOSCA and how it could fit into OpenStack Heat, OpenStack Design Summit, Apr. 15, 2013. [Online]. Available: https://wiki.openstack.org/w/images/a/a1/TOSCA_in_ Heat_-_20130415.pdf 17. Business Process Model and Notation 2.0. [Online]. Available: http://www.omg.org/spec/BPMN/2.0/ 18. T. Binz, U. Breitenbu¨cher, O. Kopp, and F. Leymann, BTOSCA: Portable automated deployment and management of cloud applications,[ in Proc. Adv. Web Serv., 2014, pp. 527–549. 19. OpenStack Compute Administration Guide, Components of OpenStack. [Online]. Available: http://docs.openstack.org/grizzly/ openstack-compute/admin/content/components-of-openstack.html 20. OpenStack Wiki. [Online]. Available: https://wiki.openstack. org/wiki/Main_Page 21. E. Brandtzg, P. Mohagheghi, and S. Mosser, BTowards a domain-specific language to deploy applications in the clouds,[ in Proc. 3rd Int. Conf. Cloud Comput., Grids, Virtualization, 2012, pp. 213–218. 22. J. Bresnahan, T. Freeman, D. LaBissoniere, and K. Keahey, BManaging appliance launches in infrastructure clouds,[ in Proc. TeraGrid, Salt Lake City, UT, USA, Jul. 2011, p. 12. 23. D. K. Nguyen, F. Lelli, M. P. Papazoglou, and W.v.d. Heuvel, BBlueprinting Approach in Support of Cloud Computing,[ Future Internet, vol. 4, no. 1, pp. 322–346, Mar. 2012. 24. M. P. Mesnier and J. B. Akers, BDifferentiated storage services,[ Oper. Syst. Rev., vol. 45, no. 1, pp. 45–53, Jan. 2011. 25. T. Benson, A. Akella, A. Shaikh, and S. Sahu, BCloudNaaS: A cloud networking platform for enterprise applications,[ in Proc. SoCC, 2011, p. 8.
Received August 22, 2013; accepted for publication September 15, 2013
G. BREITER ET AL.
9:9
Gerd Breiter IBM Software Group, IBM Germany Research and Development, 71003 Bo¨blingen, Germany (
[email protected]). Mr. Breiter is an IBM Distinguished Engineer working in the IBM Research and Development Laboratory in Bo¨blingen, Germany. As the Cloud and Smarter Infrastructure Chief Architect for Cloud Computing, he is one of the key technicians defining the IBM cloud computing architecture and strategy. With more than ten years of experience in utility computing, on-demand computing, and cloud computing, he is one of the key experts within the industry in this new compute paradigm. He is co-leading the definition of the Cloud Computing Reference Architecture (CCRA), which serves as the architectural underpinning for all the IBM private and public cloud engagements. Another one of his recent focus areas is the architecture for the build-out of hybrid clouds and the software defined environment. Michael Behrendt IBM Software Group, IBM Germany Research and Development, 71003 Bo¨blingen, Germany (
[email protected]). Mr. Behrendt is a Senior Technical Staff Member in the IBM Cloud and Smarter Infrastructure CTO Office. He has a key lead role in building IBM’s next-generation cloud technology, which focuses on the development, deployment, and operations of Bborn-on-the-cloud[ applications. In addition, he is the lead architect for IBM’s Cloud Computing Reference Architecture (CCRA), being the blueprint for all clouds implemented by IBM. Before that, Mr. Behrendt led the implementation of clouds for many customers around the globe. He assumed this role after driving the development of Tivoli Service Automation Manager, one of IBM’s key cloud products. Mr. Behrendt is a Master Inventor and a member of the IBM Academy of Technology. He has 19 patents granted, has published numerous articles, and is a frequent speaker at conferences.
Institute of Electrical and Electronics Engineers (IEEE) Computer Society and Cloud Computing Community.
Isabell Sippli IBM Software Group, IBM Germany Research and Development, 71003 Bo¨blingen, Germany (
[email protected]). Ms. Sippli works for the Cloud and Smarter Infrastructure Lab Based Services Team. Her expertise covers cloud technologies, as well as high-availability, automation, and disaster recovery solutions. Her current job involves customer engagements, from consulting to implementation guidance, as well as research projects within the lab organization. Prior to her current role, Ms. Sippli was a key developer for Tivoli System Automation Application Manager and Multiplatforms. Ms. Sippli is also a member of the Cloud Computing Reference Architecture Team, and the Technical Expert Council Germany/Austria/Switzerland. Thomas Spatzier IBM Software Group, IBM Germany Research and Development, 71003 Bo¨blingen, Germany (
[email protected]). Mr. Spatzier is a Cloud Architect who works for the Cloud and Smarter Infrastructure CTO office and works at the IBM Research and Development Lab in Bo¨blingen, Germany. His focus areas include cloud orchestration and the implementation of standards in IBM’s cloud management products. Mr. Spatzier is active in cloud standardization activities. For example, he is coauthor and editor of the OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA). Furthermore, he is actively involved in the OpenStack Heat community to contribute to the evolution of an OpenStack orchestration layer in alignment with industry standards.
Manish Gupta IBM Global Technology Services, IBM India, Vasant Kunj, New Delhi 110070, India (
[email protected]). Mr. Gupta is an IBM Master Inventor and a member of the IBM Academy of Technology working as a presales cloud solution architect with IBM Global Technology Services (GTS). Most recently, he was a Senior Researcher at IBM Research, Delhi. He has developed reverse auctions for the IBM WebSphere Commerce Suite and led the designs for the health management component of WebSphere XD version 6.1 and the feature for automatic capture of a multi-image solution in IBM Tivoli Provisioning Manager version 7.1.1. He holds Ph.D. and master’s degrees, both in computer science from Indian Institute of Science, Bangalore, and a bachelor’s degree in physics (Hons.) from St. Stephens College, Delhi University. Simon D. Moser IBM Global Technology Services, IBM Germany Research and Development, 71003 Bo¨blingen, Germany (
[email protected]). Mr. Moser is a Software Engineer and Architect (M.Eng.) with the Cloud Computing Solution Development Group at IBM’s Software Laboratory in Bo¨blingen, Germany. He has published many papers, has given many talks at international conferences, holds various patents, and is recognized as an IBM Master Inventor. Mr. Moser is also the chairman of the OASIS technical committees for the standardization of the Topology and Orchestration Specification for Cloud Applications (TOSCA) specification. Ruediger Schulze IBM Global Technology Services, IBM Germany Research and Development, 71003 Bo¨blingen, Germany (
[email protected]). Mr. Schulze is a Senior Software Engineer in the Cloud Development Department at the IBM Research and Development Laboratory in Bo¨blingen, Germany. He received an M.S. degree in computer science from the Dresden University of Technology in 1996 and joined IBM subsequently. He has worked on a broad range of development projects, with a primary focus on cloud and data center provisioning during the last few years. He currently leads the Provisioning Development Team for the IBM Cloud Managed Services (CMS) and has been recognized for his work in CMS with a Best of IBM award in 2013. Mr. Schulze is a member of the
9 : 10
G. BREITER ET AL.
IBM J. RES. & DEV.
VOL. 58
NO. 2/3
PAPER 9
MARCH/MAY 2014
