Can you run a casino for less than $100?

At Yolted, we love experimenting.

Running hack days and trying something different is part of Yolted’s DNA.

One recent topic for one of these hack days was ARM and how we can use it, and we feel the result of this is worth sharing.

The ARM architecture is nothing new. It has been around for decades, but with the growth in popularity of Rasberry PI’s for home use and, more recently, the introductions of Apple’s M1 and M2 ARM-based chips, it is clear that it has a strong future.

Even ARM-based hosting is becoming more and more available.

One of the significant advantages of ARM vs Intel x86/x64 servers is the considerable difference in power consumption.

This translates into the PC market; for example, a new Mac Studio can draw as little as 16% of the power drawn by an equally specced PC running an Intel or AMD CPU.

So naturally, this is attractive to anyone facing skyrocketing electricity prices.

So what did we need to do to get this working-?

1. Get our RGS (Remote Gaming System) and all supporting services to compile and run for ARM.
2. Package it in ARM Containers.
3. Run it on ARM container runtime.
4. Push it to the limit!

Get our RGS and all supporting services to Compile for ARM.

A significant advantage of having a Modern platform built on a modern tech stack is that you get a lot of things for free. Moreover, if your architecture and code follow best practices, this can also be quickly applied.

For us, this step was as simple as compiling the arm runtime. That’s it. Not a single code change was needed.

We did not expect that, and it’s nice to see applying good groundwork and putting in the extra effort early in our product development pays off.

Package it for ARM Containers turned out to be equally trivial.

Run it on ARM container runtime

This is where the fun starts. We decided that the proper way of tackling this is to go as low as we can.

So we bought 3x Rasberry PI 4’s and deployed a K3s cluster.

Thanks to the Rasberry PI community’s hard work, there are many guides on this.

One we based our setup can be found in this (https://bryanbende.com/development/2021/05/07/k3s-raspberry-pi-initial-setup) excellent blog post by Bryan Bende.

3x nodes, one control-plane.

We were delighted to learn that all our existing Kubernetes deployment tools (Workloads, Services etc.) were usable without almost any changes.

It only required some minor tweaking for storage.

We could use the same helm script we created for our deployments on Amazon EKS, Azure and GKE.

 

All services deployed running 3x of each (1 replica on each node). Note CPU usage shows 0.5 of 4 (4 cores).

Push it to the limit

We then proceeded to deploy our trusted Gambler bots. Built to make even the most overkill setup fall to its knees.

We use these bots to test new deployments and generate performance baselines on every release.

This is a great tool to continuously see how performance is impacted as we add new features to the RGS.

We were able to achieve roughly 5000 rounds per second. Which is not too bad and considerably better than expected.

The significant bottleneck is disk IO. Rasberry’s SD cards are only good to boot from and fold under any load.

What did we learn?

The experiment gave us 4 tickets on where we see potential bottlenecks in performance.

These are mainly related to persistence.

We currently have a very cautious approach to ensure all game rounds are always in a recoverable state, no matter what happens.

Events such as a complete power loss or database going offline should not result in any loss of data or a situation where a player sees results that are not persistent.

Will we run Rasberry PI in production?

No, of course not.

But we aim to deploy future sites on ARM-based hosting; we might even migrate fully if it makes economic sense.

What can we use this for?

My favourite application for this is to learn and to help our developers and tech staff fully understand the concept of clusters and distributed computing.

It’s cheap and easy for them to set up and take apart.