Some pretty basic design principals that would make the web client on VMware awesome, including the ability to make it redundant and supported on free systems!
I was reading this article by Trevor Pott, which does a fairly good job dealing some major problems on VMware’s vSphere web client, and how absolutely terrible it is. However I have some major issues with this article, first of all is no real concrete suggestions on architecture changes (how do we handle the vCenter single point of failure? What about free clients? What about the Flash plugins?). Here I’m going to offer up some suggestions to reaffirm Trevor’s stance that VMware could and should do this better!
A True Single-Page Application
How to Handle the API
Some suggestions on how to handle API calls to the hosts/vCenter:
- Direct Communication – vCenter and VMware’s APIs already exist over HTTPS for web services, if you serve up the single-page application from the same domain/port in a hybrid host setup there will be no additional overhead!
In-Browser Remote Console
Now this is the one piece I will detail is pretty experimental, and by all means feel free to fall back to a Flash/Java console, but what I’d really like to see is a true in-browser console, look at solutions like Guacamole which runs a full VNC client in-browser. Of course there may be some barriers here (Guacamole requires server-side code, not sure how much overhead is acceptable on the Busybox management VM on vSphere).
The only feature I can’t think of reproducing in HTML5 is direct device access required for mounting ISOs/USB devices.
Addressing The Single Point of Failure
These thin API layers (or in one case non-existent) allows not only vCenter to support these single-page web applications, but also the individual hosts. Now it becomes safe to completely scrap the old vSphere desktop clients.
Trevor Pott does some hand-waving about security issues on browsers, and then goes in to complain that the problem really relies with Flash and Java Applets. I’d recommend dropping auto-sign on removing all need for plugins and leaving it at that.
The current desktop client embeds Java applets for some 3rd party tools, so to say it’s more secure is silly.
The old Windows client is imperceptible. Click and the info is there. Expanding a tree just completes in a time frame so short that a human can’t tell there was a delay.
Yeah, I’m not going to stand by this stance at all, the desktop client is a massively bloated slow piece of garbage. It eats a massive amount of memory, is prone to killing consoles and requiring you to play whack-a-mole in your process manager to kill the spawned processes and get it online again.
The web client is slower, but the desktop client isn’t some kind of idea of what we’d want to achieve, that was pretty bad to begin with.
Using PowerCLI it seems like most operations are pretty instant, so it just seems to be entirely overhead on the applications themselves, so a well-written single-page application could easily handle this and be lightning fast.
What’s ultimately the damning element of this is that Internet Explorer is the most common enterprise browser. In many environments, browsers that aren’t Internet Explorer are outright banned.
Other Options and Why I Think They’re Not Good Routes
This is going back to the roots of the vSphere desktop client, which generally comes with the same problems (going to be Windows only). I highly doubt VMware will write some GTK+ Windows/Mac/Linux client. So far VMware has still been unwilling to patch a major problem with RVC, so I don’t think they’re giving attention to more “hip” languages like Python and Ruby.
The next option is planning on a cross-platform application, and I know what they’re going to do: what ever other vendor has done.
I don’t really think I need to say more, I have a love/hate relationship with Java, but most system admins have just the hate side. Mainly it comes down to writing cross-platform applications can be more costly in languages that aren’t like Java with a nice solid platform.
Mono is also an option, but I have a feeling VMware won’t jump on that boat this early.
By far, one of the best parts of major infrastructure decisions: freebies. Additional features or supported platforms with reduced, little or no effort. This list is by no means exhaustive.
This has been a goal off and on for VMware, obviously fully HTML5 will get you 98% of functionality on OSX and Linux, with minor plugins needed for device management.
Take that single-page web application, wrap it in a delivery method like PhoneGap, stylize it so that it fits better on the device (different CSS files for phone/tablet), and you’re going to have not just a small subset of features (like most current mobile apps available), but the ability to fully manage your VMware cluster from the ground up.
There is no reason that VMware should have shipped the web client in it’s current state, nor is it an example of why VMware shouldn’t dedicate resources to writing solid web-based management software, it misses most of the point while throwing all of it’s resources into a dying framework. A bit of design centered around delivering the things customers have been asking for could lead to a product that will put all competitors to shame, instead of turning them away from vSphere.