DevOps Is Free? Sure I’ll Support It

One of the biggest misnomers about DevOps is that since it’s all about process and communications there aren’t any costs associated with adoption. Sure, you can probably gain some improvement by simply modifying your current methods for delivering IT services in your organization, however, DevOps is about more than just modest improvements.

Let’s explore why organizations that are succeeding with DevOps are succeeding over traditional IT approaches. From the article, “Fresh Stats Comparing Traditional IT and DevOps-Oriented Productivity,” also on, we see that DevOps is driving down time spent on tasks where there is no value being added to the business, such as support, deploying changes, communication and firefighting. Time spent on these tasks reduce opportunities from innovation and responding to business needs, leading the business to view IT in an unfavorable manner unable to help them meet current business demands.

Where DevOps-oriented teams do spend time is on automating repetitive tasks so that they don’t continually consume time, self-improvement and innovation. Instead of treating IT like assembly line workers capable of only completing the task at their station, which causes friction and increases turnover, DevOps-oriented organizations foster an environment where workers are rewarded for ensuring quality and reducing overhead.


So, where are the costs associated with becoming a DevOps-oriented organization?

  • Training / Education – DevOps transformational activities takes funds and requires outside training and, possibly, consulting. For businesses that desire to move forward but are stuck in the Catch-22 that is keeping the bus rolling while trying to paint it, it can be daunting to make the necessary changes. Getting past this point often requires groups trained in helping businesses make these types of transformations.
  • Tooling – There’s some great Open Source tools that can help drive continuous integration, automation and orchestration. However, the worst thing that can happen is that getting these tools to work the way you need them to ends up consuming resources and time that you’re trying to give back to driving business value. The supported versions of these tools will provide software support and deliver tested versions, which will minimize unnecessary disruptions.
  • Updates / Refresh – Older versions of some infrastructure components or software packages may not support automation efforts. Since this is a key element of DevOps, it may be a requirement to do a technical refresh or software update.
  • Platform Changes – Alas, the big kahuna, the platform change may be a necessary action to enable your IT team to become more agile and alleviate some operational challenges. The cloud is a perfect example of a platform change that supports DevOps. A platform change can be very expensive, but the long-term benefits need to be weighed; especially if it speeds transformation of your IT team into one that is agile and more quickly addressing the needs of the business.

So, can you do DevOps without any financial outlay? Probably so, but the benefit received will be nominal, your team will most likely feel shorted and look to work for a business that has fully committed to a DevOps approach and the real time consuming sinks in your business will continue to exist eating your IT budget like a bear eating salmon in preparation for winter hibernation.

About the author  ⁄ JP Morgenthal

JP Morgenthal

JP Morgenthal is an internationally renowned thought leader in the areas of IT transformation, modernization, and cloud computing. JP has served in executive roles within major software companies and technology startups. Areas of expertise include strategy, architecture, application development, infrastructure and operations, cloud computing, DevOps, and integration. He routinely advices C-level executives on the best ways to use technology to derive business value. JP is a published author with four trade publications. Hist most recent is “Cloud Computing: Assessing the Risks”. JP hold both a Masters and Bachelors of Science in Computer Science from Hofstra University.

  • David

    “DevOps is driving down time spent on tasks where there is no value being added to the business, such as support, deploying changes, communication and firefighting.”

    This doesn’t make any sense to me. How can you conclude that those activities have no value to the business? Deploying changes doesn’t add value? Firefighting problems in the production environment adds no value? What am I missing here?

    • JP

      As a whole these are zero sum targets. That is they may be necessary to run the business, but they are a factor of decisions made due to industry maturity, poor coding, inconsistent change management processes, bad management, etc., but they don’t advance the business. If these workloads could be migrated to SaaS and provide the same or greater value for the same costs or less, the business would be well-advised to engage in these migrations. Hence, it behooves the business to invest in opportunities to minimize these costs to as close to $0 as possible.

      Thanks for the question!

  • Mike


    You hit the nail on the head with the platform change. I just spent 3 days at a workshop with a large client and one of their biggest discoveries from the work shop is that they need major investments in their platform to enable DevOps to be agile. Put another way, the biggest “waste in the system” is a lack of APIs/services from their young internal cloud.

  • George

    Thank you for a very informative article about the cost of DevOps implementation. Do you have any information, data or opinion on the percentage or ratio of the DevOps cost against the cost of actual development?

    Warm regards,

    • JP Morgenthal


      Since DevOps is not a standardized method, it would be near impossible to put any type of metric against implementation. That’s why the article presents areas for examination with regard to adopting DevOps in your organization. That said, a business that wants to increase quality across the design-to-operate process should consider that they will probably want tools that are designed to support the DevOps approach and training for those tools. Of course, those tools may also force a platform change in order to be of benefit. These are the areas that I would expect to be a greater percentage of costs for adoption.