AMD enhances the pitch for Opteron. But who’s buying it?
Coming off of a profitable quarter (after a string of bad ones), AMD came to LinuxWorld last week with a message: “Opteron is alive, well and kicking.” Underscoring AMD’s message was a couple of recent customer wins, primarily in the area of high performance computing. The Opteron technology is impressive, and it has largely lived up to its performance promises. But, over the past couple of years, I’ve had a tough time with some of the justifications AMD has offered for customers choosing Opteron over an Intel offering.
During my visit to LinuxWorld, I met with Kevin Knox, AMD’s director of worldwide business development, who wasted no time in extolling Opteron’s virtues. Cheaper (needs no explanation). Better, on the grounds of on-board memory controllers and AMD’s hyper-transport technology. Faster, in certain configurations (so your mileage will vary). Ease of migration from the 32-bit to the 64-bit world.
AMD has been hailing the migration attribute as one of Opteron’s primary selling points. Buy an Opteron today for its 32-bit prowess today, and when you’re ready to upgrade to 64-bits, you won’t have to buy a new machine, is the standard positioning.
This investment protection story, which AMD is now calling “cost avoidance,” is the AMD logic that I always had some difficulty digesting. After all, suppose you buy an Opteron-based system today thinking you can upgrade later. Three years later, your database application with its giant data set is thrashing between cache and disk, and you realize that you’ve hit the performance barrier. It’s time to stretch the addressable memory space so the system can cache up more data, and your database-bound application can forget about the physical storage. As you prepare to upgrade, you realize that you can stick with your three-year-old system or you can buy a new system (AMD or Intel) that’s umpteen times faster.
In my book, the whole AMD investment protection story is a bit over-rated. Chances are, you’re going to buy a new system anyway. I asked Knox about my theory, and surprisingly he agreed, but his disclaimer was a time threshold. “If you aren’t migrating for another two or three years, you’re right,” Knox said. “Anything after that, you should buy the best 32-bit system [now] and not worry about backwards compatibility [later]. But, for people that are migrating in 18 months or less, this makes sense.”
Ultimately though, if you follow the rest of Knox’s argument, even the 18-month threshold is easily called into question. For example, part of AMD’s Opteron pitch involves a breakdown of a server’s total cost of ownership, and it turns out that a server’s acquisition cost only accounts for about 13 to 17 percent of overall TCO. In the bigger picture, if you go to the trouble of buying an Opteron-based system with the hopes of generating some savings when doing a 32-bit to 64-bit migration, the acquisition savings is at best 17 percent of your total expected expenditure over the life of the server (not to mention the high probability that the “old” server can be redeployed against some other need). Going out 12 to 18 months, I still believe that you might as well buy a new server. Given this scenario, the 32-bit support in the Opteron becomes less of a differentiator.
Buying new systems with a plan to migrate inside of 12 months makes little sense to me. Most companies would tough it out with an old 32-bit unless they had a migration plan for year old systems that made economic sense.
Knox brought up another area of cost avoidance, which may resonate with some (but not all) buyers. After talking about how acquisition costs only account for less than 20 percent of the TCO, Knox dove into an area which, to AMD’s credit, is often overlooked and always worthy of contemplation when migrating any system: transition costs.
The cost for migrating software to 64-bit servers is a real consideration. “For example, if you are running an anti-virus product and other utilities on the same server as the 32-bit software, that all needs to be migrated,” Knox said.
Indeed, the need for that software may not go away. Even if there are 64-bit versions, the 32-bit versions may be doing the job fine without upgrading. Bearing the expense (which varies depending on the software vendor) of upgrading is senseless, and in many cases there won’t even be a 64-bit version of the software. Since the Opteron can simultaneously support the 32-bit and 64-bit versions of an application that needs to be migrated, Knox argues that the Opteron allows you to have your cake and eat it too. You can continue to run the 32-bit software, thus keeping transition costs down. This explanation started to ring a bell and, as dug through my archives, I realized that I wrote the exact same thing last September about the purpose of Intel’s IA32 Execution Layer.
In my interview with Jason Waxman, Intel’s enterprise platform marketing director, he said, "The IA32 Execution Layer comes into play when you want other stuff like anti-virus or back up applications that aren't performance-intensive to run side-by-side with the 64-bit applications they support. It's good for people who don't want to bother setting up a separate system and the application is not performance critical.”
I’ll yield to Opteron on this point because, based on the anecdotal data, it will run those 32-bit applications faster than Intel’s IA32 Execution Layer. However, for applications and utilities in which performance isn’t critical, the IA32 Execution Layer will probably suffice, once again putting the Itanium and Opteron on par with each other. Let’s not forget that for Opteron to win this uphill battle, par isn’t good enough.
Knox wasn’t done with me yet. Another transition cost, according to Knox, is the cost of transitioning x86 software. According to some AMD-commissioned research from Giga (now Forrester), a sample Fortune 1000 organization can expect to bear $1.9 million in x86 conversion costs. Knox’s explanation for this component gets to the heart of what AMD considers to be one of Opteron’s unique selling points. The Opteron’s 64-bit instruction set is an extension of the original x86 instruction set, as opposed to Intel’s 64-bit architecture (IA-64), which is driven by a new instruction set altogether. Armed with the Giga study, Knox explains how the Opteron’s x86 extensions for accessing its 64-bit capabilities means that developers who are accustomed to x86 programming need minimal retraining and, likewise, the original software is easier to migrate to 64-bits. Typical companies, as Knox explains it, can expect to spend $1.9 million more in this exercise for transitioning to IA-64 than they will for Opteron.
But here’s the catch. In order for you to qualify, you have to be one of Giga’s typical companies. According to the report, which AMD shared with me, the calculations are based on the assumption that a typical company is “a Fortune 1000-size financial services organization with a distributed computing environment using 2,000 existing 32-bit servers running 32-bit x86 custom applications: ERP, CRM, SFA with significant database and memory requirements.” In the document’s appendix, where software transition costs are offered in more detail, the heading reads: “Software cost assumptions: the cost to convert a custom assembly language-coded* 32-bit application to a (non-x86) 64-bit server.” Hint: there’s an important caveat hiding behind that asterisk.
Perhaps some of you are saying, “That’s us!” But, since 1991, when I first left an IT management job to become a tech journalist, I have not once encountered an IT shop or a reader with a custom database application that was written in the x86 assembly language, much less one that needs a 64-bit addressable memory space, therefore requiring more programming at the assembly language level. The last time I checked, the major enterprise application providers were suggesting that you use programming environments like Java and .Net. Even if you had some legacy assembler applications laying around that needed to be migrated, wouldn’t you be thinking “maybe it’s time to move to a language that’s understood by more than a handful of people.”
As it turns out, the Giga study goes on to say, “Giga found that there were no significant costs associated with converting existing 32-bit high-level code (C, C++, Java) to non-86 64-bit architectures.” This is a fairly important caveat that I felt AMD conveniently failed to disclose to me.
To the company’s credit, AMD has had some terrific wins over the last year. Getting IBM to build an Opteron-based server; a giant partnership with Sun; support from companies including Oracle, Red Hat, Computer Associates, and SuSE; and some nice customer wins from organizations such as Bristol-Meyers Squibb, The Weather Channel, Daimler-Chrysler and Pirelli.
But the next time AMD knocks on your door in hopes of adding you to that list, make sure you read the fine print.
You can write to me at david.berlind@cnet.com. If you're looking for my commentaries on other IT topics, check the archives.