In the IT industry, “the future is hybrid” is one of the few declarations that draws nearly-unanimous support. Research, including an InsightaaS survey of Canadian businesses showing that companies of all sizes are expanding the number of platforms that they use and their connections between on-premise and cloud environments, demonstrates the trend towards hybrid at a macro level. The explosion of interest in DevOps and bi-modal IT pulls IT into new organizational models that often revolve around hybrid operations. The popularity of containers (such as Docker and Kubernetes) and configuration management tools (like Chef, Puppet, Ansible and Salt) highlights the need for effective automation to support expanding hybrid IT environments. And the thousands of individual IT leaders seeking ways of melding existing (conventional) and new (cloud-based) systems into a single, integrated environment provide extensive real-world evidence of hybrid as a critical technology management issue.
Despite this broad, intense focus, in most organizations, true hybrid operations are still a future intention rather than an endpoint on a current strategy roadmap. If the hybrid imperative is so clear, why is the route to hybrid still so opaque? An important part of the answer is contained in the breadth of inputs reflected above – the collision of diverse platform technologies, evolving management models, different types of automation tools, and constraints on IT leaders’ time, knowledge and focus. With so many different paths leading to the hybrid future, the destination seems straightforward – but the blueprint needed to assemble the various components into a workable whole is complex.
Runner, a new service from CenturyLink, illustrates how framework technologies will be used to configure the hybrid future. Runner is described by Chris Kent, senior lead product manager at CenturyLink Cloud, as a “multi-cloud automation and orchestration engine… that enables users to quickly manage, provision and deploy infrastructure across their environments.” This is a useful way of positioning Runner, but it doesn’t really explain how this type of service addresses the diverse requirements associated with hybrid IT configuration and management. Providing effective support for hybrid is a multi-layered problem – and Runner operates within and across these different layers.
Runner starts with the DevOps professional responsible for building, deploying and managing next-generation hybrid environments – and the current-generation on-premise and cloud infrastructure that is integrated within these hybrid environments. Runner works with the individual’s privileges, giving a DevOps professional consolidated access and management tools that encompass (and unite) all of the discrete systems, environments and resources that they have rights for. One of the key precepts of hybrid is that it consolidates the many different IT delivery environments into a single ‘platform of record’, allowing for seamless integration of and operation across on-premise, hosted, colo, and various types of cloud (public IaaS, hosted or on-premise private cloud, etc.) deployments. Runner delivers this span of visibility and control to the DevOps professional, putting them in control of a true hybrid environment. According to Kent, further expansion of this capability is part of Runner’s development roadmap, allowing DevOps to “expose functionality outwards to the user community, providing for different ways of consuming IT resources” – the ultimate objective of hybrid initiatives.
Enhancing configuration management
The next layer in the hybrid puzzle involves the toolsets needed to build, operate and manage hybrid environments. To accomplish this, Runner provides a set of services that extend popular configuration management tools, enabling the user to assume availability of specific attributes.
Runner’s first configuration management toolset integration – with Ansible, a powerful, flexible configuration management environment – demonstrates the importance of Runner’s extensions. Ansible is a more modern offering in a technology area that was defined mainly by Chef and Puppet. Unlike Chef and Puppet (both of which were written in Ruby, and require some level of Ruby familiarity), Ansible is built in Python, which is native to Linux/Unix distributions and is understood by Unix-literate technical professionals. Analyses of Ansible[1] laud its security and performance attributes, and its capacity for enabling “finding, reusing, and sharing” content, “significantly accelerating deployment time” for routine/repeated tasks. Drawbacks of the tool include statelessness (reducing control across variances), limited support for non-Windows platforms, and little demonstrated ability to deliver corporate-grade support for workloads and users.
Runner capitalizes on the strengths that Ansible (and in time, other tools as well) offers, and addresses drawbacks associated with specific toolsets through its native capabilities. For example, reuse of code is an essential aspect of Runner’s value to users, making Ansible, which is known for this type of reuse and sharing, a natural partner. At the same time, though, Runner offers attributes that are not native to Ansible – for example, it is state-based, which offers greater predictability to the developer – and it delivers important tool-independent services.
One of these facilities is push/pull capability. Many configuration tools use one approach or the other; Ansible, for instance, is push-based. In Kent’s experience, though, while “there are areas where [push] is extremely valuable, during our beta, part of the feedback that we received was that customers in private cloud or private data centres don’t want anything reaching into their environment – they want to be able to reach out and grad the work…not everyone wants stuff being pushed in.” Companies with hybrid infrastructure that includes on-premise or colo-based systems have need of Runner’s ability to support a ‘pull’ communication model.
Another important Runner capability is idempotence, or the attribute of returning the same value each time an operation is run. Because it is idempotent, Runner can support massively parallel and/or highly heterogeneous environments – another important consideration in hybrid strategies.
Delivering on management objectives
With its DevOps-centric approach and platform and toolset agnostic technology, Runner can address the technical layers of the hybrid configuration requirement. Where Runner really shines, though, is in its support for management objectives, including improved efficiency and accuracy of task execution and support for experimentation with and integration of leading-edge technologies.
The notion of one-click management and provisioning is central to Runner’s design. DevOps professionals can create a routine and then re-run them with a single click – or they can select jobs from the CenturyLink Cloud Marketplace and use these to automate common tasks.
The Marketplace is, according to Kent, “very important” to the Runner service strategy – “it offers a different way of interacting with the product.” The Marketplace provides a forum for CenturyLink and its partners (and in time, customers) to post reusable services. Currently, code available through the marketplace is “more geared towards provisioning;“ while the Marketplace does include some operational routines today (such as power down/power up), other operational applications, such as backup routines, are expected to build over time.
Already, though, the code available through the Marketplace can be used by customers to explore leading-edge technologies. Kent points to the ability to perform a one-click provisioning of a test environment for Docker as an example. “With a simple click of a button, a user has an environment…and they can easily interact with it, they don’t need any knowledge about that particular environment to start working within it. Containers are one of those things that are kind of in a vacuum today; if you want to set up a dev environment where you can just break stuff in an encapsulated instance, Runner is a good environment for that.” The upside, Kent believes, is that Runner broadens opportunities for cloud-native development by enabling rapid provisioning through Marketplace products.
This expanding horizon provides IT leaders to respond to the pressures of “bi-modal IT” – the term (coined by Gartner) describing the need for IT to function at two levels, providing efficient management of core systems while also supporting IT-enabled innovation. Many IT shops struggle with aligning resources against these two distinct areas of competence. But hybrid IT can be used to bridge this divide, and consequently, Runner can enable this bridge. Because Runner allows for the capture and reuse of IT processes, “we can work on Mode 1 and Mode 2” at the same time, Kent says. “We really do operate on both sides – we enable the user to be as creative as they want to be, being able to apply their practices to environment and infrastructure as needed.”
The proof in the pudding
Discussion of time-to-benefit raises an important issue. Virtually all new technologies are compelling in the abstract: the key is to demonstrate, in tangible terms, how a solution delivers value to a buyer.
Asked how CenturyLink can demonstrate payback to buyers, Kent points to a range of financial, usage-based and operational metrics. One easy-to-quantify financial metric is power savings associated with automated shut down/power up, a routine that can be accessed via the Marketplace. Firms using this service across large (physical and virtual) server environments can generate immediate electricity savings. On the usage-based side, Runner provides IT management with granular insight into which IT-delivered services are being consumed, and by whom, which demonstrates internal customer interest/usage that can in turn support resource allocation decisions.
The operational metrics, however, are where Kent sees the greatest potential. “One of the areas where Runner really excels is where infrastructure is code,” he explains. “You can deploy jobs for infrastructure management in a repeatable manner – state-based, idempotent, lessening the human error potential since everything is automated – you can schedule tasks, and address functionality requirements within the Runner product to reduce the cost of troubleshooting, and the time needed to gather needed information.” Most IT leaders would see these as desirable attributes, and would expect that they would yield savings, but few would be able to quantify the extent of the affect and cost reduction. However, with Runner, Kent notes, IT management can use a cross-platform, hybrid-native system to understand “how is this impacting people in a real-world scenario?”
Wrapping up
In the near term, the tools that IT leaders select to automate their path to hybrid will depend to a large degree on the path that they are following, or the requirement level that they are addressing. Some firms will begin with DevOps and related techniques; some will begin with configuration tools; some will begin with Containers, and some with other ways of increasing management visibility and improving time-to-benefit or payback. As the journey unfolds, though, the nature of hybrid will demand platforms that connect, integrate and extend capabilities in each of these areas – and firms that dig deeper into hybrid will be looking for solutions like Runner.
[1] See Ansible vs. Chef and Top 5 Best and Worst Attributes of Ansible, both from UpGuard.com
