Interesting as it seemed that smarter edge/iot nodes would be like ARM/RaspPi, yet it seems it may get even as high as (or just straight to) Intel nuc.
This is Brian -- I wrote the article. For what its worth, we considered trying to run our clusters on an array of cell phones since they would natively support connectivity fallback and pack a real effecient resource punch in a small footprint. One of our engineers came up with that idea. With the challenges compiling on ARM and the relative ease of moving forward with x86, we went that way to start. We tried really hard to balance the "ideal" with the short term "MVP", and I think we landed in a decent spot with the NUCs. They give us enough power to run the things we need in the short term, and we have some capacity for horizontal scale in the future as our needs increase. We tried to think "cloud native" at the edge as much as we could without truly being a cloud.
Raspi cannot be used for a semi serious server application due to microsd card write wear issues. All other methods of attaching external storage by USB bus to an rpi are not reliable or suitable for this sort of purpose. Nowhere near the longevity of something with a native sata or m.2 SSD interface and a real SSD.
There's also the added complication of the fact it's an ARM based device so in some cases you might run into compatability issues, or testing your container locally becomes problematic.
"Raspi cannot be used for a semi serious server application due to microsd card write wear issues."
As an end user, I run a personal authoritative DNS server that has small RAM requirements. The RPi (or other SBC) boots to a mfs mounted root, then mounts all directories as tmpfs. Then I remove the SD card.1 As such, the logs for this server, which are automatically rotated and do not exceed 5M in total, are written to RAM.
1 I only use the SD card to boot. The only files on the card are a bootloader, a bootloader config and two kernels, each with an embedded filesystem. If updates are necessary, I make them to one of the kernels at a time. The other is the backup. The bootloader and bootloader config lets me specify which kernel to boot.
Don't most modern SD cards contain some wear leveling logic?
I did a bunch of research on this a while back and the conclusion I found was: yes, but buy name-brand better rated cards to avoid cheapo cards that do not do wear leveling or do it very badly.
It's nowhere near as good as SSD drives, but it's better than just a naked flash chip... unless I'm wrong.
Hey if you see this can you answer one more question:
How much abuse was your high availability product delivering to these cards in terms of writes? Was it something like a video recorder, database, cryptocurrency, or some other application that did large amounts of write I/O?
I ask because we're about to ship something that uses SD cards, but the I/O is very low. It's a network appliance and doesn't do anything locally that is high write throughput.
The Linux kernel in raspbian treats the SD card like a normal block device. I'm not aware of any special optimization for write wear leveling at the OS level, or on the board's sd card controller.
SD card wear-levelling is usually supposed to be handled on the controller inside the SD card. SD cards aren't like having raw access to flash, you basically write over SPI and the controller in the SD card decides where to actually put it.
This talk about SD cards is really great and explains some of this:
Working with RaspPi and Docker has been surprisingly difficult. Docker's support for multi-arch is poor at this point, and also applications that are I/O heavy seem to bottleneck at the network.
