The development of the StratusML framework and Liberate approach laid the groundwork for several future directions. The following is a list of possible future work:
• extending the framework to support micro-services architecture and containers tech- nologies: As microservices and container-based applications are getting more mo- mentum, there is more demand on frameworks that facilitates (i) designing applica- tions by composing micro-services independently from any container technology (e.g. Docker), and (ii) enabling the linkage between the build systems and infrastructure deployment artifacts. StratusML alleviates some of the challenges regarding service integration and operation, by facilitating generating the platform artifacts that are required to schedule and manage the deployment of containers. One of the direct extensions of the StratusML framework would be to enable generating the configu- ration artifacts of the container images. This will require an additional abstraction
layer that is closer to the containers technology to allow creating the containers build files. There will also be a need for another layer of abstraction, at a higher level, that facilitates utilizing microservice architectural patterns and templates to generate their corresponding artifacts.
• supporting a wider range of cloud providers: StratusML currently provides out of the box templates for generating the platform configuration for windows azure and google application engine. In the future, I will work on creating more templates to support more platform providers. Moreover, I will work on providing transformations to some of the standard cloud description languages (e.g., TOSCA [17])
• extending the StratusML to support IoT services: IoT-based services require manage- ment frameworks that support managing both the devices at the edge and the sup- porting services at the cloud platform. StratusML supports managing only the cloud platform side of the network, more work will be required to support the modeling and configuration of the edge devices. Moreover, bandwidth and latency limitations at the edge impose challenges on transferring data from the smart edge devices to the cloud. To deal with these limitations there is a need for a technological layer that sets between the edge devices and the cloud and addresses scalability and latency and provides intelligent control for the data that is generated at the edge devices. CISCO refers to this layer as Fog Computing [20]. Similar to cloud computing, the fog con- sists of compute and storage devices. However, different from the cloud dedicated datacenter model, the fog uses an ad-hoc model that depends on mobile devices that are close to the edge devices. The analytical applications that run on the fog have specific requirements. For example, these applications need to adhere to the different set of standards and protocols that are used by the different devices. In the future, I will work on developing an abstraction layer, similar to the one that I developed for the cloud, in order to facilitate deploying IoT services on the fog and automatically configuring them to the target edge devices.
• automating partitioning of applications into microservices: The current framework assumes the developers can make the right decisions in terms of partitioning the ap- plication into modules (microservices), and then distributing them into geographic locations to achieve the desired availability level. However, partitioning applications into cohesive modules is difficult and requires knowledge about the dependency rela- tionships between the different modules. In the future, I am planning to use graph theory and clustering techniques to extend the framework to support the automatic partitioning of applications into micro-services that can be hosted into containers
and to group micro-services into container pods. This fine-grain decomposition will have a huge impact on applications’ malleability, self-adaptation and its availability. • implementing feedback loops between the runtime model and the performance model. Currently, StratusPM requires manually specifying the performance model parame- ter. Future work will investigate combining the application performance monitoring (APM) and round trip model driven techniques to fully automate the application adaptation process. I will be utilizing the platform centralized logging capabilities to facilitate the management of distributed services to remediate issues or to alert operators as needed.
• supporting other target performance models. Currently, the proposed framework supports generating LQN models from the StratusPM models. In the future, I am planning to support transformations to other performance modeling languages that address modeling software components and thier underlying platforms such as Palla- dio Component Model (PCM) [11]. Supporting other performance modeling frame- works will give the users of the StratusML framework more flexibility and options to compare the performance results.
• expanding the application of domain schema matching to automate model-driven migration: In this thesis, the liberate approach has been proposed to deal with the vendor lock-in problem, by uncovering the alignments between the concepts of the provider specific schemas. Liberate is a generic approach that can be equally ap- plied to other domains. In the future, I will examine the approach in the model driven-engineering domain to semi-automate the process of creating transformation rules between the source and the target models on the fly. Particularly, I will inves- tigate how to automatically formulate mappings (transformation rules) based on the generated matches.
• further evaluation for the framework: In this thesis, I used scenario-based examples to demonstrate the usefulness and capabilities of the proposed framework. In the future, I am planning to conduct a comprehensive empirical study to evaluate the impact of the proposed framework on the roles of the cloud stakeholders and the cloud DevOps process. Particularly, I will evaluate the usability, domain coverage, correctness, maintainability, and domain specificity. That is the DSML small enough, leaving out language features that do not contribute to the purpose of the language.