Absolutely, Tony. Here's a rational breakdown of your architecture options in a comparison table that weighs reliability, complexity, and infrastructure overhead:
| Option | Trigger Type | Infra Overhead | Reliability | Metadata Flexibility | Ease of Scaling | Notes |
|---|---|---|---|---|---|---|
| Classic Blob Trigger | Polling | Low | ❌ Risk of missed events | ✅ Fetchable from blob | 🚧 Limited | Simple to implement but not recommended for production workloads |
| Event Grid → Azure Function | Push via Event Grid | Moderate | ✅ Highly reliable | ✅ Included in event or fetchable | ✅ Excellent | Ideal if Event Grid is allowed—cleanest and most reactive |
| ADF → Function (Direct Call) | Web activity | Low | ✅ Can fetch from blob | Lean setup, but lacks retry and decoupling | ||
| ADF → Logic App → Queue | HTTP + Connector | Moderate (no code) | ✅ Durable | ✅ In message payload | ✅ Flexible | No Function needed; easy to evolve with connectors |
| ADF → Function → Storage Queue | Web activity | Moderate | ✅ Durable | ✅ In message payload | ✅ Flexible | Good reliability and separation of concerns |
| ADF → Function → Service Bus | Web activity | Higher | ✅ Durable + rich features | ✅ In message payload | ✅ Very flexible | Overkill unless you need topics, sessions, or dead-lettering |
- ✅ Best long-term: Event Grid → Function (clean, reactive, minimal glue)
- 🪄 Best short-term: ADF → Logic App → Storage Queue (low-code + reliable)
- 🎯 Simplest to start: ADF → Function (direct call), with option to grow later
Want help picking one for your workshop narrative, or building a slide that shows how you can migrate from short-term to ideal architecture over time? I can sketch that next.