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.

Open Source Systems Management: What SysAdmins Want

For the past couple months, we've had a poll running on www.netdirector.org asking visitors what they'd like to see as the next feature. As anyone who knows me can attest, I am a huge believer in the wisdom of the crowds, and so the NetDirector roadmap will follow where our community takes us.

The following graph shows the results of the poll so far (click on the image to make it bigger).

As interesting and useful as this feedback is (and, btw, thank you for everyone who participated), I think it is equally interesting to read between the lines of this poll's results. The top three features requested, Windows support, and integration plugins to the two most popular open source patching tools, Apt and Yum, speak clearly and unequivocably to the need for better tool integration. As things stand today, there is no open source tool for managing across Linux, UNIX and Windows systems. Further, even in the Linux/UNIX world, Sys Admins must rely on seperate tools for managing configs (Webmin, command or scripts) and patching those systems with something like Yum or Apt. The concept of lifecycle management, where managing configurations and set up is seemlessly linked with patching and provisioning simply does not exist.

If you want all this, you have 2 choices - shell out beacoup bucks for a proprietary system from someone like Opsware (now HP) or BladeLogic, and get about twice the features you actually need and want, or build it (and then maintain it) yourself.

In the next dot release of NetDirector, we are going to go some ways towards helping integrate these various tools. We'll be offering a Windows agent, and we'll be vastly improving the developer docs so that, hopefully, we can convince people on the Yum and Apt projects to help create NetDirector plugins to these tools. Hopefully, we will also be able to include in this release a feature to allow SysAdmins to run their own scripts through NetDirector.

Open Source SysAdmin Tools: Mind the Gap

In talking with some other people in the open source systems administration / data center automation space recently, I made a surprisingly astute observation while describing where NetDirector fits into the mix. For the set up and administration of a single local server or node, you've got tried-and-true tools like YaST and Webmin, and the newer ebox. These are great for helping SysAdmins who may be newer to Linux/UNIX and for old hands that just don't want to muck around with .conf files. But they don't scale very well to multi-node and distributed environments, where things like revision control, many-as-one (AKA globbing) and RBAC become gotta haves.

If you want these features Today, you need to step up to something like Puppet or cfengine. These tools give you all the power, scalability and control you could ever want. What they aren't, though, is easy to use. So, there's this massive gap between the easy-to-use tools on one hand and the scalable tools on the other. And this is where NetDirector plays.

With NetDirector, less-experienced Admins get a GUI for fill-in-the-blanks administration of many of the most popular open source server apps running on one or a group of servers. In the near future, we will enable more experienced admins to create and run their own scripts through NetDirector against a set of distributed nodes. And NetDirector provides tight role-based access control (RBAC) so that, for example, the script functionality can only be accessed by certain Admins, and more junior Admins can only interface with services via the GUI modules.

Why does this matter? It matters, I think, because if you are a mid sized company, you don't want to have different tools for different admins. You want one tool that all admins can use.

And this brings me to the last wicked cool thing about NetDirector. The next dot release, scheduled for mid feb, will include a Windows agent. With Windows support, in addition to filling the gap between single-server tools and massive CM tools, NetDirector will also bridge the fizzure between Linux and Windows tools.

In the interest of full disclosure, what you can do with NetDirector on Windows will be limited initially, since we don't have any plugins for Windows-based applications (yet). But, if for some reason you are running Apache on Windows, you will be able to use NetDirector to manage it. But the key thing is that this sets the foundation for NetDirector really being able to serve as the single, central administration tool for mid-sized enterprises, since just about all of these guys have some Windows. And, it's free and open source (yes, I can use the term open source confidently, since we are also moving to GPLv2 in the Feb. release).

And where we plan to go with NetDirector is very exciting. So, we'll have the script plugin available soon for running scripts against Linux/UNIX servers. And later, we'll implement the ability to run batch scripts through NetDirector on your Windows machines. And how about Windows service plugins, like a SQL Server GUI, an Exchange GUI, etc.

Me Talking at BarCampRDU '06

Matt Frye is an excellent videographer. You can tell because I actually sound cogent and clear in this clip he recored at last year's BarCamp RDU...

http://www.lulu.tv/?p=12894


Thanks Matt.  I'll pay you later...  ;)

HP Opens Wide for Wares

Yesterday HP picked up Opsware for $1.6 Billion and Neoware for $214 million. Here's my thinking on what the Opsware deal means for other IT automation providers (my company Emu Software included) and for the market in general. I'll write another entry about the Neoware one.

So, HP paid 15 times sales for Opsware, which is at least double the typical premium. Were they just feeling generous? I doubt it. Rather, it was probably a competitive situation. Who else might have also wanted opsware? I'd guess the list might include EMC, IBM, CA, EDS, who knows, maybe Google.

But that's not where the story ends IMHO. Oh no. Consider the impact of this deal on a company like EDS. I read a story today about how EDS competes with behemoths like IBM global services and HP for big IT outsourcing deals, and the EDS sales pitch goes like this. You don't have to get locked-in to one vendor (or fear getting locked-in) and you don't have to pick and choose best of breed from multiple vendors and do the integration yourself (and deal with no "single throat to choke") . Go with us and our EDS Agility Alliance, and get the best of both worlds - EDS serves as point for the service and the other vendors (little companies like Microsoft, Oracle, Sun and Dell) bring their technology expertise. So, what does this have to do with HP buying Opsware, you ask? Well, EDS was probably Opsware's first customer, and may well be its largest. In 2002 Mr. Andreessen sold the ASP part of Loudcloud to EDS for a reported $63.5 million, and EDS turned around and entered into a 3 year deal (since extended) with the part of Loudcloud that Marc kept, which he renamed Opsware. Basically, some smart Sys Admins at Loudcloud needed a way to more efficiently manage their data centers, and so they built Opsware, and Marc decided he'd rather be in the software business than in the application hosting business.

Alright, so, you're EDS, or you're a member of their Agility Alliance, and your sworn enemy is HP. Do you keep relying on HP Opsware for your data center automation? That would seem to me to be a fairly precarious situation. Now, something as central as Data Center Automation is not going to be replaced quickly, but if I'm EDS, I'm actively considering my options right now.

But the fun doesn't stop there. Nortel and Cisco, who I'll remind you compete with HP's Procurve products, both resell Opsware to their enterprise customers. Cisco, for their part, is announing their own Data Center optimization solution, what they're calling Data Center 3.0, this week. According to Chambers, "Because the network is uniquely positioned to be the platform for the data center, we are investing in innovations to help our customers transform their data centers for improved efficiency and increased business productivity."

I wonder if Opsware can contiue to grow its revenue at the same pace as part of HP with all these powerful companies that prevously were freinds are now, at least in part, competitors