A continuing look at what it means to have a 'True Cloud' solution and its impact on today’s physical security technologies
Cloud Native IoT means that IoT devices communicate securely with each other and the cloud, and that cloud applications make effective use of modern cloud architecture including the elements of serverless computing, so that they can provide uniformly high performance for any size IoT device deployment. This requires sound system design and cloud engineering work, about which a manufacturer or partner security service provider should be able to provide insightful discussions and good documentation to consultants and end user customers.
Editor’s note: This is the 57th article in the “Real Words or Buzzwords?” series about how real words can become empty words and stifle technology progress.
In the opening of his white paper, “How to Think Cloud Native”, Joe Beda, a principal engineer at VMware, says, “One important note: You don’t have to run in the cloud to be cloud native.” The subtitle of the paper is, “Bite-size thought pieces on the definition and development of cloud native capabilities.”
I highly recommend this paper to all physical security industry manufacturers because our industry tends to run five to 15 years behind the IT industry in the adoption of information technology and especially the people and process aspects – the IT practices – related to the full application and use of information technology. It’s the practice side of the picture that the industry is typically incomplete on, often to the detriment of industry customers – the end users and the service providers who support them.
Beda further writes, “These techniques can be applied incrementally as appropriate and should help smooth any transition to the cloud . . . The real value from cloud native goes far beyond the basket of technologies that are closely associated with it. To really understand where our industry is going, we need to examine where and how we can make companies, teams, and people more successful.”
Cloud native techniques – which are still evolving and advancing – have been well-proven at technology-centric, forward-looking companies whose names we all know, such as Google, Netflix and Facebook. These giants have dedicated large amounts of resources to their efforts, and their lessons learned in developing successful (in scale, customer experience, and profitability) cloud solutions are worth considering. In nine pages of mostly plain language, this is what Beda delves into.
It’s natural to think, “This can’t apply to us because we’re a small company, nowhere near the size of the tech giants.” However, Beda tells us, “Smaller, more flexible companies are also realizing value here. However, there are very few examples of this philosophy being applied outside of technology early adopters. We are still at the beginning of this journey when viewed across the wider IT world.” That wider IT world is where the security industry sits — at the beginning of the journey that is Cloud and IoT.
Companies like Microsoft, Facebook, Netflix and Google, who have thousands of software developers, organize themselves into many groups and teams for each product. For smaller companies —like those found in the physical security industry — groups and teams often translate into individuals with a variety of related roles and responsibilities, many of which are only occasionally called into action or are performed regularly but don’t take up much time. The point is that many of the same principles and practices used by the big companies are still applicable, just on a smaller scale.
The rest of this article is devoted to a few technical aspects of Cloud Native IoT that are meaningful to end user customers and security service providers, as well as manufacturers.
Cloud Native IoT
A native application is one that has been developed for use on a specific platform or device, and executes more quickly and efficiently because it makes maximum use of the capabilities built into (i.e. native to) that platform or device, and doesn’t require any extra layers of translation or interface to run there. Thus, we see the terms “native iOS app” and “native Android app” used to refer to mobile apps whose software code is written just for Apple’s iOS or Google’s Android operating system.
Cloud-native refers to an application that has been designed and built to take maximum advantage—based on the purpose of the application—of the key characteristics of cloud computing.
However, IoT has been one of the driving factors in the technological advancement of cloud computing since NIST first described it in 2011. Thus, the Cloud Native Computing Foundation (CNCF) now says that “cloud native applications are specifically designed to take advantage of innovations in cloud computing. They take advantage of modern-day cloud resources and scaling capabilities, which are important for cloud-managed IoT systems. CNCF also says that cloud native applications take advantage of innovations in cloud infrastructure (computing and networking hardware and software designs) driven by cloud computing.
Thus, today, cloud native applications today include apps that run in a cloud provider’s datacentre and also on cloud native platforms on premise.
The term Cloud Native IoT refers to extensive use of serverless cloud computing resources to maximize the performance of cloud-based IoT systems, as well as to lower the cost of cloud computing for high device count IoT systems and their related analytics applications.
Under server-based cloud architecture, cloud application providers must manage the virtual server or virtual server cluster on which their applications are running. When a spike occurs in IoT device events to be processed and more processing power is needed, more virtual servers need to be spun up, which can take many minutes. That’s not an acceptable time frame for processing door forced open or intrusion alarm events. And it adds a disproportionately high cost for processing just a few events.
With serverless computing, parts of an application run in application containers. A container holds only those software code libraries required to run the application function being placed in it, as opposed to holding an entire server operating system. As a cloud resource, a container can be launched by the application automatically in a few microseconds and will run only as long as it needs to (seconds or minutes) and is then automatically shut down. The cloud service provider only pays for the time the function’s container was actually running. In cloud parlance, this is called Function as a Service (FaaS).
Such an event spike can happen for central station alarm monitoring centres and regional corporate Security Operations Centres when an earthquake occurs, and all the impacted buildings send in their sensor-based and video-based motion-detected alarms. This can render a traditional central station or SOC non-functional as alarms queues get full and valid alarms get lost amid the countless earthquake-caused nuisance alarms.
This is why, for example, Brivo uses containers for functions related to event handling. A new event arrival launches a new container, and regardless of how many events arrived, each event can be processed instantly. When a bunch of events all arrive at once, they get individually processed in parallel. The cloud infrastructure automatically expands the needed cloud resources, including application network bandwidth, so that nothing is delayed longer than its actual no-wait processing time.
This means, for example, that all access control panels at a site can send their activity to the cloud at the same time, and the cloud application never backs up. It means that a regional dashboard of events across many sites is always up to date, no matter how much activity goes on.
Cloud Native IoT means that the cloud application side of a cloud-managed system of on-premises equipment can perform much better than an on-premises system, because there is no such thing as a server’s CPU utilization maxing out. At the busiest times of day, any number of end users can use the cloud application to view events, run reports, and perform other system tasks – all with no delays. Pre-cloud, I’ve seen security applications which, around building opening and closing time or manufacturing plant shift changes, the company’s local software and SOC applications lag in reporting events and performing certain application functions.
Cloud Native IoT also means that robust device and system security controls are in place, such as strong data encryption, and digital certificate-based authentication between IoT devices and on-site appliances as well as with the cloud applications they communicate with.
System Integrations Impact
In earlier times, points of security systems integration could be bottlenecks and sometimes had reliability problems, but most of the time system integrations were not that significant in terms of the amount of data they handled. However, integration activity is changing both in frequency and amount of data exchanged, due to the arrival of AI-based video and IoT sensor-based analytics which have near-real-time sensitivity. Many of the analytics are providing new kinds of data valuable to security and to other functional areas of the business, requiring more types of information than before.
Since most organizations have transitioned many in-house applications to the cloud as well as having subscribed to commercial business cloud-based applications, cloud-based integrations are becoming the norm, especially in the current age of corporate digital transformation. Containerization for cloud application API functions can have a significant impact on security systems integration performance. This is not a significant factor now for most security systems, but it will be going forward.
In summary, Cloud Native IoT means that IoT devices communicate securely with each other and the cloud, and that cloud applications make effective use of modern cloud architecture including the elements of serverless computing, so that they can provide uniformly high performance for any size IoT device deployment. This requires sound system design and cloud engineering work, about which a manufacturer or partner security service provider should be able to provide insightful discussions and good documentation to consultants and end user customers.
A future article will follow up on Beda’s comment that “You don’t have to run in the cloud to be cloud native.” It will address challenges and opportunities for organizations with sizeable security system deployments, and options for transitioning to cloud-managed security systems.