Modern IT topics such as DevOps, container management, and the hybrid cloud require IT automation as a basis. Interfaces between IT and development teams are particularly crucial when it comes to delivering optimized applications, which calls for a state-of-the-art automation strategy that aligns communication and collaboration across these interfaces. Of importance, however, is the degree of IT automation: In typical companies, you can find automation silos in the classic infrastructure and application management areas, which means that host, storage, network infrastructure, firewall, compliance, databases, hypervisors, and applications are often managed separately.

Naturally, different automation approaches exist, usually comprising a collection of scripts, server management tools, configuration management software, application release management platforms, monitoring, batch job scheduling software, and cloud automation solutions. In the past, when software releases only took place once a year and all applications had their permanent place, this approach could work very well.

The DevOps Catalyst

With the advent of DevOps and its continuous release pipeline, the individual automation silos are often overloaded because fast release cycles require too much coordination. The constant movement of applications from the development to the test and production environment is difficult, as well. In a hybrid environment, you rub against the additional complexity of coordinating different server, storage, and network platforms in the data center and in the cloud. For example, it often makes sense to set up development environments in the public cloud, but then operate the production environment in your own data center. DevOps, therefore, needs a new automation approach.

The user is ultimately not interested in why their application displays errors or responds too slowly to mouse clicks, so a new automation approach must always be aligned with the application. Therefore, the IT department needs a new level of abstraction to describe the application requirements. Instead of infrastructure-specific requirements, this description contains a kind of "tendering" of application requirements that includes not only hardware requirements, but also dependencies with regard to specific libraries and middleware.

It is important to remember that a container is only an infrastructure that provides the necessary run-time resources faster and more efficiently for specific applications than VM-based environments could. The new application-centric automation approach must therefore be able to provide applications on bare metal, on VMs, or in containers in equal measure and must also be open to future innovations, such as edge computing as part of the Internet of Things (IoT).

Silos Broken Down by APIs

The application-centric approach just explained requires a centralized automation strategy that aims to break down automation silos. This scenario need not necessarily lead to the replacement of existing scripts or software, but starts with each infrastructure team being encouraged to make its resources available via REST APIs. In this way, servers, storage, networks, hypervisors, operating systems, and middleware can be provisioned and managed through simple API calls. Commercial automation platforms often already offer this, whereas script-based automation either needs to be adapted or replaced. Automation platforms in which legacy scripts can be integrated are also interesting in this context, because it allows a gradual transition to central automation.

Now that the silos are providing their resources through APIs, the IT department needs an automation platform that passes the application requirements to these APIs. This platform must then set priorities on the basis of cost and compliance requirements. For example, a noncritical application should optimally still be able to consume infrastructure resources as long as this consumption does not compete with a higher priority application. Data center and cloud resources are thus simply seen as infrastructure resources with different performance, compliance, and cost parameters.

Compliance must always be considered and included in automation to ensure that new application environments fully comply with compliance rules. This situation only works if IT and developers are permanently responsible for these rules in their own area of responsibility. For example, the storage team must define when data may be stored where and whether it must be encrypted, whereas the networkers are responsible for the rules for encrypting data in transit. At any time, the automation platform should provide role-related compliance reports and offer possibilities to correct compliance problems semi- or fully automatically.

Planning an Automation Strategy

DevOps describes the interaction between IT and development to find an optimal compromise between agility (short release cycle) and optimal operation of the software for a specific enterprise. Instead of large releases, DevOps continuously delivers new features to the end user. Therefore, the selected automation products must integrate seamlessly into the DevOps pipeline (i.e., cooperate with standard DevOps tools such as Jenkins or HashiCorp Atlas) because DevOps tools monitor the continuous delivery of the code, but the process itself would take too long without automating the infrastructure and the code release.

Automation has grown organically to the present day, which is why companies are confronted with a mixture of tools and scripts that cannot be easily, quickly, and cost effectively replaced by a central, application-centric automation platform. This situation is the main reason why IT automation still takes place in silos today. In the past, automation solutions such as Puppet, Chef, SaltStack, and Ansible were difficult to install and time consuming to implement (see the "IT Automation Tools and Methods" boxout). However, all four companies have largely solved this problem today and now enable the customer to automate IT processes in a simplified and gradual manner. Often a solid proof of concept for a specific problem can be achieved within a few days with the open source version of the individual offers. The commercial versions of the respective tools then offer further possibilities, which transfer the tested automation into a scalable production environment.

When planning an IT automation strategy, it is important to understand that infrastructure technologies must be interchangeable to prevent the emergence of new silos. A few years ago, for example, OpenStack was all the rage. Today OpenStack is being replaced by Docker containers. Possibly serverless computing or another technology will soon take the lead. Therefore, it is important that the IT automation strategy aims to remain independent of specific technologies and ideally relies on a community that offers continuous API integration with new products and platforms.