I tested preview 1 as well, but that was slightly shaky, so I'm taking another crack at it now. This feature is intended to solve the scenario with hosting your own Functions in a slightly more production grade way. (Still preview, so keep your expectations accordingly in check.) It is based on Docker containers below the hood; make sure that isn't an issue for your hardware, and then you can run your Functions locally to your heart's content. Another great thing for home use is that it doesn't require Windows Server, and will be equally happy running on a Windows 10 box.
In the latest Visual Studio updates there is also
tooling for Functions
, which obviously is a good thing, but this is not to be confused with the
Azure Functions Runtime
. The VS tooling is for developing Functions whereever they are running, and get the into source control, etc. The Runtime is specifically to run Functions in an environment you manage. (Without needing to go all-in with Azure Stack.)
What would be a good use case to test for this, and show why you wouldn't go cloud? After all I usually advocate putting things in the cloud if you don't have a good justification for doing otherwise :)
Like any self-respecting geek I checked out the Black Friday deals, and came across a Philips Hue lightstrip starter kit. (Yeah, I'm late to the smart bulb party.) The interesting part of the Hue package is of course that one can integrate through the API provided, and play around with the system that way. Sure, there's a ready made app as well, but who wants to run code they haven't written themselves :)
This is a fairly short and sweet Proof-of-Concept with three easy steps involved.
Ok, and in what way is this a candidate for Azure Functions Runtime? Well, the API is exposed over HTTP, and that is entirely ok. Slightly sketchy that the "authentication" is based on embedding a username in the uri though. Not to mention how consumer IoT gadgets fare when it comes to security (although I have no reason for suspecting Hue for being the worst in this department). In general you could say it works best when you are on the same network as the Hue Bridge. While you could argue that a single lightstrip isn't a hazard to put online I would rather keep it internal, and have some kind of proxy mechanism for reaching it.
I am aware of publishing through a reverse proxy, doing VPN, and all of that. I want something more lightweight though. I want to be able to publish a simple web page that I protect with Azure AD/B2C/ADFS/something OpenID Connect, and somehow have it trigger something in my home. Trigger you say? Hmmm… A trigger-based invocation of Azure Functions perhaps?
How about having a queue-triggered Function that will in turn do an HTTP-based call to the Hue Bridge? And now you can see how it makes sense having this running on a server in your own environment, and have the Function monitor a queue in Azure :)
While this Proof-of-Concept is intended for a small-scale setup at home you can employ the same pattern in other deployments as well mind you. Professional grade IoT equipment might support other protocols than HTTP, and even baked in support for IoT Edge (
) Those scenarios require thinking about both the bigger picture, and more details than I´m considering here. In short; always try to understand the problem you are trying to solve.
First thing is to create an Azure Storage Queue. (Yes, this part can be hosted in the cloud since it doesn't talk to the Hue directly.)
Why Storage Queues, and not one of the other messaging solutions in Azure? I wanted something simple. I don't need to be able to ingest a million messages per second or anything advanced. It's also dead easy putting messages into the queue directly through the Azure Portal enabling you to test with a minimum of effort.
The next part is to create the Function, and type in some code:
You'll notice that the Hue operates by having you do PUTs with some properties. (GETs are supported too, but like it should be that's for retrieving info, not applying configuration.) Apart from the Internet-unfriendly address to the Hue there's no difference between this experience and editing in the Azure Portal.
You will also probably not be impressed by the amount of verification and "proper" code I do here. Any message at all put onto the queue will trigger a call to this specific lightstrip. You probably want the option to switch it off as well, so a switch-case would be good for that.
End result - you have your IoT home accessible from the Internet, and you don't have to enable your lighs to be controlled by some script kiddie on the other side of the world to be able to have fun on your own :)