Why run insurance on a Raspberry Pi?

Before you read this, I should declare I have a passion for electronics and computing technology, and some of my fondest memories from school inspired me to take up a career in this space – which eventually brought me to the insurance industry. There I programmed an 8086 processor using a simple keypad to enter assembly language instructions for controlling lights, motors and sensors. 

Today you cannot navigate the insurance and InsurTech space without hearing about cloud machine learning, artificial intelligence, web3, the metaverse, APIs and robotic process automation. Luckily with cloud computing it is at the point where most people now accept it as the norm in the insurance industry. This, I tell you, is music to my ears, as I have been evangelising this since 2006.

Yet the insurance industry is still in many ways stuck in old technology. People are struggling to get the basics right. Managing the policy life cycle is inefficient and costs customers a great deal of hard-earned money. People are spending millions on solutions that don’t serve them. And while cloud can be useful, it isn’t the answer to everything.

For those not familiar, cloud consists of using other people’s computer hardware and software before delivering it in the form of computing power, data storage, networking and software services. Cloud offers the illusion of unlimited resources, so long as you are willing to pay for what you use. (A famous emperor from the Dark Side once called this “Unlimited Power!”)

But with unlimited power comes great responsibility. I took this to heart when, in 2020, I announced a challenge involving our newest product to the team at ChainThat. The product in question – a new Policy Administration Software platform (known as Beyond Policy Administration ) – needed to achieve the following from a technical perspective:

  • Run on the cloud

  • Use container technology

  • Offer an API-first approach

  • Be both single- and multi-tenanted when needed

  • Scale from a single user case to the largest enterprise

The final piece of the challenge was that the product needed to be capable of running on a Raspberry Pi. I will explain my reasoning behind this – an explanation my engineering team wanted from me as well. In addition, I will offer important background information on what a Raspberry Pi entails.

What is a Raspberry Pi?

In 2012, after six years of design and prototyping, British engineer Eben Upton launched the first Raspberry Pi.

The Raspberry Pi is a single-board computer on which you can run an operating system – and you can use it just like any other computer! A key difference is the size of the device and the cost of the Raspberry Pi. The original Raspberry Pi concept was designed to inspire the next generation of young computer engineers, and each model cost around $30. Since then, new models and versions have entered the market, with over 40 million devices being sold – educating millions of children in electronics and computing.

Today there are three main types of the Raspberry Pi:


(1) Raspberry Pi Model 4B - Priced at just $35, this model offers a standard shape and size. With a more powerful processor, dual displays (featuring 4K output) and USB-C power supply, the device is software backwards-compatible – meaning whatever you create on a Raspberry Pi 4 will work on older models as well. 

(2) Raspberry Pi Model Zero 2W - Those searching for a tiny $15 computer need look no further. This RP3A0, custom-built, system-in-package solution (designed right here in the UK) is up to five times faster than the original Raspberry Pi Zero. Wireless LAN offers improved RF compliance, providing flexibility in the same small-form factor.

(3) Raspberry Pi PICO - This flexible $4 microcontroller board is tiny, fast, virtual and built using RP2040 – a new and innovative microcontroller chip designed in the UK. Controlling applications and operating light displays are just some of the common use cases. Programmable in MicroPython and C, this model is both flexible and adaptable.

For the purpose of what we are doing for policy administration we focus on the Raspberry PI Model 4B shown below.

Why on earth did we do this at ChainThat?

1.    To attract future generations to our industry.

We are here for the proverbial long game and set out to appeal to young people’s technical talent by offering real-world applications for exactly what they are learning in school. The Raspberry Pi has inspired many of the younger generation to get into computing and electronics. Coupled with the fact that the Raspberry Pi promotes the Python language – one of the most popular coding languages today – we knew this could be a big hit.

 ***If anyone of any age wants to learn programming, I highly recommend grabbing a Raspberry Pi and completing a free online course in Python to master the basics.***

2.   To do our part in addressing climate change.

Climate change is at the top of everyone’s list of priorities, yet we tend to forget how much our IT and cloud-based systems contribute to the problem. The Raspberry Pi, however, uses very low power. I am a big supporter of cloud in theory but not for every application. Consequently, I wanted to show the team the potential impact of the Raspberry Pi – even if it only helped us to pay more attention to the way we create cloud applications.

3.    To show our customers that we can run the same exact software stack on a Raspberry Pi.

Many vendors talk about being cloud-agnostic, but if push came to shove, they would need further development. At ChainThat, we wanted to reassure our customers that we can not only demonstrate our solutions on the likes of Azure, AWS, Oracle and IBM, but also on the Raspberry Pi. This is important because we work in a risk-adverse industry, and everyone wants assurance that in the event of a global cloud outage – in the event of a vendor going under, or a software escrow trigger kicking in – they can continue running their system and maintaining their technology. Because if you can run it on a Raspberry Pi, you can run it pretty much anywhere else.

4.    To keep things efficient and to encourage best practices within our team. 

When designing new applications, it’s easy for our engineers and developers to get carried away with the latest and greatest software solutions. Cloud removes restrictions on what you have access to, but we wanted to ensure we use the right technology for the right products – each and every time. Imposing physical restrictions from the Raspberry Pi, including those involving CPU and memory, helped our engineers to think more efficiently and create higher-quality outputs. After all, good engineering practices lead to great long-term applications.

5.    To simplify complex business problems.

The Raspberry Pi ecosystem is rooted in teaching – and there is a lot we engineers and technologists forget about when it comes to simplifying complex problems. To teach young children programming, open-source visual tools make the process much easier. Likewise, in the insurance industry, we have many complex problems, models and different ways in which we need to interact with data and process. This allows us to draw inspiration from the way we teach children today, applying what we learn to some of our most complex user experiences for creating rating models!

6.    To rely on something tangible.

There is something very satisfying about being able to hold a computer server right in the palm of your hand, turning to the customer and saying, “This is your system.” When someone asks to see their data, you can point to a micro SD card or USB stick and simply hand it to them. This is a great way to give both clients and internal teams a grounded perspective on things of which the virtual cloud has abstracted us.  

The challenge was set during lockdown.

In 2021, we set the task was to take our Beyond Policy Administration architecture and ensure it would run on the Raspberry Pi. As much as I love this type of project myself, it was a group of volunteers from our DevOps team (pictured below) who rose to the challenge – on top of their normal innovation and delivery roles – getting us up, running and supported on the Raspberry Pi.

As with all the challenges I set for the team, we ultimately had to challenge the challenge! While we could have put our system on a single Raspberry Pi computer, we had to consider redundancy, availability and security. Of course we had to take these items seriously. Surely they would be questioned by anyone to whom we showed our new and improved solution?

During lockdown, I volunteered the use of my home office to host the Raspberry Pi, which allowed me to play datacentre engineer (in case we needed to move cables, power things down, etc.). The advantage of this was that the device could easily fit on the top shelf at my home desk (see picture below). Internet connection was achieved over my home internet; all we had to do was provide the secure remote access. The team was based in various locations across India, while I located the Raspberry Pi’s in Twickenham (UK). 

In the end we set up a three-node cluster of Raspberry Pis. (Please note that one of those pictured below was not used.) Each Raspberry Pi had a Power over Ethernet (PoE) hat, which meant we could power them from a small 1Gb Ethernet switch without the need for a separate power supply. This also provided a 1Gb network over which each Raspberry Pi could communicate. One Raspberry Pi had the ability to run all the software, but by using three nodes, we mitigated redundancy and failover, supporting any two of the three nodes failing while still being able to provide the application.

Each Raspberry Pi had a wireless connection to my home internet for external access as needed (ingress or inbound requests for SSH and secure web browser access) – controlled by port forwarding on the home broadband route. To support the resilience and availability storage, external USB 3 sticks were used to host a shared file system. For backups, we connected one node with a high-capacity external SSD drive.

To support the platform, we used the following software to support the cluster on each Raspberry Pi:

  • Ubuntu Operating System

  • GlusterFS for shared storage

  • Docker for our application containers

  • Kubernetes K3s (container management)

  • Postgres Database

  • Nginx Ingress controller

  • Prometheus and Grafana for monitoring

While the team had a few challenges selecting the right version of the software, it did not take long before the solution was up and running. Finally, we could deploy our full Policy Administration Software (PAS). 

I am fairly certain this was an industry first: a Raspberry Pi-run insurance PAS platform!

After testing the system to set up and process submissions, it showed that we needed less than 8GB of the total 24GB memory across the three Raspberry Pis (this was storage that could fit on a single 8GB Raspberry Pi) and approximately 2.3 CPU cores out of the 12 total (each Raspberry Pi has 4 cores). We’re pleased to say we achieved this without any tuning. In addition, these figures included the Grafana and Prometheus monitoring solution, which also used a portion of the CPU and memory.

The below screenshot shows the performance metrics when all the cluster’s services are running on a single Raspberry Pi. This, mind you, was all while processing submissions throughout the day as a logged-in user.

We carried out the final tests to ensure we could access the application via a secure web browser session on laptop or mobile phone. The response time proved impressive even with all services running on a single Raspberry Pi.

“Scotty, we need more power!”

To that one might say, “Sorry captain, no we don’t.” Because while comparing the power usage of the Raspberry Pi setup to a cloud service can be challenging (considering matters such as ancillary equipment, cooling, etc.), we did attach a power meter to the main socket to measure consumption while in operation (all the power was drawn through the PoE switch). While running on a single Raspberry Pi, usage peaked at 5.5 Watts; the three-node setup, conversely, featured an increased workload (number of users) and peaked at 23 Watts. To put that in context, a typical LED light bulb used at home ranges from 4 to 22 Watts.

So what the team has achieved is the effect of running a insurance policy administration system on the power needed for a single home LED light bulb. Not bad at all!

Ultimately, I must restate that we still use cloud services when working with our customers. With the team’s effort, however, we have proved the art of the possible. I am confident that you too can can run a modern, future-proofed Policy Administration Software system on a single Raspberry Pi.

Previous
Previous

Global Programs: Direct Network Partnership with Lead Insurer Strengthened Using Technology

Next
Next

Emily Asks - Andre Hardie on BPA and the benefits for brokers