Well, I’ll give it to Microsoft: maybe they have an angle with IoT and enterprise. (Not to mention a rather creepy one.) In the end, though, only time will tell.
WARNING: This post is a commentary. If you’re looking for anything technically insightful, you might be disappointed.
Out of curiosity, I attended an Azure training event a few days ago with a group of colleagues at Microsoft’s Reactor in NYC. Though I’ve played with Azure a few times, I could definitely use more insight. (Since it’s been ages I’ve been to a training event, I also wondered if I was missing out on anything. I’ll admit that the food has gotten better.) Before I start, I commend Microsoft for having made leaps and strides in various respects, particularly with Linux and open source. Also, I should commend the staff who conducted the event. They were very helpful and considerate, and I can only imagine the difficulty in a situation where you are dealing with a room full of disgruntled developers. So, they performed well despite given constraints. Now, the actual event on other hand…that’s a different story. In many ways, it reminded me of my general impression of Microsoft these days: sometimes getting a little too ahead of themselves.
So, the general idea was a good one, introducing people to Azure using a hypothetically fun scenario. In this case, the scenario depicted was one where you help save astronauts on Mars, all through a series of printed-out “classified” tutorials on contemporary topics (IoT, serverless computing, etc.). Okay, decent concept. But the devil is in the details…First, the event space didn’t have enough bandwidth to accommodate the laptops of several dozen people. (As soon as I saw that there were no LAN jacks and that it was WiFi-only, I knew that we were in trouble. It’s common knowledge that between Windows updates and NuGet packages for project builds, you’re gonna need plenty of bandwidth.) Second, the presented materials were sometimes confusing (hyperlinks on printed paper, etc.) and were loosely tied to the general theme. For example, one exercise had us utilizing their face recognition API, which is separate from Azure for some reason. Exactly how this helps stranded astronauts and why we were using pictures of college students, I couldn’t tell you. Finally, the tutorials themselves were simple exercises of copying code and hitting menu options in order to showcase certain technological features.
However, there was no tutorial that gave a general idea of what Azure is really about: being a cloud platform. The basic framework was ignored (spinning up a VM instance, loading a new database, etc.) in order to tout its more niche features. Personally, though, I think that the goal of the marketing team should have been more practical and focused when planning this event. For example, use a theme of a skunkworks team within a larger organization. How could such a team leverage Azure to become innovative? In other words, provide inspiration and ammunition to your base of enterprise users that doesn’t currently use the cloud yet. Though I understand the marketing team’s goal: to appeal to both enterprise AND startup customers for Azure. Obviously, management has envisioned that as the strategy to overtake AWS.
Which, obviously, I think might be a mistake. For example, how many people with Arduinos and Raspberry Pis are looking to create IoT products with .NET Core? True, I’m not an expert, but after spending a few minutes with it, I still can’t see it winning too many hearts and minds. Instead of spreading their resources too thin, it might be beneficial to double-down on their bread and butter, especially since there’s already so much competition in other verticals. After all, there are plenty of enterprise customers to still win over. In fact, I can think of one or two opportunities in niche spaces that are hidden among enterprise users. I know that I don’t have the mile-high vantage point, so I’m not privy to certain details…but since I’m leery of wobbly ladders, I tend to prefer low-hanging fruit. 🙂
So, there’s been so much talk about AI lately, and in particular, there’s a great deal of interest in bots. No, not the Mirai kind (which hopefully isn’t plentiful in the future, despite its Japanese translation). No, I’m talking about the friendly, enterprise kind. You know, the chatbots on Facebook that are supposed to be helpful snippets of AI, capable of booking hotel rooms for you. Of course, I don’t really understand the usefulness of these bots, since there’s no way that a bot could help me find the ideal room faster than my own investigation. In fact, they seem kinda…well…dumb. But these bots are probably not aimed at a self-appointed pariah of social media like myself. Instead, it’s probably meant for those people who are younger (i.e., millenials) and who are more predictable (troves of available marketing data via Facebook, less variety of purchases, etc.). In that case, I suppose that it’s useful for some but not for myself…or is it?
Similar to my reaction to chatbots, I never quite understood the newfound love for Slack. It’s a messenger app…so what? However, as I started to delve more into it, I started to understand its appeal through its extensible functionality, especially to developers. I can create a simple bot (or a basic web service) on my public-facing servers, so I can use Slack to talk with it on my phone and get the status of machines and processes? Okay…that’s kinda cool. (Assuming that your company and networking department embraces the idea of allocating machines just for this purpose. Trust me, I know…that can be a hard sell.) So, maybe, must maybe, I could be down with these chatbots. That way I could use Slack (or Skype) and be hip like the cool kids!
Hmmm…so how I could I actually pitch this one to the brass? Curious, I looked to see if there was already an enterprise version of such a solution, and though I did find one or two, they seemed to be costly and less flexible than desired. So why not just build one cheaply on my own? Since I recently read something about Microsoft’s nascent bot framework and its integration with Skype, I figured that I could start there as a quick way to prototype. After proceeding through a few quick tutorials, it became obvious that a chatbot is nothing more than a tailored RESTful web service, and with that realization, I quickly assembled and got working the prototype that I had in mind.
However, over the next few weeks, I started to realize that it wasn’t viable. One, since this framework is too young to even stand on its own wobbly legs, Microsoft keeps updating the framework and breaking my stable prototypes. As with previous experiences when dealing with a Microsoft gestation, I wondered again if Redmond’s new projects (along with their frenetic and seemingly bipolar updates) are victims of Conway’s Law…Two, I read about how Skype does not and will not support third-party bots that are not publicly registered in their Bot Directory. I’m fairly sure nearly all of the company brass would have a problem with a publicly available chatbot that tells the status of our internal servers. Just a hunch.
After taking a quick look at other platforms, I came away with similar impressions. In the end, I’d say that chatbots are like a lot of new tech these days: lots of potential but some distance away from ultimately being practical.
Okay, it’s true that I’m a little late to Adafruit’s Windows IoT Pack party…but, hey, better late than never, right? So, as stated previously, I set out to create a prototype that would give me the chance to try integrating Windows IoT and Azure. In the spirit of keeping things simple, I just wanted to run a program on the Raspberry Pi (powered by Windows 10 IoT Core) that would poll an Azure web service and react appropriately. Sounds fairly simple, right? Well, for an old dog like me, it took a little longer than expected; in fact, it took the better part of an afternoon.
So, the steps required were:
- Create a SQL Server database within my Azure account, with a test table
- Create an Azure web service and deploy it to my Azure account
- Assemble the Raspberry Pi 2 (i.e., RP2) and the circuit (along with the LED light) for the Blinky project
- Run the Windows IoT dashboard and connect to the running RP2
- Download the Blink project and modify the code so that the pulsing of the LED light would be determined by the results of a call to the Azure web service
- Run a debugged instance of the Blinky project on the RP2 through VS 2015
The first two were easy enough. (In fact, since the Azure Management Portal was redesigned from last year, it’s become even easier than I remembered.) When it came to assembling the RP2 circuit, things started off a little awkward, but after a few moments to recollect faint memories of my EE classes, the circuit finally clicked into place.
However, it started to become a little more difficult when I got to Item #4 and attempted to use the Windows IoT dashboard. First, the RP2 would fluctuate between showing up on the devices list and disappearing from it. (Since the WiFi dongle and the Ethernet cord connected my laptop to the device, connectivity couldn’t have been the issue.) When it did appear, it appeared as a mysterious “minwinpc” device…which, as it turned out, was my RP2. Momentarily, I saw it mentioned as a device with “AJ_” as a prefix, and I learned through further investigation that it’ll assign such a name for you. During one of those fleeting appearances, I recorded the IP address for the RP2 and bookmarked the link that goes to its Management Portal page on the RP2. If I were you, I’d quickly do the same before it disappears (as it is wont to do). The Portal page provides general administration of the device (renaming the device, changing passwords, etc.), but if you want to get down and dirty with it (like changing registry values), it’s best to connect through a Powershell session. If you’re having further troubleshooting issues, this might be the best way to resolve other problems.
After I felt like I had decent connectivity to the running RP2 from my computer, I downloaded the Blinky project, in order to modify the code. However, I was surprised to learn that Microsoft had configured these projects to be early adopters of the Universal Windows Platform (i.e., UWP). On top of requiring the download and install of gigabytes of additional framework libraries, I also had to made slight modifications to my approach for altering the code. (For example, the UWP pushes programmers in general to make asynchronous calls to Windows APIs. There may be workarounds to make synchronous calls, but they’re probably designed purposefully to be cumbersome and undesirable.) I had planned on making calls to the SQL Server database in my cloud, but it also appears that the System.Data.SqlClient namespace is missing by default from UWP. Perhaps it can be added as a NuGet package; I’ll look into it more with future iterations and/or prototypes.
In any case, I changed the Blinky project so that the frequency value for my circuit’s flashing LED light would be occasionally updated by the result returned from my Azure web service; the web service would pull the value from the SQL Server table in my cloud. Once I compiled the project, I made sure to connect VS 2015 to the Remote Machine. (Don’t be a dummy like me and be sure to hit the small arrow to the right of the menu option “Device”. That cost me a minute or two.) Then, after hitting F5, I held my breath as the project’s massive content made its way via WiFi to my RP2…and then, success!
The good news is that an old dog can in fact learn new tricks. Once I had the project working, I used SQL Management Studio to connect and then alter the table in my cloud. And, lo and behold, the frequency of my LED light changed accordingly! Prototype finished and mission accomplished!
Overall, I think that the kit has the potential of being a good introduction for novices, as long as they have an adequate background in Windows software and systems. Plus, some patience is required. Even though I haven’t learned anything really useful or broadly applicable yet, I get the impression that it’ll be easy to acquire a broad base of knowledge fairly quickly with this kit. Of course, my colleagues might suggest that to acquire an actual expertise, one should get an Arduino board and become an avid part of its community (as well as become a patron of Instructables)…but, for a newb like me, I believe that this kit is a decent launch point.
Now onto the next project (though I basically covered that ground with my improvised changes to the Blinky project). I’ll still give it a try, in order to learn anything possible…but I’m really looking forward to the sensors project. One more incremental step to an actual Haunted House!