On 11th April 2022 Yvonne Wassenaar wrote a letter to its employees (An Open Letter from the CEO of Puppet: Puppet + Perforce). Puppet is joining the Perforce Software. It’s an acquisition at the end of the day. I am not here to judge if it is good or bad. Only the future will tell us about it. I have seen some successful acquisitions in my career. So, I am hopeful that this too will result in growth for its people and customers.
Puppet is and has been a great pioneering scripting technology for Infrastructure deployment. We are not going to its technical capability, but it is an important component in DevOps toolset. Just like any other good scripting Puppet was not enough to build the whole DevOps. It needed other parts as well.
A couple of years ago we were building an Azure landing Zone for a large-scale deployment of applications. In those times we did not have the concept or the guidance like Well Architected Framework. However, we knew what we needed. Just that we had to build everything from scratch. Like any other project it was important for us to identify the tools. This was purely with the DevOps philosophy. Hence, we needed automation and auto-pilot. We are in a large meeting room talking to key decision-making people. As this was a multi-year project, we had to take a call on our choices of tools. Compatibility, Capability & Cloud --- with these 3Cs we intend to build a Landing Zone for Azure. Other clouds were not in the design consideration back then. Our choice was Azure PowerShell because it was more native and very close to the REST API exposed for Azure resources. The gap between Azure REST API vs others was immense. Azure CLI was new back then. Currently I like Azure CLI more than Azure PowerShell. Because of its simplicity and uniformity. But Azure PowerShell is what we voted for. In the room there was a person who then was big fan of Puppet and has done significant work for other Cloud. He was insisting on using Puppet for Infrastructure development. Remember Azure Terraform was not there then. But we resisted. We resisted so hard, that for the first time I was very insisting on Azure PowerShell with a lot more strong opinion. I challenged the table to pick up a use case and implement it in both. I will do it in PowerShell and other person would do it in Puppet. After two days I was ready with my solution, but Puppet had some limitations. Eventually we decided to use Azure PowerShell.
There are multiple layers of learnings out of that exercise. One, there could be the best furniture in the shop. But we will choose what fits our home. Second, a home is not just about furniture, it’s also about the people who live there and how they want to live. Coming back to Donovan’s famous definition of DevOps where he says,
“DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.”
You may buy a Porche, but you can’t drive it in rugged terrain. You need a four-wheel drive. Same with DevOps. You have choices to make which suit your current needs and future expansion. No one plans for decades. Things will go obsolete in a few years. I can name a dozen such technologies which came with a lot of promises but could not survive. So, if someone would have taken a selection on them, they had to go through a painful process of migration. Trust me, they are not easy migrations. It’s not just a version change of the same product but a whole new set of functionalities. You must work from the ground up. It is like going to play football with all the exercises you have done in swimming. Doesn’t match.
In DevOps today people look for a complete solution. Not just the best Lego pieces to fit together. They want to use something which provides end to end options. You may bring third party solutions, but they are limited. If you are deploying something select a native solution unless you can make sure the other solution would have all the required features.
Top comments (1)
No need to use glued tools, use Brainboard brainboard.co/