IoT with Azure: The ‘Serverless’ Story

‘Serverless’ has been promoted to becoming a genuine buzzword. But what does it mean? Is it truly possible to execute code with no processing on the server? Are servers a thing of the past and on their way to becoming a big no-no? Is it even possible to work without a server? And is the era of ‘client-server’ architecture gone already?

If the answer to these questions is yes, then that gives rise to more questions like these. If not a server, then who does the processing? Will this situation lead to the client’s workload becoming heavy with heaps of processing? If you have more questions along these lines, then read on!

Before delving into the ‘serverless’ world, it is important to understand what the term means, what it covers and what it doesn’t. Here’s a quick overview to get you up to speed,

What ‘Serverless’ is and what it is NOT

• Remember why we prefer cloud instead of physical infra? Essentially because it frees us from the worries of purchasing / estimating / maintaining the hardware. Also because it frees us from knowing all scaling requirements before-hand, sometimes a year or two in advance. ‘Serverless’ is a next step in the same direction.
• Plain cloud infra still requires us to provision for the resources we need and set up scaling rules in order to increase or decrease resources when demands fluctuate. Becoming serverless frees us from having to provision resources in advance. Simply quote ‘what’ you want to execute and leave the ‘how’ and ‘how much’ to the cloud!
• ‘Serverless computing’ is also known as Faas – Functions-as-a-Service
• Serverless does not mean ‘no server anywhere to help’
• Serverless does not mean that all processing happens on the client’s end

The ‘IoT’ Story

IoT – ‘Internet of Things’ is another buzzword doing the rounds in the tech circuit.

IoT is essentially all those devices in the field which have the capability to communicate with the Internet for sending messages. The meaning and purpose of the messages is different for each device, depending on the application of the device. For example, a device in healthcare will send a message indicating health parameters of the patient who is wearing the device, whereas a device in a water plant will send a message indicating water quality.

But the best way to explain what IoT is, is through a representative photograph. They say that a picture is worth a thousand words – and this one picture says it all!

Depending on the type of device and the industry, there can be multiple messages going out per day, per hour or even per minute. Those messages cannot be going into a wormhole, never to be deciphered or analyzed. ‘Someone’ needs to be listening to those messages sent by all those little devices in order to make them effective and useful. But that ‘someone’ cannot be a person. For instance, a doctor cannot and should not keep monitoring the measurements sent out by a health belt worn by a patient all day long – a piece of software is a better fit for this job, which is monotonous yet requires accurate and timely response.

So, the whole IoT story boils down to this simple expression –

Device => Internet connection => Messaging Infrastructure => Application/Service to process the messages => Response/Insight/Analysis sent to the device/stakeholders/consumer application (UI/Website)

Typically, IoT with cloud involves the following components,

• Devices/sensors measuring parameters
• Controller with an Internet connection – responsible for sending device measurements across the Internet
• Messaging infrastructure/service which runs independent of any user-defined application/service – it holds messages while the application is not available or is processing at a lesser speed than the devices or vice versa.
  • It acts as the main link between devices and the application processing of the measurements.
  • At the same time, it ensures loose coupling between the device and the cloud-side application. It protects both sides from blocking/hogging each other due to mismatch in processing speed or unexpected errors on one side.
• The application or service on the cloud side which processes the messages to derive meaning, analyze and send responses/insights to the stakeholders. It also responds back to the devices for 2-way communication requirements.

Serverless architecture for IoT

Is combining the benefits of serverless architecture with IoT possible? This question comes to mind because of the following limitations arising out of the typical architecture –

• The application, although hosted on cloud, needs resources to run for which the cloud expects us to specify a range.
• We may see a drastic increase in the number of devices in the field and the ‘range’ we specify may soon become outdated. In this case, the devices and stakeholders will see slow responses from the cloud and sometimes the cloud infra may break down and may not be able to process any message! Although the cloud provider is still within all its SLA requirements, a breakdown in communication still occurs. In such a case, the problem goes back to the on-premises resource planning case, where the resource requirements need to be well-calculated before-hand.
• The downtime may happen at odd hours or during long holidays, thereby making matters worse! Although the cloud provider is within its SLA, such situations can shake the confidence of users.
• In such cases, we need to re-provision resources and estimate the range again.
• On the other hand, sometimes we might over-provision the resources beforehand and incur unnecessary costs.

This is where the serverless solution comes in.

• Serverless computing on cloud does not ask us to provision any resource.
• It does not ask us to set auto-scaling rules (i.e. setting the ‘range’ of resources)
• The cloud just takes pieces of code which we want to execute and decides / provisions resources needed for its execution.
• At the time of peak demand, more resources are provisioned, only for the required time. As the demand recedes, resources also decrease, all the while being totally transparent to us.
• The granular resource allocation management technique saves costs and utilizes available resources in a more efficient manner.
• Hence, this is nothing but a step in the same direction as the well-known steps of efficient usage of resources
  • Physical infra => Cloud infra
  • Cloud Infra-as-a-Service => Cloud Platform-as-a-Service
  • Cloud Platform-as-a-Service => Cloud Functions-as-a-Service

The Azure Context

It will help if we take a look at an end-to-end case study that focuses on developing an IoT solution using serverless architecture on a specific cloud, Azure in this case. It will fit the bits and pieces together and provide a concrete set of components to support the abstract discussion we’ve had so far.

Azure provides an out-of-the-box solution for communicating with devices and comprises of the following components –

IoT Hub

IoT Hub is a managed service, hosted in the cloud, that acts as a central messaging hub for bi-directional communication between your IoT application and the devices it manages. It provides the following main features –

• Device registration / de-registration
• Added devices list
• Device state, called ‘device twin’
• An event-hub – messaging infra for messages to and from devices
• Secure communication using device-specific keys
• Ability to exchange files
• Ability to run a few functions on the device (IoT Edge)

Device Provisioning Service

The IoT Hub Device Provisioning Service is a helper service for the IoT Hub that enables zero-touch and just-in-time provisioning to the right IoT hub without requiring human intervention, thereby allowing customers to provision millions of devices in a secure and scalable manner.

For each device registration the device needs to be ‘known’ to the cloud, and the device needs to ‘know’ a reliable service to ping initially. This process is known as ‘device provisioning’.

All the device needs to know is that it must ping the device provisioning service in order to get attached to an IoT Hub. An organization can create multiple IoT Hubs for load distribution, but it doesn’t need to hard-code IoT Hub references in the devices. When the device pings the DPS, it gets registered to a specific IoT Hub which gives the connection string to the device.

With just these 2 components, the device communication is all set up! But what about having to process the tons of messages being emitted by your devices? That’s where Azure functions come to the rescue!

Azure Functions

Azure Functions allow users to easily run small pieces of code, or “functions,” in the cloud. You can use a development language of your choice, such as C#, F#, Node.js, Java, or PHP. Now, trust Azure to scale as needed and pay only for the time your code runs. Azure Functions let you develop ‘serverless’ applications on Microsoft Azure.

Serverless IoT Architecture on Azure

The required components fit together as ‘serverless IoT’ on Azure as described in the following diagram.

A brief description will help you understand the flow of the above diagram,

• A device pings the Device Provisioning Service
• The admin has already added the device to ‘known’ devices list.
• The DPS registers the device on one of the IoT Hubs associated with it and sends the device the connection string.
• The device is now able to connect to the IoT Hub and exchange messages.
• The IoT Hub stores the messages on an Events Hub until someone consumes them or they expire.
• An Azure function is written with an Event Hub trigger – so whenever a message arrives on the IoT Hub, the function is triggered.
  • For each message a different instance of the function is triggered, so all messages are consumed in parallel just as they come in.
• The message is processed by the function and output is sent as an email or a mobile push notification or a website – just some of the many ways available as output triggers for the function.

This flow does not talk about provisioning resources for functions, or IoT Hub, thereby making it a perfect case of ‘serverless’ architecture!