The Modern Cloud Developer’s Handbook: A Quick Refresh about Consistency, Scale, and Observability

  
 

Building on Azure today isn’t just about spinning up a Virtual Machine. It is about understanding distributed data, mastering serverless containers, and ensuring your application is observable.

Whether you are designing a new microservice or refactoring a legacy app, these are the core architectural concepts you need to know.

1. The Data Consistency Spectrum

One of the most complex choices in distributed databases (like Azure Cosmos DB) is balancing performance against data accuracy. This is defined by Consistency Levels.

Many developers default to “Strong” because it feels safe, or “Eventual” because it’s fast. However, there are five levels, and understanding the nuance is key to building fast, user-friendly apps.

The 5 Levels (From Strongest to Weakest)

  1. Strong Consistency

    • The Promise: “What you write is immediately what everyone reads, everywhere.”
    • The Trade-off: Highest latency. The database must replicate data to all regions before confirming the write.
    • Use Case: Financial ledgers, inventory systems where overselling is impossible.

  2. Bounded Staleness

    • The Promise: “Reads might lag behind writes, but only by a specific amount of time (e.g., 5 seconds) or version updates.”
    • The Trade-off: Faster than Strong, but availability can suffer if replication lags too far behind.
    • Use Case: Stock tickers, flight status boards.

  3. Session Consistency (The “Goldilocks” Default)

    • The Promise: “Read Your Own Writes.” If User A updates their profile, User A sees the change immediately. User B might see the old profile for a few seconds.
    • The Trade-off: Excellent performance and availability, but requires the client to maintain a session token.
    • Use Case: Social media profiles, shopping carts, most user-facing apps.

  4. Consistent Prefix

    • The Promise: “No gaps in history.” If you write A, then B, then C, a reader might see just A, or A and B, but they will never see A and C without B.
    • The Trade-off: Lower latency, but data is not real-time.
    • Use Case: Chat applications (you don’t want to see an Answer before the Question).

  5. Eventual Consistency

    • The Promise: “It will get there eventually.” No ordering guarantees.
    • The Trade-off: Lowest latency and highest availability.
    • Use Case: Like counts on a viral post, review counts.

2. Event-Driven & Resilient Data Processing

In modern apps, we rarely just “save” data. Usually, saving data triggers a workflow (e.g., sending an email, updating a search index).

The Change Feed Pattern

Instead of modifying your code to call five different services when an order is placed, use the Cosmos DB Change Feed. It acts as a log of every change in your database.

  • Best Practice: Use an Azure Function with a Cosmos DB Trigger. It wakes up automatically when data changes.
  • Scaling: To handle high volume, use a Lease Container. This acts as a “bookmark,” tracking how far your application has processed. If you scale your Azure Functions to 10 instances, the Lease Container coordinates them so no two instances process the same record.

Idempotency

When initializing resources (like creating a new container on startup), always code defensively.

  • Don’t use: CreateContainerAsync (Throws an error if it exists).
  • Do use: CreateContainerIfNotExistsAsync (Safe, idempotent operation).

3. The Container Ecosystem

Containerization on Azure has evolved into specific tools for specific jobs.

Azure Container Apps (ACA) & KEDA

ACA is the modern standard for serverless containers. Its superpower is KEDA (Kubernetes Event-driven Autoscaling).

  • Scale to Zero: Unlike standard metrics (CPU/Memory) which require at least one instance running to measure load, KEDA looks at external events.
  • Example: If your Service Bus queue is empty, KEDA scales your app to 0 replicas (saving money). As soon as a message drops in, the app wakes up.
  • Environments: These act as the secure boundary. If you need two apps in different Virtual Networks (VNets), they must be in different ACA Environments.

Azure Container Instances (ACI)

Think of ACI as a “pod” on demand.

  • Container Groups: You can run multiple containers (e.g., an app and a logging sidecar) on the same host. They share the same lifecycle, local network (localhost), and storage volumes.

4. Observability: OpenTelemetry & App Insights

We are moving away from proprietary logging SDKs toward open standards.

The New Terminology

If you are moving from the classic Application Insights SDK to OpenTelemetry, you need to map the terms:

  • Outgoing Calls (Dependencies): These are now Client Spans.
  • Incoming Traffic (Requests): These are now Server Spans.

Smart Logging (Sampling)

If your app handles millions of requests, logging every single one is expensive and slows you down.

  • Sampling: This technique keeps a statistically correct percentage of your logs (e.g., 5%). It preserves the “story” of failures and trends without flooding your storage.
  • Zero-Code: For Azure App Service, you can often enable “Auto-instrumentation” directly in the portal without changing a line of code.

5. Managing Secrets & Configuration

Hard-coding settings is a recipe for disaster. Here is the cloud-native way to handle config.

Azure App Configuration

  • Feature Flags: Want to test a new checkout button? Wrap it in a Feature Flag. You can toggle it on/off for specific users without redeploying your code.
  • Labels: Use Labels to version your keys. You can have the key DbString with the label Dev and the label Prod in the same store.

Key Vault Safety Nets

Storing keys is easy; keeping them safe from accidental deletion is harder.

  1. Soft Delete: Acts like a “Recycle Bin.” If you delete a key, it stays there for (default) 90 days.
  2. Purge Protection: The lock on the Recycle Bin. It prevents even an administrator from permanently deleting the key before the retention period ends. This is crucial for production secrets.