Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Like all good things, this journey must come to an end. In the previous three articles, we’ve endeavored to logically discuss and explore the important considerations one should be mindful of when choosing an operating system for networked services. So what did we learn?
There are always reasons to choose one over another. We all know about the well-advertised shortcomings of each product on the market. The crux of the situation is more about living with your decisions, and discovering whether or not you should switch. Within each OS zealot camp everyone wants you to switch, and this is no secret.
Microsoft administrators definitely have their work cut out for them. If you’re simply supporting a group of workstations, maybe running a mail server too, you aren’t in much danger. Sure, you’ve got to stay patched and fend off the spam bots, but you don’t have to worry about keeping IIS and database servers running. Hopefully, given sufficiently competent network engineers, you don’t have the traditionally vulnerable services open to the Internet. Your bubble is mostly safe. But there are plenty of web sites running on IIS combined with various back-ends from Microsoft. We would venture to say that with enough care and feeding, Windows servers are secure. You’d better know what you’re doing though. Linux, Solaris, and BSD are the same, in this sense. Running Apache and a database server takes know-how, and if a mistake is made there will be a security incident.
Security isn’t the single most important aspect of choosing an operating system. It should be considered, and it’s especially important to know by what means the OS deals with separation of privileges; but it shouldn’t be the sole determining factor. You still have to get stuff done. And if you’re using in-house applications that demand a specific server, you don’t have choice. If you have PHP, Perl, or other applications based on open standards, you’re all set for a change. If people aren’t completely dependent on Outlook calendars, you can switch. Should you?
We’ve discussed some hardware ramifications, and what to consider when purchasing additional cards and devices that require drivers. Even Unix-loving people have to admit that Windows administrators have it much easier when it comes to hardware support. The really high-end SCSI cards, for example, will likely ship with drivers for major Unix versions too, but this isn’t normally the case. Cheaper devices may or may not be supported, and finding out means you have to know what chips are used—something that’s not printed on the package.
Again, stability is mostly a moot point. Properly administered servers are remarkably stable, no matter what mainstream OS they’re running. Performance, though, is completely relevant. The sad part is that it’s almost impossible to figure out which operating systems perform better. Many reports that praise Microsoft are research studies funded by Microsoft. That doesn’t necessarily mean they’re incorrect, but it makes eyebrows rise. There exist a few minor, but major to some, points about various flavors of Unix that may tilt the scales in favor of the more tightly-managed operating systems. For critical servers there’s just something unnerving about using an OS that isn’t designed to be managed. The BSDs and Solaris are historically better under extreme loads than Linux, but the title seems to go back and forth, probably depending on how strictly the latest Linux patches were reviewed.
The Real Scoop
Are we trying to persuade people to switch to Unix-based operating systems? Not exactly. Samba doesn’t cut it for some things, and ActiveDirectory is quite complex. It really can’t be replaced. There are countless other examples of Unix-friendly applications that clone the capabilities of Windows servers, but there’s always one little detail that just can’t work, thanks to Microsoft. People who try and convince others that Windows clients can be served from Unix are either not supporting a large number of clients, or simply think that the setup isn’t complex enough to warrant the full-featured Directory Services that Windows servers offer. In the spirit of Getting Things Done, it’s probably best to keep like kinds served by their counterparts. There are always missing features in the copycat implementations.
So I should run a Web server on that Windows server too, right?
No, unless you have no choice because some manager decided that Microsoft’s latest programming language is superior. Sorry, you’re stuck. The Microsoft-funded reports show that IIS is just as fast, but websites that track security problems show something a bit more harrowing. If it’s really true that Apache and IIS are equally matched, we’re wiling to ignore the performance issue. There are still many reasons to treat Microsoft’s servers like the plague if you aren’t stuck using them.
In the first installment of this series, we attempted to show how a typical Unix or network engineer would fare running the various operating systems. It was actually surprising to learn that many of the same things could be accomplished in Windows. In many cases, though, the Windows-based admin tools are afterthoughts, and cobbled together by someone other than the original author of the tool. This trend is contrary to the server software trend, like Samba.
In the end, we’re simply going to reiterate that the OS decision ultimately depends on the single most important factor: getting things done. In an IT shop without the expertise needed to perform a switch, preaching the praises of a new operating system is futile. That doesn’t mean preaching isn’t fun. An interesting thing happens with server administrators. When one platform won’t hold up under the load, they will naturally start looking at how their services will run on another server. Various FreeBSD and Linux mailing lists are frequently fielding answers to such questions.
Getting things done, and hopefully not spending the entire day dealing with patches, is the goal. Server administrators eventually learn what is best for them, but sometimes people need a little push, so help them along.
