FireServiceRota, founded in 2006, specializes in software for emergency services in Europe. The company, which currently serves over 1,000 fire stations, aims to create a flexible solution using open source technologies and Linode infrastructure to reimagine the way scheduling and alerts work for fire services.

“We check the whole process from them being available and ensuring that there is enough resources, skilled people, to the actual alerts and ensuring that sufficient people are at the fire station to actually respond to the incident,” says Ruben Stranders, Co-Founder and CTO of FireServiceRota, on this episode of TFiR Let’s Talk.

Key highlights of this video interview are:

• Stranders explains the complexities of scheduling and coordination for retained or voluntary firefighters.
• He explains how their FireServiceRota tools work to ensure there are enough skilled firefighters on-hand to respond to incidents and protect the community.
• FireServiceRota has several APIs to integrate with the command and control system. They use Kubernetes hosted at Linode due to its scalability and the ability to backup in different data centers ensuring the resilience of these systems. Stranders discusses in further detail the technologies behind their systems.
• Stranders explains how the automation works with FireServiceRota and what areas require some manual input and why.
• Low latency is important for FireServiceRota when first responders need to receive alerts in a matter of seconds. Stranders discusses the infrastructure behind FireServiceRota and how it is achieving this.
• Although on-premises installed software has its benefits, FireServiceRota works entirely off as-a-service model. Stranders discusses the benefit of running the one version which is used by all their customers in Europe rather than customers having to install and maintain installed software.
• As disaster can be a challenging area to provide solutions for, Stranders goes into depth about the complexities they face and how their systems and services are built to tackle these. He explains how their in-built safety net of 5,000 checks enables them to take risks without putting the systems at risk.
• Stranders explains how fire services are evolving in order to serve their communities more effectively, and some of the newer technologies now being used more widely.
• FireServiceRota finds that their exclusive focus on firefighting helps them gain a deep understanding of the needs of fire services with scheduling and alerting. Stranders details a use case of one of their customers and how they have helped transition from an old rigid duty system to a more flexible one.

Guest: Ruben Stranders (LinkedIn)
Company: FireServiceRota (Twitter) | Linode (Twitter)
Show: Let’s Talk 
Keywords: Solutions for Firefighters

About Ruben Stranders: Dr. Ruben Stranders is a co-founder of FireServiceRota, which specializes in planning and dispatching software for emergency services. Ruben teaches AI at Tec de Monterrey, and also builds crypto trading bots using AI. He studied Computer Science at Delft University of Technology and holds a Ph.D. in AI from the University of Southampton.

About FireServiceRota: FireServiceRota is a powerful and flexible planning and scheduling system for fire brigades.

The summary of the show is written by Emily Nicholls.

[expander_maker]

Here is the automated and unedited transcript of the recording. Please note that the transcript has not been edited or reviewed. 

Swapnil Bhartiya: Hi, this is your host Swapnil Bhartiya and welcome to TFiR Let’s Talk. Today we have with us Ruben Stranders, co-founder and CTO of FireServiceRota. Ruben it’st’s great to have you on the show.

Ruben Stranders: Thank you very much for having me Swapnil.

Swapnil Bhartiya: I would love to know a bit more about what is FireServiceRota all about? Since you are a co-founder, so also tell me why you co-created the company.

Ruben Stranders: That’s a very interesting and quite long question, so I’m going to summarize it just a little bit. So FireServiceRota is a company that specializes in software for emergency services, mainly firefighters in Europe. And our focus is on scheduling. On one side, so planning resources and the other side is alerting. So we alert as soon as there is an incident, make sure that all resources are mobilized and do some additional checks.

We founded the company or the company was founded in 2006 by a good friend of my mine, Cor Klaasse Bos, we met in high school and a firefighter. And a number of years later in 2013, I joined after completing my PhD, wanting to go into industry, becoming an entrepreneur. And since then we basically broke clean with the old version, which was written in PHP, built everything from scratch. And yeah, now we are in multiple countries in Europe serving over 1000 fire stations.

Swapnil Bhartiya: We don’t much know about how does the backend services look like that are used by fire services. Can you help us understand it a bit What backend processes of the fire service look like?

Ruben Stranders: So firefighters, and mainly in Europe work on a retained or voluntary basis. About 80% of all firefighters in the Netherlands and about 30% in the UK, and I think in the US even a larger percentages are retained or voluntary, which means that they have normal jobs like you and me, but carry an alerting device, could be smartphone in our case or a pager. And that’s sounds as soon as there is an alert. At that point, they drop everything that they’re doing, go to the fire station. Legally, they have to be there within about five minutes, and there they depart to the scene of the incident.

So before that happens, especially in case of retained firefighters, there’s a lot of coordination and scheduling going on. And a voluntary firefighter by nature can make themselves available and unavailable throughout the day, depending on their work and family commitments. And because of that, there is quite a complex coordination or an organic coordination problem whereby they need to make sure as a team that they have sufficiently skilled people, for example, a commander, a driver and a couple of firefighters, in order to respond to any type of incidents and to protect their communities.

So we give them the tools to understand when and where they’re necessary and also vice versa when they are not necessary and can take some time off, spend some time with family, focus on work commitments, et cetera, et cetera. So as soon as there is an incident, we look at their availability, check. If we have enough people, start alerting them via a smartphone or smart pager, two-way pagers and request they confirm their attendance. And that triggers a whole business process of making sure that their ETA is tracked, that there are enough people responding, but also if that’s not the case, that we start escalating the alerts and calling in additional resources.

So we check the whole process from them being available and ensuring that there is enough resources, skilled people, to the actual alerts and ensuring that sufficient people are at the fire station to actually respond to the incident.

Swapnil Bhartiya: Can you explain a bit in detail how does the technology works to help with the process that you just explained?

Ruben Stranders: Yeah. So on a more technical level, we have several APIs to integrate with command and control system. So they would deliver an API call with some redundancies and retries if necessary, to ensure that the incident record is correctly created in our system. We use Kubernetes, we’re hosted at Linode, this is for us highly scalable, auto scaling, also backups in different data centers so we can ensure the resilience of these systems. And as soon as the API call comes in, it is routed through a so-called alerting policy. So different fire stations might have different type of alerting policy. One of the more interesting ones would be what we call demand-based mobilizing.

So we look at the minimum set of users that could satisfy the requirements of an incident. For example, we need one commander, a driver, and a few firefighters, look at who’s currently available within the system, so that is a call towards the planning and scheduling subsystem, which returns the set of currently available users. And then what demand based mobilizing does is intelligently select the people that can satisfy the minimum requirements.

That can also be based on fairness. So we take into account how long it is, was ago that certain users were called out. And this is like a little bit of AI. We do constrained optimization there and ensuring that we call out a crew that can respond to the actual incident, but also a crew that is fair to ensure motivation. These people are volunteers, they want to protect their communities, and they want to get the opportunity to respond to incidents.

So as soon as the crew has been selected, that is then passed on to a separate subsystem, which then starts alerting through voice calls. We use Twilio for this. It can be smart phones, it can be SMS. It can also be API calls or web soaked API calls to other systems that are subscribed to these incidents. And it can also be through smart pagers. So those are dedicated alerting devices.

Swapnil Bhartiya: So how much of this is automated vs manually trying to page to someone who may not be available for any reason – like their car broke or some other emergency at work or home?

Ruben Stranders: it is fully automated. It requires obviously some manual data input, and that is the schedule. So we have smart smartphone apps where users can easily mark themselves available or unavailable. They can plan their availability in the future. They can see whether they’re needed or say, “No, actually, no, I’m going to book off. I’m going to make myself unavailable, go to a party, drink some beers.” These are firefighters, so they need to stay on the alcohol limit. And it’s very important for them to have to balance this flexibility with their responsibilities towards the fire service, but also their home and work life. So that is a part that is manual.

But the whole part of the alerting through an API call, all the way to selecting the users who are going to be alerted, to collecting their responses and then escalating to other users if responses don’t arrive on time, or people reject for various reasons, car breaking down, et cetera, et cetera, that whole process is fully automated. It works 24/7, 365 days a year. And it’s also monitored. The health is monitored by our DevOps team 24/7.

Swapnil Bhartiya: Now I have a very good understanding of how the whole process works. Now let’s talk about the infrastructure side of it – where does it run?

Ruben Stranders: Right now, it runs centralized in a cloud. So we are using the London and Frank for data centers of Linode and that gives us good latency. So we’re not seeing any issues in that sense. Generally from the time that we receive an API call until the first responders are alerted via push notification or voice call, this is a matter of seconds, so 2, 3, 4 seconds. In terms of other technology we use, as I mentioned before, Twilio for placing voice call and SMS. We heavily leverage Kubernetes. We use Prometheus and Grafana Opsgenie for measuring, for recording metrics, for alerting, and then also actually calling out our DevOps team should that be necessary. Usually it’s more preemptive then that we actually have outages.

Swapnil Bhartiya: What is the product or service called? What are it’s core components?

Ruben Stranders:  Our service is called the same way as our company is called, it’s called FireServiceRota. So it involves all these components that I just mentioned. we have a very strong preference to the so far as-a-service model and all our services are indeed so far as-a-service. So we run one version in one or multiple data centers. And that is one version that is used by all our customers across Europe. We do not use any on-premise installed software, and this has many, many different advantages for us. So we have one version that we need to maintain. We have one or more sets of service that we have to maintain, but it is fully under our control. And this also allows very quick and easy onboarding for our customers, without them having to install or maintain and invest in IT.

Swapnil Bhartiya: This is a challenging areas itself as if some disaster happen there will be a flood of calls and it’s a challenge to keep the system running and scale. So can you talk about what challenges are there and what are the core technologies that you heavily rely on?

Ruben Stranders: I think there’s two answers to that question. First is, what allows us to quickly ship features to our customers. And the second is, how do we keep the system running? How do we deliver the services? I think in terms of our development strategy, we are a heavily agile based. So everything that can be automated, be it units test, performance tests, security tests, et cetera, is automated. We use GitOps Flux. So as soon as we make any changes to configuration, that configuration change is made in a Gits repository rather than directly onto a system. So that make it auditable, trackable and can also be easily reverted. This is fully automated process, so as soon as something is merged into master, it goes through the process of continuous integration and continuous deployment, which is then tracked, monitored and measured.

And I think this is really important for us to be able to innovate and also take risks, right? So it is probably the opposite of what our customers wants, to be exposed to risks, but all these checks, and we have about 5,000 of them, allow us to take risks, knowing that if we make a mistake anywhere in the process and given the complex product that we have, that is very likely to happen. We know that one of those 5,000 checks will warn us against, “Hey, you’re making a change that could negatively affect this piece of functionality.” And these are very detailed since our customers can have various, different ways of working. So that allows us to really innovate, work fast, knowing that we have a safety net.

In terms of delivering the service to our customers, yes, so as I mentioned before, we leverage Kubernetes. This allows us to very quickly scale, have our infrastructure as codes, quickly boot up new Kubernetes clusters if needed for staging, for production, for very dedicated, specific customers, if needed. For example, for our alerting infrastructure. And then also monitor it accurately 24/7 with deep, detailed application specific metrics that our team needs in order to bring this service to our firefighting customers who rely on us 24/7.

Swapnil Bhartiya: Fire services have been around for centuries. What kind of evolution have you seen and continue to see to help these services serve their communities even more effectively?

Ruben Stranders: That’s a very interesting question. I think there’s a lot of things going on within firefighting. And so I’m not a firefighter, we have several firefighters on the team who perhaps would be better suited to answer this question in terms of the actual equipment they take to the frontline. But we have heard of different companies who are starting to work with drones. Drones that are automatically dispatched or mounted on top of fire trucks, and then are launched as soon as they get close to the scene of the incident, to provide situational awareness.

We see more and more the use of, for example, Raspberry Pis to open and close doors, gates automatically, as soon as an alert comes in to make sure that the fire station is as ready as it possibly can be, for the firefighters to arrive and to quickly depart.

And we ourselves have also gone through an evolution and sometimes even couple of revolutionary steps in our technology. We started off with PHP, mySQL, which was run on a server that was owned by us and a co-located in a data center, to now having basically throw away Kubernetes clusters as soon as we need them, being able to scale them up and down on demands, and making sure that we have the capacity to serve our customers also in moments of higher traffic, for example, New Year’s Eve with fireworks, et cetera, et cetera.

Swapnil Bhartiya: Are there other areas or use-cases where your technologies can be used or this is the only focus you have at the moment?

Ruben Stranders: We have been looking into other branches or other areas of service, specifically still within emergency services. But what we find is that our exclusive focus on firefighting is also a strong benefit. We are focusing on a niche, which means that we are not only a technology company, but have also gathered deep understanding and knowledge about different ways to schedule, different ways to use resources, different ways of alerting. And our team, and I would like to specifically mention our customer success team, has now very deep knowledge to support and to consult our customers in finding better ways of getting their services to their communities and protecting their services better.

I think one of the nicer examples of that is we had a customer who switched from a fairly rigid duty system where users would be available during the night, during the day, and then have a couple of days off, it’s called a 224 system, to something a lot more flexible where they could have the option of self-schedule their duties based on demand. And this allowed them to free up a lot of administrative resources and move them to the front line. So we have many of these stories where our expertise, not only on a technological level, but also in scheduling, planning and alerting really helped our customers to create a better and safer world for their communities.

Swapnil Bhartiya: Ruben, thank you so much for taking time out today, and share with us this side of the story of our heroes and I would love to have you again on the show. Thank you for the great service you are doing by serving the firefighting community. Thank you.

Ruben Stranders: Thank you very much for your insightful questions, Swapnil. And I always love to talk about what we do. We are very passionate about serving those who serve others.

[/expander_maker]