Azure Functions caught my eye recently, mainly because of the F# support where I was hoping to write some F# based integrations. But the F# support is classified as experimental, so while I learn the capabilities of Azure Functions, I didn’t want to get held up on issues that may be only specific to their support of F#. Once I get my core objective operational via C#, I’ll attempt to rewrite the functions later, and I’ll share that too (in fact I’ll likely just update this post with re-written at some point).
I’m taking my simplest application and migrating that to make use of Azure Functions, it’s the trusty Used Guid service. If you haven’t heard of it… you’re missing out!
Playing with AppHarbor twitter and WebAPI
Background
So in the original WebAPI app, it was straight forward enough process:
The dependencies are:
- DataBase (Read + Write)
- Twitter (Write)
Function Based Architecture
The initial challenge here with the Azure Function approach is off the back of the user request, how to do the Guid lookup. The integrations offered by Azure Functions are designed in a way that it’s INPUT + OUTPUT(S).The first function has to be the input from the user and that’s an HTTP call.
I started thinking about the coordination between multiple azure functions early in this process. I thought the second function could just operate on the back of a new document showing up in the Azure DocumentDB. But upon digging into the documents I could not see any examples of how to “subscribe” to the feed of new documents. After not being able to solve it via experimentation it started to look unsupported. So I went to Stack Overflow to get confirmation (or what I was really hoping to hear: “yes, this is coming soon”.)
That was not the case. The answer now (Sept 2016) is NO: not supported. So the list of supported bindinds in the documentation was accurate and up to date:
So now the first function that takes the http INPUT, needs to have 2 OUTPUTs; DocumentDB and Queue.
Function 1
Input – HTTP
It’s going against the ease of use of the Azure Functions to do a database read and return the failure cause, though I may not have a choice but to do that.
I wrestled with the architectural approach to this problem, and it’s because this problem space is absolutely contrived and doesn’t lend itself to an elegant solution. When you actually step back at the problem domain / business’s requirement 2 users really won’t have colliding data (… the Guid). They would just ask a service to deliver them the next datam of vulue.
So with that I’ll continue on following the happy path, because the core objectives are to get to deployment concerns around functions, and just lay some groundwork here.
Outputs – DocumentDB + Queue
They simplest way to write a DocumentDB document from your Azure Function is to have it as out out object. Now in many cases you only want to write the document if you pass initial validation. It seems valid to just assign null to the out paramters you don’t want to pass data to on the invalid/error cases. To feed data to the subsequent functions, a second out paramter is needed which is the queue.
Code:
Function 2
Output – Tweet
I thought this was going to be the simpler of the 2; I wanted to look at how to get secrets (API keys, OAUTH etc) into the functions. But when I went to write the function, oh that’s right I don’t a 1 step approach to fetch NuGet packages. So making use of TweetSharp to do the authenticated twitter API call, will take a bit of extra time too.
Well I started digging around that code, and to extract out exactly what I need is taking a while. Below is a link to the original code in the WebAPI app, where making use of the library makes producing a tweet quite easy (once configured with authentication).
So the options I’ll investigate later will be:
- The minimum set of code that can do the authentication and post the tweet so it’s all embedded in the 1 function.
- Making use of Azure Logic Apps (which I need to investigate more), but look to offer some abstraction around common integrations.
Original C# code in WebAPI app:
https://github.com/NickJosevski/usedguids/blob/master/UsedGuidTwitter/Logic/Tweeting.cs
Azure Function:
For now just proving can read off the queue. The basic set up is the data on the queue being a string.
With the integration panel looking like this:
Summary
What’s working:
- API endpoint go get user requests in
- Writing to DocumentDB
- Writing to a Queue
- A second function reads from that Queue
Initial Frustrations
The Azure portal is quite nice, the effects, the theming, it does look nicer than the AWS console which I’m much more familiar with. But deep linking into Azure functions doesn’t work as expected, say you duplicate a tab, you either end up back at the dashboard level, or on the create new function screen. Sometimes it would just spin/hang for a while.
Pricing
I wanted to add a quick note on pricing, I’m no expert in this yet, but when I first start playing with the functions, I had a dedicated app instance, that was draining my balance, when I realised I switched to dynamic pricing model which I thought would have been the default.
It’s good to track the cost of running features, especially while trying out new ones, but one thing that kept showing up in the notifications (bell area) was my current balance, it would always try to get my attention, but more often than not the outstanding balance did not chang.
What’s Next?
In the coming posts I’ll be covering the deployment pipeline for these functions, stay tuned.
