IoT 101: Get started easily and scale quickly with the Soracom Platform
Written by: Marcela Batisteli
Published: April 26, 2017
Even for cloud-fluent developers, building for IoT can present a new kind of challenge. The Soracom platform is designed to make getting started easy and to scale as you do, with more advanced services available once you’re connected.
Where it all starts
From basic connectivity to advanced cloud integration, our philosophy carries across every service we offer: make it easy and keep the developer in control. Every service is offered on a pay-as-you-go, take-what-you-need basis. Pricing is completely transparent, there’s never any contract to sign, and you can stop the service the moment you stop needing it, or someone does it better than us. Even our embedded connectivity options support portability standards.
Getting Connected
- The Soracom SIM is compatible with all standard SIM form factors and available direct on Amazon. Our connectivity service, SORACOM Air, now covers 100+ countries, and can roam when multiple supported networks are available, so if your device is out of range on one network it can attach to another.
- All of your devices and connections can be managed directly from the Soracom console or through our suite of over 100 APIs.
Adding Cloud Capability Via the Soracom Platform
Most connected things don’t have a lot of memory or power, but that doesn’t mean they can’t act like they do. The Soracom platform is designed to let these devices do more with less by harnessing the power of the cloud.
With a mobile communications core built right on AWS, our services help to reduce data consumption, enhance security, and integrate directly with AWS, Azure, and other cloud resources.
- beam: works more like an HTTP server than a proxy. Send a request to beam.soracom.io and the request is forwarded to a server that you specify in config. So it doesn’t send requests to arbitrary servers. Translates thin-device protocol (e.g., UDP) to cloud-ready protocol (HTTP or HTTPS), or handles MQTT on the device and server sides.
- funnel works on the same technology stack as beam, and directs your devices straight to Kinesis, Kinesis Firehose, Azure Event Hubs, or AWS IoT without the need for an SDK on the device level. Funnel does the protocol and format translation within the adapter. Contrast this with the AWS rules engine, which is a SQL-structured selection mechanism that would allow sorting of data into AWS services. For the rules engine, you’re writing in JSON. And while multiple actions per rule can be concatenated for ease of maintenance, rules proliferate quickly. Funnel lets you avoid this work of writing, and more importantly, maintaining, so you can quickly get devices hopping on to the relevant cloud service with little fuss.
- canal / door / direct and gate layer-two & layer-three VPC peering within the AWS data center. Allows for the removal of the device from public view, and thereby allows trimming of cellular opex by chopping redundantly transmitted header, security, and other extraneous information. No initial VPC configuration, no each-time authentication process for the device when it wants to access the private resources. The different flavors refer to different levels of integration (e.g. Direct is a leased line connection, Door supports traditional IPSec VPNs). Gate actually enables secure layer-two device-to-device as well as device-to-server communication, not just the VPC in AWS (no NAT or firewall restrictions). The services allow for significant opex and security benefits depending on architectural decisions in the IoT application stack. They also let developers avoid fine-grain permission management, tedious to script and maintain in JSON.
- harvest: visualize the data from the connected sensor/device/actuator without hooking it up to the cloud just yet. Great for prototyping when the ongoing economics of the application aren’t yet secure.
- endorse: like Cognito, offers federated identity — identity pool and specific user definitions. It gives a SIM-based authentication option so that devices “outside the VPC” can get similar privileges and act like they’re inside.
The Soracom platform starts simple, but also comprises powerful dev tools, which you can explore on the Soracom developer site: https://dev.soracom.io/en/
The reference architecture diagrams you’ll find on each individual service page will give you a good illustration of how each particular service can be used (e.g., using Funnel to have devices send data directly to Kinesis Firehose and then using Lambda to fork the data to multiple AWS service targets like Redshift for your constant query targets and also DynamoDB for cases where fast lookups necessitate the indexing capability).
The power and extensibility of the SORACOM platform’s various features is evident when you browse the developer documentation, with more than 100 APIs ready to leverage. In among the 6,000+ customers and 300+ partners we have acquired since we started in 2015, there are probably plenty of use cases that relate to what you’re trying to do. Take a look and let us know if we can help you!
