|
This is the second part of my blog post in which I give people a little insight into the "Behind the Scenes" of bringing Virtualization EcoShell to life. Why did I do it, Why did I choose PowerGUI, etc. My goal is to give people just a little appreciation into the amount of effort it takes to bring new ideas to market (and to do it for free!).
Getting Started In getting started with this project I had to do a lot of research. While I still remembered all too well what the challenges I always had were it didn’t mean they still existed. After talking to many customers and partners I was almost disappointed in the fact that nearly every day-to-day challenge still existed and little was done to rectify that. Fortunately this allowed me to really draw upon my previous personal experiences to truly make Virtualization EcoShell a high-value product. Not only did I need to research and validate current customer pain points, I also had to research a go to market strategy that was different to the traditional model that Vizioncore was used to. I was able to leverage the collective knowledge of various coworkers inside Quest software to help me make the right decisions based on their previous successes (and failures) in similar projects in the past. Working for Quest Software has some significant advantages not available to many people out there looking to get started with new products or technologies. More than once, I was able to rely on my company in formulating a solid product strategy. The first advantage was that Quest is a large and successful company with cash in the bank. What this meant was that I wasn’t limited to developing a new product from scratch. What did this mean? Well, basically, I could look at other companies out there who were doing something similar that aligned with my goals.  I could approach them from a business development standpoint to see if there was a partner/OEM/acquisition opportunity to get started more rapidly than a new development effort. To cut to the chase, I was not successful in that department. The second advantage of Quest that I was able to use was the fact that there are over 120 products in the Quest portfolio. That meant that there was a lot of intellectual property that I could try and draw from. It did not take me long to stumble upon PowerGUI, which had been getting a lot of attention in the Windows world due to its PowerShell focus. I had also met Dmitry Sotnikov (one of Quest’s Windows ninjas) several times at various Quest events and he always kept me loosely aware of what he was working on in the Windows world. I introduced myself to Darin Pendergraft, the Product Manager of PowerGUI, to find out more about what he was working on and see what virtualization opportunities existed. After several meetings and demos I came to find out that Dmitry had actually started writing some basic VMware management capabilities into PowerGUI in the form of a PowerPack. This work was based on what Carter Shanklin had released with the now famous VMware Infrastructure Toolkit (VITK). I was instantly hooked. It didn’t take much to convince Darin and the PowerGUI team of the virtualization opportunities and get them to agree to let me use the PowerGUI engine for my project. With their buy-in I now had a very rapid way to get to market with an extensible toolkit. Armed with a solid use-case filled with all kinds of good market data and a solid product strategy it was time to go ask to have a new project funded. Since I was adamant that the toolkit I provided be free of charge, I met some opposition in getting approval, but at the end of it all, I was able to get minimal funding to get things kicked off. Introducing the Features The introduction to the idea of using PowerGUI to manage VMware environments had already been introduced by some initial work by Dmitry and the PowerGUI team. The next step was to refine the existing capabilities and start to add some virtualization expertise and use cases to the solution. Starting in November of 2008 and continuing straight through to the Virtualization EcoShell release I was able to work with Kirk Munro on defining these use cases and building out the VMware PowerPack to what it is today. While we were busy updating the PowerPack it was really starting to take off in popularity in the virtualization community. By March of 2009 we were able to generate over 3,000 downloads in a single month of the VMware PowerPack. This gave me confirmation that the research that was put into the validity of a VMware toolkit was accurate. While Kirk was busy blasting away on my use cases and features the core PowerGUI development team was going through a rebranding exercise to allow me to launch the product as Virtualization EcoShell. The first question that comes to many people’s minds is “Why rebrand the product?â€Â In our case it isn’t a simple rebrand of a product; it is also an architectural decision. PowerGUI, while it had some integration with virtualization, was targeted at a Windows audience, and primarily at PowerShell script developers. There were definitely significant differences in roadmaps and features for two very different audiences between PowerGUI and what I envisioned for Virtualization EcoShell. Based on these differences, we split the PowerGUI codebase for Virtualization EcoShell and I now have my own independent product in which I can extend based on my roadmap and my target audience. I also have dedicated developers working on Virtualization EcoShell. The Virtualization EcoShell developers are on the same team as the PowerGUI developers, which will allow us to share cool features with each other and still have consistent architectures, but at the same time, both products are now flexible in how they grow and mature to meet their unique customer demands. As Virtualization EcoShell proliferates and takes on a life of its own, we will see these as two independent products with different audiences. The amount of VMware administrators that will need to move an Exchange Mailbox to a different store or reconfigure an OU will be rare. Opposite of that, an Exchange administrator or AD administrator will rarely have a requirement to modify DRS settings in a VMware Cluster. This doesn’t mean basic capabilities won’t provide benefit to the opposite audience, it just means we can focus on what our specific customers really need access to in the complimentary technologies, without overwhelming them. With that, you have gotten a VERY small peak into what my life has been over the last 12 months, and I look forward to pushing this initiative forward until I’m called upon to find “The next big thing†for the virtualization community!
Trackback(0)
|
TrackBack URI for this entry
Subscribe to this comment's feed
Show/hide comment form