Nearly every vendor I talk to has some form of open source and code sharing mechanism in place. The most popular method is to use GitHub as the sharing tool. IT has changed. In the past, IT was about the UI. Now, IT is about sharing code as well as ideas. This is specifically true of automation and orchestration tools. It is a share-and-share-alike marketplace. Those who share code tend to do very well, while those who do not end up on the sidelines. However, what to share becomes increasingly difficult to judge. If you share too much, as a vendor, you give everything away. If you share too little—well, you soon may not have any customers. So, what is the proper level of sharing?
As we continue down the path to the cloud, it is becoming harder and harder to have just one tool to do everything. As we enter the multicloud, one tool is never enough. Nor is one dashboard enough. There is a need for automation and orchestration around the deployment, monitoring, updating, fixing, and eventually takedown of software and services. How does one do this? The more you have to do yourself, the more there is a repository that contains either exactly what you need, a template for making what you need, or code that provides insights into creating what you need.
One of the key things we talk about within our research is the need for automation and orchestration. This is about not just what the vendor supplies but also what can be done using third-party tools. We generally want to know whether the tool automates itself using its own APIs or private APIs. We also wish to know which third-party tools, such as Puppet, Chef, and the like, can be used to do automation. We are looking not just at configuration management, either, but at the act of meeting our needs to deploy, monitor, update, or even fix the software. In reality, we are looking at how to use a tool after it is installed, on what we call “day two” and afterward.
The sharing of code—even examples—is at odds with the vendors’ primary goal of selling their products and making money. Much of that money is made during consulting engagements. As such, knowing what to share, as well as how to share it, is crucial. Some vendors, such as Intel, share the binary code for their software. Others share scripts. Yet, the IT market is crying for more and more free tools and products. “XYZ should be free” is a common lament. My response is that it should not be free, but that part of it should be easily usable and readily modifiable to meet my specific needs. The vendor may not know how we intend to use its tools.
The need to automate and orchestrate has given rise to DevOps and tools that hopefully make that simpler. This depends on your team more than anything. Good administrators have been automating and orchestrating for years; we just never called it that. This was how tools like Puppet, Chef, and others took off. We all need to tweak something to be unique to our environments. This brings us back to the need to share and share alike, and to be free with examples to show how to use vendor software best with third-party automation and orchestration tools. I would go so far as to say that any that have an open-source component are good candidates.
This is a repository, or donation to a repository, that should continue to grow—not shrink. As more use cases are developed, the code that is shared should also change. We are looking at a world in which examples drive our automation efforts. Reading manuals seems to be out, so good code, with comments, is a great way to share ideas, workflows, even use cases. This preserves the fundamental requirements of a business: to make money, and to do so while serving the community. Sharing code and examples is one way to grow a community around a product, to raise interest, and to ensure that your products have a future in the modern multicloud.
As a vendor, where are you on example sharing? As an end user, how do you decide what products to use? Do you do your homework to ensure there are adequate examples for present or future customization, automation, and orchestration? The best place to start is probably GitHub.