What is the potential of the DevOps Modelling Language (DOML) [1] to be extended with more functionalities?

This blog post presents the recent evolvability of DOML to the extended version DOML-E. In particular, it elaborates around the DOML extension mechanisms and innovations.

DOML is a domain-specific language designed for modelling cloud applications and infrastructural resources, hiding the specificities and technicalities of current IaC solutions and increasing productivity of DevSecOps teams. Aiming at reducing the effort (see Table 1) needed to automate the deployment and operation of an application in combination with its underlying infrastructure, this has resulted in the development of a high-level modelling language that is then translated, through the Infrastructural Code Generator (ICG), into de-facto Infrastructure as Code (IaC) standard languages supporting the Ops phases of the software lifecycle.

Table 1. Metrics on the comparison between DOML and some other IaC languages

In order to meet the needs of the continuously evolving cloud markets, DOML includes extension mechanisms that allow the users to create new concepts from the existing ones. These extension mechanisms are referred to as DOML-E [2]. They allow new infrastructural components, e.g., for software execution, network communication, cloud services, or data storage, to be incorporated in the DOML language. So, this keeps the language open to the addition of new resources, both at the abstract and concrete layers.

In a nutshell, DOML aims at offering a high-level declarative approach to the definition of an application and its infrastructure. DOML models are mainly structured in three layers. Specifically, software components (e.g., web servers, databases, etc.) are described in the application layer, abstracting away from the infrastructure on which they are supposed to run. Infrastructure components are specified in the abstract infrastructure layer, and then linked to the applications they are supposed to host. This layer models infrastructural facilities, such as virtual machines, networks, containers, etc., without referring to their actual concretization in specific technologies (e.g., AWS or OpenStack VMs, Docker containers). This last aspect is tackled by the concrete infrastructure layer, where the user specifies the infrastructure components offered by the Cloud Service Provider (CSP).

The adoption of such approach allows us to overcome a limitation of the currently available IaC languages that tend to focus on specific aspects, either the configuration of the specific infrastructural elements or the installation and configuration of software elements, thus making difficult for DevOps teams to have a complete overview of their whole system [3].

 

Figure 1. DOML positioning in the PIACERE approach

Figure 1 shows the positioning of the DOML in the PIACERE ecosystem. The numbers associated to the arrows are described in detail in [4] and represent the steps of the workflow activated when a user wants to create a DOML model. More specifically, the user exploits the Integrated Development Environment (IDE) [5] to design the model. The DOML ecore [6] and Xtext [7] representations allow the IDE to support the user by providing suggestions about the syntax to use. Through the IDE, the user can exploit all other tools in the figure. More specifically, through the Infrastructural Elements Catalogues the users can obtain information about the resources that are known to PIACERE. Through the Model Checker it is possible to verify the correctness of the model in terms of internal consistency and fulfilment of explicitly defined requirements. Through the IOP it is possible to obtain a mapping of the abstract infrastructure layer into the concrete infrastructure that best suits the non-functional requirements expressed in the DOML model. Through the IGC [8] it is possible to generate IaC from a DOML model. To ensure that the generation mechanisms is flexible and extensible, the ICG relies on the definition of IaC templates that are used as a basis for the translation. Finally, the generated IaC can go through multiple security-related checks thanks to the IaC Scan Runner.

The DOML is currently extended in the following ways:

• Creation of new concepts. The new concepts will require the definition of a metaclassName. Extension elements exist in all the DOML layers, e.g., the Application Layer includes the class ExtApplicationComponent that incorporates into the Application Layer a new type of ApplicationComponent [9].
• Definition of new properties. The set of properties and attributes associated to one particular DOML concept can be extended to further increase its expressiveness.
• Usage of the Source concept. This class allows to incorporate external IaC (e.g., an Ansible playbook) to configure a software application in a DOML model, by specifying an entry point, a backend, and, if necessary, a custom inventory.
• Usage of the GenericResource concept. Missing concepts at the concrete infrastructure layer can be modelled through the usage of such class. Mainly, this should be used to model preexisting resources which need to be defined as part of the concrete infrastructure.

The extensibility of the DOML is depending on the DOML-E mechanisms defined. The effectiveness of these mechanisms has to be studied in close connection with the possibility to define in the ICG new IaC templates and modify the existing ones as otherwise any addition into the DOML would not have an impact on the generated IaC code.

During the development of one of the PIACERE use cases (UC2), we have tested the combined extension of the DOML and the ICG by introducing a new kind of software component at the application layer. This process has involved the usage of DOML properties to model the parameters needed to correctly configure such software component, and the addition of a new Ansible template to the ICG.

An important future development concerns the analysis of the role of DOML models with respect to the usage of AI to automatically derive IaC. Recently, projects aiming at generating infrastructural code from natural language are under development [10]. Clearly, such approaches have a significant potential in terms of reducing the time and effort needed to develop IaC.

In this context, the availability of DOML models providing a precise description of the application and infrastructural elements, together with their expected mapping, could potentially help in ensuring that the low-level code generated by the AI is correct and complete.

References

[1]	B. Xiang, E. Di Nitto and G. Novakova Nedeltcheva, “Deliverable 3.2: PIACERE Abstractions, DOML and DOML-E – v2,” PIACERE Consortium, 2022.
[2]	Sergio Canzoneri, Elisabetta Di Nitto, D3.3 PIACERE Abstractions, DOML and DOML-E – v3, PIACERE consortium.
[3]	M. Chiari, B. Xiang, G. Novakova Nedeltcheva, E. Di Nitto, L. Blasi, D. Benedetto and L. Niculut, “DOML: A New Modelling Approach To Infrastructure-as-Code,” in CAISE 2023, Zaragoza, 2023.
[4]	E. Morganti, “Deliverable 2.2 v 1.1 PIACERE DevSecOps Framework Requirements specification, architecture and integration strategy – v2,” PIACERE Consortium, 2023.
[5]	E. Villanueva, “Deliverable 3.7: PIACERE IDE – v3,” PIACERE Consortium, 2023.
[6]	Eclipse Foundation, “Eclipse Modeling Framework,” [Online]. Available: https://www.eclipse.org/modeling/emf/.
[7]	Eclipse Foundation, Inc., “Eclipse Xtext™,” [Online]. Available: https://www.eclipse.org/Xtext/.
[8]	D. Benedetto and L. Nicolut, “Deliverable D3.6: Infrastructural code generation – v3,” PIACERE Consortium, 2023.
[9]	PIACERE team, “PIACERE DOML Specification v 3.0.,” https://www.piacere-doml.deib.polimi.it/, October 2022.
[10]	Firefly, “Artificial Intelligence Infrastructure-as-Code Generator,” Firefly, 2023. [Online]. Available: https://aiac.dev/.

 

The blog post is written by Sergio Canzoneri, Elisabetta Di Nitto, and Galia Novakova Nedeltcheva