Friday, July 4, 2008

To GUI or not to GUI

there's been an excellent discussion going on on the Ubuntu Server List recently that reveals the multi-dimensional complexity of this topic

as I see it, this question - to GUI or not to GUI - has at least the following 3 dimensions:

1. It has a user dimension - does a user need/want a GUI (the Windows admin converting to Linux or the new admin)? or does a GUI limit the admin (the *nix expert)?

2. It has an IT department dimension - if I have Windows admins and I want to deploy Linux, I need to retrain, rehire, or give them a GUI they are comfortable with. If I am a Linux shop, and my company merges with a company that is a windows shop, how do I reconcile these two departments and their systems?

3. and it has an enterprise dimension - if I don't have some centralized system that automates change and configuration management (ccm), then I am very reliant on the sysadmins that know the complexities of the config files, that know scripting, cron, etc., and that follow revision control procedures (back up all .confs before making changes...). And if these admins leave, or don't follow procedure, the business is hurting. So enterprises have a strong business continuity motivation to implement a system that takes some of the complexity out of the ccm process.

therefore, the trick, IMO, to implementing a CCM system is to provide enough of what the noobs need, without limiting the experts too much and, at the same time, giving the enterprise more visibility and control.

These market requirements drive the design specs:

1. the system needs to be modular and flexible, with GUI and cli/scripting options
2. it needs to be functionally segregated (role based access control) so that different users can access different functions depending on their expertise
3. it needs to be scalable - client/server, many as one changes even with the GUI
4. It needs to be secure - ssl-encrypted, built-in revision control
5. it needs to be multi-platform, preferably covering *nix and windows
6. of course, it needs to be open source ;) seriously, an open source and open standards approach greatly enhances the ability to integrate with other lifecycle management tools like patching, monitoring, reporting, etc.

the problem with most open source ccm options is that they address one or a small subset of the needs to the exclusion of the others. Oliver mentions func, which I agree is a very nice improvement over scripting for medium to large fedora shops and soon probably other distros as well. But it doesn't help the Linux noob, and it doesn't give the enterprise any greater visibility or control. Is it a far better way for the *nix expert to do what they already do today with scripts and such? Yes. will it help Linux penetrate windows accounts, doubtful (and, in fairness, I don't think it was ever intended to do so). eBox and Webmin, on the other hand, simplify things for the newby, but they don't scale, they don't provide enterprise security or control (rbac, revision control, etc.) and they do handicap the expert.

So, my question to the Ubuntu server team, is, if you buy the above framework and rationale, what are their goals for a future Ubuntu server management system? who's the intended audience? Personally, I think they ought to cast as wide a net as the universe of existing systems will allow.
Add to Technorati Favorites