Azure is pretty amazing, isn't it? It seems like every week something new is being announced by the group that makes me say "wow" (or more like "WOW!"). Even with such amazingness, I have to confess a pretty shocking truth here that I have yet to dive into the depths of this beast in my own coding projects. How is it that I can be writing a blog post for a blog that is based on a technology I haven't even used yet? Well, I am by far and away "the new dev" here at the Azure Development Community Blog and since I have yet to truly dive into Azure, the great team here thought it would be nice to have a perspective from someone who is learning Azure for the first time. So, every month I will be checking in with a post that chronicles my findings and thoughts on this awe-inspiring platform.
So, where to start? It just so happens that I have a .NET console application known as the
that calculates the vote totals from my favorite Microsoft UserVoice ideas and creates a weekly report template. This application currently runs as a scheduled task on my local development machine and fires off every Friday morning at 7AM ET. After it is finished running, I take the produced contents of its output (which is
generated by an XSLT file
) and then create a blog post on my blog,
You can see an
example of a weekly report here
all of them here
if you are interested.
Gettin' Azure wit' It
This is a pretty simple application, so I figured it might be the perfect candidate to bring it to the Azure platform as a way to gain my first experience. There are some benefits to doing so with this particular applicaiton. For one, I don't have to worry about this task if I somehow move to a new machine, or if I go on vacation (like I am actually about to do tomorrow! hah) and am unavailable to be on the machine when the task runs. Incidentally, my current configuration creates the template file so that it lands in a OneDrive folder, so it will sync to my Surface Pro in the case when I am on vacation. But, what happens if OneDrive doesn't sync properly (this happens a lot, I find, unfortunately), or what if there is a power outage while I am gone and the task doesn't run at all?
These sorts of questions lead to the "aha" of Azure. If my task runs as a web job in Azure, then I do not have to worry (as much) about these sorts of issues. This makes the whole process
convenient. The web job will sit in Azure and do the exact same thing as what currently happens on my local machine -- no matter where I am in the world or what machine I am on -- and gets the, well,
done. Furthermore, if I ever change development machines, this will be one less thing that I will have to worry about as a logistical consideration.
So, with that path lined out, what is the path forward to implement an Azure-enabled Vote Reporter? Well, to start with, I was more than pleasantly surprised (elated, even!) to learn
that Azure supports web jobs right out of the gate with a console application
! How awesome is that?! You can simply write your application and publish it to Azure, and it takes care of the rest. THAT is the kind of "WOW!" I am talking about! Once I learned of this great feature, I knew I was on the right path.
However, there were a few more items of consideration discovered during my investigations, which is central to the idea of this blog post. So, without further delay, here are the three major items I will have to consider and solve in moving Vote Reporter to Azure:
Transmission and delivery of generated template.
Currently, my local console application simply opens up Notepad on my machine after the template has been generated, which I then immediately use to create a new blog post. On Azure, I will have to find some way of taking that generated content and delivering it to me. The thought strikes me to explore and use a LogicApp to do exactly this. This LogicApp could take the content/text/data sent to it and store it in Azure File Storage, and then send me an email with a link to the file on completion (
credit goes to Mr. Chilberto for this idea
I found a fantastic article on Azure's documentation and blog
that outlines a great example of a LogicApp that sends email as well. So, I am off to a good start here.
This is kind of a bummer, to be honest. Vote Reporter currently uses a Sql Server LocalDB database instance to load, update, save, and close a .mdf file. Data is stored as a local file and is a (very) convenient way handling data in the application. In fact,
I even back up the database before opening it
. No configuration, no muss, no fuss.
Unfortunately, LocalDB is not supported in Azure
, so I will have to either use Sql Server Azure (with all of the dreaded configuration required for this), or explore SQL CE. I am not sure all of the features and functionality I am using in my EntityFramework implementation work on SQL CE, so Sql Server Azure might be the lesser of two evils here.
If you have not tried
yet, you MUST try this out this very elegant and powerful logging combination. You can think of Seq as a new, cross-platform (browser-accessible) ETW, allowing you to access structured data in your logs in a very powerful and expressive manner. In order to use this in Azure, however,
I will need to dedicate a virtual machine to it and house the Seq server there
. There are plans to make this more streamlined, but this is the logistical reality as it sits today.
So there you have it, my first preliminary investigations into Azure. In the coming months I hope to check in on the above items and provide everyone here with an update on progress, in addition to any interesting findings that I encounter. Until next time, see you in the repos!