An Enterprise Developer's Journey to Internet-of-Things (IoT)

From Enterprise to Mobile to IoT (Internet-of-Things) Developer

This article by Alok Batra started me thinking about the unique differences between the Enterprise vs Mobile vs IoT development spaces and my own personal journey down this path.  I am sure my thinking will change as my IoT skills and knowledge mature - this is just a moment in time - but I thought writing it all down would be valuable.

Source: https://www.linkedin.com/pulse/becoming-iot-developer-alok-batra

Enterprise: I have primarily been an enterprise Java and .NET developer, building applications that had a browser/web front-end, a middle-tier on the server and a database tier.  Of course there are batch apps, reporting/business intelligence apps, integration via messaging and perhaps ESBs (enterprise service bus) in the average enterprise IT shop.  But at the end of the day, the vast majority of enterprise applications are used to shove data into a relational database and retrieve it back out again, normally using a web browser for data entry and display purposes.   For most of the early 2000's the enterprise web application developer only had to worry about one target desktop OS (Windows) and one target browser (Internet Explorer).   I have also spent time building things in Node.js - and the development model is fairly similar - web UI built in a HTML5 framework interacting with RESTful APIs/services and perhaps instead of a RDBMS taking advantage of a NoSQL db like Mongo.   Besides Java, .NET and Node.js, I have also spent a fair bit of time working with Vert.x - its asynchronous, reactive programming model gives you a result very similar to Node.js based real-time web apps.

Mobile: When it came to learning mobile application development a few years ago, it turned out that a fair bit of the architectural patterns from enterprise web app development could be reused.  For instance, most mobile applications that communicate with a back-end leverage HTTP and/or REST.   The good old GET, PUT, POST and DELETE HTTP verbs that we have been actively working with for 20 years. Building of the mobile front-end could be achieved via the smartphone's web browser or perhaps using something like Phonegap/Apache Cordova - the programming model was basically the same as it was for the average enterprise application.  The biggest learning curve was related to having more than a single target OS, a single target browser client and a single form-factor.  iOS + Safari, Android + Android's native browser and Android + Chrome become critical combinations for us to test our user interfaces on.  At the same time, FireFox and Chrome took marketshare from IE on the corporate desktop.  Responsive design became a thing and many developers simply took advantage of CSS libraries like Bootstrap to help address the differences in screen sizes.  In general, the transition to mobile was relatively easy - as many of the same skills you used in pre-mobile enterprise web application development could still be applied.

IoT:  I have been pushing myself through the IoT learning curve over the last few months.  It turns out that IoT is fairly unique and very different from the mobile universe.   IoT + Enterprise will be a much greater challenge for the following reasons:

1) Hardware: Most every developer has a smartphone, likely running either iOS or Android and those smartphones have all the same basic sensors and capabilities.   In the case of IoT development/prototyping boards, there are dozens of vendors running a myriad of operating systems.  No two platforms have the same sensors and capabilities.  You also have two major classes of a programmable Thing: microcontrollers (e.g. Arduino, mbed) and microcomputers (e.g. Raspberry Pi, BeagleBone Black, Intel Edison).  There are 'hobbyist' or maker platforms such as the insanely popular Arduino and its derivatives such as RFduino, LilyPad or Adafruit's FLORA.  Plus, Linux-based platforms such as the best selling UK-based computer Raspberry Pi (5 million units sold).   There are also many "professional" grade dev boards/kits from Freescale, TI and many others, therefore, the developer will have a whole lot to think about in terms of hardware selection.
How do you choose which of these platforms to invest your limited time and energy? I am still forming opinions about that myself - at this moment, I have the following sitting on my desk: Arduino, Raspberry Pi Model B (1 and 2), Spark Core, mbed LPC1768 and a BeagleBone Black.

Here is the ultra-short (90 seconds) demo teaser video:

Here is a video, drilling down on my exploration of IoT development hardware:

2) Networking: Unlike the average smartphone, the average programmable Thing does not include network connectivity out-of-the-box.  That is changing with companies like Spark pushing hard not only into Wifi-connected programmable controllers like the Core and Photon but also with the recently announced cell-based (think 2G/3G) developer kits like Electron.  For the typical enterprise web developer, having network access is assumed and this particular area is changing VERY rapidly.  In addition, the systems designer must consider power (battery or not) implications of various radios, ethernet and network stacks.

3) Client-side Operating Systems:  The client in the case of IoT is often known as the Edge. The microcontrollers are basically running C/C++ on their chip architectures, there is not really an OS in the traditional sense.  ARM's mbed offers a nice web-based IDE for crafting your C++ code and the "deployment" is a simple drag & drop of the binary to your USB-connected device.  In the case of various types of microcomputers, there are many derivatives of Linux and one of the more interesting flavors is Yocto - because you roll-your-own, including only the packages that you need to support your use case.  The bottom-line here is that unlike "desktop web" with primarily Windows or "mobile web" with primarily iOS and Android, your device-side operating systems will be highly varied and multifaceted.

4) Client-side Programming Language:  In the case of desktop and mobile, you could get by with just knowing HTML, JavaScript and CSS.  It was possible that someone in your IT organization might also know Objective-C or Android Java but in general, you do not need to "go native" for many classes of enterprise-focused mobile apps.  In the land of IoT, with some microcontrollers, you could use JavaScript: Tessel or Espruino.  But in general you will mostly be working with C/C++ in that space.  For the microcomputer class of devices, running Linux, you can get back to more enterprise developer friendly programming languages like Java, Python, JavaScript via Node.js and Ruby.  Even though I have primarily lived in the enterprise Java space and certainly do enjoy programming in Java, I do not expect Java to be the dominate language on IoT-focused devices. My programming preference running on the edge gateways/devices is Node.js at this time.

5) Physical Assembly: The phrase "Hardware is Hard" is tossed about a fair bit.  While I own a soldering iron, I have only recently learned to use it.  I think many enterprise developers will need to partner with someone who specializes in hardware and understands voltage, resistance, capacitance, and RF (radio frequency) intuitively.  Someone who can design the ultimate sensor/actuator/device package, with just the key attributes and capabilities you need.   Someone who is happy to design with Eagle CAD and create custom PCBs (printed circuit board) or at least work with the design house helping you build your custom field-deployed devices.   This is very different than buying your employees an iPhone.

6) Enterprise Architecture: In the desktop web, mobile web and even mobile apps (native, hybrid) we primarily focused on HTTPS access.  While HTTPS is still possible within the IoT universe, it is not the only connectivity protocol - it is one of MANY protocols vying for dominance: MQTT, AMQP, XMPP, DDS and CoAP are all possible candidates - and many of these are messaging-oriented, async pub-sub, not request-response.  Furthermore, some of the devices are simply too low-powered to handle any real encryption for messages.  This is something to be considered in your overall systems design.

7) Ingestion:  It is predicted that the Internet of Things will include billions of connected devices and if you work for a large enterprise, you should have a feel for the volume of trucks, pallets, boxes, warehouses, fork lifts, retail stores, bins, utility poles, meters, EKG machines, etc that are part of your organization.  What happens when many of these normally silent things begin to provide data, every few seconds?  For many enterprises, the average desktop web or mobile app, does not receive vast amounts of inbound data as human employees can only type so fast, but in the land of IoT, you can be overwhelmed with data.  As an enterprise developer, my 'tried and true' weapon of choice, the application server, may no longer be the most appropriate solution - some form of distributed message broker becomes a better solution, allowing you to more easily ingest the sheer volume of data coming your way.

8) Analytics: A traditional, CRUD (Create-Read-Update-Delete) focused enterprise web application, deposits data from your human users into a relational database like Oracle, DB/2 or SQL Server.  Countless technologies, both paid and FOSS (Free Open Source Software), exist for exploring, mining, reporting, dashboarding, etc.  Your web server logs can be digested and dissected using technologies like Splunk or ELK (Elasticsearch Logstash Kibana).  Some of these tools and techniques still apply in the world of IoT.  However, the volume and speed of the inbound data (sensor readings from your manufacturing lines) and the potential need for "real-time" analysis to prevent outages (e.g. motor temperature signals poor performing wheel bearing) may make you reconsider this area of your architecture.   Technologies like Apache Spark Streaming or Apache Storm become much more interesting as potential solutions.


In summary, as of early 2015, Internet of Things (IoT) development is fairly different from today's average enterprise web and mobile app development.   Now, the space is absolutely exploding in terms of new innovations and a massive amount of R&D investment is being liberally applied.  It could be that by the time you need to start exploring the IoT, that the average sensor/actuator device has a 64-bit multi-core processor, wifi connectivity, months of battery life, fits on your fingertip, runs a fairly standard Linux, Java and Node.js giving you a powerful yet simple programmable platform.

iOS APNS & Android GCM Push with Apache Cordova (Phonegap)

Here are my instructions for Hello World, a tutorial with Aerogear's Unified Push Server that allows you to send iOS and Android push notifications to Apache Cordova/Phonegap/HTML5 client applications. If you need help, the best place to hang out is on irc.freenode.net #aerogear channel

The instructions can be found in the readme.txt file and the sample code, while not necessary to follow the tutorial is also available at github https://github.com/burrsutter/hellopush The primary difference between the instructions in the readme.txt and the provided solution is that I added logic to address the OS configuration. If you are an Eclipse user, JBoss is adding a plugin for Phonegap/Apache Cordova project creation - here is a video to see it in action: https://vimeo.com/82204444
https://vimeo.com/81565404

My Aerogear Unified Push Server instance is running at OpenShift - sign-up is free and it only takes a few clicks to select the Aerogear Push 0.X quickstart and you are up and running.

Aerogear Cordova Push Plugin (HelloWorld)

0. getting the Cordova command line tool installed for Mac
sudo npm install -g cordova
cordova -version
3.3.1-0.1.2
http://cordova.apache.org/blog/releases/2013/07/23/cordova-3.html

Cordova Command Line Guide
http://cordova.apache.org/docs/en/3.0.0/guide_cli_index.md.html

npm itself comes from Node.js http://nodejs.org/
npm -version
1.3.25
node --version
v0.10.25
You will also need the Android SDK installed for your OS and in your PATH - commands like "android" and "adb devices" should execute
You will also need "curl", if you type in "curl" and hit return
curl: try 'curl --help' or 'curl --manual' for more information

1. Cordova create has the following sequence: "cordova create folderName bundleID appName"

cordova create hellopush com.burrsutter.hellopush "Hello Push"

2. edit hellopush (bring up your editor) if you open config.xml, you should see <name>Hello Push</name> <widget id="com.burrsutter.hellopush" the widget id becomes the bundle identifier, it must unique identify your iOS app, globally when you setup your iOS provisioning profile, you will need this unique bundle ID

3. cd hellopush

4. cordova platform add android

5. cordova plugin search push

6. cordova plugin add org.jboss.aerogear.cordova.push

7. There is a console.log in the default project as well as in the suggested example code, so make sure to also add the console plugin

cordova plugin add org.apache.cordova.console

and to know the mobile OS install the device plugin

cordova plugin add org.apache.cordova.device

8. index.html - insert the following below <div id="deviceready"> but inside <div class="app"> <font size="6"> <div id="notify">notifications </div> <div id="debug">debug </div> </font>

9. index.js

   successHandler: function (message) {
            var debug = document.getElementById("debug");
            console.log(message);
            debug.innerHTML = "success: " + message;
   },
   errorHandler: function (message) {
            var debug = document.getElementById("debug");
            console.log(message);
            debug.innerHTML = "error: " + message;
   },  
   onNotification: function (e) {
            // alert(e.alert);
            var notify = document.getElementById("notify");
            notify.innerHTML = e.alert;
   },  

    // deviceready Event Handler
    //
    // The scope of 'this' is the event. In order to call the 
    // 'receivedEvent' function, we must explicity call 
    // 'app.receivedEvent(...);'
    onDeviceReady: function() {
        var config = {
                senderID: "492580885002",
                pushServerURL: "https://aerogear-html5.rhcloud.com",
                variantID: "b3852e72-92e1-4b05-a4bd-b549438d4943",
                variantSecret: "13c9daca-457e-4837-bc26-769ba572a940"
        };
        push.register(
            app.successHandler,
            app.errorHandler,
            {
            	"badge": "true",
                "sound": "true",
                "alert": "true",
                ecb: "app.onNotification",
                pushConfig: config
            });
            
        app.receivedEvent('deviceready');
   },

Note: senderID, variantID and variantSecret were all setup in the Push Console at pushServerURL

http://aerogear.org/docs/guides/aerogear-push-android/google-setup/

http://aerogear.org/docs/guides/AdminConsoleGuide/

10. Run "adb devices" to see if an android device is plugged in correctly then cordova run android

this will install and launch the app on your plugged in, developer-ready Android phone/tablet

11. then send a message

curl -3 -u \
"f07c43a6-bb0a-4bb7-a1eb-a368db272212:e2cf19c3-6636-4712-bbe8-26b7c1ac9c09" \
   -v -H "Accept: application/json" -H "Content-type: application/json" \
   -X POST -d '{"message": {"alert":"Hello AeroGear", "badge":1}}' \
   https://aerogear-html5.rhcloud.com/rest/sender

NOTE: this is not wrapping correctly here in Blogger, here is the gist and I included a send.sh to make sending in numerous messages a little easier. Usage: ./send.sh "My Message" 3

where f07c43a6-bb0a-4bb7-a1eb-a368db272212
is your Application ID from the web console
where e2cf19c3-6636-4712-bbe8-26b7c1ac9c09
is the Master Secret also from the web console

Success, send a few more messages, changing the "Hello AeroGear Unified Push!"

Note: If you wish to deploy the app to another Android device, unplug the current one and plug in the new one - use "cordova run android" again and it will deploy to the new device - the app will still function and receive push notifications without being plugged in on USB.

12. Add iOS, if on Mac OS X, with XCode installed (via Mac AppStore is easiest) and you have previously paid your $99 and know how to get around at http://developer.apple.com

cordova platform add ios

13. Setup your provisioning profile:

http://aerogear.org/docs/guides/aerogear-push-ios/app-id-ssl-certificate-apns/ and

http://aerogear.org/docs/guides/aerogear-push-ios/provisioning-profiles/ and

http://aerogear.org/docs/guides/AdminConsoleGuide/

14. Add the variant for iOS via the Unified Push Server web console - uploading the .p12 file and its associated passphrase

15. look under platforms\ios and you should see a Hello Push.xcodeproj - double click on the .xcodeproj

If you see the General tab, double check the bundle identifier of com.burrsutter.hellopush or whatever you made yours

Modify the index.js (in XCode) for the proper variantID and variantSecret from the Unified Push Server console

16. Assuming you have previously registered your plugged in iOS device with the developer.apple.com portal, you can now hit the big arrow and target your device.

When the app installs it should prompt you to accept push notifications.

17. Look for a new installation/device token under your newly added iOS variant in the UPS web console. If you see no instance/device token then something failed.

18. Finally, send a message, it should hit all the android & iOS devices that you have deployed the app to.