-In cloud computing, modeling can be used to specify service topologies. Following a model-driven approach provisioning can be automated resulting in a significant reduction of time and costs. Yet, a forward engineering approach is limited to initial setups. That is, changes introduced posterior to a generation are not addressed per se when a complete regeneration is to be avoided. For dealing with differential changes of infrastructure service models, a model-based round-trip engineering approach is proposed that combines the power of model-driven generation with runtime reflection. For this, a de facto runtime model is reverse-engineered and model differences are calculated and operated on for enforcing a de jure model. While showcasing how to evolve a forward engineering approach accordingly, a particular implication of this contribution is the possibility to facilitate migration of cloud infrastructure services. Index Terms-cloud service, IaaS, migration, model-based, model difference, OpenStack, provisioning, service topology
directly participate in engineering processes by relating to
constructive models that abstract from technologies. In the
context of cloud computing, service topologies for
cloudbased solutions are modeled by architects. For instance, a
Web application may comprise a load balancer, web servers,
application servers, and a database system. Using modeling
techniques, the comprised services such as the infrastructure
services are specified in terms of computing power, memory,
storage, network, and security rules (cf. [
The provisioning of cloud services in terms of infrastructure
is realized by one or multiple infrastructure as a service (IaaS)
providers. By applying a model-driven approach provisioning
can be automated (cf. [
For example, a cloud architect could decide to add another server instance such as a virtual private network (VPN) gateway to the service topology of the solution. This would not affect already provisioned cloud services, but require the instantiation of a new virtual machine and the deployment of particular security rules associated with the VPN service. Given a forward engineering approach it is only intended to provision an entire service topology. In this case, however, it would be more desirable to only consider the changes to the original model and perform required actions. In other cases it might be more constructive to compare a model describing the target configuration against reality.
For overcoming limitations of forward-engineering and for considering existing infrastructure services a model-based round-trip engineering approach is proposed showcasing how a former approach can be evolved accordingly. It incorporates runtime reflection for applying differential changes to an existing service topology. Comparing two models, such as a target de jure model with a current de facto runtime model, the work can be applied for enforcing conformance. Moreover, it can facilitate alignment and migration of infrastructure services between cloud deployments.
This paper is structured as follows: The approach is depicted in Section II and Section III describes technical implementation details. Different types of application scenarios – in particular service alignment and migration – are explained in Section IV. Experiences from a case study are presented in Section V followed by a discussion in Section VI. Finally, Section VII compares to related work and Section VIII concludes.
MODEL-BASED ROUND-TRIP ENGINEERING APPROACH
For the provisioning of cloud infrastructure services, a
model-driven approach can be followed as proposed in [
Figure 1 gives an overview of the round-trip engineering approach. Initially, an architect specifies a cloud infrastructure service topology in terms of a de jure model. It is compared with another model originating from the runtime. For generating such a de facto model, a reflection service interacts with the interfaces of the IaaS provider. From the two IaaS models a model comprising model differences (referred to in this paper as a diff-model) is calculated which is processed by the execution engine. Based on the differences and depending on the kind of difference, the affected model element, and its content a model transformation takes place. Appropriate IaaS consumers are generated that – when executed – enforce the de jure model. An auxiliary generated business process helps to orchestrate these. In case differences are discovered that shall be subject to a review – e.g., when provisioned services are to be terminated – the business process also involves a human task.
typical implementation are explained. Eclipse Xtext (Xtext) 1 was used to define a metamodel using a textual grammar. Diff-models are calculated using EMF Compare 2. For model transformation, realizing the execution engine, Eclipse Xtend (Xtend) 3 was used. OpenStack 4 served as an IaaS solution.
Figure 2 depicts a metamodel comprising concepts from OpenStack Compute (Nova), a pendant to Amazon Elastic Compute Cloud (EC2) 5. An IaaS project represents a tenant comprising cloud infrastructure services such as server instances, volumes, and security groups. Firewall rules (FWRules) translate to EC2 security rules and specify permitted protocols and/or open ports.
Models conforming to this metamodel were directly
transformed to IaaS consumers in the forward engineering approach
(cf. [
The reflection service, as required for evolving the forward engineering approach, was realized as a representational state transfer (REST) service. Associated with a deployed IaaS solution, it consumes a tenant identifier and returns a de facto model reflecting the current provisioned cloud infrastructure services of the tenant. As mentioned, such a model conforms to the same metamodel as used for design time.
The service invokes the IaaS provider’s application programming interfaces (APIs) for performing the runtime reflection. Programmatically, first, a token is retrieved after an initial authentication that is used in subsequent requests. Next, a list of security groups is requested. For each of the security groups, the security rules are requested then. Next, a list of server instances is retrieved. Iterating over all the instances, the various associated properties are looked up such as the image, the flavor, the assigned security groups, the security key, and associated IP addresses. Finally, volumes and associated instances are looked up before the token is invalidated. Meanwhile, the model is populated with the obtained information. Finally, the de facto model is returned to the caller.
From two models (e.g., one model specified by an architect and one model generated by the reflection service as outlined in the previous section) a diff-model is calculated describing the discrepancy between a de jure and a de facto model. For calculating a diff-model a two-way comparison is performed using EMF Compare with the matching strategy being based on the object content ignoring identifiers. A resulting kind of difference categorizes as an addition, a deletion, a change, or a move. Former differences that merely depict extensions to the service topology can be resolved by provisioning the additional cloud services. Other differences may require review and approval prior to application. For this reason, different IaaS consumers are generated containing the respective service calls as described next.
Next, the calculated diff-model is processed by the execution engine. Depending on the kind of difference and the concerned model element respective IaaS API calls are generated. Note that the IaaS metamodel is closely related to IaaS APIs (i.e., OpenStack Identity Service (Keystone) and Nova). For this reason transformation rules can easily be expressed programmatically by MDE developers. Similarly to the forward engineering approach, Xtend extension methods have been implemented in the round-trip engineering approach: Besides the object (e.g., Server) also the container (e.g., IaaSProject) and the name (e.g., servers) of the model element are taken as parameters into account as well as the kind of difference (e.g., addition). This way, it is similarly possible to generate respective actions although a diff-model is processed. Evolving a forward engineering approach, thus, requires respective adaptation of the execution engine.
Table I displays some examples of how various differences are related to IaaS API calls and considered by the model transformation. For example, in case the diff-model contains an addition of a server instance (IaaSProject.servers), a REST consumer is generated that when executed calls the POST operation ftenant_idg/servers. While the Uniform Resource Locator contains a path parameter for the tenant identifier other data has to be passed in the body using the
image or the to be associated security groups. If a difference does not comprise all required information for code generation, additional sources (e.g., a list of not yet considered differences) need to be consulted by transformation rules that are thus accessible within an instance of the execution engine.
Although the levels of abstraction between different elements of the metamodel and API operations are often alike, this is not always the case. Therefore some differences do not result in a direct mapping. That is, sometimes multiple actions have to be generated for a calculated difference. For instance, a user may have to be created prior to assigning her to a tenant. Also, for assigning a floating IP it may first be necessary to allocate a floating IP from a pool that in a second step can be assigned to a server instance. Such a technical detail is abstracted from in the metamodel and therefore has to be incorporated during code generation. Another cause that may complicate implementation of a model transformation is the design of the target language, i.e., the OpenStack APIs in this work. While most REST operations are similar between the kinds of difference, there are exceptions to a potential naming convention. For instance, not all operations that are related to deletions use the Hypertext Transfer Protocol option DELETE: For releasing a floating IP a POST request has to be issued and the keyword unreserve has to be passed in the body.
Processing order is crucial because of composition relationships. For example, if a difference consists of an existing server instance referencing a new volume group (another difference), the volume group has to be created first and can then be attached to the server instance. Contrary, if the volume group is to be deleted again it has to be detached from the server instance first and can then be terminated. Thus, the algorithm needs to apply differences respectively in order, e.g., by traversing the metamodel, by following composition relationships, and by applying matching differences only once.
Finally, differences that do not categorize as additions or deletions may be transcribed or may need to be handled accordingly. Sometimes there is no disparity in state if a difference such as a change or a move is realized using a deletion and addition in which case these operations of the API can be resorted. If this is not the case the respective
additional operations to the minimum set.
The generated actions (i.e., API calls) are aggregated in two IaaS consumers: non-critical alignments, i.e., actions resulting from additions, are placed in the first consumer. Actions originating from other differences that require review are stored in a different consumer. In addition, a business process is generated for their orchestration and for incorporating a human review.
Once the execution engine has processed the diff-model the auxiliary business process is initialized that invokes the consumer comprising the non-critical alignments. In case of critical alignments, e.g., differences that result in the termination of infrastructure services, a review is to be undertaken. For this the generated business process contains approval tasks relating to the critical differences. When approved the respective IaaS consumer is invoked by the business process.
by discussing different types of scenarios. That is, for all of the scenarios the same approach is applied as presented in Section II using a de jure and a de facto model for determining respective provisioning actions.
The second type of usage scenario derives from the initial motivation described in the introduction. In this scenario an initial provisioning as previously described has taken place. The original model was modified then. Instead of rebuilding the entire service topology from scratch, changes are identified first and applied to the existing IaaS provider.
While in this scenario it would be possible to compare two models from design time, i.e., a revised version with an original describing the current topology in terms of infrastructure services the latter model is reverse-engineered using a reflection service. A reason for this is that the resulting model effectively constitutes a de facto model for the given point in time. If the former version of a model is to be used as the basis for comparison it would require that it reflects reality and that no changes must be undertaken apart from the model. Relying on the reflection service, this restriction is not necessary. Indeed, services can manually be provisioned without the risk to jeopardize the round-trip engineering approach.
Thus, in this scenario the de jure model is a revised version of a model and the de facto model is obtained using the reflection service. As in the previous scenario, the differences may only comprise additions. In this case they are applied directly. However it is also possible that differences are of other types. In such cases a review is scheduled.
The first type of usage scenario equals simply to what has C. Alignment of Cloud Infrastructure Services been covered by the functionality of the forward engineering Given two different cloud tenants, how can the cloud approach. That is, from a service topology, infrastructure infrastructure services be aligned between them so that one services are to be provisioned in a greenfield scenario. As tenant comprises the same infrastructure services as the other? no cloud infrastructure services are existing in the respective With the approach it is equally possible to compare two tenant, the reflection service yields an empty de facto model. runtime models, e.g., for aligning provisioned cloud infrasThis is compared against the user supplied de jure model tructure services of two tenants in different clouds. For this comprising the to be provisioned infrastructure services. As a the respective reflection services yield corresponding models. consequence, the diff-model comprises additions only. Each According to what model is elected as the de jure model addition is transformed by the execution engine into code that the tenant of the other model is aligned subsequently. This realizes the provisioning of the respective service. Thus, in scenario is similar to the previously described scenario in a contrast to the forward engineering approach the execution sense that the diff-model may contain any kind of difference engine of the round-trip engineering approach processes a (i.e., not only additions as in the initial provisioning) and that diff-model. In both approaches, a complete IaaS consumer the model transformation is alike. In fact, the only distinction for provisioning all of the services is generated using model is the selection of two runtime models. When comparing two transformation: By comparing a model against an empty model, tenants using the reflection service with the target being empty, the round-trip engineering approach yields the same actions all cloud infrastructure services from the source tenant will be as the forward engineering approach that processes the model. provisioned at the target tenant. This is exploited for facilitating In fact, an IaaS consumer that results from transforming the the migration of infrastructure services as described next. diff-model instantiates all the infrastructure services as present in the model. As a consequence, the IaaS consumers generated D. Facilitating Migration of Infrastructure Services by the different approaches are equal in terms of their behavior. Given two IaaS deployments, how can the infrastructure
This way, functionality of the forward engineering approach services from one cloud be migrated to the other? is covered and as required by this scenario. In the following By realizing the alignment of cloud infrastructure services some further application scenarios are described proving the as previously described, migration can be facilitated. First, the round-trip engineering approach to be a superior alternative to tenants are created at the new deployment. Next, they need to the formerly presented forward engineering approach. be migrated. For this, two runtime models are compared; one
originating from the source cloud comprising the provisioned services to be migrated and one empty model from the target. Next, the execution engine aligns the target with the source for facilitating the migration of the cloud services. Finally, the original cloud services are terminated once the migration has been affirmed. While this does not realize yet complete migration of cloud services (e.g., the data stored in volumes which is not in scope of this paper), it does automate some basic steps and as a consequence facilitates migration of cloud infrastructure services. After the alignment of the infrastructure services has taken place, the business process schedules a task for manually completing and verifying the migration. When the migration is affirmed to have succeeded the IaaS consumer is invoked for terminating the original cloud services completing the migration.
ing and for capturing concepts from IaaS provisioning (see Figure 2). In addition to an IaaS metamodel the round-trip engineering approach relies on a diff-metamodel. The diffmetamodel provides the means to describe changes between (any) two models that conform to the same metamodel. In particular it comprises addition and deletion of model elements as concepts. This diff-metamodel does not need to contain domain specific concepts but can be a generic metamodel.
That is, for any metamodel it can describe changes between
conforming models (cf. [
V. EXPERIENCES FROM A CASE STUDY Although the same IaaS APIs can be used in both approaches, In a case study, a migration from OpenStack 2012.1 (Essex) the forward engineering approach does not perform runtime to OpenStack 2013.2 (Havana) was attempted. For this, the reflection as in case of the round-trip engineering approach. setup and procedure as described in the previous paragraph was For this reason the models used in the forward engineering chosen. That is, two OpenStack deployments were available approach are limited to design time models whereas the roundin parallel, with one constituting the target cloud. While trip engineering approach also incorporates reverse engineered the reflection service operated on the former version, the runtime models. In contrast to the forward engineering apexecution engine generated IaaS consumers for the later version. proach, the execution engine of the round-trip engineering While realizing a proof of concept, the prototype was not approach does not operate on a model conforming to the IaaS deployed to undertake a factual migration of real IaaS tenants metamodel. Instead, a diff-model is processed. Both approaches as further problems need to be addressed such as how to migrate can be used for an initial provisioning. In addition, the round(assigned) floating IP addresses. Also the migration of data, trip engineering approach is able to apply incremental changes e.g., in volumes, was not yet tackled. Finally, the monitoring posterior. Finally, the forward engineering approach operates and reporting of the overall migration has to be worked out. on a single cloud whereas the round-trip engineering approach
As some code in the reflection service and the execution can be applied in a multi-cloud deployment, i.e., to compare, engine is specific – not only to the IaaS solution but also align, and migrate infrastructure services between two clouds. IaaS version – dedicated plugins hold respective parts. In fact, when conducting the case study with these two OpenStack B. Round-Trip Engineering Approach deployments an incompatibility of APIs was detected. While libraries and projects (e.g., DeltaCloud 6) exist that try to abstract and unify various IaaS interfaces there is no established standard for IaaS provider services adequately implemented by IaaS solutions. EC2, widely adopted in industry, could be a candidate, but because of some limitations and convenience (e.g., names of server instances) the (OpenStack native) Nova API was chosen. During prototyping it was discovered, however, that between these two versions the API underwent some changes that required adaptation of the code. With the possibility to provide plugins for each specific IaaS (version) the prototype is extensible and adaptable. This way, further IaaS solutions can be supported for applying the approach.
provisioning (e.g., in an iterative practice) but potentially also
valuable to stakeholders for representation purposes (cf.
modelbased reporting [
Note that certain adaptation scenarios can already be achieved by providing only some transformation rules. For example, if the diff-model contains only an addition of a new server, it suffices to call the transformation rule for generating the respective Nova API operation as shown in Table I. Thus, not all kinds of differences need to be supported for covering a wide range of adaptation scenarios. Yet, for the transformation to be complete and fully automated any model element of the metamodel must be mapped depending on the kind of difference to appropriate API calls.
As mentioned, the work serves as a first step towards the migration of cloud services. For completely migrating cloud infrastructure services further work has to be carried out. For example, there are remaining challenges such as how to migrate (assigned) floating IP addresses.
VI. DISCUSSION
In contrast to a na¨ıve model-driven, and forward-only approach, the presented model-based round-trip engineering approach enables alignment of existing cloud infrastructure services. Incorporating runtime reflection for reverse-engineering a runtime model of infrastructure services the approach paves the way for facilitating their migration.
6http://deltacloud.apache.org
VII. RELATED WORK
work, approaches, and efforts from academia and industry. First, the topic of model differences is discussed briefly. Next, some related work on runtime models and model-based adaptation is presented. Finally, the cloud computing context is looked at.
Cicchetti et al. [
The idea of comparing a target model against reality as
applied in this work is the base of many studies. Bencomo et
al. [
The OASIS Topology and Orchestration Specification for
Cloud Applications (TOSCA) standard 8 is not limited to
infrastructure services but covers the complete service stack
and management of cloud applications (cf. [
CloudFormation 9 and the OpenStack Orchestration (Heat) 10 pendant permit to describe setups in a file based manner. While not at a modeling level these technologies can be used to provision services in different cloud regions. Also, reverse engineering may be possible, yet, the comparison and resolution for aligning infrastructure services is not addressed. 7http://cloudml.org 8http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.pdf 9http://aws.amazon.com/cloudformation 10http://docs.openstack.org/developer/heat/
DSLs (e.g., CloudML see above) targeting cloud applications:
Bergmayr et al. [
The migration of cloud infrastructure services between IaaS deployments can be facilitated using a model-based round-trip engineering approach combining generation techniques with runtime reflection. By realizing this, this paper showcased how a model-driven forward engineering approach can be evolved to a round-trip engineering approach by enriching a metamodel with runtime aspects, by establishing a reflection service, and by basing the model transformation on processing a diff-model.
The author would like to thank peers cordially for valuable feedback, communicative exchange, and for kindly providing information of avail.