Amazon has more than half of all Arm server CPUs in the world
Why not Half of all Arm server CPUs now live in the Amazon?
Amazon is the most successful manufacturer of Arm server chips, accounting for just over half of Arm-based server CPUs currently deployed, while some chipmakers are also now betting on Arm-based Windows PCs. This information comes from a report issued by Bernstein Research which estimates that nearly 10 percent of servers …
What sort of e-waste are they generating?
The cloud provider obviously wants to sell the same chip as many times over to customers as possible so want it to be as powerful as possible. At the same time reducing their own running costs so need less power consumption (good, mostly...).
That suggests an incredibly short life time for individual boxes. Is there any prospect of re-using them in other applications? Or are Amazon doing what they do with customer returns and chucking them all in a skip?
Probably less than you might think - older instance types are available for a long time after they are no longer current generation instances - eg t2 is still about and that's an instance type from 2014.
I can still start up A1 instances too - they were the very first generation of ARM instances back in 2018.
This, servers can run for an insane amount of time.
I am currently in the process of replacing a bunch of servers at a client that have been running just fine for 15 years...they're only being swapped out because it is no longer possible to buy spares and keeping them beyond the stash of spares they have stocked up is risky.
They aren't replacing all of the servers either, they're just reducing the number of older servers to ensure they have more parts available than there are servers.
As long as you regularly replace the disks to avoid disk failure, there is nothing wrong with kit that is over a decade old for most use cases if it has been running in a clean, air conditioned, server room etc.
It'll just keep running...as for the energy use aspect, low power servers are not a new thing...I have a couple of old(ish) servers running in my homelab that use just under 110W...Fujitsu Primergy servers (yeah I know, I know, but I like them)...both have 24 cores, 128GB of RAM and run Proxmox...I modded them both to use quieter Noctua fans and I have kitted them out with PCIe m.2 cards for storage (ZFS)...they do have spinning rust in them as well (4 disks each) but I don't use that as "active" storage for virtual machines...it's more like scratch storage for virtual NAS machines for moving stuff about.
These servers are from roughly 2015/2016 I think...so coming up to a decade old...but they're solid...never had any weird issues or quirks...only disk failures, which is to be expected.
They aren't the greatest performers in the world, but I mostly deal with infrastructure and web development, so as long as they run the latest version of Linux in containers, it's all good.
Why would the e-waste be any different than if they used x86 chips? Obsolete hardware is eventually going to be scrapped no matter where it came from. Since Amazon is designing not only the chips but the entire server package which is several orders of magnitude more potential waste, we can hope they are designing them with efficient recycling in mind. That will be a lot easier with a handful of standard form factors they choose to match their recycling capability than buying stuff off the open market that's designed purely for cost without regard to how easy it will be to recycle at EOL.
It is also clearly a lot better for the world to provide performance 'x' with less energy, especially at Amazon's scale.
China recycles a *lot* of chips...you can still buy *new* motherboards with *obsolete* chips salvaged from old kit. There's quite a bit of demand for weird and whacky motherboards out there...especially for lab environments that use expensive old school PCI cards that are difficult to replace...I know, I look after one such lab.
It's not feasible to throw out your expensive lab PCI cards (that often cost thousands of pounds) just because your new suite of PCs can't support them...if you want the latest CPU horsepower and m.2 bells and whistles etc...but you still need PCI, you have to go whacky Chinese...they're often really well made boards as well...they cost a bit more than a typical board...but a lot less than replacing a dozen £10,000 PCI cards.
Have you seen how ARM servers are constructed?
They are extremely modular. The chipset, memory controller and CPU exist on a separate mezzanine board to the motherboard, and sometimes even the RAM...you don't necessarily have to throw out the entire server to upgrade to the next generation. ARM servers will lead to less e-waste if anything.
With x86 servers, you get two generations of upgrade path if you're lucky. If you want to upgrade your kit to speed up internal processes, take advantage of a new instruction set or keep your competitive edge...you're replacing the whole server. With an ARM server, you can keep your backplane, chassis or pretty any component as longer and only upgrade the bits you need to. Extremely modular.
Whilst this isn't a server...it serves the purpose of demonstrating the concept and applies to a lot of ARM servers out there...I just can't find an effective set of images for the servers I've seen.
It still remains to be seen, but it would appear that if a new generation of ARM processors came out, it's entirely reasonable to assume that you can take out the mezzanine board with the CPU, RAM etc on it, and drop in a new one and utilise the existing PCIe slots, storage backplane, chassis, power supplies etc...I could be wrong, but ARM servers seem to be designed for long term maintenance and scale.
Yes, it's always worth testing.
I had a client that uses Amazon for databases (m class MySQL)...and when I ran tests, I found that there was a clear peak in performance at around 8x.large...12x large and beyond were considerably slower...despite having more cores and more RAM.
It was a job that is not unusual for infrastructure guys...a standard "platform is running slowly, devs want to throw more cores and RAM at it, can it be optimised" situation. The devs were arguing that they needed to push to 24x, but after testing I argued that they needed to drop to 8x large to see a performance increase...devs were up in arms about it, "can't possibly be faster" etc etc...so we tested it for a week and it was considerably faster...not fast enough to solve the problem (the problem was IOPS related and required changes to the storage), but fast enough for the devs to take notice and be like "hmm, that's interesting".
The end result was I brought the site response down from 250ms+ to around 30ms and saved around £30k a year in AWS fees....of which, 20% was my "savings bonus" which the client pays off over 12 months...yeah I know, weird financial model...but businesses go for it. Charge them a lower day rate to investigate then a percentage of the first year projected savings...you'd be surprised how much more money you'll make this way...plus regular cash flow. I currently have 5 or 6 clients paying me an average of a few hundred quid a month on tick after saving them money on Amazon.
It is tempting to take the chunk up front, but for things like mortgage applications, they like to see regular income rather than a massive stash of net worth...plus, it's lot less painful for the client to pay off over say 12-24 months than it is to pay a large wad...I also typically throw in some lightweight consultancy for the duration of the payments as well...nothing hands on, just a voice on the phone to get a second opinion from while the devs get to grips with things...everyone wins!
ARM on Windows will never become a thing as there's too much software written for x86. Microsoft has tried it numerous times and every time it falls flat on its face.
For server workloads ARM could become a tour de force since data centers do care about power density since cooling costs are significant.
Windows RT and Windows Mobile (on ARM) failed because even Microsoft could not be eased to compile for ARM - leaving it to wither and die with massive App gaps. I see nothing different this time around.
Apple have not done the same, which is why Apple Silicon is a rip-roaring success.
But Apple's Mac sales are falling precipitously, as I predicted would happen. Compatibility with x86 is vital for some of their MacBook customers, who need to run Windows to serve their customers. If they can't they'll switch over to high-end laptops from other vendors like HP's Z-Book / EliteBook.
I'm predicting we'll hear more about this in coming months / years since it will definitely impact Apple.
Apple had previous experience with Rosetta though...so it was a lot less complicated for them. Technically, all the x86 builds of MacOS had an x86 translation layer involved somewhere...so porting MacOS was probably a lot easier for them because they weren't necessarily going from pure x86 to ARM.
That and Apple only has a very small number of SKUs to account for...Microsoft has a whole legion of hardware manufacturers that need to play ball in order for them to be able to completely port across. Your Dells, HPs and Fujitsus of the world.
You also have to remember that the customer base for Apple is mostly consumer and content production oriented...and the odd wanker of a CEO...Macs have never really been that practical for professional use...yeah you can use them, but you're often better off with Windows or Linux depending on what you do.
It's a lot less common these days for software devs to use a Mac for example...especially outside of "web agency" style businesses...you have your .NET crowed who are hopelessly nailed into Windows, even though they don't have to be...
The folks you tend to see in those trendy open plan shared office spaces that write "code" on Macs, aren't really developers...they're mostly building MVPs and prototypes usually stitching together frameworks and wrapping wrappers around wrappers for wrappers to make microservices out of languages that are essentially wrapped wrappers abstracted from wrappers wrapped around abstraction to wrap wrappers around before pushing their wrapped wrapped wrapped wrapped wrappers to an online app hosting wrapper like Heroku...I call them Onioneers or Aggrebaters....because they make shit hundreds of layers deep just to fuck around with and aggregate other peoples APIs and produce a free ad supported app that they can hype online before embarking on seed funding, a speaking tour etc.
Can we please stop calling it "Apple Silicon"...and call it what it is...a crippled proprietary ARM package...a PAP if you will...an Apple PAP...an Apple PAPintosh...back in the PowerPC era, me and my colleagues would call them a Crapple Naffintosh...because we hated troubleshooting the rubbish unstable network stack...or a Ramble Spamintosh because of the sheer amount of broadcast noise they'd put out on the network flooding various network kit.
Density is less important than the maintenance overhead. ARM servers are relatively straight forward compared to x86 servers....they are also highly modular. It's possible to keep the guts of your server for a looooooong time with an ARM server...because even the CPU socket is socketed, the CPU is installed in a socket on a mezzanine board (which typically has the VRMs on as well)...so if you end up with a power delivery issue, you can replace the mezzanine, but keep the CPU and keep the mainboard...really cheap to maintain and easy.
ARM on Windows will never become a thing as there's too much software written for x86.
They have a fairly good translator. Problems arise with things that load 'extensions' that are CPU specific, but a surprising amount of stuff just works.
Microsoft has tried it numerous times and every time it falls flat on its face.
Have they? I thought they tried it with Win RT in the windows 8 era, and then again with Windows 10?
Since the Windows 10 on ARM stuff though they've been exclusive to Qualcomm, once that restriction expires I would expect there to be more stuff available.
It's not going to be an overnight success, but I'm not sure the change in instruction set is a major barrier any more.
Just like the withholding of Amazon Marketplace traders funds post sale of goods. Some are owed more than £100,000. The AMZN wants to loan you the money at 14% interest rates. Just give the traders the money they are owed FFS.
Do we need any more reasons NOT to buy stuff from Amazon? If you can, go direct.
this is also interesting, and other manufacturers have started doing similar things. The chips are being optimised for the expected tasks and load. That means they might turn in poor general benchmark results, because the bits needed for those are not optimised (or might not even be present), but they will scream when doing the tasks they are designed for, and use less power in the process.
I think this is very interesting and hope more and more companies will start doing this. It makes running standard benchmarks difficult, and futile, because current benchmarks aren't designed around real-world tasks. Maybe we will start seeing more and more specialised benchmarks (AI tasks, Hadoop and various transaction processing benchmarks). When speccing a system, you then look at the chips designed for your workload and look at the relevant benchmarks for doing the type of work you will be doing. Specialisation and optiomisation, instead of a jack of all trades.
As an aside, regarding optimisation, we had a mainframe manufacturer turn up and install a demo machine for us - we were looking to consolidate a fleet of VAX computers with a few mainframes. The rep gave us a tape and said, "here is a FORTRAN benchtest, compile it on the VAX and on our system, then call me in a week, when ours is finished..."
By the time he got back to the office, there was a message for him to call us back, the VAX was finished! It turns out that the mainframe might have been quicker, but the VAX, or at least its compiler, was smarter. The VAX FORTRAN compiler had looked at the code and decided that no input, lots of processing of a huge in-memory array, transformations of the arrays etc, and no output meant that the lots of processing bit in the middle just wasn't needed, it generated a stub program that finished running, before the operator had taken their finger off the return key... The mainframe, on the other hand was using its amazing processing power to prove to the world just how fast it was!
Work smarter, not harder.
task specific hardware is a reasonable idea but you need to be a big spender and even bigger user to warrant spending the money time and staff resources to develop your own custom hardware and software to run on it.
This is exactly the old mainframe approach, the hard part is writing your compilers and optimising your software to gain any advantage your highly optimised hardware can offer
I would bet a fair few beers that there is a lot more to be gained by optimising your existing software for the hardware you currently have than would be gained by porting this newly optimised code to specialist hardware...