DECIDE workflow starts from the design of the multi-cloud native application that is sensitive to the changeable situation in a multi-cloud based environment. For that, developers establish a set of quantitative (i.e. Mean Time Between Failures (MBTF), availability, response time, lag, cost, throughput) and qualitative (i.e. security, location, financial, low / high technological risk) NFP s that the application must comply with and uses DECIDE’s ARCHITECT [KR2] tool to support the design and development process of the distributed application and its components through the architectural implementation of patterns and the recommendations derived from the tool on which patterns to apply in which components [KR2 ]. Qualitative NFR will only be applicable for the selection of the cloud services, while quantitative will be used for monitoring and simulation purposes. DECIDE ARCHITECT also follows the continuous DevOps philosophy in the new ‘continuous architecting’ way. After the application of this initial set of multi-cloud based architectural patterns, the developer follows with the implementation process (following the CQ, CI and again continuous architecting DevOps approach). For the implementation (continuous development, CI, CQ, CD), DECIDE will integrate open environments such as Eclipse,Git, Puppet, Chef, Docker, Jenkins, and Vagrant, among others.

As a next step, DECIDE will support the selection of the deployment topology and the underlying selection of the most suitable (combination of) cloud services through the OPTIMUS tool [KR3] . The OPTIMUS tool will base the simulation on the profiling of the different components to be considered: profiling of the multicloud application, profiling of the cloud services to be used (data bases, processing clusters, etc.), profiling of the communications between nodes, and profiling of external services to be used by the multi-cloud application. For the modeling of the profiling information so that it can be processed, represented and used, existing technologies such as CloudML and OpenTosca will be evaluated. Optimization algorithms such as genetic algorithms, Harmony search, or Dandelion codes will be used by OPTIMUS to provide a set of potential combination of cloud services that fulfills the established user requirements. Along with these simulation results, OPTIMUS will provide the developer with information about the required changes in the application structure/schema/code to achieve the required configuration deployment and the technological risk that each of these configurations imply (low technological risk or high technological risk), i.e. moving from an IaaS to a PaaS, move from one PaaS to another like OpenShift vs. Cloudfoundry. 

Once the application is implemented and the (combination of) cloud services are selected, the developer needs to define the service level agreement that the application will offer to end-users (MCSLA). This MCSLA will be influenced by the SLAs of the underlying (combination of) cloud services to be contracted. DECIDE Multi-cloud native applications DevOps framework [KR1] will support the definition of this composite MCSLAs (Multi Cloud Service Level Agreement) and the corresponding SLOs (service level objectives) of the application and the dependencies and needs on the underlying (combination of) cloud services in a machine-readable format for the representation. This composite MCSLA will be then assessed at run time to check if it is being accomplished. To finish this first cycle of the development phase, the developer will select the deployment scripts based on the selected configuration from the simulation phase through the continuous deployment supporting tools and the architectural patterns for deployment. Each deployment configuration will be stored in the multi-cloud native application controller, maintaining the current deployment configuration situation as well as the historic of the previous deployment configuration used, so that they can be checked in the re-deployment phase.

Once the application has been developed, the operation phase starts. The application owner contracts the corresponding (combination of) cloud services (accomplishing the required MCSLAs) and deploys the application over different clouds (ACSmI [KR4]) using the DECIDE self-adaptation application provisioning tool (ADAPT [KR5]) . The following CSPs and corresponding technologies will be integrated in DECIDE: ARSYS (VMWare), AIMES (modified OpenStack), TECNALIA (OpenStack and OpenShift), Amazon as well as other European Cloud Service providers.

During the application operation phase, the ADAPT tool [KR5] will continuously monitor and assess the fulfillment of the established NFR and MCSLA. If a violation of any of the former metrics occurs, the self-adaptation tool through the ACSmI [KR4] will assess the operation of the (combination of) cloud services selected and discard those that are affecting the MCSLA. If the application configuration has been established as of low technological risk, the multi-cloud application will be self-adaptive and it will be redeployed automatically, following a new deployment configuration. In case the application has been identified as high technological risk, once it has identified the aspects that are affecting the malfunctioning of the application, it will alert the operator and using the OPTIMUS tool it will look for new (combination of) cloud services to set up a new deployment schema. The DECIDE application controller and the continuous deployment supporting tools will support the selection of the new deployment scripts (based on the architectural patterns for deployment), and thus semi-automatically re-deploy it. DECIDE will also support parallel re-deployment strategies definition and multiple cloud layers. In this case the new operation phase will start again contracting the new services and deploying the new scripts into the new configuration of cloud services