Best way to structure small projects when learning Azure services

Hey @David Carter

when you’re just spinning up small practice projects, say a couple of Azure Functions talking to Storage and exposing a simple HTTP API—here’s a pattern that tends to keep things clean, reusable, and easy to manage:

Scaffold everything in one repo, but separate by concern • /functions – host.json (shared settings) – local.settings.json (dev secrets & connection strings) – Function1/Function2 folders (each with its own function.json or code file) • /api-client (optional) – basic script or Postman collection to hit your HTTP-triggered functions • /infra (optional) – ARM/Bicep/Terraform or Azure Developer CLI (azd) templates

Use Azure Developer CLI or VS Code extensions for quickstarts • azd init (functions-quickstart…-js or ‑ps template) will spin up a resource group, storage account, function app, etc. • You get a consistent structure plus an “environment” folder for your dev config

One Function App per logical workload • If all your functions share the same triggers, bindings, storage connection string and permissions, deploy them together. • If you need different app settings, separate privileges (e.g., one set of functions needs read/write to Storage, another only reads), or different scaling, spin up a second Function App.

Keep storage accounts scoped to each Function App • In dev, you can point multiple apps to the same Storage account locally (UseDevelopmentStorage=true), but in Azure use one storage account per Function App for less cross-pollution and lower latency.

Leverage host.json for shared runtime settings • Common retry/prefetch/extension configs belong here. Anything function-specific lives in function.json or your function code.

Local dev → cloud parity • local.settings.json mirrors your Application Settings in the portal (AzureWebJobsStorage, your own connection strings, FUNCTIONS_WORKER_RUNTIME). • Test everything locally with func start, then publish with azd up or VS Code/Azure CLI.

Simple API layering • Build your HTTP-triggered endpoints in Functions, then if you grow beyond “just functions” you can front them with API Management or an Azure App Service. • Keep business logic in shared libraries/packages so you can call it from multiple functions or even a separate web API project.

That setup will let you iterate quickly, keep config and code tidy, and—when you’re ready—scale one piece without dragging everything else along. Hope it helps!

Reference list

• Improve the performance and reliability of Azure Functions: https://dori-uw-1.kuma-moon.com/azure/azure-functions/performance-reliability
• Best practices for reliable Azure Functions: https://dori-uw-1.kuma-moon.com/azure/azure-functions/functions-best-practices#configure-storage-correctly
• Quickstart: Build a scalable web API using Azure Functions (JavaScript): https://dori-uw-1.kuma-moon.com/azure/azure-functions/create-first-function-azure-developer-cli?#initialize-the-project
• Quickstart: Build a scalable web API using Azure Functions (PowerShell): https://dori-uw-1.kuma-moon.com/azure/azure-functions/create-first-function-azure-developer-cli?#run-in-your-local-environment

For small practice projects, use a simple, consistent structure that mirrors how Azure services are introduced in the learning paths and modules.

1. Start with a single resource group per practice project
   • Create one resource group for each project so all related Azure Functions, storage accounts, and APIs are managed, monitored, and cleaned up together.
   • This aligns with guidance where a resource group is used to keep all Azure services for a single project under a common scope.
2. Use one Function App per logical application
   • Group related Azure Functions (for example, all functions for a simple API or workflow) into a single Function App.
   • Within that Function App, organize by trigger type and responsibility (HTTP-triggered endpoints, queue-triggered background tasks, timer-triggered jobs).
   • This matches the way modules such as Develop Azure Functions and Create serverless logic with Azure Functions treat a Function App as the unit that contains multiple related functions.
3. Keep storage simple and close to the Function App
   • Create a single Storage Account per project (or per Function App) for queues, blobs, and tables used by that project.
   • Use it both as the required backing storage for Azure Functions and for application data (for example, blob containers for files, queues for background processing).
   • Place the Storage Account in the same region as the Function App to reduce latency and complexity.
4. Build a small, HTTP-based API first
   • Start with HTTP-triggered Azure Functions to expose a simple API (for example, CRUD operations over a storage-backed resource).
   • Use input/output bindings to connect functions to Storage (blobs, queues, or tables) instead of writing direct SDK code where possible, as described in the Develop Azure Functions and Create serverless logic with Azure Functions modules.
5. Evolve the structure as scenarios grow
   • For very small exercises, keep everything in one Function App and one Storage Account in a single resource group.
   • As scenarios become more complex, follow the patterns from Create serverless applications:
     • Add Durable Functions when long-running workflows are needed.
     • Introduce Azure API Management later if multiple Function Apps need to be exposed as a single, consistent API surface.
   • For microservice-style learning, use the guidance from Create cloud-native apps and services with .NET and ASP.NET Core to separate concerns into independently deployable services when ready.
6. Align with learning paths and quickstarts
   • Use the Azure Functions quickstart that builds a scalable web API with HTTP-triggered functions as a template for structuring practice APIs.
   • Combine this with the Azure Fundamentals learning path to understand how compute, storage, and networking fit together as the project grows.

This approach keeps early projects small and manageable while matching the patterns used in official training content, making it easier to scale skills and architectures later.

References:

• Implement Azure Functions
• Microsoft Azure Fundamentals: Describe Azure architecture and services
• Create serverless applications
• Develop Azure Functions
• Explore Azure Functions
• Create cloud-native apps and services with .NET and ASP.NET Core
• Quickstart: Build a scalable web API using Azure Functions (programming-language-csharp)