For data-creating objects, we’re set. But there’s plenty of devices we’ve demonstrated that don’t just manage sensor data. Instead, they’re used for autonomous or remote control, like an IoT lamp. Another common process that services provide is a mechanism for multiple devices in an IoT application to communicate and receive events from each other.
If you happen to have a setup where all devices are in the same location, using the same transport, on the same physical network, speaking the same protocol, and within range of each other, it’s possible that they can communicate directly without a service. An example of this would be how Philips Hue lights and switch controls communicate with a local bridge device over Zigbee.
But that’s an uncommon situation these days, and can be very constricting. For example, if you wanted to turn off all the lights in your home, using an application on your phone or computer, you’d need to install a ZigBee modem. And once you get out of that 30-meter ZigBee range, say because you’re at work, or out of town, you’d be completely out of luck.
In the case of the Hue lights, this is solved with an internet-facing IoT service. The Hue bridge chats with all those lights and switches over ZigBee, but will also connect to an online message-passing service at meethue.com. That services forwards events and messages between the bridge in your living room and the phone app. The phone app and light system can independently connect to that messaging service, and the service will broker communication between them, even though the devices cannot connect directly.
Another common scenario is when multiple devices need the ability to publish and subscribe to the same events. Rather than having each device monitor the activity of all the other things, a service makes it possible for each device to use a single, efficient messaging channel which produces and consumes only the events that are pertinent to the particular device.