Cloud Native IoT


The technical and commercial success of cloud computing technology made it feasible to evolve the most demanding information and communication technology (ICT) infrastructures, such as communication networks, from specialized hardware and software to new software paradigms, referred to as ‘cloud-native’. Internet of Things (IoT) virtualization – IoT built on cloud-native principles – is to IoT platforms what Network Function Virtualization (NFV) is to communication networks.

What are the most important attributes of cloud-native IoT?

  • Horizontal scalability :
    IoT software, built to support load balancing, has virtually no limit when it comes to the number of supported devices or gateways, apart from the number of computing instances that can be allocated by the cloud infrastructure. Cloud-native IoT allows automated scale-up and scale-down computing and storage capacity, according to administrator policies. The intent is to cope with sudden changes in generated IoT data volumes.
  • High throughput :
    IoT software must handle high volumes of data without any impact on system performance. It is important to recognize that IoT traffic can be ‘bursty’ and that data sources can be highly synchronized. Some would counter this argument by saying IoT is characterized by low data throughputs generated by constrained, low-power devices. But, even in this case, the resource and application monitoring logs generated by a large number of IoT gateways could be very substantial – typically several Gigabytes of data. These logs need to be transferred, correlated with other logs and acted upon to detect or isolate failures as well as make recommendations for predictive maintenance, for example. Here we see why cloud-native tools such as Apache Kafka use massive parallelism to collect and process high throughputs of datasets. Another important concept for high throughput is MapReduce, a programming model that allows the splitting of large datasets into smaller ones and the movement of processing closer to data.
  • Low latency :
    Low latency is essential to applications such as autonomous driving or industrial automation. Edge computing drives latency lower by moving computing resources closer to the field domain where an action takes place. This must be matched by system architecture designs that are able to support low latency. There is no single mechanism to achieve low latency – programmers and system architects need a toolbox so that they can mix-and-match tools to meet the different requirements and traffic patterns associated with applications. Examples of such tools include brokers capable of routing IoT application messages in (near) real time. There are also evolutions of MapReduce that make massive use of in-memory databases capable of meeting low-latency requirements.
  • No single point of failure :
    The software components of an IoT server could be optimized around tasks performed for specific purposes, referred to as microservices. Microservices communicate using message brokers. Both microservices and brokers run on virtual machines or containers, the latter providing a lightweight software environment to host individual processes. The design, orchestration and administration of the microservices that make up an IoT platform, as well as that of the broker used for communications, must be done in such a way that avoids single points of failure (a point of failure with serious ramifications for the operation of the entire IoT service). This is where an open-source container orchestration system such as Kubernetes or Docker Swarm comes into play. Kubernetes, in particular, enables the monitoring of an IoT platform and subsequent recovery from failures independently of the cloud infrastructure. Should parts of the cloud IoT platform suffer a sudden hardware or software failure, this will not impact the overall operations of the IoT service.