Future platform for internet of things


Published on

Future platform for internet of things and development tools - presentation from bcfic.org

Published in: Technology
1 Comment
1 Like
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Future platform for internet of things

  1. 1. Future platform for Internet of things Dmitry Namiot dnamiot@gmail.com Lomonosov Moscow State University BCFIC 2011
  2. 2. Future platform <ul><li>As per Wikipedia, the Internet of Things (also known as the Internet of Objects) refers to the networked interconnection of everyday objects </li></ul><ul><li>It is generally imagined as a self-configuring wireless network of sensors whose purpose would be to interconnect all things. </li></ul>
  3. 3. Future platfrom <ul><li>It is simply a paradigm changing. From anytime, any place connectivity for anyone, we will now have connectivity for anything </li></ul><ul><li>T he number of communications-enabled devices will run into tens of billions. One widely quoted statistic is a figure of 50 billion devices by 2010 versus 6.5 billion people. </li></ul>
  4. 4. Future platform
  5. 5. Future platform <ul><li>There are more than enough futuristic scenarios but one question is constantly missed </li></ul><ul><li>Developers, development tools and deployment </li></ul><ul><li>Who and how will put that in production? </li></ul>
  6. 6. Future platform <ul><li>Microsoft CEO Steve Ballmer's famous video &quot; Developers, Developers, Developers! &quot; </li></ul><ul><li>CEO of Nokia Elop:” Developers bring the ecosystem to life and allow us to compete effectively all over the world.&quot; </li></ul>
  7. 7. Future platform <ul><li>“ the only thing you can save is a time” Karl Marx, Capital </li></ul>
  8. 8. Future platform <ul><li>time to market ( TTM ) is the length of time it takes from a product being conceived until its being available for sale. (Wikipedia) </li></ul><ul><li>Key indicator: how does our development tool affect TTM for the products </li></ul>
  9. 9. Future platform <ul><li>Some recent examples: </li></ul><ul><li>Parlay – solves interoperability, does not affect (or even negative affect) TTM – no chances to survive </li></ul><ul><li>HTML5 vs. native applications. Speed of development (deployment) vs. access to the rich features </li></ul>
  10. 10. Future platform <ul><li>CTO of Facebook: “ Facebook has been feeling some pain in supporting so many different platforms. If the company wants to roll out a new feature, it has to add it on Facebook.com, across its various mobile and tablet websites, and across its multiple mobile applications ” </li></ul>
  11. 11. Future platform <ul><li>“ Over the long term, most people really view HTML5 as the future platform that we’re going to be looking to ” </li></ul><ul><li>What is saved here actually: it is time again </li></ul><ul><li>So let us review the existing (and demanded) tools keeping this criteria in mind </li></ul>
  12. 12. Future platform <ul><li>The modern mobile phones are simple and small examples of that ubiquitous computing only. </li></ul><ul><li>With the connectivity for anything we need to scale the whole systems dramatically. </li></ul>
  13. 13. Future platofrm <ul><li>Nowadays we have people posted data into social networks (and getting information from the same networks). </li></ul><ul><li>And what happened when/if some (many, all) things around become social too? </li></ul><ul><li>They (things, devices) need to be social. We as the human in the modern Internet (old internet) are getting more and more information via the social networks. So there is simply no other way for things – they should go social too. </li></ul>
  14. 14. Future platform <ul><li>And very important: it is not about the traffic. Traffic is an issue for video. But there are no processing – just streaming. </li></ul><ul><li>And social network is not only traffic. It is (on the technical level) about the programming connections, social graphs etc. </li></ul><ul><li>It is where we need development tools </li></ul>
  15. 15. Future platform <ul><li>Sometimes people are talking about two types of tasks – Internet of things, as a net of devices and Semantic web – as a set of readable data (including data from devices too). </li></ul>
  16. 16. Future platform <ul><li>From this point of view Internet of things is mostly about connections and Semantic web is mostly about data and addressing of things. </li></ul><ul><li>I think it is not correct. They (data) should not be separated. Internet of things is not about networking at all . </li></ul>
  17. 17. Future platform <ul><li>It is all about getting data from things and make them available for everyone everywhere </li></ul><ul><li>And what is important – not only available via some predefined applications but also available for the future custom processing. Even the processing we unaware about at this moment. </li></ul>
  18. 18. Future platform <ul><li>Lets us see to the requirements from the future services from the technical point of view. </li></ul><ul><li>Internet of things is by the definition the connection of many separate devices that could be either pulled for the new data or publish some new data (e.g. measurements) by themselves. </li></ul>
  19. 19. Future platform <ul><li>From the technical point of view it means only one thing - scalability. </li></ul><ul><li>Our future architecture and its implementation should be ready at the first hand to support more requests; it should be able to work on the much more requests per seconds levels. </li></ul>
  20. 20. Future platform <ul><li>The key moment – the scalability for all. </li></ul><ul><li>Right now: site -> scalable solution (cluster) -> application platform </li></ul><ul><li>Futute: platform for all. By default. The whole web is an application platform </li></ul>
  21. 21. Future platform <ul><li>As soon we entering into our system some artificial elements (e.g. measurement devices, sensors etc.) we can predict much higher level of requests but: </li></ul><ul><li>we can not predict the stable levels for those new request. We simple need to expect that the level of requests could be varied in the relatively big boundaries. </li></ul>
  22. 22. Future platform <ul><li>Today – DDOS </li></ul><ul><li>Tomorrow – just a peak for sensors in the network </li></ul><ul><li>Detection should be automated </li></ul>
  23. 23. Future platform <ul><li>In the most cases our system will get write requests for saving raw data from our things. </li></ul><ul><li>And it will get read requests from the analytical systems either for getting raw data for the future processing or for the updating some analytical information. </li></ul>
  24. 24. Future platform <ul><li>What kind of actions caused the main loading for the current social networks? </li></ul><ul><li>Any forms of status changing from the participants (user writes a new message, sends friends requests, posted photo, changed place etc.) </li></ul><ul><li>We will see absolutely the same picture with our sensors. Just with the big multiplications. </li></ul>
  25. 25. Future platform <ul><li>The main difference from the current state: lack of the predefined structures. </li></ul><ul><li>We will have many different things in our system the task for presenting/saving data within some common (one size fits all) schema is absolutely useless. </li></ul><ul><li>We have to have deal with the schema-less data. </li></ul>
  26. 26. Future platform <ul><li>Because our data is schema-less and they will present completely different systems (think for example about the different sensors) we need some solutions for describing metadata. </li></ul><ul><li>Simply, having in our persistent store a lot of various measurements for example we should be able to say what means what, what kind of measurements we have in our store etc. </li></ul>
  27. 27. Future platform <ul><li>And as soon as new set of sensors (read -measurements) could be connected any time we need some way to describe that new set of data. </li></ul><ul><li>It means that our data should be self-descriptive - each record/chunk of records contains not only raw data but a metadata too </li></ul>
  28. 28. Future platform <ul><li>Now let us talk about the possible processing for data. </li></ul><ul><li>As soon as we spoke above about socializing connected things we should think about the same types of the processing (on the abstract level) the modern social networks have right now. </li></ul>
  29. 29. Future platform <ul><li>Right now there are two main things: requests over the social graph and open API for data access. </li></ul><ul><li>Mapping these things to our net of connected devices we can define two elements: request mashups for measured data and again open API for data access. </li></ul>
  30. 30. Future platform <ul><li>Wikipedia highlights the clear benefits of mashups. </li></ul><ul><li>In Web development, a mashup is a Web page or application that uses and combines data, presentation or functionality from two or more sources to create new services. </li></ul>
  31. 31. Future platform <ul><li>Most of the modern web development examples are mashups </li></ul><ul><li>There is simply no other way to go for the future platform </li></ul>
  32. 32. Future platform <ul><li>The term implies easy, fast integration, frequently using open APIs (an interface implemented by a software program that enables it to interact with other software) and data sources to produce enriched results that were not necessarily the original reason for producing the raw source data . </li></ul>
  33. 33. Future platform <ul><li>Yahoo Pipes </li></ul><ul><li>The simplest mashup’s platform </li></ul><ul><li>Underestimated by the community </li></ul><ul><li>Could be a great prototype </li></ul>
  34. 34. Future platform <ul><li>As per API. Here we will practically stay on the same level, just because the education for developers is much more conservative. </li></ul><ul><li>We will see the same REST based approach, where JSON based data will prevail. And the main advantages that will drive JSON - simplicity for its processing in the most languages </li></ul>
  35. 35. Future platform <ul><li>Server side: Hadoop and all the associated solution (like Hbase, Hive and similar projects) will thrive. Measurements data are always good candidates for the MapReduce – relatively simple, independent and good adopted for the parallel processing. Like the current classical examples with log files processing. </li></ul>
  36. 36. Future platform <ul><li>Cloud computing. </li></ul><ul><li>Getting out of the marketing things is a way for obtaining resources dynamically. If we are talking about the web applications is a way for obtaining either extra CPU cycles needed for serving exceeding requests or extra memory for saving exceeding data. </li></ul>
  37. 37. Future platform <ul><li>Leading platforms: </li></ul><ul><li>- Amazon (EC2 for CPU cycles, S3 for storage, Cloudfront for Content Distribution etc.) </li></ul><ul><li>- Google App Engine </li></ul><ul><li>Amazon’s things are easy to use, where Google’s approach could be more flexible, but requires more programming. </li></ul><ul><li>There are no high level tools for both approaches! </li></ul>
  38. 38. Summary <ul><li>Point attention to the problem: future platform creates a demand for new development tools too </li></ul><ul><li>Today’s social networks programming and implementations as prototypes </li></ul><ul><li>Role of mashups </li></ul><ul><li>Telecom and Internet companies are in equal positions </li></ul>