The Internet of Things – drawing parallels between the past and now to predict the future

When I was dabbling with the Internet of My Things in my little hobbyist project, GetFitY’all, there were many tell-tale signs that I had experienced this before, like déjà vu. It prompted me to ask questions like what are the differences between the past and now, and could I possibly predict what the future lies for the IoT ecosystem in my most honest and humble opinion.

Devices had  always been connected one way or another. My earliest experience of mucking around with devices transports me back over 13 years ago during a time when I had a payphone sitting on my work desk. It was a big green device, so much so that it obscured the view of me dozing off behind my desk (how nice to doze off in office to get inspiration on how to get things right with the payphone :P). The payphone had IP connectivity, and my work as the tech lead in this project was to repurpose my company’s own pride and joy, a WAP browser called WAPman from being client-side to a server-side implementation that could send commands to the payphone and also listen to events from the payphone (such as key presses and when the handset is hung up). The communication protocol under the wire was ASN.1. The only way to debug the payload was to eyeball the  data structure which was encoded in hexadecimal numbers. *phew* am I glad I didn’t have to wear glasses after that project. I was treating the LCD display on the payphone as a remote display, I was rendering bitmaps and displaying text through specific data structures encoded in ASN.1 to be sent to the payphone. Some of the optimization involves sending the commands in batches so as to reduce network latency. My biggest issue in my server-side implementation was SCALABILITY!


Scalability was an issue because I had to learn within a very short time frame how to repurpose a WAP browser which was essentially a client app written in C++ and then to expose an API implemented in a socket server. The socket server must handle multiple connections from the payphones and scale out processes on-demand to meet the demands of the payphone connections. I certainly did not have any internet scale back then. I only had 2 Sun Solaris servers powering this up in the customer’s datacenter (DC). The good news was that the project was launched and I lived to tell the tale now. It may be a little exaggeration but I still remember the night when I almost froze in the customer’s DC. What happened was that the customer’s PM said there is no time to deploy my code to the servers the next day, I had to do it that night, so he swung by my office at Amoy Street in Singapore, and off I went in his MPV to their DC at Tai Seng Drive.

Fast forward to now, if I look at the state of things from a macro level, what remained the same is the following: we still have “things”, connectivity, server-side processes and people. However the pace of doing things are a lot faster. Let’s look at this and I’ll try to draw parallels at each of those perspectives

  • “Things” – devices have gotten a lot smaller and personal. From a communication device standpoint, who uses a payphone these days anyway? Do you even have a land-line phone at home? Things are very mobile, and the biggest challenge is battery life.
  • Connectivity – IP connectivity is king, but it is not to be taken for granted, connectivity can still be sparse, just accept that “things” could be occasionally connected. Things can connect via other protocols such as ZigBee, Z-Wave and most recently I heard about the Thread consortium. Connectivity could be one-way, or two-way either directly with the server-side processes or through a device gateway.
  • Server-side processes – the order of the day for server-side processes is that it must be scalable, secure, robust . It only makes sense to have less reinvention of the wheel here because a horizontal platform could make things easier and faster time-to-market for an ISV or SI to build a IoT vertical solution. If I had a good cloud-scale IoT horizontal platform, I could easily repurpose my WAP client app as the logic behind command & control module within a horizontal IoT platform/framework.
  • People – ultimately we are the reason why “things” exist, “things” to be connected, and “things” to be managed and “ruled” through some server-side processes. People pretty much determine if we want our “things” to be connected and produce insights and productivity in many ways to make our lives better. Along with that some of our resistance of course.

There are much more parallels that one could draw between the past and now. As for predicting the future, I’ll keep my humble opinions to a later post. What follows this post is a more technical post about another way in which I am mashing location history data points with my Fitbit activity data points.

Categorized as IoT

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.