Blog
Automation
Automation is the key to greater efficiency for many companies and organisations.
Due to the agile approaches in many IT areas and in order to meet the resulting shorter provisioning times of IT infrastructure, many IT organisations are thinking about what could be automated with reasonable effort in order to meet the growing requirements on the part of the business.
In addition to agility, it is also the costs and not least the required quality that encourage automation. Once a process has been automated, IT staff with other qualifications or, in the best case, the customer of a service himself, can also carry out this step, which ultimately has a positive effect on costs.
Conditions
In order to automate a process, it must be standardised, i.e. it must always run in the same way with as few exceptions as possible. In addition, this process must be requested and carried out frequently in order to justify the effort of automation.
Automation also requires that the IT infrastructure is virtualised in the areas of compute, storage and network. If hardware has to be purchased and installed every time an additional instance of a service is to be switched on in the data centre, automation is not possible.
Type of automation
A distinction is made between vertical and horizontal automation. This graphic shows the difference.
With horizontal automation, the processes are automated limited to the respective level. Here, as an example, the data centre network, which is automated with an "out of the box" SDN solution from a network manufacturer. Or the "Firewall & Proxy Rules" level is automated with a firewall policy management. The same applies to the "Compute & Storage" level, which is automated with the automation tools of the delivery agents of the virtualisation of compute or storage.
Only when the individual levels are sufficiently automated can vertical automation be realised in order to automatically provision instances of a multilayer service, i.e. a service that consists of services from different levels. In the case of vertical automation, this is often referred to as orchestration. Vertical automation requires that the products used to automate a layer have a "Northbound API". This is used by the vertical automation orchestrator to provision instances in the corresponding level. For example, to configure a virtual router with the associated VLANs on the "Datacenter Network" level, to which the orchestrator connects the VMs via the compute automation tool in a further step.
Architecture Automation Tools
The automation tools of one level all have approximately the same architecture. This is shown in the following graphic.
Let's start with the Northbound API, which is used to configure the services of a layer. This is done either through the GUI by a person, or directly by the vertical automation orchestrator. It is crucial here that the GUI also uses the "Northbound API", as this ensures that all GUI functions are also available to the orchestrator.
The Workflow Engine performs the various steps that make up the service. Subsequently, the "Provisioning Engine" creates the "Snipplets" necessary for configuration, which are then provisioned to the components of the infrastructure via Rest-API, Netconf or CLI. The structure and parameters of a service are recorded in the service DB, which always represents the "single source of truth".
In a model-driven automation, the configurations of the infrastructure components are periodically compared with the service database. This raises the question of how to deal with deviations. Often, only a report is created and the differences have to be corrected manually, since a direct reprovisioning from the service DB could result in an interruption of the affected service.
In addition, the service structure and parameters can be displayed directly online or as a report from the service database using the "Service Viewer" in the form of a service tree. This is an important feedback tool to check the correct functioning of the workflow and provisioning engine.
