feature article
Subscribe Now

Golgi and the IoT

Or, Does the IoT Demand a Cloud Platform?

We hereby embark on a reverie that commenced before and continued during the writing of this article. And I’m not quite sure if it’s done yet. The evolution of thought practically happened in real time as I tried to explain… stuff. And to draw said stuff. In the end, perhaps this is an etude in defining the Internet of Things (IoT). As usual, it may raise more questions than it answers.

I can’t believe it’s been almost two years since I made a feeble attempt to put some structure behind this nebulous concept of the IoT. Much of my thinking (not to mention the industry) has progressed since then, but I had a discussion recently that forced me to go back to an image I had put together illustrating how I saw the various pieces of the IoT coming together. To a first order, it still feels more or less relevant (although clearer than ever that it wasn’t put together by a true graphic artist).

I reprise the figure below as a starting point, but I’ve de-highlighted the bits I don’t really want to pay attention to in this discussion. I’ve even removed the “hub” (or “gateway”) – not because it’s not relevant, but because it’s a complicating factor that doesn’t really matter. Let’s pretend we don’t need it, shall we?

Figure_1.png 

What we’re left with is a configuration consisting of Things talking to the Cloud. And, critically, Phones that also talk to the Cloud. So data can travel from the Thing to the Cloud; the Cloud can work its deep learning and analytical magic and then present the results to the Phone for us to gaze at admiringly. (Assuming we’re under 40 years old and can read the text.)

But, after talking to Golgi,* I was left with the feeling that maybe it’s not quite so simple. Although, as I write, I must admit I’m still wrapping my head around what follows. Because, in my original thinking, the Cloud-to-Phone communication is bidirectional. Yes, data goes from the Cloud to the Phone, but then, presumably, instructions will go from the Phone back to the Cloud and thence back to the Thing. It’s all one big integrated-but-distributed beast.

Where does Golgi fit then? Golgi enables Phones to talk to Things. They do that by having the Thing talk to Golgi’s Cloud infrastructure, which then talks to the Phone. And vice versa. But they go to pains to clarify that they’re not a Cloud platform.

What that means is that Golgi isn’t implementing the Cloud portion of this figure. Because the goings-on in my conception of the Cloud are defined by the system developer. All of the analytics and algorithms are application-specific. With a convenient platform, it’s easy to configure and build all of this custom functionality, but, regardless of how much work was required, it’s still custom.

How does this compare to Golgi’s Cloud component? The difference is that you can’t control any of what goes on in the Golgi Cloud bits – they’re fixed, and they implement only what’s required to ensure that blobs of data travel reliably back and forth between the Thing and the Phone.

I got to see a demo of Golgi technology in action at the IoT DevCon recently; sure enough, given a collection of Things using a variety of communication modes – even texting (under the hood, using SMS as a channel) – they were able to control the Things from the Phone. In that case, it might seem odd to send the messages way off to the Cloud somewhere, only to have them come back two feet away, but it makes much more sense when the Things are at home and you’re on the train.

Still and all, having seen that, I was scratching my head (while nodding sagely so that no one could see that I was perhaps a step behind). If IoT apps talked to Phones from Cloud platforms (and Golgi wasn’t a Cloud platform), then why was a separate Golgi pathway needed?

Listening to the discussion, my initial takeaway was that this phone communication stuff is actually difficult, and that most of the other systems couldn’t make it work. So Golgi would let you establish a Phone connection alongside your other Cloud implementation. This would look something like the next figure.

 Figure_2.png

This still isn’t particularly satisfying. Even with this parallel path, you still need to be able to view Cloud data on the Phone. So it feels like this parallel path is only for controlling the Thing. Which is consistent with the fact that the communication model with Golgi is remote procedure call (RPC), not publish/subscribe. In other words, it’s command-centric, not message- or data-centric.

Still, communication really happens both ways with Golgi, so this just seems a bit clumsy.

It then occurred to me – literally while writing – that my confusion may all come down to how one defines the IoT. The original figure comes from my conceptualization of the different components of the IoT, and the presence of the Cloud with application-dependent functionality is, to me, a critical element in that definition. Otherwise you’ve simply got a collection of networked equipment.

But what if I backed off on that? What if some guy is making equipment and wants only to be able to control it from a phone from anywhere? No fancy-schmancy algorithms, no wading up to your armpits in pools of big data; just make the dang Phone talk to the dang Thing. Is that too much to ask?

Well, in that case, the whole Cloud platform part of the picture disappears, and you’re left with Golgi as a communication channel. And there’s no ambiguity. The two Cloud entities (custom and Golgi) don’t coexist; they’re alternatives. The following image, to me, makes far more sense.

Figure_3.png 

The question that then comes to mind is, does such a Golgi implementation really represent an IoT instance? I think that this is what’s gotten me swimming a bit – the fact that this is supposed to be an IoT Thing without a real Cloud intelligence component. If my conclusion is correct (and a quick check-in with Golgi seemed to confirm it), then it feels to me like this is simply implementing a Phone as a (very) remote control for a Thing.

That’s not meant as a put-down; I’m sure there’s a ton of hard work that has gone not only into making the communication work via the many ways devices can talk, but also into defining the mechanism that lets developers build the apps that implement that communication. Using dev kits for the selected platforms, developers write programs using Golgi’s APIs and four basic data types, and then Golgi creates the drivers and files required to make this work on the targeted systems. Pretty slick.

But I just can’t visualize the IoT without the Cloud. Why? Because the Cloud is where all this abundance of data is supposed to be transformed into wisdom and peace and love and rock and roll. (Sex and drugs optional.) All that data fusion is what makes the IoT more than the sum of all the Things.

But I could be wrong. If you define the IoT as any distributed system with an internet component – which a Golgi-powered system would definitely be – then you don’t need a “smart” Cloud function. Feel free to opine in the comments below.

 

AFTERWORD: Between writing and submitting this piece, I happened to attend the Sensors Expo conference. One conversation with Anaren had a similar flavor: accelerating the ability to connect a phone to a device. Again, like a remote control. This reinforces a view of the IoT as being “connected devices” that may or may not have intelligent Cloud capabilities. I got the sense from some of the people that I talked to both at Sensors Expo and at DAC that the whole Cloud intelligence thing is still more concept than reality. (I’m sure some Cloud companies would disagree.)

 

*For those of you with medical skills, this will be obvious. For the rest of us, well, it’s not clear if this word has Greek, Latin, Germanic, or other roots. My pronunciation guess was a Hellenic “goal-ghee.” That’s not correct: it’s “Gaul-jee.”

 

More info:

Golgi

 

One thought on “Golgi and the IoT”

Leave a Reply

featured blogs
Oct 16, 2019
The top level of product categories on Samtec.com feature our Connectors, Cables, Optics, and RF pages, which give users a jumpoff point into the four main categories of products that Samtec sells. These pages were first released in 2016 with a very simple approach, to get th...
Oct 16, 2019
The last day of Arm TechCon opened with Charlie Miller talking about Experiences with and Views on the Future of Driverless Cars Technology . Charlie has appeared in Breakfast Bytes before in... [[ Click on the title to access the full blog on the Cadence Community site. ]]...
Oct 15, 2019
As technology advances, it's becoming harder and harder to know what is real and what isn't....
Oct 14, 2019
My working life includes a lot of writing – blogs, articles, conference papers and white papers are typical of what I produce. A common factor of my writing is that it is aimed to be technical and instructive. What I do not like writing is sales pitches. I can accept th...
Oct 11, 2019
[From the last episode: We looked at subroutines in computer programs.] We saw a couple weeks ago that some memories are big, but slow (flash memory). Others are fast, but not so big '€“ and they'€™re power-hungry to boot (SRAM). This sets up an interesting problem. When ...