Microsoft’s is an important addition to , providing the back end needed to build distributed applications that can work at scale, with minimal management and orchestration. It brings to Microsoft’s serverless tools an event routing fabric that simplifies subscribing to events raised by other Azure services and by external sources.

There’s a lot to be said for using as the basis of a modern cloud application architecture. For one thing, there’s no need to worry about the underlying infrastructure, or even the network you’re using, reducing the management load on your application orchestration tools. But serverless models, like , are themselves limited, launching on demand in response to events. If they don’t receive the appropriate signals, they don’t fire.

Working with Azure events

So how should you capture events? Traditional event queues are an issue in distributed architectures, because it can be hard to ensure that events are delivered correctly. Ideally, you want messages to be idempotent, delivered once and once only, with that delivery guaranteed. In practice, that’s a hard problem to solve, so you’re more likely to use a system that delivers a message at least once; that way, you can use back-end code to clean up logs and stored data, using event and message IDs to identify duplicates.

With Event Grid, Microsoft has done the hard work of building a publish-and-subscribe system for you, integrating it with notifications from various Azure services. Events are now a first-class object, and your Event Grid configuration can filter and direct events to appropriate services. It’s also scalable, so it can handle simple architectures with one or two sources as well as complex environments with thousands.

, so using Event Grid to trigger Flow actions to feed from, say, an e-commerce application into Dynamics 365 could let you update customer records on the fly, or quickly target offers to specific customers. Then there’s the option of using Event Hubs in to push events from IoT devices, quickly raising alerts and using a function to pull data from a device as and when its actually needed, saving bandwidth and avoiding complex IoT hub architectures that may not be supported by low-cost, simple hardware.

With Azure Functions at the heart of Microsoft’s serverless model, you can easily imagine an application that uses Event Grid to source data from key Azure services, triggering a function that then uses the API to launch containers running more complex services to process data that’s linked to the underlying event trigger, with Kubernetes reclaiming the container resources when they’re no longer needed. With this type of architecture, you avoid an expensive permanent virtual infrastructure, and you’re billed only when your services run.

Perhaps we should start thinking about infrastructureless applications rather than serverless ones.