Keeping things simple in IT

Over the years, it seems that things in IT are becoming overly complex. Not just because of the natural progression of IT in general, but from extra bloat and nonsense that is being added on top of it all.
Written by Chris Clay Clay, Contributor

Over the years, it seems that things in IT are becoming overly complex. Not just because of the natural progression of IT in general, but from extra bloat and nonsense that is being added on top of it all. Sometimes I think we need to start looking at trimming the extra fat from the bloat, and get back to the basics.

Recently, there's been recent discussion on Firefox and its new versioning system and lifecycle. When you step back and look at it, it doesn't make sense. The versioning that has been used for years has worked out well, and now all of a sudden somebody feels that there is a need for change. Mozilla could keep things simple and just stick with the conventional versioning system and release cycle.

I also wonder about software that is just becoming over bloated. I've often had these thoughts regarding messaging platforms when I compare Microsoft Exchange to open source solutions. Microsoft Exchange is basically a glorified IMAP type messaging platform. But it requires a huge amount of resources. For starters, it requires a 64-bit operating system on the server, plus 1-4 GB per processor core of RAM (I won't get into disk space or performance to keep things simple here). I've worked with a professional consultant and the recommendation for a company with about 600 mailboxes, is an Exchange 2010 server with 8 processors, 64-bit only, and 40 GB of RAM. When I compare Exchange and its requirements to a similar open source messaging solution (running on Linux) like imapd plus sendmail/procmail, Exchange needs such a large amount of resources in comparison. I have run a Linux-based solution using sendmail, procmail, and pop3d & impad for 600 mailboxes, using a 2 processor server, 32-bit mode, with 4 GB of RAM. Microsoft also does everything it can to minimize the load on the server by making Outlook cache all user mailbox data by default. While this does make sense, it seems like Microsoft is trying to cover up the bloat by requiring more hardware resources and RAM (it uses as much RAM as possible to help minimize disk utilization and speed up processing), rather than making the messaging platform more efficient. Don't get me wrong, Exchange has a ton of features right out of the box, which makes it very unique. And Exchange is highly scalable. But the overheard seems really high, especially for a smaller scale solution.

I further expand on my observations of Exchange because of issues I have seen with mail simply disappearing in user mailboxes. This article explains the issue in more detail. With a messaging platform, messages should NEVER disappear. To me, the Exchange model for a mailbox is just overly complex. There is more room for problems, like mail disappearing, rather than sticking to a more standard solution as imapd uses (even though it may not be as efficient -- more testing would be needed to benchmark the two). I have never witnessed any sort of disappearing mail with imapd like I have with Exchange. I've concluded that fewer issues are seen with imapd because it uses text files to store mail, and not a proprietary database type of files.

And even further I'll expand issues with Outlook vs. Thunderbird. Outlook stores local mail in OST and PST files, which are basically database type files as well. Thunderbird also uses a type of database file however it can be parsed as text, while Outlook files cannot. When the PST files become corrupt in Outlook, it is a lot of work to repair mainly because all of the mail is stored in one central file, making a single point of failure. Thunderbird stores local mail in separate files (one file for each folder), so that if one of them becomes corrupted, the entire local mail storage is not affected. Again, the simpler solution has its benefits.

It's no doubt that IT changes often and quickly. But I think we need to keep simplicity in mind when moving forward.

Editorial standards