- Create a certificate-signed RDP shortcut via Group Policy - Fri, Aug 9 2019
- Monitor web server uptime with a PowerShell script - Tue, Aug 6 2019
- How to build a PowerShell inventory script for Windows Servers - Fri, Aug 2 2019
However, at a grass-roots level, it is so much more. DevOps is built on business culture, which is the main criterion by which you can consider your business a “DevOps shop.” Such a culture consists of tolerance of failure, open communication, willingness to help out regardless of the job, and simply working closely as a team. The actions and way of thinking of the group as a whole are what a company’s culture is born from. They are critical to DevOps success, but it seems that unfortunately, vendors and DevOps practitioners are forgetting this.
It’s hard to fully understand culture, mutual respect, mindset, and other “soft” DevOps topics. To consider a business “successful” on these points is all relative. What is seen as successful in one business may be seen entirely differently in another. However, when it comes to tools, things are rather more clear cut. We can easily appreciate the success of a configuration management tool configuring a server just like it’s supposed to, but it’s much harder to put your finger on a “good” culture. This is why much talk around DevOps has turned into a tools discussion.
Tools are tactical; they allow us to put a checkmark next to a task and feel good about ourselves. I, for one, love the various tools that have sprung up around DevOps, such as configuration management, containers, various cloud technologies, etc. These tools are important in assisting developers to write code, in letting operators deploy the code, and for enabling users to provide feedback as quickly as possible. But we must realize that tools are only a small part of what DevOps means.
They say that money can buy happiness, but happiness is a highly relative term; what makes me happy may not necessarily be what makes you happy. Simply saying that “money can buy happiness” doesn't make any sense. The same can be said for DevOps, but companies are attempting to do just that; putting a price on something that can’t be bought. Companies are hiring DevOps engineers and purchasing tools because they want to see the real benefit that DevOps is known for; a collaborative environment that yields better software services for businesses. Since a financial transaction is a cut and dried operation, it’s easy to buy a software product and get it installed. Once the tool is implemented, and a company sees some immediate benefit, they consider themselves a “DevOps shop.” What they don’t realize is that unless the culture and mindset of the organization change first, the tool will simply adhere to the company’s current modus operandi rather than implementing a transformative DevOps change.
Incisive software companies, such as Chef, “get” DevOps. They realize that it is not just about the tools. Ask anyone at the company and they will tell you this. Chef is a company that needs to make money and sell software but, at the same time, they attempt to guide their users into a more DevOps-oriented mentality. They realize that unless the company that purchases their software recognizes the culture and other “soft” aspects of DevOps, their tool will simply be treated as another piece of software that IT has to manage, not as an instigator of a much bigger cultural shift. If the cultural prerequisite has been met ahead of time, a business like Chef can get much greater benefits from their tool, which equals more money for the company. It’s a win-win for both parties.
DevOps is not just about tools. If there is a running joke in your company about how the software developers hate operations and vice versa, yet you are providing servers with Docker, managing your infrastructure as code, and using Jenkins, you’re probably not using DevOps. Even though companies can do DevOps differently, there are a few key components that need to be met to consider yourself a DevOps shop. For a breakdown, I recommend checking out Adam Jacobs’ talk on DevOps Kung Fu.
Subscribe to 4sysops newsletter!
Unless these components are there, it’s like you're putting fancy wheels and a big stereo system in a $500 car. Regardless of the bling that gets added, it will still billow smoke, break down on you, and leave you on the side of the road. There is no brilliant paint job in the world that can fix a 500,000 mile, $500 car. Don’t expect buying a tool to use DevOps to be any different.