IoT Service Platforms:

Some Assembly Required? Whitepaper Sponsored by Ayla Networks

May 23, 2016

Page 1

© TIRIAS RESEARCH ALL RIGHTS RESERVED

This paper is an introduction to designing Internet of Things (IoT) solutions for designers and

manufacturers of consumer major appliances, as well as light industrial applications. Readers will

learn about emerging IoT service platforms – also called IoT Platform as a Service (PaaS) – that

simplify IoT product and service development and shorten the time it takes to get to market.

The “Internet of Things” is not very well defined. There isn’t just one big, ubiquitous vision of

IoT, there are and will be many perspectives on and visions of IoT – solutions that do different

things, solve different problems, or create new opportunities – by creating specialized applications

and networks. Although each vision of IoT will have unique physical attributes at the endpoints or

in how the endpoints connect, all IoT frameworks will share architecture features of logical,

service-oriented systems. These shared service features will contribute heavily to each solution’s

time-to-market, quality of service, and profitability.

For example, smart building commercial property managers’ requirements for heating, ventilating,

and air condition (HVAC) are different than that of homeowners installing a new central heating

and air conditioning unit. Commercial property managers want to optimize HVAC usage by

deploying more sensors for remote monitoring of many properties from a central location.

Homeowners want to personalize their experience and receive notifications through their

smartphone, and they want to integrate their central A/C control with other appliances.

Definitions

The terms “platform” and “component” have many different meanings. In this paper:

Component: a replaceable piece of hardware and its operating software. A component is

designed to perform a single task or a small but closely related set of tasks through a well-

defined hardware interface and software application programming interface (API). For

example, solid-state disks (SSD) are components, so are thermostats, network routers, and

smartphones.

Platform: a system that defines a set of APIs and/or hardware interfaces to address larger

solutions or behaviors. Successful platforms typically create an ecosystem of component

suppliers. In the consumer market, Apple and Google have created platforms around their

smartphone operating systems, where smartphones and apps are components inside of the

larger app ecosystem platforms.

IoT is a Service Platform

TIRIAS Research considers each vision of IoT to be a “service platform”. This is a big change

from the way information technology (IT) has been delivered in the past. Previously, IT platforms

Page 2

IoT Service Platforms:

Some Assembly Required?

TIRIAS RESEARCH

were simple – a bundle of hardware and software ready to run an application. Because applications

were generally stand-alone, they were relatively easy to validate and updates typically did not

affect other applications.

Each IoT framework requires a system of systems connected by networks. Systems of systems

behave differently than stand-alone devices. Changes to one portion of one system may have

unintended consequences to the rest of the linked systems.

In modern distributed architectures, including IoT, each constituent system has an API. APIs

expose a system’s service level interface. The hardware and software under an API can be replaced

or upgraded without making other components of an IoT deployment aware of those changes.

APIs are the heart of “microservices”. While there isn’t a standard definition for microservices, at

their core they are a software services design methodology for writing small, independent, reusable

pieces of code that can be independently tested and deployed. Microservices are a fundamental

building block of distributed architectures, as the complexity of deploying and scaling a service

platform over hundreds, thousands, millions, or even billions of devices is simply too hard to

manage without localizing service and failure domains. The adage “think globally, act locally”

definitely applies to designing scalable distributed architectures based on local access to globally

connected microservices.

Service platforms provide high-level logical architectures, system of systems design templates,

and the microservice APIs required to deliver a solution to market. Service platforms enable

application developers to focus on their customers’ needs, instead of spending resources trying to

get a bundle of technology to interoperate and scale.

Product Lifecycles in a Service Platform

Classic product development cycles assume that products will live a long and healthy life in a well-

understood environment. As a result, companies implement linear waterfall lifecycle models,

where each phase of a product’s life cycle - inception, definition, development, test, deployment,

volume ramp, and end of life - are a discrete point in time along an inevitable trajectory. Perfect

execution of each step is assumed, and moving backwards, trying to go back up the waterfall, is

expensive and implies that someone really messed up in a previous step.

In a distributed service platform architecture, such as an IoT deployment, designers must assume:

Microservices are the constant, components are ephemeral. Service continuity depends

on redundancy and flexibility in operating and integrating microservices, and not on the

robustness of any individual component.

Page 3

IoT Service Platforms:

Some Assembly Required?

TIRIAS RESEARCH

There is no way to anticipate all of the component failure modes in a service platform.

Components will fail at random. They will also fail in unpredictable ways. A service

platform must anticipate, detect, isolate, report, and route around failures. Manufacturers

will discontinue components, as well, forcing a service to find replacement components

that will not behave identically to the discontinued component.

None of a system’s component’s lifecycles will synchronize with each other. Some

components will be available off-the-shelf before initial deployment, some will be purpose

designed for initial deployment, and others will be added to the platform after initial

deployment – purpose designed or off-the-shelf.

The key to designing IoT components is understanding that each component must adapt in the

field to the API it services. Many IoT components will be deployed for decades-long product

lifetimes. They will be placed in remote, hostile, and/or inconvenient environments, where the cost

to physically replace a functioning component for a software upgrade is prohibitive.

The heart of agile development is a highly iterative development, integration, and test loop within

a larger deployment cycle (see graphic, below). After a component is deployed in the field, it

continues to return performance data to its development team, as it did in the rapid development

loop. The development team

monitors operational component

behavior, and determines when

enough evidence has been

gathered for bug fixes, feature

updates, or behavioral changes

based on microservice

performance.

Under the old waterfall model,

vendors sometimes referred to

competitors’ products as the

result of a “rapid prototype and

ship” mentality, and that was

considered to be a very bad

methodology. In a modern networked microservices environment, rapidly deploying components

to obtain real world performance data achieves faster time-to-market as well as a nimbler

understanding of changing service environments.

Figure 1. The Agile Development Loop

Page 4

IoT Service Platforms:

Some Assembly Required?

TIRIAS RESEARCH

Given that there is no perfect understanding of the system, most IoT components will ship in

volume as an extended beta test that will last through their entire product lifecycle. When should

an IoT component move out of field beta test and into high volume production? The answer to that

question is another question – when will the design team perfectly understand a complex system

that will continue to change over time and microservices fail to fix, change, or improve the existing

platform? A component’s lifecycle ends when a new physical design is required to meet evolving

service platform and microservices requirements.

A Physical View of IoT Service Platforms

Much of the focus for IoT development is in endpoint design – endpoints are sensor and actuator

platforms that gather local physical data for local and remote analysis, and they may also be able

to change local physical conditions in response to those analyses. If you only look at endpoints, it

is easy way to convince yourself that each IoT deployment is radically different from every other

IoT deployment.

Figure 2. Example: Physical View of Smart Building IoT End-to-End Solution (Simplifying Cloud)

The most critical part of endpoint design is understanding that endpoints are only one part of the

physical and logical design of an IoT service platform. Endpoints are necessary but not sufficient

to field a complete IoT solution.

Endpoints must be connected to a larger solution, which is the point of IoT. Endpoints must be

capable of being managed remotely – important functions being shut-down, start-up,

reconfiguration, software updates, device status, health monitoring, and data management. Some

Page 5

IoT Service Platforms:

Some Assembly Required?

TIRIAS RESEARCH

simple or older endpoints may not be directly managed, they will be monitored by newer

aggregation points and gateways.

After initial endpoint deployment, the real learning begins. Gathering enough data to interpret

general sensor input takes scale, and experiencing uncommon and rare conditions takes time as

well as scale. Scale has an impact on endpoint and system-wide communications and networks, as

well as the cloud services that enable the “Internet” part of IoT.

As an example, Ayla Networks’ Agile IoT Platform is designed to gather consumer appliance

sensor data to enable auto-refill of consumables (such as soap, fabric softener, etc.), monitor

quality of service, and provide predictive maintenance guidance. All of this information will help

reduce the cost of extended warranties and increase participation in customer loyalty programs.

Network topology will have a huge impact

on IoT services delivery. There are no best

practices yet for determining how and

where to deploy multi-protocol gateways,

where to aggregate upstream data and

component metadata, how to manage

downstream configuration and updates,

and how to distribute analytics and storage

capabilities throughout the physical

infrastructure.

The cloud services component needed to

complete an IoT service platform is in a

similar state of early experimentation. For

example, AWS IoT lists nine major component services that their IoT customers must master to

implement the cloud services side of an IoT service platform.1 Each service is associated with

separate physical infrastructure.

1 AWS IoT website as of 7 May 2016, http://aws.amazon.com/iot/ - AWS claims: “AWS IoT makes it easy to use AWS services like AWS Lambda, Amazon Kinesis, Amazon S3, Amazon Machine Learning, Amazon DynamoDB, Amazon CloudWatch, AWS CloudTrail, and Amazon Elasticsearch Service with built-in Kibana integration, to build IoT applications that gather, process, analyze and act on data generated by connected devices, without having to manage any infrastructure” but learning, managing and scaling these services is a do it yourself (DIY) project.

Figure 2. Cloud Architecture: Streaming Data, Data Center Networking, Distributed Storage, Compute and

Pattern Analytics

Page 6

IoT Service Platforms:

Some Assembly Required?

TIRIAS RESEARCH

A Logical View of IoT Service Platforms

Similar to the device-centric physical view of IoT platforms, the logical view of IoT is dominated

by the local environments where endpoint deployments are aimed. Locality determines what to

measure, where to measure it, what actions might be taken, and how and where those actions can

be taken.

However, locality is only one part of a complete

end-to-end IoT service platform, data and

control planes, applications, and the overarching

solution complete the logical picture.

Data plane describes the physical components

that data flows over, to and from local

environments. The data plane enables obtaining

data from the real world and to communicate

any actions that must be taken there. It also

includes continuous metadata (data describing

the health and status of the data plane system

while it is operating) to manage an IoT service

platform’s physical infrastructure. The data

plane is the basis for an IoT service platform and

directly impacts the quality of service for the overall platform.

Control plane describes the logical architecture used to manage the data plane. The control plane

constantly evaluates data plane metadata while the data plane is running, and can manage data

plane components or change data plane operational rules on-the-fly.

Applications use the microservices exposed by control and data planes to perform a series of

coordinated actions based on local conditions. Applications must derive insight from local

conditions. As a result, at a logical level, each application must have access to insight derived from

pattern analytics and must be able to apply that insight to local conditions in real-time.

At the highest level, a service platform orchestrates applications to respond to a challenge or solve

a problem at the locations it services. The service platform also oversees the complete IoT service

platform security and data management functions. While each physical component contributes to

both, it is at the service platform level that security and data management come together.

Applications depend on service platforms such as Ayla Networks’ Agile IoT Platform to create a

microservices environment that ensures security and data management.

Figure 4. Service Platform Hierarchy

Page 7

IoT Service Platforms:

Some Assembly Required?

TIRIAS RESEARCH

Investing in an IoT Service Platform

Scale and cumulative experience matter in deploying an IoT service platform. End customer

expectations for the quality of service of IoT service platforms are evolving at a faster pace than

“do it yourself” (DIY) IoT application developers can maintain.

There are a few key questions that IoT application developers should ask as they define their

requirements:

How quickly can you get to market? Time-to-market (TTM) is directly affected by how

long the reiterative development cycle takes before a project passes a requirements

acceptance test. Taking advantage of known good platform APIs can help speed TTM.

What else can you be doing with your development resources? Opportunity cost – what

else you can do with your resources to generate more revenue or make your crowdsourcing

windfall last longer? This is hard to quantify, but it also has a direct relationship to TTM.

How will you economically deliver a Total Cost of Ownership (TCO) benefit? After

you have sold and deployed physical components as capital expenses (CAPEX), what will

your customer’s operational expenses (OPEX) requirements be to make your solution work

and to ensure it continues to work as expected? How much will you spend in support costs

to meet your customer’s service metrics? Security and data management are major

contributors to overall TCO.

While the physical view of IoT service delivery seems daunting, a logical view shows that true

differentiation in IoT service delivery is based in locality and applications. Data plane, control

plane, and high level service platform orchestration are necessary, but they each have a lot in

common between application domains. That means they can be outsourced to dedicated IoT

service platforms.

Ayla Networks’ Agile IoT Platform is a good example of this emerging class of IoT service

platforms – sometimes called IoT Platform as a Service (PaaS). Ayla Networks addresses three

critical components of IoT PaaS – connecting devices to cloud services at scale, generating insights

from sensor data, and delivering a consumer mobile app experience.

Ayla Networks (www.aylanetworks.com) enables their customers to focus on end-customer

applications, what they do best, knowing that they have a solid services infrastructure base to

deliver those applications with a quality experience.

Page 8

IoT Service Platforms:

Some Assembly Required?

TIRIAS RESEARCH

Copyright TIRIAS Research LLC 2016. All rights reserved.

Reproduction in whole or in part is prohibited without written permission from TIRIAS Research LLC.

This report is the property of TIRIAS Research LLC and is made available only upon these terms and

conditions. The contents of this report represent the interpretation and analysis of statist ics and information that

is either generally available to the public or released by responsible agencies or individuals. The information

contained in this report is believed to be reliable but is not guaranteed as to its accuracy or completeness.

TIRIAS Research LLC reserves all rights herein. Reproduction or disclosure in whole or in part is permitted

only with the written and express consent of TIRIAS Research LLC.