// the find
Azure-Samples/Serverless-microservices-reference-architecture
This reference architecture walks you through the decision-making process involved in designing, developing, and delivering a serverless application using a microservices architecture through hands-on instructions for configuring and deploying all of the architecture's components along the way. The goal is to provide practical hands-on experience in working with several Azure services and the technologies that effectively use them in a cohesive and unified way to build a serverless-based microservices architecture.
A Microsoft-authored reference architecture for building serverless microservices on Azure, using a fictional rideshare app as the teaching vehicle. It covers Azure Functions, Durable Functions, Event Grid, API Management, CosmosDB, and SignalR all wired together. The target audience is .NET developers who want to see how these services actually fit together rather than reading docs in isolation.
The Durable Functions usage is the strongest part — TripManagerOrchestrator and TripMonitorOrchestrator show real orchestration patterns (fan-out, external events, timers) that aren't obvious from the official docs. The Bicep modules are well-decomposed and actually deployable, not just illustrative. The architecture separates concerns properly: drivers, passengers, trips, and orchestrators are genuinely independent function apps with their own deployment units. Documentation is unusually thorough for a sample — step-by-step setup, data flow diagrams, and monitoring guidance all in one place.
It's still on Azure Functions v3 in 2024, with a v4 upgrade sitting in an open PR (#43) that hasn't merged. That means the in-process model, which Microsoft has deprecated, and you'd need to port it yourself before using this as a real baseline. The ServiceFactory pattern in Shared/Services is a static service locator — it was dated when it was written and makes testing painful. The Vue.js frontend uses options API and webpack, both showing age. There are no unit or integration tests in the repo at all, just a Postman collection and a .http file, so you can't verify the thing works after you make changes.