// Integration

We recently introduced you to API Management, how it maps to architectural principals and why you may consider using it as a producer or consumer of APIs. In this post, we'll be continuing on the story - focusing mostly on the API Management policies functionality.

We now live in a world where multiple systems connect or integrate with each other. This is not new, and has been a technology trend for some time. But - in a world of distributed compute (on the increase, thanks to cloud), and the rise of microservices, we find that we have more and more services that we need to integrate with each other. Integration is typically handled through a couple of routes, including Enterprise Messaging (such as message brokers), as well as APIs (Application Programming Interface). There are many areas that we should consider when building our APIs, and that's what we'll give some thought to in this blog post.

Azure Event Grid routes blob-created events from Azure Storage to downstream handlers, enabling scalable event-driven pipelines where producers and consumers are fully decoupled. This Cloud Drop builds an end-to-end workflow using an Event Grid system topic, subject filtering, an Azure Storage Queue as the event handler, a system-managed identity with the Storage Queue Data Message Sender role, and an Azure Function queue trigger to process and remove each message.

You may have heard of Event-Driven Architectures before, but haven't had the chance to get hands-on and build one as yet. That's exactly what we'll be working through in this blog post!

Azure Functions supports PowerShell Core as a runtime stack, enabling PowerShell scripters to build serverless event-driven workflows without compiled code. This Cloud Drop demonstrates creating an HTTP trigger and an Event Grid trigger function, configuring requirements.psd1 to load the Az PowerShell module, and using a system-assigned managed identity with the Contributor RBAC role to dynamically tag Azure resource groups on creation.

Following hot off the heels of my recent blog post introducing Logic Apps and how I use the technology on cloudwithchris.com, I thought it made sense for the second post to continue the Logic Apps theme. This time, we'll be focusing on Logic Apps preview (sometimes referred to as Logic Apps v2) - the evolution of Logic Apps. Typically when you deploy Logic Apps, you deploy it as a multi-tenanted service. There are some benefits to that, including the serverless capability, so being able to pay per execution rather than an overall infrastructure cost. But what if cost is less of a requirement for you? What if you care more about portability, greater performance, and ultimately control over your environment? If those are more along the lines of your requirements, then you may want to investigate the Logic Apps previewhttps://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-overview-preview. The Logic Apps preview builds upon the Azure Functions extensibility model. Yes, you read that right - Azure Logic Apps is effectively building on top of Azure Functions. Why should you care? Anywhere that Azure Functions can run, then Logic Apps can run.

Many years ago, I wrote a blog post which introduced Logic Apps at a very high level when they were initially released. Ahead of a blog post that I want to write on Logic Apps v2, I thought that it may be worth writing a more thorough recap of Logic Apps as a platform. Logic Apps is a Platform as a Service (PaaS) offering, which allows you to easily build visual workflow integrations. Whether that's plumbing several microservices together, entirely different solutions within an enterprise, or some of the repetitive backend administrative tasks for a podcast or blog site, Logic Apps may be worth exploring.

Chris and Peter cover two cloud design patterns in depth. The External Configuration Store pattern addresses one of the most critical security concerns in cloud development: keeping secrets and connection strings out of source code. They explore Azure Key Vault and Azure App Configuration as canonical implementations, discuss deployment slot behaviour, and highlight the risks of committing credentials to version control. The Claim Check pattern tackles a different challenge — what happens when your message payload exceeds the size limits of your messaging infrastructure (Azure Service Bus, Azure Queue Storage)? By externalising the payload to a data store and passing only a correlation ID on the queue, you gain scalability and flexibility at the cost of added latency. Azure Event Grid's automatic claim check generation is also demonstrated. Security is a thread running through both patterns: compromised config stores and poisoned messages both demand an operational response plan.

Chris Reddington and Will Eastbury cover three closely related messaging patterns in one packed episode. They start with the Publish-Subscribe (Pub/Sub) pattern — arguably the most transformative shift in enterprise messaging — where a single producer broadcasts to multiple isolated subscribers via Azure Service Bus topics or Azure Event Grid. Real-world use cases include insurance aggregators, credit check pipelines, and bank account sign-up workflows. From there they move to the Priority Queue pattern, which ensures high-priority messages are processed before lower-priority ones even when consumers are under load. Finally, the Pipes and Filters pattern decomposes complex message processing into a chain of discrete, reusable transformation steps — reducing complexity and enabling independent scaling of each stage. The episode also connects these patterns back to earlier topics like Competing Consumers and Queue-Based Load Leveling, and flags related patterns including Choreography and Compensating Transactions.

Do you have an application with specific scalability and continuity-of-service requirements? What happens when traffic spikes dramatically — think a major concert or FIFA World Cup ticket sale crashing a site? In this Architecting for the Cloud episode, Chris and Will Eastbury walk through three closely related patterns: Queue-Based Load Levelling, Competing Consumers, and the Asynchronous Request-Reply pattern. They explore how message queues act as shock absorbers for traffic spikes, how competing consumers enable elastic horizontal scaling, and how async request-reply lets you retrofit these patterns into existing architectures with minimal disruption. Key trade-offs covered include queue depth limits, Azure Service Bus configuration, distributed tracing with Application Insights, and when the added complexity genuinely justifies reaching for these patterns.