Choosing the right DevOps tools should be a careful, thoughtful process.
On May 12, 1848, a store owner named Sam Brannan held a “one-man parade” to announce the start of the San Francisco Gold Rush. “Gold! Gold from the American River!” Brannan shouted up and down the market street in San Francisco. He held his hat in one hand and waved a bottle of gold dust in the other. San Franciscans had received false news of gold before. But by all accounts, Brannan’s performance sent residents running in search of riches.
Brannan had a good reason for spreading the news rather than panning for gold himself. The canny entrepreneur owned a general store that served the workers, and in the week between learning about the discovery and yelling about it in San Francisco, he’d bought all the picks and shovels in the city. Brannan’s announcement helped spur a seminal event in California’s history. As Brannan raked in money selling mining supplies, his actions also, years later, led to the coining of a famous maxim. (source)
During a Gold Rush, Sell Shovels
In the current age of DevOps and Agile rush of enterprises, there is a lesson to be learned from the gold rush: Don’t let your DevOps transformation become a parade of tools. While automation is critical for the success of modern ways of technology delivery and operations, the wide range of tooling choices can often lead to wrong decisions—especially well-intentioned, top down purchase of tools, duplication in toolsets and, most importantly, ignoring the voice of the teams on the ground.
With such variety of tools available in the market today, we all have opinions regarding the tools that we would like to use. Our preferences are based on either our history of using certain tools, because we have invested time and effort to learn a tool, or partnerships your service vendors might have with tooling vendors.
This leads to two general attitudes toward tooling adoption, with each having their own advantages and disadvantages:
Autonomy for teams: Let teams decide the tools they feel are suitable for their context.
The advantage is that teams can experiment and pick a tool that suits their context better. The disadvantages can, potentially, include security risks due to lack of patching and maintenance, and limited cross-team collaboration and sharing of tooling skills and know-how.
Standardized tool suite: A centralized way of dictating tooling choices.
The advantage is that it allows for capacity planning, integration between tools, larger pool of community for collaboration and create platforms-based solutions.The disadvantage is that this method at times prevents teams from using tools that best suit their unique needs and creation of avoidable dependencies on centralized tooling teams in the organization.
These contrasting views lead to debates at every level for the choice of tools and, in some cases, slowing down decision-making—or even leading to the purchase of tooling licenses without input from technical teams on the ground. The decision-making process must be improved, and the need for autonomy must be balanced with standardization and optimization. Also, the two approaches of “autonomy for teams” and “standardized tool suite” do not always have to be binary and will change depending on the context of the team needs and area.
By considering desirability, viability and feasibility of the DevOps tools, we can help achieve the balance between autonomy and alignment.
Here are some tips to help ask the right questions:
Desirability
- Do teams want this? or is this a solution chasing a problem?
- Do you anticipate that teams will need this in the near future?
- Does this help improve team productivity and effectiveness?
Viability
- Does this make commercial sense?
- Have we considered maintenance costs and total cost of ownership?
- Do we have existing license arrangements with the tooling vendors?
- Do we have comparable tools already in use and that can do the job?
- Do we need to purchase licenses throughout the enterprise?
- Are there any open source alternatives?
Feasibility
- Can we implement this in the enterprise IT landscape?
- Have we considered the ease of setup and configuration of the tool?
- Does it scale across the enterprise? Does it have to scale across the enterprise?
