Welcome back to Cloud 66! We missed you. In case you missed our first post, we introduced the Iridium CloudConnect Short Burst Data® (SBD®) on Amazon Web Services (AWS) Quick Start, and gave an overview of how this resource helps developers and their teams implement the service. For this edition, we wanted to get even more technical, and to take you on a deep dive of the different ways developers can use Iridium CloudConnect for their cloud-based back-end applications. So, without further ado, let’s dive in.

Now, for a quick history lesson. As you no doubt know by now, cloud-based solutions are becoming the de-facto way for businesses to deliver IT applications and services. The Iridium CloudConnect service allows organizations building or using IoT capabilities through AWS to extend their reach to the entire planet through Iridium’s global satellite network. 

These two services, Iridium CloudConnect and AWS, intersect at two fast-growing areas of technology. An early player in the cloud-hosting space and especially IoT, Amazon now leads this market sector. Iridium CloudConnect and AWS together provide a powerful tool for developers looking for a single communications platform to manage connected devices. It allows existing AWS customers to expand the reach of their IoT solutions with the global coverage and connectivity of the Iridium network, while continuing to use industry standard protocols and practices. Iridium customers now have access to IoT data in their AWS solution without added development efforts and impacts.

Iridium CloudConnect enables message exchange in standard file format, JavaScript Option Notation (JSON), for both Mobile Originated (MO) and Mobile Terminated (MT) messages, simplifying the way developers can send and manage their IoT data. Additionally, the Iridium CloudConnect service includes cloud configuration to generate Simple Queue Service (SQS) queues to support Iridium CloudConnect in your own AWS environment in any AWS region.

One huge benefit of using Iridium CloudConnect is the flexibility it offers. As detailed above, the service allows developers to host their data in whichever way works best for their business, while taking the translation component off the developer’s plate. To help paint a clearer picture of how Iridium CloudConnect simplifies the data management process while also promoting innovation and experimentation, we have mapped out a set of five potential data scenarios to illustrate how a potential architecture looked before Iridium CloudConnect, and how Iridium CloudConnect may work within your own development construct.

Figure 2: Scenario – Before Iridium CloudConnect – If you use Iridium DirectIP today, your solution probably looks like this architecture. As you work toward an AWS hosted solution, you could refactor your Iridium DirectIP solution, or you could use the convenience and architecture of Iridium CloudConnect and implement your solution with the SQS queue sets that are provided during the deployment of Iridium CloudConnect.

Figure 3: Scenario – Using Iridium CloudConnect backend solution notional architecture – This scenario illustrates what the architecture might look like.  As you can see, one can remove the load balancer, and the instances connected to the load balancer – major time saver! You would update your binary payload translator to translate to/from SQS. Optionally, you can also convert your binary payload translator to a serverless function.

Figure 4: Scenario – Transitional test setup – As you work through your development, you may opt to set up your old and new system in parallel for developing or testing purposes. Iridium can route production messages to the existing implementation and send a second copy to the Iridium CloudConnect implementation to avoid having to do a hard migration. This approach also provides you with a means to compare apples to apples for delivery time, application efficiency, etc.

Figure 5: Scenario – Development setup with simulated device functionality – Partners can use development SBD devices and create simulated devices as shown above.  These devices can drop the JSON SBD messages directly into the SQS queues as you develop your server-side application, eliminating the need to have actual devices send actual traffic over the air.

Thank you for taking the time to tune into our On Cloud 66 series! We hope you’ve found this information helpful and are inspired to join us in the cloud. In our next blog, we will focus on additional considerations for parsing MO and MT messages from SQS queues, and suggestions for integration with solutions such as AWS IoT Core, MQ Telemetry Transport (MQTT) messages, AWS Kinesis, and AWS Firehose. 

If you, a team member or cloud and backend server specialists need help implementing Iridium CloudConnect, make sure to check out the Iridium CloudConnect SBD on Amazon Web Services (AWS) Quick Start guide for additional information and assistance. 

For more information about Iridium CloudConnect, please visit https://www.iridium.com/services/iridium-cloudconnect/.