Build with an Azure free account. Get USD200 credit for 30 days and 12 months of free services.

Start free today

Azure Functions: Less-Server and More Code

Play Azure Functions: Less-Server and More Code
Sign in to queue


In this episode, Dmitry is joined by Jeremy Likness for a discussion of Azure Functions, which provide the powerful capability to merge events and code to quickly deploy micro services directly from Visual Studio or as part of a DevOps pipeline. With a variety of triggers that call the code and bindings that connect code with resources like storage, queues, and databases, functions empower developers to focus on what is unique about their code without having to deal with infrastructure and scaffolding.

Jeremy shares his real world experience building a URL shortening utility to functions and demonstrates how to build a function app from scratch, debug it locally, and deploy it to the Azure cloud. He also dives into Application Insights and the tracking, telemetry, anomaly detection using machine learning and rich reports that are all provided "out of the box."





The Discussion

  • User profile image

    Hi, this is a great example showing the power of Azure functions.  One question I have is regarding the NextId parameter.  As I understand it, functions are automatically scaled, so this function may be called concurrently, meaning that 2 concurrent invocations will initially have the same NextId from the Table.  This will cause both urls to have the same paritition and row keys and therefore the possibility of one of them routing to the wrong url.  It would be a really great addition to the Table API if one could work with truly atomic integer id's. 

    i.e. var id = tableClient.GetNextId("id partition scheme"); //Atomically update and return a unique id for the specified name.

    If we could do the above then we could guarantee that the id used for the Encoding will indeed be unique.

    Many thanks


  • User profile image

    @tartufella: that is a great point! I purposefully did not worry about concurrency in this case because it is my link shortener so I don't plan to be concurrent with myself, but absolutely something to think about in the bigger picture. However, concurrency is handled by the Table Storage in my understanding. When the NextId is loaded, there is a unique concurrency identifier in it (that's why we inherit from the TableEntity class) and this is sent back in the update operation. If the timestamp on the entity in storage has changed, it will throw an exception. So I don't believe you can actually end up with duplicate short URLs unless you explicitly disable the concurrency check. If you haven't already, great description in this doc: Managing Concurrency in Microsoft Azure Table Storage.

  • User profile image

    @JeremyLikness:Thanks so much Jeremy, great point on the Table concurrency, so the worst that could happen is the need to retry the original request.

    I also love the usage of the Azure Resource Management templates, this would make it possible for us as a third party company to provide pre-canned solutions that our customers can import into their Azure environments.

    This cloud stuff is coming along nicely ;)



Add Your 2 Cents