A look inside the DevOps movement
A comprehensive collection of articles, videos and more, hand-picked by our editors
It's not uncommon for a technology to gain publicity faster than it gains implementation traction among enterprises, and that's certainly been true for cloud computing. Some enterprises claim two factors are slowing cloud adoption: difficulty in proving cloud's benefits and an inability to make cloud operations run as efficiently as data center operations. DevOps could offer at least a partial solution to both problems.
DevOps is an attempt to pass along knowledge about an application's need for resources and connectivity from the developers -- who build in those dependencies -- to the operations teams. The goal of DevOps is to describe application needs in a way that provisioning tools can read so that deployment becomes automatic. By organizing how applications are deployed, it's possible to automate the processes that monitor application health and restore functionality if a failure occurs.
Central to the DevOps concept is the ability to determine application resource needs. Depending on the specific DevOps tool, this is determined by a feature called a "template," "model," "container" or even "charm."
In a utopian world, the description of what the application needs would be written at the same time the application is built. However, because few apps have been developed with DevOps compatibility in mind, not many of them are built in this manner. Until this paradigm changes, one factor for choosing a DevOps tool is to look at how it supports the creation of application descriptions for existing, or deployed, applications.
Criteria for choosing a DevOps tool
When picking a DevOps tool, begin by examining the tools offered for the cloud stack your enterprise selects. OpenStack, for example, collects the list of active DevOps projects so users can see the capabilities and status of each package.
So, you need to know what to look for before you begin shopping. Aside from basic cloud stack compatibility, there are three criteria for choosing a DevOps tool:
- Compatibility with public cloud services. Most companies want the ability to deploy applications in hybrid cloud environments. To support this, a DevOps package needs an interface with the cloud provider's management system. In some cases users can customize these interfaces based on cloud API specifications, but that will require some development skills.
- Support for both network and IT (i.e., server, storage) resources. In many cases, modern applications will be "componentized" and distributed across multiple servers and multiple locations. The multiplicity of sites and systems, and the ability to create network connections among them, is a requirement. Simple applications that consist of one component are less difficult to organize and may not require this feature.
- Link between deployment and monitoring/management tools. You can't manage an application component if you don't know where it was installed; DevOps tools must maintain a log of where apps were placed. This log must also be able to connect management and monitoring tasks to deployed application elements.
Vendors such as Dell, IBM and Microsoft include DevOps tools in their cloud or virtualization packages. A growing number of open source DevOps projects are also underway. The most widely known and used is Juju, one of the OpenStack DevOps projects and a component of Ubuntu Linux's cloud tools. Juju enables teams to define not only application deployments but also scalability mechanisms. Juju can be used to spawn multiple instances of applications to improve performance.
Third-party providers also offer DevOps tools, some of which are linked with, or even classified as, application integration tools. Unlike most open source tools, third-party DevOps tools provide a way to create network connections among components in a deployed application or link users to an application through directory updates. Enterprises should carefully review this option; a reduction in both operations efforts and error rates may offset the cost of a commercial product.
DevOps tools are like all other tools; they must be applied in a structured operations framework by skilled professionals. Most companies that use DevOps on a large-scale report have a specific administrator who's responsible for creating and maintaining application descriptions in the appropriate DevOps form. This admin ensures that changes to cloud software or configurations can be managed by the package and descriptions.
Without this type of process, users may report that application descriptions have become obsolete or corrupted, and people may bypass the DevOps process that ensures applications deploy correctly. This erodes the benefits and credibility of DevOps and often poisons the entire DevOps concept.
In the long run, it's very unlikely any major enterprise will be able to deploy a public, private or hybrid cloud application set without DevOps. And without DevOps, it's unlikely that enterprises can manage cloud applications through the typical change-state-release lifecycle with acceptable levels of staffing. DevOps is the key to taking cloud computing from a limited test environment to production within enterprise IT.
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.