COOL: A Model-Driven and Automated System for Guided and Verifiable Cloud Solution Design

Over the last few years, the rate of adoption of cloud computing has accelerated significantly. In the enterprise marketplace, managed cloud services are common in which an enterprise migrates all their applications from their own data centers to cloud and expects the cloud providers to manage it for them [1]. There are different levels of managed services: managed infrastructure only (virtual machines, network, etc.), managed infrastructure, middleware, and database but not applications, and managed applications in which the service levels are defined at the application level. The first step in a cloud sales deal is capturing the client requirements including application hosting, infrastructure needs, service level requirements, the need for disaster recovery, database resiliency, backup, etc. The problem is the automated generation of correct solutions that meets client’s requirements, as per the cloud provider’s offering.

In this demonstration paper, we present Cloud Solution Design Tool (abbreviated as COOL), which is a model-driven and automated solution design tool for infrastructure and managed services offerings of a cloud provider. COOL makes novel contributions by supporting the end-to-end lifecycle of technical solution design, starting from client requirements to generating a deployable solution, and the associated bill of material for costing/pricing. COOL also offers a guided solutioning approach to enable solution architects not only to create correct solution drafts, but also to modify an existing solution configuration in compliance with the provider cloud offerings.

The conceptual architecture of the Cloud Solution Design Tool (COOL) is depicted in Fig. 1. COOL consists of 7 main components, i.e. requirement capture, client requirement analysis, automated solution generation, solution validator, solution design editor, and output generator. These components sit on top of a persistence layer containing cloud data models, solution transformation logic, and an offering description language, which makes COOL’s data model extensible. The data model consists of a set of generic elements that form the model of the world, on top of which offering specific constructs are defined. The world data model includes a set of generic cloud data elements and their relationships, such as a virtual machine (VM), CPU, RAM, Storage, and network interfaces; Database, and Application. Offering-specific entities include elements for different types of VMs, database/OS types, and specific applications. For instance, for SAP Managed Services Offerings, the element of an SAP System defines a set of attributes to specify a system for an SAP Product with a specific role (production, Dev, QA–quality assurance-, etc.). An SAP system may be served by several servers/VMs. Similarly, the client requirement model is described by building on the world’s model constructs. The offering model extends the data model to describe a specific provider’s cloud offerings including applicable constraints, mapping and transformation rules, and solution patterns (pre-built solution offerings). The Requirement Analysis module uses formal methods to validate the client’s requirements w.r.t. provider’s offering including specific choice of values and types of resources/services requested. The solution generation approach in COOL employs a hybrid of model-driven and formal methods for generating correct solution drafts for given client requirements. This is done by first generating a solution skeleton using transformation rules, and then updating the solution by populating the constructs with valid values, using an approach called value propagation from constraint satisfaction domain [6], and adding any required constructs due to value assignment. At this stage, the draft solution still has attributes that may need to be further configured by the solution architect. As the architect makes changes, the Solution Validator uses a constraint solver [6], which reads the offering model, to check if the chosen values are valid with respect to the offering definition, otherwise identifies the conflicting attributes/values based on unsatisfiable core identification approach [6]. COOL’s Solution Design Editor supports guided solutioning through value propagation and guiding the user to resolve identified conflicts. More detail on technical architecture and implementation of COOL can be found in [7].

The conceptual architecture of cloud solution design tool (COOL)

Full size image

COOL makes novel contributions compared to the state of the art. As a cloud specification language, TOSCA [2] allows specifying application architecture and deployable application components. Similarly, CloudML [3] offers a language for representing cloud applications with a focus on managing elasticity and scalability at deployment time. OCCI [4] offers a generic metamodel and a model-driven approach for cloud application deployment. In industry, Microsoft’s MAP [5] supports assessment and planning of migration of Windows-based servers to Microsoft Azure. However, all these approaches focus on the specification and deployment of cloud applications. COOL addresses the open space of cloud solution design starting from complex client’s business and IT requirements, and offer a model-driven approach for solution validation and analysis, and requirement-offerings fitness in the sales lifecycle.

We demonstrate the use of COOL for end-to-end cloud solution design automation. In COOL, architects can create a solution design project including one or more of supported cloud offerings. Client requirements are separated into business requirements, and IT requirements. The business requirements consist of a set of questions, some disqualifying questions to check whether the offering can address the client’s need from a business point of view. COOL can take the client’s IT requirements in spreadsheet format that are loaded into the tool, or directly entered through the interactive IT requirements capture UI. Next, architects are guided to requirement analysis that checks whether various combinations of requested resources and services can be supported by the chosen offering, and creates a report consists of warnings and errors. For example, in a managed application offering, there may be only specific combinations of supported OS and Databases. To resolve these issues, the architect is offered an interactive UI to either modify the requirements, or allow the tool to use default values. After all errors are resolved (and not necessarily warnings), the architects can proceed with automated solution generation. The model-driven solution generation module generates a skeleton of the solution, by mapping requirement elements to offering elements, using the mapping/transformation rules. These transformation rules are codified as parameterized JavaScript code fragments over the data domain of requirements and solution models, represented in JSON. Data domains (values) are expressed in form of tables that can be edited by non-expert users. The transformation logic lives out of the main application code, and it is updatable independently of the application. Therefore, new Cloud offerings can be added to the tool, or existing ones modified, without impacting COOL’s application code.

After the model-driven transformation step, the generated solution object is passed to a constraint satisfaction solver, which understands the offering model and associated solutioning constraints (these are automatically generated from the offering models). In this process, it progressively populates the attributes with allowable values based on other chosen values (the same as in the example of specific allowed combinations of OS and database types). Value propagation logic may add new elements to the solution object based on attribute values, as well, for example additional CPUs, RAM, Storage or VMs to meet progressively updated solution. Once a solution draft is generated, if some attributes are note automatically populated, COOL marks the solution as incomplete, and points architects to make applicable selections. If the architect’s updates lead to an incorrect solution, COOL flags the solution as incorrect and identifies conflicting solution elements and values. Once the solution is valid and complete, the COOL allows generation of deployable solution specification, according to the offering logic, and also outputs detailed billing feature codes for a downstream solution costing/pricing tool. In the demonstration, we will also show accelerated solutioning options through predefined requirement and solution templates, based on best practices.