DEV Community: Vignesh Athiappan

Promotable, Deployable, Rotatable: Making Bench Management an Actual Process

Vignesh Athiappan — Thu, 27 Aug 2026 13:57:52 +0000

Every services organisation has a bench — people between projects, waiting on a client start date, rolling off an engagement that ended early, or parked because the skill they have and the skill the market wants have drifted apart. The bench is not a defect. It's the cost of being able to say yes to work you haven't won yet.

What is a defect is not knowing anything useful about the people on it.

The usual state of affairs is a spreadsheet with a name, a skill string, a rate, and a date. That tells you who is unallocated. It tells you nothing about what to do about it. So the conversation in the weekly review becomes a series of individual negotiations, driven by whoever in the room happens to remember something about that person. Decisions don't accumulate. Six weeks later you have the same conversation about the same person, and nobody can reconstruct why the last one went the way it did.

PDR is one way out of that. It's a small idea, and most of the value is in the discipline it forces rather than the taxonomy itself.

The three dispositions

PDR classifies each person on the bench against three questions:

Promotable — is this person ready to move up a level? Not "are they good," but: is there evidence they are already operating above their current band, and would a promotion make them easier to place at a higher billing rate?

Deployable — can this person be put on billable work as-is, right now, with no intervention? This is the most misread of the three. Deployable is not a compliment. It means the skills match live demand and there is nothing blocking a start.

Rotatable — should this person move to a different technology, domain, or vertical? Rotation is the answer when someone is capable but their current specialisation has no pipeline behind it.

The point of three separate axes is that they are not mutually exclusive and they are not a ranking. Someone can be promotable and rotatable — a strong senior engineer in a dying stack. Someone can be deployable but not promotable — solid, well-matched, not ready for the next band. Someone can be none of the three, and that is the most important signal the framework produces, because it means the situation needs a decision that isn't "wait."

The moment you collapse this into a single label — a tier, a grade, an A/B/C — you lose exactly the information you built the system to capture.

The process

1. Intake

Bench entries come from allocation data, not from manual entry. If someone has to remember to add a person, the list will be wrong within a week. The system should derive the bench from the absence of active billable allocation, then let humans annotate.

Intake also needs a start date for the bench period. Aging is the single most predictive field you have, and it only works if the clock starts automatically.

2. Assessment

Someone with actual knowledge of the person marks the three flags. This is usually a delivery lead or a resource manager, not HR and not a tool.

Two design decisions matter more than they sound:

Unassessed must look different from assessed-and-negative. "Not promotable" and "nobody has looked at this yet" are completely different facts, and a UI that renders both as an empty checkbox will quietly destroy your data quality. Blank means unknown. Show it as unfinished.

Every negative or unusual combination needs a justification. Not a dropdown — free text, required, at the point of assessment. This is the gate that turns the framework from a labelling exercise into a decision record. It also slows people down, which is the intended effect. If marking someone as not deployable takes two seconds, it will be done thoughtlessly and often.

3. Action

A classification with no downstream action is theatre. Each disposition should route somewhere concrete:

Promotable → into the next promotion cycle with the justification attached as evidence
Deployable → into active matching against open demand
Rotatable → into a reskilling track with a named target skill and a timeline
None of the above → escalation, with a review date

The fourth case is the one organisations avoid building. It's also the one that determines whether the whole exercise is honest.

4. Audit

Every assessment change is appended, never overwritten. Who changed what, when, from what to what, and why. Append-only, no edits, no deletes.

This is non-negotiable for two reasons. The obvious one is that these records touch promotion, reassignment, and eventually separation decisions, and you will be asked to explain them. The less obvious one is that the history is where the actual insight lives. A person marked rotatable four quarters running, with four justifications, is telling you something about your reskilling programme, not about the person.

What actually goes wrong

Coverage gets measured instead of accuracy. "94% of the bench is assessed" is a number that goes up when people click things. It says nothing about whether the assessments are right. Coverage is a hygiene metric — worth a single indicator, not a dashboard. If your reporting makes coverage the headline, you have built an incentive to fill in boxes.

Deployable becomes the default. Marking someone deployable is the path of least resistance: it's positive, it needs no justification, it moves the problem to the matching team. Watch the distribution. If deployable is running above 70% of assessed bench while placement rates stay flat, the flag has stopped meaning anything.

Assessments go stale. A three-month-old assessment is a guess. Build in expiry — an assessment older than a defined window reverts to unassessed rather than continuing to display as fact. People will hate this. Do it anyway.

Rotation is recommended without capacity to deliver it. Marking someone rotatable is free. Actually retraining them costs money, bench time, and a mentor. If rotation recommendations exceed reskilling capacity by 5x, the flag is a way of deferring a harder conversation.

The framework gets used as a performance tool. PDR describes market fit and placement readiness. It is not a performance rating, and the two must not be joined. A high performer in a technology with no demand is not deployable, and if your system lets that read as a performance signal, you will lose good people and deserve to.

The honest framing

PDR is a decision-forcing device, not an optimisation engine. It won't tell you what to do with anyone. What it does is make the absence of a decision visible — an unassessed row, a stale assessment, a person marked rotatable for three quarters with no training assigned. That visibility is uncomfortable, which is the entire point, and it's also the reason most implementations quietly drift toward measuring completion rates instead.

If you're building something like this, the test isn't whether the dashboard looks good. It's whether the weekly bench review is shorter and produces fewer repeat conversations than it did before. If a person's situation comes up twice with no change in between, the system failed regardless of how much of the bench is "covered."

One last thing worth saying plainly: these are people, and the labels are blunt. "Not deployable" is a statement about a market, a skills pipeline, and a sales pipeline — three things the individual mostly doesn't control. Build the justification field wide, require it, and read what people write in it. That text is usually a more accurate description of your organisation's problems than of the person's.

CI/CD for Azure Logic Apps Standard on a Private (ILB) ASE — Without a VNet Agent

Vignesh Athiappan — Wed, 26 Aug 2026 04:19:58 +0000

How we wired an Azure DevOps pipeline to a Logic App Standard running on an internal App Service Environment, hit six real-world failures on the way, and ended with a deployment that needs no SAS tokens, no SCM access, and no VNet-connected build agent.

The problem

Logic Apps Standard on an ILB App Service Environment (ASE v3) has no public SCM (Kudu) endpoint. That kills the two "normal" deployment routes:

Route	Why it fails on ILB ASE
`az webapp deploy` / zip-deploy from a Microsoft-hosted agent	Talks to the SCM endpoint, which is private
VS Code / portal publish	Same SCM dependency, plus it isn't CI/CD

The usual answer is "stand up a self-hosted agent inside the VNet." That's the right long-term answer — but you can ship today without it, using Run-From-Package with a managed-identity-authenticated blob URL. The pipeline only ever talks to two public planes:

Azure Storage (upload the package)
ARM / management.azure.com (set one app setting, restart the app)

The app then pulls the package itself, from inside the VNet, using its own managed identity. SCM is never touched. No SAS token ever exists.

Git push ──▶ ADO pipeline ──▶ zip ──▶ Blob Storage
                                          ▲
                                          │ (pull via app's
                                          │  managed identity)
             ARM: set app setting ──▶ Logic App (ILB ASE)
             ARM: restart app

What you need before starting

#	Prerequisite	Notes
1	Logic App Standard resource, Started	A stopped app silently accepts settings and deploys nothing. Check the Overview blade — ours had been sitting in `Stopped` and cost us a confused hour
2	A storage account the ASE can reach	Same region as the ASE. Public network access enabled is the simple path; a private endpoint works too
3	A blob container, private access	e.g. `deployments`
4	An ADO agent (hosted or self-hosted) with Azure CLI installed	Ours was a Windows self-hosted box that did not have `az` — see failure #3
5	An ARM service connection	Any auth type works. If it's the "Managed identity (agent-assigned)" type, the identity must actually be enabled on the agent VM — see failure #2
6	Rights to create role assignments on the storage account and the Logic App's resource group	Or a friendly admin

Step 1 — Repository layout

One folder per Logic App Standard resource; one subfolder per workflow. The zip we deploy is simply the app folder's contents.

logicapps-platform/
├── apps/
│   └── la-integration-prod/          ← 1 folder = 1 Logic App Standard resource
│       ├── host.json                 ← runtime + extension bundle
│       ├── connections.json          ← connector references ({} to start)
│       ├── parameters.json           ← per-environment values ({} to start)
│       ├── .funcignore
│       └── Heartbeat-Test/           ← 1 folder = 1 workflow
│           └── workflow.json
└── pipelines/
    └── deploy-la-integration-prod.yml

host.json:

{
  "version": "2.0",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
    "version": "[1.*, 2.0.0)"
  }
}

connections.json:

{
  "managedApiConnections": {},
  "serviceProviderConnections": {}
}

Heartbeat-Test/workflow.json — a deliberately trivial pilot workflow. No connectors, no secrets, nothing that can fail for reasons unrelated to the pipeline. Prove the pipe first; migrate real workflows second.

{
  "definition": {
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "contentVersion": "1.0.0.0",
    "triggers": {
      "Every_Hour": {
        "type": "Recurrence",
        "recurrence": { "frequency": "Hour", "interval": 1 }
      }
    },
    "actions": {
      "Compose_Heartbeat": {
        "type": "Compose",
        "inputs": {
          "message": "Deployed via ADO pipeline",
          "runAt": "@{utcNow()}",
          "workflow": "@{workflow().name}"
        },
        "runAfter": {}
      }
    },
    "outputs": {}
  },
  "kind": "Stateful"
}

Path gotcha: if your files live in a subfolder of the repo (e.g. myrepo/logicapps-platform/apps/...), the pipeline's sourceFolder variable and trigger paths must include that prefix. Our first run failed with Cannot find path ...\apps\ for exactly this reason.

Step 2 — Identity and role assignments

Three grants total. Two for the pipeline's identity (whatever your service connection authenticates as), one for the Logic App's own identity.

2a. Pipeline identity

Role	Scope	Purpose
`Storage Blob Data Contributor`	The storage account	Upload the package
`Website Contributor`	The Logic App's resource group	Set app settings + restart

az role assignment create \
  --role "Storage Blob Data Contributor" \
  --assignee-object-id <pipeline-identity-object-id> \
  --assignee-principal-type ServicePrincipal \
  --scope "/subscriptions/<sub-id>/resourceGroups/<storage-rg>/providers/Microsoft.Storage/storageAccounts/<storage-account>"

az role assignment create \
  --role "Website Contributor" \
  --assignee-object-id <pipeline-identity-object-id> \
  --assignee-principal-type ServicePrincipal \
  --scope "/subscriptions/<sub-id>/resourceGroups/<logicapp-rg>"

How to find the pipeline identity's object ID when nobody remembers it: run a throwaway pipeline on the target pool that asks the instance metadata service directly:

trigger: none
pool:
  name: 'SelfHosted-Windows-Pool'
steps:
- powershell: |
    $r = Invoke-RestMethod -Headers @{Metadata="true"} -Uri "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
    $p = $r.access_token.Split('.')[1].Replace('-','+').Replace('_','/')
    switch ($p.Length % 4) { 2 {$p+='=='}; 3 {$p+='='} }
    $c = [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($p)) | ConvertFrom-Json
    Write-Host "objectId : $($c.oid)"
    Write-Host "resource : $($c.xms_mirid)"   # full ARM ID of the VM - tells you where it lives
  displayName: Who am I

If this returns Identity not found, the agent VM's system-assigned identity is off — enable it (VM → Identity → System assigned → On) and note the object ID it produces. This exact thing happened to us: the MI-type service connection had existed for months and had never worked.

2b. Logic App identity (the key to SAS-free deployment)

Enable the app's system-assigned identity (Logic App → Identity → System assigned → On), then:

az role assignment create \
  --role "Storage Blob Data Reader" \
  --assignee-object-id <logicapp-identity-object-id> \
  --assignee-principal-type ServicePrincipal \
  --scope "/subscriptions/<sub-id>/resourceGroups/<storage-rg>/providers/Microsoft.Storage/storageAccounts/<storage-account>"

RBAC propagation is real. Allow ~5 minutes between creating a role assignment and testing it. Restarting the app 30 seconds after the grant gives a false failure.

Step 3 — The pipeline

The complete, working YAML. Written for a Windows agent (all steps PowerShell); on a Linux agent, switch scriptType: ps to bash and adjust the validation step.

# ============================================================================
# Deploy Logic App Standard via Run-From-Package (Blob, MI-authenticated URL)
# The app pulls the package with ITS OWN managed identity: no SAS, no expiry,
# and the SCM endpoint is never touched, so an ILB ASE is not a problem.
#
# PREREQS:
#   - Logic App system-assigned identity ON, with 'Storage Blob Data Reader'
#     on the storage account
#   - Pipeline identity: 'Storage Blob Data Contributor' on the storage
#     account and 'Website Contributor' on the Logic App's resource group
# ============================================================================

trigger:
  branches:
    include: [ main ]
  paths:
    include:
      - apps/la-integration-prod/**
      - pipelines/**

pool:
  name: 'SelfHosted-Windows-Pool'     # or vmImage: 'ubuntu-latest' for SP-auth connections

variables:
  serviceConnection: 'my-azure-service-connection'
  resourceGroup:     'rg-logicapps-prod'
  appName:           'la-integration-prod'
  storageAccount:    'stdeploypkgs'
  container:         'deployments'
  sourceFolder:      'apps/la-integration-prod'
  packageName:       'la-integration-prod-$(Build.BuildId).zip'

stages:

# ----------------------------------------------------------------------------
- stage: Build
  displayName: Validate & package
  jobs:
  - job: Package
    steps:

    - powershell: |
        $bad = 0
        Get-ChildItem -Path "$(sourceFolder)" -Recurse -Filter *.json | ForEach-Object {
          $raw = Get-Content $_.FullName -Raw
          try { $raw | ConvertFrom-Json | Out-Null }
          catch { Write-Host "##vso[task.logissue type=error]Invalid JSON: $($_.FullName)"; $bad++ }
          if ($raw -match '"(secret|client_secret|clientSecret|password)"\s*:\s*"(?!@)') {
            Write-Host "##vso[task.logissue type=error]Inline secret in: $($_.FullName)"; $bad++
          }
        }
        if ($bad -gt 0) { exit 1 }
      displayName: Validate JSON + block inline secrets

    - task: ArchiveFiles@2
      displayName: Zip app content
      inputs:
        rootFolderOrFile: '$(sourceFolder)'
        includeRootFolder: false          # host.json must sit at the ZIP ROOT
        archiveType: zip
        archiveFile: '$(Build.ArtifactStagingDirectory)/$(packageName)'

    - publish: '$(Build.ArtifactStagingDirectory)/$(packageName)'
      artifact: package

# ----------------------------------------------------------------------------
- stage: Deploy
  displayName: Deploy to $(appName)
  dependsOn: Build
  jobs:
  - deployment: Deploy
    environment: 'logicapps-prod'         # add an approval gate on this environment
    strategy:
      runOnce:
        deploy:
          steps:

          - download: current
            artifact: package

          - task: AzureCLI@2
            displayName: Upload package to blob
            inputs:
              azureSubscription: '$(serviceConnection)'
              scriptType: ps
              scriptLocation: inlineScript
              inlineScript: |
                az storage blob upload `
                  --account-name $(storageAccount) `
                  --container-name $(container) `
                  --name $(packageName) `
                  --file "$(Pipeline.Workspace)/package/$(packageName)" `
                  --auth-mode login --overwrite

          - task: AzureCLI@2
            displayName: Point app at package (MI-auth URL, no SAS, no SCM)
            inputs:
              azureSubscription: '$(serviceConnection)'
              scriptType: ps
              scriptLocation: inlineScript
              inlineScript: |
                $ErrorActionPreference = "Stop"
                $url = "https://$(storageAccount).blob.core.windows.net/$(container)/$(packageName)"

                az webapp config appsettings set `
                  -g "$(resourceGroup)" -n "$(appName)" `
                  --settings WEBSITE_RUN_FROM_PACKAGE="$url" WEBSITE_RUN_FROM_PACKAGE_BLOB_MI_RESOURCE_ID="SystemAssigned" `
                  -o none

                az webapp restart -g "$(resourceGroup)" -n "$(appName)"
                Write-Host "Deployed $(packageName). App restarted."

          - task: AzureCLI@2
            displayName: Verify workflow exists
            inputs:
              azureSubscription: '$(serviceConnection)'
              scriptType: ps
              scriptLocation: inlineScript
              inlineScript: |
                Start-Sleep -Seconds 60
                $sub = az account show --query id -o tsv
                az rest --method GET `
                  --uri "https://management.azure.com/subscriptions/$sub/resourceGroups/$(resourceGroup)/providers/Microsoft.Web/sites/$(appName)/workflows?api-version=2022-03-01" `
                  --query "value[].name" -o tsv

Three lines carry the whole trick:

WEBSITE_RUN_FROM_PACKAGE = the plain blob URL — no SAS query string.
WEBSITE_RUN_FROM_PACKAGE_BLOB_MI_RESOURCE_ID=SystemAssigned — tells App Service to fetch the package using the app's own managed identity. Without this setting the runtime attempts anonymous access, fails, and the app reports ServiceUnavailable from the host runtime. This is the single most-missed step.
includeRootFolder: false in the archive task — host.json must be at the root of the zip, not nested one level down.

Step 4 — Run it, and what "success" looks like

Create the pipeline from the YAML, run it. First run will pause to ask permission on the service connection / environment / pool — click Permit.
Green pipeline, and the Verify step prints your workflow name(s).
Portal → Logic App → Workflows shows the workflow, Stateful, Enabled.
Open it → Run history → confirm a run actually executed with the expected output. A workflow that loads but never runs is not success.

Everything that actually went wrong (the useful part)

Our path to green, in order. If you're debugging, scan this table first.

#	Symptom	Root cause	Fix
1	`Unable to locate executable file: 'bash'`	Assumed Linux; the self-hosted agent was Windows	All steps → PowerShell (`scriptType: ps`)
2	`Invoke-RestMethod : {"error":"invalid_request","error_description":"Identity not found"}` on the metadata endpoint	Agent VM's system-assigned managed identity was off — the MI-type service connection had never actually worked	VM → Identity → System assigned → On. If the identity was enabled after boot, a VM restart may be needed before the token endpoint responds
3	`Azure CLI 2.x is not installed on this machine`	Fresh agent VM, no `az`	Install via portal Run Command (no RDP needed), then restart the agent service so it picks up the new PATH: `Invoke-WebRequest -Uri https://aka.ms/installazurecliwindows -OutFile C:\az.msi` `Start-Process msiexec.exe -ArgumentList '/i C:\az.msi /quiet /norestart' -Wait` `Get-Service vstsagent* \
4	{% raw %}`Get-ChildItem : Cannot find path '...\apps\'`	Repo files nested one folder deeper than the YAML expected	Fix `sourceFolder` and trigger `paths` to include the prefix
5	`ERROR: incorrect usage: --expiry should be within 7 days from now`	Identity-based (user-delegation) SAS is capped at 7 days — and a 7-day SAS would be a time bomb anyway, since the app re-reads the package URL on every restart	Drop SAS entirely; switch to the MI-authenticated plain URL (this article's approach)
6	Pipeline green, but portal shows `Error retrieving workflows. Encountered an error (ServiceUnavailable) from host runtime`	App couldn't pull the package: `WEBSITE_RUN_FROM_PACKAGE_BLOB_MI_RESOURCE_ID` missing, and the app's identity had no role on storage	Add the app setting; grant `Storage Blob Data Reader` to the app's identity; wait ~5 min for RBAC; restart

A 60-second diagnostic when the runtime won't start

Run from any machine with az — checks the four usual suspects at once:

$rg="rg-logicapps-prod"; $app="la-integration-prod"
$st="stdeploypkgs"; $strg="rg-storage"; $sub="<sub-id>"

# 1. Identity on?
az webapp identity show -g $rg -n $app --query principalId -o tsv

# 2. Both settings present?
az webapp config appsettings list -g $rg -n $app `
  --query "[?starts_with(name,'WEBSITE_RUN_FROM')].{n:name,v:value}" -o table

# 3. App identity has a role on storage?
az role assignment list --assignee <principalId-from-step-1> `
  --scope "/subscriptions/$sub/resourceGroups/$strg/providers/Microsoft.Storage/storageAccounts/$st" `
  --query "[].roleDefinitionName" -o tsv

# 4. Storage reachable at all?
az storage account show -g $strg -n $st `
  --query "{publicNetworkAccess:publicNetworkAccess, defaultAction:networkRuleSet.defaultAction}" -o table

Whichever check comes back empty is your culprit.

Why this beats the alternatives

Approach	Verdict
SAS URL in `WEBSITE_RUN_FROM_PACKAGE`	Works, but user-delegation SAS caps at 7 days and account-key SAS means handling keys. Either way the app dies quietly when the token expires — on whatever future day it happens to restart
Zip-deploy via VNet self-hosted agent	The classic answer. Fine — but it makes deployment hostage to one VM's health, and you still shouldn't need SCM for a package-based app
MI-authenticated Run-From-Package	No secrets, no expiry, no SCM, works from any agent that can reach ARM + Storage. The package is also immutable per build ID, so rollback = point the setting at the previous zip and restart

Hardening checklist for after the pilot

Approval gate on the ADO Environment before the Deploy stage.
Private endpoint on the storage account once the pattern is proven (the app pulls over the VNet; the pipeline needs its own route — service endpoint or an agent with access).
Lifecycle policy on the container — build-numbered zips accumulate forever otherwise.
Keep the inline-secret linter. It costs nothing and blocks the exact class of mistake that infests legacy workflow definitions.
New workflows that replace still-running legacy ones should ship disabled and be enabled at cutover — never let two schedulers fire the same job.

Total elapsed time for us, including all six failures: one working session. Total time if you follow this article: about 30 minutes — 25 of which are waiting for an MSI installer and RBAC propagation.

# CSPM, CWPP, CIEM, CNAPP, EASM: Decoding the Cloud Security Alphabet

Vignesh Athiappan — Sat, 22 Aug 2026 04:30:21 +0000

Part 4 of 4 in the "Security Testing Landscape" series

The cloud security market has produced some of the worst acronyms in IT history. Here's the secret that makes them all click: these aren't tests — they're continuous monitoring platforms, and each one watches a different layer of your cloud.

The analogy that makes it permanent: your cloud is a house.

CSPM — Cloud Security Posture Management

Are the doors and windows locked?

CSPM watches your cloud configuration: public storage accounts, wide-open network security groups, disabled encryption, subscriptions without MFA. It continuously scans against benchmarks (CIS, well-architected frameworks) and flags drift the moment someone loosens a setting.

Answers: "Is my cloud set up wrong?"
Tools: Microsoft Defender for Cloud, Wiz, Prisma Cloud, Orca

CWPP — Cloud Workload Protection Platform

Is there an intruder inside a room?

CWPP watches the workloads themselves — VMs, containers, serverless functions: vulnerabilities inside them, malware, suspicious runtime behavior, file integrity changes. Think of it as EDR, but for cloud compute.

Answers: "Is something bad running inside my machines?"
Tools: Defender for Servers/Containers, CrowdStrike Falcon Cloud Security, Aqua, SentinelOne

CIEM — Cloud Infrastructure Entitlement Management

Who has too many keys?

CIEM watches identities and permissions: which users, service principals, and managed identities can do what. It hunts over-permissioned accounts, roles nobody has used in months, and toxic combinations like "this identity can read the secrets vault and is reachable from the internet."

Answers: "Who can do too much?"
Tools: Microsoft Entra Permissions Management, Wiz, Sonrai, Tenable (Ermetic)

CNAPP — Cloud-Native Application Protection Platform

The whole smart-home security system.

Here's the trick: CNAPP is not a new capability. It's the umbrella that bundles CSPM + CWPP + CIEM (plus IaC scanning and container scanning) into one platform with one dashboard. Its real power is chaining findings into attack paths:

vulnerable container + public exposure + admin identity = critical attack path, fix this first

That prioritization — attack paths instead of ten thousand isolated alerts — is why the entire market converged on CNAPP.

Answers: "Show me the actual attack paths across everything."
Tools: Wiz, Prisma Cloud, Orca, Defender for Cloud (full plans) — the same vendors, selling the full suite

EASM — External Attack Surface Management

Walking around the street outside, checking what a burglar sees.

EASM flips the camera: it scans your organization from the public internet, like an attacker with a browser and patience. It routinely finds assets you forgot existed — abandoned subdomains, exposed test APIs, expired certificates, shadow IT spun up by a team three years ago.

The uncomfortable, recurring outcome: EASM discovers things that aren't in your asset inventory at all.

Answers: "What can the internet see of mine?"
Tools: Microsoft Defender EASM, Censys, Palo Alto Cortex Xpanse — and Shodan for the manual version

The House, One Last Time

Acronym	Watches	House analogy
CSPM	Settings/config	Doors and windows locked?
CWPP	Workloads	Intruder inside a room?
CIEM	Identities/permissions	Who has too many keys?
CNAPP	All of the above	The full smart-home system
EASM	The outside view	What the burglar sees from the street

One final classification note: CSPM, CWPP, CIEM, and CNAPP are all white box — they read your subscriptions with granted access. EASM is the lone black box of the group, and that outsider's perspective is exactly what makes it valuable.

Series Wrap-Up

Across four posts, the entire landscape reduces to four questions:

Is my application code safe? → App Security Testing (SAST, DAST, SCA…)
Can someone actually break in? → Offensive assessments (VAPT, red teams, bug bounties)
Are we designing, building, and proving it right? → Reviews and audits
Is my cloud continuously watched? → CSPM/CNAPP family

Master which question each acronym answers, and you'll never nod along blankly in a security meeting again.

The Security Work That Never Attacks Anything: Reviews, Audits & Threat Modeling

Vignesh Athiappan — Sat, 22 Aug 2026 04:30:00 +0000

Part 3 of 4 in the "Security Testing Landscape" series

The previous two posts covered tools and humans that attack systems. This group is different: nobody attacks anything. These are humans (and a few platforms) inspecting your designs, code, configurations, and paperwork — with full access. Every single item here is white box; that's the group's signature.

The best way to remember them is by the question each one answers on the project timeline.

"Are we designing it right?" — Before You Build

Threat Modeling

A structured brainstorm at design time: for each component, how would an attacker abuse it? The output is a prioritized list of threats and mitigations — before a single line of code exists, when fixes are cheapest.

The frameworks you'll hear:

STRIDE — the classic threat checklist: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
PASTA — a risk-centric, seven-stage methodology that ties threats to business impact.
DREAD — a scoring model for ranking threats: Damage, Reproducibility, Exploitability, Affected users, Discoverability.

Tools: Microsoft Threat Modeling Tool, OWASP Threat Dragon, IriusRisk

Architecture / Design Review

Security engineers walk the diagrams and data flows: where are the trust boundaries, is authentication centralized, are secrets in a vault, does a frontend talk directly to a backend when it shouldn't. If you've ever defended an architecture diagram in front of a senior reviewer, you've lived this one.

References: cloud well-architected security pillars, OWASP ASVS

"Did we build it right?" — During and After the Build

Secure Code Review (Manual)

A human reads the code — especially auth logic, crypto usage, and input handling — catching design-level flaws that automated SAST cannot, like "this check can be bypassed by calling the API endpoints in a different order." Tooling assists (Semgrep, CodeQL, PR review workflows), but the value is the brain.

Configuration Review / Hardening Assessment

Compare actual server, database, and cloud settings against a hardened baseline: TLS versions, open ports, default accounts, logging enabled. The gold-standard baselines are the CIS Benchmarks and DISA STIGs.

Tools: CIS-CAT, Nessus compliance scans, Azure Policy

"Are we running it right?" — Continuously

Cloud Security Posture Assessment

The configuration review idea, applied to your entire cloud estate, continuously: public storage, over-permissive IAM, missing encryption, exposed endpoints — all scored against benchmarks in near-real time.

Tools: Microsoft Defender for Cloud (secure score), Prisma Cloud, Wiz, Orca

"Can we prove it to outsiders?" — When Auditors Arrive

Security Audit / Compliance Assessment

An external auditor checks whether you actually follow a standard — through evidence, policies, interviews, and screenshots. The output is a certification or findings report, never an exploit.

The standards you'll meet:

ISO 27001 — certifies your information security management system
SOC 2 — a trust-criteria report, the staple for SaaS vendors
PCI DSS — mandatory if you touch card data
HIPAA / GDPR — health data and personal data regulations

Tools: GRC platforms like Vanta, Drata, ServiceNow GRC — but mostly document review.

"Are we spending money right?" — Above Everything

Risk Assessment

The business-level exercise that sits on top of all of it: list assets → identify threats → score likelihood × impact → prioritize. This decides where the security budget goes and feeds every other activity on this page.

Frameworks: ISO 27005, NIST 800-30, and FAIR if you want risk quantified in actual currency.
Tools: honestly, spreadsheets — or a GRC platform if you're fancy.

The Timeline Recap

Question	Activity	When
Designing it right?	Threat Modeling, Architecture Review	Before build
Built it right?	Code Review, Config Review	During/after build
Running it right?	Cloud Posture Assessment	Continuously
Proving it?	Compliance Audit	Audit season
Spending right?	Risk Assessment	Always, above all

Remember: the testing groups attack; this group inspects with full access. Both are necessary — inspection finds what attacks miss, and attacks prove what inspections suspect.

Final post in the series: the cloud alphabet soup — CSPM, CWPP, CIEM, CNAPP, and EASM.

From Vulnerability Scans to Red Teams: The Offensive Security Ladder

Vignesh Athiappan — Sat, 22 Aug 2026 04:29:14 +0000

Part 2 of 4 in the "Security Testing Landscape" series

Every company eventually asks: "are we actually hackable?" There's an entire industry of ways to answer that question, and they form a ladder of realism and cost. This post climbs it rung by rung.

Rung 1: VA — Vulnerability Assessment

An automated scanner sweeps your servers, VMs, and network for known CVEs and misconfigurations. It's breadth over depth: it finds and lists problems, but never exploits them. Think of it as a metal detector — it beeps, it doesn't dig.

Tools: Nessus, Qualys, OpenVAS, Rapid7 InsightVM
Box: Usually grey (the scanner gets network access or credentials); can run uncredentialed as black box.

Rung 2: PT — Penetration Testing

Now a human takes the scanner's findings and actually exploits them — chaining vulnerabilities, escalating privileges, reaching real data — to prove genuine business impact. Depth over breadth, scoped and time-boxed.

Tools: Burp Suite, Metasploit, Nmap, SQLMap, BloodHound, Cobalt Strike

This is where the black/grey/white box terminology originates:

Black box: the tester gets nothing but a URL or IP — simulates an external attacker.
Grey box: the tester gets a normal user account and basic docs — simulates an insider or a compromised user. This is the most common flavor in practice, and the best value.
White box: the tester gets source code, architecture diagrams, and admin credentials — maximum coverage per paid day.

Rung 3: VAPT — The Compliance Staple

VAPT is simply VA + PT packaged together: scan everything automatically, then let a human manually exploit the interesting bits. This is the standard annual engagement companies buy for compliance, and the term you'll see on every audit checklist in this part of the world.

Rung 4: Red Teaming

A red team gets a goal, not a scope: "reach the HR database without being detected." Weeks long, stealthy, no holds barred — phishing, physical entry, custom malware, whatever works. Crucially, it tests your defenders and detection capability, not just your systems. The blue team usually isn't told it's happening.

Tools: Cobalt Strike, Sliver, Mythic, GoPhish
Box: Black by design.

Rung 5: Purple Teaming

Red and blue sit at the same table. Red runs an attack technique, blue immediately checks "did our SIEM catch that?", they tune the detection, and repeat. Collaborative rather than adversarial — the fastest way to actually improve detection coverage.

Tools: MITRE ATT&CK framework, Atomic Red Team, VECTR
Box: White — full transparency is the point.

Rung 6: BAS — Breach & Attack Simulation

Software that continuously and automatically replays known attack techniques inside your environment to verify your controls (EDR, SIEM, WAF) still detect them — an always-on mini red team that never sleeps or invoices per day.

Tools: AttackIQ, SafeBreach, Cymulate, Picus
Box: Grey/white — agents installed inside, techniques known.

Rung 7: Bug Bounty

Open the doors and invite researchers worldwide to attack your production app, paying per valid bug instead of per day. Continuous coverage, pay-for-results economics.

Platforms: HackerOne, Bugcrowd, Intigriti
Box: Black — researchers get exactly what the public gets.

The Human-Focused Rungs

Three assessments attack things other than servers:

Social Engineering / Phishing Simulation targets your people — fake phishing emails, phone pretexting (vishing), USB drops — measuring click and credential-submission rates. Tools: GoPhish, KnowBe4, Microsoft Attack Simulator.
Wireless Assessment targets your airwaves — rogue access points, WPA2 handshake cracking, evil-twin attacks. Tools: Aircrack-ng, Kismet, WiFi Pineapple.
Physical Security Testing targets your building — tailgating, badge cloning, lock picking, plugging into exposed ports. Tools: Proxmark, LAN Turtle.

All three are black box: the targets don't know.

The Ladder, One Line

VA (scanner lists bugs) → PT (human proves bugs) → VAPT (both — the compliance staple) → Red Team (full attack, tests your people and detection) → Purple (red and blue learn together) → BAS (automate it forever) → Bug Bounty (outsource it to the world).

Each rung up costs more and simulates reality more faithfully. Most organizations start with VAPT and grow upward.

Next in the series: the quiet group that never attacks anything — reviews, audits, and threat modeling.

The Alphabet Soup of Application Security Testing, Explained With a Car

Vignesh Athiappan — Sat, 22 Aug 2026 04:28:48 +0000

Part 1 of 4 in the "Security Testing Landscape" series

If you've ever sat in a security review meeting and heard SAST, DAST, IAST, and SCA thrown around in the same sentence, you know the feeling: everyone nods, half the room is quietly Googling. This post fixes that permanently, using one analogy — your application is a car you're building and driving.

The Core Four

SAST — Static Application Security Testing

SAST is reading the car's blueprint before it's ever built. You spot that the brakes are drawn wrong without starting an engine.

In IT terms: SAST scans your source code for insecure patterns — SQL injection, hardcoded credentials, weak crypto — without running the application. It lives in your CI pipeline and fires on every commit or pull request.

Tools: SonarQube, Checkmarx, Fortify, Semgrep, GitHub CodeQL
Box: White box — it has full access to your code.

DAST — Dynamic Application Security Testing

DAST is test-driving the finished car and deliberately trying to crash it. It never looks at the blueprint.

In IT terms: DAST attacks your running, deployed application over HTTP exactly like an external hacker would — malicious payloads into URLs, forms, and headers. It has zero knowledge of your code.

Tools: OWASP ZAP, Burp Suite, Acunetix, Invicti
Box: Black box — it only sees what an attacker sees.

IAST — Interactive Application Security Testing

IAST is a sensor inside the car during the test drive. When the brakes get slammed, it feels exactly which part shook.

In IT terms: an agent sits inside the running app (in the JVM or .NET runtime) and watches code execute while your QA or DAST tests run. Result: it pinpoints the exact vulnerable line, combining the strengths of SAST and DAST.

Tools: Contrast Security, Synopsys Seeker, HCL AppScan
Box: Grey box — the app is running, but the agent sees internals.

SCA — Software Composition Analysis

Your build might be flawless, but the tires you bought from another shop have a recall notice. SCA checks the parts you didn't make.

In IT terms: SCA scans your dependency manifests — package.json, pom.xml, .csproj — against CVE databases for vulnerable open-source libraries (think Log4j) and license risks. Given that most modern codebases are 70–90% third-party code, this one is not optional.

Tools: Snyk, Mend, OWASP Dependency-Check, GitHub Dependabot
Box: White box.

The Supporting Cast

RASP (Runtime Application Self-Protection) is the odd one out — it's not a test at all. It's the airbag: an agent embedded in your production app that blocks real attacks as they happen, like killing a SQL injection mid-execution. Tools: Contrast Protect, Imperva RASP.

MAST (Mobile AST) is the same testing story for a motorbike — SAST and DAST applied to APK/IPA binaries, hunting mobile-specific issues like insecure local storage and reverse-engineering exposure. Tools: MobSF, NowSecure, Appknox.

API Security Testing ignores the car body and inspects the fuel pipe connections. Doors can be locked while a leaky pipe sinks you: it tests APIs directly for auth bypass, BOLA/IDOR, and mass assignment, usually driven by the OpenAPI spec. Tools: Postman, Burp Suite, 42Crunch, Salt Security. Typically grey box.

Fuzzing pours random junk into the fuel tank — sand, juice, bolts — until the engine chokes. Massive volumes of malformed input fired at an app or API until it crashes or misbehaves. Tools: AFL++, libFuzzer, Burp Intruder, RESTler. Typically black box.

Secret Scanning checks whether someone left the car keys taped to the windshield — leaked API keys, tokens, and connection strings in repos and git history. Tools: GitLeaks, TruffleHog, GitHub Secret Scanning. White box.

Container Scanning inspects the shipping crate the car arrives in — Docker images scanned layer by layer for OS-level CVEs before deployment. Tools: Trivy, Grype, Aqua. White box.

IaC Scanning audits the factory setup instructions. If the manual says "leave the door open," every car built there is unsafe: Terraform, Bicep, ARM, and Kubernetes YAML scanned for misconfigurations before anything is provisioned. Tools: Checkov, tfsec, Terrascan, KICS. White box.

The Timeline That Makes It Stick

Before the app runs (paperwork and parts): SAST, SCA, Secret Scanning, Container Scanning, IaC Scanning
While it runs in testing (test drives): DAST, IAST, Fuzzing, API Testing
While it runs in production (the airbag): RASP

And the box rule: anything that reads your files is white box; anything that attacks the running app from outside is black box; the agent that does both is grey.

Next in the series: the offensive world — VA, PT, VAPT, red teams and bug bounties.

The Product Maturity Matrix: How We Measure Whether Our Internal Products Are Actually "Grown Up"

Vignesh Athiappan — Sat, 22 Aug 2026 04:07:50 +0000

Every engineering team ships features. Very few teams can answer a harder question: is this product mature?

Not "does it work" — mature. Can it survive an audit? Can it survive the person who built it leaving? Can it survive an AI prompt injection attack at 2 AM on a weekend?

Recently, I was asked to review and refine our product maturity matrix — the framework we use to assess every internal product across our portfolio. What started as a review exercise turned into a genuinely useful lesson in what "maturity" actually means for modern products, especially ones with AI baked in. Here's what I learned.

Why a maturity matrix at all?

When you're running a portfolio of internal products — a PSA platform, an ATS, an AI assistant, dozens of integrations — you can't rely on gut feel. Each product has different teams, different tech debt, different risk profiles. A maturity matrix gives you one honest lens across all of them.

The version I reviewed covered 12 areas. By the time I was done, it was 10 — and sharper for it. The final structure:

Access Management
Security Monitoring
Encryption & Data Protection
AI Security & Risk Management
Architecture & Design
Data Quality
Integration Management
DevOps & Engineering Automation
Observability
Engineering Excellence

Each area has five concrete criteria. Not aspirations — checkable statements. "Rollback procedure is defined and tested." "Access reviews are done periodically with business owners." The difference between a checklist and a wishlist is whether you can fail it.

Lesson 1: Kill the duplicates, or the matrix eats itself

The first thing I found when reviewing was overlap. "Security attacks" appeared under Observability. "AI red-teaming" appeared in two places. Credential expiry monitoring was floating around with no clear home.

This matters more than it sounds. When the same control lives in three rows, three teams either all claim it or all assume someone else owns it. Both outcomes are bad.

The fix was a simple ownership rule:

Observability = visibility. Can you see what's happening — logs, dashboards, traces, latency, failures?
Security Monitoring = detection and response. Attacks, network traffic, alerts, SLAs.
AI Security = assessment. Red-teaming, risk reviews, guardrail evaluations.
Integration Management = operational hygiene. Job monitoring, credential and token expiry.

One control, one home. Everything got easier after that.

Lesson 2: "100% accuracy" is not a criterion — it's a trap

The original data quality row demanded "100% accuracy of all business reports." Sounds rigorous. It's actually the opposite.

You cannot measure 100%. You cannot prove it. Every audit against it either fails or gets hand-waved — and hand-waving is precisely what a maturity matrix exists to eliminate.

We replaced it with something you can actually run:

Business reports are validated periodically by the tech team against source data, and reported data issues are resolved within a defined SLA.

Measurable. Auditable. Honest. If your maturity criteria require perfection, teams will quietly stop taking the whole matrix seriously. Write criteria a good team can pass and a struggling team will visibly fail.

Lesson 3: AI changed what "mature" means

Five years ago, a maturity matrix stopped at DevOps and monitoring. Today, if your products have AI agents in them — and ours increasingly do — you need two new muscles:

AI Security & Risk Management as a first-class area. Prompt injection, data leakage, model misuse — these aren't hypotheticals. In our own security assessments we've caught things like PII slipping out through encoded payloads that a naive filter would never flag. Red-teaming your own AI features before someone else does it for you is now table stakes.

AI observability inside the observability row. Traditional APM tells you the request took 800ms. It doesn't tell you what the user asked, what the model answered, how many tokens it burned, or where in the agent chain the latency lives. Mature AI products trace the full conversation path: query → layers → response, with token usage and guardrail outcomes visible.

If your maturity framework predates your AI features, it's assessing a product that no longer exists.

Lesson 4: The most embarrassing finding is the most valuable one

One row in the matrix — Encryption & Data Protection — contained criteria that had clearly been copy-pasted from a completely different section. It described automation workflows. Nothing about encryption at all.

Nobody had noticed, because nobody had read it. It had been reviewed in meetings, circulated in emails, and nodded at repeatedly.

That's the real argument for periodic deep reviews of governance documents: not to add more rows, but to check that the existing ones still say what everyone assumes they say. We rewrote it properly — encryption at rest and in transit, secrets in a managed vault with no hardcoded credentials, PII classification and masking, retention and disposal policies.

Lesson 5: Merge what belongs together

The original matrix had separate rows for "Coding & Secure Practices" and "Release Notes," plus an empty placeholder called "Engineering Excellence." We merged all three.

Code review, static analysis, dependency scanning, release notes, updated documentation — these aren't separate disciplines. They're one discipline: the craft of shipping responsibly. Splitting them across rows just multiplied the paperwork without adding rigor.

A shorter matrix that people actually use beats a longer one they skim.

The takeaway

A product maturity matrix isn't a compliance artifact. Done well, it's a mirror. It tells you which of your products would survive scrutiny and which are running on luck and tribal knowledge.

Three principles carried the whole review:

Every criterion must be checkable. If you can't fail it, delete it.
Every control needs exactly one home. Overlap is unowned risk.
The matrix must evolve with the stack. AI features demand AI-shaped criteria.

If your team has a maturity framework gathering dust, open it up and actually read every row. You might find automation criteria hiding in your encryption section too.

What does product maturity look like in your organization? I'd genuinely like to hear how other teams are handling AI security and observability in their governance frameworks.

Serving Millions of Users Without Melting the Database (Explained with Swiggy)

Vignesh Athiappan — Thu, 20 Aug 2026 04:08:33 +0000

At 8:30 PM on a Friday, millions of people open a food app at once. How does it stay fast — and how does the database survive? Not with one trick, but with five layers, each removing load before it reaches the expensive part. Here they are, using Swiggy.

The 5 techniques

#	Technique	One-line
1	Caching	Keep hot data close, skip the slow DB
2	Load Balancing	Spread traffic across many servers
3	CDN	Serve content from near the user
4	Partitioning / Sharding	Split one huge DB into pieces
5	Autoscaling	Add/remove servers automatically

1. Caching

Keep frequently-used data somewhere fast so you don't hit the slow database every time.

Where caches live:

Level	Where	Swiggy example
Client	On your phone	Your cart, cached locally
CDN	Edge servers worldwide	Restaurant images
Distributed	A shared cache cluster	Menu, sessions (Redis)

How writes interact with the cache:

Strategy	How it works	Trade-off
Cache-aside	App fills the cache on a miss	Simple; first read is slow
Write-through	Write to cache + DB together	Always fresh; writes slower
Write-back	Write to cache now, DB later	Fast writes; risk of loss if cache dies

Swiggy: menu in a distributed cache (Redis), images on a CDN, cart on the client. Different data, different cache home.
Azure: Azure Cache for Redis.

The golden rule: cache things where "a few seconds stale is fine" (menu, restaurant list). Never cache things where stale = wrong (wallet balance, payment status).

2. Load Balancing

Spread incoming traffic across many identical servers so no single one drowns.

              ┌→ Server 1
Users → [ LB ]┼→ Server 2
              └→ Server 3   (LB picks which one)

Two types — L4 vs L7:

	L4 (Transport)	L7 (Application)
Sees	IP + port only	Full HTTP (URL, headers)
Speed	Faster, dumber	Smarter, slightly slower
Can do	Raw distribution	Route `/search` vs `/pay` to different pools

How it picks a server:

Algorithm	Rule
Round-robin	Next server in turn
Least connections	The least-busy server
IP hash	Same user → same server (sticky)

Swiggy: millions of requests spread across hundreds of servers. An L7 balancer routes /search to search servers and /payment to payment servers.
Azure: Load Balancer (L4), Application Gateway / Front Door (L7).

3. CDN — Content Delivery Network

Copy static content to servers around the world, so users get it from nearby.

❌ No CDN:  user in Chennai → fetches image from a US server (slow, far)
✅ CDN:     user in Chennai → fetches from a Chennai edge server (fast, near)

How content actually gets there — it's pull-based, not push:

First user in a region requests logo.png → the edge has nothing → it fetches from your origin, stores a copy, serves it.
Next users in that region → served from the edge copy; origin untouched.
Each edge manages its own cache, so another region still pulls from origin until its edge caches it too.

You never "upload" files to a CDN. The first request in each region fills the cache — which is why it needs almost no setup.

Three things beginners get wrong:

Myth	Reality
"The CDN caches automatically"	On modern services (like Azure Front Door) caching is opt-in per route — you switch it on
"It's safe to cache everything"	Never cache authenticated or per-user pages — a shared edge cache can serve one user's data to another
"Staleness is controlled"	If your origin sends no `Cache-Control`, the default TTL can be days — set your own

Swiggy: restaurant photos, app JS/CSS, menu images — all static, all cached at the nearest edge. Your biryani photo loads instantly because it's cached 20km away, not 12,000km. But the logged-in order page is never cached — that stays dynamic.
Key: a CDN is caching for location. Distance = latency, so serve from close by.

4. Partitioning / Sharding

Split one giant database into smaller pieces (shards), each holding part of the data.

The make-or-break decision is the partition key — how you split.

Strategy	How	Watch out
Hash	`hash(key)` decides the shard	Even spread, but no range queries
Range	A–M here, N–Z there	Simple, but can create hotspots
Directory	A lookup table maps key → shard	Flexible, but the lookup is a dependency

✅ Good	❌ Bad
Scales beyond one machine	Cross-shard queries are painful
Each shard is smaller/faster	The partition key is ~irreversible

Swiggy: orders partitioned by cityId or userId — Bengaluru's orders on one shard, Delhi's on another.
Azure: this is exactly the Cosmos DB partition key — the single most important, effectively permanent design choice you make up front.

⚠️ The trap: a bad key creates a hot partition — one shard takes all the traffic while the others sit idle. Choose a key that spreads load evenly.

5. Autoscaling

Automatically add servers when busy, remove them when quiet.

3 PM (quiet):   ▪▪         (3 servers)
8:30 PM (peak): ▪▪▪▪▪▪▪▪▪▪ (auto-scaled to 20)
2 AM (dead):    ▪          (scaled back to 1)

Type	Rule
Reactive	Scale when CPU/queue crosses a threshold
Predictive	Scale ahead of a known pattern (the dinner rush)

✅ Good	❌ Bad
Pay only for what you use	Scaling isn't instant (there's lag)
Handles spikes automatically	Cold starts on new instances

Swiggy: scale up before the 8 PM rush, scale down after midnight. Never pay for 500 servers at 3 AM.
Azure: VM Scale Sets, AKS autoscaler, App Service autoscale.

How they connect

CDN            → serves static content from the edge (never hits your servers)
Load Balancer  → spreads the dynamic traffic that remains
Caching        → cuts DB reads for that traffic
Partitioning   → splits the DB when caching isn't enough
Autoscaling    → adjusts server count to match live demand

Each layer removes load before it reaches the expensive part: CDN catches the easy stuff → the load balancer spreads the rest → the cache skips the DB → partitioning shares the DB load → autoscaling flexes capacity.

The whole thing in one line

Scaling isn't one big trick — it's five layers peeling load away before it reaches the database. Serve static from the edge, spread the rest, cache what you can, split what you can't, and flex capacity to match the crowd.

How Services Send Messages Without Losing Them (Explained with Swiggy)

Vignesh Athiappan — Wed, 19 Aug 2026 04:05:51 +0000

Instead of calling each other directly, services often drop messages and move on. It's more resilient — but it raises real questions. What if the receiver is down? What if a message gets processed twice and a customer is charged double? These 5 patterns are the answers.

The 5 patterns

#	Pattern	One-line
1	Message Queue	A buffer between sender and receiver
2	Publish-Subscribe	One message, many independent receivers
3	Competing Consumers	Many workers share one queue to scale
4	Dead-Letter Queue	Where failing messages go to be inspected
5	Idempotent Consumer	Processing twice = same result as once

1. Message Queue

A buffer that holds messages between sender and receiver. One message → one consumer.

Order svc → [ ▪▪▪ QUEUE ▪▪▪ ] → Payment svc
            (holds messages safely)

✅ Good	❌ Bad
Sender & receiver decoupled	Adds a component to manage
Receiver can be down — the message waits	Not instant (it's async)
Absorbs traffic spikes	Ordering can be tricky

Swiggy: "charge this order" is dropped on a queue. If Payment is briefly down, the message waits — nothing is lost.
Azure: Service Bus Queue.
Key idea: each message is consumed once, by one worker.

2. Publish-Subscribe (Pub-Sub)

One message published → delivered to MANY subscribers, each independently.

The difference from a queue: a queue delivers to one. Pub-sub delivers a copy to everyone who subscribed.

"Order placed" → [ TOPIC ] →→ Payment    (own copy)
                            →→ Restaurant (own copy)
                            →→ Analytics  (own copy)

✅ Good	❌ Bad
Add new subscribers without touching the sender	Harder to trace who got what
Fully decoupled	Eventual consistency
One event, many reactions	—

Swiggy: "order placed" → payment, restaurant, and analytics each get their own copy and react independently.
Azure: Service Bus Topic (with subscriptions), or Event Grid.

Queue vs Topic — lock this in:

Queue	Topic
One message → one consumer	One message → many subscribers
"Assign this task"	"Announce this happened"

3. Competing Consumers

Multiple workers pull from the SAME queue to process faster. They compete for messages.

             ┌→ Worker 1
[ QUEUE ] ───┼→ Worker 2   (whoever's free grabs the next message)
             └→ Worker 3

✅ Good	❌ Bad
Scale by adding workers	Message order isn't guaranteed
Auto load-balances	Workers must be stateless
Drains faster at peak	—

Swiggy: at dinner peak, 50,000 "charge order" messages pile up. Run 100 payment workers off one queue → it drains fast. Each message still goes to exactly one worker (no double-processing).
This is how you scale a queue consumer.

4. Dead-Letter Queue (DLQ)

A separate queue for messages that keep failing — so one bad message can't block everything.

The problem it solves is a poison message: one malformed message that fails, retries, fails, retries… forever, jamming the queue.

[ QUEUE ] → try process → fail → retry → fail (3x) → move to [ DLQ ]
                                                       ↑ inspect later; queue keeps flowing

✅ Good	❌ Bad
One bad message can't block the line	Needs monitoring
Failed messages saved for inspection	Manual cleanup

Swiggy: a corrupt order message fails 3 times → it's shoved into the DLQ → the main queue keeps flowing for everyone else. An engineer inspects the DLQ later.
Azure: Service Bus has a DLQ built-in on every queue and subscription.

⚠️ The trap: teams set up a DLQ and never watch it. Messages die silently. Always alert on DLQ depth.

5. Idempotent Consumer

Processing the same message twice produces the SAME result as processing it once.

Why you need it: queues can deliver a message twice (a network hiccup, a retry). Without protection, "charge ₹450" runs twice → the customer is charged ₹900. 💥

Message "charge order #123" arrives twice:
  ❌ Not idempotent: charge ₹450 + charge ₹450 = ₹900 (disaster)
  ✅ Idempotent:     "already processed #123?" → skip the 2nd → ₹450 ✅

How it works: track a unique message/operation ID; if you've seen it, skip it.

✅ Good	❌ Bad
Safe against duplicate delivery	Must store processed IDs
Retries become harmless	Adds a check on every message

Swiggy: every payment carries an idempotency key. A duplicate "charge" message is detected and skipped. Charged once.
This is non-negotiable in money flows — "at-least-once delivery" means duplicates will happen, so consumers must be idempotent.

How it all connects

Message Queue        → the basic buffer (1 → 1)
Publish-Subscribe    → the broadcast version (1 → many)
Competing Consumers  → scale the consumer side (many workers, 1 queue)
Dead-Letter Queue    → catch the failures
Idempotent Consumer  → survive duplicate deliveries

The whole thing in one line

A queue assigns one task; a topic announces to all. Then you scale it (competing consumers), protect it (dead-letter queue), and make it safe to retry (idempotent consumer). Get those right and messaging becomes the most reliable way for services to talk.

Keeping Data Correct Across Microservices (Explained with Swiggy)

Vignesh Athiappan — Tue, 18 Aug 2026 03:42:03 +0000

Here's the catch nobody warns you about: the moment you split an app into microservices, each one owns its own database — and suddenly there's no single source of truth. An order lives in one DB, its payment in another, its delivery in a third. So how do you keep everything correct? These 5 patterns are the answer.

The 5 patterns

#	Pattern	One-line
1	Database-per-service	Each service owns its data, period
2	Saga	Manage a transaction that spans many services
3	CQRS	Separate the write model from the read model
4	Event Sourcing	Store changes, not current state
5	Outbox	Reliably publish events without losing them

1. Database-per-service

Each microservice owns its own database. No other service touches it directly.

[Order svc]   → Order DB     ❌ Payment svc CANNOT read Order DB directly
[Payment svc] → Payment DB      it must ASK the Order service

✅ Good	❌ Bad
Services are truly independent	No easy JOIN across services
Change one DB freely	Data is spread out, harder to keep consistent
Fault isolation	You need the patterns below to fix consistency

Swiggy: Order, Payment, and Delivery each own their DB. This is why the next four patterns exist — it creates the consistency problem they solve.

⚠️ The golden rule: never let one service reach into another's database. Always go through its API or events.

2. Saga — the big one

A transaction that spans multiple services, done as a chain of steps with undo actions.

Normally a database transaction is all-or-nothing. But across 4 services with 4 databases, you can't wrap one giant transaction around everything. So a Saga does it as steps — and if one fails, it compensates (undoes) the earlier ones.

Place order:
  ✅ Order created
  ✅ Payment charged
  ❌ No delivery partner available!
  → COMPENSATE: refund payment → cancel order

Two flavors:

	Choreography	Orchestration
How	Each service reacts to events, no boss	One coordinator directs each step
Analogy	Dancers who know their cues	A conductor leading an orchestra
Good for	Simple flows	Complex flows
Downside	Hard to trace	The coordinator is a dependency

✅ Good	❌ Bad
Consistency without one giant lock	Complex to design
Each step can retry	You must write "undo" logic for everything

Swiggy: the classic "order stuck → auto-refund" flow. Payment succeeded but no rider? The Saga triggers the refund (a compensating transaction).
Azure: Durable Functions (orchestration) or Service Bus (choreography).

3. CQRS — Command Query Responsibility Segregation

Split your data model in two: one for writing, one for reading.

The name sounds fancy; the idea is simple. Writes and reads have different needs, so stop forcing them through one model.

WRITE side (Command): "Place order"     → normalized, safe, transactional
READ side  (Query):   "Show my orders"  → denormalized, fast, pre-shaped

The two sides are kept in sync (often via events).

✅ Good	❌ Bad
Reads are blazing fast (pre-built views)	Two models to maintain
Scale reads and writes separately	Eventual consistency between them
Each side optimized for its job	Overkill for simple apps

Swiggy: writing an order needs strict validation. Reading "your past orders" needs to be instant. CQRS lets the read side be a fast, pre-shaped view — no heavy JOINs at read time.

⚠️ Don't reach for CQRS unless read and write needs really diverge. It adds real complexity.

4. Event Sourcing

Instead of storing the current state, store every change as an event. Rebuild state by replaying them.

❌ Normal:        balance = ₹500   (you only see the final number)
✅ Event Sourced: +₹1000 deposited
                  -₹300 order
                  -₹200 order
                  → replay = ₹500   (and you have the FULL history)

✅ Good	❌ Bad
Complete audit trail (every change kept)	Complex to build
Can rebuild state anytime	Replaying can get slow (needs snapshots)
"Time travel" — see state at any past point	Steep learning curve

Swiggy: an order's life — placed → confirmed → cooking → picked up → delivered. Store each as an event and you get the entire timeline for free (great for support and disputes), not just "delivered."

Pairs with CQRS: the events are the write side; you build fast read views from them.

5. Outbox Pattern

Guarantees you never lose an event when you save data and publish a message.

Here's the hidden bug it fixes: you save an order to the DB, then publish "order placed" to the queue — but the app crashes between those two steps. Order saved, event lost, payment never happens. 💥

❌ Risky:  save order → 💥 crash 💥 → publish event (never runs)
✅ Outbox: save order + event in ONE DB transaction
           → a separate process reads the "outbox" table → publishes reliably

✅ Good	❌ Bad
Never lose an event	Extra table + a publisher process
Data + event saved atomically	Slight delay before publishing

Swiggy: "order placed" MUST reach payment. The outbox writes the order and the event together in one transaction, so a crash can't drop it.

How they fit together

These aren't 5 random tools. They're layers solving one chain of problems created by splitting the database:

Database-per-service   → creates the consistency problem
       ↓
Saga                   → keeps a multi-service transaction consistent
Outbox                 → makes sure the events driving it never get lost
CQRS                   → fast reads across all that split data
Event Sourcing         → full history + feeds the CQRS read side

The whole thing in one line

Splitting the database is what makes microservices powerful and what makes data hard. Saga keeps multi-service actions consistent, Outbox makes their events reliable, CQRS makes reads fast, and Event Sourcing keeps the full history. Reach for each only when the problem it solves is actually yours.

Where Do You Draw the Lines Between Services? (Explained with Swiggy)

Vignesh Athiappan — Mon, 17 Aug 2026 14:56:10 +0000

Splitting an app into microservices sounds easy — until you try it. Draw the boundaries wrong and you get a distributed mess that's harder to run than the monolith you started with. This post covers the 5 ideas that help you draw those lines well, using Swiggy.

The 5 ideas

#	Concept	One-line
1	DDD (bounded contexts)	Split by business domain, not tech
2	Strangler Fig	Safely kill a monolith piece by piece
3	Anti-Corruption Layer	A translator guarding your clean model from a messy one
4	BFF (Backend-for-Frontend)	A tailored backend per client (mobile vs web)
5	API Gateway	One front door for all services

1. DDD — Bounded Contexts

The core skill: split services by business domain, not by technical layer.

The word "order" means different things in different parts of Swiggy. DDD says: let each area own its own meaning.

❌ Wrong split (by tech):   [All Controllers] [All Databases] [All Logic]
✅ Right split (by domain): [Ordering] [Delivery] [Payments] [Restaurant]

A bounded context = a boundary where a word has ONE clear meaning.

Word	In Ordering	In Delivery
"Order"	items + price + cart	pickup + drop location + route

Same word, different meaning per context. Each context is a candidate microservice.

✅ Good	❌ Bad
Boundaries match the business	Needs deep domain knowledge
Teams own a whole domain	Over-splitting early = pain

Swiggy: Ordering, Delivery, Payments, Restaurant Onboarding, Search — each a bounded context, each a team.
The rule: find where the language changes → that's a boundary.

2. Strangler Fig

Kill a monolith gradually — never a risky big-bang rewrite.

Named after a vine that grows around a tree and slowly replaces it. You wrap the old system, peel off one feature at a time, until the monolith is gone.

Step 1: [Monolith] ← all traffic
Step 2: [Facade] → routes SEARCH to a new service, rest to monolith
Step 3: more features moved out...
Step 4: [Monolith gone] — all services new

✅ Good	❌ Bad
Low risk, one piece at a time	Slow, takes patience
Ship continuously	Two systems run in parallel for a while
Roll back easily	The facade adds complexity

Swiggy: moving from a 2014 monolith to microservices. You don't rewrite overnight; you strangle it feature by feature.
Azure: API Management as the facade — routes some paths to the old app, some to new services.

3. Anti-Corruption Layer (ACL)

A translator that stops a messy external system from polluting your clean model.

When you integrate with a third party (or a legacy system) whose data model is ugly, you don't let their mess leak into your code. You put a translation layer in between.

[Your clean Payment model] ← ACL translates → [Messy external bank API]

✅ Good	❌ Bad
Your domain stays clean	Extra layer to build/maintain
Swap the external system without touching your core	Translation adds a little latency

Swiggy: integrating a payment gateway or a legacy restaurant POS that returns weird formats. The ACL converts their mess into your clean shape — the Order service never sees the ugliness.

4. BFF — Backend-for-Frontend

A separate, tailored backend for each type of client.

A mobile app and a web dashboard need different data shapes. Instead of one bloated API serving both badly, give each its own backend.

[Mobile App] → [Mobile BFF]  ─┐
[Web App]    → [Web BFF]      ─┼→ shared microservices
[Partner App]→ [Partner BFF] ─┘

✅ Good	❌ Bad
Each client gets exactly what it needs	More backends to maintain
Mobile gets light payloads	Some logic duplicated
Change one client without breaking others	—

Swiggy: the customer app, the delivery-partner app, and the restaurant dashboard each hit their own BFF — mobile gets tiny payloads, the dashboard gets rich data. Same core services underneath.

5. API Gateway

One front door for all your services.

Clients don't call 20 services directly. They hit ONE gateway, which routes, secures, and manages everything.

Clients → [ API Gateway ] → [order] [payment] [search] [delivery]

What it handles in one place:

Job	Meaning
Routing	Send each request to the right service
Auth	Check tokens once, centrally
Rate limiting	Stop abuse
SSL termination	Handle HTTPS here
Aggregation	Combine several service calls into one

✅ Good	❌ Bad
One place for cross-cutting concerns	A single point of failure (must be highly available)
Clients don't know the internal layout	Can become a bottleneck

Azure: this is API Management (APIM).

Gateway vs BFF (the confusion everyone has)

	API Gateway	BFF
How many?	One for everyone	One per client type
Job	Route + secure + manage	Shape data for a specific client
Analogy	The building's main reception	A personal assistant per VIP

They stack: clients → their BFF → the gateway → services. BFF shapes; gateway routes.

How it all fits together

[Mobile] → [Mobile BFF] ─┐
[Web]    → [Web BFF]     ─┼→ [API Gateway] → microservices split by [Bounded Contexts]
                                                    ↑
                          (Strangler Fig built these by peeling off the monolith)
                          (ACL guards each service from messy external systems)

The whole thing in one line

Draw service boundaries where the business language changes (DDD), migrate to them safely (Strangler Fig), shield them from messy outsiders (ACL), give each client a tailored backend (BFF), and put one front door in front of it all (API Gateway). Get the lines right, and microservices actually pay off.

From Server Room to Cloud: Hard-Won Lessons from a Production Azure Migration

Vignesh Athiappan — Mon, 17 Aug 2026 05:23:09 +0000

What I learned migrating two enterprise applications from on-premises infrastructure to Azure — the gotchas nobody warns you about, and the patterns that saved us.

Over the past several months, I led the end-to-end migration of two enterprise applications from on-premises Windows servers and SQL Server to Microsoft Azure. Frontends, backend APIs, an integration layer, a production database, scheduled jobs, CI/CD pipelines, DNS — the whole stack. We completed production cutover with a full smoke-test pass and zero rollback.

It went well. But "went well" hides a lot of 2 AM debugging sessions. This post is everything I wish someone had told me before we started.

The Architecture (Generalized)

The target landscape looked like this:

Edge: CDN → Azure Front Door → WAF
Frontends: Two Node.js apps on Azure App Service
Backends: .NET 8 APIs on a shared PremiumV3 App Service Plan
API Gateway: Azure API Management — for integration traffic only
Database: Azure SQL Managed Instance (General Purpose) behind a private endpoint
Secrets: Azure Key Vault with private endpoint
Scheduled work: SQL Agent jobs on the MI + Windows Task Scheduler tasks on a small infra VM
CI/CD: Azure DevOps with a self-hosted agent inside the VNet
Monitoring: Application Insights per app, shared Log Analytics workspace

Nothing exotic. And yet almost every layer had at least one surprise.

Lesson 1: Azure AD 401s Are Almost Always an Audience Mismatch

Our most painful post-cutover bug: one API returned 401s for every authenticated request, even though the identical configuration "worked" on another API.

Root cause: the JWT validation middleware was comparing the token's aud claim against the configured ClientId — a plain GUID — while the tokens actually carried the audience as a full URI (api://<guid>). One app registration happened to issue GUID-form audiences; the other issued URI-form. Same code, different token shape.

The fix was one line: set an explicit Audience key in appsettings.json instead of relying on ClientId doubling as the audience.

Takeaway: When you see 401s in an Azure AD–protected API, decode the token first. Compare aud character-for-character against what your middleware validates. Don't assume the ClientId is the audience.

Related gotcha: when a gateway app registration fronts an API app registration, tokens must be requested with the gateway's client_id, not the API's. Requesting with the wrong one produces perfectly valid-looking tokens that fail validation downstream.

Lesson 2: Silent Logging Failures Are Worse Than Loud Errors

We spent hours debugging an integration API that returned 500s with no logs at all. Two separate issues had stacked:

The Serilog SQL sink was configured with unsubstituted placeholder strings (think #{ServerName}# left over from a deployment token that never got replaced). The sink failed to initialize — silently — and took all error reporting down with it.
UseAuthorization() had been placed inside a conditional block that only ran when auth was enabled. With auth toggled off for testing, the middleware pipeline was malformed and every request 500'd before reaching a controller.

Takeaways:

Always configure a console sink as a fallback. If your primary sink dies, you need somewhere to see it die.
Middleware order and placement is not optional decoration. UseAuthorization() belongs unconditionally in the pipeline; if you need an "auth off" mode, use a global AllowAnonymousFilter instead of restructuring the pipeline.
Audit your deployment token replacement. A #{Placeholder}# that survives into production config is a time bomb.

Lesson 3: Key Vault References Need Version Pinning After Rotation

We rotated the SQL admin password post-cutover, updated the secret in Key Vault, and expected App Services using Key Vault references to pick it up.

They didn't — at least not promptly. Versionless Key Vault references cache, and the refresh isn't instantaneous or predictable. During a credential rotation, "eventually consistent" is not what you want between your app and its database.

Takeaway: After rotating a secret, update App Service environment variables to a version-pinned Key Vault reference. Yes, it means touching config on every rotation. It also means you know exactly which secret version every app is using, which turns out to be worth a lot during an incident.

Bonus: watch out for special characters in connection string passwords. Semicolons, quotes, and braces need careful escaping — generate rotation passwords with a character set your connection string format tolerates.

Lesson 4: SQL Agent Jobs Don't Just Lift-and-Shift to Managed Instance

We had ~20 SQL Agent jobs to migrate. Managed Instance supports SQL Agent, but with constraints that broke our scripted-out jobs in three ways:

Domain-scoped job owners (DOMAIN\user) don't exist on MI. Every job owner had to be replaced with a SQL login created for the purpose.
sp_delete_job calls embedded in the scripted output had to be stripped.
Only T-SQL subsystem job steps are fully supported — anything using CmdExec, SSIS, or PowerShell subsystems needs to be re-homed (we moved those workloads to Task Scheduler on an infra VM).

Takeaway: Treat Agent job migration as a porting exercise, not a copy exercise. Script everything out, then clean systematically: owners, delete statements, subsystems.

The Task Scheduler tasks themselves migrated cleanly via XML export/import — but every task's connection config had to change from Integrated Security to SQL authentication, since there's no domain trust between an Azure VM and a Managed Instance out of the box.

Lesson 5: The Database Restore Itself Is the Easy Part

The actual data move was almost anticlimactic:

Take the source database offline
Take a final full backup and verify it (RESTORE VERIFYONLY — do not skip this)
Upload to blob storage with AzCopy
RESTORE DATABASE ... FROM URL with a SAS credential on the MI

What people forget is everything around the restore:

Recreate SQL users and role memberships. Logins don't travel inside the database backup the way you'd hope. Have a script ready for every application login with its exact role grants (datareader, datawriter, execute, etc.).
Run sp_updatestats post-restore. First-day performance complaints often trace back to stale statistics, not the cloud.
Verify TDE. Depending on how your database arrives, encryption at rest may not be enabled. Check it explicitly — ALTER DATABASE ... SET ENCRYPTION ON if needed — before your security review does.

Lesson 6: Draw the Traffic Flow, Then Draw It Again With Callouts

Our architecture had one nuance that everyone misread: the frontends called their backend APIs directly, while only integration/partner traffic routed through API Management.

Every new stakeholder assumed all traffic went through APIM. Every architecture review re-litigated it. Eventually I added an explicit callout panel to every diagram: "APIM handles integration traffic only. UI traffic bypasses APIM."

Takeaway: If a routing detail gets misread twice, it will be misread forever unless the diagram itself corrects the reader. Don't rely on people reading the arrows carefully — annotate the misconception directly.

Lesson 7: Workload Isolation on Managed Instance = Resource Governor

Our integration workload could occasionally hammer the database hard enough to affect interactive users. On Azure SQL Database you'd have limited options; on Managed Instance, Resource Governor is available and it's exactly the right tool:

A dedicated resource pool with CPU and memory caps for integration workloads
A workload group with lower importance and a MAXDOP limit
A classifier function routing sessions by SQL login

One caution: keep the classifier function trivial. It runs on every login, so anything slow in there becomes login latency for the entire instance.

Also budget time for the General Purpose tier's IO envelope. GP is remote-storage-backed; IO-heavy workloads that were fine on local SSDs on-prem can hit the ceiling. Query tuning, DOP limits, and alerting on IO percentage got us stable — but the honest long-term answer is often a tier or vCore bump.

Lesson 8: Load Test "Failures" Deserve Forensics Before Panic

Our first serious load test reported an 18–22% error rate. Cue alarm.

Root-cause analysis showed the application was fine: the JMeter test plan was missing Authorization headers on roughly half its samplers. The "errors" were 401s the app was correctly returning to unauthenticated requests.

Similarly, an early scare about latency dissolved on inspection: p95 around 700ms with a flat p50 around 180ms doesn't mean the system is degrading — it means occasional outliers exist. If p50 is flat under ramp, you don't have systemic pressure.

Takeaways:

Never accept a raw error percentage from a load tool. Break errors down by status code and endpoint before concluding anything.
Learn to read p50 vs p95 together. A scary p95 with a calm p50 is an outlier story, not a capacity story.
How the frontend calls APIs matters as much as API speed — parallel vs sequential call patterns change perceived latency dramatically.

Lesson 9: DNS Cutover Is a Sequence, Not an Event

The cutover itself was CNAME changes pointing custom domains at the Front Door endpoint. Simple. What made it low-drama:

Pre-stage everything at Front Door: custom domains validated, certs deployed, routes and WAF associations configured before touching DNS.
Inventory every hostname, not just the user-facing ones. We found integration and backend references still using an old domain suffix that had to be updated separately.
Hunt for hardcoded server names in code. We found an on-prem server name hardcoded in a repository base class. It didn't break cutover, but it was a landmine waiting for the day that server gets decommissioned. Grep your codebase for old hostnames before you celebrate.

Lesson 10: The Migration Isn't Done at Cutover

Green smoke tests on cutover day are the start of the hardening phase, not the end of the project. Our post-cutover backlog looked like:

Availability tests against the public URLs (through Front Door, not just direct)
Action groups and full alert rule coverage — an alert without a notification target is decoration
A PITR fire drill: actually restore the database to a point in time and prove the runbook works
Verifying the MI's public data endpoint is disabled — the kind of thing everyone assumes and nobody checks
Defender for Cloud, geo-filtering at the WAF, log consolidation
Documented upgrade path (zone-redundant compute, geo-replica for DR)

Takeaway: Write the "day 2" backlog before cutover, as a gap register with severity ratings. Otherwise cutover euphoria eats it.

The Meta-Lessons

If I compress the whole experience into four principles:

Distrust silence. Silent sink failures, silent cache staleness, silent config placeholders — the worst bugs made no noise. Build fallback observability everywhere.
Identity is the hardest layer. Compute and data moved predictably. Azure AD audiences, client IDs, SQL auth conversions, and login recreation caused more incidents than everything else combined.
Root-cause before you react. The load test scare, the 401 storm, the latency worry — every one of them looked like a crisis and turned out to be something narrower. The discipline of "break it down before you escalate" saved days.
Diagrams are living defenses against misunderstanding. The best architecture doc isn't the most complete one — it's the one that preempts the specific misreading your audience keeps making.

Migrating to the cloud isn't a technology problem. It's a hundred small correctness problems, each of which is easy in isolation and only dangerous because they arrive together. Track them in a register, kill them one at a time, and cutover day gets boring — which is exactly what you want.

Thanks for reading. If you're planning a similar migration and want to compare notes, I'm happy to talk.