Death by Command Line – NOT
http://viarengo.com has been running smoothly on VMware for more than 10 days now.
CPU utilization is around 10% which is common in many IT applications out there.
CPU Usage Post Virtualization
I am running two virtual machines on the server now:
- My web site
- A file server.
Unfortunately I don’t really have the need to utilize the available CPU cycles for other applications. My use case is really about encapsulating a legacy application to be able to run it in the future in its current configuration on any x86 platform. Eventually, I will want to run it in the cloud (more on this later).
A Pleasant Surprise
One pleasant surprise in using VMware Converter, ESXi and the VI Client is their ease of use. The reason I am surprised is that way too often server software is plagued by the “tyranny of the geeks” syndrome where installing, configuring and managing it is done through “Death by Command Line”.
Don’t get me wrong. If you read Sriram Krishnan’s post on the tyranny of the Geeks, I am NOT against being accurate and strict at the level where VMware software works. Managing hardware resources is not like the Web where the KISS principle rules and sloppiness is not only acceptable but often useful as described in this great post by Adam Bosworth.
Also, I do get the value of having command line and scripting interfaces for automated management and the ability to integrate with existing management tools.
What I am talking about is the fact that ease of use and management tools are often an afterthought in server-side software. I remember when I worked at Object Design, we had some really amazing engineers (mostly from MIT). They built an amazingly powerful product (Object Store) that stored ANY C++ structure on disk transparently to the C++ developer. Very powerful and elegant.
The problem was that once you stored your C++ objects into the database, the only way to get at the data was through the C++ application that put it there in the first place. No browsing, query, reporting, or visual administration tools. This was good for me as it allowed me and my partners to build a startup to fill these gaps but it was bad for early customers trying to build mainstream applications on ObjectStore.
Born to Suffer
The early adopters of any given technology don’t care as much about ease of use. As I sometimes joke about it with colleagues and friends, the early adopters are ‘born to suffer‘. They kind of like it. They feel empowered by making the product work, cracking the code, finding the undocumented command line argument that does the trick.
The rest of us just get frustrated. Note that this does not apply to most SaaS applications as the lack of usability prevents them from taking off in the first place.
While it is natural for a new technology to be slighlty hard to use and lack some of the more mainstream tools, in my experience it requires a different type of product management and engineering culture to take a product to the next level of usability. But this is not the subject of this post.
The Simple Baker Usability Test
This post is about how refreshing it was to be able to install, configure, run and administer my VMware instance ALL through the UI of the provided management tools (other than the small workaround to make ESXi work on an unsupported disk controller). No complex command line commands, switches, messing with configuration files, etc.
Although my use case is relatively straightforward, I touched many parts of the VMware stack foundation and tools.
- PTV (Physical to Virtual) Conversion – VMware Stand Alone Converter
- ESXi installation – VMware ESXi
- ESXi Configuration – VMware Virtual Infrastructure Client
- VM Deployment – VMware Stand Alone Converter
- VM Creation – VMware Virtual Infrastructure Client
- Additional Storage Installation – VMware Virtual Infrastructure Client
- VM Performance Monitoring – VMware Virtual Infrastructure Client
It will be intersting to go learn from VMware customers what their experience is in more complex IT scenarios.
No “tyranny of the geeks” so far.
)