How a Hackathon COVID-19 App Was Ported to OpenShift – InApps Technology 2022

Red Hat sponsored this post.

Software developers can go fast when properly motivated, and what better motivation than helping millions of people deal with the COVID-19 crisis? It didn’t take long for programmers around the world to try and help out. Hackathons to build software for the on-going viral outbreak kicked off as early as March 22, with Hack-the-Crisis — which broke the competitions down by country.

In Finland, an initial team of Otto Kekäläinen, Matias Huhta, Tuuli Elonen and Olli Savisaari took on the challenge of implementing some form of testing, however rudimentary, to phones around the world. But building out their mobile application and server architecture was only half the battle; the other half required Red Hat OpenShift. Scaling from a small number of users to millions overnight takes planning and Linux containers, because even the simplest of applications can become complex when it also has to deal with privacy, geolocation and real-time data.

FeverMap was a privacy-aware application designed to help track a user’s temperature and to aggregate that data to help track the transmission of COVID-19. Knowing how many fevers there are in a given region is a good and reliable data point for decision-makers.

Through a simple dialog box, the user could submit their current temperature with a slider bar. The application also collected typical symptoms of COVID-19 and some anonymized personal data, such as age range and gender.

FeverMap was one of the submissions picked to go on to actual existence in the real world, with development continuing after the hackathon. However, that meant bringing a lot more scale and collaborators into the project.

For example, since its launch, the FeverMap app was translated into 22 languages. The app was capable of tracking users around the globe. It’s hard for countries to test all of their citizens, and a significant number around the world remain uncounted at all. FeverMap was a lightweight solution to get an indication of spread immediately. Information is important, for example when making decisions on when to open a closed society and businesses.

Ilkka Tengvall, lead solution architect in Finland for Red Hat, saw Kekäläinen’s tweet about FeverMap right after the initial hack weekend. He thought it was a great initiative and started contributing in his free time. He also asked his colleague Tero Ahonen to join. They requested support from Red Hat. Red Hat agreed to sponsor the application as a corporate patron.

Said Tengvall, “When I first took a look at the project, I saw that it was done using Docker images. I thought, ‘oh this will be trivial to put into Kubernetes, and automate the entire build process, and help get updates and releases out into production more rapidly, as well as aid the collaboration process.’”

To that end, Tengvall and Ahonen helped the team deploy their app onto OpenShift in a manner that would allow for quickly scaling to global size, while enabling the distributed development team to update and adjust the application. This last part required an automated, open hybrid, cloud-based build and deployment process.

“So out of curiosity, I started hacking on it at home to see if we could deploy and host it on OpenShift,” said Tengvall. “It seemed to be rather easy; and then I thought we needed to write up some instructions, and ended up putting it into my own demo and instance. So then we set up the project on OpenShift Online and after quite a few nights of effort, FeverMap had a fully automated build process. It’s now done by taking the containers a bit forward into OpenShift, building, making them run there, and getting monitored and autoscaled.”

“The FeverMap application was a nice architecture to begin with. It’s a simple and small architecture consisting of three containers and a database. There is the front end web application, API container, push notifications API and then the MariaDB database. I put that very same setup which is documented here in the GitLab templates.

“So it’s now set up on OpenShift Online in such a way that there is one single MariaDB, and then there is an autoscaler for the API and the application container. If there is more traffic, the front-end and the API would scale. Otto told us that the database is going to be the bottleneck if any, so once the data submission rate grows, it will be trivial for us to move the data into the MariaDB cloud service, change the address and the data will flow there. This is all open source, and potential organizations can run these components as they want. They can have their own database instances and do it as they wish, so they are not depending on MariaDB Cloud or Openshift Online,” said Tengvall.

That flexibility is the key to the open hybrid cloud. While it enables developers to take advantage of cloud-based services, build and deploy pipelines, and the GitOps way of working, it’s also open enough to allow for customized solutions to unique problems — such as wanting to bring a third-party service into your own hosting environment.

Image credit: Olli Savisaari

Tengvall says, “FeverMap is an example of how a spontaneous idea could become a very timely and professional solution to real-world problems. It also shows how organizations don’t often understand the benefits of open source. Unfortunately, no organization in the world went to production with the solution. However, millions are budgeted to create COVID-19 tracking apps in different places.”

While FeverMap is no longer in development (it was closed in July), it was a testament to how quickly global-scale applications can be designed, deployed and modified. The project may now be dormant, but it is possible the team will start back up working on it in the future, if another project finds it useful to build upon this open source code. There have been different kinds of use cases proposed for future use — like using it for data gathering for academic studies, or monitoring busy public transport routes. It’s a very good base for creating any such variation from quality code and an automated base.

Feature image via Pixabay.

At this time, InApps Technology does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: [email protected].

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.