olly - Fotolia
Nearly all of the measures proposed to make IT more capital-efficient threaten to make it operationally more expensive...
The obvious solution to this problem is software automation of application lifecycles, which reduces manual intervention in deployment and redeployment, and the number of costly errors made trying to manage complex virtual environments.
One class of software tool seems ready-made to step into the software automation role: DevOps. Even in its original mission of carrying application deployment and integration from development into operations, DevOps as an implementation was a basic deployment toolkit, a step forward from basic operating system scripts. Under the influence of virtualization and the cloud, DevOps has a radically expanding scope and mission.
The configuration management process enables DevOps throughout development, test and operations. There are two models: imperative and declarative. Declarative configuration management is the clear winner, and there are reasons and market symptoms to back up that claim.
Imperative configuration management is a direct evolution of scripting; operations personnel develop deployment instructions in what is, in effect, a programming language. This approach serves well when applications are deployed in private data centers, where deployment is the main focus of concern. People expect operations specialists to handle problems with applications manually in this scenario.
The declarative configuration management model defines the end result you expect, not the steps required to attain it. As operations needs evolve from deployment alone to comprehensive application lifecycle management (APM), these new requirements are more easily addressed by a configuration management process that starts with a picture of the successfully running application. With declarative configuration management, that end result is the center of everything, because the proper operating state should be the center of everything.
Declarative configuration management software analyzes the current state of an application -- or, in theory, any cooperative IT resource and software relationship -- and the goal state, then automatically invoking steps to achieve the goal. The IT operations group doesn't have to know every possible application state and define a set of steps for each to converge on the goal. By contrast, with an imperative DevOps tool, the administrators must explicitly define every pathway from wrong states to the right one, and this can be difficult to plan and nearly impossible to get right, as deployment and redeployment become more complicated.
Given all of this logic, it's not surprising that the imperative approach is shifting to become more declarative. Chef, the premier imperative tool, has been evolving more toward modularity and adding specific support for lifecycle management. This shift has, in effect, made Chef declarative -- not so much of a goal state but of goal-seeking functions. To avoid creating massive libraries of scripts, the user modularizes the functions needed to approach the goal, from whatever starting point.
The ability to recognize events -- meaning outside conditions -- makes this configuration management process work. Declarative models also need event recognition; events are signals that something deviates from the goal state in declarative models, and they're the signal that activates scripts or goal-seeking functions in imperative configuration management programming. The notion of events, in software, is almost always linked with the notion of state, meaning the condition of the application at the moment the event occurs. State/event structures are inherently declarative, because they create a system with built-in instructions on how to respond to events. Event-handling is a validation of the declarative model.
Imperative configuration management software is making a telling accommodation of APM with a focus on continuous delivery. The weakness to declarative processes lies in how difficult it is to get changes to an application's structure reflected in the DevOps model and software. If the software takes action to secure the goal state, and if that goal state now changes because the software was changed, how long will it take for the DevOps tool to catch up? Focusing on continuous delivery aligns imperative configuration management tools with the problem most difficult to solve in the declarative approach. It's playing defense.
Defense, it's often said, only delays your loss. The declarative configuration management model has a natural advantage in several ways, and every service and APM process is driving forward based on that advantage: The goal of software automation is the simplification of lifecycle management. It's simpler to define what you want an application, data center or network service to look like and let software do the rest, working from the differences between the goal and current conditions. Simple always wins.
That doesn't mean every DevOps organization should scrap imperative approach tools. Because these tools are evolving, you can create a pretty convincing declarative model using them, and this model allows DevOps professionals to quickly adapt their tools to changes in applications, resources or connectivity. It remains to be seen how declarative tools will fare in the face of virtualization, cloud computing and hybrid applications.
Declarative tools are also evolving. Topology and Orchestration Specification for Cloud Applications, known as OASIS TOSCA, is a declarative model that evolves in an imperative direction, with support for specific recipes and the same kind of modular structure the imperative configuration management process uses.
DevOps is getting more complicated, and tools and concepts are converging, but they're converging more on a declarative vision than on the imperative. As network services and network applications like internet of things evolve, the value of a simple goal-state model will only become more obvious. However you gild the lily here, declarative has won.
Plan ahead for the IoT effect on networks
Draw up a cloud automation roadmap
How infrastructure as code works