Paul DuBois
paul@kitebird.com
Document revision: 1.01
Last update: 2003-01-25
Microsoft's presence in the computing market is well-established,
with Windows running on the vast majority of desktop systems worldwide.
In the server arena, Microsoft's segment is much smaller by comparison
due to prior market penetration by other vendors such as Sun and
HP, as well as by Open Source operating systems like Linux and
variants of BSD Unix. This is a clear opportunity for Microsoft,
which has been making a strong push for the hearts, minds, and
pocketbooks of administrators responsible for organizational central
computing services. For example, a recent Microsoft advertisement
features video showing a slate of servers running Windows 2000
humming in a machine room while the voice-over soothingly assures
the viewer that the servers have been running "for days"
without attention. (Presumably this is intended to assuage the
concerns of users familiar with daily lockups and crashes like
the "blue screen of death" that commonly plague earlier
versions of Windows.) It's clear that Microsoft intends to position
its offerings as providing the systems of choice all along the
computing spectrum. One particular part of that spectrum that
has become especially popular in recent years is the organizational
or enterprise web site, which generally requires at least three
components:
Not everyone builds a web site around IIS, of course. The most
visible alternative is Apache, which is the most widely used server
in the world. According to Netcraft, Apache powers more than half
the web sites available on the Internet. Of such sites that are
database-backed, a combination of tools that has proven especially
popular is the pairing of Apache with the MySQL database system,
which can be integrated by means of scripting languages such as
PHP or Perl.
This article takes a look at Microsoft's product offerings for
web site development based on IIS, and compares them to the corresponding
Apache site components. Apache, MySQL, and scripting languages
such as PHP and Perl are best-of-breed components in their respective
categories for web site development. When these products are placed
in head-to-head competition with the corresponding components
of an IIS-based site, they not only perform better at lower cost,
but also give you wider latitude to make your own operating system
and server hardware choices.
The proposition presented here is that organizations currently
running a web site based on IIS have much to gain by considering
other options. The contents of the article will be most pertinent
to groups operating under the following circumstances:
The next section of the article discusses some reasons to consider
alternatives to IIS. For groups that are interested in moving
IIS-based web services to Apache, a later section suggests some
migration strategies.
Reasons To Consider Alternatives to IIS
Running a web site can be a complex business, and many factors
go into assessing the site's effectiveness. This section discusses
several aspects of web site development, comparing an IIS-based
site to one based on Apache.
Choice in Selecting System Configuration
Developing a system to meet the needs of your site requires that
you be able to choose the best tools for the job. This includes
not only your web development components, but your operating system
and the server hardware that the site runs on. Thus, the choice
of what software to use for developing your web site is not a
decision made in a vacuum. In general, tools that can be deployed
only on one platform constrain your options, whereas tools that
are platform neutral allow you to consider a wider range of alternatives.
In this regard, IIS exhibits a complete absence of platform neutrality.
Its users have a choice of running it only under Windows--that
is, no choice. This is reminiscent of Henry Ford's remark about
his Model T automobiles that customers could have in any color
they desired, "so long as it's black." Similarly, you
can run any operating system you like with IIS, so long as it's
Windows. This operating system lock-in has a ripple effect as
well: If you can run only Windows, you can choose only server
hardware that Windows supports. Needless to say, if the consequence
of selecting IIS is to determine your operating system and hardware
choices as well, it rather narrows your options. The same kind
of lock-in occurs with Access and SQL Server as well, which also
are Windows-only products.
By contrast, an Apache-based site provides developers with more
of a choice. If you want to run Windows, you can; Apache, MySQL,
PHP, and Perl all support it. But if you want to go with Unix
or Linux instead, you can do that, too. This freer choice of operating
system translates directly into a broader selection of server
hardware. You can choose hardware that Windows supports if you
like, but it's also possible to select hardware supported by Unix
or Linux--for example, if you require high-end servers beyond
anything that Windows is capable of running on.
Reliability
Customers expect to be able to visit an organization's web site
at any time, not be turned away because the site is down or the
server is having problems. Earlier, this article mentioned a Microsoft
advertisement that pointed out how Windows-based servers can run
"for days" without attention. The ad projects an image
of stability and reliability, but an additional--and no doubt
unintentional--message is that the ability to run for days is
a new thing for Windows. This may indeed be a novel phenomenon
in the Windows world, where a common and well-known strategy among
NT administrators is to reboot servers every few days to keep
them from failing or locking up. But elsewhere in the computing
community, long-running systems are taken for granted. Administrators
who run Unix or Linux are used to measuring uptime in terms of
weeks or months, and sometimes years. In this context, an uptime
of days is decidedly unimpressive.
Aside from differences in typical uptime under normal use, the
tight integration of IIS into Windows has a negative impact on
system availability--the familiar sequence that after applying
a patch or update, the entire system must be rebooted. Worse yet,
you may need to reapply patches after changing the system
configuration, leading to further downtime. With Apache, reconfiguration
takes only seconds, because you restart only that program rather
than the entire machine on which it runs.
Security Concerns
Security is one of the most important aspects of any Internet-based
system. The consequences of being hacked are considerable, ranging
from the inconvenience of having to reload software deleted by
or compromised by an attacker to outright theft or destruction
of sensitive information. Yet, security is perhaps the area in
which IIS is weakest--so much so that insiders refer to IIS as
"It Isn't Secure." New exploits often spread worldwide
with an astonishing rapidity, sometimes crippling systems to the
point where entire networks must be shut down or disconnected
from the Internet while system administrators scramble to correct
the problems and deal with the damage. This may provide job security,
but certainly in an unwelcome form.
The recent waves of Code Red and Nimda attacks that infected hundreds
of thousands of IIS servers illustrate the problem well. Other
IIS exploits, such as buffer overrun attacks against its printing
and indexing functions that give the intruder complete control
of the server host, also are indicative of IIS's mediocre security
record. But these incidents should be viewed in their surrounding
context. They actually demonstrate but one aspect of a larger
issue, which is the general failure of Windows-based products
to seriously address the security concerns of the administrators
responsible for their use. To appreciate the full extent of the
problem (and thus the real basis for concern), consider the larger
picture. IIS vulnerabilities are symptomatic of a history that
goes back years, to the Melissa and ILoveYou email viruses that
targeted Outlook and Exchange users and debilitated mail systems
worldwide after they were released, and to the inception before
that of macro viruses transmitted by means of Word and Excel documents.
Virtually all of the most damaging exploits in recent times involve
one vendor's products. These incidents are not exceptions, they
are part of a pattern. The administrator who wearies after attempting
to cope with these myriad vulnerabilities may be forgiven for
concluding that security simply was not a high priority in the
design of these products, and that perhaps their most effective
function is to serve as a vector for the transmission of malicious
and dangerous attack software.
In defense of Microsoft, one might argue that the number of exploits
against Windows systems compared to those against Unix or Linux
reflects nothing more than the prevalence of Windows in the market.
But if that is so, it's to be expected that the continual scrutiny
given to its products provides feedback that should allow Microsoft
to significantly harden them against attack. That new exploits
arise no less frequently now than ever indicates that this has
not happened. In any event, if scope of deployment correlates
to the number of exploits expected to occur, weaknesses should
be discovered most often for Apache, which is much more popular
than IIS. Yet the majority of breaches occur at IIS sites, while
Apache enjoys an excellent reputation for security.
Perhaps it is the case that inexperienced IIS administrators just
do not make use of the patches that are available, and thus that
problems are due to failure to apply the proper safeguards? There
may be something to this. On the other hand, the number of patches
that Microsoft finds it necessary to issue make the administrator's
life overly difficult, especially in shops that run several IIS
servers. Applying patches can become a full-time pursuit, simply
because there are so many of them. This makes it difficult to
keep up.
At any rate, if inexperienced administrators in the field are
most likely to have security problems, who should be least likely?
Microsoft's own people, of course, such as those responsible for
Passport, the web-based service that Microsoft now champions as
a secure repository for storing consumer information. Apparently
experience is not enough, however; Passport has already had to
be shut down temporarily over issues that left consumer financial
data vulnerable. If Microsoft's own staff have trouble running
its products in a secure fashion, where does that leave the rest
of us? But the most disturbing aspect of this incident is that
it illustrates an attitude toward security that should give administrators
pause. In the wake of publicity about the Passport shutdown, Microsoft
first attempted to shift the blame, characterizing the group that
publicized the vulnerability as irresponsible and saying that
the group should have notified Microsoft instead. After it came
to light that Microsoft had in fact been notified and did nothing
until public disclosure of the security hole, it was forced to
backtrack and acknowledge the true course of events leading to
the shutdown.
This is significant because if you are going to rely on a product
and commit confidential business resources to it, you want to
know that the vendor's claims about the security of the product
are trustworthy. When Microsoft says that it cares a great deal
about security, it's not clear that such claims can be taken at
face value, given events such as those surrounding the Passport
incident. This is worth keeping in mind when evaluating other
security-related claims. For example, Microsoft introduced its
Secure Windows Initiative for Windows 2000, and more recently
its Strategic Technology Protection Program. However, it remains
unclear what the practical effect of these will be. For example,
Windows 2000 and Windows XP are subject to the concepts Microsoft
has laid out in the Initiative, and thus one might expect them
to be more secure. On the other hand, these versions of Windows
have had IIS tightly integrated into them, and IIS is based on
legacy code that predates Windows 2000. Given the track record
of IIS, this is not a promising basis for better security, which
is only as good as the weakest link.
Granted, maintaining security is an ongoing task, and it's never
trivial. But some systems make the job easier than others. In
the arena of security, Apache unquestionably provides a superior
platform for web development compared to IIS. One reason that
Apache is more secure than IIS is that it's designed using a different
philosophy. Apache developers proactively seek to identify and
address security issues They don't wait to be publicly embarrassed
into doing so.
An Apache server should not be considered secure just because
it is Apache, of course. If its administrator pays no attention
to security issues, problems are still likely to occur. But the
default installation is more secure, and Apache certainly won't
need several patches right out of the box, or the continual updating
at the same rate as an IIS server. Apache works with you to help
maintain security. It's not a problematic piece of software over
which you must cast a wary eye, ever vigilant against the next
new wave of infection. The history of Apache is that it's an asset,
not a liability. The history of IIS points to the likelihood that
the product will continue to be a source of problems, and that
it may be prudent to consider a change. After all, who really
pays the price for security breaches? The organizations that use
insecure products, not the one that markets them. Customers have
little choice but to swallow hard and hope the damage will be
minimal--unless they make another choice.
Cost
IIS is included with Windows 2000 and Windows XP, so a site consisting
of static pages can be built using no additional software. But
a truly dynamic site really necessitates the use of a database
back end, and for IIS, the two common choices--Access or SQL Server--must
be purchased as add-ons. The cost of alternative products, such
as the Apache web server and the MySQL database engine, is modest
by comparison. Another factor to take into account is that acquisition
costs are only part of the total cost of ownership. For example,
many costs can arise from security-related issues:
All in all, the total cost of ownership may be very high indeed,
even when the up-front outlay is low.
Performance and Features
In a web service environment, the most resource intensive component
is likely to be the database used as the back end for creating
dynamic content, especially for complex queries. In this setting,
MySQL is one of the fastest databases available, if not the fastest.
Compared to Access, which has a number of shortcomings, an alternative
database engine like MySQL offers a number of advantages for web
site developers. These benefits are outlined in another article,
"Migrating from Microsoft Access to MySQL" (see the
"Resources" section). They include better performance
in networked and multiple-client environments, ability to handle
larger databases, and platform neutrality.
When a more heavy-duty database engine is required, IIS sites
often use SQL Server in preference to Access. Like MySQL, SQL
Server is more capable than Access and provides more robust performance
under significant load. As a result, choosing between MySQL and
SQL Server is not as easy as choosing between MySQL and Access.
Nevertheless, MySQL is attractive in terms of performance, cost,
ease of use, and support. (And of course if you want to run your
site on something other than Windows, SQL Server will not work
at all.) When evaluating the features of each database, be sure
to review current materials, because older critiques of either
product may no longer apply. For example, a common complaint against
MySQL in the past has been its lack of support for ACID transactions,
a capability crucial for business application. This criticism
is no longer valid, because transaction capabilities and full
ACID compliance are now provided by the InnoDB table handler.
Migration Strategies
Issues discussed earlier in the article such as security and platform
neutrality are most important when deciding whether or not to
make a switch from IIS to Apache. Other considerations, such as
compatibility issues, come into play more when planning how
to make the switch. Changing web service platforms isn't a trivial
thing and should be planned carefully. To reduce the effort required
for migration, consider in advance the problems you'll face, your
options for overcoming them, and what help is available in making
the switch. Some principles to keep in mind are as follows:
Try to use portable database interfaces in your applications to
make it easier to switch database engines. This is especially
important if you're planning to make a transition at some point
down the road but are continuing to develop applications on the
existing site in the meantime. Using portable interfaces for your
applications will allow them to be migrated more easily when the
transition does occur. Code encapsulation is important, too. For
example, applications should make connections to the database
using a library call, not by means of connection parameters wired
into individual scripts. This makes it easier to connect to a
different database later by changing the library call rather than
multiple scripts.
It still will be useful to perform a feature comparison between
your old database and MySQL to identify SQL constructs where porting
effort is likely to be concentrated. To take one instance, if
a site uses sub-selects heavily, this will be a concern. MySQL
does not support sub-selects until version 4.1, so if you run
an earlier version, queries that use sub-selects will need to
be rewritten in other forms. (For example, many NOT IN
queries can be expressed as LEFT JOIN operations.)
Leverage What You Know
Three ways to use existing knowledge and experience to minimize
transition shock are to retain some components of your existing
setup, to use new components that are similar to those you're
using now, and to use a development environment that works under
both the old and new sites.
For example, you can retain Windows as the underlying operating
system while switching the web site components that run on top
of it. If you set up a test bed system this way, it allows developers
to continue using a familiar operating system while moving to
Apache and MySQL. This is a smaller leap than making the jump
to a different operating system as the same time. As you gain
experience with the new site development tools, it becomes a less
imposing prospect to migrate from Windows to Unix or Linux. (Although
all the components of an Apache-based site can run under Windows,
migrating to Unix or Linux provides better overall stability and
performance.)
If you want to retain ASP as the site scripting language, consider
using a compatibility engine such as Chili!Soft ASP. This engine
runs under Apache, works on Windows, Unix, or Linux, and includes
a MySQL driver. Thus, it allows use of a familiar language while
opening up other avenues of deployment for your web applications.
Shops with no particular reason to use only ASP can still apply
staff expertise with ASP to new languages. If you like the embedded-tags
approach of ASP, candidates that employ a similar markup-tag structure
include PHP and the Apache::ASP Perl module. Each of these
allow you to write pages that consist of mixed HTML and executable
code. (Apache::ASP requires the use of the mod_perl
Apache module. However, it's a good idea to use mod_perl
anyway, because it provides a dramatic speedup for Perl scripts
running under Apache.)
If you want to explore Java-based options, JSP (JavaServer Pages)
is even more like ASP than is PHP in terms of its scripting syntax.
JSP does require a servlet container such as Tomcat, which is
freely available at jakarta.apache.org
and can be installed and configured relatively easily. You can
even set up a site such that Apache and Tomcat cooperate, with
Apache handling all requests initially and passing through requests
for JSP pages to Tomcat. This requires somewhat more configuration
effort initially, of course, but it give visitors to your site
a more uniform view of your installation as a single server rather
than two disparate servers.
If your developers are not fully familiar with the new tools you're
considering, you may also find it a good idea to hire outside
help to assist in making the transition and helping your staff
get up to speed. (The expense may well be offset by no longer
having to allocate staff time to dealing with the IIS "patch
of the week" dance.)
Use Conversion Tools
You may be able to use conversion tools to migrate your data to
MySQL and to convert existing applications for use with the new
site:
Organizations have a choice in determining which products to use
for web site development, and while Microsoft's IIS is a popular
web server, alternatives are available that are superior in terms
of reliability, security, and cost. In particular, the combination
of Apache and MySQL is an attractive option, with benefits that
range from greater flexibility, performance, and security, to
lower cost and maintenance. Tools are available to help make the
transition from IIS to Apache; the article suggests some migration
paths.
Resources
The following references provide more information about topics
discussed in this article.
http://www.netcraft.com/
http://www.kitebird.com/articles/
http://www.chilisoft.com/
http://asp2php.naken.cc/
http://p2p.wrox.com/php/
http://www.apache-asp.org/
http://news.cnet.com/news/0-1003-200-6077282.html http://www.zdnet.com/zdnn/stories/news/0,4586,2766045,00.html http://www.theregister.co.uk/content/8/18324.html
http://www.microsoft.com/technet/security/topics/codealrt.asp http://www.microsoft.com/technet/security/bulletin/ms01-023.asp http://www.microsoft.com/technet/security/bulletin/ms01-033.asp