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.

DevNexus Docker for Java Developers: Hands-On Lab

Hello DevNexus 2015
March 12 2015 at 1:00 PM

We have 75 minutes to get your laptop setup with Docker for building and running Java EE applications.   The good news is that you can come to the session prepared.   I made the assumption that most folks will have a Windows or Mac OSX laptop and can use boot2docker which bundles VirtualBox.

The complete tutorial (the core of the overall talk) is available on Github
https://github.com/burrsutter/docker_tutorial
and
https://github.com/burrsutter/docker_mysql_tutorial

If you can, make the attempt at getting boot2docker running on your Windows or Mac laptop prior to the session.  There can be numerous challenges with the installation process, most of which I have tried to describe workarounds in the tutorial document.   Once you have successfully executed:

docker run centos /bin/echo "Hello World"

You are ready to go!

You can also simply install Docker on your Linux machine directly:
Ubuntu: https://docs.docker.com/installation/ubuntulinux/
Debian: https://docs.docker.com/installation/debian/
Centos: https://docs.docker.com/installation/centos/

Publish Subscribe with Spark Core (1+1=3)

Do not make the same mistake that I made.  I purchased a solitary Spark Core and nearly missed the awesomeness of Spark.   You must buy two (2) from Spark.io, Sparks need friend!

A few years ago, I spent many hours with Arduino Uno but did not find it to be that engaging.   By default an Arduino Uno lacks networking and it is not a member of the "Internet of Things" unless you add on an appropriate shield or integrate another component.  At the time, the ethernet shield was somewhat expensive and Wifi fairly challenging.  Fast forward to 2015 and the world has changed dramatically.

I started exploring the Spark Core, the Open Source IoT Toolkit, essentially a Wifi-enabled Arduino for $39 (I have two Photons on backorder and backed the Electron on Kickstarter),  just last weekend.  This included my dusting off my Arduino Uno for testing various resistors, sensors, actuators, logic, etc prior to trying those so things on the Spark.  By this weekend, I wanted to see what it would take to "integrate" a couple of Spark Cores.

The Spark Core is inherently network-aware, in its default state, you must have a Wifi connection even to flash/program it (which does mean it is slower to flash than a USB-connected Arduino).  More importantly, your code can expose variables or functions which can be invoked via a REST API call to the Spark Cloud.  You can use curl to interact with the physical world - for a Java/JavaScript coder like myself...this is pretty incredible.

In addition, you can engage in publish/subscribe messaging between two or more Spark devices.

My thinking is that an intelligent sensor (based on Spark Core) in one location can take readings and based on need (e.g. stock needs replenishing,  conveyor motor offline, temperature is rising), can alert other intelligent actuators to take some action in the physical world.

In this case, I used a Force Sensitive Resistor where its reported value rises based on the amount of pressure (squeeze) you apply and I used the super simple Spark.publish API to send out the event to the Internet.   On the other Spark Core, I set up a subscriber that invokes a simple function to "animate" the servo+gripper also from SparkFun.   Both Spark Cores are sitting on their respective breadboards (the Core ships with a breadboard) and the subscriber core (the gripper) is being powered by the Spark Battery Shield.

Publisher (with Force Sensitive Resistor) Code

#include "application.h"

/*
From the article: http://bildr.org/2012/11/force-sensitive-resistor-arduino
https://www.dropbox.com/s/dodvjb814uxfscs/2015-03-04%2019.59.21.jpg?dl=0
https://www.dropbox.com/s/rduygfde2irjyv7/2015-03-04%2019.59.34.jpg?dl=0
*/

int FSR_Pin = A0; //analog pin 0
int ledPin = 7;
bool wasHigh = false;

void setup(){
  Serial.begin(9600);
  pinMode(ledPin, OUTPUT);
}

void loop(){
  int fsrReading = analogRead(FSR_Pin);

  Serial.println(fsrReading);

  if (fsrReading > 3000) {
    Serial.println(wasHigh);

    if (!wasHigh) {
      Serial.println("sending HIGH");
      wasHigh = true;
      digitalWrite(ledPin, HIGH);
      Spark.publish("burrsqueeze", "HIGH", 60, PRIVATE);
    }
  } else {

    if (wasHigh) { // the state is normally sub-3000
      Serial.println("sending LOW");
      digitalWrite(ledPin, LOW);
      Spark.publish("burrsqueeze", "LOW", 60, PRIVATE);
      wasHigh = false;
    }
  }

  delay(400); //just here to slow down the output for easier reading
}

Subscriber (with Servo+Gripper)

#include "application.h"

/*
 Receives a 'squeeze' HIGH event and closes the servo+gripper to close
*/

Servo myservo;

const bool DEBUG=true;

int minPos = 32;
int pos = 0;
int maxPos = 160;
int ledPin = 7;

int i = 0;

void close_gripper() {
  if (DEBUG) Serial.println("close");

  // close
  for(pos = maxPos; pos >= minPos; pos-=1) {
    myservo.write(pos);
    delay(25);
  }
}

void open_gripper() {
  if (DEBUG) Serial.println("close");

  // open
  for(pos = minPos; pos < maxPos; pos += 1) {
    myservo.write(pos);
    delay(25);
  }
}

void eventHandler(const char *event, const char *data)
{
  if (DEBUG) Serial.print(event);
  if (DEBUG) Serial.print(", data: ");
  if (data) {
    if (DEBUG) Serial.println(data);
    // assume LOW unless HIGH arrives
    if (String(data) == "HIGH") {
      digitalWrite(ledPin, HIGH);
      close_gripper();
    } else {
      open_gripper();
      digitalWrite(ledPin, LOW);
    }
  }
  else {
    Serial.println("NULL");
  }

}

void setup() {
  if (DEBUG) Serial.begin(9600);
  Spark.subscribe("burrsqueeze", eventHandler, MY_DEVICES);
  pinMode(ledPin, OUTPUT);
  myservo.attach(A0);
  myservo.write(maxPos);
}

void loop() {
  delay(400);
  if (DEBUG) {
    i++;
    Serial.print("I'm Alive: ");
    Serial.println(i);
  }
}

Note: I use the Spark Dev (on desktop Atom-based Spark tool) so I include application.h