RISC to IA or Server Migration – what do we call all this effort?

I was at a conference recently and while I demonstrated the Xeon E7 processor RAS (Reliability, Availability, Serviceability) features, I discussed RISC to IA migration with the attendees. Occasionally I got blank stares."Oh, we’re doing server migration," was a common response, along with "we’re migrating our UNIX servers to Linux."

Perhaps we here at Intel get ourselves tripped up over our usage of terms. Many of us live in the world of processor architectures.  This leads us to use the terms RISC to IA, which refer to the different processor architectures.  Moving up the stack to the hardware layer, some refer to Server Migration or Platform Migration.  Let’s take another step up the stack to the operating systems. Here, what we discuss is referred to as UNIX to Linux migration.  This also includes moving applications from proprietary servers to the cloud and even data center consolidation where large proprietary servers are replaced by Virtual Servers running on Intel based hardware.

If you’re doing any of the above, then you need to read these blogs for hints and suggestions.  You should also visit the server migration website for helpful tips.  The website is public and is filled with white papers, case studies and How-Tos. We add to the site all the time, so keep visiting us!

The term proprietary hardware usually refers to servers that are marketed uniquely by one vendor.  For example, POWER 7, sold uniquely by IBM, or SPARC sold by Oracle. Both fall into this definition.  While these processors have many good features, they have a serious limitation.  Usually, once you buy into the server line, you are limited to the same processor based servers for future upgrades. These upgrades can involve significant physical changes in the data center.  Often, the term ‘forklift upgrade’ is used as this type of upgrade entails the replacement of an entire rack of hardware.

The term ‘Open Servers’ is used for hardware that utilizes the x86 architecture.  This hardware is characterized by two processor vendors and numerous choices for server platform manufacturers, as well as form factors.

Another term used here is commodity server.  This usually means something cheap but low cost Xeon processors are anything but ‘cheap’ in the pejorative sense.   Here, commodity is related to availability from a wide range of vendors in a variety of form factors.

Another term used at a very technical level is Endianness. This refers to the byte order of mutli-byte data. In a crude example, say the number 1758 is represented by two bytes. On a Big Endian machine, like SPARC or POWER, the first byte has 17 and the second byte has 58. On a Little Endian machine, like the Intel Xeon, the first byte has 58 and the second byte has 17. There are a lot of reasons for each architecture but suffice it to say that multi-byte data has to be converted before it can be used by a machine with a different architecture.  While some programs are written to be ‘endian neutral,’ most databases are not, and custom built programs aren’t either.

This endian difference is the reason we have to go through this migration protocol. If you search for endian difference on Intel.com, you can find white papers and even a video addressing how to code for this.

I want to end on where the term ‘endian’  came from (I worked with Danny Cohen 10 years after he wrote this paper). Almost 300 years ago, Jonathon Swift wrote Gulliver’s Travels, a satire on the politics of the day.  He had the characters of the world he created go to war over which end of an egg to break, the big end or the little end, when taking the shell off of a hardboiled egg.  To me, the bottom line is that we have to be careful how seriously we take ourselves. While endian differences created considerable work for us, there should never be an argument about who is right or wrong.