Azure Functions

Azure Cosmos DB – TTL (Time to Live) – Reference Usecase

October 9, 2018 .NET, .NET Core, .NET Framework, Analytics, Architecture, Azure, Azure, Azure Cosmos DB, Azure Functions, Azure IoT Suite, Cloud Computing, Cold Path Analytics, CosmosDB, Emerging Technologies, Hot Path Analytics, Intelligent Cloud, Intelligent Edge, IoT Edge, IoT Hub, Microsoft, Realtime Analytics, Visual Studio 2017, VisualStudio, VS2017, Windows No comments

TTL capability within Azure Cosmos DB is a live saver, as it would take necessary steps to purge redudent data based on the configurations you may. 

Let us think in terms of an Industrial IoT scenario, devices can produce vast amounts of telemetry information, logs and user session information that is only useful until we operate on them and take action on them, to be specific up to finate period of time. Once that data becomes surplus, we need an application logic that purges these old records.

With the “Time to Live” or TTL, Microsoft Cosmos DB provides an ability to have your documents automatically purged from database storage after a certian period if time(which you configured)

  • This TTL by default can be set on a document collection level and later can be overridden on a per document basis.
  • Once the TTL is set, Cosmos DB service will automatically remove the documents when its lifetime is over.
  • Inorder to track TTL, Cosmos DB uses an offset field to check when it was last modified.  This field is identifiable as “_ts”, which exists in every document you create.  Basically it is a UNIX epoch timestamp. This field is updated everytime when the document is modified. [Ref: Picture1]

image

[Picture1]

Enabling TTL on Cosmos DB Collection:

You can enable TTL on a Cosmos DB collection simply by using Azure Portal –> Cosmos DB collection setting for existing or during creation of  a new collection)

TTL value needs to be set in seconds – if you need 90 days => 60 sec * 60 min * 24 hour * 90 days = 7776000 seconds

image

[Picture2]

Below is a one of the reference architecture in which Cosmos DB – TTL would be essentially useful and viable to any Iot business case:

image

[Picture3]

Hope that was helpful to get some understanding. For more references visit:  Cosmos DB Documentation

Azure Functions App–Run OnDemand Serverless code – a path way to Serverless Computing

June 18, 2017 App Service, Azure, Azure Functions, CosmosDB, Microsoft, Resilliancy, Scalability, Windows Azure Development, Windowz Azure No comments

Azure Functions is a new cloud solution from Azure that would let you execute small pieces code or “functions” in the cloud.  This means you do not have to worry about the infrastructure or environment to execute your little piece of code to solve any of your business problems.

functions-logo

Functions can make development even more productive, and you can use your development language of choice.

Benefits:

  • Pay only for the time your code runs and trust Azure to scale as needed.
  • Azure Functions lets you develop serveries applications on Microsoft Azure.
  • Supports wide variety of development language choices , such as C#, F#, Node.js, Python or PHP.
  • Bring your own dependencies – you can bring any of your Nuget/NPM dependencies for your functional logic.

What can we do with Azure Functions?

Azure Functions is a very good  solution for processing data, integrating systems, working with the internet-of-things (IoT), and building simple APIs and micro services.

Functions provides templates to help you  get started with some useful scenarios, including the following:

  • BlobTrigger – Process Azure Storage blobs when they are added to containers. You might use this function for image resizing.
  • EventHubTrigger – Respond to events delivered to an Azure Event Hub. Particularly useful in application instrumentation, user experience or workflow processing, and Internet of Things (IoT) scenarios.
  • Generic Webhook – Process webhook HTTP requests from any service that supports webhooks.
  • GitHub Webhook – Respond to events that occur in your GitHub repositories.
  • HTTPTrigger – Trigger the execution of your code by using an HTTP request.
  • QueueTrigger – Respond to messages as they arrive in an Azure Storage queue.
  • ServiceBusQueueTrigger – Connect your code to other Azure services or on-premises services by listening to message queues.
  • ServiceBusTopicTrigger – Connect your code to other Azure services or on-premises services by subscribing to topics.
  • TimerTrigger – Execute cleanup or other batch tasks on a predefined schedule.

Integration Support with other Azure Services:

Following are the services integration supported by Azure Functions app.

  • Azure Cosmos DB
  • Azure Event Hubs
  • Azure Mobile Apps (tables)
  • Azure Notification Hubs
  • Azure Service Bus (queues and topics)
  • Azure Storage (blob, queues, and tables)
  • GitHub (webhooks)
  • On-premises (using Service Bus)
  • Twilio (SMS messages)

Costing:

Azure functions will be charged based on two pricing plans below:

  1. App Service Plan – if you already have an Azure App Service running with Logic, Web, Mobile or Web Job, you can use the same environment for your Azure functions execution without needing to pay for extra resources.  You will be charged based on regular app service rates.
  2. Consumption plan  – with this plan you only need to pay for how long and how many times your functions runs and computational needs/resource usage during that execution time. Consumption plan pricing includes a monthly free grant of 1 million requests and 400,000 GB-s of resource consumption per month.

You can find further pricing related info here

Support and SLA:

  • Free billing and subscription management support
  • Flexible support plans starting at $29/month. Find a plan
  • 99.95% guaranteed up time. Read the SLA

Useful Links: