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.
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.
