DEV Community: Manohari Jayachandran

Azure Function Apps in C#: Triggers, Bindings, Durable Functions and Everything I Learned in Production

Manohari Jayachandran — Thu, 11 Jun 2026 12:24:40 +0000

Azure Function Apps are a serverless compute service that runs small focused pieces of C# code in response to events. You write a function, deploy it to Azure, and it runs only when triggered — paying only for the milliseconds it actually executes, not for a server sitting idle 24 hours a day.
I used Function Apps at Blue Yonder as the transformation and processing layer in our integration pipelines. Logic Apps handled orchestration, Service Bus handled messaging, and Function Apps handled the complex C# logic that was too sophisticated for Logic App expressions.

Function App vs Logic App vs API Management
This is the question every Azure engineer faces. Here is the honest answer:
Use Function Apps when you need complex C# business logic, custom data transformation algorithms, high performance compute, or reusable code components across multiple pipelines.
Use Logic Apps when you are connecting existing services visually, the workflow has clear sequential steps, or you need one of the 500+ built-in connectors.
Use API Management when exposing APIs to external consumers, applying rate limiting and authentication, or managing API versioning and documentation.
The real answer for enterprise integrations is use all three together. APIM as the front door, Logic App as the orchestrator, Function App for complex transformations, Service Bus for reliable messaging between them. This is exactly the pattern I built at Blue Yonder.

The Six Trigger Types
A trigger is what causes your function to run. Every function must have exactly one trigger.
HTTP Trigger runs when an HTTP request arrives. Use for REST APIs, webhooks, and callbacks from external systems.
Timer Trigger runs on a schedule using a CRON expression. Use for nightly jobs, hourly reports, and cleanup tasks. The expression "0 0 2 * * *" runs at 2am every day.
Service Bus Trigger runs when a message arrives on a queue or topic subscription. This was my most used trigger at Blue Yonder. It automatically handles retries and dead lettering — your function completing successfully means the message is completed, throwing an exception means it gets retried.
Blob Storage Trigger runs when a file is uploaded to Azure Blob Storage. Use for image processing, file transformation, and document parsing.
Queue Storage Trigger runs when a message arrives in an Azure Storage Queue. Good for simple high-volume task processing at the lowest cost.
Event Grid Trigger runs when an Azure event occurs — like a new user created in Azure AD or a resource deployed in your subscription. Use for reacting to platform-level events.

Input and Output Bindings
Bindings are the most underused feature of Function Apps. They connect your function to other Azure services without writing any connection boilerplate code.
An input binding reads data into your function automatically. An output binding writes data out of your function automatically. You declare what you need in the function signature and Azure handles the connections.
Instead of writing 20 lines of SQL connection code to read a record, you add one attribute to your parameter and Azure injects the data directly. Instead of writing Service Bus SDK code to send a message, you add an output binding and just call AddAsync with your object.
This eliminates entire classes of connection bugs and makes functions dramatically easier to read and test.

Durable Functions — Long Running Workflows
Regular functions run for a maximum of 10 minutes on the Consumption plan. Durable Functions solve this with a pattern that can run for hours, days, or even months.
There are three function types. The Orchestrator coordinates the workflow — calling activity functions in sequence or parallel, handling retries and timeouts, with state automatically checkpointed so it survives restarts. The Activity does the actual work — calling external APIs, querying databases, sending messages. The Client starts the workflow, usually via an HTTP trigger, and returns an instance ID for status checking.
I used Durable Functions at Blue Yonder for integration flows that needed to wait for external system responses — start the flow, call ServiceNow, wait up to 24 hours for a callback, then continue processing. Without Durable Functions this required complex custom state management. With them it was straightforward orchestration code.

Connecting to Azure Key Vault
Never hardcode connection strings in your function code. Use Key Vault references in your application settings instead.
In the Azure Portal under your Function App Configuration, add an application setting with a Key Vault reference as the value. Azure resolves the reference automatically at runtime — your code just reads the setting name as a normal environment variable. Enable Managed Identity on your Function App and grant it the Key Vault Secrets User role. No passwords anywhere in code or config files, ever.

Hosting Plans — Which to Choose
The Consumption plan charges per execution at roughly $0.20 per million calls. It auto-scales automatically but has a 10 minute timeout and 1-3 second cold starts on first call. Perfect for unpredictable traffic and low volume workloads.
The Premium plan costs around $140 per month minimum but eliminates cold starts with pre-warmed instances, has no timeout limit, and supports VNet integration. Use this for production customer-facing functions where latency matters.
The Dedicated plan runs on an existing App Service plan. Use this when you already have App Service infrastructure and want consistent predictable load without the serverless cold start behavior.

Key Lessons From Production
Always use Managed Identity and Key Vault — never hardcode connection strings anywhere.
Service Bus trigger is more reliable than HTTP for processing integration messages — it handles retries, dead lettering, and message locking automatically.
Use Durable Functions for any workflow that might run longer than 10 minutes or needs to wait for external callbacks.
Premium plan eliminates cold starts for customer-facing functions — the Consumption plan cold start is acceptable for background processing but not for real-time user requests.
Keep functions small and focused — one function should do one job. If your function is doing three things, split it into three functions.
Always add local.settings.json to your .gitignore file — it contains your local connection strings and must never be committed to GitHub.

The Complete Azure Integration Stack
This is the architecture that handles enterprise-scale integrations reliably:
External requests enter through Azure API Management which handles authentication, rate limiting, and routing. Logic Apps orchestrate the business workflow using built-in connectors. Azure Service Bus provides reliable messaging between components with dead letter queues for failures. Function Apps handle complex C# transformation logic that Logic Apps cannot express. Azure SQL Database provides persistent storage. Application Insights monitors every step of the entire stack automatically.
Each layer has one responsibility. No layer does what another layer is designed for. This separation is what makes the architecture maintainable and debuggable at scale.

Summary
Azure Function Apps are the C# powerhouse of the Azure integration stack. Serverless execution means zero infrastructure management. Six trigger types connect to every Azure service. Bindings eliminate boilerplate connection code. Durable Functions handle complex long-running workflows.
Combined with Logic Apps for orchestration, Service Bus for messaging, and APIM for the front door — Function Apps complete the enterprise integration toolkit on Azure.

Originally published at TechStack Blog — https://calm-island-0a7b4b30f.7.azurestaticapps.net/
Follow for weekly posts on Azure integration, C#, and cloud engineering.

Azure API Management: Gateway, Policies, Authentication and Everything I Learned in Production

Manohari Jayachandran — Wed, 10 Jun 2026 21:39:43 +0000

Azure API Management (APIM) is a fully managed gateway that sits in front of all your backend APIs. Instead of exposing your raw APIs directly to consumers, every request goes through APIM first. It handles security, rate limiting, transformation, monitoring, and documentation — all in one place.
I used APIM at Blue Yonder as the front door for all integrations on the SIAM platform. Every external system — Salesforce, ServiceNow, third-party vendors — called our APIs through APIM. It gave us one place to control, monitor, and secure everything.

Core Components
API Gateway receives all incoming API calls, applies policies before forwarding to the backend, and returns the response to the caller. This is the actual runtime component that handles every single request.
Developer Portal is an auto-generated documentation website where developers can discover and test your APIs, subscribe for API keys, and get started without calling your team. It is fully customizable with your branding.
Management Plane is the Azure Portal interface where you define APIs, products, policies, and users. You can import APIs directly from OpenAPI specs, WSDL files, Logic Apps, or Function Apps.
Analytics automatically logs every request with response times, error rates, and usage broken down by consumer. Built-in dashboards show you exactly what is happening across all your APIs.

APIs, Products and Subscriptions
Understanding this three-level hierarchy is the key to using APIM correctly.
An API is a group of related operations. For example an Orders API would contain GET /orders, GET /orders/{id}, POST /orders, and DELETE /orders/{id}.
A Product is a bundle of one or more APIs with its own subscription keys and policies. A Partner Product might contain the Orders API and Inventory API with a limit of 5000 calls per day and require approval to subscribe.
A Subscription is a key pair that grants access to a Product. Every caller gets their own subscription key. You can revoke individual keys without affecting any other consumer — critical for security incidents.
At Blue Yonder we had three products:

Internal Product — no rate limit, no approval needed
Partner Product — 5000 calls per day, requires approval
Public Product — 100 calls per day, open signup

Policies — The Heart of APIM
Policies are rules that run on every request or response. Written in XML, they are applied at four levels — Global, Product, API, or Operation — giving you incredibly fine-grained control.
Every request goes through four policy sections in order:

Inbound — runs before the request reaches your backend
Backend — controls how the backend is called
Outbound — runs before the response reaches the caller
On-Error — runs when any policy throws an exception

Here are the policies I used most in production:
Rate limiting — limits a caller to a set number of calls per time window. Returns 429 Too Many Requests when exceeded.
Quota — a hard cumulative limit over a longer period. Different from rate limiting — this counts total calls over the day rather than calls per minute.
IP filtering — only allow requests from specific IP address ranges. Essential for internal APIs that should never be called from the public internet.
Validate JWT — validates an Azure AD JWT token on every request. This is the most important security policy for external-facing APIs. It checks the token is valid, not expired, and contains the required claims.
Set header — adds or modifies a header on the backend request. We used this to pass internal API keys to backend services without ever exposing them to callers. The caller sends their subscription key. APIM validates it then adds the real internal key before forwarding.
Rewrite URL — maps the external URL to a different internal URL. Callers hit /orders/{id} while the backend receives /v2/orders/{id}. This lets you version your backend without breaking existing callers.
Cache response — caches GET responses for a configurable duration. We cached inventory lookups for 5 minutes which reduced backend load by 60 percent during peak hours.
Transform JSON to XML — converts a JSON request body to XML before forwarding to legacy backends. Modern callers send JSON, APIM handles the transformation transparently.

Authentication Options
APIM supports four authentication methods. You choose based on who is calling and what level of security you need.
Subscription Key is the simplest option. The caller passes a key in the Ocp-Apim-Subscription-Key header. Good for partner and internal system integrations where you control both ends.
OAuth 2.0 with Azure AD is the most secure option for external APIs. The caller gets a JWT token from Azure AD first then passes it as a Bearer token. APIM validates it using the validate-jwt policy. The token contains the caller identity, roles, and permissions. Use this for all user-facing apps and B2B enterprise integrations.
Client Certificate (mTLS) requires the caller to present a certificate instead of a password. APIM validates the certificate thumbprint. We used this at Blue Yonder for banking integrations where the highest security was required.
Basic Authentication passes username and password encoded as Base64. Only use this for legacy systems that support nothing else and always over HTTPS. Avoid for any new integration.

Named Values — Storing Secrets Safely
Named Values are APIM variables that store sensitive values like API keys and connection strings. You reference them in policies using double curly braces without ever hardcoding the actual value.
When you create a Named Value you mark it as secret. The value is encrypted at rest and never visible in the portal after saving. Best practice is to link Named Values directly to Azure Key Vault so secrets rotate automatically without any policy changes.

Versioning and Revisions
Versions handle breaking changes. You run v1 and v2 simultaneously at different URLs. Callers choose which version to use and you retire v1 only after all callers have migrated. No forced upgrades.
Revisions handle non-breaking changes. You create Revision 2 as a work in progress that is not live yet. Make and test your changes safely. Promote to live when ready. Instantly roll back to Revision 1 if something goes wrong.
This is how we deployed all APIM changes at Blue Yonder — zero downtime, zero caller impact, instant rollback capability.

Monitoring and Tracing
Every APIM request automatically logs the timestamp, caller IP, subscription key used, operation called, response time, and HTTP status code.
The most useful debugging tool is request tracing. Add the Ocp-Apim-Trace: true header to any request and the response includes a full trace of every policy step — exactly what data entered each policy, what came out, and how long it took. This saved me hours of debugging at Blue Yonder. You can see precisely which policy transformed what and where a request slowed down or failed.
Connect APIM to Application Insights and every request appears there automatically. Set alerts on error rate thresholds or response time degradation to catch problems before your callers do.

The Full Enterprise Integration Pattern
This is the complete architecture I built at Blue Yonder combining APIM with Logic Apps, Service Bus, and Azure SQL:
External System
|
| HTTPS with JWT token
v
Azure APIM
Validates JWT token
Applies rate limiting
Adds correlation ID header
Rewrites URL to internal format
|
v
Azure Logic App
Orchestrates business workflow
Calls ServiceNow and Salesforce APIs
|
v
Azure Service Bus
Reliable async messaging
Dead letter queue for failures
|
v
Azure App Service API
Processes the message
Updates the database
|
v
Azure SQL Database
Each layer has one job. APIM handles the front door. Logic Apps handles orchestration. Service Bus handles reliability. The API handles business logic. SQL handles persistence.

Key Lessons From Production
Always use Named Values for secrets — never hardcode API keys or passwords directly in policy XML.
Apply rate limiting at Product level not Global — different consumers have different needs. Partners get more calls than public users.
Use Revisions for every change — instant rollback has saved production incidents more than once.
Enable Application Insights from day one — you will need those logs the moment something goes wrong in production.
Use the Trace header during development — it shows exactly what every policy does to every request. Invaluable for debugging complex policy chains.
Set up the Developer Portal early — partners and consumers love self-service documentation. It reduces support requests dramatically.
Use validate-jwt for all external APIs — subscription keys alone are not enough. Tokens give you identity, roles, and expiry.
Add circuit breaker on every backend — protect your services from cascade failures when a downstream system goes down.

APIM Tiers
The Consumption tier charges per call with no monthly commitment — perfect for learning and low traffic APIs. The Developer tier costs around $50 per month with full features but no SLA — good for development and testing. Basic at around $150 per month is the entry point for production workloads. Standard at around $700 per month adds VNet support for enterprise use. Premium at around $2800 per month enables multi-region deployment and zone redundancy for global enterprise applications.

Summary
Azure API Management is the professional way to expose APIs in enterprise Azure architectures. One gateway to handle security, rate limiting, transformation, versioning, and monitoring for all your APIs.
Combined with Azure AD for authentication, Key Vault for secrets, Logic Apps for orchestration, and Service Bus for messaging — APIM completes the enterprise integration stack on Azure. If you are building serious integrations on Azure, APIM is not optional. It is the foundation everything else builds on.

Originally published at
https://calm-island-0a7b4b30f.7.azurestaticapps.net/
If you found this useful, follow me for more posts on Azure integration, C#, and cloud engineering.