Skip to content
Jose RubioES
All work

Case study 08 / 17Azure Cloud

Cloud delivery of a 3D digital twin and a client demo at parity

Moved a 3D twin to its own cloud host with managed settings and caching, and brought its client demo level with the product, checked daily.

Stack

  • Azure App Service
  • Azure CLI
  • Node.js
  • CesiumJS
  • WebGL
  • Web Workers
  • Brotli
  • Next.js

01 · How it works

  • Data flow

What it does

I moved a browser-based 3D twin of a pipeline system and a channel from a developer machine to its own cloud host, with its settings and imagery token managed outside the code. In the same effort I brought the product's cloud demo, the version external clients evaluate, from 229 commits behind to parity.

Read more

Every product API route is now answered or excluded for a stated reason, and a daily check flags new drift.

5 connections· select a part to trace it
  1. Build package to Cloud app server: precompressed brotli files
  2. Cloud app settings to Cloud app server: token on restart, no deploychanged
  3. Web client to Cloud app server: parallel requests at start
  4. Cloud app server to Web client: brotli, or 304 with 0 byteschanged
  5. Web client to Terrain service: terrain requests with token

02Results

  • R01Lower is better

    Client demo views failing a walkthrough (of 38)

    Before 14, after 0, eliminated. Lower is better.
    Before
    After
  • R02Lower is better

    Data a repeat visit downloads

    Before 9.4 MB, after 0.01 MB, 940× lower. Lower is better.
    Before
    After
  • R03Lower is better

    First visit, page load to scenario ready

    Before 5.1 s, after 4 s, −22%. Lower is better.
    Before
    After

What it achieved

  • Client demo: 14 of 38 views failing → 0, at parity with the product
  • API coverage: 55 routes unanswered → every route answered or excluded for a stated reason
  • Imagery token: hard-coded in source → one cloud app setting, rotated without a redeploy
Read more
  • Drift: found by hand → flagged the same day, and a lost patch anchor stops the copy
  • Repeat visit: 9.4 MB downloaded again → 0.01 MB or less, served from cache

The challenge

The twin ran from a developer machine with a hard-coded imagery token, so rotating the token required a code change. In the cloud it was slow for reasons the server could not explain: the host idled near 5% CPU while the browser chained requests, waited on terrain and recomputed the physics on every visit, with nothing cached.

Read more

The client demo had drifted much further: 229 commits behind, 55 product API routes unanswered and 14 of 38 views failing a walkthrough. What external clients evaluated no longer matched what the product does.

What I learned

Measure before buying hardware: a larger plan would have doubled the cost of a server idling at 5% CPU, when the delays lived in the browser. I planned to precompute the default scenarios, then measured the physics at 72 ms; the real wait was worker start-up, so the first scenario now runs on the page thread with nothing stored to go stale.

Read more

I rejected a token-hiding proxy, since the browser receives the token regardless. The demo runs the product's own engines over recorded scenarios: current behavior, nothing staged.

Stack

  • Azure App Service
  • Azure CLI
  • Node.js
  • CesiumJS
  • WebGL
  • Web Workers
  • Brotli
  • Next.js

Skills

  • Cloud deployment
  • Web performance
  • HTTP caching
  • Secrets management
  • Drift detection
Cover picture for Cloud delivery of a 3D digital twin and a client demo at parityCover picture for Cloud delivery of a 3D digital twin and a client demo at parity