Minor Downtime and IIS7 Musings

Ok, this week has been a bit hectic for me because we are going through another one of those mini-milestones for IIS7, and I am also on "point" for issues team-wide. So, I have been looking at way too many random things lately and not really spending a lot of coherent time thinking about the various topics to write about.

Also, some of you have also been asking me direct questions about your specific problem which while pertinent to you, I think they may not be interesting to anyone else. While I do not mind answering questions or explaining how things work, I do draw the line when I start taking on a consultant or tech-support type of role because such services imply support... which is not something I am signed up to do. The best source for Microsoft product support remains contacting Microsoft PSS.

About the IIS7 "Changes"

Some of you have been asking for more of the not-so-obvious tidbits about IIS7... you know, the human side of it as well as personal observations. I understand - the press releases, TechEd presentations, slide decks, etc all just talk about the technical details, which is great and all, but it does not give any insight into the team, process, attitude, atmosphere, etc. And to that, I can chat about without breaking any obvious rules. :-)

Much like how people have been experimenting with Windows Vista Beta 1 on Virtual PC/Server and finding interesting issues/incompatibilities at the OS-level, I have to say that IIS7 is encountering a similar sort of growing pains internally. Why?

Well, if you stop and think about it, IIS7 is basically yet another major architectural change when compared against IIS6 and IIS5, except this time, many of the key changes are internal and not immediately user-visible (other than the UI and the distributed configuration system).

For example, the biggest user-visible architecture change between IIS5 and IIS6 is the IIS6 Process Model, based on independent w3wp.exe worker processes aggregated into logical Application Pools for purposes of health monitoring and management. Well, this same process model and user-visible benefits are still there in IIS7, except we are re-working the internal plumbing to support additional scenarios.

Then, you look at the core server engine, the piece that runs inside of w3wp.exe to handle user requests, and you notice that while ISAPI Extensions and ISAPI Filters are still supported in IIS7, they are no longer considered the native extensibility APIs. IIS7 introduces a new native code Win32 extensibility API (completely public, of course, so you can do whatever we can do to IIS7), and we basically re-implemented (with copious amounts of code copying from IIS6, of course) our modules on top of this new API to mimic the IIS6 server behavior. Once again, to the casual observer, nothing is dramatically different on the surface, even though the internal plumbing is completely different and once again supports additional scenarios not previously possible, such as deep integration with IIS behavior by 3rd party modules who can truly monopolize the entire web server stack.

I can go on and on about how every major subsystem in IIS7 is often refactored from IIS6 to better support scenarios. For example, to maintain backward-compatibility between the new distributed configuration system and the old IIS metabase, we have to give you an optional mapping system to translate values between the two configuration systems, so that your old administration scripts as well as existing product setup programs still function. Once again, no new functionality as far as the customer base is concerned, but the internal engineering compatibility is definitely there. We will work with your existing scripts, but we definitely encourage writing to non-legacy APIs.

Of course, you still have the option to run IIS7 completely clean of legacy, and I encourage it to get the maximal benefits from IIS7. Getting rid of cruft by doing clean installs (no upgrades) and migrations is a good idea in general.

Dealing with Change

Of course, all of these "internal" changes are bound to catch up with us when we hit major milestones and other MS teams start to verify their existing IIS dependencies against our newly refactored (but IDEALLY should be IIS6-compatible) IIS7.

Hehehe... those of you who have been around this industry for a while should immediately realize the futility of such a statement. We basically just re-wrote the IIS world. And yup, it is all going to work the very first time with the rest of the IIS world. :-) A-ok.

So, yeah, the number of interesting broken assumptions and "feature changes", either by-design or unintentional, is definitely climbing, but nothing bad or unexpected. I know that IIS6 broke a lot of applications due to our hard security stance, but IIS7 will not be much different, unfortunately.

We are going even MORE hard-core on security changes to simplify your administrative experience (hopefully) as well as improve application isolation for the web hoster. For example, memory management for Longhorn/Vista improves tremendously, allowing IIS7 to break the arbitrary OS-limits of user-desktop heap and simultaneous connections. So, you can finally have as many simultaneous connections as the OS can handle (instead of an arbitrary value calculated from available NonPagedPool memory), or as many simultaneous Application Pools using unique user identities (instead of the ~60 limit right now or sharing single user sessions to scale - web hosters get the full user process isolation benefits for free). But with more features comes more rope to hang yourself with...

But, yeah... if you get some good things for free, then you should also expect to get some "by design" breaking changes for "free". ;-) So, I think you should be flexible to deal with the situation. We do try very hard to maintain compatibility and do not break your applications just-because (though sometimes, the reason may not obvious to you and it is hard for us to ever communicate why or make it obvious).

I suggest that you do not get too stuck with the thought of "this code worked on IIS5/6 but does not work on IIS7, so it must be an IIS7 bug" and instead consider all the NEW capabilities that we are bringing to the table... and sometimes, those new changes will break existing code or be hard to maintain backward compatibility, and we will make the architectural call, much like security...

So, yeah, change is coming, and it is coming in a big wave. Get ready for the ride... :-)

//David