Edge computing - A story of buses, IoT, and API gateways

The IoT industry has been running for some years now adding millions of devices into the network. The range of devices and capabilities is very wide and heterogeneous, from small devices powered with a 9-volt battery to track the location of freight shippings traveling the oceans (using platforms like Sigfox) to permanently plugged devices with more powerful computing like a Raspberry Pi where computation cycles are not a problem.

Generally speaking, all these devices collect raw data and send it to the cloud where big data centers process it. In some cases it will trigger events back in the devices that are subscribed to a service. All devices are pretty dumb as they are quite passive and don’t process much data, they just send raw data and some even wait for a single service to provide feedback (the smartest devices) and trigger some action.

The Edge Computing philosophy tries to change this paradigm by making IoT devices more autonomous and put under their umbrella logic that was before in the cloud.

Disclaimer

We are not not in the business of IoT, robotics, or the automotive industry. I am going to deliberately skip the difficult part of making the sensors work. The implementation of the following story requires qualified people manipulating the devices. Do not attempt to run a bus full of children with our gateway in your own neighborhood.

A fleet of buses running Raspberries

Let’s picture a fictional situation and a transportation company, Foggy Whale Bus Inc, which fleets several buses in your local city. Each one of these expensive vehicles are able to automatically collect several metrics thanks to its different sensors, devices and internally installed Raspberry Pi.

Examples of the bus capabilities are:

• Knowing vehicle status: Power/fuel levels, emissions, hours of service, assigned driver, average speed, tire pressure…
• Reporting service status: Location, stops, remaining capacity, idle time, timing…
• Firing events to the central : Crash, breakdown, driver sickness…
• Receive external data: Traffic service, weather conditions… and of course data from Foggy Whale Bus central.

All the devices’ data is orchestrated by the Raspberry Pi installed inside the bus. The Raspberry possesses a special software to track the devices, and each device has a different system to report it, like low-range networks (bluetooth, IR, wifi…) or direct wiring. The software that makes the data ready for KrakenD could be something similar to eywa. The Pi also provides connectivity to the Internet via the attached 4G/LTE/3G/HSPA module.

As we want to make the fleet manager happy we offer her a centralized dashboard on premises where we give an unified way to read data from all the buses at once, in real time. In all, this is the idea:

Placing KrakenD in every bus offers an HTTP API that is accessible via Internet from Foggy Whale Bus Inc premises. KrakenD makes sure the authentication token passed is valid and the request comes from a trusted source. It also decorates and complements the existing data by offering a nice way of representing it a more convenient way, and provides a communication mechanism from and to the central by exposing endpoints. An endpoint that is worth mentioning is the /health, that reveals problems with the bus.

At the same time, the central has another KrakenD that is used to query all buses at the same time and is able to reveal aggregated data in an efficient manner. The KrakenD in the central has another /health endpoint, only that this is the “health of the healths” and quickly allows to find problems in the fleet and take action with the data (send another bus, notify passengers, etc).

The installation of KrakenD in the central responsible of getting data from all the buses is a regular KrakenD installation and is not worth mentioning in this context. The installation in the Raspberry is more relevant to this post, so let’s see how to do it.

Installing KrakenD on the Raspberry (bus)

Now with the pictures clear, let’s install KrakenD on the Raspberry, which is the easy part. The Raspberry comes with a small 4-core processor built with the ARM architecture. Fortunately KrakenD is coded in Go so it can be compiled in multiple architectures like amd64, 386, arm, arm64, s390x or ppc64le. Go is also a language that powers frameworks for robotics, such as Gobot.

Step 1: Install go

Since today we are not distributing binaries for Raspberry, we will need to compile the code, which isn’t a great deal. The only needed tool to compile the code is to have Go. The easiest way to install Go is to download and decompress it. We are doing it in the /tmp/go folder but you might want to choose a different location if you want to use go permanently.

cd /tmp
wget https://storage.googleapis.com/golang/go1.10.linux-armv6l.tar.gz
tar xvf go1.10.linux-armv6l.tar.gz

Now add go in the $PATH var:

PATH=$PATH:/tmp/go/bin
GOPATH=$(go env GOPATH)
PATH=$PATH:$GOPATH/bin/

Now typing go should work.

Step 2: Compile KrakenD for ARM

The following commands will compile KrakenD for your raspberry. All needed dependencies will be installed via dep which is a Go dependency management tool. You only need to type the following:

go install github.com/golang/dep/cmd/dep
mkdir -p $GOPATH/src/github.com/krakend/
cd $GOPATH/src/github.com/krakend/
git clone https://github.com/krakend/krakend-ce.git
cd krakend-ce/
make

After make has finished you’ll have a new file in the directory named krakend. This file along with your own krakend.json is all you really need, so you can delete everything else and just copy these file in all the devices without installing go or anything. To run KrakenD in debug mode run:

./krakend run -c krakend.json -d -p 8000 > /dev/null

Now KrakenD is running in port :8000 and will gather all the needed information when accessing its endpoints. Through the KrakenDesigner it is possible to create the gateway configuration using a visual tool instead of manually editing the configuration file.

When the service runs you should see something similar to this:

Benchmarking the Raspberry

Although the bus shouldn’t be receiving a lot of queries because is meant to be used only from the central, it is a service exposed to the Internet and is always interesting to know what are the limits of this setup. Running KrakenD on a Raspberry PI 2 Model B (year 2015) gave us more than 700 requests per second which will suffice the requirements.

The tool we always use to generate load is hey:

100 concurrent requests:

1000 concurrent requests:

As per the resource consumption, nothing unexpected. We put the hardware close to its limits and the CPU usage was intensive. The raspberry has 4 cores but still we had some margin to grow, although the performance didn’t get better.

Summary

We have shown practical information on how an API Gateway can be compiled and placed in clients’ side as a tool to facilitate data gathering and API interaction. Our fictional company has now a connected fleet of buses that provide an API with their status and facilitate their management. We used this example of the Foggy Whale Bus company to show a less obvious use of API Gateways in the daily life, and now is able to serve +700 requests per second on a $30 hardware inside every bus.

Building the software in Go gave us the ability to run our application in multiple architectures and scenarios, such as in Raspberry for IoT. The use cases where an API Gateway can be helpful are open to imagination, but we gave you some materials to explore out of the most common ones. Just remember that unless other products, KrakenD can speak several protocols and can communicate with different transport layers (there is a life out of HTTP!) and can be used to create useful APIs for dashboards and kiosks.

Also, due to its small footprint and portability, it can be installed in all kinds of hardware and cloud providers.

Finally, if you want to create a quick site using aggregated data from KrakenD have a look at API2HTML. A simple website builder that converts API data into HTML using simple mustache templates.

The wheels on the bus go round and round, all through the town…