Though Apple has made great strides in the consumer computing
market, it has lagged in acceptance in one important area:
enterprise-level networks.
Don't get me wrong, Mac OS X Server is a good product with many
unique features, such as iChat server, Spotlight server, and wiki
server. However, Microsoft has a number of superior design features
that Apple could learn from to create a more competitive solution with
big businesses.
Issues in Apple's Domain
In large corporate networks, directory services are commonplace. In
essence, these allow users to store login information and be managed
from a central repository. In Windows, this is called Active Directory,
and in Mac OS X, Open Directory. Currently, Mac OS X has
built-in support for authenticating with either service. However, Mac
users cannot be managed as well with an Active Directory system as they
can with Open Directory. This is a simple issue of native technology;
each system is designed for its consumer OS counterpart. This means
that Mac OS X servers are required for maximum functionality with
Mac OS X computers.
If a lot of people need to authenticate with the directory service,
it makes sense to distribute the load over multiple servers. The
ability of a technology to function in both large and small
installations is known as "scalability" (the ability to scale up and
down to handle the load). Unfortunately, there are four major
scalability issues hampering Apple's ability to penetrate into large
corporations on a wide scale.
Maximum Number of Servers
First, Apple has imposed a maximum limit of 1,057 servers per Open
Directory domain (a domain is a container used to house and partition
users and resources based on one or more attributes, such as department
or physical location). This may seem like a lot, but with extremely
large networks, this limit can become a scalability stopper.
Circumventing it would require slicing users into domains based on what
server they are closest to - not always a good policy from an
organizational standpoint.
Replication
Related to this issue is the method of replication that Open
Directory uses (replication refers to the process of transferring
directory data between servers to keep them all up to date). In Apple's
solution, one central server directly replicates to up to 32 servers,
which in turn can replicate to up to 32 servers, creating the limit of
1,057 servers. Of course, this is an improvement of Mac OS X
10.4's model, where every replica replicated directly from the master,
creating even more scalability problems. Also, this tree shaped model
can be less efficient than a mesh with the same
number of servers.
Not only that, but the one "master server", as Apple refers to it,
is unfortunately the only one allowed to make changes to directory
data; the rest of the servers are read-only copies. Most people can see
the issue here - putting all your eggs in one basket. If that server
malfunctions, nobody can change anything, not a single password, until
a replacement is implemented and introduced as the new master.
Microsoft dropped this model in Windows 2000 Server with the
introduction of Active Directory, instead implementing something called
"multimaster" replication. In essence, each directory server is exactly
the same as any other in a domain: i.e., "multiple masters". Anyone can
make changes to directory data on whatever server they are connected
to, and if a server goes down, it can simply be replaced with a new
one, which will be given a copy of the newest directory data from the
other servers. This creates more fault tolerance, a major factor in
scalability.
In addition, when servers may be separated by WAN links that are not
constantly active, this model allows local administrators to make
changes for their group of users while allowing users at different
sites to share a single domain; this flexibility in domain design is
another factor promoting scalability.
Though the multimaster model can lead to some data conflicts when
more than one person is able to change data at the same time, as well
as security holes when more people have access to writable copies of
the directory, Microsoft appears to have ironed out most of the
problems in the years since it introduced this, including allowing some
servers to be read-only when full write access is not necessary or even
dangerous, such as cases where physical security is weak or
nonexistent.
Database Size
The third problem is also one of size. The current version of
Berkeley DB, the
underlying software storing all of Open Directory's data, can only
handle about 200,000 records while remaining efficient. Once again,
this seemingly large number can be used very quickly, especially when
one takes into account the number of different things that are stored
in this database. In contrast, Microsoft has a custom-designed database
engine that they say can handle several million records.
This gap also hampers Apple's ability to scale up in large
corporations.
Some may point out that, like the solution for the first flaw, one
could simply cut the users up into different domains.
Not only does this solution share the same organizational flaws, but
it can also present an administration nightmare on a large scale.
Though normally a Mac is able to scan for and automatically locate the
closest server, in a larger environment this doesn't always happen as
planned. In order to balance load on the servers, Apple's solution
sometimes requires an administrator to specify the directory server
each computer will use. While this can be handled en masse by
DHCP (the protocol that automatically configures a network connection),
it still requires tuning to ensure optimal configuration for each
client: i.e., preventing someone from authenticating with a server
three buildings away when the nearest one is down the hall.
Domain Integration
Unfortunately, this can also exacerbate the final major issue,
domain integration. Apple's domains are separate entities from each
other in pretty much every way, forcing a person to add the domains
manually to a "search list" if the correct servers for each domain the
Mac needs to authenticate with are not located.
In Active Directory, domains are treated a bit differently. While
they are separate entities, they are stilled glued together into what
is called a "forest". When a computer is first introduced into the
directory structure under Windows, it is placed into a domain. This
allows someone with a username in that domain to login easily, and if
someone from another domain in the same forest - or even another forest
(e.g. another company) if set up correctly - gives their domain name,
the system automatically gets login information from those servers.
This is because the entire Active Directory is glued together by DNS
(the system that turns web and other word-based addresses, like
www.apple.com, into IP addresses, which are used by the network to
identify computers). When you give your domain, DNS allows you to look
up the nearest server for that domain in order to authenticate. Also,
this solution requires very little knowledge of the server
infrastructure to join a computer to the domain: all one needs is the
name of the domain and the credentials of an admin in the domain.
In other words, these two issues can create shaky ground for
automatic configuration in larger networks, especially those segmented
by routers. This is not an issue in most Active Directory
installations, because DNS records are established by direct
communications with the server, rather than discovery broadcasts like
those used by Bonjour, which are generally not repeated to other
network segments by routers.
The Low-end Issue
One big issue that is loosely related to the others is that of
low-end support. While clients are taken care of all the way back to
Mac OS X 10.1 (and into OS 9 and earlier for some services),
the server side is fairly inflexible. Namely, Open Directory servers
must be a uniform version of the Mac OS. If the master is upgraded from
10.4 to 10.5, all the replicas must be upgraded. In the same way, a
10.5 server will not act as a replica to a 10.4 server.
Microsoft, on the other hand, has an intricate system of "functional
levels" based on what server OSes must be accommodated, with newer
features becoming enabled as older systems are eliminated.
Going Apple can create a huge financial burden on a company if they
choose to upgrade, especially with Apple's somewhat more radical
approach to dropping support for the low-end as of late (i.e., Snow Leopard's Intel-only
restriction), possibly forcing companies to buy new servers to reap the
software benefits.
The Bright Side
On a much more positive note, there are many advantages that Apple's
server technology possesses. The wiki server is just one example of
Apple's propensity to quickly embrace new technologies. Not only that,
but Apple has extraordinarily good command-line support, allowing
everything from installation forward to be run without a GUI. This
partnered with the rock solid SSH support that Mac OS X inherits
from its Unix roots allows it to wipe the floor with the command-line
only version of Windows Server (only introduced with the newest 2008
revision) in terms of command-line administration.
The Future
When Microsoft rose to dominance in the server/network OS field, it
wasn't the dominance of Windows that got it there. Indeed, Novell's
offering integrated well with Windows and was itself a well-built
product. What created Microsoft's victory was their ability to
duplicate Novell's functionality and go beyond it.
Apple should try this with their server product. After all, they've
done it for years in the consumer field.
