Skip navigation
Establishing DevOps-Friendly Infrastructure Orchestration

Establishing DevOps-Friendly Infrastructure Orchestration

IT organizations face increasing pressure to move faster to support business initiatives, writes Alex Henthorn-Iwane of QualiSystems. How can they leverage infrastructure orchestration to support DevOps initiatives in a sustainable fashion?

Alex Henthorn-Iwane is the Vice President of Marketing at QualiSystems.

Orchestration and DevOps are buzzwords often heard these days, yet they have serious meaning for IT and data center professionals. The intersection between orchestration and DevOps indicates a major shift in how data center infrastructure is expected to be deployed and utilized to achieve line-of-business goals. IT organizations face increasing pressure to move faster to support business initiatives. How can they leverage infrastructure orchestration to support DevOps initiatives in a sustainable fashion?

Infrastructure That Supports DevOps

DevOps is a culture of collaboration between developers and IT operations. Its lean manufacturing roots often explain the software’s progression from development to production deployment as analogous to the journey from raw materials to finished goods on factory floors. There are other teams that must work on the software ‘goods’ before they hit production, including QA/testing, information security, and compliance teams.

Think of infrastructure as each team’s workbench, which can either enable or hinder productivity, quality and velocity. If infrastructure provisioning to developers and other teams lags, then this is obviously a problem for velocity and productivity. According to Enterprise Management Associates’ (EMA) 2014 study on the software defined data center, 47 percent of enterprise IT teams take from one week to over a month to provide infrastructure resources to developers and testers.

Infrastructure is supposed to support DevOps by becoming an Infrastructure-as-a-Service (IaaS) “cloud,” defined as follows:

An IaaS cloud allows efficient self-service access to infrastructure resources that can be assembled into production-like working environments and automatically provisioned.

Orchestration is the software-based process to create IaaS clouds. If collaboration is the goal of DevOps, then infrastructure orchestration must enable the IaaS with the characteristics below.

Flexible Self-Service Model

Each team has different roles and needs in the pipeline from Dev to Ops. Developers are innovators who create new code and model an accompanying infrastructure environment that is best suited for running that code. For today’s complex, distributed applications, that means creating an infrastructure topology of multiple VMs and other infrastructure resources in a dynamic sandbox. Once developers finish their work, QA testers run functional and performance tests against any permutations of the infrastructure existing in the production environments. Information security personnel need to ensure sound interactions with other infrastructure components such as firewalls; compliance teams must run their own tests based on applicable regulatory frameworks such as HIPAA or PCI.

DevOps-friendly orchestration must offer infrastructure self-service needs that are looser and more sandbox-like at the development stage where innovation happens, and progressively tighter, more standardized and catalog-driven self-service for teams working in the later stages. Empowered by this orchestration capability, the IT group can collaborate with the developers innovating new infrastructure topologies to adapt them into standardized environments that other teams operate on in later stages.

GUI and API-Enablement

Unlike Web companies, most enterprise IT infrastructure teams are staffed primarily with vendor-trained domain experts, most of whom can do some scripting, but aren’t professional software engineers. Ultimately the goal is to create continuous automated processes. This means that orchestration should support both GUI and API-driven ways to create infrastructure environments and the underlying automation workflows.

Handling Physical and Virtual Infrastructure

DevOps was first practiced by hyperscale and Web companies with the luxury of totally modern, virtualized or public cloud infrastructure, making it relatively easy to adopt a code-centric approach to infrastructure. Many enterprises, however, have a mix of legacy, physical, and virtual infrastructure, meaning that the concept of infrastructure clouds can’t assume that everything is already virtualized.

The EMA study referenced above revealed 89 percent of enterprise IT teams still run applications on dedicated, non-virtualized servers. Networking is also primarily non-virtualized today, and despite the SDN hype, this will be the reality for a while. Many of these non-virtualized systems and networks have remarkable staying power, are mission critical and touch many applications. It’s reasonable to start with the easiest infrastructure and less critical applications when trying to practice DevOps, but if the plan ignores physical realities, the initiative may stall when investment plans weren’t sufficiently thought out.

One banking IT infrastructure team invested in an orchestration product assuming that virtualization was enough, then discovered that users needed access to physical resources. That orchestration investment fell apart after a year of consulting services were spent trying to Band-Aid over the gap and they had to admit defeat. It’s beneficial to determine where your infrastructure cloud roadmap is going to lead you in what timeframe. If you believe that your non-virtualized resources will be upgraded and migrated before needing servicing, then your orchestration job is easier. Otherwise, you need orchestration that bridges the physical and virtual resource gap.

Pre-Deploy vs Deploy Use Cases

When developers, testers, InfoSec and compliance teams are working, the infrastructure resources use case is fundamentally different than when applications or services are deployed. DevOps-friendly orchestration needs to support both use cases. Orchestration for the deployment-stage focuses on ensuring infrastructure resources are available to support application up-time and performance. Production orchestration typically provides pools of resources dedicated to particular applications or services, or shared between different applications with a policy for prioritizing allocation when conflict occurs.

In the pre-deployment stages, the focus is team productivity, to enable many users contending for infrastructure resources from a shared pool. Developers and testers need to use resources for relatively short periods then release them after they’ve done a particular task. Orchestration therefore must support rapid assembly and disassembly of environments from a shared infrastructure resource pool, based on ad-hoc requests by users generally considered equal in priority. The orchestration goal is to manage resources, allocation conflicts and utilization to enable maximum user productivity.

Properly done, infrastructure orchestration can be the tool and process that IT uses to provide a collaborative platform for developers, testers, InfoSec, compliance and Ops teams to drive high performance, high quality software outcomes. Consideration of varying requirements around self-service models, GUI vs. API-enablement, physical vs. virtual infrastructure, and pre-deploy vs. deploy use cases can ensure that orchestration will help IT and data center professionals play a constructive role in creating DevOps culture.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.