The automation of Cloud application provisioning is one of the most important key success factors for Cloud Computing. In case a complex composite Cloud application has to be provisioned across multiple different private Clouds, a single centralized provisioning engine or workflow is not possible: For security reasons, private Clouds typically do not expose their internal provisioning APIs to the outside. Thus, it is impossible to make them callable by an external service. Consequently, distribution of provisioning logic across multiple workflows is required. This paper envisions that choreographies can be used to distribute the provisioning logic.
Cloud computing gains more and more attention due to its economical, organizational, and technical benefits. The reason for this evolution lies in the essence of Cloud computing—the industrialization of IT [ ]: application provisioning and management are automated as much as possible and follow well-defined processes to provide industrial properties for virtualized infrastructure, middleware, and software as a service. To enable this, Cloud providers employ Cloud management software to virtualize, manage, and operate their physical infrastructure. One part of this management is responsible for rapid on-demand provisioning of parts of a multi-Cloud application for customers. It has been shown that not all management tasks can be done in a declarative way [ ]. Moreover, many applications need to consume different services for their particularities that are not completely provided by one single Cloud provider [ ]. Thus, these applications need to be distributed across several different Clouds to gain the needed functionality [ ]. Distributing components of one application among multiple Clouds, however, increases the complexity of provisioning. Provisioning applications on a single Cloud (based on internal provisioning engines) helps the Cloud provider to secure the system: most of the required management operations can be executed locally by provisioning engines behind strict firewalls and only coarse-grained facade APIs need to be exposed to the outside. This changes if the application is distributed across multiple Clouds: the provisioning on different Clouds needs to be orchestrated by an external provisioning engine. Thus, Cloud providers have to expose also the low-level management operations, interfaces, and APIs to make PHP Container (Apache PHP-5
Module)
Ubuntu (Ubuntu-14.04
VM) them accessible from the outisde. Figure shows this kind of provisioning for an application hosted on a Tomcat as WAR file. First, a virtual machine has to be instantiated, then a Tomcat has to be installed. Afterwards, the WAR file has to be deployed and configured. The calls to the respective management operations have to pass the firewall of the local Cloud provider, which might not be allowed.
We have the vision of modelling the provisioning of distributed multi-Cloud applications as a choreography model, wherein each participant flow executes the provisioning of one part of the application at one provider.
As a consequence, we need a means to coordinate the provisioning of multiCloud applications in a way that the execution of provisioning logic remains on the side of Cloud providers. This avoids that the low-level management functionalities must be made accessible from the outside. Our proposed solution is to use choreographies [ ] for application provisioning: the provisioning logic has to be split among the participants, each representing a local Cloud provider. Figure presents such a model for the described example. Now, the remote workflow sends a single message triggering the provisioning within the local Cloud provider. The provisioning is implemented by a workflow running within that Cloud provider.
The APIs for each component still need to be accessible. With the current approach, they only need to be accessible from local environment and not from the outside. We claim that this shift makes it easier to make the APIs accessible for provisioning workflows. Regarding the firewall setup, one access to the local Choreographies are Key for Provisioning management infrastructure has to be opened. This endpoint is known in advance. In the orchestration-based provisioning, the concrete endpoints are not known in advance as the reachable components are provisioned and thus not available before. For instance, Tomcat is installed during the provisioning and its IP address is not known in advance.
Herry et al. [ ] generate provisioning workflows out of given constrains. Our approach relies on human-generated choreography models. The infrastructure for executing the provisioning workflows does not need to be available all the time: Vukojevic-Haupt et al. [ ] showed that it is also possible to provision that middleware on demand.
Schulte et al. [ ] identify the state of the art of elastic Business Process Management with a focus on infrastructural challenges. They focus on the runtime of business processes. Their results can also be applied to provisioning.
Another approach is to model a single provisioning workflow and to split this workflow [ ] according to the distribution of the topology. For the split, new coordinators might be required [ ]. When using a choreography model, the provisioning workflows and their coordination can be generated easily as the coordination of participants is inherently specified by the choreography. We aim to use this model-driven approach to generate the provisioning workflows and their coordination out of the choreography model. Thus, the provisioning choreography is not seen as purely descriptive means, but as a starting point for an automatic processing.
Weber et al. [ ] propose to use blockchains in order to enact choreographies in a decentralized fashion. They use the Blockchain concept of “Triggers” to facilitate communication between internal and external APIs.
The idea presented in the paper is not tied to concrete languages or tools. It is possible to model it in an arbitrary language. This includes BPMN TOSCA [ ], which is a language tailored to provisioning with TOSCA [ ]. In our setting, we use the domain-specific language BPMN TOSCA as it allows focusing on the provisioning logic without having to abstract from the nodes in the application topology when modeling a provisioning choreography. To validate the approach, we plan to (i) enable swimlanes in our current modeling tool and (ii) to show that the approach is feasible in our OpenTOSCA eco system.
The provisioning workflows can be seen as subprocesses [ ] of the central coordinator as they receive one instantiation message and then no communication is taking place any more. In more complex settings, it might be necessary that the provisioning workflows communicate with the coordinator again and thus forming a choreography with arbitrary interactions between caller and callee [ ]. The discussion of this aspect together with possible autonomy grades [ ] is part of our future work.
Acknowledgments This work is funded by the BMWi project SmartOrchestra ( MD F).