Resource
BlogTopic
Edge ComputeDate
Jan 16, 2020By 2020, the number of connected devices will exceed 20 billion. These devices are increasingly relying on edge infrastructure, or compute resources that are geographically closer to devices than traditional cloud resources. The explosive growth of internet-connected devices – the IoT – along with new applications that require real-time computing power, continues to drive edge computing systems.
MQTT, a standardized publish/subscribe messaging protocol (pub/sub), is a technology that works well with edge compute as it requires extremely low latency. It’s also great for geolocation applications. After all, it was originally designed in 1999 for use on satellites.
Because pub/sub is at the heart of MQTT, the technology is based around a message broker with other nodes surrounding the broker in a star topology. This is a very different model to the standard client/server approach. At first, it might seem a little strange, but the decoupling it provides is advantageous in many situations.
With MQTT, clients can publish or subscribe to particular topics that are similar to message subjects. They are used by the broker to decide who will receive a message. Topics in MQTT have a particular syntax. They are arranged in a hierarchy using the slash character (/) as a separator, much like the path in a URL. So your phone might publish to a topic like owntracks/peter/iPhone.
Assume you need to query geolocation data from a sensor on a vehicle to track its movement. This sensor maintains a connection to a broker and, every ten minutes, it reports the current location.
An example of a technology that uses MQTT to accomplish this is Owntracks, a geolocation platform and mobile app for tracking data from your phone, others phones, and a variety of sensors using geofencing. It accomplishes this via a mobile application that sends periodic MQTT messaging to notify the broker of the phone’s current location. The MQTT broker is typically provided by you, the user, for security reasons—although there are public brokers available.
In many applications, the latency of this connection is very important. For example, the world of emergency services and law enforcement requires information and updates on workers every second and lag can mean life or death to someone in the field. By processing data as close to the source as possible, latency decreases and valuable lives and resources are saved.
In this tutorial, we will set up a Mosquitto MQTT broker for our Owntracks setup on Stackpath using the API as an edge container workload.
Before starting this tutorial, you will need:
To get started, you need to provision your container workloads in a distributed nature with the mosquitto-mqtt image. You can make calls to the API with cURL to provision your workload and distribute it. In this tutorial, we’ll distribute it to a total of four PoPs in two regions:
North America:
Europe:
Make your cURL command resemble what follows. And remember to replace BEARER_TOKEN and STACK_ID with your own information.
curl -s -X POST https://gateway.stackpath.com/workload/v1/stacks/STACK_ID/workloads
-H "Authorization: bearer BEARER_TOKER
-H "Content-Type: application/json"
-d '{
"workload": {
"name": "test-workload",
"metadata": {
"version": "1",
"annotations": {
"anycast.platform.stackpath.net": "true"
}
},
"spec": {
"networkInterfaces": [
{
"network": "default"
}
],
"containers": {
"webserver": {
"image": "mosquitto-mqtt:latest",
"command": [],
"ports": {
"http": {
"port": 80
},
"https": {
"port": 443
}
},
"resources": {
"requests": {
"cpu": "1",
"memory": "2Gi"
}
}
}
}
},
"targets": {
"north-america": {
"spec": {
"deploymentScope": "cityCode",
"deployments": {
"minReplicas": 1,
"selectors": [
{
"key": "cityCode",
"operator": "in",
"values": [
"ATL, DFW"
]
}
]
}
}
},
"europe": {
"spec": {
"deploymentScope": "cityCode",
"deployments": {
"minReplicas": 1,
"selectors": [
{
"key": "cityCode",
"operator": "in",
"values": [
"FRA, AMS"
]
}
]
}
}
},
"slug": "test-workload"
}
}'The API call will return a JSON object with your WORKLOAD_ID. You will use this to provision your workload.
Note: Refer to the API documentation here for more information about the API calls.
To get started, install OwnTracks on your smartphone at the Google Play or Apple Store. Then make an API request to get the external IP of your instance.
curl -X GET https://gateway.stackpath.com/workload/v1/stacks/STACK_ID/workloads/WORKLOAD_ID/instances
-H "Authorization: bearer BEARER_TOKEN"
-H "Content-Type: application/json"The response will contain your external IP address in this format:
{
"pageInfo":{...}
"results":[
0:{
"stackId":"a37d79b4-e7d7-4be4-98b0-77aabf51d8a1"
"workloadId":"5f77d8a7-af12-4d48-a342-41b40bbac779"
"id":"cdf65506-1c15-11ea-95a4-0cc47a18eb58"
"name":"test-workload-dal-0"
"metadata":{...}
"location":{...}
"phase":"STARTING"
"ipAddress":"10.128.0.2"
"externalIpAddress":"151.139.63.47"
"createdAt":"2019-12-11T12:57:36Z"
"networkInterfaces":[...]
"resources":{...}
"containers":{...}
"containerStatuses":[...]
"virtualMachineStatuses":[]
"reason":""
"message":""
}
]
}Get the external IP and navigate to Preferences > Connection > Host in OwnTracks, then paste the IP.
Now you’re sending low-latency geolocation data to your MQTT broker at periodic intervals!
You can use OwnTracks for a variety of other things such as setting geofences to activate smarthome sensors based on your location, as well as tracking your friends (with their permission of course).
Now you know how to install an MQTT broker on the edge and send low-latency geolocation data to it. For next steps, check out the Awesome List for MQTT and see what other tools and applications you can use to send low-latency data to your broker.