Category Archives: Azure

Quick Tangent: It’s Probably for the Best

So, it’s been a while since I talked about indoor navigation. It’s one of those things that I always come back to, especially since that idea for the ghost game always comes back to me now and again. After a conversation with a hardware grad student in a PhD program, I got excited about the idea again and went looking once more for a software solution. As it turns out, Microsoft wants in on the action. After playing with it for a while, though, there’s only one problem: much like other indoor navigation solutions, it doesn’t work exactly.

In my apartment several stories up and which occupies only one floor, I will walk several feet. Then it will suddenly prompt me, asking me which floor I’m headed to. Apparently, it thinks that I’m in an elevator or on an escalator.

With all the difficulties amassed between AR and navigation, it’s no wonder that Project Tango was closed by Google. And it’s no wonder that this Microsoft navigation project apparently hasn’t been updated for a year now. After all, AR and indoor navigation are tough subjects to tackle.

So, it’s refreshing to hear that Microsoft might be rethinking some of its past approaches. After having experimented with their earlier iterations of Windows IoT, I found it an interesting foray for Microsoft. However, I didn’t really believe that it’d be adopted by manufacturers and (especially) developers. It seems that Microsoft has had the same realization recently, and it’s now pursuing a new project to revamp their IoT (and mobile, to some degree) portfolio called Azure Sphere. Now, this initiative could maybe breathe new life into some of that confused tech. If somebody out there creates a kit for Azure Sphere, I’m a taker. I’m looking at you, Adafruit!


Red Shirt Tour NYC

A few weeks ago, Microsoft VP Scott Guthrie stopped in NYC as part of his promotional tour for Azure’s cloud services. Normally, I don’t really care for these long informercials, but I decided to go in this case for two reasons. One, it took place in Cooper Union’s Great Hall, which was something historic I had always wanted to check out. Two, even though I’ve played with Azure’s offerings on occasion, I was curious what Guthrie would highlight in his presentation, especially after friends and colleagues had talked up Azure in the last couple of years. So, I went, and I was surprisingly glad that I did.

A few years ago, when I learned of some of Microsoft’s ambitions in the cloud space, I bought some MSFT shares and thought that they might catch up with Amazon in the cloud space. Impatiently, after a year, I began to have my doubts, and I sold off the shares. If you look at its latest price, that was clearly a mistake. I should have held onto them, and while listening to Guthrie’s presentation, it became painfully obvious as to why. Of course, he talked about the inherent power of Azure, with its various data centers around the world. (Which were all shown in a dramatic video seemingly directed by Michael Bay, with an intensely dramatic score blaring in the background.) However, it was the maturity of the platform, with its various tools and considerations for the user that was impressive.

Even though I’ve only dabbled with cloud platforms, I especially appreciate their raw power and penchant for structure. Even when you create apps that are meant to be deployed for the cloud, it heavily reinforces structure in their templates for developers. For example, if you build a web app within Visual Studio destined for Azure, it refers to queues in the project template by default (which are automatically available in Azure). You might question its need to reinforce such a feature through templates, thinking that the usage of queues in a web app as obvious. “What vital web service that receives a POST wouldn’t automatically queue that request, since the resources to fulfill the request might be temporary unavailable? Who wouldn’t do that?” Oh, you’d be surprised. Let’s just say that such bug-ridden deployments are not unheard of.

First, Guthrie talked about the typical use cases of cloud offerings, like creating and deploying a serverless app with ease or creating a container and deploying it with Kubernetes. Even when he talked about deploying apps to specific data centers, those features were interesting but expected. (I still have mixed feelings about the Azure Portal dashboard, but since that’s an argument about interfaces, that’s an entirely different subject.)

However, I was more impressed when he started talking about the other free tools offered by the platform that were supplemental. For one, its inherent monitoring system was akin to Splunk, and it could be used to monitor and query your entire setup (apps, databases, hosted servers, etc.), and you could customize your system instances with networking rules (like lock port 54545 every morning). Next, the number of devops options seemed more diverse than I remembered (with build options including Maven). There was even a tool which would suggest how you could reduce your expenses, like by consolidating servers and minimizing resources (storage, # of dedicated CPUs, etc.). After watching some examples of machine learning and image recognition, my only regret was that I had no reason to use them in my own projects.

After several years of concentrated effort, they had created an impressive, mature cloud platform that definitely could give Amazon a run for its money. I only had two points of contention. One, this promotional tour was somewhat eponymously named The Red Shirt Tour, since I was told by staff that Guthrie has a certain love for them. Aside from a terrible name for the tour, I would say ditch the symbolic shirt, since that will forever more belong to Jobs. Pick a hat, and in order to reinforce Azure, go for a blue beret instead.

Two, they served Subway for lunch. To which the answer is always no.

Yes, it was free. However, just like if you were offered torture for free, you shouldn’t accept it.

Aside from that, though, I walked away impressed. Nicely done, Guthrie and MS!

You Might Be Doing Too Much at Once, Microsoft

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

Quick Tangent: Dumb Bots

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.

Windows IoT Kit: Initial Impressions

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:

  1. Create a SQL Server database within my Azure account, with a test table
  2. Create an Azure web service and deploy it to my Azure account
  3. Assemble the Raspberry Pi 2 (i.e., RP2) and the circuit (along with the LED light) for the Blinky project
  4. Run the Windows IoT dashboard and connect to the running RP2
  5. 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
  6. 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!