Lead Image by Alex Kotliarskyi on Unsplash

Lead Image by Alex Kotliarskyi on Unsplash

A REST API automation strategy for DevOps

IT Factory

Article from ADMIN 46/2018
Making resources available through REST APIs breaks down the automation silos that cater to the different IT and development environments and sets up an application-centric automation approach.

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.

IT Automation Tools and Methods

Infrastructure-independent DevOps. Quali CloudShell and Chef Habitat provision development, test, or production environments – for example, for the popular Jenkins continuous integration (CI) server. Jenkins CI creates a software build and transmits its deployment environment requirements to CloudShell or Habitat, which then automatically deploy the appropriate infrastructure. Depending on the policy, this can be based on bare metal, VMs, or container resources and can include testing, bug tracking, monitoring, and data virtualization. Other suppliers in this area are Puppet Enterprise, Ansible (by Red Hat), and SaltStack.

Consistent infrastructure APIs and software-defined services. Hyperconvergent systems such as Cisco HyperFlex or Dell EMC VxRail feature a central API layer through which servers, networks, storage, and hypervisors can be provisioned and managed. Cisco, Dell EMC, and VMware systems also provide granular quality of service management to prioritize application requirements. Other providers in this area are Nutanix Prism, Pivot3 Acuity, Tintri, and HPE Synergy.

Compliance as Code. Chef InSpec allows developers, compliance experts, security staff, and IT managers to codify, continuously monitor, and further develop their respective compliance rules. This process is critical to ensure that the company automatically complies with all policies regardless of the technology used – cloud, VMs, containers, bare metal, or serverless functions. Puppet Enterprise also can achieve this.

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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=