By: Brendan (btrotter.delete@this.gmail.com),
Room: Moderated Discussions
Hi,
Ireland (boh.delete@this.outlook.ie) on March 13, 2017 2:07 pm wrote:
> My other question about this, is we're used to thinking about a server in terms of the kind of product which
> one would build around x86 cores. When I read you're explanation above, I'm left wondering to myself, what
> sort of a beast is 'a server' possibly going to morph into, with ARM cores in the near to medium future?
Unfortunately (because I really do hate ACPI); it's extremely likely that "ARM server" is going to be almost identical to a modern PC, with all the exact same standards (PCI-E, UEFI, ACPI, DDR4, USB, etc), where the only difference is "nothing relevant" (the instruction set the CPU uses and a few minor things like the interrupt/IRQ controller).
> Like, in the sense, that in the past 'server' machines were something that admin's used to actually
> hate. Reason? There was every conceivable and any service, all trying to run on top of 'a' kernel,
> . . . . and because of that, everyone was in dread of their lives, that 'one' machine would fail.
Changing the instruction set from 80x86 to ARM won't make any difference to server administration; except for making it a little harder to find compatible software and creating additional options to consider when purchasing hardware.
> End Result: The 'server' became this thing, that had half or more of it's cost, actually wrapped up in Raid arrays,
> Raid controllers, redundant psu's, and redundant parts, for redundant parts. And that's part of the reason why
> servers used to be so expensive - and at the same time, not loved at all - by the admin community.
None of that will change either - you'd still have (the option of) redundancy and fault tolerance when purchasing server hardware.
> Now, with virtualization, and thinking along the lines of this fabric design
> that you describe, I wonder where is the server going to go next?
>
> The one thing with moving to x86/ARM, . . . as the chief architect would explain, there's a lot of
> blank sheets of paper in the plan. You really want to have a group of capable, forward thinking individuals
> around this now, because one doesn't get too many 'blank sheet' opportunities in anything these days.
> The opportunity, is a valuable one indeed, because the whole notion of what a server is going to
> become, in the future, is a little bit more flexible than it used to be too.
A few software developers are going to add "ARM target" to their makefiles; and nobody else is going to notice or care whether it's ARM or 80x86. The "blank sheets of paper" are hype fuelled delusions because nothing that actually matters will be any different.
- Brendan
Ireland (boh.delete@this.outlook.ie) on March 13, 2017 2:07 pm wrote:
> My other question about this, is we're used to thinking about a server in terms of the kind of product which
> one would build around x86 cores. When I read you're explanation above, I'm left wondering to myself, what
> sort of a beast is 'a server' possibly going to morph into, with ARM cores in the near to medium future?
Unfortunately (because I really do hate ACPI); it's extremely likely that "ARM server" is going to be almost identical to a modern PC, with all the exact same standards (PCI-E, UEFI, ACPI, DDR4, USB, etc), where the only difference is "nothing relevant" (the instruction set the CPU uses and a few minor things like the interrupt/IRQ controller).
> Like, in the sense, that in the past 'server' machines were something that admin's used to actually
> hate. Reason? There was every conceivable and any service, all trying to run on top of 'a' kernel,
> . . . . and because of that, everyone was in dread of their lives, that 'one' machine would fail.
Changing the instruction set from 80x86 to ARM won't make any difference to server administration; except for making it a little harder to find compatible software and creating additional options to consider when purchasing hardware.
> End Result: The 'server' became this thing, that had half or more of it's cost, actually wrapped up in Raid arrays,
> Raid controllers, redundant psu's, and redundant parts, for redundant parts. And that's part of the reason why
> servers used to be so expensive - and at the same time, not loved at all - by the admin community.
None of that will change either - you'd still have (the option of) redundancy and fault tolerance when purchasing server hardware.
> Now, with virtualization, and thinking along the lines of this fabric design
> that you describe, I wonder where is the server going to go next?
>
> The one thing with moving to x86/ARM, . . . as the chief architect would explain, there's a lot of
> blank sheets of paper in the plan. You really want to have a group of capable, forward thinking individuals
> around this now, because one doesn't get too many 'blank sheet' opportunities in anything these days.
> The opportunity, is a valuable one indeed, because the whole notion of what a server is going to
> become, in the future, is a little bit more flexible than it used to be too.
A few software developers are going to add "ARM target" to their makefiles; and nobody else is going to notice or care whether it's ARM or 80x86. The "blank sheets of paper" are hype fuelled delusions because nothing that actually matters will be any different.
- Brendan
