All posts by Scott Alan Miller

Started in software development with Eastman Kodak in 1989 as an intern in database development (making database platforms themselves.) Began transitioning to IT in 1994 with my first mixed role in system administration.

Understanding the Western Digital SATA Drive Lineup (2014)

I choose to categorize Western Digital’s SATA drive lineup for several reasons. One is that WD is the current market leader in spinning hard drives so this makes the categorization most useful to the greatest number of people, the “color coded” line is, based on anecdotal evidence, far and away the chosen drive family of the small business market where the diagnosis is most important and SATA drives retain the most disparity of features and factors making them far more necessary to understand well. While technically the only difference between a SAS (SCSI) and SATA (ATA) drive or even a Fibre Channel (FC) drive is nothing but the communications protocol used to communicate with them, in practical terms SAS and FC drives are only made in certain, high reliability configurations and do not require the same degree of scrutiny and do not carry the same extreme risks as SATA drives. Understanding SATA drive offerings is the more important for practical, real world storage needs.

WD has made understanding their SATA drive line up especially easy by adding color codes to the majority of their SATA drive offerings – those deemed to be “consumer” drives, and an “E” designation on their enterprise SATA drives and one outlier, the high performance Velociraptor drives which seek to compete with common SAS performance for SATA controllers. Altogether they have seven SATA drive families to consider covering the gamut of drive factors. While this diagnosis will apply to the easy to understand WD lineup, by comparing factors here with the offerings of other drive makers the use cases of their drives can be determined as well.

In considering SATA drives, three really key factors stand out as being the most crucial to consider (outside of price, of course.)

URE Rate: URE, or Unrecoverable Read Error, is an event that happens, with some regularity, to electromechanical disk storage media where a single sector is unable to be retrieved. In a standalone drive this happens from time to time but generally only affects a single file and users typically see this as a lost file (often one they do not notice) or possible a corrupt filesystem which may or may not easily be corrected. In healthy RAID arrays (other than RAID 0), the RAID system provides mirroring and/or parity that can cover for this sector failure and recreate the data protecting us from URE issues. When a RAID array is in a degraded state UREs are a potential risk again. In its worst case, a URE on a degraded parity array can, in some cases, cause total loss of an array (all data is lost.) So considering UREs and their implications in any drive purchases is extremely important and is the primary driver of cost differential in drives of varying types. URE varies from the low end at 10^14 to the high end at 10^16. The numbers are so large that they are always written in scientific notation. I will not go into an in-depth explanation of URE rates, ramifications and mitigation strategies here, but understanding URE is critical to decision making around drive purchases, especially in the large capacity, lower reliability space of SATA drives.

Spindle Speed: This is one of the biggest factors to most users, spindle speed directly correlates to IOPS and throughput. While measurements of drive speed are dynamic, at best, spindle speed is the best overall way to compare two otherwise identical drives under identical load. A 15,000 RPM drive will deliver almost exactly double the IOPS and throughput of a 7,200 RPM drive, for example. SATA drives commonly come in 5,400 RPM and 7,200 RPM varieties with rare high performance drives available at 10,000 RPMs.

Error Recovery Control (ERC): Also known as TLER (Time Limited Error Recovery) in WD parlance, ERC is a feature of a drive’s firmware which allows for configurable time limits for read or write errors which can be important when a hard drive is used in a RAID array as often error recovery needs to be handled at the array, rather than the drive, level. Without ERC, a drive is more likely to be incorrectly marked as failed when it has not. This is most dangerous in hardware based parity RAID arrays and has differing levels of effectiveness based on individual RAID controller parameters. It is an important feature for drives assumed for use in RAID arrays.

In addition to these key factors, WD lists many others for their drives such as cache size, number of processors, mean time between failures, etc. These tend to be far less important, especially MTBF and other reliability numbers as these can be skewed or misinterpreted easily and rarely offer the insight into drive reliability that we expect or hope. Cache size is not very significant for RAID arrays as they need to be disabled for reasons of data integrity. So outside of desktop use scenarios, the size of a hard drive’s cache is generally considered irrelevant. CPU count could also be misleading as single CPUs may be more powerful than dual CPUs if the CPUs are not identical and the efficacy of the second CPU is unknown. But WD lists this as a prominent feature of some drives and it is assumed that there is measurable performance gain, most likely in latency reduction, through the addition of the second CPU. I do, however, continue to treat this as a trivial factor and mostly only useful as a point of interest rather than as a decision factor
The drives.

All color-coded drives (Blue, Green, Red and Black) share one common factor – they have the “consumer” URE rating of 10^14. Consumer is a poor description here but is, more or less, industry standard. A better description is “desktop class” or suitable for non-parity RAID uses. The only truly poor application of 10^14 URE drives is in parity RAID arrays and even there, they can have their place if properly understood.

Blue: WD Blue drives are the effective baseline model for the SATA lineup. They spin at the “default” 7,200 RPMs, lack ERC/TLER and have a single processor. Drive cache varies between 16MB, 32MB and 64MB depending on the specific model. Blue drives are targeted at traditional desktop usage – as single drives with moderate speed characteristics, not well suited to server or RAID usage. Blue drives are what is “expected” to be found in off the shelf desktops. Blue drives have widely lost popularity and are often not available in larger sizes. Black and Green drives have mostly replaced the use of Blue drives, at least in larger capacity scenarios.

Black: WD Black drives are a small upgrade to the Blue drives changing nothing except to upgrade from one to two processors to slightly improve performance while not being quite as cost effective. Like the Blue drives they lack ERC/TLER and spin at 7,200 RPM. All Black drives have the 64MB cache. As with the Blue drives, Black drives are most suitable for traditional desktop applications where drives are stand alone.

Green: WD Green drives, as their name nominally implies, are designed for low power consumption applications. They are most similar to Blue drives but spin at a slower 5,400 RPMs which requires less power and generates less heat. Green drives, like Blue and Black, are designed for standalone use primarily in desktops that need less drive performance than is expected in an average desktop. Green drives have proven to be very popular due to their low cost of acquisition and operation. It is assumed, as well, that Green drives are more reliable than their faster spinning counterparts due to the lower wear and tear of the slower spindles although I am not aware of any study to this effect.

Red: WD Red drives are unique in the “color coded” WD drive line up in that they offer ERC/TLER and are designed for use in small “home use” server RAID arrays and storage devices (such as NAS and SAN.) Under the hood the WD Red drives are WD Green drives, all specifications are the same including the 5,400 RPM spindle speed, but with TLER enabled in the firmware. Physically they are the same drives. WD officially recommends Red drives only for consumer applications but Red drives, due to their lower power consumption and TLER, have proven to be extremely popular in large RAID arrays, especially when used for archiving. Red drives, having URE 10^14, are dangerous to use in parity RAID arrays but are excellent for mirrored RAID arrays and truly shine at archival and similar storage needs where large capacity and low operational costs are key and storage performance is not very important.

Outside of the color coded drives, WD has three SATA drive families which are all considered enterprise. What these drives share in common is that their URE rate is much higher than that of the “consumer” color coded drives. Ranging from URE 10^15 to 10^16 depending on model. The most important result of this URE rate is that these drives are far more applicable to use in parity RAID arrays (e.g. RAID 6.)

SE: SE drives are WD’s entry level enterprise SATA drives with URE 10^15 rates and 7,200 RPM spindle speeds. They have dual processors and a 64MB cache. Most importantly, SE drives have ERC/TLER enabled. SE drives are ideal for enterprise RAID arrays both mirrored and parity.

RE: RE drives are WD’s high end standard enterprise SATA drives with all specifications being identical to the SE drives but with the even better URE 10^16 rate. RE drives are the star players in WD’s RAID drive strategy being perfect for extremely large capacity arrays even when used in parity arrays. RE drives are available in both SATA and SAS configurations but with the same drive mechanics.

Velociraptor: WD’s Velociraptor is a bit of an odd member of the SATA category. With URE 10^16 and a 10,000 RPM spindle speed the Velociraptor is both highly reliable and very fast for a SATA drive competing with common, mainline SAS drives. Surprisingly, the Velociraptor has only a single processor and even more surprisingly, it lacks ERC/TLER making it questionable for use in RAID arrays. Lacking ERC, use in RAID can be considered on an implementation by implementation basis depending on how the RAID system interacts with the drive’s timing. With the excellent URE rating, Velociraptor would be an excellent choice for large, higher performance parity RAID arrays but only if the array handles the error timing in a graceful way, otherwise the risk of the array marking the drive as having failed is unacceptably high for an array as costly as this would be. It should be noted that Velociraptor drives do not come in capacities comparable to the other SATA drive offerings – they are much smaller.

Of course the final comparison that one needs to make is in price. When considering drive purchases, especially where large RAID arrays are concerned or for other bulk storage needs, the per drive cost is often a major, if not the driving, factor. The use of slower, less reliable drives in a more reliable RAID level (such as Red drives in RAID 10) versus faster, more reliable drives in a less reliable RAID level (such as RE drives in RAID 6) often provides a better blend of reliability, performance, capacity and cost. Real world drive prices play a significant factor in these decisions. These prices, unlike the drive specifications, can fluctuate from day to day and swing planning decisions in different directions but, overall, tend to remain relatively stable in comparison to one another.

At the time of this article, at the end of 2013, a quick survey of prices of 3TB drives from WD give these approximate breakdown:

Green $120
Red $135
Black $155
SE $204
RE $265

As can be seen, the jump in price primarily comes between the consumer or desktop class drives and the enterprise drives with their better URE rates with Red and RE drives, both with ERC/TLER, being in a price ratio of almost exactly 2:1 making, for equal capacity, it favorable to choose many more Red drives in RAID 10 than fewer RE drives in RAID 6, as an example. So comparing a number of factors, along with current real world prices, is crucial to making many buying decisions.

Newer drives, just being released, are starting to see reductions in onboard drive cache for exactly the reasons we stated above, drives designed around RAID use have little or no purpose to having onboard cache as it needs to be disabled for data integrity purposes.

Drive makers today are offering a wide variety of traditional spindle-based drive options to fit many different needs. Understanding these can lead to better reliability and more cost effective purchasing and will extend the usefulness of traditional drive technologies into the coming years.

Choosing Software Versions for Deployment

Something that I see discussed very often in IT circles is “which version of software should I install.” This could apply to a database, an application, firmware or, probably most often, operating systems, and with the upcoming end of support life for Windows XP the topic has reached a fevered pitch.

There are effectively two sides to this discussion. One side believes that the latest and, presumably, greatest software should always be used. The other believes that software needs to mature and take a “wait and see” approach or even considers each version to be a different product and not a continuum of development.

Both approaches have their merits and neither should exist completely without the other. Blindly updating software willy nilly is not wise and avoiding patches and updates without reason is not wise either. Careful consideration of the factors and empathy for the software development process are important to keep in mind when making these decisions.

First, there are two completely different scenarios to consider. One is the updating of current, existing software. The assumption being that the current state of things is “working” with the accepted possibility that “working” might include a security exposure that has been discovered and requires updating in order to close. The other scenario is a new deployment where there is nothing currently and, we are starting from scratch.

Let’s start with the second case, as it is far easier to provide guidance on.

In the case of new software deployments (or new operating systems), always use the current, most recent version of the software unless there is a clearly known technology limitation preventing it ?? such as known bugs or software incompatibilities.

Software is not like other types of products, especially not in today’s world of online patch releases and updates. I assume that the mentality that old versions of software might be preferable to current ones comes from a combination of physical products (watches, cars, dishes, furniture, wine) where a specific year or model might be superior to a newer model for various reasons and from legacy software delivery modes where finished software products were just ??thrown over the wall? and the final state was, quite simply, the final state without any reasonable opportunities for updates, patches or fixes. Neither of these cases applies to modern business software (with only the rarest of exceptions.)

Software development is roughly a continuum. Normal development processes have new software being built on top of old software either directly (by creating updates to an existing code base) or indirectly (by rebuilding based on knowledge gained from having built a previous version of the software.) The idea being that each subsequent version of software is superior to the one preceding it. This is not guaranteed, of course, there are such concepts as regression errors and just bad development, but by and large, software improves over time – especially when we are talking about enterprise class software used in businesses and under active development. New software is not just the next phase of the old software, it also represents, in nearly all cases, the current state of patches, bug fixes, updates and, when necessary, changes in approach or technique. New software, coming from quality shops, is almost exclusively better than old software. Software evolves and matures.

Beyond the quality of software itself, there is the concept of investing in the future. Software is not something that can sit on the shelf forever. It needs to stay, to some degree, up to date or it stops functioning because the platform that it runs on changes, some new artifact comes to light, security holes are discovered or needs change. Installing old software means that there is an investment in the past, an investment in installing, learning, using and supporting old technology. This is called “technical debt.” This old technology might last for years or even decades, but old software loses value over time and becomes increasingly expensive to support both for the vendors, if they continue to support it, and for the end users, who have to support it.

The same concept of technical debt applies to the software vendors in question. There is a very large cost in creating software and especially in maintaining multiple versions of that software. Software vendors have a lot of incentive to reduce support for older versions to focus resources on current software releases (this is a major reason why SaaS deployments are so popular, the vendor controls the available versions and can eliminate legacy versions through updates.) If customers require support for old versions, the cost must be absorbed somewhere and often it is absorbed both in monetary impact to all customers as well as a decrease in focus on the new product as development teams must be split to support patching old versions as well as developing the new. The more effort that must go in to old versions, the less effort that can be put into new improvements.

Within the framework of what I have already said, it is important to talk about code maturity. Often code maturity is stated as a reason for deploying “old code”, but I think that this is an IT misunderstanding of software development processes. If we think about a released line of code, just because it is released and in use does not really make it more mature. Code does not change in the wild, it just sits there. Its maturity is “locked” on the day that it is released. If it is patched, then yes, it would “mature” post release. Later versions of the same software, based on the same code base but more up to date, is truly the more “mature” code as it has been reviewed, updated, tested, etc. to a greater degree than the early release of the same code.

This is counterintuitive to, say, a car where each release is a fresh thing with new opportunities for mechanical problems and different reliability concerns – where waiting a few years gives you a chance to see what reliability issues get uncovered. Software is not like this. So the concept of wanting more mature software would push you to deploy the “latest and greatest” rather than the “tried and true.”

If we think of software version numbers rather like ages, this comes through.  Linux 3.1 is much older, in terms of software maturing, than Linux 2.4.  It has a decade of additional development.

Let’s use a real world example that is very relevant today. You are in a shop about to install your first server(s). Windows Server 2012 R2 has just released. Should you install Windows Server 2008, 2008 R2 (2010), Server 2012 or Server 2012 R2 (late 2013?)

To many shops, this sounds like we are talking about somewhere between two and four different products entirely which probably have different reasons for choosing each. This, by and large, is untrue. Each newer version is simply an upgrade, update, patch and feature increase on the previous one. Each one, in turn, is more advanced and mature than the one preceding it. Each new version benefits from the work done on the original release of its predecessor as well as bug fixes, patches and feature additions done in the interim between the original release and the successor release. Each new release is, in reality, a “minor release” of the one before it. If we look at the kernel revision numbers, instead of the marketing names of the releases, it might make more sense.

Windows Server 2008 was Windows NT 6.0. Windows Server 2008 R2 was Windows NT 6.1, obviously a minor revision or even a “patch” of the previous release. Windows Server 2012 was Windows NT 6.2 and our current Windows Server 2012 R2 is Windows NT 6.3. If we were to use the revision numbers instead of the marketing names, it sounds almost crazy to intentionally install an old, less mature, less updated and less patched version. We want the latest updates, the latest bug fixes and the latest security issues to have been addressed.

For new software deployments, the newer the software installed, the better opportunity to leverage the latest features and the most time before inevitable obsolescence takes its toll. All software ages so installing newer software gives the best chance that that software will last for the longest time. It provides the best flexibility for the unknown future.

Following this line of thinking might lead us to feel that deploying pre-release or even beta software would make sense as well. And while there might be specific cases where this does make sense, such as in “test groups” to check out software before releasing it to the company at large, in general it does not. The nature of pre-release software is that it is not supported and may contain code which never will be supported. Using such code in isolation can be beneficial, but for general use it is not advised.  There are important processes that are followed between preview or beta releases and final releases of code no matter what maturity level the overall product is at.

That brings us to the other situation, the one in which we are updating existing software. This, of course, is a completely different scenario to a fresh install and there are many, many more factors involved.

One of the biggest factors for most situations is that of licensing. Updating software regularly may incur licensing fees that need to be factored in to the benefits and cost equation. Some products, like most open source software, do not have this cost and can be updated as soon as new versions are available.

The other really large factor in updating software is a human effort cost to updating – unlike in a fresh installation, where the effort of install is effectively a break even between old software and new.  In reality, new software tends to be easier to install than old software simply due to improvements and advancements.  Maintaining a single version of software for a decade means that resources were not dedicated, during that time, to upgrade processes. Upgrading annually during that time means that resources were used ten times to enact separate upgrades. That makes updating much harder to cost justify. But there is more than just the effort of the update process itself, there is also the continuous training needed for end users who will be forced to experience more changes, more often through constant upgrades.

This might make updating software sound like a negative, but it is not. It is simply an equation where each side needs to be weighed. Regular updates often mean small, incremental changes rather than large leaps allowing end users to adapt more naturally. Regular updates mean that update processes are often easier and more predictable. Regular updates mean that technical debt is always managed and the benefits of the newer versions which may be features, efficiencies or security improvements, are available sooner allowing them to be leveraged for a longer period of time.

Taking what we have learned from the two scenarios above, however, there is another important take away to be found here. Once the decision to perform an update has been made, the question is often “to what version do we update?” In reality, however, every update that is more than a standard patching process is really like a miniature “new software” buying decision and the logic as to why we “always” install the newest available version when doing a fresh install also applies here. So when performing an update, we almost always should be updating as far as we can – hopefully to the current version.

To apply the Microsoft example again, we can take an organization that has Windows XP deployed today. The business decides to invest in an update cycle to a newer version, not just continued patching. There are several versions of the Windows desktop platform that are still under active support from Microsoft. These include Windows Vista, Windows 7, Windows 8 and Windows 8.1. Updating to one of the less current versions results in less time before that version’s end of life which increases organizational risk, using older versions means continued investment in already old technologies which means an increase in technical debt and less access to new features which may prove to be beneficial once available. In this particular example, newer versions are also considered to be more secure and require fewer hardware resources.

Every business needs to find the right balance for them for existing software update cycles. Every business and every software package is different. Enterprise software like Microsoft Windows, Microsoft Office or an Oracle Database follow these models very well. Small software projects and those falling near the bespoke range may have a more dynamic and unpredictable release cycle but generally will still follow most of these rules. Consider applying empathy to the software development process to understand how you and your software vendor can best partner to deliver the greatest value to your organization and combine that with your need to reduce technical debt to leverage your software investment in the best possible way for your organization.

But the rules of thumb are relatively easy:

When deploying new or updating, shoot for the latest reasonable version of software.  Use any deployment opportunity to eliminate technical debt as much as possible.

When software already exists weight factors such as human effort, licensing costs, environmental consistency and compatibility testing against benefits in features, performance and technical debt.

Doing IT at Home: Logging

Continuing my series of making your home more like a serious business environment, this time I want to talk about log collection. We touched on this a little in “Doing IT at Home: Ticketing and Monitoring” as Spiceworks, which I mentioned there, does some amount of Windows event collection. That was a very light treatment of the subject, however, and a serious “Do IT at Homer” is going to want something more robust and enterprise class.

Enterprise log collection, searching and reporting has really moved from a niche to a core IT tool over the past decade with the charge lead by the ubiquitous Splunk. There are many products that potentially fit into this category with varying degrees of features and robustness. Traditional “old school” logging systems tend to fall into the categories of Windows event collectors like Spiceworks, Windows Event Collector and ManageEngine EventLog Analyzer. In the UNIX world and in networking hardware worlds we tend to work with syslog compatible systems like Rsyslog and Solarwinds Kiwi Syslog Server. But these products are pretty limited, being very focused on limited platforms and are often quite expensive (Kiwi) or lack a good user experience (Rsyslog.) In exploring for your home lab it may make sense to play with some of these products. But for really taking your logging to the next level we are going to need to looks at vastly more robust platforms that address all of these data sources and more, are extensible and are designed around not only collecting data but making it searchable and displayable and, hopefully, usable by more than just the hard core home system administrator.

Leading the charge for this new breed of log collection systems is Splunk. Splunk is primarily an on-premise, proprietary software package but is available with a “Free” option that is generally perfect for a home IT enthusiast. The Free edition limits the volume of daily log ingest and does not support multiple users which is unlikely to be a real stumbling block for home use. The ingest limit is currently 500MB per day which is an incredible volume of logs . Splunk understands that their paying customers will only ever be larger shops with large log volumes so giving their product away for free for small shops and personal users actually helps their bottom line by encouraging broader experience with and knowledge of their product. Splunk is relatively complex and will take some effort to set up but is extremely powerful and featureful.

Splunk is hardly the only on premise log handling game in town. In the open source realm there is a flurry of activity around log collection and reporting, mostly built atop the Elasticsearch NoSQL data platform and the key one is known as the “ELK” stack referring to the three principle components: Elasticsearch, Logstash and Kibana. A common alternative is to keep the stack but to replace Kibana, the data analytics interface, with Graylog2 which is also open source. The ELK or similar stacks provide very “Splunk like” functionality without the Splunk limitations. Splunk is certainly the more popular choice for enterprises today but ELK is making significant inroads in mindshare and is to be seen most often in more innovative companies such as technology startups, research firms and large hosting services (Dreamhost is a notable sponsor.)

Tackling an on premise log management project will provide a great excuse for all of that extra hardware lying around the house and will provide deeper systems administration experience as there is more “server” to be managed and maintained. Unlike in a business, when doing IT at Home there are significant benefits to technology sprawl and intentionally taking on the more difficult path. We are actively seeking challenges and meaningful systems to be run at home that produce real value and log analysis is a great place to add value by leveraging data that your network is already creating and providing it to you in a way that makes you better able to anticipate problems before they occur, track down issues after the fact and dramatically increase security – knowing what is going on on your network and in your devices has a lot of value and manually parsing Windows Events and UNIX syslogs is boring and error prone. Looking at graphical data is more effective and reliable. And logging platforms can send alerts based on logging events as well.

On premise log management is not the only option. Log management is also available in a Software as a Service business model with two really key players, Splunk – by way of their “Splunk Storm” service and the market leader, Loggly. Both of these vendors offer completely free, capacity limited versions of their hosted products which are far more than any home IT user will need. These services allow you to get up and running with enterprise log management in a matter of minutes without any investment, neither in time nor money nor hardware. If your goals are less around learning system administration and more purely around focusing on good log management or you simply lack the racks of hardware at home that precipitate intentionally creating “extra” IT services in the house then hosted log management is very likely the right choice for you. For those focused on development, network administration or other areas of IT this is likely the more useful option. Loggly, especially, is easy for anyone to sign up and start sending log data and is the leading hosted log management product today.

The larger and more active that your home network becomes the more valuable good log collection and management becomes. Logs provide deep insight into your network and a good log management solution will not only provide you with a high level view of your data but will also be useful in replacing the traditional views of your live log data. Working from an attractive web interface is generally far more effective than manually scouring logs, even when looking at current events.  And some log management solutions will also provide good facilities for long term log retention which is often lacking in non-centralized solutions.

Good log management is rapidly becoming more and more important and an expected service in business. Five years ago it was common to see even very large enterprises not yet adopting these kinds of tools. Today it is assumed that any company of any reasonable size will have a solid, mature logging solution, almost certainly Splunk, in place and with the increasingly lower and lower barriers to entry from ELK and Loggly we see enterprise logging working its way into smaller and smaller firms. Logging at home is an excellent way to enhance your personal portfolio, extend your knowledge and skillbase and build up your resume. Get logging today!

The Desktop Revolution Is Upon Us

With the pending end of support for Windows XP looming just around the proverbial corner, it is time to take stock of the desktop landscape and make hard decisions. Windows XP has dominated the desktop landscape in both home and business for more than a decade. Sure Windows 7, and to some small degree Windows 8, have widely replaced it, there is still a huge Windows XP install base and many companies have failed to define their long term strategy in the post-XP world and are still floundering to find their footing.

A little context is, I feel, pretty important. Today it may seem a foregone conclusion that Microsoft will “own” the business desktop space with Mac OSX fighting for a little piece of the action that Microsoft barely notices. This status quo has been in place for a very long time – longer than the typical memory of an industry that experiences such a high degree of change. But things have not actually been this way for so long.

Let’s look instead to the landscape of 1995. Microsoft had a powerful home user product, Windows 95, and were beginning to be taken seriously in the business space. But their place there, outside of DOS, was relatively new and Windows 3.11 remained their primary product. Microsoft had strong competition from many fronts including Mac OS and OS/2 plus many smaller niche players. UNIX was making itself known in high end workstations. Linux existed by had not yet entered the business lexicon.

The Microsoft business desktop revolution happened in 1996 with the landmark release of Windows NT 4.0 Workstation. Windows NT 4 was such a dramatic improvement in the desktop experience, architecture, stability and networking capability that it almost instantly redefined the industry. It was Windows NT 4 that created the momentum that made Microsoft ubiquitous in the workplace. It was NT 4 that defined much of what we think of as modern computing. NT 4 displaced all other competitors relegating Mac OS to the most niche of positions and effectively, completely eliminating OS/2 and many other products. It was in the NT 4 era that the concept of the Microsoft Certified Professional and the MCSE began and where much of the corpus of rote knowledge of the industry was created. NT 4 introduced us to pure 32-bit computing in the x86 architectural space. It was the first mainstream operating system built with the focus being on being networked.

Windows NT 4 grew from interesting newcomer to dominate the desktop space between 1996 and 2001. In the interim Windows 2000 Pro was released but, like Vista, this was really a sidelined and marginalized technology preview that did little to displace the incumbent desktop product. It was not until 2001, with the release of Windows XP, that Windows NT 4 had a worthy successor. A product of extreme stability with enough new features and additional gloss to warrant a wide-spread move from the old platform to the new. NT 4 would linger on for many more years but would slowly fade away as users demanded newer features and access to newer hardware.

Windows NT 4 and Windows XP had a lot in common. Both were designed around stability and usability, not as platforms for introducing broad change to the OS itself. Both were incremental improvements over what was already available. Both received more large scale updates (Service Packs in Microsoft terms) than other OSes before and after them with NT 4 having seven (or even eight depending on how you count them) and XP having three. Each was the key vanguard of a new processor architecture, NT 4 with the 32bit x86 platform and XP being the first to have an option for the 64bit AMD64 architecture. Both were the terminal releases of their major kernel version. Windows NT 4 and Windows XP together held unique places in the desktop ecosystem with penetration numbers that might never be seen again by any product in that category.

After nearly eighteen years, that dominance is waning. Windows 7 is a worthy successor to the crown but it failed to achieve the same iconic status as Windows XP and it was rapidly followed by the dramatically changed Windows 8 and now Windows 8.1 both built on the same fundamental kernel as Windows 7 (and Vista too.)

The field is different today. Mobile devices; phones, tablets and the like; have introduced us to new operating system options and paradigms. The desktop platform is not a foregone conclusion as the business platform of choice. Nor is the Intel/AMD processor architecture a given as ARM has begun to make serious inroads and looks to be a major player in every space where Intel and AMD have held sway these last two decades.

This puts businesses into the position of needing to decide how they will focus their end user support energy in the coming years. There are numerous strategies to be considered.
The obvious approaches, those that I assume nearly all businesses will take if for no other reason than to maintain status quo, is to either settle into a “wait and see” plan that involves implementing Windows 7 today and hoping that the new interface and style of Windows 8 goes away or that they will find an alternative between now and when Windows 7 support ends. This strategy suffers from focusing on the past and triggering an earlier than necessary upgrade cycle down the road while leaving businesses behind on technology today. Not a strategy that I would generally recommend but very likely the most common strategy as it allows for the least “pain today” – a common trend in IT. Going with Windows 7 represents an accumulation of technical debt.

Those businesses willing to really embrace the Microsoft ecosystem will look to move to Windows 8 and 8.1 to get the latest features, greatest code maturity and to have the longest support cycle available to them. This, I feel, is more forward thinking and embraces some low threshold pain today in order to experience productivity gains tomorrow. This is, in my opinion, the best investment strategy for companies that truly wish to stick with the Microsoft ecosystem.

However, outside of the Microsoft world, other options are now open to us that, realistically, were not available when Windows NT 4 released. Most obvious is Apple’s Mac OSX Mavericks. Apple knows that Microsoft is especially vulnerable in 2014 with Windows XP support ending and users fearing the changes of Windows 8 and is being very aggressive in their technical strategy both on the hardware side with the release of a dramatic new desktop device – the black, cylindrical Mac Pro – and the free release (for those on Apple’s hardware, of course) of Mac OSX 10.9. They are pushing hard to get non-Mac users interested in their platform and to get existing users updated and using the latest features. Apple has made huge inroads into Windows territory over the last several years and they know full well that 2014 is they biggest opportunity to take a sizable market chunk all at once. Apple has made their Mac platform a serious contender in the office desktop space and is worth serious consideration. More and more companies are either adding Macs to their strategy or switching to Mac altogether.

The other big player in the room is, of course, Linux. It is easy to make the proclamation that 2014 will be the “Year of the Linux Desktop” which, of course, it is not. However, Linux is a powerful, mature option for the business desktop and with the industry’s steady move to enterprise web-based applications the previous prohibitions against Linux have significantly faded. Linux is a strong contender today if you can get it in the door. Cost effective and easy to support Linux’s armor’s chink is the large number of confusing distros and desktop options. Linux is hardly going to take the desktop world by storm but the next five months do offer one of the best time periods to demo and trial some Linux options to see if they are viable in your business. In preparation for the likely market surge that Linux will feel most of the key Linux desktop players, Suse, Ubuntu and Mint, have released big updates in the last several weeks giving those looking to discover Linux for the first time (or for the first time in a long time) something especially tempting to discover. The Mint project has especially taken the bull by the horns in recent years and introduced the Mate and Cinnamon desktops which are especially appealing to users looking for a Windows 7-esque desktop experience with a forward looking agenda.

Also in the Linux family but decidedly its own animal, Google’s ChromeOS is an interesting consideration for a company interested in a change. ChromeOS is, most likely, the most niche of the desktop options but a very special one. ChromeOS takes the tack that a business can run completely via web interfaces with all applications being written to be accessed in this manner. And indeed, many businesses are approaching this point today but few have made it completely. ChromeOS requires a dramatic rethinking of security and application architectures for a normal business and so will not be seeing heavy adoption but for those unique businesses capable of leveraging it, it can be a powerful and extremely cost effective option.

Of course, an entire new category of options has appeared in recent years as well – the mobile platforms. These existed when Windows XP released but they were not ready to, in any way, replace existing desktops. But during the Windows XP era the mobile platforms grew significantly in computational power and the operating systems that power them, predominantly Apple iOS and Google Android, have come into existence and become the most important players in the end user device space.

iOS and Android, and to a lesser extent Windows Phone and Windows RT, have reinvented the mobile platform into a key communications, productivity and entertainment platform rivaling the traditional desktop. Larger mobile devices, such as the iPad, are widely displacing laptops in many places and, while different, often provide overlapping functionality. It is becoming more and more common to see an iOS or Android device being used for non-intensive computing applications that traditionally belonged to desktop or laptop devices. Mobile platforms are hard to imagine being able to be the sole computing platform of a business over the next few years but it is possible that we will see this begin to happen in fringe case businesses during this product cycle.

Of course, any talk of the desktop future must take into account changes not just in products but in architectures. Marketing around VDI (Virtual Desktop Infrastructure) has propelled virtualized and centralized computing architectures into the forefront and with the the concept of hosted or “cloud” desktop offerings (including Desktop as a Service.) While still nascent the category of “pay by the hour” utility desktop computing will likely grow over the next several years.

Of course, with so many changes coming there is a different problem that will be facing businesses. For the past two decades just about any business could safely assume that nearly all of its employees would have a Windows computer at home where they would become accustomed to any current interface and possibly much of the software that they would use on a day to day basis. But this has changed. Increasingly iOS and Android are the only devices that people have at home and for those with traditional computers keeping current Windows is less and less common while Mac OSX and Linux are on the rise. One of the key driving forces making Windows cost effective, that is a lack of training necessary, may swing from being in its favor to working actively against it.

Perhaps the biggest change that I anticipate in the next desktop cycle is not that of a new desktop choice but of a move to more heterogeneous desktop networks where many different OSes, processor architectures and deployment styles co-exist. As BYOD proliferates and support of different device types becomes necessary and as user experience changes and business apps move to web platforms the advantages of a disparate “choose the device for the task or user” strategy will become more and more common. Businesses will be free to explore their options and choose more freely based on their unique needs.

The era of desktop lock-in are over. Whether because of market momentum or existing user experience or application limitations – the reasons that kept business tightly coupled to the Windows platform are fading quickly. The future offers a landscape of choices both in what we deploy but also in how we deploy it.