Let’s talks clouds…
We often get questions how Synpse is compared or competes with public cloud IoT solutions. Synpse is not competing with any of the Public Cloud offerings. Contrary - it adds value ontop. Most public cloud providers gives users a framework to interact with their devices and consume their data.
It is very much SAAS (Software as a Service) layer product. Where Synpse allows you to manage devices in the lower layers, more like a PAAS (Platform as a Service).
In most cases Public cloud vendors provides SDK’s (Software development kit’s) to integrate with your devices. Most generic flow to integrate your IoT fleet to with public clouds include these high level steps:
- Generate unique certificate/key per device (or get one from cloud provider)
- Make certificates available to individual devices (usually part of device manufacturing or application deployment process)
- Integrate your device with the cloud using SDK’s
- SDK’s enabling both ways communication with the device, but in the limited capacity
Usually edge applications are quite monolith in nature and hard to update. Most SDK’s provide ability to control the application and update them partially. But if you want to update full application it might require additional innovation on application side.
This is even harder if you get into embedded applications as they are part of hardware itself. In the “age of containers” we are used to packaging application outside of hardware and iterate on both independently.
This is where Synpse comes in the picture. It allows to decompose your applications into a set of microservices and still keep all the benefits of IoT and cloud providers. Even with ability to migrate biggest components in your application stack.
We went quite extensive lengths to try and compare all 3 major cloud providers to find common ground for IoT stacks. Despite the fact all cloud providers provide slightly different IoT stack, they have few common ground to be used. So if you need to integrate with a different cloud providers or migrate between them you better off using lowest denominator between clouds.
We intentionally ignoring details like price, message retention, ETL flows to get messages from IoT service to your preferred destination. In reality these details are not important in the grad picture. You either commit to one cloud, or build in the ways you can move between clouds. In either way these details are irrelevant (feel free to argue this with us :) Discussions are more than welcome!)
Your best bet is to use MQTT and certificate/TLS authentication for cloud providers. And abstract all cloud specific communication with separate microservice.
We prepared very simple examples to show how this could be done using Synpse. Working together with public cloud offerings you can create bespoke architectures.
https://github.com/synpse-hq/metrics-nats-example-app - Example golang application gathering metric and publishing them to local instance of NAT’s messaging queue. This messaging topic will be consumed by cloud specific example and published into the cloud specific MQTT technology.
https://github.com/synpse-hq/azure-iot-hub-example - Azure IoT Hub example https://github.com/synpse-hq/gcp-iot-core-example - Google Cloud IoT Core example https://github.com/synpse-hq/aws-iot-core-example - AWS IoT Core example
Technologies used
- Synpse - manage devices and deploy applications to them
- NATS - a lightweight message broker that can run on-prem
- Google IoT Core
- AWS IoT Hub
- Azure IoT Hub
Wrapping up
This is very short intro into what follows in the future blog posts. We will cover integration examples in details in the article bellow. So let’s get cracking…
If you have any questions or suggestions, feel free to start a new discussion in our forum or drop us a line on Discord
