As you take an IoT solution to scale, as in any move to commercialization, you will likely make some significant changes. Especially for large scale deployments, which will be the focus here.
First, let’s address the hardware side. It may be that you will want to work with the hardware supplier of your MVP to make some adjustments to their product and offer you a special product for your needs. But, because all of the devices that were discussed in the previous article are based on “open source hardware”, it is not a major development effort to build your own special purpose version of hardware for deployment. It is really all a question of scale and cost and what makes the most business sense. If the development cost of a special purpose board is greater than the savings you will see anytime soon, and if you can get the quality and reliability that you need from a “general purpose” product, use that. If general purpose hardware is just too hard to deploy, or you need special regulatory or quality metrics, you may need to go down the custom product path. Generally, if you plan to hit high volume you will eventually go down this road or else establish a strategic partnership with one or two very good suppliers that you can trust.
On the connectivity and software side, all of the concepts implemented in the MVP still apply, but scale and reliability concerns, as well an increased need to be able to add special features and direct the way your application works in detail may force some new dimensions to you architecture. Of course, anything that was previously “free” will either need to be upgraded or replaced. If your volume will stay relatively modest, and you anticipate that the features you implemented in your MVP will suffice for the foreseeable future, you can continue to use services like PubNub, Dweet.io, or Freeboard, but with paid subscriptions. But, if you believe that your IoT solutions will scale significantly, or you will need new features and capabilities, and you likely will for more scaled solutions, you will need to integrate similar capabilities into your own offering. This does not mean that you are starting from scratch, but rather that you will now use more of the “raw materials” of the open source code available (there is so much available), or from the tool kits of your service providers to put together your solution.
As mentioned in the previous article, Verizon, AT&T, Amazon, Microsoft, and others offer a lot of tools and software services in their solutions. In their PaaS offerings (Platform as a Service) you can pick from a menu of software offerings that have been pre-designed to integrate with each other with API reference guides to help you create the stack you need. From what we have seen so far from the completeness of the offerings of AT&T and Verizon, we believe that their toolkits are great for your connectivity services, but for flexibility, expandability and and extended library of software tools, Amazon, Microsoft, and IBM will provide this level of capability, especially for more complex systems with large reach. Of course this all depends on your needs. Up to a point, simpler is better. If you are confident that can get all you need from AT&T, Verizon, or another service provider that is a simpler path. If you are not using cellular and are using wired connections or some other form of RF (WiFi, Zigbee, 802.15.4g/6LowPAN, SigFox, LoRa) that is backhauled over the internet, service providers do not enter into the equation and should choose the PaaS provider that you think best fits your needs. And, while it is a much larger undertaking, if you application has more extreme security implications, and long term significant scale as well, you can set up your own “cloud” using OpenStack and Cloud Foundry and layer all of the other “big data” software you might need running on your own server farm. Still, to get up and running, this is to be avoided as this can create significant expense and add a lot to time to market.
But, before we look at the different PaaS offerings, we should look at what might be a good “general purpose” IoT architecture. The architecture shown below assumes the need for near-real-time processing (using Apache Kafka as a publish-subscribe infrastructure and Apache Spark for an in-memory fast-path processing). This reference also assumes Service Oriented Architecture (SOA) to compartmentalize software functions for maintainability and module independence.
This architecture depicts an end to end design, showing the embedded edge devices, edge gateway elements, the transport network, and a “cloud-edge data delivery system” that connects to SOA components as well as noSQL databases. Apache Spark is shown in the architecture as an in-memory processing element to allow near-real-time processing. Also shown in the architecture, as one of the SOA elements is an API to back end business systems. The idea here is that few new systems will exist stand-alone, and they will be most valuable when connected to existing back end business systems. This architecture is by no means what each implementation needs, but is show as a frame of reference as we look at the PaaS systems available. When we look at these PaaS solutions, we need to think about how to transform these “raw materials” into a working system that may look, at least something, like the above.
Given this context, we can now take a brief look at several of the PaaS offerings that we can choose from, starting with Amazon.
Amazon is now offering an IoT PaaS stack product. An illustration of this is below:
The platform is intended to provide a lot of the architectural elements needed for your IoT implementations, with working APIs and associated SDKs between each piece of the architecture (table on features embedded below). The cloud edge processing is handled by “Ingest”, initial data transformation is handled by “Apache Spark Streaming”, the “data lake” is based on Amazon’s own “Dynamo DB”, the analysis layer uses Amazon’s “Elastic Map-Reduce”, an Hadoop based noSQL data management application. The combination of these infrastructure capabilities provide you with a lot of flexibility in implementing your IoT system, but this look at the architecture is somewhat abstract. An Amazon diagram that more clearly shows how your “things” securely connect to the PaaS solution is probably more useful, and a diagram of this is show below as well:
This diagram better shows the “out of the box” deliverables that Amazon provides you to interconnect your “things” to your back end system. Amazon provides C (for constrained devices) and Node.js (for less constrained devices), SDKs to embed in you “things” and give you seamless access to their “cloud edge” services. The cloud edge services include secure mutual authentication and encryption services, registry services and connectivity to MQTT (publish / subscribe) an HTTP interface to the back end. Behind the Device Gateway is a Rules Engine to manage the forwarding of device messages to back end applications, and also a JSON based device shadow application that always reflects the “state” of your device to the software running in the cloud. For a number of reasons (most importantly, the fact that IoT devices sometimes sleep), I really like this Device Shadow / local proxy architecture. Your applications can interact with the Device Shadow, which represents the current state of the device as if it were the device itself, and state can be synchronized based on the constrained availability of the field device.
Using this infrastructure, you can connect your devices, establish secure connections, set up device registration meta data, forward messages from devices to upstream applications, manage the devices and understand the last “state” of your devices whether or not your device is awake at the time. From there, you can deploy as simple or as complex a back end system made up of the components described in the earlier chart. With this architecture, we can easily set up “fast path” processing for near-real-time control as well as “slow path” processing for data processing, normalization and big-data analytics.
To show another alternative, here is an architectural chart from Microsoft:
This diagram breaks down the architecture between Device Connectivity, Data Processing and Analytics, and Presentation. Again, the “Cloud Gateway” is of particular interest to us. A closer look at Microsoft’s Cloud Gateway interworks with the system is show here:
Microsoft’s IoT Hub is their “Device Gateway”, and provides a per-device reliable communication between the devices and the back end processing functions. Microsoft provide C, Node.js as well as .Net SDK’s to help you easily use the IoT services to the IoT Hub. The IoT Hub uses either MQTT, HTTP or AMQP (which provides some advantages, depending on your needs). The IoT Hub provides a device identity registry for information about connected devices, a device information services for connection status, last activity time and to be able to enable or disable devices.
In this architecture, each device has two channels to interact with the cloud. The Device-to-Cloud channel is used to send data and requests to the cloud as well as transaction results from requests from the cloud. The Cloud-to-Device channel is used to receive requests from the cloud, and this IoT Hub channel provide feedback to cloud applications that the command has been acquired by the device for execution. Similarly, the cloud applications have two channels to communicate with each device. The Cloud to Device channel is a Time to Live (TTL) queue of commands to the device, and the IoT Hub applications provides feedback to back end applications on successful delivery of messages to devices. The Device to Cloud channel is an Event Hubs endpoint that back end applications use to receive device messages.
It is worth noting that the Microsoft PaaS stack comes with all of the Microsoft back end service interfaces, so this may be the most suitable for “Microsoft Shops”, and the Microsoft back-end analytics and visualization tools may be more familiar and readily useable to some businesses (although there is a host of excellent for-pay and open source tools available to use with and Amazon platform).
A table comparing some of the features of these PaaS offering (also showing contrasting what is provided by IBM) is shown below:
Credit: Toby McClean
Using either of these cloud base solutions, you can securely and reliably connect your field IoT devices to the cloud and connect them through the SDKs and APIs provided to back end systems. Both provide mechanisms to deliver both fast path processing or slow path back end data normalization, analytics and connectivity to back end applications. Once connected, in keeping with Agile development methodologies, you can incrementally add basic IoT services and basic visualization, then connectivity to essential business tools, then analytics, then machine learning and on and on.
In conclusion, these articles walked us through a look at how to look at what economic benefits we might see for IoT, how we could implement an IoT Minimum Viable Product to demonstrate and validate our concept to ourselves and with customers, and finally provided a look at turning our MVP into a final product.
It is worth noting that there many other options in turning your MVP into a final product, and this overview only touched a few. There are several very good IoT suppliers that provide customers with both hardware and backend hosted software solutions that can be branded and customized to your needs, and there are several “tiers” of such solutions. You can also set up your own system from scratch. As mentioned earlier, you can set up your own server farms, install OpenStack and CloudFoundary, and run open source IoT middleware like KAA, and run your own proprietary “cloud”. Depending on your needs, customer types, and long term plans, this may be a very good long term options, although this path is more challenging at the start, and with a longer-time-to-money).
We hope this overview has been helpful. And if you need a partner in putting together your IoT plans, reach out to us at Juxtology. We love IoT.