The optimal execution of parts of cloud applications, so-called fragments, is the essence of PrEstoCloud. As mentioned in our previous post, the TOSCA language is used and extended, to express the deployment of application fragments, i.e., code methods, functions, classes, microservices, etc. How does PrEstoCloud support the deployment of application fragments and what are the configuration options?
The PrEstoCloud component responsible for deployment of application fragments is the Data-Intensive Application Fragmentation & Deployment Recommender (DIAFDRecom). DIAFDRecom is capable of parsing (pre-)annotated Java code fragments, as well as DevOps preferences and requirements (e.g. cloud provider requirements) expressed in a policy file. These requirements are then grouped and a preliminary (“type-level”) TOSCA file is produced. This type-level TOSCA is subsequently pushed to the PrEstoCloud Repository, whence it is retrieved by the appropriate Control Layer components in order to calculate the optimal configuration for the initial application deployment.
The workflow of the DIAFDRecom component is illustrated below.
The annotations of the developer reflect not only processing requirements which should be met by the host of a fragment, but also placement restrictions (e.g. collocation & anti-affinity statements) as well as deployment guards (maximum number of instances of each fragment). Once the annotation of the code has finished, the DevOps can further direct the placement of the topology with additional requirements, using a Policy file (e.g. specifying the Cloud provider to be used). Then, DIAFDRecom processes the requirements included in these files, and produces output in TOSCA format, understandable by the components of the Control layer, which can process it and instantiate the processing topology in an automatic way.
DIAFDRecom provides a solution for the DevOps and the developer to express their requirements in an easily-understandable format (key-value in the policy file, and annotation-based in the source code), and yet be able to communicate over a modern cloud standard (OASIS 2017). It has been built in a modular way in order to permit enhancements, and a new, improved version is already underway!