Pleasing the DevOps Customer

Ajay Gulati is Co-founder and CTO of ZeroStack.

During the past few years, the relationship between the IT department and its end users has turned upside down. In the old days, IT dictated which hardware and software its ‘customers’ used; but now, those customers are dictating what they want from IT. This is particularly true of DevOps organizations: Individual developers have their own favorite tools, and they expect IT to provide them. The IT department continually scrambles to cost effectively provision hardware and software resources, while developers complain about provisioning delays and other challenges. In this article, we’ll look at how developers can get what they want in a way that actually makes the IT department more agile and cost-effective.

The DevOps/IT Divide

There is a basic disconnect between what developers want and the IT department that serves them. Essentially, developers want to be left alone to use their preferred tools and resources without intervention from the IT department, but the IT department needs to control access to those tools and resources in order to keep costs down. The most common IT operations obstacles are long procurement and provisioning cycles, lack of automation, and organizational silos.

Long Procurement and Provisioning Cycles: In many companies, the IT operations team has a lengthy procurement and provisioning cycle, and developers may have to wait several days or even a few weeks for IT operations to handle requests for development tools, network connectivity, access to servers or VMs, databases, or storage resources.

Lack of Automation: The company may be using an outdated ticketing system to communicate IT requests. Each time a developer issues a ticket request, an IT operations person must follow a certain workflow to fulfill that request, and must complete each step before sending the ticket on to the next IT operations person in the chain. These workflows often consist of time-consuming manual steps. For example, an IT administrator may spend hours manually copying database software from a file server over to the requested hardware using Command Line Interface (CLI) scripting. The administrator must then install and configure the database software and connect it to the network. All of this is costly and time-consuming.

Organizational Silos:  In large enterprises, different individuals or teams fulfill certain tasks for a Dev/Test request separately from the others. These silos turn IT procurement into a long series of handoffs. And when something goes wrong in the process, the lack of visibility from one silo to another means there’s a lot of finger-pointing and scrambling to determine the cause.

A self-service private cloud is one solution to these challenges. Such a cloud should offer a set of automated provisioning tools so developers and testers can create their own ‘sandbox’ or ‘workbench’ environments. It should include both a self-service user interface and API-driven infrastructure-as-code that lets developers create VMs and databases, access storage, set up network connections, and perform other provisioning tasks using RESTful API coding.

In essence, a self-service private cloud automates the provisioning process by letting developers and testers manage their own initial deployments and configurations. This removes many of the confusing and error-prone manual steps that IT operations people must go through to deliver the infrastructure and software stacks that developers need. It also removes the silos within the IT organization, as it puts provisioning of individual elements (VMs, databases, storage, etc.) in the hands of developers.

But  if self-service provisioning creates nightmares of users running amok in the IT department, it shouldn’t. A well-designed cloud platform gives the IT department full visibility into and control over users’ choices. For example, fully-implemented role-based access control functionality allows IT to determine who can use and provision what. Moreover, the IT department can set quotas, thresholds and alerts to inform them when CPU, network or storage usage is too high so they can adjust resources accordingly.

Here are some requirements for a self-provisioned cloud that gives developers what they want while reducing overhead in the IT department.

An Intelligent and Well-Organized User Interface

An intelligent user interface (UI) gives developers easy access to a set of common infrastructure tools (i.e., VMs, Oracle or SQL Server databases, storage, network connections) and applications. This eliminates the old ticketing-based processes where users must submit multiple tickets to IT Ops to build their physical and software stacks, allowing developers to set up their own DevOps environments on the private cloud with just a few clicks.

Ideally, a self-service UI should allow IT Ops administrators to assign resources in an organized manner. They should be able to designate business units (BUs) on the UI (i.e. "AppDevTeam1," "WebDevTeam1") based on units within the company; assign team members to BUs; and designate current projects (i.e. "AppDevProject1") on the UI according to BU. They should also be able to assign quotas to each BU (i.e. AppDevTeam1 gets 100 VMs, 25 vCPU cores, 100 GB memory, and 400 GB storage), and to each individual project (i.e. AppDevProject1 gets 10 VMs, 5 vCPU cores, 8 GB memory, and 40 GB storage).

An Application Store

A self-service private cloud should have an online "application store" that provides single-click access to common development tools and services. For example:

 The private cloud should also allow IT operations to place commonly-used applications on the self-service UI, to give developers and testers even easier access to them. For example, IT operations can make a duplicate of the production environment available on the UI for testers. They can then update the clone production environment every few months to make sure testers are using the most current and accurate duplicate.

Seamless, Two-way Cloud Migration

A self-service hybrid could should have seamless, two-way migration. This enables developers and testers who have public cloud access to easily move applications and workloads back and forth between public and private clouds.

Administrative Dashboards

A self-service private cloud solution should have a set of administrative dashboards that allow the IT team to control access to resources on the UI. These dashboards should give administrators complete visibility into which teams and team members are using which resources, and allow the IT operations team to perform administrative tasks, such as:

A Software as a Service (SaaS) Platform

A SaaS platform with portal-based access is the best venue for a self-service private cloud solution. The SaaS platform provides the flexibility to do upgrades and customization to the various features of the UI, application store, and administrative dashboards.

IT departments and DevOps users have different priorities when it comes to using IT resources, which often leads to a disconnect. The IT department wants control and efficiency, while the DevOps community wants freedom and instant access to tools and resources. A self-provisioned private cloud addresses all of these priorities, enabling IT to please its DevOps customers while reducing overhead.

Opinions expressed in the article above do not necessarily reflect the opinions of Data Center Knowledge and Informa.

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.