Cloud Team - Buildr

• YAML and GitHub Actions
• DevOps with Microsoft Azure
• Azure Services: A Tech Team Quick Reference Page
• Introduction to Azure Service Bus
• Smart Bank – AI Powered Banking Assistant
• OpenTelemetry Developer Handbook – Azure, GCP & AWS
• Zero-Downtime Deployment in Azure App Service: Deployment Slots, Health Checks and Rollbacks

YAML and GitHub Actions

YAML Fundamentals and GitHub Actions Workflows

Understanding Configuration as Code and Workflow Automation

By Presica Peter Pinto  •  Cloud Team

Modern DevOps teams succeed when important work is repeatable, and repeatable work is automated. YAML gives teams a clear way to describe that automation in code. GitHub Actions then executes those definitions whenever repository events occur. Together, they connect engineering intent to reliable delivery.

YAML CONFIGURATION  +  GITHUB ACTIONS  =  CI/CD AUTOMATION

Readable IntentEvent-Driven ExecutionReliable Software Delivery

YAML and GitHub Actions together turn engineering intent into reliable delivery.

1. What Is YAML?

YAML (YAML Ain’t Markup Language) is a human-readable format used to represent structured data, most often for configuration. Unlike XML or verbose JSON payloads, YAML keeps syntax light and relies on indentation to show hierarchy. That makes it easier for engineers to read quickly, review in pull requests, and maintain over time.

Files typically use the .yml or .yaml extension. In cloud and DevOps workflows, these files act as executable specifications stored in Git and interpreted by automation platforms.

Five characteristics that make YAML the standard language of cloud automation.

2. YAML Syntax Fundamentals

Most production YAML files are built from three patterns: key-value pairs, lists, and nested objects. Once these patterns are clear, engineers can work confidently across CI/CD pipelines, container tooling, and platform configuration files.

name:    AzureApp
version: 1.0
env:     production

services:
  - frontend
  - backend
  - database

server:
  host: localhost
  port: 8080

name:    "Sam"          # string
age:     52             # number
active:  true           # boolean
manager: null           # null
notes: |
  Multi-line string
  value supported

# This is a comment
app:
  name: myapp        # spaces only, never tabs
  version: 1.0       # indentation = hierarchy
  services:
    - api            # hyphen = list item
    - web

YAML vs JSON: Choosing the Right Tool

Verdict: YAML for human-written configs  |  JSON for machine-to-machine APIs.

3. YAML in Modern Cloud Engineering

YAML is valuable not only because it is readable, but because the skill transfers across platforms. The same syntax appears in Kubernetes manifests, Docker Compose files, GitHub Actions workflows, and Azure Pipelines definitions—giving teams a practical learn-once, apply-everywhere advantage.

Key Message: YAML is the common language of cloud automation. Engineers fluent in YAML can move smoothly between application configuration, infrastructure provisioning, and pipeline engineering.

4. Introduction to GitHub Actions

GitHub Actions is GitHub’s built-in automation platform for CI/CD and repository-level operations. It reacts to events such as pushes, pull requests, schedules, and manual triggers, then runs workflows on managed runners.

Workflows are stored in .github/workflows/ as YAML files, which keeps delivery logic version-controlled and visible alongside application code. This tight integration improves traceability and simplifies team collaboration.

5. Anatomy of a GitHub Actions Workflow

A workflow combines triggers, jobs, steps, and runners into one automated sequence. A simple factory analogy helps: on is the entry sensor, jobs are departments, steps are tasks on each station, and runners are temporary workers assigned for one shift.

.github/workflows/build.yml

name: CI/CD Pipeline          # display name in Actions UI

on:                           # WHEN to run
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]
  workflow_dispatch:          # manual trigger button

jobs:
  build:
    runs-on: ubuntu-latest    # ephemeral Ubuntu VM
    steps:
      - uses: actions/checkout@v4    # reusable action
      - name: Build Application
        run: npm run build           # shell command

WORKFLOW LIFECYCLE: FROM CODE PUSH TO STATUS REPORT

Each stage acts as a quality gate — if one fails, downstream execution stops.

6. Hands-On Demo: Production CI/CD Pipeline Walkthrough

The live demonstration used a production-style pipeline for GoCart, a Next.js e-commerce application. Its structure reflects practical enterprise needs: controlled triggers, fail-fast quality checks, security visibility, containerization, and auditable releases.

FULL PIPELINE ARCHITECTURE: GOCART APPLICATION

Seven sequential quality gates — each job declares needs on the previous one.

Triggers and Concurrency Control

The workflow listens to push and pull_request events on main/master, and includes workflow_dispatch for manual runs. Concurrency settings prevent duplicate branch runs by canceling outdated executions. On protected branches, teams often keep in-progress runs intact to avoid partial deployment states.

Typical use of workflow_dispatch: hotfix redeployments, reruns for a specific commit, and operator-controlled release execution.

Global Environment Variables

env:
  NODE_VERSION: '20'                 # defined once and reused by all jobs
  DOCKER_IMAGE_NAME: gocart          # consistent image naming across stages
  NEXT_PUBLIC_CURRENCY_SYMBOL: '$'   # region-configurable app-level setting

Centralized variables reduce repetition and lower the risk of drift. For example, changing the Node runtime in one place updates every job that depends on it.

Build Stage: Reproducibility and Artifact Handoff

- uses: actions/checkout@v4
- uses: actions/setup-node@v4
  with:
    node-version: ${{ env.NODE_VERSION }}
    cache: npm                         # avoids re-downloading unchanged packages
- run: npm ci                          # exact lock-file install for reproducibility
- run: npm run build                   # compile Next.js and generate .next output
- uses: actions/upload-artifact@v4
  with:
    name: build-output
    path: .next/
    retention-days: 1                  # short-lived handoff between jobs

npm ci installs exactly what the lock file defines, which keeps builds deterministic across environments. Since jobs run on fresh runners, artifacts are used to hand off build output to later stages.

Lint and Test Stages: Quality Gates with Diagnostics

The lint stage enforces coding standards and catches static issues early. The test stage runs the automated suite with verbose reporting. Both stages publish logs using if: always(), so failure data is retained for troubleshooting and audit trails.

Security Stage: Visibility-First Governance

The security stage usually combines dependency auditing and secret-pattern detection. Dependency checks identify known CVEs; secret scanning looks for leaked credentials such as API keys and passwords. Together, these checks improve release confidence without relying on manual inspection.

In many enterprise teams, findings are reported and retained for compliance review, while remediation is prioritized based on severity and business impact.

Docker Build and Conditional Push: Governance in YAML

# Docker Build validates the image, but does not push on pull requests
- uses: docker/build-push-action@v6
  with:
    push: false                       # build-only on PR branches
    tags: gocart:test
    cache-from: type=gha              # layer caching shortens repeated builds
    cache-to: type=gha,mode=max

# Docker Push runs only for approved execution paths
if: github.event_name == 'push' || github.event_name == 'workflow_dispatch'

This condition enforces a critical policy: pull requests validate code, but do not publish release images. Credentials are injected through encrypted repository secrets and are never stored in plain text in workflow files.

Release Stage: Automated Versioning and Traceability

For successful main-branch runs, release automation can generate semantic tags and publish GitHub Releases with generated notes. This gives teams clean version history, commit-level traceability, and faster rollback capability.

7. Benefits, Best Practices, and Conclusion

Conclusion

Conclusion: YAML provides the structure; GitHub Actions provides the execution. Together, they turn DevOps principles into repeatable daily practice. Teams gain faster feedback, clearer governance, and more reliable releases without increasing manual overhead.

YAML = Foundation  |  GitHub Actions = Automation Engine  |  DevOps = Culture of Continuous Delivery

DevOps with Microsoft Azure

DevOps with Microsoft Azure

Understanding Modern Software Delivery and Cloud Operations

By Dheeraj S Bhat

Modern organizations must ship features faster, with higher quality and greater reliability than ever. The old model—developers writing code and “throwing it over the wall” to a separate operations team—cannot keep pace. DevOps answers this: a cultural and technical movement that unifies software Development and IT Operations through collaboration, automation, and continuous delivery.

DEVELOPMENT  +  OPERATIONS  =  DEVOPS

Faster DeliveryHigher QualityGreater Reliability

DevOps unifies Development and Operations into one continuous, value-driven flow.

1. What Is DevOps?

DevOps is not a single tool or product. It is a combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity, shortening the development life cycle while delivering fixes and updates frequently and reliably. The payoff is faster delivery, higher quality, and greater reliability.

DevOps directly attacks the pain points of traditional development—slow release cycles, manual deployments, communication gaps, frequent outages, and inability to adapt—through continuous delivery, automated testing, shared ownership, and rapid feedback.

2. Core Principles: The CALMS Framework

DevOps maturity is measured against five interdependent pillars:

The five CALMS pillars of DevOps maturity.

These principles work together: culture is the foundation, automation enables speed, lean removes waste, measurement guides decisions, and sharing accelerates learning.

3. The DevOps Lifecycle

DevOps is best visualized as a continuous loop—an unending cycle of delivery and improvement, where feedback from the final stage drives the next planning cycle.

The nine-stage DevOps lifecycle — a continuous loop where feedback feeds the next cycle.

4. Continuous Integration & Continuous Delivery (CI/CD)

Continuous Integration (CI) automatically builds and tests code on every commit, delivering early bug detection, faster feedback, and consistent builds. Azure Pipelines provides cloud-hosted agents for any language on Windows, Linux, and macOS.

Although grouped as “CD,” two practices differ: Continuous Delivery keeps code always deployable with a manual approval gate before production, while Continuous Deployment automatically deploys every passing change with no human intervention.

CONTINUOUS INTEGRATION

CONTINUOUS DEPLOYMENT

Each stage is a quality gate — any failure stops the pipeline.

5. The Azure DevOps Platform

Azure DevOps is Microsoft’s comprehensive, end-to-end platform supporting any language and platform, cloud or on-premises deployment, deep Azure integration, and built-in enterprise security. It is organized into five core services:

6. Infrastructure, Containers, and Orchestration

Infrastructure as Code (IaC)

IaC manages infrastructure through machine-readable code rather than manual processes, providing version control, consistent environments, repeatable deployments, and reduced drift. Azure tools include Terraform (multi-cloud, HCL), Bicep (Azure-native DSL), ARM Templates (JSON), and Azure Blueprints (governed environments).

Containerization with Docker

Containers package application code with all dependencies for portable, consistent deployment. Docker is lightweight versus VMs, starts quickly, and simplifies deployment: Dockerfile → image → registry → running container. Azure Container Registry (ACR) integrates natively with Azure DevOps and AKS.

Kubernetes & Azure Kubernetes Service (AKS)

Kubernetes automates deployment, scaling, and management of containers with auto-scaling, self-healing, load balancing, and zero-downtime rolling updates. AKS provides managed Kubernetes with Azure AD integration, Container Insights, auto-scaling, and Azure DevOps integration.

7. Monitoring, Observability, and Security

8. A Real-World Azure DevOps Architecture

CONTINUOUS INTEGRATION

CONTINUOUS DEPLOYMENT  •  OBSERVABILITY

A complete cloud-native pipeline — every component is a natively integrated Azure service.

Every component is an Azure service that integrates natively with the others, eliminating the friction of stitching together disparate tools.

9. Benefits, Challenges, and Best Practices

Conclusion & the Future of DevOps

DevOps is ultimately a culture, not just a set of tools. Microsoft Azure complements that culture with a complete platform: CI/CD pipelines automate delivery, IaC enables consistent environments, and monitoring and security are woven throughout.

Looking ahead, four trends shape the next chapter: AI-assisted DevOps (AIOps), GitOps for Kubernetes-native deployments, Platform Engineering, and FinOps for cloud cost optimization. Organizations that embrace these practices—anchored by a collaborative culture and powered by Azure’s integrated toolset—position themselves to deliver software faster, more reliably, and more securely than ever.

Azure Services: A Tech Team Quick Reference Page

Azure Services: A Tech Team Quick Reference

A condensed, decision-focused guide to the major Azure service categories

By Swedel F Menezes - Cloud Team

A condensed, decision-focused guide to the major Azure service categories. For each service: what it is, primary use cases, and a one-line “when to choose it” rule. Use this as a quick reference when designing or reviewing an Azure architecture.

Azure Reference Architecture — Layer Overview

1. Compute

2. Storage

3. Networking

4. Databases

5. AI & Machine Learning

6. DevOps & Monitoring

7. Security & Identity

8. Integration & Messaging

9. Analytics

Service Selection Decision Tree

Always add: Entra ID (identity) • Key Vault (secrets) • Monitor + App Insights (observability)

Figure 2 — Decision tree mapping a workload type to the recommended Azure service.

Service Selection Quick Reference

Introduction to Azure Service Bus

Azure Service Bus: Reliable Messaging for Modern Cloud Applications

A Practical Guide to Decoupled, Resilient, and Scalable Cloud Communication

By Kenneth Gavin Dcosta • Cloud Team - Buildr

Modern applications are rarely built as one large system anymore. Instead, they are made up of many smaller services: order services, payment services, inventory systems, notification engines, shipping workflows, analytics pipelines, and more. This makes applications easier to scale and maintain, but it also introduces a new challenge: how do these services communicate reliably without becoming dependent on each other?

AZURE SERVICE BUS + CLOUD ARCHITECTURE = RELIABLE COMMUNICATION

Decoupled Services Asynchronous Processing Reliable Delivery

Azure Service Bus turns fragile direct communication into reliable, scalable, production-ready messaging.

1. Why Direct Service Communication Becomes a Problem

At first, direct communication between services feels simple.

For example, in an e-commerce application, the order flow may look like this:

Order Service → Payment Service → Inventory Service → Shipping Service → Notification Service

This works well when everything is healthy. But in real-world systems, services fail, slow down, restart, or experience sudden traffic spikes. If one service in the chain goes down, the entire workflow can be affected.

Imagine the Shipping Service is unavailable. The Order Service may still be working, the Payment Service may still be working, and Inventory may still be available — but because the flow is tightly connected, the overall order process may fail.

This is known as tight coupling.

For small systems, this may be manageable. For modern cloud applications, it quickly becomes risky.

2. What Azure Service Bus Solves

Azure Service Bus solves this problem by introducing asynchronous messaging.

Instead of one service directly calling another, the sender places a message into Service Bus. The receiving service then picks up and processes that message independently.

Sender Application → Azure Service Bus → Receiver Application

The sender does not need to know whether the receiver is online. The receiver does not need to process the message immediately. Service Bus safely stores the message until it can be handled.

This gives applications breathing room.

• If the receiver is temporarily down, messages wait.
• If traffic increases suddenly, Service Bus absorbs the load.
• If one downstream service fails, other services can continue working.

Core value: Azure Service Bus separates services so they can operate independently without losing messages.

3. A Simple Analogy: The Post Office

The easiest way to understand Azure Service Bus is to compare it to a post office.

When you send a letter, you do not personally deliver it to the recipient. You do not need to know the mail carrier, the route, or the exact delivery time. You simply drop the letter into the postal system.

The post office stores, sorts, and delivers the letter. The recipient collects it when available.

Service Bus acts as an intermediary that enables reliable, asynchronous communication between applications.

4. Core Components of Azure Service Bus

Azure Service Bus is built around a few key components. Understanding these makes the rest of the service much easier.

Namespace

A namespace is the top-level container for Service Bus resources. It holds queues, topics, subscriptions, and related configuration.

gocart-servicebus-namespace

orders-queue
payments-queue
neworders-topic
shipping-subscription
notification-subscription

Queue

A queue is used for one-to-one message processing. One or more senders place messages into a queue, and each message is processed by one receiver.

Order Service → Orders Queue → Order Processor

Queues are useful for background jobs, order processing, invoice generation, email sending, and other tasks where each message should be handled once. This is also known as the Competing Consumers pattern.

Topic

A topic is used for one-to-many communication. One service publishes a message to a topic, and multiple subscribers can receive their own copy of that message.

Order Service → NewOrders Topic
                    ├── Inventory Subscription
                    ├── Payment Subscription
                    ├── Shipping Subscription
                    └── Notification Subscription

Subscription

A subscription belongs to a topic. Each subscription receives a copy of messages from the topic. Subscriptions can also include filters, so different consumers receive only the messages relevant to them.

Message

A message is the unit of data sent through Service Bus. It usually contains a body, properties, metadata, message ID, timestamp, and other information needed by the receiver.

{
  "orderId": "ORD-10291",
  "customerId": "CUST-7781",
  "amount": 2499,
  "currency": "INR",
  "eventType": "OrderPlaced"
}

The message body carries the business data, while metadata helps with tracking, filtering, correlation, and troubleshooting.

5. Queues vs Topics: Choosing the Right Pattern

Queues and topics are both messaging entities, but they solve different problems.

Use a queue when one service should process each message. Use a topic when multiple services need to receive the same message.

Simple rule: Queue = one task, one processor. Topic = one event, many listeners.

6. How Messages Are Processed

Azure Service Bus follows a reliable message lifecycle.

MESSAGE LIFECYCLE: FROM SEND TO RETRY

• A producer sends a message to a queue or topic.
• Service Bus stores the message reliably.
• A consumer receives the message.
• Service Bus locks the message so other consumers cannot process it at the same time.
• If processing succeeds, the consumer completes the message.
• If processing fails or the consumer crashes, the lock expires and the message becomes available again for retry.

Peek-Lock ensures that a message is not lost if a receiver fails during processing. This is one of the most important reliability features of Service Bus.

7. Dead-Letter Queue: Handling Messages That Cannot Be Processed

In real systems, not every message can be processed successfully.

A message may fail because:

• Required data is missing.
• The format is invalid.
• A business rule fails.
• A downstream service is unavailable.
• The consumer has a bug.

If the same message keeps failing, it should not block the entire queue. Azure Service Bus handles this using a Dead-Letter Queue, commonly called a DLQ.

After the maximum retry count is reached, Service Bus moves the failed message to the DLQ. Developers or operations teams can then inspect it, understand why it failed, fix the issue, and decide whether to resubmit or discard the message.

Best practice: Treat the DLQ as a problem mailbox. A growing DLQ usually indicates a code issue, schema mismatch, missing configuration, or dependency failure.

8. Enterprise Features That Make Service Bus Production-Ready

Azure Service Bus includes several features that are especially useful in enterprise systems.

These features make Azure Service Bus more than a simple queue. It is designed for real production workloads where reliability, ordering, retries, and operational control matter.

9. Security and Monitoring

Security is a critical part of any messaging system because messages often carry business-sensitive data.

Service Bus also supports encryption at rest and encryption in transit using TLS. Premium tier scenarios can also use customer-managed keys.

Operational rule: If queue depth keeps increasing, consumers are not keeping up. That may mean you need more consumers, faster processing, better scaling, or investigation into downstream failures.

10. Azure Service Bus vs Other Azure Messaging Services

Azure provides multiple messaging and eventing services. Each has a different purpose.

In real architectures, these services can also work together. For example, Event Grid may trigger a process, Event Hubs may ingest telemetry, and Service Bus may coordinate business workflows.

11. Real-World Example: E-Commerce Order Flow

Let us revisit the e-commerce example.

Instead of directly calling every service, the Order Service publishes one event to a topic:

Customer places order
        ↓
Order Service
        ↓
NewOrders Topic
        ↓
        ├── Inventory Subscription
        ├── Payment Subscription
        ├── Shipping Subscription
        └── Notification Subscription

Each service receives its own copy of the message and processes it independently.

• The Inventory Service reserves stock.
• The Payment Service processes payment.
• The Shipping Service prepares a label.
• The Notification Service sends an email.

If the Notification Service fails, payment and inventory can still continue. If the Payment Service is slow, shipping and notification are not necessarily blocked. Failed messages can go to the DLQ for review.

Key message: One business event can safely trigger multiple independent workflows. If the business later wants fraud detection or analytics, a new subscription can be added without rewriting the Order Service.

12. Best Practices for Production Use

Azure Service Bus is powerful, but like any messaging technology, it should be used carefully.

Conclusion

Azure Service Bus plays a vital role in modern cloud architecture. It helps applications communicate without being tightly connected to each other. By placing a reliable messaging layer between services, it improves resilience, scalability, and maintainability.

• Queues help distribute work to one processor.
• Topics allow one event to reach many independent subscribers.
• Dead-letter queues help isolate failed messages.
• Sessions, duplicate detection, TTL, scheduled delivery, and transactions support real enterprise scenarios.
• Security and monitoring features make the service suitable for production workloads.

A QUICK MENTAL MODEL

Azure Service Bus = Reliable Messaging Layer

Queues = One-to-One Work Processing
Topics = One-to-Many Event Distribution
DLQ = Failed Message Investigation
Managed Identity = Secure Authentication
Azure Monitor = Operational Visibility

The main lesson: Azure Service Bus turns fragile direct communication into reliable, scalable, and production-ready messaging.

For teams building cloud-native applications, it is not just a messaging service. It is a foundation for building systems that can handle failure, scale with demand, and evolve without breaking everything around them.

Service Bus = Reliable Messaging | Queues = Work Distribution | Topics = Event Broadcasting

Smart Bank – AI Powered Banking Assistant

Smart Bank – AI Powered Banking Assistant

Role-Based Dashboards using Semantic Kernel, Azure OpenAI, MySQL & OpenTelemetry

A Reference Architecture for Intelligent, Secure, and Observable Digital Banking

Banking customers now expect instant, conversational, and personalized service, while banks must keep every interaction secure, auditable, and compliant. Smart Bank answers both needs: an AI-powered banking assistant built on role-based dashboards for customers and administrators, orchestrated by Semantic Kernel, reasoning with Azure OpenAI, backed by a MySQL core data store, and observed end-to-end with OpenTelemetry.

Figure 1 — The complete Smart Bank architecture, from role-based user access through the FastAPI application layer, Semantic Kernel orchestration, Azure OpenAI reasoning, MySQL persistence, and full-stack observability.

Smart Bank Architecture — Layer Overview

1. What Is Smart Bank?

Smart Bank is a reference architecture for an intelligent banking assistant that lets users converse naturally with their bank instead of navigating dozens of screens. It is not a single product but a composition of cloud-native services that turn natural-language requests like "show my last five transactions," "what is my EMI due date," or "raise a complaint" into safe, governed actions against real banking data.

2. Users and Role-Based Access

Two primary roles drive the entire experience. The architecture deliberately keeps their capabilities separate so that a single platform can serve very different needs without compromising security.

3. Authentication & Access Control

Every session begins at the security boundary. Credentials are verified, a token is issued, and a role-based engine decides what the authenticated identity is allowed to do.

4. Role-Based Dashboards

Once authenticated, each role lands on a tailored dashboard. Both dashboards embed the same AI Banking Assistant, but its scope and verbs differ by role.

5. The Application Layer (FastAPI)

A set of focused, independently scalable services, built with FastAPI, exposes the bank's capabilities as clean APIs. Each service owns a single domain, making the system easier to reason about, test, and evolve.

6. MySQL Database: The Core Data Store

A relational MySQL database is the system of record. A normalized schema links identities, roles, and financial entities through primary and foreign keys, keeping data consistent and queryable.

7. Semantic Kernel Orchestration Layer

The intelligence of Smart Bank lives in the Semantic Kernel orchestration layer. It sits between the chat interface and the bank's capabilities, turning a free-form request into a precise, governed sequence of operations.

Figure 2 — The Semantic Kernel orchestration flow, from chat message to grounded response, with OpenTelemetry tracing every step.

8. Plugins, Knowledge Search & Azure OpenAI

Three capabilities power the assistant's reasoning: a library of banking plugins for actions, a retrieval-augmented knowledge base for grounding, and Azure OpenAI for language understanding.

9. External Integrations & Document Storage

Smart Bank does not operate in isolation. It connects to the broader banking ecosystem and stores documents durably in the cloud.

10. Observability & Telemetry (OpenTelemetry)

Observability is the feedback loop that keeps the platform healthy. OpenTelemetry instruments the entire stack and pipes signals into Azure monitoring, audit logging, and alerting.

Pipeline: Instrumentation (traces, metrics, logs, events) → OTel Collectors → Telemetry Data → Azure Monitoring → Audit & Security Logging → Alerting & Notifications

11. End-to-End Data Flow

Bringing every layer together, a single request travels a clear, traceable path from the user interface to the AI and back, while telemetry is captured at every hop.

Flow: User → React UI (Dashboard / Chat) → JWT Auth → FastAPI APIs → Semantic Kernel (Orchestration) → Plugins / Functions → MySQL DB (Data Retrieval) → Azure OpenAI (Response Generation) → Response to UI → Telemetry Captured

Conclusion

Smart Bank shows how modern AI can be woven into banking without sacrificing security or control. Role-based dashboards keep experiences tailored and safe; Semantic Kernel and Azure OpenAI turn natural language into grounded action; MySQL provides a trustworthy system of record; and OpenTelemetry ensures the whole platform is observable and auditable. Every component is a managed, cloud-native service that integrates natively with the others, eliminating the friction of stitching together disparate tools and positioning the bank to deliver intelligent service that is fast, secure, and reliable.

A reference architecture for intelligent, secure, and observable digital banking.

OpenTelemetry Developer Handbook – Azure, GCP & AWS

OpenTelemetry (OTel) is an open-source observability framework and toolkit that gives you a single, vendor-neutral way to generate, collect and export telemetry data — the signals your application produces to tell you what it is doing and how healthy it is.

It is a CNCF Graduated project (the highest maturity level), widely adopted by Google, Microsoft, AWS, Datadog, and hundreds of others.

The Three Pillars of Observability

We will use Node.js as the example. The same concepts apply to Python, Java, Go, .NET, etc.

Step 1 – Install the Core SDK Packages

npm install @opentelemetry/api @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node @opentelemetry/sdk-trace-node @opentelemetry/sdk-metrics @opentelemetry/resources @opentelemetry/semantic-conventions

Step 2 – Create instrumentation.js

// instrumentation.js — load BEFORE your app
const {{ NodeSDK }} = require('@opentelemetry/sdk-node');
const {{ getNodeAutoInstrumentations }} = require('@opentelemetry/auto-instrumentations-node');
const {{ Resource }} = require('@opentelemetry/resources');
const {{ SemanticResourceAttributes }} = require('@opentelemetry/semantic-conventions');
const {{ ConsoleSpanExporter }} = require('@opentelemetry/sdk-trace-node');

const sdk = new NodeSDK({{
  resource: new Resource({{
    [SemanticResourceAttributes.SERVICE_NAME]: 'my-first-service',
    [SemanticResourceAttributes.SERVICE_VERSION]: '1.0.0',
  }}),
  traceExporter: new ConsoleSpanExporter(),
  instrumentations: [getNodeAutoInstrumentations()],
}});
sdk.start();
process.on('SIGTERM', () => sdk.shutdown().finally(() => process.exit(0)));

Step 3 – Run your app

node -r ./instrumentation.js app.js

npm install @azure/monitor-opentelemetry-exporter

const {{ AzureMonitorTraceExporter }} = require('@azure/monitor-opentelemetry-exporter');
const {{ AzureMonitorMetricExporter }} = require('@azure/monitor-opentelemetry-exporter');
const {{ PeriodicExportingMetricReader }} = require('@opentelemetry/sdk-metrics');
const connectionString = process.env.APPLICATIONINSIGHTS_CONNECTION_STRING;
const sdk = new NodeSDK({{
  traceExporter: new AzureMonitorTraceExporter({{ connectionString }}),
  metricReader: new PeriodicExportingMetricReader({{
    exporter: new AzureMonitorMetricExporter({{ connectionString }}), exportIntervalMillis: 60000,
  }}),
  instrumentations: [getNodeAutoInstrumentations()],
}});
sdk.start();

# Linux / macOS
export APPLICATIONINSIGHTS_CONNECTION_STRING="InstrumentationKey=xxx;..."
node -r ./instrumentation.js app.js

# Windows PowerShell
$env:APPLICATIONINSIGHTS_CONNECTION_STRING = "InstrumentationKey=xxx;..."
node -r ./instrumentation.js app.js

requests
| where timestamp > ago(1h) and duration > 500
| project timestamp, name, duration, resultCode
| order by duration desc | take 50

gcloud services enable cloudtrace.googleapis.com monitoring.googleapis.com
gcloud iam service-accounts create otel-exporter
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID --member="serviceAccount:otel-exporter@YOUR_PROJECT_ID.iam.gserviceaccount.com" --role="roles/cloudtrace.agent"
gcloud iam service-accounts keys create ./gcp-otel-key.json --iam-account="otel-exporter@YOUR_PROJECT_ID.iam.gserviceaccount.com" 

npm install @google-cloud/opentelemetry-cloud-trace-exporter @google-cloud/opentelemetry-cloud-monitoring-exporter

const {{ TraceExporter }} = require('@google-cloud/opentelemetry-cloud-trace-exporter');
const {{ MetricExporter }} = require('@google-cloud/opentelemetry-cloud-monitoring-exporter');
const projectId = process.env.GOOGLE_CLOUD_PROJECT;
const sdk = new NodeSDK({{
  traceExporter: new TraceExporter({{ projectId }}),
  metricReader: new PeriodicExportingMetricReader({{
    exporter: new MetricExporter({{ projectId }}), exportIntervalMillis: 60000,
  }}),
  instrumentations: [getNodeAutoInstrumentations()],
}});
sdk.start();

export GOOGLE_APPLICATION_CREDENTIALS="./gcp-otel-key.json"
export GOOGLE_CLOUD_PROJECT="your-gcp-project-id"
node -r ./instrumentation.js app.js

npm install @opentelemetry/id-generator-aws-xray @opentelemetry/propagator-aws-xray @opentelemetry/exporter-trace-otlp-grpc

const {{ AWSXRayIdGenerator }} = require('@opentelemetry/id-generator-aws-xray');
const {{ AWSXRayPropagator }} = require('@opentelemetry/propagator-aws-xray');
const {{ OTLPTraceExporter }} = require('@opentelemetry/exporter-trace-otlp-grpc');
const {{ propagation }} = require('@opentelemetry/api');
propagation.setGlobalPropagator(new AWSXRayPropagator());
const sdk = new NodeSDK({{
  idGenerator: new AWSXRayIdGenerator(),  // CRITICAL for X-Ray
  traceExporter: new OTLPTraceExporter({{ url: 'grpc://localhost:4317' }}),
  instrumentations: [getNodeAutoInstrumentations()],
}});
sdk.start();

export AWS_REGION=us-east-1
node -r ./instrumentation.js app.js

Quick Comparison: Azure vs GCP vs AWS

Common Errors and Fixes

OpenTelemetry Developer Handbook

OpenTelemetry is a CNCF Graduated project. All cloud vendor names are trademarks of their respective owners. Targets OTel SDK 1.x and Node.js 18+.

Zero-Downtime Deployment in Azure App Service: Deployment Slots, Health Checks and Rollbacks

Deploying an application should not require displaying a maintenance page, restarting the production application in front of users, or hoping that the new release starts successfully. Azure App Service provides deployment slots that allow teams to deploy, initialize, validate and test a new application version before it receives production traffic.

A properly designed slot-based deployment process separates two activities that are often incorrectly treated as one operation:

Every Azure App Service application has a default production slot. When the App Service plan supports deployment slots, you can create additional live environments such as staging, testing or pre-production.

Each slot has its own hostname, deployed application content and configurable settings. For example:

Production:
https://contoso-api.azurewebsites.net

Staging:
https://contoso-api-staging.azurewebsites.net

The responsibility of each slot

Create a staging slot using Azure CLI

az webapp deployment slot create \
  --resource-group rg-production-app \
  --name contoso-api \
  --slot staging \
  --configuration-source contoso-api

A slot swap is not the same as copying files from staging to production. Azure prepares the staging application with the target slot's applicable settings, restarts processes when required, sends warm-up requests and then redirects traffic.

What happens during a swap?

Warm-up is essential for applications that perform initialization tasks such as loading configuration, establishing connection pools, compiling views, populating caches, loading machine-learning models or resolving external dependencies.

Configure a custom swap warm-up path

WEBSITE_SWAP_WARMUP_PING_PATH=/health/ready
WEBSITE_SWAP_WARMUP_PING_STATUSES=200

The warm-up endpoint should return success only when the application is actually ready to serve traffic. A shallow endpoint that always returns HTTP 200 can allow an incomplete or unusable application instance to enter production.

Preview and execute the swap

# Preview the swap and apply production configuration to staging
az webapp deployment slot swap \
  --resource-group rg-production-app \
  --name contoso-api \
  --slot staging \
  --target-slot production \
  --action preview

# Complete the swap after validation
az webapp deployment slot swap \
  --resource-group rg-production-app \
  --name contoso-api \
  --slot staging \
  --target-slot production \
  --action swap

During a slot swap, some configuration values should move with the application, while environment-specific values should remain attached to their original slot. Azure calls environment-specific values deployment slot settings, commonly referred to as sticky settings.

Configure a sticky setting

az webapp config appsettings set \
  --resource-group rg-production-app \
  --name contoso-api \
  --slot staging \
  --slot-settings \
    ENVIRONMENT_NAME=staging \
    DATABASE_CONNECTION_STRING="staging-database-connection" \
    APPLICATIONINSIGHTS_CONNECTION_STRING="staging-insights-connection"

Deployment slots can make the web application deployment nearly seamless, but they do not automatically make database changes backward compatible. During a release, the old and new application versions can temporarily exist at the same time. Therefore, the database must support both versions throughout the transition.

Use the expand-and-contract pattern

Safe and unsafe database changes

A deployment completing successfully only proves that files or a container image reached App Service. It does not prove that the application started correctly, can connect to its dependencies or can process business requests.

Configure an application endpoint such as /health or /health/ready. A meaningful readiness endpoint can validate:

Enable App Service Health Check

az webapp config set \
  --resource-group rg-production-app \
  --name contoso-api \
  --generic-configurations '{"healthCheckPath": "/health/ready"}'

App Service Health Check regularly sends requests to the configured path on each instance. An endpoint response in the HTTP 200–299 range is treated as healthy. App Service can remove unhealthy instances from load balancing and continue checking them for recovery.

Run a staging smoke test

STAGING_URL="https://contoso-api-staging.azurewebsites.net"

curl --fail \
  --retry 12 \
  --retry-delay 10 \
  --retry-all-errors \
  "${STAGING_URL}/health/ready"

curl --fail "${STAGING_URL}/api/version"
curl --fail "${STAGING_URL}/api/smoke-test"

After staging is swapped into production, the previous production version moves to the staging slot. This creates a fast rollback path because the earlier release remains deployed and can be swapped back.

Rollback command

az webapp deployment slot swap \
  --resource-group rg-production-app \
  --name contoso-api \
  --slot staging \
  --target-slot production

Rollback decision process

A production-ready GitHub Actions workflow should deploy to staging first, validate the release, optionally run a controlled database migration, swap staging into production and then perform post-deployment verification.

Recommended pipeline

Complete GitHub Actions example

name: Deploy Azure App Service

on:
  push:
    branches:
      - main
  workflow_dispatch:

permissions:
  contents: read
  id-token: write

env:
  RESOURCE_GROUP: rg-production-app
  WEBAPP_NAME: contoso-api
  STAGING_SLOT: staging
  NODE_VERSION: 20
  STAGING_URL: https://contoso-api-staging.azurewebsites.net
  PRODUCTION_URL: https://contoso-api.azurewebsites.net

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    environment: production

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Configure Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Run automated tests
        run: npm test

      - name: Build application
        run: npm run build --if-present

      - name: Create deployment package
        run: |
          zip -r release.zip . \
            -x ".git/*" \
            -x ".github/*" \
            -x "release.zip"

      - name: Sign in to Azure using OpenID Connect
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - name: Deploy release to staging
        uses: azure/webapps-deploy@v3
        with:
          app-name: ${{ env.WEBAPP_NAME }}
          slot-name: ${{ env.STAGING_SLOT }}
          package: release.zip

      - name: Wait for staging readiness
        shell: bash
        run: |
          for attempt in {1..20}; do
            echo "Staging readiness attempt ${attempt}"

            if curl \
              --silent \
              --show-error \
              --fail \
              "${STAGING_URL}/health/ready"; then
              echo "Staging is ready."
              exit 0
            fi

            sleep 15
          done

          echo "Staging did not become ready within the expected time."
          exit 1

      - name: Run staging smoke tests
        shell: bash
        run: |
          curl --fail --show-error "${STAGING_URL}/api/version"
          curl --fail --show-error "${STAGING_URL}/api/smoke-test"

      - name: Run backward-compatible database migrations
        shell: bash
        env:
          DATABASE_CONNECTION_STRING: ${{ secrets.DATABASE_CONNECTION_STRING }}
        run: npm run database:migrate

      - name: Swap staging into production
        shell: bash
        run: |
          az webapp deployment slot swap \
            --resource-group "${RESOURCE_GROUP}" \
            --name "${WEBAPP_NAME}" \
            --slot "${STAGING_SLOT}" \
            --target-slot production

      - name: Validate production
        shell: bash
        run: |
          for attempt in {1..12}; do
            echo "Production validation attempt ${attempt}"

            if curl \
              --silent \
              --show-error \
              --fail \
              "${PRODUCTION_URL}/health/ready"; then
              echo "Production deployment is healthy."
              exit 0
            fi

            sleep 10
          done

          echo "Production validation failed."
          exit 1

For high-risk production environments, configure the GitHub production environment with required reviewers. The workflow can deploy and test staging automatically, pause for approval and then perform the production swap.

Before deployment

Before the swap

After the swap