Stomp has made some very true remarks here. I'd like to add some points.

1) Most questions in IT are not about the tools to use but about planning and "strategic coherence". If you solve problems without having an overlaying strategic decision made chances are you end up with a (in a way running but) quite incomprehensible environment. This will at some point come to haunt you and - unfortunately - not immediately but in the long run, when it is hard to redesign. So plan, plan thoroughly and then rethink your plans. You will get the invested time and effort back in manifolds.

2) stomp already mentioned it, but i'd like to stress the point for emphasis: keep in mind that your environment will change over time and that means you need a tool with enough flexibility and compatibility to support these ever-changing platforms. We are right now starting to use chef too to manage our AIX environment, btw. but are not completely satisfied because we need to use a Linux system as a chef server instead of our native platform.

3) Never forget that practice and prospects are two fundamentally different things. I grew up in a time when PC networks were nearly exclusively served by Novell Netware servers. Then came M$$ and shoved their "WinNT server" onto the market, usually against the outcry of the IT department. Their selling argument was like see, it looks like the Windows desktop your secretary uses to type your correspondence, so she can administrate your network in between two letters. This, of course was utter nonsense (my kitchen knife has the same "interface" as a scalpel - that doesn't qualify me as a surgeon), but it sounded good in the presentation. Once (that was back ~1993) the single 64MB 2-processor Novell server was thrown out and replaced by 8(!) 256MB-4-processor WinNT-Servers (which combined produced about half the speed of the single server before) it was too late to change directions. You might want to avoid such decisions.

4) If you can rely on open source tools. On average (notice: if you look at a specific product you need to evaluate it specifically, not on some market average which may or may not apply in the specific case) they are usually better maintained than commercial software and are less prone to falling victim to "strategic market decisions" - forcing customers to do the manufacturers bidding, no matter what. OSS development directions are (again: in general) also not driven by the same rationale as commercial software. Commercial software is built to earn money for the manufacturer, the more the better. Things like usability, fitness for a certain purpose and code quality are just means to this end, not goals themselves. With OSS software, which is in most cases written by volunteers for the sheer fun of it, this is different.

OK, so far. I might add more points after thinking this over.

I hope this helps.

bakunin