September 22, 2016
DevOps essentials
By: John Shiner

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? Tweet
As DevOps becomes more established, practitioners are applying a more critical analysis of what works well within each stage of automation. As it turns out, small, modular, composable architectures assembled with a mature package management and dependency management capability are easier to work with and provide more agile potential than monolithic platforms. In effect, adopting DevOps reaches into the vertical dimensions of what and how components, applications and systems are assembled.

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? Tweet
In my discussions, there is often a sentiment from somebody that DevOps is not new. It is true that embracing DevOps can seem like yet another approach to apply tools and automation to speed quality development. What is different is that DevOps is a set of tools, patterns and processes that are adaptive to a wide range of languages, tools and technology stacks. It naturally aligns with iterative, constantly adjusting, agile development processes. The underlying concepts can be viewed as principles that can be realized in a myriad of ways. DevOps works by breaking down silos and barriers between project stakeholders.

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.

Why Now?
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 Tweet
Stripping away specific tools, pipeline stages, technology stacks and so on, the enabling mechanism that allows DevOps to sustain frequent changes is the ability to have each change to a code base be serialized and verified one-at-a-time. Before being accepted into the code base, a continuous integration process analyzes, builds and packages the application with the new changes. It then runs a battery of automated tests (including tests submitted by the developer for the code changes being submitted) to verify that the code is not breaking the code base and is working as designed. The integration process monitors the output of each processing step and collects build and verification output from the various tools. If anything fails, the build process stops, notifications are sent out to whom it may concern, and the DevOps integration process (accepting and verifying changes) STOPS until the offending change is either corrected or withdrawn from the code base.

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.

Popular Tags



      COMMENTS (0)




      Your Data Privacy

      By providing your e-mail address, you agree to the terms
      outlined in our privacy statement associated with
      commenting on the site. Your e-mail address will not be
      used for promotional marketing purposes.

      Change the CAPTCHA codeSpeak the CAPTCHA code