What is the difference between a Device and a Service?
The internet of things is going to have a big impact on technology and business. Let’s look at some ways we should change how we think of services and devices.
We are facing some interesting paradigm changes as our Platform 3 software platform evolves. Platform 3 is the combination of new technologies related to mobile, the cloud and social that are redefining how we make software and deliver it.
How should we think about managing devices versus a service. In some ways these things are very similar. We want to manage these things similarly in the sense that it would be ideal to think of physical devices as simply conduits of information to and from the physical world without having to worry about their physical aspects too much. We do this with multi-tiered architecture. Separating the physical layer from the abstract layers we use in programming.
A service, micro-service and a device all have the following features in common:
1. Have an interface for communicating, managing, getting data to and from, a clearly defined set of APIs
2. There can be many instances
3. Need authentication to control access and entitlement to control aspects available to each entity requesting access
4. The interaction can be request-reply or publish-subscribe
5. The location of the service or device may be important
6. Provides a minimal set of functions around a single purpose that can be described succinctly
7. Have a cost of operating, maximum throughput and operational characteristics and configuration details per instance
8. may be external or owned by external party
9. Usually has a specific URI to refer to a particular entity
10. has access to a limited set of data defined in advance
11. Can depend on or be depended on by many other services or devices
12. Can be part of larger groups of entities in multiple non-hierarchical relationships
13. Orchestration of higher level capabilities involves interacting with multiple services or devices
14. Needs to be monitored for health, managed for security, for failure and have configuration changed and all the corresponding best practices management aspects of this
15. Services and devices both have social aspect where people may want to know all about or comment on the specific service or device or the class of services and devices
16. Can be infected with malware, viruses or compromised in similar ways
17. Can have side effects or be purely functional
18. May have data streams associated with their activity
Some differences between Services and Devices:
1. Services:are Multi-tenant with data isolation per tenant. Devices usually have only one tenant.
2. Devices: Physical existence can be compromised physically, stolen, tampered with.
3. Devices: Possibly have a physical interface for humans. Services do not.
4. Devices may have data embedded in the device whereas services usually are designed to be stateless
5. Devices may be mobile with changing location
6. Devices connectivity can be marginal at times with low bandwidth or nonexistant
7. A device may have compromised functionality but still work fine usually services are working or not working
8. Service failover can be as simple as spinning up new virtual instances. Physical failure usually involves physical replacement. Service failure may point to a physical device failure but is usually not dependent on any particular physical device, i.e. can be replicated on similar abstract hardware.
9. A physical device may produce erroneous results or be out of calibration
10. Services can be scaled dynamically instantly whereas devices need manual component to be scalable.
11. Devices have a physically unique identification such as a MAC address or NFC id whereas services are usually fungible and identified by a URI uniquely.
Enterprise Store or Catalog
It is apparent that devices and services have a large number of common characteristics. Especially important are the social aspects and interdependence which means that it is desirable to consider sharing the same interface to look at services, micro-services, devices, APIs.
Apps are more like devices and depend on services. Apps, Services and Devices share a number of characteristics as well.
To make all these things more reusable it is desirable to put them in a store of repository where people can comment and share useful information to prospective users. Thus the concept of the Enterprise Store makes complete sense where the store can store any asset that might be shared.
Each asset including APIs, Mobile Apps, Service, Micro-service can have social characteristics, health characteristics, instances, owners, belong to groups, need to be permission’d and allocated. Further, you will undoubtedly want to track usage, monitor and maintain the asset through upgrades, lifecycle. You will also want to revoke permission, limit usage or wipe the device.
Apps are usually built up from APIs and Devices. Orchestration of multiple devices and services together makes having a common interface a good idea as well. Using this interface you can see the dependencies and easily combine APIs, Devices and Apps to build new functionality.
Device management vs Service Management
There are some difference outlined above between services and devices.
Additional security capabilities are needed with physical devices similar to the kinds of things that cell phones and EMM can do. EMM systems have the ability to insure encryption of data at rest, box the data on the device and delete it with or without the owners permission or physical possession of the device. Geofencing is an important capability for devices since some devices when outside a defined area may be considered stolen.
It’s also important to be able to tell if a device is being tampered with or has been compromised and set up appropriate measures to replace or recover the device.
Devices inherently collect data that is user specific or location specific that has implications for privacy.
The fact that devices can sometimes have marginal or zero connectivity means the management must be able to take advantage of opportunities when a device is connected as well as to set reminders and queue activities for when a device does become available.
Since the inventory of devices is more problematic and can’t be “dynamically created on demand” a link to the acquisition systems and automatic configuration and security management services is desirable. Monitoring their health and being responsive to impending failure is important whereas a service will fail for completely different reasons.
There are other issues with devices versus service management that can be encapsulated in an abstraction layer.
The Connected Device Management Framework Layer
For many reasons an IoT or IIoT architecture with many devices presents problems for management that need to be abstracted to be effectively managed.
1. The communication layers differ depending on the device. Today there are well over a dozen different protocols and physical layer standards. This number will decline hopefully as the market converges but the different requirements for communication are real and will require different solutions so there will never be a single “IoT” protocol or communication paradigm. Some devices have persistent always-on communication but many devices cannot afford that level of connectivity. Some have marginal connectivity to the point with NFC devices where not much more than presence is communicated. Some devices have mesh capability to help propagate messages from other devices and some don’t. As a result of differing power and physical limitations there is a need for multiple protocols and different connectivity models that will never go away.
2. Some devices have APIs that can be directly communicated with, some are passive devices only reporting information and can take no action, some are only action and don’t report or measure anything. Some talk to a server that is their proxy. Some devices have SDKs. Some have GPS capability and some can only report their proximity to other devices.
3. Due to the variety of manufacturers some devices will only work in a relatively proprietary environment and some are much more standards compliant and open.
Due to all these variations that seem impossible to bridge in the short term it is my belief that the only way to support a variety of devices is through an abstraction layer with support for multiple device types, protocols, connectivity.
WSO2 has created such a device abstraction layer which is called the “Connected Device Management Framework (CMDF)” which allows a variety of standards and proprietary protocols and management interfaces to be added. The LWM2M standard for device management which is an outgrowth of the OMA mobility standard can be supported as well as other standards or even proprietary management can be added into this open framework. I believe other vendors should adopt such a CMDF layer.
The CDMF layer includes management capabilities, device definition, communication and orchestration, data management and understanding relationships of devices and services.
The general management capabilities of all management platforms include things like security, device catalog, upgrading, device health can be abstracted and delegated to specific handlers for different devices. The need for this is important because there is no hope that the vast array of manufacturers will agree to a common standard soon. Even in the case such an agreement could be reached there would still leave billions of legacy devices that may need to be worked with. So, a CMDF is the way to go.
Tiered Data Architectures
Most industrial applications of IoT devices will incorporate the notion of functional and regional grouping of devices. Many IoT devices will put out voluminous amounts of data. Storing all that data in the cloud would represent a 100-fold increase in cloud storage needs. It is not really practical to store all data from all devices for all time and to do so in a single place as the data usually is better used locally.
As an example, imagine all the video feeds from security cameras across a company. Unless there is an incident it is usually not necessary to keep the entire full resolution copy of all those devices for all time. So, when an incident is discovered you might tag more detailed information should be maintained or to do research you may want to pull certain information from a region or all regions but in general after an expiration period you would maintain more and more abstracted versions of the original data.
A management architecture for services or devices should support the notion of regional data stores, regional services and devices as well as being able to catalog devices by tags that represent functional capabilities such as all security devices, all mobile phones, all telepresence devices, all devices in Sales or Finance. It should be possible to tier data along various functional, regional or other criteria as fits the application.
Multi-tiered services / device architecture
There is a need in service and device management to support multi-tiered architectures. The best practice around multi-tiering is that it promotes agility by enabling abstraction of a service or device. The service or device can be replaced at will, improved at a differing pace than the services that depend on it.
So, you can modify the physical device to a competitive device or to a new API to the device or new functionality without having to change the code of all the applications that depend on that device. Similarly if you change the applications that use devices the devices themselves shouldn’t have to change to support the applications.
Multi-tiered architectures started primarily by the need to isolate database design from application design. The database designers could design databases to be efficiently organized to promote maximum performance without impacting the application design. New fields could be added to support new features and existing applications which didn’t need that feature wouldn’t have to be changed. More important they wouldn’t crash or fail unexpectedly when you made changes because they were insulated from changes.
In a similar way it should be the case that devices are abstracted into service APIs or proxies that represent idealized devices or views of a device that insulates you from changes to devices and similarly allows you to change applications without having to change devices.