IoT Developer Survey: My Point of View

DZone 's Guide to

IoT Developer Survey: My Point of View

JavaScript adoption, OS choice, security, and protocols to consider along with the Eclipse Foundation's recent IoT Developer Survey.

· IoT Zone ·
Free Resource

A few days ago, the Eclipse Foundation published the report of the last IoT developer survey sponsored by the foundation itself with IEEE IoT and Agile IoT. This survey has as main objective to understand what are the preferred technologies used by developers in terms of languages, standards and operating systems; furthermore, it shows what are the main concerns about IoT and how companies are shipping IoT solutions today.

Great content about this report was published by Ian Skerrett (Vice President of Marketing at Eclipse Foundation) on his blog and on slideshare with a summary of all main information about it.

I'd like just to add my 2 cents with some absolutely personal considerations about the results.

Companies are Investing...

Regarding how companies are delivering IoT solutions, it's clear that the IoT market is growing. A lot of companies already have IoT products in the fields and the others are planning to develop them in the coming months. It's not a surprise, other than a buzzword, the IoT is a real business opportunity for all companies strictly related to the embedded devices (silicon vendors, OEMs, ...) or software companies (for the cloud and application side) which are rapidly changing how their business operates.

Security and Interoperability: the Big Concerns

The result related to the main concerns about IoT is very clear: people and companies are worried about security. All data flowing from our personal life or owned by companies to the cloud need to be protected in order to avoid theft. The concern about security is strictly related to software protocols (i.e. SSL/TLS, ...) and hardware stuff (i.e. cryptochip, ...), and today it seems that a good solution isn't available. The same goes for interoperability: having a lot of IoT standard protocols means having NO standard protocols. A lot of consortiums are trying to define some standard specifications and frameworks in order to define a standard but they are too much; all big companies are divided in different consortiums and some of them are part of more then one. This is a big deal, as for protocols... it means NO standard.

Developers Prefer Java and C... What About JavaScript ?

It's not a surprise that Java was the most preferred language and C was the second. Java is used in a lot of cloud solutions which are based on open source products, and C is the better language for developing on the devices side with great performance at low cost (at least from a hardware point of view). The first strange position is that JavaScript is the third most used language. I hope this position is related to its huge usage with NodeJS on the server side and not as "embedded" language on devices... I'm scared about that.

Protocols: the Current Know-how is Leading

Now, the protocols...

Having HTTP/1.1 as the first most widely-used protocol is really because today it's the only well known protocol in the developer world. In order to develop and deliver an IoT solution with a quick time to market, companies leverage on internal know-how and sometimes they don't invest to figure out how other protocols work and if they have other advantages. It explains this position to me, thanks to HTTP/1.1's simplicity and its ASCII/text based nature. A lot of developers don't like binary format so much. Last point is that the REST architecture is a very good solution in a lot of scenarios, and HTTP/1.1 is the most used protocol (the only one ?) for that.

MQTT and CoAP are used a lot thanks to the available open source projects and their simplicity; MQTT is very lightweight and works great on tiny embedded devices, CoAP tries to overcome some of HTTP/1.1's disadvantages (i.e. server push, observer, ...) with new features and its binary nature.

A lot of developers are scared about AMQP because I have to admit it's not so simple like the previous ones but it's powerful and everyone should give it a try. If you want to start with it, you can find a lot of links and resources here.

I'm surprised by the fourth position of HTTP/2.0 ! I mean ... how many developers know, love and use HTTP/2 today ? I was surprised by this high position ... I expected it behind "in-house, proprietary", AMQP and XMPP. I suppose that companies are prototyping solutions using this protocol because they think that thanks to the HTTP/1.1 knowledge it's quite simple to move to the next version : I think it's totally wrong, because HTTP/2.0 is completely different from HTTP/1.1. I love it ... I'll invest in it.

OS: Linux and RTOS on Bare Metal

Regarding operating systems, the first position for Linux isn't a surprise but we have to consider it both on server side and devices side (even if embedded devices based on Linux are a lot). The other OS are only for embedded devices (low constrained devices) so the percentages don't have any help from cloud side. Finally Linux is useful for IoT gateway too (as we know with Kura) even if Microsoft, for example, is investing in its Windows IoT Core and will release an IoT Gateway SDK in the next months.

All the Services in the Cloud

Not a surprise, Amazon AWS is the most widely-used Cloud services provider, but I don't think about their relatively new AWS IoT platform, just all the IoT open source stuff that developers prefer to run on Amazon VMs than Azure VMs.


Here the great news is that the IoT market is growing and developers/companies are investing in it to try to be in the market as soon as possible. The "bad" news is that too many different protocols and frameworks are used,  and the way to interoperability and interconnection is quite long or ... infinite.

amazon aws, amqp, azure iot suite, coap, http, internet of things, iot development, iot protocols, mqtt, protocols

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}