POST

I have a bunch of RaspberryPi devices kicking around the house and office. There are some Pi 2s, Pi 3s, and a Pi Zero. I use them for a lot of different things. I just setup a Pi 3 to act as a scanning server for the Fujitsu iX500 ScanSnap that we use to keep a paperless home. There's a Pi 2 running NUT, some cron scripts, and some other admin stuff for my home network. We got a Pi Zero from an Ada Box that we setup to run RetroPie. While interesting, it's not overly complicated stuff. Places like Los Alamos National Labratory use Raspberry Pis for prototyping their large systems.

The versatility of the Raspberry Pi is undeniable. When my colleagues at Particular Software started working on a .NET Core version of NServiceBus I had to know; would NServiceBus run on the Pi? An hour of .NET Core research plus the Learning Transport sample and I had this

Step 2 complete: #NServiceBus running the Learning Transport in Docker on a RaspberryPi3. pic.twitter.com/OixMIjWbCB

— Donald Belcham (@dbelcham) September 1, 2017

The only trick with it was that I had to dotnet publish using the -r linux-arm parameter.

This doesn't seem like much, but it can open up a lot of options for a team developing distributed apps. One of the biggest challenges for those teams is having a non-production environment that mimics the topology of the ultimate solution.. In my experience teams struggle with getting the infrastructure required to properly test. Servers are allocated by a different team. Once setup, the topology is fixed which makes it difficult for the team to experiment and/or adjust their architecture.

Now, what could you do with 8 Raspberry Pis if you were building a distributed system? Well you could have one running a database server (SQL Server, MySQL, and Postgres will all run on ARM hardware), one Pi could run your messaging system (RabbitMQ for example), and the rest could represent nodes for your distributed code. Great, but that's no different than using 8 VMs you say?

Unplug one of the distributed nodes. Just unplug it. Don't shut it down gracefully. With a Pi that's easy, you just reach for the plug and pull. With a VM it's a fair bit harder, and if you can the infrastructure folks will blow a gasket that you just did that to their precious, stable systems. This is really important in a distributed system though. How does your system handle uncontrolled shutdowns? How do you plan your recovery in that scenario? What if you just pull the network cable but leave the power on? How does recovery differ? What do your reporting tools tell you when this happens, and what do they tell you right after the problem is fixed?

There are a lot more moving parts in a distributed system which lead to a lot more disaster prevention and recovery needs. A collection of Raspberry Pis running as a testing or development environment gives you a great platform to simulate many of these situations. They don't allow you to do all your testing though. I'd never pretend that a setup of Pis would be adequate, or appropriate, for load testing a system.

Raspberry Pi is a great platform for prototyping (and more). Don't relegate it to just prototyping things you'd like to play with at home. They can be a huge tool for distributed system development too. Heck, if Los Alamos is using them, why can't you?

Happy Pi Day!