FIWARE & Kubernetes Open Data Platform

UPDATE! configs available in Gitlab

For the past half a year or so we (together with HYPERTEGRITY and omp) have been building a solution for the City of Paderborn. The platform is build on top of provided Kubernetes solution. In this post I want to share the essentials that are used.

Here is an architecture overview:

Simplified component view

The diagram (not all connections are in diagram for clarity) divided in few sections via color coding. Green bit (Main data pipe) first!

Main Data Pipe

The interface to the platform is good ‘ol NGSI-v2. Green path represents the data pipeline. We take in data from IoT Platform via 443 to Umbrella, where it’s routed to Orion Context broker, Mongo DB stores the right time data. From Orion data travels to QuantumLeap vie Orion’s notification mechanism. QuantumLeap stores the historical data to Crate DB. Grafana is used to visualise the Data. Here is an example of data visualisation via Grafana. It shows the parking status in the Domplatz:

City of Paderborn’s Grafana example

Other Components

There are other components with different colors; With respect to the data pipe, Keyrock, API and Tenant management are supporting components and they enable Multi-tenancy. Data access is /Tenant basis, and controlled via Bearer tokens. Knowage has Keyrock integration. Perseo can access OrionĀ“s data via NGSI-v2. Cosmos can be used to do big-data analysis, but they are not actively used at the moment. Kurento is simply deployed, but not configured.

I’ll Tell you more about the other components and security on later posts.

Kubernetes part

Ah the Kubernetes part! Here is another view:

Port view of K8S cluster

This view gives more details on the data flows inside the platform and insight how the Kubernetes part works in all this. Kubernetes provides Persistent volumes and MySQL for Keyrock and Knowage. All this beauty is running on top of Open Stack.

Benefits of K8S, optimisations

We are also scaling QuantumLeap, there are five replicas running now. Running five replicas makes Orion the bottleneck and allows QuantumLeap enough processing capacity. Scaling is dead easy, performance optimisation..not. Kubernetes adds more variables to the play, but again, more on that later.


We have been using Gitlab as CI/CD pipe. All the projects are clonable and then deployable via Gitlab CI/CD pipe. Nice!

Open source all the way

Now, I know you are thinking “I want this too!” no worries! All of this goodness we have created is open sourced! I’ll update the post when it’s available in Gitlab.

Then what?

This deployment is so big and has so many components and features that I decided to split the posts, more will follow. I’ll try to spit out a post at least one/month. Blogs I was thinking about are:
– The other components
– Data intake & Data Models
– The Good, the Bad and the Ugly
– How to make this better

What do you want to hear about next? Write on the comments below or email:

P.S. Sometimes projects do not go smoothly. In this occasion things ran really smooth, even with COVID-19 impose travel restrictions and complications. This is in no small part due to the fluent co-operation between all parties and I’d like to especially give credit how well the City has managed this project. Clear direction, no back and fort, flexibility and pragmatism. Thank you!