1. We are here at GOTOCon Aarhus 2014, I’m sitting here with Todd Montgomery, Todd who are you?
My name is Todd Montgomery, I’m an architect for Kaazing. Previously I was cofounder and CTO of a company called 29West doing high frequency, low latency messaging in the capital markets. Previous to that I’ve worked on many different protocols as well as seen many different high performance systems mostly in financial services, but across different markets as well.
It's definitely a buzzword but it’s not new. We’ve been living with the increasing role of devices in our lives and in our business as well. So while it has a lot of hype and it has a lot of buzzwords attached to it and people are looking at it and trying to figure out is it real or not. The real story is that it’s been here for a long time and we are just now recognizing it, so I look at it as we have to deal with it anyway, I think the boat has left in terms of whether can be capitalized or not, it can be, people are, you can even look back as far as like 2005 or so, and see how devices started to appear and we started to use them. And even previous to that there are lots of things about connecting devices to networks, this has been done for a very long time in the industrial space. So none of it it’s new, we are just really recognizing it, but is it a hype? Yes.
In many ways yes, it’s more interaction, I mean the whole IoT space is very large, so when it comes is not only things that humans interact with, but things that they don’t actually interact with like seismic sensors even healthcare, all different sensors that are attached to a patient. Who is an ICU for example, and capturing that data, that’s Big Data, that’s IoT, that’s a lot of different stuff. So it is also new ways of interaction, watches, wearables, there is a lot of different things there that are really kind of new and will push how we interact with connected devices.
In the industrial space it would be all of the lower level engineers doing things like scaling systems and even wireless systems for reading of different meters and I mean this goes quite far. But even more interesting in that would be things like printer drivers and things that have been around for a very long time and they’ve been connected to LANs for a long time. So those are constrained environments where things are, you know, you don’t have enough resources and be careful with what you do. Your cycles are actually limited, so what do you do in those environments?
Werner: So it really reminds me of 2007 in the mobile space where we had infinite cycles and then you are on an iPhone 1 and you found you had a finite amount of cycles and yet you had to do things.
Yes, you know, constrained environments are one of them, but now we have things like Raspberry Pis, where the amount of compute power that we have, the amount of storage and the amount of RAM is non-trivial, I mean it’s much more then even back in early 90’s that you had or even early 2000’s. So these really aren't as constrained as they used to be, so the game is different, but we still have these devices that are running on limited power supplies, so things like how the radio is used, how the CPU is used, how much RAM is used, these actually have much more of an effect on battery life than other things. And that’s something that you can't just throw away, a device is only good as long as it’s operating, if it can only operate for half an hour a day, that’s kind of annoying.
Werner: So in a way you have hundreds of millions of cycles, but you are not allowed to use them because otherwise your battery goes flat, you still have to optimize.
Yes, you have to think about it and a classic example is on an Android device, is a really good example. Applications that are very memory hungry like a perfect one would be image manipulation, there is techniques there where they don’t use garbage collection for example, they can’t because it will suck the battery dry, because it will thrash very heavily on memory. So there is a lot of different techniques, a lot of the techniques that come from game design are very applicable in many other areas, so it’s just rediscovering other techniques from other disciplines and applying them, if the end result is like battery life or responsiveness for user or richness of UI, those things can borrow a lot of different things from a lot of different disciplines.
Not necessarily, with the devices and the amount of RAM that many of them have, garbage collectors can run just fine, the more RAM you have, the better the garbage collector runs. When you are constrained and your RAM is, or your problem is such that you can’t have a lot of free space, then yes, the garbage collector often has to be circumvented or you know defeated in other words. And that’s not desirable but that’s just what we have. There’s other approaches like iOS has taken, it is automated reference counting, it’s sort of a different form of garbage collection which actually works better in constrained environments, but in general the way that we are going with more RAM, garbage collectors can run quite well, if they are in the right environment.
Werner: So I guess Azul has to bring out the low latency embedded version.
Who knows?
Werner: Maybe, if you are listening I got dibs on it. So I guess in your talk you mentioned that there is no IoT language or IoT system, so what do you think, would it be just a free-for-all, will be anything specific, or can Java be successful in this space.
I think what we are going to see is because it is a space that many have their eye on and want to grab more of and there are so many competing interests and even from standard bodies, there is different interest. You can look at the number of IoT protocols for example, and you’ve got a number of them that are angling for various things.
So languages, runtimes, protocols I think there will not be one single one that will rule them all very quickly, we may eventually kind of drift towards some, but it’s going to be several years, maybe a decade before we really have that. So to sort of look at things now and if you want to be able to take in and interact with many different devices, you can’t assume a single language, you can’t assume a single protocol, you can’t assume a single runtime. So I mean what it really is, is what is driving me, I’m a protocol geek, I design protocols, I’ve implemented them many times, I actually like how different entities communicate at that level, so it’s a great time for me because I see it as kind of resurgence in the interest in protocols which is something I’ve been interested for a number of years.
Absolutely yes, different kinds of ways of looking at that, it’s very interesting that the nexus of what we have now is, just within IoT, different languages and things like that. There is a real microservices resurgence, microservices and the idea of actors it’s been for a long time and implemented in different ways, different languages, but really looking today at the importance of microservices are now playing in traditionally very enterprise heavy environments. I think what we are going to see is a lot more of a model where it’s an m:n scheduler, where you have m number of processes on n number of threads on a set of cores, and so those models have to be efficient.
Coroutines is one way, there is all kinds of other ways of doing scheduling and I mean if you are looking at packet scheduling and other things and ways of doing that, that are a little different. And it will be interesting to see what develops, because languages like Rust and Go and Erlang, they are looking at it from very different perspectives, but from the programming side a lot of developers can use things from one language to another semantically, syntactically no, but semantically yes, very close. So it would be interesting to see how that kind of works its way out in the coming years. It will take a while.
7. So at your talk you also mentioned something called Nuklei, so what’s that?
Nuklei is sort of a toolkit that Kaazing have been playing with and developing. It grew out of our own internal needs, we needed something which was sort of a microservices kind of framework, but very less frameworky, more of a toolkit and we needed it to really talk with protocols and have a very high interaction in that way, and so we decided, well, we're developing this and we are consuming it ourselves and sort of iterating on it, let’s see if anyone else is interested and put it out under an APL license, so anyone can use it with no restrictions and see what we can, just put it out and see what happens, more of an experiment. And we looked at it as more, Kaazing look at things as a protocol, a set of protocols that are composed, and there is a, been a lot of work that has been done and academic side of composing protocols.
But we looked at it as we should be able to put these things together like Legos, you should be able to layer different types of protocols on top one another if you consider them to be connected with a very basic kind of interface, that is common between them, and that’s sort of where we are going as looking more at the protocols side, how to connect these things together and using standard protocols and supporting different ones. At the very least it’s interesting sort of protocol building blocks that can come out but we think that will be a little bit more than that.
And then we took a sort of fresh view of containment, the things that have been done with Docker, there is no reason to have an app server, it just doesn’t make any sense, even if you are doing Java development, I mean that could be maybe a controversial statement for some, but I’m not a traditional Java developer, I look at that as most of that is doing a lot of things that operating systems are already doing. So why not leverage it, Docker is a classic example where it’s going to revolutionize, I think, containment, but I think it also has the chance of really just upsetting the app server market because it’s a much better way of doing things.
It’s on GitHub [Editor's note: https://github.com/kaazing/nuklei ], there is a Kaazing page for the organization, it shows all of our projects. We have a few others as well, we’ve really been very quiet about what we are doing, we are putting these things out, we are telling a few people about them, some other things that are there, we have some interesting protocol testing tools, something called Robot, but it actually is a way of doing testing of protocols and something that we built internally, we needed it to test the implementations of protocols that we’ve done and as doing that integrating with different test environments and stuff like that. We think of it as testing the I in IoT, so it’s kind of neat but to us it makes a lot of sense.
Werner: Well testing and IoT is two buzzwords together in a close space, that’s a good way to end and thank you Todd.
Thank you!