01 - Choose the App Service Sidecar Pattern

Overview

An Azure App Service sidecar is an auxiliary container that runs in the same environment as the main Linux app container. Sidecars add capabilities such as local AI inference, telemetry collection, or caching without placing those capabilities inside the main application image.

Configuration Model

Multi-container apps on App Service use a custom JSON configuration file (often referred to as a "sitecontainers spec" or implicitly managed via ARM properties). Each container defined in this configuration has:

• A name and image
• A boolean isMain flag (exactly one container must be true)
• Its own startup command / entrypoint
• Its own container-specific environment variables and volume mounts

Flow Explanation

1. The Entry Point: The public client securely connects via HTTPS to the Azure App Service Instance boundary.
2. Main Routing: Traffic hits the Main API Container because it is marked as isMain: true.
3. Internal Handoff: The Main API Container executes business logic and forwards inference requests privately to the Model Server Sidecar over the shared localhost network namespace.
4. Shared State: Both containers write and read from the exact same Shared Disk Volume to maintain synchronized state, without needing an external database.

// Main Container (Exposes public HTTP endpoint)
{
    "name": "flask-frontend",
    "image": "myregistry.azurecr.io/frontend:v1",
    "isMain": true
}

// Sidecar Container (Internal AI Inference Engine)
{
    "name": "phi3-onnx-engine",
    "image": "myregistry.azurecr.io/phi3-engine:v1",
    "isMain": false
}

Core Principles of App Service Sidecars

When choosing to use sidecars instead of separate microservices, keep these core behaviors in mind:

1. Shared Network Namespace (localhost)

All containers (the main container and all sidecars) share the exact same network namespace.

• The sidecar container does not get its own IP address.
• The main container can communicate with the sidecar by making requests to http://localhost:<sidecar-port>.
• Only the isMain: true container receives external inbound traffic from the internet (via the App Service load balancer). Sidecars cannot be accessed directly from the internet.

This is ideal for AI models because you can deploy a local LLM or Embedding engine in a sidecar, and your main application queries it securely over localhost with zero network latency and zero risk of public exposure.

2. Tightly Coupled Lifecycle

Containers in an App Service sidecar group share a lifecycle. They are created together, scaled together, and destroyed together.

• If the App Service plan scales out to 5 instances, you will have 5 VMs, each running 1 Main Container + 1 Sidecar Container.
• You cannot scale them independently (e.g., you cannot have 10 sidecars and 2 main containers). If the AI model requires massively different scaling metrics than the frontend, a sidecar is the wrong pattern (use Azure Container Apps instead).

3. Shared Storage Volumes

All containers in the App Service instance can mount and share the exact same Azure Storage file shares (/home).

• This allows a sidecar to download and cache a multi-gigabyte AI model to a shared volume upon initialization.
• The main container can read flags, status files, or outputs written by the sidecar.

Next Step

In the next section, we will write the code for our FastAPI ONNX model server (sidecar) and our Flask frontend (main container) to leverage this localhost integration.