DevOps is an approach and methodology (even a philosophy) for developing and testing new applications and deploying them into a production environment. Because DevOps is first and foremost a methodology, tools to implement DevOps should be used as a way to implement the desired methodology, rather than being an end in and of themselves.

Of course, many tools exist for automating parts of the DevOps methodology, and many are widely adopted. For example, few development teams would operate without source code control and versioning software. Yet I continue to be amazed at the number of enterprises that think that the best approach to implementing their DevOps methodology is to write some of the automation tools themselves.

The DevOps methodology is a common methodology, based on longstanding principles first espoused by W. Edwards Deming, through Six Sigma quality processes, and later popularized by “Lean” programming practices. Nothing is new in DevOps. So, what would be the advantage for an organization to implement their own DevOps tools?

We hear some common justifications for “Do It Yourself” solutions. Let’s review these justifications to see if they hold water:

• I can implement exactly the processes I want with less effort and cost.

This justification is based on some common misconceptions. For example, it is often difficult to do a good side-by-side comparison of cost between a commercial tool, an open source tool and writing the code yourself. Clearly the commercial tool has the most concrete and well established cost. When comparing to an open source tool, it is very important for enterprises to take into consideration the ongoing maintenance and upgrade costs that they will undertake themselves.

Early in 2015, Qualisystems interviewed its enterprise customers and asked them if they thought that the cost of open source tools was lower than commercial tools. They unanimously agreed that the cost was about the same from a total cost of ownership perspective. Other factors were the key influencers in whether to use an open source tool or a commercial tool. Estimating the cost of an internal development effort is even more difficult. One would have to consider the upfront development effort, and the ongoing maintenance and upkeep. A number of other intangible factors include the likelihood that the project will run over time (and therefore cost); how well the code will be understood in the future by new developers; the risk of loss of the key developers, etc.
Finally, there is the interesting question of how efficiently teams will implement their own DevOps tools if they aren’t yet already using DevOps methodologies and tools. (This is a little bit like a Catch-22).

Another hidden assumption behind this statement is that your enterprise doesn’t need all of the features provided by commercial tools, so therefore the cost to implement will be lower. Of course, most commercial and open source software has been vetted already by customers and the list of features is usually a result of extensive customer use and feedback. Often this feedback is not obvious to a new team just starting out with DevOps tools. And, then there is the fact that commercial and open source tools spread the cost of development across their entire customer base, so no one customer is bearing the cost of actual development.

• Why would we, as developers, pay other developers to write any code that we could easily write ourselves?

Well, that is like saying that since I have a driver’s license, I should be able to drive a semi-truck. Designers of software applications require specific knowledge of the problem space and solution space. This knowledge and expertise yields Intellectual Property. If we extend this concept to DevOps tools, we would conclude that creating DevOps tools also requires specific knowledge and expertise and it is different from the knowledge and expertise of most enterprise software developers.

There is also an opportunity cost to writing your own code to implement tools. That time and effort is taken away from developing applications and solutions that would directly benefit the business of the enterprise. That opportunity cost could be quite high. The simplest way to do this assessment is to ask yourself, “Is a DevOps automation tool going to add to the relevant IP of my company in a way that increases our revenue?”

• Rather than implement tools like automation that will help us to share equipment, it is cheaper and easier for me to just buy more equipment.

This argument also falls prey to the difficulties of accurately comparing the costs between automation and equipment. Purchasing more equipment to eliminate sharing will be an ongoing activity. The extra cost will be replicated every time equipment is upgraded or replaced. The extra cost will also grow linearly with the size of the software development and test teams. And, any equipment cost will be doubled by the cost of management, operations, power and cooling, etc.

Even with completely dedicated equipment, software tools will be required to properly configure that equipment to replicate different operating environments, a common requirement in testing and QA. If these software tools also implement sharing of equipment, then the overhead cost is low.

• If I write my own tools for some DevOps processes, I will be able to easily connect to any other tool of my choice through their APIs.

This is true but will also require that you maintain these plug-ins yourself over time, including staying current with API changes in third-party tools. Typically, commercial tools will carry this burden for you.

• The market is still early and there are many, many tools. Writing my tools myself will allow me to control my own destiny.

Well, it is hard to argue with fear and uncertainty. On the other hand, if the tool is just a means to an end, then switching tools should not require massive changes in process or methodology. If enterprises keep their focus on acquiring tools that match their methodology and processes, then they really can’t lose, even if they end up switching tools over time.

So, what is the answer? Perhaps there is a “best of both worlds” solution. After all, DevOps is a process and it is possible and even likely that each enterprise will want to implement that process in a way that best optimizes their own internal pipeline from development to production. Furthermore, each enterprise has its own mix of infrastructure in production and must optimize their testing to that infrastructure. Each enterprise has their own mix of legal and compliance requirements that they also must test against.

Perhaps the right answer is to provide a commercial (or open source) software solution that is more of a platform that enables easy customization (even in the form of code) to support unique process requirements, unique infrastructure, and unique testing requirements. At the same time, a common framework for implementing process orchestration, and for describing and controlling infrastructure would address the other cost issues of “do it yourself” development and make it easy to integrate in a standard way with other DevOps tools.

The time for “do it yourself” tools for DevOps is over. In the same way that no one would consider writing their own backup tool today (remember the good ole days when people did their own backups with tar files?), writing your own DevOps automation tools is usually not the best approach.

About the Author/Joan Wrabetz

Joan Wrabetz is the CTO for QualiSystems. Most recently, she was theVP and CTO for the Emerging Product Division of EMC. Joan received her MBA at the University of California, Berkley, and MSEE at Stanford, and a BSEE at Yale. She has held teaching positions at the University of St. Thomas, St. Mary’s University and the University of St. Thomas, St. Mary’s University. Joan holds patents in load balancing, distributed systems, and machine learning classification and analytics. Her experience inclues: founder and CEO of Aumni Data, CEO of Tricord Systems, Vice President and General Manager for SAN operations at StorageTek, Founder and CEO of Aggregate Computing, Management and senior technical positions at Control Data Corporation and SRI International, Partner with BlueStream Ventures.