Connect to and consume Azure services

A request arrives and the slow part has to happen somewhere else: an embedding has to be generated, a document has to be indexed, three unrelated pieces of code have to learn that an order was placed. The moment your application hands that work to another component, two questions decide everything that follows. Who holds the work until it is finished, and who initiates the delivery? Azure Service Bus answers pull: the broker keeps each message, a consumer connects and takes it under a lock, and in the default PeekLock receive mode nothing leaves the entity until that consumer settles the message by telling the broker how processing ended. Azure Event Grid answers push: the publisher POSTs one event and is done, Event Grid sends a copy outward to every event subscription whose filter matches (an event subscription being a routing rule that pairs a filter with a handler endpoint and its delivery settings), and the handler's HTTP status code is the entire acknowledgement. Those two sentences are the model the whole domain hangs on, and they are also the trap, because a scenario uses the words message and event loosely while the mechanics decide the answer. If one worker must take each item and prove it finished, that is Service Bus. If several independent handlers each need to be told the same thing happened, that is Event Grid.

Read the four subtopics in order and the stages join up. Queue and process back-end operations with Azure Service Bus settles the pull side of the carry stage: queues that hand each message to one competing consumer, topics whose subscriptions each receive their own copy, the lock a receiver has to settle, and the dead-letter sub-queue a message lands in when it fails too often or grows too old. Implement event-driven workflows with Azure Event Grid settles the push side: filters that live on the event subscription instead of inside the handler, the small set of HTTP status codes that count as a successful delivery, and the two bounds that finally end a failing one. Build serverless APIs with Azure Functions triggers and bindings is the consume stage, where exactly one trigger starts each function and every other service the function reaches declaratively is a binding rather than a client you wrote. Configure and deploy Azure function apps is the host stage, the decisions taken once for the whole app: which hosting plan it runs on, how the code gets in, which application settings the runtime and your code read, and which identity it presents to everything else. One seam runs backwards from consume to carry and is worth learning early: Functions publishes no single retry story, so when a scenario asks what happens to a failed invocation, the answer usually comes from the service behind the trigger.

The same reflex is rewarded in all four subtopics: the behaviour you need is usually a property of the entity, the subscription, or the app, not logic you add to the handler. Redelivery on Service Bus comes from the receive mode and the entity's max delivery count, not from a retry loop wrapped around your processing. Content-based routing on Event Grid comes from filters on the event subscription, not from a handler that inspects every payload and quietly ignores what it does not care about. Reading one document and writing one result comes from an input binding and an output binding, and where a binding names a connection, that name points at an application setting rather than holding the connection string itself. The hosting plan, the deployment method, and the runtime version sit on the function app and apply to every function inside it, so a scenario that needs two incompatible behaviours needs two function apps. When one option adds code and another sets a property, the property is usually the answer.