I'm always looking for better ways to get my job done, save my employer money, and expand my skill set. So whenever I get a chance I'm looking at the competition of the tools we're currently using to see if there's tricks to learn, or reasons to switch. I've been keeping an eye on IIS on various Windows servers for a while, more recently I've been looking at SyBase and SQL Anywhere, as well as CouchDB for data storage (but more on those two later).
So: Windows, WIMP, and why I think you should be giving it a serious look if you're currently a Windows shop.
1. Use the expertise you already have in-houseIf you're currently running Windows you already know how to: install patches, restart machines, manage security and ACLs, connect and administer, get help, etc. When I say you I mean you as an organization, not an individual.
When I was younger, and slightly more full of stupid than I am now. I made probably the stupidest decision of my professional life (thus far). I was in a Windows shop running Windows servers for everything, with quite a few applications running through Lotus Notes. I was tasked with building a new Intranet. Rather than re-training myself (one person, and an intern at that) to use the monstrosity that was Lotus Notes R5, I somehow managed to convince my boss that we should put a Linux machine in the server room. The project for the most part worked: I built a decent (by my then current standards) Intranet system for the company.
I guarantee the system didn't survive six months after my departure.
Why? Because maintaining it required everyone else (many more than one) in IT to learn what I was good at. They had to re-train themselves to maintain a single system in a network of many. It simply wasn't worth the effort.
2. Avoid duplication of ServersWhen you introduce a new stack, you're inevitably introducing a new server. That's an extra server to maintain, backup, power, upgrade, manage, etc. If you're doing a small roll out there's inevitably a machine in the room already that's not seeing a lot of load, just throw it on there. If it's an entirely different stack your current solutions for a lot of the problems aren't going to work (your backup scripts and applications for Windows won't auto-magically migrate over to Linux).
If you read my first story, you can see how many additional problems I caused there. Backing up the machine was going to take extra effort. It was another slot in the rack that couldn't be used for anything else (despite ridiculously low load).
3. Avoid duplication of StaffWhen you're running multiple stacks for important or critical applications, you need staff to support them. If you've got Windows servers and Linux servers you've got staff supporting them both. Multiple sys-admins, multiple people on-call, multiple sets of vacations to manage.
At my current employer, this is our current situation, as we have linux servers for the web, and Windows for everything else. This means we have two sets of system administrators, one for the Windows stuff, the other for Linux. We've got multiple pagers so one person from each team can be on call 24x7. I'm not suggesting this is bad per se, but it is an additional cost.
4. Integrate tightly with current technologiesWhen you're consistently running systems of a similar stack, things just play nicely with each other. Reporting applications, backup, information sharing, etc. It all just works. You don't need a different username password combination for your development server as you do for your machine logon, and another one still to restart a service. If your security policies permit (and it seems wise) you can centralize this.
At work we have passwords, many of them. We mount dev systems over semi-reliable samba shares, with unique logins and directory structures not entirely tied to our general login accounts. This causes both groups of sysadmins to come together for every new hire to create the appropriate directories and entries in various configuration files.
5. There's features out there not available on LAMPMany of us have become overly complacent in the thought of Microsoft as a follower in the web arena, products like Internet Explorer aren't doing much to shake this. IIS 7 is more than a follower, in a lot of realms I feel it has advantages over the technologies I'm used to using. In particular I might call out their XML based configuration system, and per-directory configuration without the performance hit. In terms of configuration XML has a lot of advantages over .ini, in terms of parsing, grouping of elements, parent child relationships, etc. They're also easy to manipulate programatically with predictable results which allows Microsoft and others to create great user interfaces for their maintenance and upkeep (i've never found a graphical apache configuration tool I didn't hate). For per-directory configuration think .htaccess files, only with more power (like virtual hosts), and without the performance hit. Most production sites turn off .htaccess support (AllowOverride None) because otherwise you've got a slew of needless stat calls on every request, with IIS 7 you leave them on, the server simply subscribes to the files so changes are pushed into the application by the operating system, rather than being pulled on each request. You've essentially got drag and drop-able applications (since the entire app, configuration, data (SQLite), and all can reside on disk, in one folder) with no performance problems. Streaming media is also very easy on IIS servers, throw in the media services plugin and you get a wealth of congfiguration options, a process that's still difficult to set up efficently on Apache.
At work we end up leaving .htaccess support on a lot, mostly for some of our more frequently (daily) changing sites. By changing daily not only do I mean it, I also mean changes beyond simple database updates, drastic changes to code and presentation happen regularly. Rather than lean on our hosting provider for frequent restarts we've ended up leaving .htaccess support enabled. To manage the performance hit these pages are relegated to their own machines, in separate clusters from the rest of our production sites. Managing system configuration with all the various virtual hosts has become so complex that only a few staff members are trusted with the task.
In conclusion, and to be perfectly clear. I'm not suggesting that WIMP is the right solution for you. I'm merely encouraging that you pull your head out of the sand and consider your options. If you're already running a substantial Windows server room, there may be more reasons to stay, than to switch.