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

docker, Docker, DOCKER!

My first run of the Docker Tutorial Live has been canceled for today, February 16 at TriJUG, alas, Old Man Winter has intervened and we are expecting snow & freezing rain during the TriJUG meeting time window.  And for those of you who have lived in the South, snowflakes are a cause for major alarm - I suspect the grocery stores have already been raided for bread, milk, eggs and ammunition :-)

The next live event will be DevNexus in Atlanta on March 10 to 12th 2015.   DevNexus is an excellent JUG-organized developer-focused event which basically equates to a great speaker line-up at a great price point.  

For those of you following along at home (not physically making it to TriJUG or DevNexus), please check out the written Docker Tutorial materials - the focus is on the Windows-based enterprise Java Developer.  With our JBoss Tools project, we receive opt-in usage data that shows us that the vast majority of enterprise Java developers run Windows as their primary desktop.  While Docker is a Linux innovation, it can be run on Windows via boot2docker (which includes VirtualBox in its installation).  And Java developers do want to understand how building Docker images and running containers could impact their future toolchain and workflow.

I wrote the tutorial documents in markdown (many thanks to Pete Muir for helping my formatting) and stored them in github to make them "forkable" - hopefully allowing anyone who wishes to run their own Docker Workshop use the materials and perhaps even send back a pull request.

Getting Started with Docker, boot2docker, on Windows for the Java Developer

Adding MySQL and additional tips for Java EE on Docker

Once you have a comfort level with Docker builds and runs...then it is time to learn one of the orchestration solutions - basically tools that allow you to start multiple docker containers, linking them, declaratively.  We (Red Hat) are focused on Kubernetes by Google as that piece of the infrastructure.  Check out this short recorded demo of Kubernetes in action.

New Technology Learning Process

I love learning.  I was a curious child and became an even more curious adult.  When it comes to all sorts of enterprise-related software development, I really wish to know what a new technology or technique might bring to the table.

One trick that I will use on myself is to sign up for a presentation as that will force me to learn the technology (or technique) well enough to at least get through a 60 to 90 minute presentation and demonstration...with a hard deadline.   The demonstration being the key thing for me - I tend to work backwards from the demos to the slides - so that the slides reflect what I can actually show off in the demos.

In the last few years, the set a presentation date trick was how I learned:
- Platform-as-a-Service and cloud computing in general
- HTML5
- Vert.x (minute 46)
- Apache Cordova (Phonegap)
and now I am doing it with Docker for TriJUG and DevNexus.

My basic learn something new technique is as follows:
1) 30 seconds: when I first hear about something check the term out on Wikipedia (e.g 6LoWPAN)
2) If the term is so new or esoteric that wikipedia does not have a entry, search Twitter
3) 5 minutes: try to find a sub-10 minute YouTube video on the subject.  
4) 30 minutes: find a decent tutorial/getting started guide - these are very critical to my learning path - therefore I try to craft my own tutorials when possible.
5) 1 hour: find some decent examples - I am definitely a learn by example kind of person.  Some folks call it a "copy & paste" programmer.  As part of my first hour or three of learning...finding some good examples and "playing" with the new technology is critical.  That early feeling of success is a huge motivational factor.  And if the examples fail, then you feel challenged.
6) Look for the deeper dive presentation on YouTube or if I am lucky, seeing it presented at a conference.  I find that the way someone presents the high points of a technology - the advantages and its warts is very helpful in my initial "wrapping my head around it".
7) Find the forums, the better technologies should have a community forum, perhaps a simple Google Group and/or tags out at StackOverflow.  I like scanning through the questions as that gives you a feel for how the technology is being used in the real world.  You can then compare the use cases to your own needs.   I use this same basic technique when reading reviews - does the reviewer (question asker) think as I would?

What is your learning process? How do you prioritize the list of things to be learned and then what steps do you follow to gain some (or great) insight into the new technology?

HTML5, Vert.x, Leap Motion and other goodies

What follows are some of my favorite presentations/demonstrations of some very fun technology.  Leveraging technologies like HTML5 Canvas, Vert.x - a reactive async platform and Leap Motion for gesture UI.   

Multi-user Painting with Vert.x

One of most fun demos I have created was related to Vert.x 2 and allowing for audience participation...in a live demonstration.   Here is a single-user recording of the demonstration I called "paint" as it is a multi-user painting tool.  Audience members use their phones to touch draw via HTML5 canvas something on their smartphone web browser,  those events were captured via JavaScript, sent up to Vert.x running on Openshift and then back to the dashboard running on my laptop's browser.  

This demonstrates not only the power of HTML5 Canvas, but also Websockets and a reactive async platform like Vert.x.  Warning: some of your audience members may draw some rated R or NC-17 images when you are displaying all the individual images via the dashboard, I have had that happen.  I used this demo at Great Wide Open 2014 and Devoxx 2013 (Vert.x is toward the very end). 

Note: Paint is NOT a representation of great coding - it is cool hacking - to make something work with the least amount of pain.  :-)

Leap Motion Finger Painting

Taking advantage of Leap Motion and Leap.js to capture the figure gestures to draw on my desktop browser but also leverage Vert.x EventBus to reflect the gestures out to mobile devices.  I think of it as a "reach out and touch somebody" kind of demo - where I can put my hands on the audience's phones.   In this case Leap's gestures are being sent up "to the Cloud" (Openshift) and then back out to the mobile devices.  Basically the opposite flow from the multi-user painting demonstration above.

 

Finger painting code

Reveal.js and Leap Motion

The Hitchhikers Guide to the JBoss Galaxy presentation has been used on several occasions and different events and I took some time to move it from PowerPoint to Reveal.js.   Based on the experience with gesture tracking and finger painting,  I thought I can hack in simple gesture-based navigation.  It works fairly well but it is hard to capture via video.  

I used the ZiggiHD USB-powered document camera to make the Leap Motion controller visible in the bottom left corner - see video.

 

Docker for Java Developers (Lab)

Docker for Java Developers (Lab) 

We have been working on a hands-on tutorial to help people ram up on Docker!

Containers are enabling developers to package their applications (and underlying dependencies) in new ways that are portable and work consistently everywhere? On your machine, in production, in your data center, and in the cloud. And Docker has become the de facto standard for those portable containers in the cloud, whether you’re working with Amazon Web Services, Google Cloud Platform, or Microsoft Azure. Docker is the developer-friendly Linux container technology that enables creation of your stack: OS, JVM, app server, app, and all your custom configuration. So with all it offers, how comfortable are you and your team taking Docker from development to production? Are you hearing developers say, “But it works on my machine!” when code breaks in production? And if you are, how many hours are then spent standing up an accurate test environment to research and fix the bug that caused the problem? This lab offers developers an intro-level, hands-on session with Docker, from installation (including boot2docker on Windows/Mac), to exploring Docker Hub, to crafting their own images, to adding Java apps and running custom containers. This is a BYOL (bring your own laptop) session, so bring your Windows, OSX, or Linux laptop and be ready to dig into a tool that promises to be at the forefront of our industry for some time to come.

The First Tutorial (planning on more in the series)
https://github.com/burrsutter/docker_tutorial

And recommended blogs by Arun Gupta for more concepts:

• Accessing the Wildfly Admin Console
• Hooking up a MySQL container to the Java EE/Wildfly container