Although the burgeoning paradigms of IoT and Cloud Computing allow seemingly immaculate technological implementations, we mustn’t forget the prevalence of our bad practices. Even now in 2018, millions of dollars are wasted at the expense of inefficient deployment and development designs.
In the world of IoT embedded devices, this waste is partly due to a dogmatic default to the device-edge-cloud model. This approach involves the network of IoT devices sending large sums of data to a local edge computer. The edge then either processes that data to push to a cloud repository or pushes the data first for the cloud to process.
This methodology aims to better facilitate data traffic across a network; however, this is not a one-size-fits-all IoT framework as it sometimes carries crippling detriments for the project’s cost, development, and deployment.
To illustrate, consider an agricultural IoT farm that aims to install sensors which gather soil moisture data and adjust its sprinkler systems accordingly. If the farm were to take a device-edge-cloud model approach, several costly and time-consuming issues may arise:
- Edge computers add a layer of complexity to the overall compute-storage network architecture and can cause severe data latency issues. If the network is too large, sprinklers can be left on for too long, drowning the crops
- Edge devices have a high number of refresh cycles, which results in ‘architecture design’ lock-in. This is an important aspect when designing the overall architecture as it restricts the amount of physical change the environment can cater for such as seasons and natural disasters.
- If the farm decides to expand its network, the farmer would either have to pay large front-end costs towards installing additional edge computers or invest in stronger IoT devices to take care of greater workloads. Regardless, scalability is a nightmare.
While Edge Computing certainly has its place in IoT, the framework has been redundantly overused. Instead, engineers and developers must learn to think differently about structuring their network architecture.
In 2018’s advent of stronger cloud computation, cloud-based state machines provide an extremely versatile and efficient solution to IoT network design. For those yet unaware of the inner mechanisms that derive a state machine in the cloud, it is useful to follow this article, as it explains in detail what a cloud machine is and how to build one from the ground up.
This article will serve as a companion piece to the latter, as instead of answering HOW one would use a cloud machine, it shall focus on explaining WHY. Particularly, this piece will tackle the 3 dogmas of IoT: Hardware, Development/ Deployment, and Business model.
This article will also reference Functions as the cloud-machine exemplar. Function’s ability to fire a block of JavaScript code in tandem with any message sent over its pub-sub framework makes it a perfect candidate for cloud-machine architecture. Find out more about Functions here!
Dogma 1: Hardware Performance
Housing a state machine in a Function means that the user can outsource all of their data and computations to the cloud. Therefore, at the very least, an IoT device can solely publish and subscribe data over a REST API or “native SDK” so all the work can be taken care of in the cloud.
A minimalist pub-sub framework for client-side code provides many favorable benefits for the IoT device’s hardware:
- Can afford to use cheaper and dumber devices
- Lower need for memory space and processing power
- Even a little bit of logic outsourced to the cloud can save a lot of money if the network is big enough.
- Longer Duty Cycles
- Faster execution time
Here's an example of how one would implement such a framework.
Dogma 2: The Software Development and Deployment Process
When deploying a network of devices that report to an Edge server, the debugging process can take just as long, if not longer, than the development itself. Even diagnosing the issue can be extremely tedious if the problem is not apparent; however, when a network is working under a state-machine framework, the problem can be much easier to pinpoint.
For example, state machines allow for code to be very readable as the code can be broken up into very small and manageable blocks that other users can quickly run through. If an IoT device or network is not functioning properly, the developer can physically identify which state is dysfunctional and quickly fix the problematic code associated with that state.
Ex. of a state machine with blank states and 4 inputs
if(state == 0 || !state){
if(input == a){
//do something
}else if(input == b){
//do something
}else if(input == c){
//do something
}else if(input ==d){
//do something}
}
else if (state == 1){//same structure}
else if (state == 2){//same structure}
else if (state == 3){//same structure}
Additionally, instead of having an on-site Edge, a cloud Edge can be accessed remotely from any location. With Functions, this benefit becomes more pronounced when trying to update issues remotely.
From this UI, the user is able to virtualize the terminal screen of each IoT device with the console-debugger. Since all the device needs is an internet connection, the user can essentially program logic for any network of devices from anywhere in the world!
The Functions module also comes with an array of APIs that can easily be imported into the cloud code, without requiring the device to need more hardware. This means that even the smallest of IoT devices can now interact with any API, no matter how large.
<If you're interested in the wide variety of API's PubNub has to offer, check out the Blocks Catalog>
Dogma 3: Business Model and Strategies
On the business end, cloud state machines share many of the same benefits as do conventional cloud-based networks.
The largest benefit of cloud systems involves the project’s scalability. As the business of the project begins to expand, adding more devices to the network has little to no effect on the networks infrastructure. A device simply needs to be pre-programmed to publish and subscribe to the network, requiring no more than an access token from the server.
The server side of the business can then follow a pay-as-you-grow business model where the clients can adjust payments for a dynamically growing network. This is contrary to the edge model where the client needs to pay an upfront cost for additional servers that may never be used.
Additionally, the business can manufacture itself into a Platform as a Service (PaaS); The company can provide their cloud server as a platform for other device networks to use. For example, if a company were to build a robust Function optimized for a particular IoT smart farm, other companies can pay to use that Function to deploy their own IoT smart farm.
Try It Out For Yourself!
If this article has enticed you towards the world of cloud-machines, come build one yourself to see the power first hand!
