DevOps, the word, is an umbrella term that describes the ever-growing set of practices to enable applications to change and evolve gracefully, as if they are built for change. DevOps, the movement to transform to these practices, is a convergence of engineering know-how, specialty tools (that fundamentally change the way software is assembled and deployed), and of the acceleration afforded from the Internet to connect developers to open-source components, platforms, tools, and most-importantly to other developers and a world of know-how. This blog will describe a very high-level, nutshell view of what I think are the essentials for understanding why DevOps is important and how it works.
The first essential to remember as context for everything else, is that DevOps is the application of architecture principles, patterns and conventions to the business of developing, integrating, verifying, and deploying software and infrastructure. In effect, the ability to economically and efficiently change software and systems can be done much easier than ever before because of we have learned to apply our collective experience to create and use tools to drive the development (or testing, provisioning, deployment) process much more efficiently.
DevOps is directly accessible to everyone because of architecture capabilities built into open-source tools, such as task managers and component (package) repositories, that address historically thorny problems.
These tools, effectively, divide and conquer the complexity of development into packaged tool solutions that provide coordinated capabilities out-of-the-box.
|The DevOps buzz—Why pay attention?|
This agile potential, to be leveraged, comes at the cost of managing more components. This is where automation tools incorporated by DevOps rise in importance. To leverage better architecture capabilities, you necessarily require more automation, but the overhead to manage more frequent release cadences is less awkward and can be released with higher confidence that things will work. However, because DevOps is an architecture turned towards the business of building and deploying high-quality systems, the scope of a DevOps implementation is similar to any other system and determined by priorities and decisions. Be aware of DevOps feature backlog items that may not be in place yet and spot-check these gaps.
|Is DevOps Really New?|
Engineering, architecture and automation have been around for decades. DevOps is the result of turning these tools towards the business of development and the results have congealed into something entirely new.
DevOps is new, especially in the enterprise IT landscape. It brings together highly evolved software engineering best practices, with the high availability of open source tools that incorporate those best practices, and supports all this with access to expertise (via connected developers and thought leaders in blogs, chat rooms, code repositories, YouTube channels, wikis, etc.). The tools themselves are almost always open, with plug-in architectures that allow them to be adapted cleanly to a wide range of uses. The low-barrier to world-class tools, combined with the expert insight, tutorials, documentation, and community support creates a potential to build world-class software on every developer’s desktop.
In addition, the disrupting vision of how open source software can improve the state of development and applications, is another fundamental driver behind why and how DevOps is something new and more powerful. Everything has been developed with an eye for extensibility and for as wide a base of users as can be imagined.
|How DevOps Works|
This is a nutshell depiction of the DevOps process.
On the left, developers and development teams work on changes in parallel in short, iterative sprints and eventually submit their changes for integration into a common integration branch in the code base. It is this insistence that only worthwhile, vetted changes are allowed that drives the ability and capability to address higher-order build-deploy-operate functions and objectives.
The output in this case may be the deployment of code to a running server (which is a very simple case). Often, to make better use of resources and drive other efficiencies, build processes may deploy the build output to a “package repository” for later deployment. There are best practices and emerging tools to automate models to do this. In addition, there is also a maturing set of tools and platforms for automating the release and management of components in a runtime environment.
Bringing DevOps to the Enterprise
Now that we have the basic mechanisms defined, the challenge for most companies is how to introduce DevOps across its portfolio of applications. I’ll address why this is a challenge and how to approach this in a subsequent post.