This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
3. - The tools of the DevOps trade: Read more in this section
Explore other sections in this guide:
It's hardly necessary to tell IT professionals involved in application deployment that their jobs are becoming more complex. Even before the advent of virtualization and cloud computing, IT pros were looking for ways to streamline deployment and reduce errors that impacted production. And over the last decade, these two new trends in IT further altered application deployment.
One solution to streamline the process was to have app developers use existing software to build a set of models or templates that describe the applications' resource and connection requirements. This strategy, which combines development and operations, was called "DevOps."
One important truth about cloud DevOps is that the 'Dev' part is likely to be more important than the 'Ops.'
DevOps models could then be used by a more sophisticated software tool to build applications in the cloud on demand; DevOps tools could also modify or remove apps, as needed. More recently, however, the cloud has altered how IT pros interpret DevOps, and that could result in more efficient application design.
Virtualization and cloud computing have helped advance the old, monolithic application-per-server model into a set of complex application systems involving multiple software components with complex workflows among them. To make such a system functional, every piece has to be deployed and connected. It's not a manual task anymore.
The evolution of IT has also stretched the limits of conventional, script-based process automation. Application systems can be deployed on fixed server resources using a simple scripting tool, like the ones provided with most operating systems. If applications are run in a flexible resource pool, managing the variables associated with matching application requirements to resources -- including the connection resources of the network that create the resource pool itself -- is too complicated.
Cloud and DevOps: Trouble defining application needs
The challenge that cloud computing poses to the vision of DevOps is that cloud resources are interdependent and three-dimensional. Applications need servers, storage and connectivity -- none of which can be provided without considering the impact of one on the other two. Traditional DevOps tools are still "procedural" in nature; they describe a linear process of committing applications to resources rather than taking an iterative or optimized approach. As a result, the cloud-oriented DevOps tools tend to deviate from scripting in favor of a mechanism that describes needs rather than processes.
In some respects this change relates more to development than operations -- a developer knows what the application needs to run. Therefore, one important truth about cloud DevOps is that the "Dev" part is likely to be more important than the "Ops." This means that if a developer's definition of an application's needs are not sufficient or correct, getting the rest of the process correct will be very difficult.
Unfortunately, there are no accepted standards for defining needs this way. IT pros disagree on whether an existing language can be used to describe application needs or if a domain-specific language must be invented. (Juju, for example, lets its models or "charms" be written in nearly anything.) The biggest impact of this disagreement is that it makes it difficult for commercial software developers to create DevOps templates for their own software because it would have to be customized for each third-party tool on the market. Thus, there are no accepted ways for commercial software needs to be described for later translation into application deployment instructions.
Users developing their own applications can pick a DevOps tool that makes sense for them, but any significant use of third-party software in a company will demand either working with multiple tools or creating internal DevOps models to describe application resource needs. Commercial DevOps software is likely to be updated more often to accommodate the various third-party apps out there; open source tools like Juju are easier for companies to modify as needed on their own.
Using DevOps for Agile application design
It's not enough for a cloud DevOps tool to be able to correctly model application resource needs; those needs will have to be communicated to the cloud management system to commit resources and alter directory contents, among other things.
A cloud stack or public cloud service that has little support for its management system interfaces will be exceptionally difficult for users to adopt on any large scale, clearing the way for DevOps to be the major force driving management interface consolidation and convergence in the cloud. If this convergence doesn't evolve quickly, then smaller cloud stacks and cloud service providers will have to customize at least one popular DevOps tool to fit their management system, which would expand the use of the more easily customized open source tools.
Because cloud DevOps shifts developers' thinking toward defining needs rather than processes, it impacts the higher-level process of software-building. Software architects working with DevOps for the cloud say that their use of DevOps makes them more aware of the impact of software structure -- or how applications are decomposed into separate components -- on deployment, which may result in more efficient application design.
DevOps not only helps reduce the impact of that cloud's complexity on near-term deployments, it can also help developers understand how to build flexible Agile applications. These kinds of applications are what the cloud of the future will need if businesses are to fully realize benefits and use cloud as the model of IT. Supporting flexible Agile applications from development to deployment is perhaps the most important mission any cloud component can play.
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.