Ever since Netcraft has started tracking statistics regarding Web server usage, IIS has never beaten Apache when it comes to the number of sites using the two Web servers. Even in early 2002, when Apache took a dip while IIS increased in popularity, there was still a 30% gap between them. Today (in early March 2006), Apache enjoys almost a 50% lead over IIS. Of course, these statistics take into consideration all of the free and cheap hosting services that use Apache and don't consider internal use of IIS in many companies.
That said, 50% is still a huge gap! And, there are a number of reasons that your company might consider making the jump from an IIS solution to Apache. I'll quickly explain some of these reasons and then go over some of the ramifications of such a decision and provide some advice for mitigating problems related to this kind of a move.
Since the focus of this article is on moving from IIS to Apache, I'm not going to spend a lot of time balancing the argument. That is, while I personally consider both IIS and Apache to be worthy products, I'm leaning toward Apache, which is the intended focus of this article.
First off, IIS is a good Web server, and it's getting better with each new version, so why make a jump from a perfectly good Web server to Apache? Moreover, with each new iteration, Microsoft improves the security of IIS, making the case for change a little less compelling. And, for some organizations—particularly those that have a heavy reliance on other Microsoft tools—a change would simply not make any sense.
Now, for those of you that do not have tools—such as SQL Server Reporting Services—that are tightly tied to IIS, are there compelling arguments for making the leap?
The answer: If you have a need to operate in a heterogeneous environment, and have a need to choose a single Web server to use across all platforms, you simply can't beat Apache. The lines have blurred with regard to other issues that used to set Apache apart from IIS, including the security and manageability of the servers.
Another answer: If you need to implement a significant Web service and want to be able to do so with a minimal license cost, consider Apache on Linux for your solution.
For sake of argument (and to get on to the meat!), I'm going to assume that your organization has made the decision to at least consider moving from IIS to Apache and you want to know what to expect should you decide to begin an actual migration.
Plan for ASP
One significant hindrance to migration efforts from IIS to Apache lies with the issue of dynamic scripting language choice. For most Windows Web environment, ASP or ASP.NET are the languages of choice since they are very well supported and included with IIS. Unfortunately, both are native to Windows and Microsoft has not moved them outside this playground. However, there are a number of ways that you can still make the move to the open source Apache/Linux combination (or Apache/Windows, for that matter).
Change to another language
If you only use ASP casually on your site, you can opt to migrate your ASP code to another language, such as PHP. With smaller sites, this is probably best handled manually, but for larger sites, the prospect of converting code could be a major undertaking. However, there are some tools available that can help you with a conversion. For example, asp2php is a free tool that can help you make this leap. While this free tool is only provided to help you make the move (it doesn't do it all, by any means), it can help you avoid some of the tedious task of recoding hundreds of pages of code.
Also consider the use of a Java-based framework for a site if you decide to take the plunge and migrate to another language. Apache's Tomcat provides you with a free, open source servlet container to help make this change.
If you do decide to make the jump to a new language, remember that it's not the syntax that was difficult to write in the first place, but it was the logic. Since you already have the logic completely documented in your ASP code, migrating to another language shouldn't be horrendously difficult.
Keep ASP and still run Apache
One great thing about open source and an open market is that for just about any need, you can find a reasonable solution. In the case of continuing to run ASP code after moving to Apache, there are many solutions available for you to peruse.
The most well-known solution, Chilisoft ASP, is now a
product from Sun called Sun Java System Active Server Pages 4.0 and provides
ASP support for certain versions of Solaris, Red Hat Enterprise Linux, HP-UX,
AIX and Windows (without IIS, of course). Sun Java System ASP 4.0 supports
Apache 1.3 and 2.0. Sun's solution also provides
As with anything, a conversion process using this software is probably not going to be 100% perfect and you may need to make some minor code changes to make everything work exactly as you expect, and there are some instance—if you use Visual Basic objects, for example—in which this solution won't work at all.
Another option is to use Apache's mod_perl module and a perl-based solution called Apache::ASP. This is not as clean a solution as others, so do a lot of research before you decide on this free solution.
Learn a new management style
If you're an IIS guru, the Internet Services Manager has probably become a familiar tool for you. In IIS 6.0, the Internet Services Manager manipulates the XML-based IIS metabase. What Apache administrators have been able to enjoy for a very long time is the manipulation of server configuration files using nothing more than a text editor. While this is possible in IIS 6.0, it's far from a well-known fact! In versions of IIS prior to IIS 6.0, the metabase was a binary file that required special tools to manipulate.
Apache, on the other hand, using simple, (usually) readable, plain-text configuration files to handle 100% of its configuration. When you need to change the path you're your server's document root file, you just load up httpd.conf (Apache's main configuration file) into a text editor, look for the DocumentRoot directive and change the path.
Why is this a good thing? First off, you don't need any special tools to make configuration changes to your Web server. GUI-based tools, at times, can make the reconfiguration job more difficult.
Second, for a production Web server, the corruption of a single file should not result in an unusable Web server. While you always need to back up configuration files, it's easier to back up the contents of a text-based configuration file in multiple places. For example, for Apache, you can print the contents of your httpd.conf file after you make changes.
On the flip side of the complexity equation, if you do like Apache's text-based approach, you'd be prudent to install some kind of versioning system so that you can easily track changes that are made to these files. That's one thing you don't really have to contend with under Windows since it's a little harder to make mistakes that bring the system down that you have trouble finding later on.
Note: The upcoming IIS 7.0 is supposed to permanently do away with both the IIS metabase and Internet Services Manager in favor of .config files for IIS' configuration and a new tool to manipulate the settings of the .config files.
Of course, Windows admins are very used to GUI-based management tools so converting to a text-based approach may require some time and training. Make sure to allow yourself enough time to become familiar with Apache's various directives and commands.
There's a module for PHP, a module for Perl, a module for MySQL, a module for this and a module for that. Simply put, Apache is nothing if not incredibly modular! That Apache approach is this: Install only what you need and nothing else. This seriously reduces the attack surface of the Web server and also improves performance since you're only running what you need. Yes, you can disable certain IIS services, particularly under IIS 6.0, but a default IIS 6.0 installation is still less efficient than a default Apache installation.
What do you need to learn here? First off, everything in Apache is handled through some kind of module. Want database access? Get a module. Want scripting? Get a module. Want proxy services? Get a module. This is definitely a good way to handle this kind of service, but Windows administrators may not be used to the flexibility offered by a system like Apache. There are hundreds of modules available that help you make Apache do new and interesting things. For example, with IIS, you're somewhat limited with your authentication methods. With Apache, as of this writing, there were 64 modules listed on the Apache Module Registry that are all designed to extend Apache's authentication methods to other systems, including PostgreSQL databases, IMAP servers, LDAP directories, NT servers, Oracle databases and a whole lot more.
In total, the Apache Module Registry has well over 400 modules all designed to help Apache help you meet your goals.
This brings up the issue of how you handle direct connections to things like Microsoft SQL Server, which is commonly used with IIS. An open source called—FreeTDS—provides your Linux or IIS-less Windows Server the capability to continue to communication directly with SQL (or Sybase) servers.
Or, while you migrate from IIS, you could also consider migrating to a lower cost database such as MySQL or PostgreSQL.
Note: IIS 7.0 is also supposed to "go modular" a la Apache.
As for other modules, such as IIS-specific ISAPI modules, you will need to migrate these to something that works outside of IIS, such as NSAPI. Apache does includes the mod_isapi module which provides basic ISAPI extensions, but not support for ISAPI filters.
Understand platform differences
Index.htm vs. index.html: The difference is subtle, but will bite you if you don't notice it. Apache's default document is "index.html" whereas IIS uses "default.htm". Further, Windows systems use path names with backslashes while Linux and UNIX use normal slashes.
As you migrate your site, make sure to be aware of platform differences and adjust appropriately. I would recommend adding another default document named "index.htm" to your Apache configuration file and also allow Apache to process files with both ".htm" and ".html" extensions.
The birds-eye steps
The migration from IIS to Apache is not trivial, but it can be broken down into just a few high-level decision-making steps.
Decide on a platform
The good news: Apache runs on practically anything you have. Run it on Windows, Linux, UNIX, NetWare, and it will work. The bad news: This makes your decision about where to run Apache a little more difficult.
After all, with IIS, your platform decision was made for you. With Apache, you're free to choose to run Apache anywhere you like. The answer to this question lies in your overall environment. If you're open to trying open source in your environment, or you're trying to move to open source, consider Linux. If you're only moving away from IIS for security reasons, consider sticking with Windows.
Decide the future for scripting in your organization
If your IIS servers use ASP, I highly recommend you try Sun's ASP server product. It does a surprisingly good job at working with your ASP code on any platform.
If you're not doing any scripting yet and are serving just static pages, the point here is moot, but, if you do take up scripting, look for something pervasive like Java or PHP.
Choose your database
While there is no reason to move of SQL Server, if you're in an organization committed to moving off closed-source products, consider the use of MySQL or PostgreSQL for your database needs. I've used PostgreSQL for some significant databases and have directly migrated SQL Server databases to the product and have found it to be a very worthy replacement.
Does your IIS server authenticate users against Active Directory? You'll need Apache's mod_ldap. Go through your entire site and ask yourself exactly how it works what locate the Apache modules that you will need to support your business.
Install, migrate, and test!
Once you've made all of your selections, install your new servers, install the supporting services, such as Apache modules or Sun ASP, migrate your code and test it thoroughly.
Take it in baby steps
As you would expect, any conversion like this can't be broken down into two or three steps and called good, except for the simplest of sites. Decide if it's worth taking the plunge and then plan your strategy very well. With Apache's wealth of support resources, you will probably be able to conquer any problem that comes your way.