WIth 2.1 GAed yesterday, I am happy to announce the 3.0 project kicks off officially. For more fun, I picked up a code name for 3.0 release: Crescendo. For folks know music, crescendo means music gets louder and louder. That is where I want to bring the project to. It’s been a huge success for this VMware sponsored open source project. We’ve had 9,000+ downloads, plus 1000+ SVN code sync, after its first debut in 2008.
So where are we going next?
Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.
Before answering the question, let’s take a look at the themes of previous releases. The theme of 1.0 was ease of use with full object model and getter methods hiding property collector. The theme of 2.0 was Just Enough High Performance Web Service Engine resulted in not only performance boost, but also clean license with pure BSD, and much smaller footprint and zero memory leak.
Now it’s time to re-visit ease of use again, but from a different perspective. As I discussed early, the learning curve of vSphere API comes from two folds: lack of object model, and complexity of data objects. The 1.0 release solved the problem nicely. Now it’s time to tackle the second one.
There are two possible ways to take care of this. First, provide more samples with better documentation as starting point. Secondly, come up with a higher level of APIs that capture the most common use cases so that you have a giant shoulder to stand on. Crescendo will take the second approach.
Let me give a quick example here. As today if you want to add a hard disk to a virtual machine, you have to use the reconfigVM_Task() method with tons of possible parameters while you actually need just a few. What is the point to read deeply into the parameter data objects? These parameters can easily get wrong. You can, for instance, mistakingly assign a unit number that has been taken by other devices under the same controller. Many more details exposed than needed. Therefore I see a need for a higher level APIs that address this use case with far simpler method.
This is just one sample of many common use cases you may find in real projects. To make sure it’s something you find useful, I would love to hear from you on how you use vijava today and what you wish to have in the future. If you have some code to contribute, that would be even better. I can use them as the base to abstract high level of APIs. I will give you credits whenever it’s due.
Architecture wise, the new layer won’t be mixed up with existing layer, meaning you have choice to skip this layer. But if not, you will enjoy a much higher productivity than using the current abstraction.
Another important thing is that crescendo will empower system administrators on writing automation scripts. The current vijava API is mainly targeted toward software developer even though we have nice jython, Groovy tutorials. With Crescendo, the scripts will be easier and shorter.
BTW, I will be at VMworld next week presenting vSphere API best practices, helping at VMware booth in exhibition hall, and book signing at bookstore (Tuesday 12:30~1PM). If you happen to be there, please feel free to stop by.