At crossroads, IoT calls for paradigm shift in programming

by | Nov 21, 2014

At crossroads, IoT calls for paradigm shift in programming

Last March Node1 had the opportunity to co-host the first European edition of the API Strategy and Practice Conference (APIstrat Amsterdam). The conference was a great success. Kat Borlang, Adam Wiggens, Mehdi Medjaoui and Romain Huet gave wonderful talks. Among this impressive line of speakers there was also Mike Amundsen. Director of API Architecture at the API Academy for CA Technologies, Amundsen is an internationally recognized industry expert on distributed network architecture, Web development, cloud computing and more. During APIstrat Amundsen gave a fascinating talk on how we could tackle the scalability issues that lay ahead of us in enabling the Internet of Things – billions and billions of devices talking to each other and us.

Amundsen’s thesis is in a nutshell that this will only be possible if we code the programmable world with no code. He proposes a rule based approach to programming based on the concept of cellular automata. The concept was originally discovered in the 1940s by Stanislaw Ulam and John von Neumann. Conway’s‘Game of Life’ and Stephen Wolfram’s two-dimensional cellular automation are the most known applications.

In this interview we had the privilege to delve a bit more into the details of his APIstrat keynote speech and ask Amundsen why there is indeed no telling to what we could do if we code without code.

Node1: At the recent APIstrat you gave a fascinating talk about APIs, the Internet of Things and essentially the future of computing. You said that we are at crossroads. Can you elaborate on that?

Amundsen: I think we are at crossroads, because in the coming years we will see an exponential growth of the number of devices connected to the Internet. It’s going to be difficult to manage these billions of devices with the tools, techniques and concepts that we use today to program them. These devices need to be much easier to deal with and it should be much tougher for them to fail.

You’re proposing that we shouldn’t build algorithms for these devices, but program them on the rules based concept of Cellular Automata. Why?

If you look, for instance, at gmail it has tens of thousands of lines of code. Small sensors in the home, utilities sensors in buildings and road sensors can’t have tens of thousands of lines of code. These individual Internet of Things devices just need to know when to turn the lights on and off, etc. This is where the cellular automata pattern comes into play. Cellular automata don’t use statistics, they use sensing. They pay attention to a few things surrounding them in what is called ‘the neighborhood’. The entire programming model is  when the neighborhood changes, the cell changes its behavior. Much of life works this way, too. For instance a flock of birds: if everybody is turning left, you turn left. The so-called intelligence emerges when groups behave, not when an individual behaves. Yet, we don’t program in groups, we program each individual thing.

Alluring to this rule based way of programming you have said that the best bugfree code is no code. Why is it bugfree?

If you can create a simple rule to program a device, programming that device will become inexpensive. The chance that it’s going to malfunction is very low and you can mass produce it for a lot of people. Developing an algorithm is more work, more likely to break and harder to scale to thousands of devices. Think about it this way: if you have a very complicated program and burn that into a home sensing device that is sold millions of times and it turns out there is a bug in it than you have a big problem.

But the cellular automata pattern isn’t completely flawless. You can still make mistakes.

Absolutely, but the likelihood of failure greatly diminishes. So if I write millions lines of code I have way more than a million opportunities to make a mistake. If I write ten lines of code I have a several orders of magnitude less opportunity to make a mistake. At the same time we then have devices that simply pay attention to things around them and have a very low level of responsibility. They are responsible for one thing. It’s also more difficult for them to malfunction in a way that causes a great deal of problems.

APIs are central to enabling the IoT. You’re arguing that we have to create what amounts to a new form of API. Why?

The way we design APIs today are as static function calls between devices. Every device has its unique set of functions. We won’t be able to get devices talk to each other that way. All the devices have to use the same interface. This is what the CoAP protocol does really well. Everyone needs the same interface, but different message formats. That’s a lot of what the hypermedia pattern is based on: same limited API and all the important stuff goes into the message.

Is that already happening?

It’s early on and it’s growing. The people that are working on this are the ones working on hypermedia interfaces for the World Wide Web. There are about half a dozen new formats that are designed to make this possible. Those are the people that I think have the right idea about how to program the Internet of Things. However most of the people I know doing this message based work are not yet focused on the Internet of Things. It’s going to take some time, probably years, before things move into that space.

Can you give examples of these formats?

Most of these formats have actually been done through open source by individuals. The most popular one right now is HAL or Hypertext Application Language that was designed by Mike Kelly and Amazon Web Services just picked it up. That’s the highest profile example. Another popular format that I designed myself is Collection+JSON. Siren, Mason, HAN, UBER and Atom are others. These message based models don’t require you to agree on function names, but do require you to agree on message formats. And that’s going to enable the Internet of Things.

Do you agree that although everybody concurs that the Internet of Things is the future it’s not really taking off?

The implementation is not yet living up with the media hype. The primary reason for this is that the model we are using to organize and code these devices is incorrect. We are already having a hard time getting devices to talk to each other and act in a resilient manner. For example, Google Nest and other similar home systems don’t talk to each other. This indicates that we have to switch what we are doing and move to this automata style model. The other thing to keep in mind is typical market patterns. We’ll start with a bunch of proprietary solutions and it can take a while before we coalesce into the one or two that work for most cases. People don’t remember that HTML and HTTP were not the dominant protocols in the mid ‘90s.

In your APIstrat keynote speech you said that the next big thing is small, small code or even better: no code. If we start working on that than there is no telling where we can end. Why? 

If you create this automata pattern where I can take lots of small items that are simple sensors and arrange them in a way to solve problems, you lower the barrier for people to be creative. I don’t need to learn how to write computer code anymore. I just need to think creatively about plugging these things together. Once we have this ability to start creating things without programming, millions and millions of more people will start doing it. This means that experimentation will be easier and faster, too. That’s why there is really no telling what the future holds, because it’s such a different way of thinking it’s hard for us to imagine what great things are ahead.

Here is Mike Amundsen’s APIstrat Amsterdam talk of last March.

Need help with your API Strategy? Sieuwert is your guy!

Share This