The value proposition of PIACERE includes the provision of an extensible modelling engine. It will enable users to visually describe all networks and nodes related to the deployment and operation lifecycle of complex applications. This engine is provided through the Piacere “Integrated Development Environment” or “IDE” for short.

The IDE will help in overcoming the current difficulty of using multiple languages for various infrastructural aspects (provisioning, deployment, configuration, monitoring, etc), while relying on its DevSecOps Modelling Language (DOML), as well as on its extension mechanisms (DOML-E). PIACERE, with its IDE, should allow to model service infrastructures in an abstract manner, without the need to have its users being simultaneously fluent in several IaC languages. This environment is already undergoing development, and a first alpha prototype will shortly be presented to PIACERE’s partners.

The Piacere IDE is being built with the purpose of creating a user-friendly environment to:

• enable the creation of DOML models
• enable their verification through AVT
• the generation of the corresponding IaC through:
  • the ICG (Infrastructural Code Generator),
  • the security code inspector,
  • the security components inspector,
  • and the DOML extension mechanisms.

The IDE will also incorporate the DOML Extension Mechanisms that will enable experts in operational aspects to extend DOML in order to support account for new technological advances and future operational scenarios.

Furthermore, we can mention as a goal the possibility of gaining new insights on state-of-the-art practices regarding application optimization, so that on-premises deployment teams of Use Cases’ applications, and other future adopters of PIACERE project´s outcomes, are able to better understand and execute tasks such as deployment automation, redundant infrastructure management, software containerization, or going serverless. This should greatly increase efficiency, on these use case applications, in terms of performance, complexity, arrangement, traceability, monitorisation, integration level, chokepoint relieve, infrastructural costs, and resource consumption (both physical and digital). Read more in this previous post.

At this stage, we are exploring and benchmarking alternatives for provisioning and configuring platform-agnostic infrastructural elements in multi-cloud environments (with more than one IaaS provider), or in public clouds (with a single provider) whenever an additional control layer is desirable. We are currently not yet experimenting private cloudsdue mainly to their closed, costly, and highly customized nature.

Moreover, we have validated this approach and performed our first experiments with template-based components, including automating conversion and parsing tools for JSON and YAML infrastructural elements description formats. At this stage, credential management has shown to be the first challenge to be addressed, which is necessary for third-party provisioning in public clouds. Our next stage after these successful and consolidated experiments will be to validate this approach for software containers too.

Naturally, careful planning and documentation are of high importance to reduce and accelerate the forthcoming code implementation cycles, by anticipating problems and preventing undesired branching out source code. Regarding version control systems, it has been decided to take full advantage of Git-like tools, particularly leveraging their online collaboration and advanced branching capabilities. This will facilitate source-code development, revision and debugging, while enhancing progress visibility and easing the creation of code forks.