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 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. device-edge-cloud 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 , 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. refresh cycles 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, is a nightmare. scalability While 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. Edge Computing In 2018’s advent of stronger cloud computation, 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, , as it explains in detail what a cloud machine is and how to build one from the ground up. cloud-based state machines it is useful to follow this article This article will serve as a companion piece to the latter, as instead of answering one would use a cloud machine, it shall focus on explaining . Particularly, this piece will tackle the 3 dogmas of IoT: , , and . HOW WHY Hardware Development/ Deployment Business model This article will also reference PubNub 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 PubNub Functions here! Dogma 1: Hardware Performance Housing a state machine in a PubNub 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 or “native SDK” so all the work can be taken care of in the cloud. REST API A minimalist pub-sub framework for client-side code provides many favourable 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 can be accessed remotely from any location. With , this benefit becomes more pronounced when trying to update issues remotely. cloud Edge PubNub Functions 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 . 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. scalability The server side of the business can then follow a 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. pay-as-you-grow Additionally, the business can manufacture itself into a ; 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 PubNub Function optimized for a particular IoT smart farm, other companies can pay to use that Function to deploy their own IoT smart farm. Platform as a Service (PaaS) 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! Sign up for free API keys here. Originally published at www.pubnub.com .
