Azure Functions as natural extensions for existing applications and integrations

Introduction: This article is a continuation of the series of articles starting with the description of SignalR service which was followed by a discussion on Azure Gateway service, Azure Private Link, and Azure Private Endpoint and the benefit of diverting traffic to the Azure Backbone network. Then we started reviewing a more public internet-facing service such as the Bing API. and the benefits it provided when used together with Azure Cognitive Services. We then discussed infrastructure API such as Provider API, ARM resources, and Azure Pipeline and followed it up with a brief overview of the Azure services support for Kubernetes Control Plane via the OSBA and Azure operator. Then we followed it with an example of Azure integration service for Host Integration Server (HIS). We started discussing the Azure FHIR service next. We were reviewing its search capabilities, followed by its regulatory compliance and security policies. Most recently, we discussed Azure Synapse link for Cosmos DB. This article is about connecting all Azure functionalities via extensions that do not affect existing deployments. Specifically, we discuss Azure Functions.

Description: 

Azure does not limit resources to be commissioned only on the public cloud control plane. It is quite flexible and extensible in nature providing vast integration features that allow on-premises resources to be connected to the cloud, resources to be made available to an instance of a Kubernetes control plane, resources that can span Apache stack and a variety of ecosystems. Within the public cloud, the services proliferate to well over a hundred different types and even more SKUs. When existing deployments and assets become immovable or untouchable, it might be mind boggling to find a right home for extra functionality or a module. Azure Functions fills this gap very well without any impact or hindrance to ongoing operations.

For a sample usage of this Resource and its implementation, please refer this catalog and sample code: https://1drv.ms/u/s!Ashlm-Nw-wnWhKYdp9QwpiEacjprGQ?e=1LD6jY. It takes the use case of segregating azure resources under resource groups which are within subscriptions and in turn accounts on Azure. This hierarchy is very useful towards billing and cost management and since the allocations are isolated by subscriptions, this provides a technique to set a property on those subscriptions so that they can be managed independently from others.

The Azure function takes very little resource but encapsulates the logic to something that is specific and required for integration across other existing resource. This provides architects with a low-cost production grade option for deployments that are lightweight and ready for mission critical purposes.

It is also important to recognize where the Azure Functions do not apply. Service Bus, Message broker, message processing architecture and continuous events is a paradigm that is well suited for IoT traffic. Background processing in heavy online transaction systems can also have multiple Azure Functions as delegates instead of actual services but it is harder to study the flow across discrete functions as compared to a service where all the components log to the same destination and the service represent a system driven top-down architecture rather than a bottom-up convenience. If there is a need to run a user-defined action that is outside the scope of any RP or ARM template, then there is an option now to add Functions as part of orchestrated rollout execution. If the resource provider can provide that functionality and manifest via an ARM template, the need to have logic in its own function is eliminated. Similarly, hundreds of extensions are desirable in certain cases while they can quickly get out of hand in others.