April 2nd, 2014

The Next Big Thing is Small

Written by
 

The Next Big Thing is SmallOne of the challenges facing the tech community is the addition of tens of billions of Internet-connected devices over the next few years. Currently, this Internet of Things (IoT) is expected to grow from 20 billion connected devices in 2015 to 40 billion in 2020.

That’s a Lot of Things
Estimates vary widely but most agree we have something less than 10 billion connected devices today including computers, handhelds, cars and controller devices such as SCADA and others. So, adding tens of billions more in just a few short years is definitely going to present some challenges.

A Lot of Little Things
And – if you start to think about wearables, RFID and micro/nano-size items, you realize that billions of these devices are going to be quite small. Not just physically but also in terms of capability and capacity. These devices will not have the power or flexibility of a laptop or even a handheld mobile phone.

These new members of the “connected community” will be tiny, single-purpose, low-power devices that do one thing and do it well. And it is likely that the program-ability of these devices will be limited. You might be able to flash the memory or even tweak configurations but a good number of these devices will not be hosts to custom code the way Web servers and handhelds are today.

Yet, we still need these devices to work together – even if only to publish device data, consume data from others devices and react to outside stimulus (lights on/off, heat, air movement etc.) So, how will we do that? How can we get things to interact with each other?

Step-by-Step Programming
Most developers today write “code” by stringing long lists of imperative statements together into a coherent set of instructions for machines. To most developers “programming” is just that – providing step-by-step instructions. This means we take on responsibility for any mishaps along the way, whether they occur due to problems inherent in the instruction set or due to unexpected events outside the instruction set, such as other devices not responding to our requests or sending us unexpected data. Doing this on tiny devices with limited capacity and ability is going to be a problem.

Luckily, there is another way to “program” these devices.

Rules, Not Code
We can also use a rule-based approach to programming. In this paradigm, programmers establish a set of coherent rules that tell the device how to respond to outside stimulus (“if the lights are on do X else do Y” or “if the motion detector reports true then turn on the light” etc.) And that is all you do; you write simple rules and leave the device to its own…. well, devices.

This means “programs” are much smaller (just a set of rules), easier to debug and easier to safely modify. It also means the devices themselves don’t need to do a great deal of work in order to “act” according to the rules.

That’s what I mean by small. The code will be small; the code will be rules.

How Does That Help Us with IoT?
It seems unlikely that we’ll be able to “program” billions of devices to safely and successfully interact with each other if we have to constantly provide step-by-step instructions on how each one operates and how they all interoperate. Instead, we’ll rely on simple devices each of which does one thing well and makes its action history available (as a stream of data, occasional dumps etc.) to other authorized devices.

It is also important to keep in mind that these devices will not be “phoning home” asking servers for guidance on how to proceed. The amount of traffic that tens of billions of new devices might generate if they need to constantly get instructions from distant servers would be massive and a huge waste of time and bandwidth. Instead, most IoT devices will act on their own, making decisions in real time, using the rules provided to them.

So, This is a Big Deal, Right?
This way of thinking about how devices will work and how we will “program” them is a big change for many developers. But not all of them: There are people today who build “low-level” device handlers and other things that do pretty much what I describe here. Motion detectors, security systems etc. all operate on this model (simple rules executed in real time). The difference we’ll see in the near future is that more of us will need to start designing and coding for devices that use this rule-based model.

But yes, this is a big deal.

By the way, I see quite a number of people building “Internet of Things” apps and models still assuming that the devices will be high-powered, fully-programmable computers similar to today’s handhelds and laptops. This is a mistake. While there may be some IoT devices with that profile, I suspect it will be a very small minority of the projected 40 billion devices.

So, start thinking ahead. Start planning for a new way to program devices. Those who start working like this now will have a jump on their peers and competitors. And there is good reason to start contemplating this right away. Rule-based systems will require different training and even different tooling. Think about how this will affect the “test-driven development” movement and related practices. And that’s just one example.

Are There Examples of This “New” Kind of Programming?
Yes, there are. And I’ll pick up that thread in a future post.

(This post, which was originally published on my personal blog, covers material from my recent talk at the API Strategy Conference in Amsterdam. You can see the notes from my talk online, along with the slides and related videos.)

March 26th, 2014

Of Monsters & Men & Machines

Written by
Category API Security, IoT, M2M
 

Monsters Men Machines

In my last post, I talked about IoT and its nascent emergence into our everyday lives, with products like Anki Drive and the Nest Thermostat beginning to get a foothold. I also talked about the need for security, as IoT becomes more present in our day-to-day lives. Today, let’s talk about a few real-world examples where security was an “oh, we didn’t think of that” kinda thing.

Implantable medical devices (think pacemakers, for example) are absolute lifesavers for virtually all recipients. And, as you would suspect, they need to be monitored – usually at a doctor’s office. BUT what if the recipient lives in a rural area (e.g. anywhere in Montana, North/South Dakota, Wyoming)? A quick visit to the office might be out of the question. But there’s an app for that (you knew that was coming, right?) Pop an IP address and wireless on that pacemaker, plug that address into the doctors app and voila! Monitoring via the Internet! Yeah! Only thing is… suppose somebody got a hold of that IP address? And suppose that somebody had access to said app? Monitoring could easily become something far more nefarious – bumping up the heartbeat, slowing it down (either of which may have the same result, mind you). Not too cool.

Or how about using a baby monitor with video? New parents are always going to want to have complete unfettered access to their precious being – and the newest generation of baby monitors not only delivers audio but video and yes, with an IP address, there’s an app for that too! So mom/dad can be anywhere and keep complete tabs on the fruit of their loins. Of course, in the wrong hands, with an IP address and no security, that baby monitor all of a sudden becomes an audio/video surveillance tool. No big deal unless, say, that new mom or dad works in the President’s office, NORAD, banking or any one of a number of businesses where you really wouldn’t want to let sensitive information out via casual conversation around a dinner table – with the baby monitor catching every word.

Finally, how about the car – a ubiquitous item (in many countries) of which the newer ones are just chock-full of various computer systems, some of which talk to each other, some of which don’t, some of which are supposed to talk to each other but don’t (anyone played with the Cadillac CUE lately?). All these systems are there to make the driving experience either better or safer. One of these is simply brilliant – the Tire Pressure Monitoring System (TPMS) reports pressures to the primary automotive ECU, keeping the owner informed of poorly-inflated tires (when appropriate). By definition, these systems have to be wireless – and unfortunately, they are completely unsecured. What if someone was within range (say the car behind you) and used the same set of APIs that power the TPMS to send invalid data to the ECU – thereby potentially shutting down the car or, worse, making it unsafe?

All of these examples sound outlandish, right? And yeah, they are.

Oh and they’re also all true. The remarkable Robert Vamosi details these exploits, along with many others, in his phenomenal book When Gadgets Betray Us (available on Amazon here). Writing at a layperson’s level, Vamosi details time and time again how the emergence of IoT consistently takes security for granted or ignores it completely. It’s a scary bedtime story but worth reading. And it’s worth taking note of the key lesson: In IoT, security is very, very important.

March 10th, 2014

The Internet of Things – Today

Anki Drive CarA quick intro: I’m Bill Oakes, I work in product marketing for CA Layer 7 and I was recently elected to write a regular blog about the business of APIs. I’ve been around the block over the years – a coder, an engineer… I even wrote a BBS once upon a time (yes, I’m pre-Web, truly a dinosaur – roar!) But now I “market things”. That said, I still have a bit of geek left in me and with that in mind, this blog is going to focus not so much on the “what” or “how” when it comes to APIs, their implementations and how they affect businesses/consumers but rather, the “why” (which means, alas, I won’t be writing about the solar-powered bikini or the Zune anytime soon – I mean, really… why?)

For an initial first post, I thought I’d take a look at the Internet of Things (IoT) because it’s something no one else is really discussing today (cough). We are beginning to see the actual emergence of nascent technology that can be called the IoT. First, I’m going to take a look at one particular example – one that’s actually pretty representative of the (very near) future of IoT. Yes, I’m talking about Anki Drive (and if you haven’t heard of Anki Drive, you really should watch this short video).

What’s amazing about Anki Drive cars is that they know WHAT they are, WHAT their configuration is, WHERE they are, WHERE you are… Five hundred times a second (in other words, effectively real time), each of these toy cars uses multiple sensors to sample this information using Bluetooth Low Energy, determining thousands of actions each second. Oh… and they’re armed!

Equally amazing is the fact that kids of all ages “get it”. (By “kids”, I of course mean “males” – as once males hit 15 or so, they mentally stop growing, at least according to my wife. Although, I’ve seen many women enjoy destroying other vehicles with Anki too… but I digress.) Players intuitively know how to use the iOS device to control their cars and after learning the hard way that the “leader” in this race really equates to the “target”, they adapt quickly to compete against true artificial intelligence (AI) and each other. It really is an incredible piece of work and is absolutely the best representation of the IoT today.

So, you ask: “What does this have to do with moi”? Well, imagine if your car could do this kind of computation in real time as you went to work. Certainly, Google is working aggressively on this track but Anki lets you get a feel for it today. (And I’m fairly certain Google is not going to provide weaponry its version.) Still, the real-world application of this technology is still a ways away. Let’s reign in timeframes and take a look at what is happening with the IoT in other industries today.

Imagine that your appliances knew about and could talk to each other. Google, though its Nest acquisition, is working on this with its learning thermostat. My first thought on the Nest was something along the lines of: “What kind of idiot would spend $250 on a thermostat when you can get a darned good programmable one for around $50?” But then Nest introduced the Protect. Simply an (expensive) smoke detector with CO detection built in. Big deal, right? Except that if your Nest Protect detects CO, it makes a somewhat logical assumption your furnace is malfunctioning and sends a command to the thermostat to shut down said furnace. That is the power of the IoT in the real world today. So I bought into Nest (thus answering that previous question) and, yeah, it’s pretty cool – not nearly as cool as Anki Drive but then Anki really doesn’t care if my furnace has blown up and Nest does.

As we see more and more real-world introduction of functional, useful IoT solutions, these solutions will all have one thing in common: they will use APIs to communicate. And what IoT will absolutely require is a solution that ensures that only the right devices can communicate with other right devices, in the right way, returning the right results, with no fear of Web-based (or, technically, IoT-based) threats, bad guys, MITM etc. As solutions roll out, it’ll be interesting to see how many vendors remember that security and performance are not options in IoT – they are 100% essential.

November 29th, 2013

Ending the IoT Protocol Wars

Ending the IoT Protocol WarsIt’s been a while since my last blog post – not least because I have been traveling quite a bit to run Layer 7’s European API workshops together with my colleague Ronnie Mitra. The workshops (part of Layer7′s outreach program via the apiacademy.co) are vendor-neutral and focused on sharing API design and management best practices.

To be honest, I probably learn as much during these workshops as the participants do. It has certainly been striking to watch how our material evolves throughout the workshops. We constantly keep adding and tweaking material, based on what we learn. In particular, I’m struck by the amount of changes my IoT section has been going through.

Here is what I have learned regarding IoT protocols: It’s a zoo out there, with lots of protocols trying to become the next HTTP. And some candidates deploy a formidable array of marketing, making it exceedingly hard to cut through the fog.

My current shortlist of main contenders is (in alphabetical order):

I might add STOMP to that list, just for its simple brilliance. STOMP is a text-based messaging protocol that has recently been extended to allow for binary content. Additionally, I’ve recently started talking with some transportation companies and learning about their use of DDS, which might be another candidate for the shortlist.

In the corner of residing champion, we have JSON/HTTP. Not content to see this protocol pushed into early retirement, advocates have been developing some very interesting approaches that attempt to ensure the continuing relevance of HTTP for asynchronous small messages – WebSocket being the most well-known. Hypercat, Simple Thing Protocol and EventedAPI represent just a small sample of the interesting approaches emerging to support async eventing and messaging with HTTP.

Where does this leave a developer trying to choose the right protocol for that awesome winged steam punk toaster? I don’t really have the answer but there are some documents trying to tease out the differences. Take a look at the MQTT vs. CoAP comparison from 1248.io or the DDS/AMQP/MQTT/JMS/REST comparison from DDS champion PrismTech.

Based on what I’ve learned so far, only XMPP and DDS have significant commercial deployments while MQTT is being evaluated by almost every major vendor I have talked to. While MQTT’s use as the protocol powering Facebook’s messenger is a good demonstration of its scalability, I don’t think this constitutes a proof point for mission-critical commercial deployments. If you know of commercial deployments of MQTT, I’d love to hear about them.

Each protocol has weaknesses: MQTT appears to be weak in security; DDS seems to be complex to scale and has version dependencies; XMPP is considered heavy-weight. But they all have strengths too, of course: DDS has the deployments in the field to prove its relevance; XMPP supports EXI and WebSocket for efficiency and a proven track record; both DDS and XMPP are extremely mature and have built-in security. Given the industry interest in MQTT, I am sure that whatever security problems exist will be fixed in one of the next versions. The one puzzling piece is the absence of CoAP in a commercial deployment. Again, if you know of one, please let me know.

Where do I stand on all of this? Having watched technologies rise and fall, I think it’s very normal at this stage to have multiple contenders trying to improve on HTTP. What I try to keep in mind though is that both bandwidth and computing power seem to be on an ever-increasing trajectory, while at the same time becoming cheaper and cheaper. Reduction in power consumption and increase in battery capacity, mostly driven through mobile, further lowers the bar for mainstream technology to power even small devices. I would not be surprised if, after the initial phase, we continue to see HTTP and JSON being dominant. As geeks, we sometimes get too excited about efficiency gains while losing sight of the fact that, for most products, technology simply needs to be good enough. But I won’t complain if I am proven wrong this time.

And don’t just take my word for any of this. To help you learn more, here are a couple of other articles reviewing IoT protocols:

November 5th, 2013

Thoughts on Trends in IoT & Mobile Security

Written by
 

IoT and Mobile SecurityRecently, I read an article about predicted growth in the Internet of Things (IoT). Extrapolating a previous estimation from Cisco, Morgan Stanley is predicting there will be 75 billion connected devices by 2020. This sort of math exercise is entertaining and has a real “wow” factor but the real question here is: What does this mean for consumers and enterprises?

In recent years, consumer electronics manufactures have started to see the usefulness of building Internet connectivity into their appliances. This enables the post-sales delivery of service upgrades and enhanced features. It also allows mobile apps to control home appliances remotely. This is nothing radical per se, a decade ago I observed a sauna in the Nokia Research Center’s lab being controlled by voice and WML. But this was still a simple one-off integration. As the number of device form factors increases, the complexity of integrating devices grows. The term “anytime, anywhere computing” is usually used to describe this scenario but it isn’t entirely adequate. As a consumer I don’t only want device-independent access to a service – I want the various devices and appliances to work with each other so that smarter interactions can be achieved.

Today, we already see a plethora of connected devices with more-or-less crude connectivity and integration options. Smartphones can sync and connect with tablets, TVs and laptops. Mostly, these are very basic integrations, such as your various devices “knowing” about the last page you read in an eBook, regardless of which device you used. But the number and complexity of these integrations will increase greatly in the coming years.

The Coming Age of Connectivity
One of the main reasons the iPhone revolutionized mobile computing was Apple’s focus on user experience. Since then, mobile vendors have battled to see who could provide the best experience within the device. The next battle will be over cross-device experiences within the broader ecosystem, as users roam from device to device. And in the battle, the big players will keep adding their own proprietary components (software and hardware). The sheer size of these ecosystems will make the opportunity large enough to attract even more mindshare. If you make money – who cares about proprietary protocols and connectors?

But how does this relate to IoT, you may ask – isn’t this just a subset of IoT’s promise? The answer is “yes” but that is how this revolution will work – closer to an evolution where the consumer-driven use cases will be implemented first. Yes, there are other enterprise use cases and we can see many protocols and frameworks that claim to address these requirements. In the end though, I believe most of these platforms will struggle with developer uptake as most of the developer mindshare is found in the big mobile ecosystems. As with mobile, the successful approaches will be the platforms that can offer developers familiar tools and a roadmap to revenue.

It’s clear the big players in mobile, like Samsung and Apple, see a huge opportunity in connected devices. As we move on, we will see more devices get included in each of the mobile ecosystems’ spheres. Increased integration between mobile devices and cars is already in the works. Similarly, among the many notable events at last week’s Samsung DevCon (an excellent show, by the way), several SDKs were launched with the aim of solving specific consumer needs around media consumption in the home. But the impact of increasing connectivity will go beyond these relatively well-understood use cases to encompass home automation, smart grid, healthcare and much more.

Alternative Authentication Methods for the Connected World
In this multi-device, multi-service world, conventional username/password login methods will not be convenient. Advances in the biometric space (such as Nymi or Apple Touch ID) will be relevant here. I suspect that, just as we have seen a bring-your-own-device trend grow in enterprise mobile, we will see a bring-your-own-authentication paradigm develop. As a larger set of authentication methods develops in the consumer space, enterprise IT systems will need to support these methods and often be required to adopt a multi-layered approach.

Ensuring Big Data Privacy in the Age of IoT
Another set of challenges will be created by the enormous amounts of data generated by IoT. Increasingly, connected devices are able to collect and transmit contextual data on users. This information can be highly useful for vendors and users alike. But what happens if data is used for purposes other than those first intended or agreed to? Who owns the raw data and the generated insights? And how is the rightful owner in control of this? Today, there is no general standard available nor are the mobile ecosystems providing adequate privacy protection. Sometimes one gets the feeling that users don’t care but they will probably start caring if and when data leakage starts to make an impact on their wallets.

Meanwhile, Layer 7 will continue to innovate and work on solutions that address the challenges created by IoT, multi-device authentication and Big Data. Oh and by the way, I believe Morgan Stanley underestimated the number, I think it will be double that. You heard it here first…