Cloudify is an open tool developed by Gigaspaces, which can serve as NFVO and VNFM, and also provides the ability to orchestrate the entire cloud environment. Like Tacker, it provides a monitoring environment and the ability to automatically correct some errors.
VNF templates are called blueprints, and their format is the same as for Tacker specifications TOSCA YAML. Compared to Tacker, however, they are larger and do not split into two parts.
In one blueprint file, all parts of the application, such as such as its structure, middleware links, source codes and scripts, configurations, logs, and metrics. Blueprint can also include definitions of the individual phases of life application cycle, where for each of them can be defined specific tasks including applications, who will perform them.
All VNF lifecycle management tasks are performed with help modules written in the Python programming language. Without these modules, Cloudify can not perform any operations over the environment, so there are some modules for the most widespread services, such as OpenStack, AWS, Azure, or Docker, along with it.
For specific purposes, these base modules can be customized or replaced by their own. Of course there is the possibility to simply add any quantity of others custom modules that will extend compatibility with other systems.
Cloudify is a powerful tool for managing both the NFV architecture and the entire cloud environment. It is very flexible thanks to easily customizable modules and standardized blueprint. The disadvantage for ease of use is the fact that the basic modules are not too extensive and need to be expanded very often. Their number is also not large, so it is almost always necessary to add custom modules to cover all the components in the environment.
SaltStack, often called only Salt, is an open tool for managing configuration and remote execution. Salt was not primarily designed as an NFV infrastructure orchestration, as is the case with Tacker and Cloudify, but far more general to manage almost any system with very scalable capability. Due to this, its architecture differs significantly, as can be seen in Fig. 3.5.
Salt uses a server-agent communication model, that the server sends an action request to one or more agents who perform these actions and then the server returns their results. The server is in this case a station running a Salt-Master service that manages all the execution and configuration.
running within managed stations is called Salt-Minion. The other components of the Salt are the so-called Runners, which provide the salt-master action. Additionally, there is a Reactor, a component that monitors whether or not there are specified types of events to which an example may respond by performing certain actions, running states, or other specific behaviors. Salt can also provide an application interface that lets you control salt-master from external systems.
For communication between all the components of the Salt, a mixed event event called Event Bus is used. These events can be called a Runner action, a call to an application interface, or events for the Reactor. Jump on master / minion communication emphasizes speed and security, communication runs through a high-performance ZeroMQ message queue, encryption runs through the AES protocol, and authentication is provided with public keys.
For remote actions such as installing software packages or launching services, Salt does not need any regulatory files. These files are required in the event of configuration management when called so-called states. The status is, in the case of Salt, the sequence of certain actions and enforced the required configuration. A so-called formula is described, which prescribes these actions and requires configuration, with a syntax of language.