The box arrived today, just in time before the holidays, sitting on my doorstep like a time capsule. The moment I saw the familiar Commodore logo on the packaging, I had to pause. It wasn’t just another retro gadget. It was the Commodore 64. Or at least, as close as we’re ever going to get in 2025.

I tore open the cardboard (carefully, because let’s be honest, I’ll probably keep the box) and there it was: the Commodore 64 Ultimate, in all its beige glory. The weight of it, the shape, even the slight texture of the plastic, it all felt right. Like holding a piece of my childhood again.

A Perfect Recreation

The first thing I noticed was the manual. A real, spiral-bound, physical manual, complete with BASIC listings. I flipped through it, running my fingers over the pages, and for a second, I was 12 years old again, typing in programs and hoping I didn’t make a typo. The attention to detail here is insane. The keyboard has that same satisfying clack (though, admittedly, with better switches than the original), the ports are all where they should be, and even the power LED glows with that same warm, slightly orange hue.

But this isn’t just a replica. It’s a reimagining.

The C64U is built around an FPGA, meaning it’s not emulation, it’s real hardware, just like the original. No software tricks, no shortcuts. It is a C64, just with a few modern luxuries. HDMI out. Wi-Fi. USB ports. A 48MHz Turbo mode (which feels almost like cheating). And yet, when I plugged in an old cartridge, it just… worked. No fuss. No compatibility issues. Just that familiar LOAD "*",8,1 prompt staring back at me, waiting for commands.

I connected it to my modern monitor via HDMI, but I also dug out an old CRT (Commodore 1084S monitor) from the garage, just to see. And there it was, the same slightly fuzzy, slightly wobbly image I remember from 1985. The same SID chip music, crackling through the speakers like it never left.

The Little Things That Matter

The C64U comes with a USB “cassette drive” preloaded with 100+ games, some classics and new (https://www.commodore.net/pressplay), tools, music and even a few demos that push the hardware in ways I didn’t think possible back then.

And then there’s the Turbo mode. 64MHz! My 12-year-old self would have lost his mind. Games load almost instantly. BASIC programs run at speeds that feel impossible. And yet, with a flick of a switch, I can throttle it back to 1MHz, just like the old days.

This Feels Different

I’ve owned a C64 in the past, but the Ultimate is something else. It’s not just about playing the games, it’s about feeling the machine again. The way the keys press down. The way the screen flickers just a little when you run a particularly aggressive POKE command.

It’s the closest I’ve ever gotten to reliving those late-night coding sessions, where I’d stay up way past my bedtime, typing in BASIC programs and hoping they’d work.

Is It Worth It?

At $299.99 (for the basic beige model, what I have), it’s not cheap. But then again, neither was the original C64 when it came out. And just like back then, this isn’t just a computer, it’s an experience.

If you grew up with the C64, you’ll understand. If you didn’t, well… this might just be the best way to find out what you missed.

I don’t know if I’ll use it every day. But I know I’ll keep it on my desk, within reach, for those moments when I need a little nostalgia or when I just want to remember what it was like to ‘boot’ up a computer and feel like anything was possible.

Now, if you’ll excuse me, I have a SID chip to abuse and some old type-in listings to revisit.

The Commodore 64 Ultimate isn’t just a retro computer, it’s a time machine with modern conveniences. It’s a love letter to the era of 1 MHz processors and 64 KB of RAM, wrapped in a package that makes it accessible and enjoyable in 2025. For anyone who ever loved the C64, this is as close as it gets to coming home.

Thank you Christian Simpson aka Peri Fractic to make this possible again!

RUN

I’ve been watching Model Context Protocol (MCP) servers pop up everywhere as the glue between AI agents and the real world. The pitch is simple: expose tools and data through a standard protocol and suddenly your AI agents can plan trips, analyze documents, query databases, or in my case, work with maps. MCP clicked for me because it’s opinionated where it matters and unopinionated where it shouldn’t. It standardizes how clients and servers talk, but it doesn’t box you into a single stack. Think of it as the USB-C of AI integrations: one cable, many devices.  

I’m a developer who lives in Visual Studio Code and ships on Azure. I wanted to see how far I could get by letting AI do the hands-on coding while I focused on architecture, constraints, and review. The goal was audacious but grounded: build a practical Azure Maps MCP server that exposes real geospatial capabilities as MCP tools, and get there largely by prompting. The result is live in a public repo if you want to skim or run it: cschotte/azure-maps-mcp.

What follows is the story of how I used GitHub Copilot in VS Code to go from a blank folder to a working MCP server backed by Azure Functions and the Azure Maps SDKs and REST APIs. I’ll walk through the prompts, the refactors, the architectural guardrails I put in, and the moments where the agent went off the rails and I had to step in.

Why MCP + Azure Maps?

Maps make agents useful. Route planning, isochrones, reverse geocoding, POI search, static renders, time zones, weather, even IP-to-country, these are building blocks for real workflows. Azure Maps gives you all of that via .NET SDKs and REST. I wanted a server that exposes a curated, batteries-included set of tools that an LLM can call safely and consistently. 

MCP gives me the language to describe those tools and a predictable way to call them from agentic clients. On the server side, I chose Azure Functions (isolated worker) so I could target modern .NET independently of the Functions host, wire up DI cleanly, and run everything locally with the Functions runtime while I iterate in VS Code. 

The “No-Code” Setup That Still Needs Engineering Judgment

I started with an empty folder in VS Code and asked Copilot Chat to scaffold an Azure Functions isolated worker project in C# targeting .NET 9. I was explicit about constraints: no in-process model, use DI, and keep the entrypoint minimal. Copilot generated Program.cs, a project with a Functions host, and a skeleton for configuration. I added a Services layer for Azure Maps, a Tools layer for the MCP endpoints, and a Common area for input validation, a small REST helper, and a uniform response envelope.

Copilot wrote the first pass of the Program.cs. I nudged it toward what I consider a healthy baseline: explicit logging, named HttpClient for REST calls, and a single place to bind the Azure Maps key from configuration (local dev reads from local.settings.json; production expects environment or Key Vault). The entrypoint ended up looking like this:

I asked Copilot to generate VS Code tasks so that F5 would build and start the Functions host and attach the debugger. It created a build (functions) task and a func: host start task wired to the Azure Functions Core Tools. From there, local development was a single keypress. The repo’s README shows the same flow if you want to reproduce it. 

Modeling the Tools the Way Agents Actually Use Them

I didn’t try to mirror every Azure Maps API. Instead, I curated a set that maps to common agent intents: find a place, reverse geocode and fetch boundaries, plan a route or compute an isochrone, fetch nearby POIs, render a static map, resolve an IP to a country, get a time zone, pull weather, and snap GPS points to roads. The server exposes these as discrete MCP tools with small, stable input shapes and predictable outputs.

Two early patterns mattered:

1. A uniform response envelope. Every tool returns { success, meta, data }. Lists use { query, items, summary }; singletons use { query, result }. This made it much easier to write prompts on the client side like “call location_find and show me the first item’s coordinates; if success is false, summarize the error.”
2. Stringy booleans at the boundary. Some MCP clients bind function args as strings. I kept boolean-like inputs as “true”/“false” at the tool boundary, then normalized them to real booleans in the handlers. It’s a small accommodation that avoided brittle binding errors across clients.

For example, the location_find tool accepts a text query and an includeBoundaries flag. Under the hood it calls Azure Maps Search and, if requested, walks a fallback strategy for polygons (locality → postalCode → adminDistrict → countryRegion) because boundary availability varies by place and level. Azure Maps’ coverage nuances are real; your tool needs to be defensive. 

Where Copilot Shined

I used three Copilot experiences constantly:

Ask mode was my rubber duck and librarian. I’d drop a doc link to Azure Maps Time Zone or Weather and say “extract the minimal request/response we need and sketch a C# wrapper.” It would lift the right REST path, query parameters, and payload into a clean method. For SDK-backed APIs like Search or Routing, I asked it to show the equivalent with the .NET client. That cut my “find the right API and object model” time to minutes. 

Edit mode let me refactor wide. When I noticed duplication in validation and HTTP error handling, I asked Copilot to “extract and centralize validation rules for lat/lon, radius, and ISO codes; make all tools use the same guard methods; return 400 with a consistent shape when validation fails.” It proposed diffs across multiple files, and I accepted them chunk by chunk. 

Agent mode was my power tool for multi-step tasks, like turning three loosely similar tool handlers into a single navigation_calculate that handles directions, matrix, and range (isochrone) flows with a calculationType discriminator. It iterated on compiler errors and mismatched types until it ran. I still reviewed the final diff like a hawk, but this mode saved hours. 

Copilot inevitably over-codes if you let it. It suggested extra abstractions I didn’t need and occasionally “fixed” something another model wrote by undoing it. I kept it on task with narrow prompts, frequent test runs, and a willingness to say “back up two commits and try a smaller step.” The more precise and isolated the task, the better the result.

Clean Inputs, Predictable Outputs

Each Function exposes one MCP tool via a simple HTTP trigger. Instead of binding directly to arbitrary JSON, I had Copilot generate specific request models with explicit types and validation attributes, then a controller-style handler that calls the service and wraps the result in the uniform envelope.

One subtle but important lesson: when you design for LLMs, error shapes matter. I made Copilot implement a small error type with a code, a friendly message, and a details bag. It turned cryptic HTTP exceptions into actionable feedback an agent can reason about.

Copilot for the “Glue Work”

The time savings weren’t just in code. I used AI smart actions in VS Code to generate commit messages that accurately summarized multi-file changes, then tweaked intent in a sentence or two. For README work, I pasted code and asked Copilot to explain usage tersely and to propose a clear “Build and Run” section. It also generated the local tasks.json pipeline that lets me run the Functions host with one command. These things used to be procrastination traps; now they’re minutes. 

What Went Sideways

Letting the agent roam is seductive. I tried one broad prompt “consolidate the three navigation handlers into a single tool with a discriminator; add docs and tests” and watched complexity creep in. The model introduced extra layers and re-named DTOs mid-diff. I aborted, rewrote the prompt into three atomic tasks, and the result was clean.

Model hopping also caused “helpful undo” moments. One model preferred slightly different DTO names and dutifully refactored usages, breaking earlier code. My rule now: pick one model per task, keep the diff small, and run the host between steps. Copilot is powerful, but you remain the engineer of record.

Lessons I’m Taking Forward

Agentic tooling is finally good enough to feel like a teammate. The biggest unlock wasn’t that Copilot wrote code; it was that it kept context across the repo, docs, diffs, and terminal output, and it could operate in different modes tailored to what I needed, ask, edit, or act. The trick is to design like a senior engineer and prompt like one: define constraints, choose simple interfaces, keep tasks small, and insist on clear error stories. Copilot will happily pour concrete, but you still have to draw the blueprint. 

On the product side, MCP is a pragmatic standard that lets me expose Azure Maps safely to any MCP-aware client without yet another bespoke integration. It’s early days, but the “USB-C for AI apps” metaphor is earning its keep. 

A personal history in a few very nerdy chapters

Pac-Man

The first “computer” that really knocked on my brain wasn’t even called a computer. It was an Atari 2600 with those giant wood-paneled vibes, a plastic spaceship parked under a living-room TV. Somewhere far from home (friends of my parents), the kind of visit where adults drink coffee forever, I met Pac-Man and the notorious E.T. They weren’t just games, they were a portal. The graphics were blocky miracles, the sound was pure electricity, and my head did that little swivel where a new obsession clicks into place. I didn’t own one. I barely got to touch it. But the idea got in. That was enough.

The Commodore 64

Back then a computer at home was a rare beast, the sort of thing you circled in a catalog and dreamed about. My dad heard coworkers talking about this “Commodore” machine and, after saving for ages, brought home a Commodore 64C with a tape drive, a color TV to borrow as a monitor, and one noble joystick that took more abuse than a drum kit. The original ad my dad marked up made it clear, this was an investment. For him it was “education.” For me and my brother, it was warp drive.

We fired it up and there it was, the blue screen that launched a million obsessions: READY. No OS like we think of today. Just the ROM, the kernel, and Commodore BASIC blinking at you like a dare. Our first flights were games, like Chopper Hunt and the brutal Fort Apocalypse, which taught me two things: one, helicopters are hard; two, loading from tape requires saintly patience.

BASIC

The C64 came with that ring bound manual that didn’t just tell you which key was RUN/STOP but taught you how to make the machine sing. I devoured First Computer Library titles like “Computer Fun” and “Simple BASIC” by Gaby Waters, beautifully illustrated by Graham Round. BASIC was my first superpower. I typed, I ran, I crashed, I learned. Printing scrolling text felt like broadcasting to the world. Making a sprite walk across the screen felt like building life from numbers.

10 PRINT "Hello World!"
20 GOTO 10

At some point the tape drive had to go. Floppies arrived like the future showing up early. Faster loads, easier saves, fewer rituals. Then came the add-ons that turned the C64 from a friendly pet into a pocket monster, the KCS Power Cartridge, followed by The Final Cartridge III with its delicious machine-code monitor. Suddenly I could freeze programs, peek inside, dump sprites, edit text right there in memory. It felt like lifting the hood and discovering the engine actually wanted to talk.

Assembly

I joined Computer Club Zeeland (CCZ), where Saturdays smelled like solder and success. We swapped disks, traded tips, and most importantly, shared knowledge. I kept a handwritten list of every relevant PEEK and POKE, plus addresses for C64 and SID registers like they were phone numbers of superheroes. BASIC had been great, but I wanted speed and control, so I dove into assembly for the MOS 6510, that quirky cousin of the legendary 6502. When your world is 64 KB wide and your CPU ticks around 1 MHz, you learn to think like a tightrope walker. Every byte counts, every cycle matters, and cleverness beats brute force nine times out of ten.

It still blows my mind when I look at today’s software, how much stuff we sling around just to draw a button. Back then, a demo would swirl a ’thousand’ sprites and play a melody that could break your heart, all while fitting into memory you could scribble on a napkin.

The Amiga 500

At CCZ meetups I kept drifting toward a table that sounded different. The Commodore Amiga had color that didn’t just glow, it danced. It had audio that wasn’t beeps, it was music. And it had a proper desktop, Workbench, that made the PC’s DOS prompt look like a gas station receipt. I did jobs, saved coins, begged grandparents, and eventually landed an Amiga 500. The built-in disk drive sounded like a tiny factory making joy.

I fell headfirst into DeluxePaint and lost countless evenings drawing pixels until they started to feel like atoms. Animations, palettes, and the delicious thunk of saving to disk, my creative loop clicked. And yes, I kept programming, this time with Devpac 3 Assembler and the Amiga ROM Kernel Reference Manuals. Nothing makes you feel more unstoppable than compiler warnings you finally understand.

The Amiga 1200

Eventually I sold the Amiga 500 and upgraded to an Amiga 1200, which felt like getting glasses and realizing trees have leaves. Better graphics, more memory, and then the absolute splurge, a 120 MB hard drive that cost me 800 Dutch guilders. I added a board with a MC68030 and an FPU, which my 3D software (LightWave 3D) gobbled up like candy. Through the first couple years of my Computer Information Sciences and Technology studies, I was still hardcore Amiga. PCs with MS-DOS or even Windows 3.1 felt like a downgrade in soul. The Amiga wasn’t just a machine, it was a party trick that never got old.

And then the music stopped. Commodore went bankrupt. The line that had taught me how to think about computers, that had taught me how to build, draw, and dream, just… ended. I kept the A1200 and I still have it, now with a few modern bionics: extra hardware, memory, fresh connectors, even HDMI. Every once in a while I power it up and the room gets that old glow again.

What the 8-Bit computers taught me

Those early machines taught me a kind of respect. When you only have 64 KB to play with, you learn restraint. When your CPU runs near 1 MHz, you learn patience and precision. And when you’re forced to understand memory maps, interrupts, and why your raster bar flickers, you learn to own your code. Today’s devices are miracles, but it’s easy to forget what sits under the glass. You don’t have to know how a car’s engine works to drive, but if you’re a developer, understanding how the pistons move will make you smoother on every curve.

Commodore is back

Here’s the plot twist I didn’t see coming, Commodore is back under Christian “Perifractic” Simpson (yep, the one from Retro Recipes). The first new product is the Commodore 64 Ultimate, a modern C64 that isn’t just emulation but the real silicon soul reborn. Of course I bought one. Of course I did. Sometime this year, my first true computer will walk back through my door wearing a new jacket, and I’m not even pretending to be chill about it.

READY.

From an Atari joystick miles from home to a blue screen that taught me the word READY., from PEEK and POKE to copper lists and DPaint brushes, the journey has always been the same, curiosity, tinkering, and the sheer thrill of making a machine do something it didn’t do a minute ago. My first computers didn’t just run programs, they rewired my brain. And as I wait for that C64 Ultimate to arrive, I can almost hear the SID warming up. One more program to write. One more sprite to nudge. One more chapter to load.

RUN

Why I Built an AI Assistant for My Blog

I wanted my blog to do more than list posts. I wanted visitors to be able to ask natural questions about me, my work, and anything I’ve written, and get answers that cite the right articles without me hand. In my previous post I laid the infrastructure groundwork by running n8n on Azure as an orchestration layer. This article goes deeper into how I assembled the chat assistant itself and wired it to semantic search so it actually “knows” my content rather than doing a brittle keyword lookup.

Structuring My Blog Data for Search and AI

I started by shaping the data. My site is a static Hugo build, which is convenient because Hugo can emit not just HTML and RSS but also JSON. That gave me a clean content feed I could parse from n8n and index into Azure AI Search. In hugo.toml I enabled JSON for the homepage and created a minimal contract for the assistant to consume. The output is a single index.json containing one object per page with normalized, plain-text content and the metadata I care about. The important detail is that the id and a stable id_hash are derived from the relative permalink, keeping updates idempotent when I re-publish.

This is the JSON template I use under /layouts/index.json:

{{/* Homepage JSON output for Azure AI Search vector store */}}
[
    {{- $pages := where .Site.RegularPages "Draft" "!=" true -}}
    {{- range $index, $page := $pages -}}
      {{- if $index -}},{{- end }}
      {
        "id": {{ $page.RelPermalink | jsonify }},
        "id_hash": {{ $page.RelPermalink | md5 | jsonify }},
        "title": {{ $page.Title | jsonify }},
        "description": {{ $page.Description | default $page.Summary | jsonify }},
        "content": {{ $page.Content | plainify | jsonify }},
        "url": {{ $page.Permalink | jsonify }},
        "relative_url": {{ $page.RelPermalink | jsonify }},
        "date": {{ $page.Date.Format "2006-01-02T15:04:05Z07:00" | jsonify }},
        "publishDate": {{ $page.PublishDate.Format "2006-01-02T15:04:05Z07:00" | jsonify }},
        "lastmod": {{ $page.Lastmod.Format "2006-01-02T15:04:05Z07:00" | jsonify }},
        "categories": {{ $page.Params.categories | default slice | jsonify }},
        "tags": {{ $page.Params.tags | default slice | jsonify }},
        "featured": {{ $page.Params.featured | default false }},
        "draft": {{ $page.Draft }},
        "type": {{ $page.Type | jsonify }},
        "section": {{ $page.Section | jsonify }},
        "wordCount": {{ $page.WordCount }},
        "readingTime": {{ $page.ReadingTime }},
        "keywords": {{ delimit (union ($page.Params.tags | default slice) ($page.Params.categories | default slice)) "," | jsonify }},
        "searchable_content": {{ printf "%s %s %s %s" $page.Title $page.Description ($page.Content | plainify) (delimit ($page.Params.tags | default slice) " ") | jsonify }},
        "summary": {{ $page.Summary | plainify | jsonify }}
      }
    {{- end }}
]

The content value is plain-text and already stripped of markup; this matters for embeddings because you want consistent tokenization, not HTML noise. I also assemble a searchable_content field that concatenates headline signals with the body and tags. While the assistant relies on vectors, Azure’s semantic search benefits from lexical hints for re-ranking and captions, so giving it both worlds improves quality.

Indexing with Azure AI Search and OpenAI Embeddings

With content ready, I defined an Azure AI Search index. The index has text fields for title, content, URL and keywords, plus a vector field that stores the embedding for each page. I use cosine similarity and HNSW for approximate nearest neighbor retrieval. The embedding model is OpenAI’s text-embedding-3-small hosted on Azure AI Foundry; it returns a 1536-dimension vector which must match the index’s dimensions property. If these don’t match, Azure will reject documents at ingestion time, so it’s worth calling that out explicitly.

Here is the index definition I deployed:

{
  "@odata.etag": "\"0x8DDD2B748AD9259\"",
  "name": "clemens",
  "fields": [
    { "name": "id", "type": "Edm.String", "key": true,  "searchable": false, "retrievable": true, "stored": true },
    { "name": "title", "type": "Edm.String", "searchable": true, "retrievable": true, "stored": true, "analyzer": "standard.lucene" },
    { "name": "url", "type": "Edm.String", "searchable": true, "retrievable": true, "stored": true, "analyzer": "standard.lucene" },
    { "name": "content", "type": "Edm.String", "searchable": true, "retrievable": true, "stored": true, "analyzer": "standard.lucene" },
    {
      "name": "vector",
      "type": "Collection(Edm.Single)",
      "searchable": true,
      "retrievable": false,
      "stored": true,
      "dimensions": 1536,
      "vectorSearchProfile": "vector-profile-1754242634632"
    },
    { "name": "keywords", "type": "Edm.String", "searchable": true, "retrievable": true, "stored": true, "analyzer": "standard.lucene" }
  ],
  "similarity": { "@odata.type": "#Microsoft.Azure.Search.BM25Similarity" },
  "semantic": {
    "configurations": [
      {
        "name": "clemens",
        "rankingOrder": "BoostedRerankerScore",
        "prioritizedFields": {
          "titleField": { "fieldName": "title" },
          "prioritizedContentFields": [{ "fieldName": "content" }],
          "prioritizedKeywordsFields": [{ "fieldName": "keywords" }]
        }
      }
    ]
  },
  "vectorSearch": {
    "algorithms": [
      {
        "name": "vector-config-1754242641035",
        "kind": "hnsw",
        "hnswParameters": { "metric": "cosine", "m": 4, "efConstruction": 400, "efSearch": 500 }
      }
    ],
    "profiles": [{ "name": "vector-profile-1754242634632", "algorithm": "vector-config-1754242641035" }]
  }
}

I kept the HNSW parameters conservative. A higher m increases the graph’s connectivity and memory footprint; dialing efSearch up lets me trade latency for recall at query time. Because my corpus is modest, I can afford an efSearch of 500 to make results stable without spiking response time.

Running Embedding and Upload Workflows in n8n

For embeddings I deliberately chose text-embedding-3-small over the larger variant. The quality difference on my content was negligible while the latency and cost advantages were tangible. A personal site rarely needs cross-domain reasoning. What matters is that semantically related passages end up close in vector space. The model is trained for that, and it performs well for questions that don’t literally match my phrasing, for example, “Where did you study?” finds my education background even if the word “school” never appears in the text, because vector similarity captures that intent.

Ingestion runs through n8n. I created a workflow that fetches https://clemens.ms/index.json, iterates records, calls the Azure OpenAI embeddings endpoint for each page’s content, and then pushes the merged document to Azure AI Search. The payload I send looks like this, with n8n expressions injecting values from the previous steps:

{
  "value": [
    {
      "@search.action": "mergeOrUpload",
      "id": {{ JSON.stringify($json.id) }},
      "title": {{ JSON.stringify($json.title) }},
      "content": {{ JSON.stringify($json.content) }},
      "url": {{ JSON.stringify($json.url) }},
      "keywords": {{ JSON.stringify($json.keywords) }},
      "vector": [ {{ $json.data[0].embedding }} ]
    }
  ]
}

The choice of mergeOrUpload allows me to re-run the workflow after publishing without wiping the index. The id remains stable across deployments, so the document is updated in place. For now I index by page rather than chunking into paragraphs. With a small corpus this is fine and massively simplifies grounding. If I grow into long-form guides, I’ll switch to chunking with overlap to improve retrieval granularity and reduce token usage when I assemble the context.

Designing the Chat Agent with Tool-Use and Guardrails

The assistant itself runs as an n8n “agent.” Conceptually it’s an orchestrator around a large language model with a single tool: semantic search against my index. I use GPT-5-mini for its reasoning and multi-turn memory. The agent has a compact system prompt that sets expectations, instructs the model to always consult the search tool when answering anything about my site, and reminds it to keep responses helpful and grounded. This is the skeleton of that prompt:

You are ClemensGPT, a helpful, trustworthy, and knowledgeable AI assistant for the personal website and blog of Clemens Schotte (https://clemens.ms).

Always use the Azure AI Search Index tool to search for answers about site content. Maintain conversational context across turns, but never fabricate facts; if the index has no answer, say so and suggest related posts.

At query time I embed the user’s message using the same text-embedding-3-small model, which guarantees the vectors live in the same space as my documents. I submit a hybrid request that includes both the raw query and the vector, asking Azure to apply semantic configuration for re-ranking and captions. I request the top three results, which gives the model enough grounding without flooding its context window. The request looks like this:

{
  "search": "{{ $('Webhook').item.json.body.content }}",
  "queryType": "semantic",
  "semanticConfiguration": "clemens",
  "vectorQueries": [
    { "vector": [{{ $json.data[0].embedding }}], "fields": "vector", "k": 30, "kind": "vector" }
  ],
  "select": "id,title,content,keywords,url",
  "top": 3
}

Frontend Integration and Final Deployment

The assistant then synthesizes a response by quoting or summarizing those passages. Because n8n gives me a built-in chat UI during development, I iterated on the prompt until the tool-use behavior was consistent. Once I was happy, I hardened CORS in the chat settings and embedded the production widget in my site with a simple script include:

<link href="https://cdn.jsdelivr.net/npm/@n8n/chat/dist/style.css" rel="stylesheet" />
<script type="module">
  import { createChat } from 'https://cdn.jsdelivr.net/npm/@n8n/chat/dist/chat.bundle.es.js';
  createChat({ webhookUrl: 'YOUR_PRODUCTION_WEBHOOK_URL' });
</script>

On the operational side I keep ingestion simple. A scheduled n8n trigger runs after I publish, pulls the fresh index.json, and updates the index. The Azure AI Search tier I’m on includes semantic capabilities; the free tier doesn’t.

The most satisfying test was asking questions the text doesn’t literally answer. “What technologies power this site?” brings back Hugo, Azure, and n8n from different posts and the about page. “What school did clemens study?” surfaces my background even though the word “school” isn’t used. That’s the point of using embeddings and semantic re-ranking together: intent over string matching, with just enough lexical signal to help the system pick the right snippets.

Visitors can now ask, and the site answers with context it actually understands. That feels like a small but meaningful upgrade to how a personal blog can work in 2025.

Last week I joined Geospatial FM, the podcast hosted by Wilfred Waters, to talk about AI agents and the Azure Maps MCP server I had created and bloged about.

We touched on how Bing Maps is the familiar public-facing mapping service, while Azure Maps is the developer platform for bringing mapping, routing, traffic, and spatial analytics into enterprise and IoT apps. The heart of our conversation was about Model Context Protocol (MCP) and why it matters. MCP lets AI agents use tools and pull fresh data from APIs, so instead of guessing about roads, traffic, or places, an agent can call Azure Maps in real time.

Watch & listen here:

Or you can also find it on YouTube, Spotify, and Substack:

• YouTube
• Spotify
• Substack

A lightweight Azure backend for my AI agent

Over the past few weeks, I’ve been exploring different ways to power a personal AI agent for my blog, one that can answer questions about me, my background, and my work using context I provide. I wanted a simple, secure, and cost-effective backend that I fully control and can iterate on fast.

n8n is a powerful open-source automation tool that’s perfect for wiring together APIs and logic without having to spin up tons of infrastructure.

But first, I needed to get n8n up and running on Azure.

This blog post documents exactly how I did it: deploying n8n on Azure Container Apps, connecting it securely to Azure Database for PostgreSQL Flexible Server, and setting everything up to follow best practices like private networking, basic auth, encryption, and persistent workflows.

What you’ll need

Before I could start stitching together containers and databases, I needed to make sure my local environment was ready. For me, that meant working from my Windows machine using PowerShell (my go-to shell for anything Azure-related). I wanted this setup to be clean, repeatable, and fully self-contained, without depending on extra tooling or scripts from elsewhere.

The goal was to keep things simple but robust. With just a few PowerShell commands and the Azure CLI, I’d provision a complete backend in the cloud that felt lightweight yet production-grade.

At the core of this setup is a single Azure Container App running the official n8nio/n8n image. It’s backed by a PostgreSQL Flexible Server that lives securely inside a private VNet. Every connection is internal. Every service knows its place. Nothing is exposed unless I want it to be.

If you’re ready to follow along, all you really need is an updated Azure CLI, the Container Apps extension, and a PowerShell window. That’s where we begin:

az upgrade --yes
az extension add --name containerapp --upgrade
az login
az account set --subscription "<YOUR_SUBSCRIPTION_ID_OR_NAME>"

1. Define your variables

This code defines all the values we’ll use: region, resource names, credentials, and secrets. Random values are generated for passwords and encryption keys so you never have to hardcode them.

# Region close to me (Netherlands)
$LOCATION = "northeurope"

# Resource names (lightweight but persistent)
$RG        = "n8n"
$ENV_NAME  = "n8n-lite-env"
$APP_NAME  = "n8n-lite"
$VNET_NAME = "n8n-vnet"
$SUBNET_NAME = "n8n-subnet"
$POSTGRES_SUBNET_NAME = "postgres-subnet"

# PostgreSQL Flexible Server (required for n8n best practices)
$POSTGRES_SERVER = "n8n-postgres-$(Get-Random -Maximum 99999)"
$POSTGRES_DB = "n8n"
$POSTGRES_USER = "n8nadmin"

# Basic auth for n8n editor
$N8N_BASIC_USER = "admin"

# Generate a strong random password for PostgreSQL and a 32-byte hex encryption key
Add-Type -AssemblyName System.Security
$bytes = New-Object byte[] 32
[Security.Cryptography.RandomNumberGenerator]::Create().GetBytes($bytes)
$N8N_ENCRYPTION_KEY = ($bytes | ForEach-Object { $_.ToString("x2") }) -join ""

$chars = (48..57 + 65..90 + 97..122)
$N8N_BASIC_PASSWORD = -join (1..24 | ForEach-Object { [char]($chars | Get-Random) })
$POSTGRES_PASSWORD = -join (1..24 | ForEach-Object { [char]($chars | Get-Random) })

2. Provision secure networking

We’ll create a virtual network and two subnets: one for Container Apps and one for PostgreSQL. Each is delegated to the correct Azure service for secure, private communication.

Write-Host "`nCreating resource group..." -ForegroundColor Cyan
az group create --name $RG --location $LOCATION | Out-Null

# Create VNet for secure communication (following best practices)
Write-Host "Creating secure virtual network..." -ForegroundColor Cyan
az network vnet create --resource-group $RG --name $VNET_NAME --location $LOCATION --address-prefixes 10.0.0.0/16 | Out-Null

# Create subnet for Container Apps
az network vnet subnet create --resource-group $RG --vnet-name $VNET_NAME --name $SUBNET_NAME --address-prefixes 10.0.0.0/23 | Out-Null

# Create separate subnet for PostgreSQL
az network vnet subnet create --resource-group $RG --vnet-name $VNET_NAME --name $POSTGRES_SUBNET_NAME --address-prefixes 10.0.2.0/24 | Out-Null

# Delegate Container Apps subnet
Write-Host "Delegating subnet to Container Apps..." -ForegroundColor Cyan
az network vnet subnet update --resource-group $RG --vnet-name $VNET_NAME --name $SUBNET_NAME --delegations Microsoft.App/environments | Out-Null

# Delegate PostgreSQL subnet
Write-Host "Delegating subnet to PostgreSQL..." -ForegroundColor Cyan
az network vnet subnet update --resource-group $RG --vnet-name $VNET_NAME --name $POSTGRES_SUBNET_NAME --delegations Microsoft.DBforPostgreSQL/flexibleServers | Out-Null

$SUBNET_ID = az network vnet subnet show --resource-group $RG --vnet-name $VNET_NAME --name $SUBNET_NAME --query id -o tsv

Write-Host "✓ Secure network created with separate delegated subnets" -ForegroundColor Green

3. Create a secure PostgreSQL server

n8n officially recommends PostgreSQL for production. Here we deploy a private Flexible Server inside the delegated subnet. No public access, no internet exposure.

Write-Host "`nCreating secure PostgreSQL Flexible Server..." -ForegroundColor Cyan

# Create PostgreSQL with VNet integration (secure, no public access)
az postgres flexible-server create `
  --resource-group $RG `
  --name $POSTGRES_SERVER `
  --location $LOCATION `
  --admin-user $POSTGRES_USER `
  --admin-password $POSTGRES_PASSWORD `
  --sku-name Standard_B1ms `
  --tier Burstable `
  --storage-size 32 `
  --version 14 `
  --vnet $VNET_NAME `
  --subnet $POSTGRES_SUBNET_NAME `
  --yes | Out-Null

# Create the n8n database
Write-Host "Creating n8n database..." -ForegroundColor Cyan
az postgres flexible-server db create `
  --resource-group $RG `
  --server-name $POSTGRES_SERVER `
  --database-name $POSTGRES_DB | Out-Null

Write-Host "✓ Secure PostgreSQL server created: $POSTGRES_SERVER" -ForegroundColor Green

4. Set up the Container Apps environment

Azure Container Apps supports full VNet integration, great for security and compliance. I disable Log Analytics to save costs and keep things simple.

Write-Host "`nCreating secure Container Apps environment..." -ForegroundColor Cyan
az containerapp env create `
  --resource-group $RG `
  --name $ENV_NAME `
  --location $LOCATION `
  --infrastructure-subnet-resource-id $SUBNET_ID `
  --logs-destination none | Out-Null

Write-Host "✓ Secure Container Apps environment created" -ForegroundColor Green

5. Deploy the n8n container

This is where it all comes together. We deploy the latest n8n image and configure all secrets and environment variables, including: Basic auth credentials, PostgreSQL connection string, Encryption key, TLS (automatically provided by Azure) and Static scaling (1 replica)

Write-Host "`nDeploying n8n container app..." -ForegroundColor Cyan

az containerapp create `
  --name $APP_NAME `
  --resource-group $RG `
  --environment $ENV_NAME `
  --image n8nio/n8n:latest `
  --ingress external --target-port 5678 `
  --cpu 1.0 --memory 2.0Gi `
  --min-replicas 1 --max-replicas 1 `
  --secrets `
      n8n-basic-password="$N8N_BASIC_PASSWORD" `
      n8n-encryption-key="$N8N_ENCRYPTION_KEY" `
      postgres-password="$POSTGRES_PASSWORD" `
  --env-vars `
      DB_TYPE=postgresdb `
      DB_POSTGRESDB_HOST="$POSTGRES_SERVER.postgres.database.azure.com" `
      DB_POSTGRESDB_PORT=5432 `
      DB_POSTGRESDB_DATABASE=$POSTGRES_DB `
      DB_POSTGRESDB_USER=$POSTGRES_USER `
      DB_POSTGRESDB_PASSWORD=secretref:postgres-password `
      DB_POSTGRESDB_SSL_REJECT_UNAUTHORIZED=false `
      DB_POSTGRESDB_CONNECTION_TIMEOUT=30000 `
      DB_POSTGRESDB_POOL_SIZE=5 `
      N8N_BASIC_AUTH_ACTIVE=true `
      N8N_BASIC_AUTH_USER=$N8N_BASIC_USER `
      N8N_BASIC_AUTH_PASSWORD=secretref:n8n-basic-password `
      N8N_ENCRYPTION_KEY=secretref:n8n-encryption-key `
      N8N_PROTOCOL=https `
      N8N_PORT=5678 `
      N8N_DIAGNOSTICS_ENABLED=false `
      N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true `
      GENERIC_TIMEZONE="Europe/Amsterdam" `
      TRUST_PROXY=true | Out-Null

Write-Host "✓ n8n container app deployed securely" -ForegroundColor Green

6. Configure webhooks and URL

After deployment, we extract the public FQDN and configure n8n’s internal variables like WEBHOOK_URL and N8N_HOST.

# Get the public hostname and configure webhook URLs
Write-Host "`nConfiguring webhooks..." -ForegroundColor Cyan
$APP_FQDN = az containerapp show `
  --resource-group $RG `
  --name $APP_NAME `
  --query "properties.configuration.ingress.fqdn" -o tsv

# Update webhook and host configuration
az containerapp update `
  --resource-group $RG `
  --name $APP_NAME `
  --set-env-vars WEBHOOK_URL="https://$APP_FQDN" N8N_HOST="$APP_FQDN" | Out-Null

Write-Host "✓ Webhook configuration complete" -ForegroundColor Green

7. Final output and login details

Summary of everything you need to access and manage the n8n instance, including login credentials.

Write-Host "`n=== n8n Secure Deployment Complete ===" -ForegroundColor Green -BackgroundColor Black
Write-Host "`nn8n URL: https://$APP_FQDN" -ForegroundColor Cyan
Write-Host "Username: $N8N_BASIC_USER" -ForegroundColor Yellow
Write-Host "Password: $N8N_BASIC_PASSWORD" -ForegroundColor Yellow

Write-Host "`nPostgreSQL Details (Private Network):" -ForegroundColor Cyan
Write-Host "Server: $POSTGRES_SERVER.postgres.database.azure.com" -ForegroundColor Yellow
Write-Host "Database: $POSTGRES_DB" -ForegroundColor Yellow
Write-Host "User: $POSTGRES_USER" -ForegroundColor Yellow
Write-Host "Password: $POSTGRES_PASSWORD" -ForegroundColor Yellow

In the Azure Portal it looks like this:

Connecting my AI chat agent to n8n

At this point in the setup, I finally had what I needed: a secure, self-hosted instance of n8n, always-on, neatly tucked into a private Azure network, and ready to receive input. But this wasn’t just about deploying a container or setting up PostgreSQL correctly. I was building the backend for something more personal, an intelligent agent that could talk to visitors on my blog, understand who I am, what I’ve worked on, and respond as if it were me.

That’s the vision behind ClemensGPT.

Inside n8n, it all starts with a workflow triggered by a webhook. This is the entry point, the moment someone on my website types a message into the chat box, and the request flows through the cloud, landing inside my n8n container. From there, the magic begins.

The workflow parses the message, routes it through a series of logic steps and returns a thoughtful, contextual response. The actual chat interface on the blog is nothing more than HTML and JavaScript calling the right endpoint, but behind the curtain, there’s a full orchestration engine at work.

This is what excites me most about building with n8n and Azure, every piece is composable, flexible, and private by design. I can iterate fast, fine-tune workflows in real time, and integrate anything from OpenAI to my own MCP server or blog metadata store.

The infrastructure is now invisible. All that’s left is the experience.

Conclusion

When I started this project, I just wanted a way to play with ideas, I needed something small and cheap. But what I ended up creating is the foundation for something much bigger, an extensible, secure automation engine that powers a real-time AI assistant tied to my digital identity.

This wasn’t just about running n8n in a container. It was about control. About learning. About giving shape to an idea I had late one night “what if my blog could talk back?”

The beauty of this approach is that I’m not limited to just one agent. Tomorrow, I can build another focused on developer tools, or Azure Maps APIs, or even automating parts of my work. With n8n as the backend and Azure AI as the brain, the possibilities are wide open.

In the next post, I’ll show how I designed ClemensGPT itself, how I injected memory and personality into the responses, streamed tokens for instant feedback, and fine-tuned everything to reflect my voice. But for now, the backend is alive. The pipes are connected. The agent is listening.

The first time I connected Visual Studio Code with GitHub Copilot, I expected party tricks. I got something closer to a new way of working. It wasn’t that code appeared by magic. It was that the little frictions, like the boilerplate, the glue code, the tests I knew I should write but kept postponing, stopped dominating my day. VS Code had already been my editor of choice for its ergonomics and extensibility; Copilot turned that editor into a cockpit where intention became motion. This post is my field report: what I actually run, how I prompt, where it saves time, and where I still slow down and think.

What I ask from an IDE

My week crosses C# backends on .NET, Rust services and CLIs, and the occasional Zig utility when I want to get close to the metal. I need a place where navigation doesn’t melt under solutions and workspaces, where debugging is first-class for CoreCLR and native processes, where analyzers and formatters keep me honest, where I can orchestrate repeatable tasks without a pile of shell glue, and where a brand-new contributor can open the project and be productive in minutes. VS Code hits those marks out of the box; the difference after adding Copilot is that the hand-offs, like authoring tests, drafting docs, sketching refactors, writing commit messages, start to feel like a single continuous motion instead of separate chores.

What I think about Copilot

Copilot is, for me, a drafting engine with context awareness. It reads what I’m doing in the editor and offers the most likely next move. I don’t treat it as an oracle. I treat it like a sharp junior engineer who has seen a million repositories and never gets tired of typing. If my intent is vague, its suggestions are vague; if my intent is precise, its drafts become eerily on target. When I’m unsure where I’m going, I sketch types or tests first, then let Copilot fill the empty spaces. When correctness matters, I keep my hands on the wheel, review everything, and tighten the specs.

The setup I actually use

I keep VS Code lean but deliberate. Copilot and Copilot Chat are installed and enabled. For C#, the C# Dev Kit and the official C# extension give me language services, Roslyn analyzers, and a one-keystroke test runner. For Rust, rust-analyzer and CodeLLDB give me the right balance of hints and stepping power; for Zig, the Zig extension keep the feedback loop tight. I treat VS Code’s tasks and launch configurations as part of the codebase because “press F5 and go” is culture, not an accident.

Prompts that pull their weight

The prompts that consistently work are specific, grounded in the files that are open, and framed with constraints. I’ll say, “Given CsvToNdjson.cs, rewrite the parser to avoid allocations using spans; keep the public signature, add tests for malformed rows.” Or, “In src/main.rs, add Serde models and stream CSV to NDJSON with proper error handling; no panics; propose a minimal diff.” If I’m refactoring, I’ll ask for a before/after with a rule like “no side effects; inject I/O; keep pure functions testable.” When a test fails, I paste the stack trace and ask for an explanation and a minimal patch that doesn’t change the public API. The more I emphasize small functions, exhaustive types, and early returns, the more the drafts read like my code instead of generic code.

Examples

I like examples that stand up in production. A simple but representative task is a streaming transform that reads a large CSV, converts amounts, and writes NDJSON (It’s a format where each line is a separate JSON object). It’s the kind of thing with a right answer but lots of ceremony.

C#

I want this to run in constant memory, avoid unnecessary allocations, and write one JSON object per line. I’ll keep the parser simple and deterministic and use System.Threading.Channels to bound the pipeline so one slow stage does not drown the rest.

// src/CsvToNdjson.cs
using System.Buffers.Text;
using System.Text;
using System.Text.Json;
using System.Threading.Channels;

public static class CsvToNdjson
{
    public record InputRow(string Id, int AmountCents, string Currency)
    {
        public bool IsHighValue(int threshold) => AmountCents >= threshold;
    }

    public static async Task ConvertAsync(
        string csvPath,
        string outPath,
        int threshold = 50_000,
        CancellationToken ct = default)
    {
        var channel = Channel.CreateBounded<InputRow>(new BoundedChannelOptions(8192)
        {
            SingleReader = true,
            SingleWriter = true,
            FullMode = BoundedChannelFullMode.Wait
        });

        var producer = Task.Run(async () =>
        {
            await using var fs = File.OpenRead(csvPath);
            using var sr = new StreamReader(fs, Encoding.UTF8, detectEncodingFromByteOrderMarks: true, bufferSize: 1 << 16);
            string? header = await sr.ReadLineAsync();
            if (header is null) return;

            while (!sr.EndOfStream)
            {
                ct.ThrowIfCancellationRequested();
                var line = await sr.ReadLineAsync();
                if (string.IsNullOrWhiteSpace(line)) continue;

                // naive split; swap with a CSV reader if your data contains quoted commas
                var parts = line.Split(',');
                if (parts.Length < 3) continue;

                if (!int.TryParse(parts[1], out var amount)) continue;
                var row = new InputRow(parts[0], amount, parts[2]);
                await channel.Writer.WriteAsync(row, ct);
            }

            channel.Writer.Complete();
        }, ct);

        await using var outStream = File.Create(outPath);
        await foreach (var row in channel.Reader.ReadAllAsync(ct))
        {
            var json = JsonSerializer.Serialize(new
            {
                id = row.Id,
                amountCents = row.AmountCents,
                currency = row.Currency,
                isHighValue = row.IsHighValue(threshold)
            });

            var bytes = Encoding.UTF8.GetBytes(json);
            await outStream.WriteAsync(bytes, ct);
            await outStream.WriteAsync(new byte[] { (byte)'\n' }, ct);
        }

        await producer;
    }
}

I like my tests to be small and expressive. xUnit gives me exactly that, and Copilot happily drafts the first pass that I then tighten.

// tests/CsvToNdjsonTests.cs
using System.IO;
using System.Text;
using Xunit;

public class CsvToNdjsonTests
{
    [Fact]
    public async Task Converts_And_Flags_High_Value()
    {
        var csv = "id,amount,currency\nA,50000,EUR\nB,49999,USD\n";
        var tmpCsv = Path.GetTempFileName();
        var tmpOut = Path.GetTempFileName();
        await File.WriteAllTextAsync(tmpCsv, csv, Encoding.UTF8);

        await CsvToNdjson.ConvertAsync(tmpCsv, tmpOut, threshold: 50_000);

        var lines = await File.ReadAllLinesAsync(tmpOut, Encoding.UTF8);
        Assert.Contains("\"isHighValue\":true", lines[0]);
        Assert.Contains("\"isHighValue\":false", lines[1]);
    }
}

For debugging, I keep a simple launch.json so hitting F5 under CoreCLR does the right thing, with symbols ready and just-my-code enabled.

// .vscode/launch.json (excerpt)
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": ".NET Launch",
      "type": "coreclr",
      "request": "launch",
      "program": "${workspaceFolder}/bin/Debug/net9.0/YourApp.dll",
      "cwd": "${workspaceFolder}",
      "console": "integratedTerminal",
      "justMyCode": true
    }
  ]
}

I also let Copilot draft analyzers and ruleset updates when a pattern repeats in reviews; it won’t replace human judgment, but it saves me from rewriting the same diagnostic boilerplate.

Rust

Rust is where I go when I want sharp edges and strong guarantees. I still keep I/O injectable and avoid panics for expected errors. Copilot is good at filling out the pattern once I’ve defined the types and the contract.

# Cargo.toml (excerpt)
[package]
name = "csv_ndjson"
version = "0.1.0"
edition = "2021"

[dependencies]
csv = "1"
serde = { version = "1", features = ["derive"] }
serde_json = "1"
thiserror = "1"

// src/main.rs
use csv::StringRecord;
use serde::Serialize;
use std::{fs::File, io::Write, path::PathBuf};
use thiserror::Error;

#[derive(Debug, Error)]
enum AppError {
    #[error("io: {0}")]
    Io(#[from] std::io::Error),
    #[error("csv: {0}")]
    Csv(#[from] csv::Error),
    #[error("invalid row: {0}")]
    Invalid(String),
}

#[derive(Serialize, Debug)]
struct OutRow {
    id: String,
    amount_cents: u64,
    currency: String,
    is_high_value: bool,
}

fn map_record(rec: &StringRecord, threshold: u64) -> Result<OutRow, AppError> {
    let id = rec.get(0).ok_or_else(|| AppError::Invalid("missing id".into()))?;
    let amount_str = rec.get(1).ok_or_else(|| AppError::Invalid("missing amount".into()))?;
    let currency = rec.get(2).ok_or_else(|| AppError::Invalid("missing currency".into()))?;

    let amount_cents: u64 = amount_str.parse().map_err(|_| AppError::Invalid("bad amount".into()))?;
    Ok(OutRow {
        id: id.to_string(),
        amount_cents,
        currency: currency.to_string(),
        is_high_value: amount_cents >= threshold,
    })
}

fn run(input: PathBuf, output: PathBuf, threshold: u64) -> Result<(), AppError> {
    let mut rdr = csv::Reader::from_path(input)?;
    let mut out = File::create(output)?;

    for result in rdr.records() {
        let rec = result?;
        let row = map_record(&rec, threshold)?;
        // let json = serde_json::to_string(&row).expect("serialize");
        let json = serde_json::to_string(&row)?;
        writeln!(out, "{json}")?;
    }
    Ok(())
}

fn main() -> Result<(), AppError> {
    // hardcode paths for brevity; wire clap/argp in real life
    run("input.csv".into(), "out.json".into(), 50_000)
}

And the test that keeps me honest lives right next to it. Copilot will generate something close to this once it sees the function signature; I always tighten the assertions and add failure cases.

// src/lib.rs (optional if you split logic for testing)
// tests/transform.rs
#[cfg(test)]
mod tests {
    use super::*;
    use std::io::Write;
    use tempfile::NamedTempFile;

    #[test]
    fn flags_high_value_correctly() {
        let mut csv = NamedTempFile::new().unwrap();
        writeln!(csv, "id,amount,currency").unwrap();
        writeln!(csv, "A,50000,EUR").unwrap();
        writeln!(csv, "B,49999,USD").unwrap();

        let out = NamedTempFile::new().unwrap();

        run(csv.path().into(), out.path().into(), 50_000).unwrap();

        let content = std::fs::read_to_string(out.path()).unwrap();
        let lines: Vec<_> = content.lines().collect();
        assert!(lines[0].contains("\"is_high_value\":true"));
        assert!(lines[1].contains("\"is_high_value\":false"));
    }
}

For stepping through Rust, CodeLLDB in VS Code remains my default. I keep a launch configuration that points at the produced binary so I don’t think about paths while I’m thinking about state.

// .vscode/launch.json (rust excerpt)
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug Rust binary",
      "type": "lldb",
      "request": "launch",
      "program": "${workspaceFolder}/target/debug/csv_ndjson",
      "args": [],
      "cwd": "${workspaceFolder}"
    }
  ]
}

Zig

Zig is refreshing when I want predictable performance and explicit control. Copilot is still helpful for the scaffolding, but I rely on the standard library for the important parts and keep errors explicit.

// src/main.zig
const std = @import("std");

pub fn main() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();
    const allocator = gpa.allocator();

    var args = std.process.args();
    _ = try args.next(); // program name
    const in_path = args.next() orelse "input.csv";
    const out_path = args.next() orelse "out.json";

    const threshold: u64 = 50_000;

    var infile = try std.fs.cwd().openFile(in_path, .{ .read = true });
    defer infile.close();
    var outfile = try std.fs.cwd().createFile(out_path, .{ .write = true, .truncate = true });
    defer outfile.close();

    var br = std.io.bufferedReader(infile.reader());
    var in_stream = br.reader();

    var line_buf = std.ArrayList(u8).init(allocator);
    defer line_buf.deinit();

    // read header
    _ = try readLineAlloc(in_stream, &line_buf);

    while (try readLineAlloc(in_stream, &line_buf)) |line| {
        var it = std.mem.split(u8, line, ",");
        const id = it.next() orelse continue;
        const amount_s = it.next() orelse continue;
        const currency = it.next() orelse continue;

        const amount = try std.fmt.parseInt(u64, amount_s, 10);
        const is_high = amount >= threshold;

        try outfile.writer().print(
            "{{\"id\":\"{s}\",\"amountCents\":{d},\"currency\":\"{s}\",\"isHighValue\":{s}}}\n",
            .{ id, amount, currency, if (is_high) "true" else "false" },
        );
    }
}

fn readLineAlloc(reader: anytype, buf: *std.ArrayList(u8)) !?[]u8 {
    buf.clearRetainingCapacity();
    var stream = reader;
    const nl: u8 = '\n';

    while (true) {
        var byte: [1]u8 = undefined;
        const n = try stream.read(byte[0..]);
        if (n == 0) break;
        if (byte[0] == nl) break;
        try buf.append(byte[0]);
    }
    if (buf.items.len == 0) return null;
    return buf.items;
}

Zig’s test blocks live right next to the code. I’ll often write a tiny line-split test to pin behavior before letting Copilot fill the pattern everywhere else.

test "parse int safely" {
    const parsed = try std.fmt.parseInt(u64, "50000", 10);
    try std.testing.expectEqual(@as(u64, 50000), parsed);
}

Debugging with AI in the loop

Debugging is where the integration matters most. I run tests or start the program under the debugger, capture the failing stack trace, and paste it into Copilot Chat with a request to explain what happened and propose a minimal fix that avoids changing public APIs. Because the code and errors are already open in the editor, the back-and-forth stays grounded. Conditional breakpoints and logpoints are my default because they don’t require code changes, and I keep a handful of watch expressions to track the objects that tend to go sideways. In .NET, I keep symbol loading fast and source link enabled; in Rust and Zig, I let CodeLLDB or the C/C++ debugger step through optimized builds when I’m chasing heisenbugs.

Exercising APIs and wiring CI

I like having an api.http file that hits real endpoints during development. It doubles as documentation you can execute, and Copilot is surprisingly good at filling in token flows and error cases once it sees the pattern. On the CI side, I let Copilot draft a minimal pipeline—dotnet test with caches for NuGet, cargo test with a sensible Rust toolchain matrix, and a simple Zig build—then I tune it to fit the project’s real constraints. The speed-up is not in writing YAML I could write myself; it’s in not context-switching away from the code that actually matters.

Pull requests, reviews, and change management

A good pull request is a story with a beginning, middle, and end. Inside VS Code, I use the GitHub Pull Requests extension to live inside that story, and I ask Copilot to help with the narrative parts. It will summarize a diff, call out potential risks, and suggest missing tests; it will also draft a conventional commit message with a “Why” section that I can edit down to the truth. The point isn’t to outsource judgment. It’s to spend judgment on design and correctness instead of on verb forms and checklists.

Closing thoughts

VS Code without Copilot is a great editor. VS Code with Copilot is, for me, a force multiplier that shortens the path between intention and impact. The magic isn’t that it “writes code for you.” The magic is that the editor becomes a place where you can describe what you mean in the language of your project, and the ceremony melts away. If you try this stack, start small: pick a real task, state your intent as precisely as you can, and let the assistant draft the parts that don’t deserve creative energy. Keep the parts that do.

Imagine this: you work at a company, and you have a clear idea for a web app, something like a custom expense tracking tool that fits exactly the way your team works. You’ve tried off-the-shelf products, but they always miss the mark. The alternative, building your own application, is usually time-consuming, expensive, and requires getting developers involved early on. But what if you could prototype your idea, adjust the UI, change the data model, and publish it, all without writing a single line of code?

That’s exactly what GitHub Spark makes possible

What is GitHub Spark

GitHub Spark is a new tool in the GitHub Copilot ecosystem, designed for anyone who wants to bring software ideas to life without being a developer. It leverages AI to translate natural language descriptions, yes, just plain text, into a fully functional web application. You describe what you want, and Spark generates the user interface, the data layer, and even deployment instructions. It doesn’t just simulate an app, it builds it.

Describe Your Idea in Plain Text

The process is surprisingly intuitive. You open GitHub Spark and simply write what you want the app to do: “I want an expense tracker with categories, approval flows, and a dashboard for summaries.” Within minutes, Spark will scaffold your application, including forms, tables, styling, and storage. You’ll see it running right away. This is not a fake mockup, this is a live prototype. And if something isn’t quite right? Just type what you want to change. “Make the buttons blue.” “Add a notes field to each expense.” “Group the expenses by project.” Spark listens, understands, and adapts in real time.

Customize Everything Visually

It’s not only functional, it’s visual. You can fine-tune the app’s look and feel without design tools or CSS. Change the typography, update the color palette, adjust the border radius. Want to change how the app stores or displays data? That’s editable too. The whole experience feels like talking to a smart assistant who just happens to be a front-end dev, a back-end dev, and a designer rolled into one.

Speed and Accessibility for All Creators

At its core, GitHub Spark is about speed and accessibility. For non-technical creators, this is an incredibly powerful way to test ideas, validate concepts, or even deploy simple tools that are good enough to use right away. And for technical teams, it’s a great way to get ahead, kickstarting the UI or getting a working data schema in place before engineering resources are allocated.

Developers?

GitHub Spark isn’t going to replace skilled developers for complex enterprise-grade systems. It’s not meant to. But what is impressive is how quickly and accurately it lets you build a real, working prototype. You don’t just explain the idea, you see it, use it, and iterate on it. That alone makes it one of the most interesting AI-powered tools GitHub has launched since Copilot.

Ready to Try Spark?

If you’re curious, Spark is now available in public preview, and you can read more about it on GitHub’s official documentation. But the best way to understand Spark is to try it. Think of an idea you’ve had for a while, open Spark, and just start describing it.

You’ll be surprised how fast you can go from “I wish I had an app for this…” to “Here’s the link to the expense app, try it out.”.

AI is no longer an abstract promise of the future. It’s here, embedded into enterprise workflows, products, and decision-making processes. From Microsoft Copilot to ChatGPT and domain-specific assistants, businesses are adopting AI at an unprecedented pace. But too often, “AI” is used as a catch-all term for a wide range of technologies. To lead the next transformation wave, organizations must move beyond generic AI adoption and toward agentic AI, a more autonomous, goal-driven form of AI that’s ready to take on real work.

Agentic AI brings intelligence into action. It refers to AI systems that don’t just respond, they act! These systems exhibit goal-directed behavior, operate autonomously, make decisions, use tools, and apply reasoning and planning across time and tasks. In essence, an AI Agent is a digital co-worker, one that doesn’t need micromanagement, doesn’t take lunch breaks, and adapts to dynamic environments with memory and purpose.

This evolution is more than hype. It’s the operational shift from static machine learning models to AI-driven workflows that reason, remember, and execute.

What Is an AI Agent, Technically?

At its core, an AI Agent is a form of intelligent orchestrator. Unlike traditional automation scripts or rule-based bots, an AI Agent is built with modular cognitive capabilities. It uses a Large Language Model (LLM), or for more resource-efficient use cases, a Small Language Model (SLM), as its reasoning engine. This ‘brain’ is surrounded by memory (both short-term and long-term), a set of tools (think APIs, databases, services), and a controller that manages objectives, context, and planning.

In this architecture, the agent receives a goal or task, either via human input, another system, or even another agent and autonomously decides how to accomplish it. That includes invoking tools through Model Context Protocol (MCP) servers, storing and retrieving information from (vector) databases, interacting with external APIs, and even collaborating with other AI Agents in what’s known as Agent-to-Agent (A2A) workflows.

This level of autonomy is not trivial. It requires careful design choices: prompt engineering, tool chaining, vector search optimization, and guardrails to ensure safety, compliance, and operational efficiency. These agents are not “one prompt away” systems, they are designed, configured, and iterated like software components. And yes, there are platforms that let non-technical users describe what they want and auto-generate a lightweight AI agent. But in my experience leading enterprise-scale transformations, these tools rarely deliver the robustness, observability, and cost-efficiency needed for production-grade systems.

Agentic AI in Action

Let’s leave the abstract and dive into a real-world example: logistics (knowing me this should be not a surprise). Suppose you run a mid-sized delivery company with hundreds of daily shipments, multiple depots, and a fleet of trucks and drivers. Every evening, your dispatch team prepares the next day’s delivery plan; routes, assignments, departure times. It’s a repetitive, constraint-heavy problem. Now imagine replacing or augmenting that function with an AI Agent.

The AI Agent wakes up every evening with one objective: generate the most cost-efficient, constraint-satisfying delivery plan. It pulls data from internal systems: driver availability, vehicle health, customer delivery windows, and package locations. It uses tools like Azure Maps and NVIDIA cuOpt to optimize routing based on real-time traffic, road conditions, and fuel efficiency. It then notifies customers of expected delivery times, and if something changes, driver calls in sick, a truck breaks down, or a high-priority shipment arrives late, it recalculates and adapts without needing manual intervention.

This isn’t just about automation. It’s autonomy. It’s a system that understands goals, reasons about alternatives, and executes actions independently. And the impact? Reduced operational overhead, improved delivery SLAs, and real-time resilience. That’s the promise of agentic AI and it’s already happening.

Behind the Scenes

Memory is the difference between a chatbot and a cognitive agent. Without memory, an AI system is like a goldfish, it forgets everything after each prompt. To build agents that can handle dynamic workflows, context shifts, and strategic planning, we must give them memory, both episodic (short-term) and semantic (long-term).

This is where vector databases become critical. Unlike traditional databases, vector stores allow semantic retrieval. Text, images, code, or other high-dimensional data are encoded into vector embeddings, which can then be queried by similarity. In AI agents, this enables contextual recall: “What happened in the last planning session?”, “What did the customer ask three days ago?”, or “What were the top-performing routes last month?”

Even more importantly, vector databases allow grounding LLMs with external knowledge. One of the biggest weaknesses of LLMs is their tendency to hallucinate or forget facts. By querying a vector store and injecting relevant context into the prompt, agents can generate responses that are both accurate and relevant to the domain. This approach, often called Retrieval-Augmented Generation (RAG), is essential for enterprise reliability.

What this means for the Enterprise

Agentic AI is not a lab experiment. It’s a production-ready pattern that can improve cost-efficiency, accelerate decision-making, and unlock new capabilities across industries, from logistics and supply chain to customer service, healthcare, and compliance.

But building effective AI Agents is not just a matter of plugging an LLM into a workflow. It requires experience in systems design, cloud architecture, vector semantics, tool integration, and AI safety. As someone who has worked across both Microsoft’s Azure Maps platform and real-world customer implementations, I’ve seen firsthand what works and what doesn’t. AI Agents and agentic AI are not just buzzwords. They are the future of enterprise intelligence.

In today’s AI era, you’ve likely interacted with Microsoft Copilot, ChatGPT, or Claude.ai, tools powered by advanced Large Language Models (LLMs). These models excel at understanding and generating human-like text based on vast amounts of training data. However, while LLMs are impressive at reasoning and answering general questions, they fall short when it comes to performing real-world tasks or retrieving live, domain-specific information.

This is where the Model Context Protocol (MCP) comes in.

MCP extends the capabilities of LLMs by connecting them to structured, real-time, and authoritative data sources, essentially giving them access to tools and APIs that can “do things” instead of just “talk about things.” One compelling use case is enriching LLMs with geospatial intelligence by integrating Azure Maps into an MCP server.

Let’s consider a practical example, you ask Copilot:

“Which neighborhood does this address Kerkstraat 10, Amsterdam belongs to?”

Out-of-the-box, the model may not know the answer. At best, it might offer a hallucinated guess based on its training data, which is often outdated or incomplete for such hyper-local questions.

By integrating Azure Maps into an MCP server, you empower the LLM to perform (reverse) geocoding to get address details, Identify neighborhoods, postal codes, or administrative regions, visualize or reason about spatial data like routes, boundaries, or real-time traffic details.

With an MCP server acting as a bridge between the LLM and Azure Maps, the process looks like this:

1. User Query: The user (or AI agent) asks a geographically relevant question.
2. MCP Routing: The MCP server receives the query and routes it to a plugin/tool backed by Azure Maps APIs.
3. Azure Maps Execution: The server makes the API call (e.g., reverse geocoding, route calculation, etc).
4. LLM Response Generation: The MCP server returns structured results to the LLM, which incorporates it into a coherent and accurate response.

Integrating Azure Maps into an MCP server is surprisingly straightforward, especially when using .NET and Azure Functions. In this blog, I’ll walk you through the core setup to expose Azure Maps as a tool to an LLM via MCP.

While implementing a Model Context Protocol (MCP) server normally requires strict adherence to the MCP protocol specifications, Microsoft has made it much easier by providing a prebuilt extension: Microsoft.Azure.Functions.Worker.Extensions.Mcp. This NuGet package abstracts away most of the boilerplate, so you can focus on defining the tools you want to expose and simply wire them to Azure Maps APIs. We’ll start by creating a standard Azure Functions project using Visual Studio or Visual Studio Code.

Step 1: Set Up the Project

Create a new Azure Functions project targeting .NET 9 or newer and add the following NuGet package:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp

Step 2: Configure MCP

Here’s a sample Program.cs that sets up the MCP tool metadata and registers an HttpClient for making requests to Azure Maps:

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();
builder.EnableMcpToolMetadata(); // Enables tool registration metadata
builder.ConfigureMcpTool("Azure Maps Tool"); // Register the tool name exposed to LLMs

builder.Services
    .AddHttpClient("AzureMaps") // Named http client for Azure Maps
    .AddStandardResilienceHandler(); // Optional: adds resilience policies

builder.Build().Run();

Step 3: Implement an MCP Tool

Let’s expose one function for this example: geocoding a location (i.e., converting an address or landmark into geographic coordinates) using Azure Maps.

Here’s the function code:

public class AzureMapsTools(IHttpClientFactory httpClientFactory, IConfiguration configuration)
{
    [Function(nameof(GeocodeLocation))]
    public async Task<string> GeocodeLocation(
        // This attribute registers the function as an MCP tool trigger.
        // The name and description help users understand what the tool does.
        [McpToolTrigger(
            "geocode_location",
            "Geocode a location, such as an address or landmark name using Azure Maps")] ToolInvocationContext context,
        [McpToolProperty(
            "location",
            "string",
            "address or landmark name")] string location 
    )
    {
        // Get the Azure Maps subscription key from configuration.
        // This key is needed to authenticate requests to the Azure Maps API.
        // If the key is missing, throw an error to alert the developer.
        var subscriptionKey = configuration["AZURE_MAPS_SUBSCRIPTION_KEY"] 
            ?? throw new InvalidOperationException("Azure Maps subscription key not configured");

        // Build the URL for the Azure Maps geocoding API.
        // The query parameter contains the location, and the subscription key authenticates the request.
        var url = $"https://atlas.microsoft.com/geocode?api-version=2025-01-01&query={Uri.EscapeDataString(location)}&subscription-key={subscriptionKey}";

        // Create an HTTP client to send the request.
        using var httpClient = httpClientFactory.CreateClient("AzureMaps");

        // Send the GET request to the Azure Maps API.
        var response = await httpClient.GetAsync(url);

        // Check if the response was successful.
        // If not, read the error message and throw an exception.
        if (!response.IsSuccessStatusCode)
        {
            var error = await response.Content.ReadAsStringAsync();
            throw new HttpRequestException($"Azure Maps API failed with status {response.StatusCode}: {error}");
        }

        // Read the result from the response as a string (JSON format).
        var result = await response.Content.ReadAsStringAsync();

        // Return the geocoding result to the caller.
        return result;
    }
}

The function returns the full Azure Maps response in JSON format, which can then be parsed or summarized by the LLM in its reply.

By combining the real-time spatial intelligence of Azure Maps with the reasoning capabilities of large language models, you move beyond passive AI into the realm of actionable AI agents, where systems not only understand queries but execute real-world tasks in response.

You can easily add more tools such as reverse geocoding, route calculation, POI search, or even time zone conversion, all backed by the same MCP server architecture.

The logistics industry constantly seeks efficiency in routing vehicles to deliver goods. This is where the Vehicle Routing Problem (VRP) and Pickup and Delivery Problems (PDP) come into the picture as both are sophisticated extensions of the classic Traveling Salesperson Problem (TSP). The TSP poses a simple yet challenging question: “What is the most efficient route that visits each destination once and returns to the starting point?” This problem is not just academic; it has practical applications in logistics, where optimizing routes can lead to substantial savings in time and costs.

So, what is needed to tackle this problem? At its simplest incarnation, you need reliable inputs that provide estimates as to how long each route to a location will take and then you need to know how to apply the rest of the constraints like driver availability, time taken at each location, opening hours, working hours, demand, capacity and more. In the solution we will review here, Azure Maps provides the input and NVIDIA cuOpt will apply the constraints for optimization.

The Flexibility of Azure Maps

Azure Maps offers, besides mapping, also an advanced routing engine, tailored for both cars and commercial trucks, complete with a Route Matrix API and traffic and accident APIs what are part of the routing engine as well. Learn here more about what Azure Maps can do for you.

The Power of NVIDIA cuOpt

Enter NVIDIA cuOpt, a state-of-the-art, GPU-accelerated engine designed for tackling complex routing challenges. It leverages parallel heuristics to accelerate solutions to VRP, PDP, and other related optimization problems. NVIDIA cuOpt is versatile, accommodating various constraints such as vehicle capacities, delivery time windows, and even the intricacies of drivers’ shifts and breaks.

Solving TSP with Azure Maps and NVIDIA cuOpt

Imagine you’re tasked with coordinating package deliveries from multiple depots, utilizing a fleet of vehicles with varying capacities, to a diverse set of customers with unique requirements. Azure Maps and NVIDIA cuOpt emerge as your allies in this complex scenario.

Preparation: Gathering Essential Data

Before you begin with route optimization, you’ll need to collect some fundamental data:

• Depot Locations: Where your journey begins.
• Customer Drop-off Locations: Including details like opening hours and dwell time.
• Vehicle Specifications: Capacity, starting, and ending locations.
• Driver Details: Working hours, breaks, vehicle assignments, and costs.

Step One: Constructing a Cost and Travel Time Matrix

Using Azure Maps Matrix APIs, you can calculate a comprehensive matrix that outlines the ‘cost’ in meters and travel time in seconds between every depot and drop-off location. For instance, with two depots and eight drop-off points, you’d create a 10x10 matrix. Each location serves as both an origin and a destination, resulting in a matrix where the distance and time to the same location are zero—since they are, naturally, identical.

We have developed a Multi-Itinerary Optimization Sample to get you started quickly, the core of this sample is this function:

// Itinerary Optimization function
async function itineraryOptimizationClicked() {

    // Show loading icon
    showLoadingIcon(true);

    // Clear the route data source
    routeDataSource.clear();

    // We need all coordinates together depots + stops
    const allCoordinates = [...depots, ...stops];

    // Get the Azure Maps Matrix results for all coordinates
    const matrix = await getMatrixAsync(allCoordinates);

    // We use the NVIDIA cuOpt optimizer service to calculate the Multi-Itinerary Optimization
    const solver = await getOptimizedRouteAsync(matrix);

    // Render the route on the map for each vehicle using Azure Maps Route API
    renderRoutes(allCoordinates, solver);

    // Hide loading icon
    showLoadingIcon(false);
}

The complete Multi-Itinerary Optimization Sample source code can be found on the Azure Maps Code Samples GitHub page.

Step Two: Determining the Optimal Delivery Sequence

With the matrix data in hand, it’s time to decide the delivery sequence. This is where NVIDIA cuOpt shines, optimizing the order of delivery for each vehicle based on capacity, demand, and operational hours—without needing any sensitive location or customer data, thus addressing privacy concerns.

See our how-to guide how to set up and create a solution with NVIDIA cuOpt and Azure Maps.

Step Three: Real-World Route Mapping

Once NVIDIA cuOpt has determined the optimal delivery order, the final step is to map the actual routes using Azure Maps Routing APIs. This process translates the optimized sequence into actionable routes for each vehicle.

In a hypothetical scenario with four vehicles serving two depots and eight drop-off locations, the outcome might look like this:

Depot 1: Vehicle A -> Stop 1 -> Stop 3 -> Stop 5 -> Depot 1
Depot 1: Vehicle B -> Stop 2 -> Stop 4 -> Stop 6 -> Depot 1
Depot 2: Vehicle C -> Stop 7 -> Stop 8 -> Depot 2
Depot 2: Vehicle D -> Stop 9 -> Stop 10 -> Depot 2

Are you ready to deliver? Get started with the Azure Maps and NVIDIA cuOpt to optimize your delivery needs. Read our how-to guide and start delivering to your customers quicker.

This blog post was initially written by me for the Azure Maps Tech Blog.

We are thrilled to announce the unification of Bing Maps for Enterprise (BME) with Azure Maps, marking a significant milestone in our geospatial services at Microsoft. Azure Maps now boasts a robust stack of geospatial offerings, leveraging the powerful capabilities of Microsoft Maps, which also drives Bing Maps (our consumer maps experience). Over the past year, our team has dedicated significant time and effort to combine the strengths of Bing Maps for Enterprise into Azure Maps, enhancing our global quality and coverage.

One of the major enhancements is the adoption of vector tiles in Azure Maps for a more responsive map experience. When utilizing Azure Maps in your solutions, you not only leverage the security and compliance advantages of Azure but also benefit from the extensive quality and coverage provided by Microsoft Maps.

This unification ensures that users of Azure Maps receive a comprehensive mapping solution backed by the unparalleled strengths of Azure’s infrastructure, Microsoft Maps’ data quality and coverage, and many of the same advanced geospatial capabilities that Bing Maps for Enterprise customers depend on. We are excited about the opportunities this integration presents and look forward to continuing to deliver innovative mapping solutions to our customers worldwide.

Azure Maps has many of the same features that BME customers have come to rely on. Nevertheless, this unification also introduces exciting new features to Azure Maps, such as weather APIs, private indoor maps, multiple authentication methods, geolocation service, and robust privacy and compliance benefits.

Ready to Make the Move?

For customers that are using Bing Maps for Enterprise and are migrating over to Azure Maps, some development will be needed. To help you in this transition period, we have written migration documents for our REST APIs and as well for the Azure Maps web control. Also, a good start is our Azure Maps samples site where you can find not only samples for many scenarios, but also the source code.

More resources about Azure Maps can be found here:

• Azure Maps Documenation
• Azure Maps Samples
• Azure Maps Blog
• Microsoft Q&A for Azure Maps

Have you ever wondered what it’s like to be a Program Manager (PM) at Microsoft? As someone who often fields this question, I’d like to offer some insights into the fascinating world of product development and customer-centric decision-making that defines the role of a PM at one of the world’s leading tech companies.

At Microsoft, our mission revolves around creating products and services that address real-world needs and deliver tangible value to our users. As a Program Manager, my primary responsibility is to delve into the evolving landscape of customer demands and technological advancements to identify opportunities for enhancing our products.

One of the key aspects of the PM role is conducting thorough research to understand what new features or improvements customers are seeking. This involves not only listening to direct customer feedback but also analyzing market trends and competitive landscapes. While it’s essential to prioritize features that align with customer needs, we also need to consider the business impact and feasibility of each enhancement.

It’s not just about fulfilling every customer request; it’s about strategically investing our resources where they will have the most significant impact. This means evaluating the potential financial returns of a feature against the cost of development and deployment. If a proposed feature only caters to a small subset of users, we need to assess whether it aligns with our broader strategic goals and market positioning.

Collaboration is at the heart of everything we do at Microsoft. As a PM, I work closely with Product Marketing Managers (PMMs) to ensure that our product roadmap aligns with market demand and consumer behavior. Customer studies and meetings play a crucial role in gathering insights into the challenges users face and the solutions they’re seeking.

Once a feature has been conceptualized and scoped, it’s time to hand it over to the Product Manager for inclusion in the product roadmap. This collaborative effort involves engaging with engineering teams to ensure that the proposed features are technically feasible and align with the overall product vision.

On a typical day, I engage in frequent meetings with my fellow PMs to discuss ongoing projects and align our strategies. Cross-team collaboration is essential, especially in complex product ecosystems like Azure Maps, where integration with other Microsoft products is commonplace.

Being a Program Manager at Microsoft is both challenging and rewarding. It requires a blend of technical expertise, strategic thinking, and a deep understanding of customer needs. By constantly iterating on our products and embracing a customer-centric approach, we strive to deliver innovative solutions that empower users and drive business growth. If you’re passionate about technology and thrive in a fast-paced, collaborative environment, a career as a Program Manager at Microsoft might be the perfect fit for you.

Maximize Visibility

In today’s digital age, the visibility of your business is paramount. Once you’ve captured customer interest online, the next crucial step is guiding them to your physical storefronts. Azure Maps Store Locator streamlines this journey, offering an interactive and intuitive experience that leads customers right to your doorstep.

Simplifying Store Discovery

Creating a basic store locator using Azure Maps is already a straightforward task, involving the loading of store locations onto a map and potentially setting up a simple search functionality. However, for larger organizations managing thousands of locations and requiring advanced filtering options, a more sophisticated solution is essential. Fortunately, the Azure Maps Store Locator, combining the power of various Azure services, caters precisely to these needs.

Enhance Your Locator Experience

Imagine a tool that effortlessly connects potential customers to the nearest branch of your business, tailored to their specific needs. Whether they’re searching for a particular service or other points of interest, Azure Maps Store Locator is the user-friendly and adaptable tool you need. It’s backed by a comprehensive management system, enabling you to create a rich locator experience.

Feature-Rich Platform

Azure Maps Store Locator boasts a wide array of features to improve your location-based offerings:

• Store Locator Backend: Integrates REST APIs and a Store Locator Web Control for seamless management.
• Autocomplete Search: Quickly find store names, addresses, POIs, or zip codes.
• Scalability: Manages over 10,000 locations without a hitch.
• Proximity Insights: View nearby stores and distance metrics.
• Location-Based Search: Searches can be performed based on the user’s current location.
• Travel Time Estimates: Provides estimated travel times for various modes of transport.
• Comprehensive Store Details: Access store information, directions, and more through interactive popups.
• Dynamic Filtering: Users can filter stores based on specific features.
• Individual Store Pages: Delve into what each store offers with detailed embedded maps.
• Security: Employs Microsoft Entra ID for secure access to the location management system.
• Rich Data: Store details include location, hours, photos, and the option to add custom features.
• Accessibility: Features speech recognition and other accessibility enhancements.
• Effortless Deployment: Easily deploy within your Azure ecosystem.

Quick Setup Guide

Deploying Azure Maps Store Locator is straightforward:

1. Azure Subscription: Confirm you have an Azure subscription. If not, obtain one for free at the official Azure website.
2. Azure Shell Access: Sign in to Azure Shell. https://shell.azure.com/
3. Deployment: Run the provided PowerShell script to install the Azure Maps Store Locator.

iex (iwr "https://samples.azuremaps.com/storelocator/deploy.ps1").Content

Integrating the store locator into your website requires some HTML and JavaScript to call the store locator backend REST APIs. Once implemented, the solution is yours to modify and tailor the source code in your Azure Maps Store Locator according to your specific needs.

The Azure Maps Store Locator empowers you to create and maintain an intuitive location-based search experience to delight your customers. Enhance your online presence today with the power of Azure Maps!

You find the Azure Maps Store Locator source code on GitHub.

We are excited to announce that we have developed a new and improved style for our maps across Microsoft. Azure Maps now utilizes the same vector tiles and satellite imagery directly as our other Microsoft mapping platforms, including our Bing Maps consumer site and more. This updated style introduces a fresh cartographic identity across Microsoft, focusing on enhancing usability, information clarity, and aesthetic appeal.

Key Features of the New Style

1. Style Choices: As before, Azure Maps allows you and your customers to choose from several styles, such as:
   • Road
   • Night
   • Hybrid
   • Grayscale (dark and light)
   • Terra
   • High Contrast (dark and light)

2. Fine-Tuned Colors and Information Density: We have carefully considered feedback from our previous styles. The result is a balance of colors and information density designed to make our maps more easily consumable across different zoom levels and device profiles.

3. Transport Features: We’ve introduced transport features with hairline rendering. These features provide more context and information without compromising readability.

4. Greener Base Map Colors: Our base map colors now support biomes and landcover classes, including subtle yet functional terrain shading rendered with ambient occlusion.

5. Improved Label Density: With this update, we have significantly improved label density. You’ll find an even and consistent level of detail across various zoom levels and geographies.

6. Clear Hierarchy of Types: We’ve defined a clear hierarchy for labels, making it easy to distinguish between:

   • Transport and infrastructure labels
   • Administrative districts
   • Natural features

7. Expanded Coverage: Thanks to our partners, the Microsoft mapping platform now combines and enhances data from various sources. As a result, we’ve expanded our coverage in China, Japan, and Korea.

8. Additional Enhancements:
   • Road Details
   • Building Footprints
   • Hiking Trail Coverage
   • Wider Zoom Level Ranges for the Terra style
   • More Transit Types and Information (e.g., ferry stops, metro stops, bus stops)
   • Additional details about mountains, altitude, and waterfall locations

Exploring the New Style

If you want to explore the new style, visit our Azure Maps Samples or try out the Azure Maps Demo site.

Developers can also use the Azure Maps V3 Web Control in there applications by utilizing our CDN endpoint or the NPM package.

<link rel="stylesheet" href="https://atlas.microsoft.com/sdk/javascript/mapcontrol/3/atlas.min.css" type="text/css" />
<script src="https://atlas.microsoft.com/sdk/javascript/mapcontrol/3/atlas.min.js"></script>

Azure Maps Creator is a powerful product that transforms your static floor plans into dynamic, interactive indoor maps for your business locations. It allows you to overlay technical building plans ontop of Azure Maps, enabling the visualization of IoT data such as temperature, occupancy, and other location-based services. The onboarding process is streamlined, requiring only the preparation and uploading of your DWG floorplan files (the native file format for Autodesk’s AutoCAD software) into Azure Maps Creator.

Important: As of 2024, Azure Maps Creator has been deprecated and is no longer available. Microsoft has discontinued this service. If you’re looking for indoor mapping solutions, please refer to the Azure Maps documentation for current alternatives and migration guidance.

Onboarding simplified

The Azure Maps Creator onboarding tool has been designed to make the process of integrating DWG floorplans straightforward. With the simplified drawing package requirements, the tool facilitates the development of indoor maps without the need for expensive third-party services or the risk of exposing sensitive data. The onboarding steps are clearly outlined in the documentation.

Steps to onboard your indoor map

1. Assign each DWG file to a facility level: This step organizes the levels within your facility, enabling seamless floor transitions and wayfinding capabilities in your indoor map.
2. Map DWG layers that will be converted: Identify and map the DWG file layers that will be transformed into indoor map features, such as furniture or infrastructure components.
3. Position Your Facility on the Map: Place your indoor map accurately over a base map to ensure proper visualization and alignment.

After these steps, you’ll have a drawing package ready for Azure Maps Creator. The final action is to upload this package, which will then allow you to utilize your custom indoor map.

Azure Maps Creator

The simplified drawing package requirements and Azure Maps Creator onboarding tool are some of the many helpful additions we have made to Azure Maps Creator to offer an even better experience for our customers. It enables the transformation of static building floorplans into interactive experiences and smart spaces to enhance productivity, efficiency, and comfort. We are using it ourselves How Microsoft uses Azure Maps Creator and are excited to share this technology with you to see how you will use it for indoor mapping scenarios.

In the evolving landscape of remote work and sustainability, the optimization of physical spaces has become increasingly important. Microsoft is at the forefront of this transformation, utilizing Azure Maps Creator to enhance the management of its diverse global workspaces. This product is essential for facilities managers, providing dynamic, interactive indoor mapping solutions that allow for real-time assessment of space and resources, quick response to critical issues, and seamless adaptation to the needs of a hybrid workforce—all while minimizing environmental impact.

Important: As of 2024, Azure Maps Creator has been deprecated and is no longer available. Microsoft has discontinued this service. If you’re looking for indoor mapping solutions, please refer to the Azure Maps documentation for current alternatives and migration guidance.

Azure Maps Creator is not just a product for efficient space management; it’s a showcase of Microsoft’s commitment to creating exceptional experiences for employees, customers, and partners visiting its buildings. By integrating IoT sensors throughout its facilities, Microsoft can monitor various environmental parameters such as temperature, energy consumption, and occupancy levels. This data, coupled with the capabilities of Azure Digital Twins and Azure Maps, empowers the Digital Workplace team to construct detailed floorplans and data pipelines that support sustainable operations and superior indoor navigation.

Imagine a hybrid employee contemplating their commute to the office. With Azure Maps Creator, they can evaluate whether to attend a meeting in person or remotely via Microsoft Teams, consider the environmental and time implications of different travel options, and even check parking availability. This decision-making process is part of what Microsoft refers to as the “Green Commute” initiative, which aims to identify the most efficient commuting method in terms of both time and energy.

Upon arrival at a Microsoft facility, employees are greeted by kiosks equipped with Azure Maps Creator’s interactive maps. These maps not only display detailed floor plans but also provide navigational guidance to meeting locations, individuals, or specific areas within the building. For the health-conscious, the maps can suggest stair routes as an alternative to elevators. And for those unexpected meetings, this experinace enables the instant search and reservation of available meeting rooms, accessible via the kiosk or a mobile device.

The integration of Azure Maps Creator into Microsoft’s kiosks exemplifies the company’s innovative approach to enhancing the workplace experience. It transforms technical building plans into smart, adaptable overlays that offer a wealth of interior data visualization options. To learn more about Azure Maps Creator and its comprehensive capabilities, be sure to explore the Azure Maps Blog.

Introduction

In today’s energy and climate crisis, prices for energy such as natural gas for heating and electricity have risen significantly in recent years, with prices at least two to three times higher than in past decades. This is particularly true in Europe, where affordable natural gas from Russia is currently not available. The price of electricity is also closely linked to the price of natural gas, so even when clean electricity is generated through wind, solar, and nuclear power, the price is still higher than what we are used to. This is due to the demand for and availability of electricity, which is typically high during the day and in the evening, but low during nighttime. When there is no wind or sun, electricity is generated by gas, coal, and lignite power plants, which is harmful to the environment. The mix of energy and the linked gas price drives up our energy bills.

The demand for energy is increasing worldwide as countries and markets modernize and raise their standard of living. As a result, it is unlikely that energy prices will return to their previous lows. However, there are ways for consumers to reduce their energy bills.

Dynamic Pricing

In the past, most people in the Netherlands had fixed energy contracts for one or more years, with a fixed monthly price. New energy contracts still use this model, but there is little incentive to save or reduce consumption and habits when demand is high. However, dynamic pricing in combination with home or block storage of electricity in batteries can make a big difference. By storing electricity when it is cheap (typically during the night) and using it during the day, you can save money without changing your habits.

Home Battery Storage

For example, I have a dynamic energy contract (ANWB) where the price of electricity changes every hour. I also have a home battery, a Tesla Powerwall 2, with a capacity of 13.5 KWh (read here more details about my setup). I charge the battery automatically between 1am and 5am in the night when the price for electricity is almost free and sell my solar electricity during the day when the price is high. This has resulted in a very low energy bill for me.

Even if you do not have solar panels, a combination of a dynamic energy contract and a home battery can make a big difference in your energy bill. Home batteries are becoming more affordable each year, and in a normal setup, you can earn back your investment in just under two years with current energy prices.

While Azure Maps is known for great use cases around visualizing and interacting with a map and location data, you probably also need secure and reliable storage for that data that offers the flexibility to query your (location) data. In this blog post, we explore the different options for storing and querying geospatial data in Azure, including Azure Cosmos DB, Azure SQL Database, and Azure Blob Storage. Storing and querying geospatial data in Azure is a powerful and flexible way to manage and analyze large sets of geographic information.

Azure Cosmos DB

Azure Cosmos DB is a globally distributed, multi-model database that supports document, key-value, graph, and column-family data models. One of the key features of Cosmos DB is its support for geospatial data, which allows you to store and query data in the form of points, lines, and polygons. Cosmos DB also supports spatial indexing and advanced querying capabilities, making it a great choice for applications that require real-time, low-latency access to geospatial data.

Example query:

SELECT f.id
FROM Families f
WHERE ST_DISTANCE(f.location, {"type": "Point", "coordinates":[31.9, -4.8]}) < 30000

Read here more information about Geospatial and GeoJSON location data in Azure Cosmos DB.

Azure SQL Database

Another option for storing and querying geospatial data in Azure is Azure SQL Database. SQL Database is a fully managed, relational database service that supports the spatial data types and functions of SQL Server. This allows you to store and query geospatial data using standard SQL syntax, and also includes spatial indexing and querying capabilities. SQL Database is a good choice for applications that require a traditional relational database model and support for SQL-based querying.

Read here more information about Spatial Data in Azure SQL Database.

Azure Blob Storage

Azure Blob Storage can be used to store and query large amounts of unstructured data, including geospatial data. Blob Storage allows you to store data in the form of blobs, which can be accessed via a URL. This makes it a great option for storing large files, such as satellite imagery or shapefiles. While Blob Storage does not include built-in support for spatial querying, it can be used in conjunction with other Azure services, such as Azure Data Lake Storage or Azure Databricks, to perform spatial analysis on the data.

In this sample we used satellite imagery that is stored in Azure Blob storage

Geospatial data processing and analytics

To see a sample that pulls Azure Maps and Azure Databases together, see the Microsoft Learn topic Geospatial data processing and analytics. This example scenarios also uses:

• Azure Database for PostgreSQL - a fully managed relational database service that’s based on the community edition of the open-source PostgreSQL database engine.
• PostGIS - an extension for the PostgreSQL database that integrates with GIS servers. PostGIS can run SQL location queries that involve geographic objects.

Conclusion

Azure offers a variety of options for storing and querying geospatial data, including Azure Cosmos DB, Azure SQL Database, and Azure Blob Storage. Each of these services has its own set of features and capabilities, and choosing the right one will depend on the specific needs of your application. Whether you need low-latency access to real-time data, support for traditional SQL-based querying, or the ability to store and analyze large amounts of unstructured data, Azure has the tools you need to get the job done.

Azure Maps is more than just a Map on your website. It is a complete enterprise solution for location-aware solutions. For example, you can do (reverse) geocoding of customer addresses and use an isochrone to find out withs customers a close to your store or get weather conditions for all your past sales data to know withs products sell best by rain or hot weather or get the correct time-zone for your customer by translating an IP-address to a location and get the time-zone information, or you need to know what the travel time is between two or more locations. So many scenarios and use cases you can make location aware with Azure Maps.

You can call the Azure Maps REST APIs directly from any programming language, which is not difficult but always needs extra work. With the introduction of the public preview Azure Maps REST SDKs for C# (.NET), Java, Phyton, and TypeScript (Node.js), you can earlier use the power of Azure Maps in your backend without the hassle of calling the APIs the correct way.

To give you a simple example in C#, we are searching for a Starbucks close to a customer’s location in Seattle. Before we can begin, you need an Azure Maps key; see here how to get a free Azure Maps key.

The following code snippet creates a console program MapsDemo with .NET 8.0. You can use any .NET standard 2.0-compatible version as the framework.

dotnet add package Azure.Maps.Search --prerelease

The following code snippet demonstrates how, in a simple console application, to import the Azure.Maps.Search package and perform a fuzzy search on “Starbucks” near Seattle. In the Program.cs file add the following code:

using Azure; 
using Azure.Core.GeoJson; 
using Azure.Maps.Search; 
using Azure.Maps.Search.Models; 

// Use Azure Maps subscription key authentication 
var credential = new AzureKeyCredential("Azure_Maps_Subscription_key"); 
var client = new MapsSearchClient(credential); 

SearchAddressResult searchResult = client.FuzzySearch( 
    "Starbucks", new FuzzySearchOptions 
    { 
        Coordinates = new GeoPosition(-122.31, 47.61), 
        Language = SearchLanguage.EnglishUsa 
    }); 

// Print the search results 
foreach (var result in searchResult.Results) 
{ 
    Console.WriteLine($""" 
        * {result.PointOfInterest.Name} 
          {result.Address.StreetNumber} {result.Address.StreetName} 
          {result.Address.Municipality} {result.Address.CountryCode} {result.Address.PostalCode} 
          Coordinate: ({result.Position.Latitude:F4}, {result.Position.Longitude:F4}) 
        """); 
} 

In the above code snippet, you create a MapsSearchClient object using your Azure credentials, then use that Search Client’s FuzzySearch method passing in the point of interest (POI) name “Starbucks” and coordinates GeoPosition(-122.31, 47.61). This all gets wrapped up by the SDK and sent to the Azure Maps REST endpoints. When the search results are returned, they’re written out to the screen.

To run your application, go to the project folder and execute dotnet run in PowerShell.

More information you can read in the Azure Maps REST SDK Developer Guide. Happy coding!

Enhancing your Azure Maps with a custom WebGL layer opens up a realm of possibilities for rendering dynamic 2D and 3D data. While Azure Maps provides a robust set of built-in features, there are times when you may require a more tailored solution. This is where the power of a custom WebGL layer shines.

WebGL, a cross-platform and royalty-free web standard, empowers you to harness low-level 3D graphics right in your web browser. By utilizing WebGL, Azure Maps gains a performance edge, surpassing the capabilities of standard HTML canvas rendering. However, it’s important to note that WebGL’s low-level nature adds complexity and may not always align with straightforward business solutions.

To bridge this gap, Azure Maps’ custom WebGL layer can be integrated with leading open-source 3D frameworks such as Babylon.js, Deck.gl, and Three.js. These frameworks simplify the management of 2D and 3D layers, making it more accessible to create high-performance, interactive graphics that come to life in real-time—ideal for simulations, data visualizations, animations, and 3D modeling.

To implement a custom WebGL layer, you’ll utilize the map.layer.add() function, passing in a new WebGLLayer. This layer requires a renderer object, which you’ll define by implementing the WebGLRenderer interface. You can also specify additional options, such as visibility at certain zoom levels:

// Add the layer to the map with layer options.
map.layers.add(new atlas.layer.WebGLLayer("layerId", {
    renderer: myRenderer,
    minZoom: 10,
    maxZoom: 22,
    visible: true
}));

Azure Maps operates on the Spherical Mercator projection (EPSG: 3857), a system that converts the spherical shape of the globe into a 2D map, stretching it at the poles for a square representation. The map’s camera matrix translates these Spherical Mercator coordinates into WebGL coordinates for your custom layer.

3D Frameworks

• Babylon.js: A comprehensive, real-time 3D engine developed by Microsoft, offering a user-friendly framework for game and rendering engine capabilities.
• Deck.gl: A WebGL-powered framework designed for the visual exploratory analysis of large datasets, allowing for the construction of intricate visualizations through layer composition.
• Three.js: A versatile, lightweight 3D library that’s easy to use across different web browsers.

For those eager to dive into developing their custom WebGL layer, extensive documentation is available, along with a plethora of samples showcasing the vast potential of Azure Maps. Explore these resources to kickstart your journey and unlock the full creative power of Azure Maps with custom WebGL layers.

Introduction

One of the requirements when building a business application, which may give access to private business data, is that only authenticated employees or agents be able to see that data. So how can you use Azure Maps in combination with authentication and authorization to ensure only the people that should be allowed have access?

Our Azure Maps docs describe in detail many different authentication scenarios but the complexity can make it seem difficult to implement. This blog post will focus on our most requested authentication scenario for Azure Maps. Use the following step by step guidance to have a .NET web application embedded Azure Maps web control where only authenticated users can see the website and use the map.

🚀 Updated Resources Available! For the latest version of this tutorial with updated code samples, improved best practices, and additional security enhancements, check out the companion GitHub repository: azure-maps-authentication. The repository includes modernized .NET code, enhanced Azure CLI scripts, and additional authentication patterns not covered in this original post.

Prerequisites

In this article, we use the following resources:

• .NET 8.0 and the C# programming language. You can download, and install the latest version of .NET from https://dot.net/
• To make it easier to edit source code, we also recommend installing Visual Studio Code Edition, which is a lightweight but powerful source code editor from Microsoft https://code.visualstudio.com/
• Before you can use Azure Maps, you will need to sign up for a free Azure subscription, at https://azure.microsoft.com/free
• And finally, install the Azure Command-Line Interface (CLI) tools. Read here How to install the Azure CLI.

Step 1. Basic Web Application with Azure Maps

Let’s start with a basic .NET web application and Azure Maps. No authentication yet, that will come in the next paragraph. This first step will use an Azure Maps Key (a ‘shared Key authentication’ or subscription key) that should not be used in production. An Azure Maps Key has complete control over your Azure Maps resource. In the next paragraph, we will remove this key and replace this with managed identities for Azure resources.

Create a folder, we called ours AzureMapsDemo, and add a new web application to it. Then open the newly created web application in Visual Studio Code. Start PowerShell (or any other terminal) and enter the following commands:

mkdir AzureMapsDemo
cd .\AzureMapsDemo
dotnet new mvc
code .

Next, we need to add the Azure Maps web control to the Home view, open the file Views/Home/index.cshtml, and replace all the content with:

@{
    ViewData["Title"] = "Home Page";
}

<div class="text-center">
    <h1 class="display-4">Azure Maps</h1>
    <p>Learn about <a href="https://docs.microsoft.com/azure/azure-maps/">building Azure Maps apps with ASP.NET Core</a>.</p>
</div>

<div id="myMap" style="width:100%;min-width:290px;height:600px;"></div>

@section Scripts
{
    <link rel="stylesheet" href="https://atlas.microsoft.com/sdk/javascript/mapcontrol/3/atlas.min.css" />
    <script src="https://atlas.microsoft.com/sdk/javascript/mapcontrol/3/atlas.min.js"></script>

    <script>
        var map;

        // Initialize a map instance.
        map = new atlas.Map('myMap', {
            center: [-122.33, 47.6],
            zoom: 12,
            style: 'satellite_road_labels',
            view: 'Auto',

            // Add authentication details for connecting to Azure Maps.
            authOptions: {
                authType: 'subscriptionKey',
                subscriptionKey: '[YOUR_AZURE_MAPS_KEY]'
            }
        });

        // Wait until the map resources are ready.
        map.events.add('ready', function() {
            // Add your post map load code here.
        });
    </script>
}

As you can see, we need a subscription key for Azure Maps before starting the web application and using the map. In the next step, we are creating an Azure resource group and adding a new Azure Maps Account. Then we extract the Azure Maps Primary Key from this Azure Maps Account, which we use in our Home view.

1.1 Login into your Azure subscription and save the Azure subscription Id, we need this for later.

az login

1.2 (Optional) Select the subscription where you would like to create the Azure Maps Account.

az account set --subscription "<your subscription>"

1.3 Create a resource group, and change the name and the location for your needs.

az group create -l westeurope -n rg-azuremaps

1.4 Create the Azure Maps Account, and accept the terms and conditions. Save the uniqueId for later.

az maps account create -n map-azuremaps -g rg-azuremaps -s "G2" --kind "Gen2"

1.5 Now we can extract the Azure Maps Primary Key and add it to the Home view in our web application.

az maps account keys list -n map-azuremaps -g rg-azuremaps

1.6 Replace the [YOUR_AZURE_MAPS_KEY] in the file Views/Home/index.cshtml with the Azure Maps Primary Key we just listed in step 1.5.

1.7 Now we can run and test our AzureMapsDemo web application.

dotnet run

Step 2. Managed identities for Azure Maps

In this paragraph, we are removing the ‘shared Key authentication’ (the Azure Maps subscription key) and replacing this with a more secure and production ready managed identities for Azure Maps.

Managed identities for Azure resources provide Azure services with an automatically managed application-based security principal that can authenticate with Azure AD. With Azure role-based access control (Azure RBAC), the managed identity security principal can be authorized to access Azure Maps services.

This means that the web application can request a short-lived token to get access to Azure Maps from Azure Active Directory (AAD). Because this is managed, we do not need to know any passwords or create users. However, to get this token back to the client (the Azure Maps Web Controls runs in the users’ browser), we need to create a simple token proxy API in our web application to forward this token.

We start by creating an Azure Web App where our web application will be hosted and running. This Azure Web App then needs to have rights to get a token for Azure Maps, which we will forward using the token proxy API we create in the below steps.

2.1 Create an app service plan and web app, and change the unique name web-azuremaps and the location for your needs.

az appservice plan create -g rg-azuremaps -n plan-azuremaps -l westeurope

az webapp create -g rg-azuremaps -p plan-azuremaps -n web-azuremaps -r "dotnet:8"

2.2 Next, we create a system-assigned identity for this web app. When finished, we are presented with the principalId, we need this in the next step. To make it simple, you can see the system-assigned identity as an account Azure manages.

az webapp identity assign -n web-azuremaps -g rg-azuremaps

2.3 Now that we have the principalId (use this in the below command) for this system-assigned identity, we can assign the role (what can this system-assigned identity do and access). In this step, we assign the role of Azure Maps Data Reader to this system-assigned identity, which means that this system-assigned identity can only read and not modify or delete data from your Azure Maps account. You already see this is way more secure than the plain Azure Maps key, which has all the rights to do everything. We also need the [YOUR_AZURE_SUBSCRIPTION_ID] from the first step.

az role assignment create --assignee "[PRINCIPAL_ID]" --role "Azure Maps Data Reader" --scope "/subscriptions/[YOUR_AZURE_SUBSCRIPTION_ID]/resourceGroups/rg-azuremaps/providers/Microsoft.Maps/accounts/map-azuremaps"

Hint to get your Azure subscription Id use the following command: az account subscription list

2.4 To get the access token from Azure Active Directory (AAD) back to the client (the web browser), we will create a simple proxy API forwarding this access token. We start by creating an API controller in our web application and adding the GetAzureMapsToken() method.

2.5 First, we must add the Azure Identity NuGet package to our web application.

dotnet add package Azure.Identity

2.6 Next, we create a new ApiController.cs file under the folder Controllers. This new ApiController.cs file will have a method GetAzureMapsToken() that is acting like a proxy for our access token. Read here more about Controllers in a MVC web application.

using Azure.Core;
using Azure.Identity;
using Microsoft.AspNetCore.Mvc;

namespace AzureMapsDemo.Controllers;

public class ApiController : Controller
{
    private static readonly DefaultAzureCredential tokenProvider = new();

    public async Task<IActionResult> GetAzureMapsToken()
    {
        var accessToken = await tokenProvider.GetTokenAsync(
            new TokenRequestContext(new[] { "https://atlas.microsoft.com/.default" })
        );

        return new OkObjectResult(accessToken.Token);
    }
}

2.7 Now that we have our token API proxy, we only need to change the authentication options for the Azure Maps Web Control. Replace in the file Views/Home/index.cshtml the authOptions with the following:

// Add authentication details for connecting to Azure Maps.
authOptions: {
    // Use Azure Active Directory authentication.
    authType: 'anonymous',
    // Your Azure Maps client id for accessing your Azure Maps account.
    clientId: '[YOUR_AZUREMAPS_CLIENT_ID]',
    getToken: function(resolve, reject, map) {
        // URL to your authentication service that retrieves
        // an Azure Active Directory Token.
        var tokenServiceUrl = "/api/GetAzureMapsToken";

        fetch(tokenServiceUrl).then(r => r.text()).then(token => resolve(token));
    }
}

2.8 We also need to update the clientId we saved when we created the Azure Maps account. (Optional) To get the Azure Maps Client Id again, use the value of uniqueId from:

az maps account show -n map-azuremaps -g rg-azuremaps

2.9 Now we can build and deploy our web application that uses managed identities for Azure Maps. We first build and create a release package.

dotnet publish --configuration Release

Compress-Archive -Path bin\Release\net8.0\publish\* -DestinationPath release1.zip

2.10 Then we publish our release package to the Azure Web App.

az webapp deployment source config-zip -g rg-azuremaps -n web-azuremaps --src release1.zip

2.11 Open a web browser and navigate to the https://web-azuremaps.azurewebsites.net/ where the web-azuremaps subdomain is your unique name when creating the Azure Web App. The application looks like this:

2.12. (Optional) We can also navigate to the token proxy API https://web-azuremaps.azurewebsites.net/api/GetAzureMapsToken, copy the token, and past this in the https://jwt.ms/ tool to decode and inspect the token.

Step 3. Protecting the web application and the Azure Maps token proxy API

The web application we built in the last paragraph uses managed identities, and the Azure Maps Web Control uses the access token. Unfortunately, the web application and token proxy API are still accessible to everybody. Therefore, in this paragraph, we are adding the Azure Active Directory (AAD) Authentication to the web application and the token proxy API, so that only authenticated users can view the web application and use the Azure Maps Web Control in a secure way.

3.1 We start by registering an application in the Azure Active Directory, and we need this application registration later to give access to the web application and token proxy API.

az ad app create --display-name "Azure Maps Demo App" --web-redirect-uris https://web-azuremaps.azurewebsites.net/signin-oidc --enable-access-token-issuance true --enable-id-token-issuance true --sign-in-audience AzureADMyOrg

3.2 We need to add four Identity and Authentication NuGet packages to our web application.

dotnet add package Microsoft.Identity.Web
dotnet add package Microsoft.Identity.Web.UI
dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer
dotnet add package Microsoft.AspNetCore.Authentication.OpenIdConnect

3.3 Next, we need to add the [Authorize] attribute to every controller in our web application. Below is our token API proxy controller as an example. Do not forget to do this also for the Home controller!

using Azure.Core;
using Azure.Identity;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Authorization;

namespace AzureMapsDemo.Controllers;

[Authorize]
public class ApiController : Controller
{
    ...

3.4 In the program startup file Program.cs we need to add the Authentication and Authentication logic. Replace all the default code in the Program.cs file with the following:

using Microsoft.AspNetCore.Authentication;
using Microsoft.AspNetCore.Authentication.OpenIdConnect;
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc.Authorization;
using Microsoft.Identity.Web;
using Microsoft.Identity.Web.UI;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"));

builder.Services.AddAuthorization(options =>
{
    options.FallbackPolicy = options.DefaultPolicy;
});

builder.Services.AddControllersWithViews(options =>
{
    var policy = new AuthorizationPolicyBuilder()
        .RequireAuthenticatedUser()
        .Build();
    options.Filters.Add(new AuthorizeFilter(policy));
});
builder.Services.AddRazorPages()
    .AddMicrosoftIdentityUI();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Home/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthentication();
app.UseAuthorization();

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");
app.MapRazorPages();
app.MapControllers();

app.Run();

3.5 The last step before redeploying our secure web application is to add the details from our registered application in the Azure Active Directory into the configuration file. Open the appsettings.json file and replace this with:

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "Domain": "[PUBLISHER_DOMAIN]",
    "TenantId": "[AAD_TENANT_ID]",
    "ClientId": "[APP_ID]",
    "CallbackPath": "/signin-oidc"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*"
}

3.6 Replace the [PUBLISHER_DOMAIN] and [APP_ID] with the values we saved in step 1 when we registered the application. Your Azure Active Directory Tenant ID [AAD_TENANT_ID], you can get with the following command:

az account tenant list

3.7 Now we can build and deploy our web application that uses Azure Active Directory to login. We first build and create a release package.

dotnet publish --configuration Release

Compress-Archive -Path bin\Release\net8.0\publish\* -DestinationPath release2.zip

3.8 Then we publish our release package to the Azure Web App.

az webapp deployment source config-zip -g rg-azuremaps -n web-azuremaps --src release2.zip

3.9 Open a web browser and navigate to the https://web-azuremaps.azurewebsites.net/ where the web-azuremaps subdomain is your unique name when creating the Azure Web App. You are now prompted to log in with your work or school account (AAD) and give permissions.

3.10 A recommended last step is to disable the use of the Azure Maps Key authentication.

az maps account update -n map-azuremaps -g rg-azuremaps --disable-local-auth true -s "G2"

Conclusion

When we have done all the steps in this step-by-step article, you have a protected web application in combination with Azure Maps that uses of Azure Active Directory, Azure role-based access control (Azure RBAC), and Azure Maps tokens. I recommend that you read our Authentication best practices and Azure Maps documentation. Also the Azure Maps Samples website offers so great ideas, with source code on Github, and uses most of the steps described in this article. Happy coding!

This blog post was initially written by me for the Azure Maps Tech Blog.

Introduction

When using Bing Maps for Enterprise in your solution/application, you need a Basic Key (limited free trial) or an Enterprise key to use the services. For example, you would add a Bing Maps Key to the script URL loading the Bing Maps Web Control like this:

<script src="https://www.bing.com/api/maps/mapcontrol?callback=GetMap&key={your bing maps key}"></script>

Important: Bing Maps for Enterprise has been deprecated and is no longer available. Microsoft has discontinued this service. If you’re looking for mapping solutions, please refer to the Azure Maps documentation for current alternatives and migration guidance.

Now your key is open text on your site source code and people who look can find and use your key. Search engines will index your page and, as a result, will also store your key. Is this a problem? Not really.

Protecting

The Bing Maps key is mainly used to determine the usage and allow access to Bing Maps features. To protect your Bing Maps key, so it can’t be misused on other websites, there is an option in the Bing Maps Dev Center to protect your key. This security option allows you to specify a list of referrers (website URLs) and IP numbers who can use your key. When at least one referrer rule is active, any requests that omit a referrer and any requests from non-approved referrers will be blocked, preventing others from using your key for requests. You can have up to 300 referrer and IP security rules per key.

Your key is now protected but is still visible in your website code. So how do I hide my Bing Maps key?

A best practice is never to store any keys or certificates in source code.

Hiding

To hide the Bing Maps key, you create a simple API endpoint that will only return the Bing Maps key if the request comes from a trusted referral URL. The Bing Maps Samples site is a good example that uses this approach.

In this example we are using an Anonymous HttpTrigger Azure Function written in C# that returns the Bing Maps key:

public static class GetBingMapsKey
{
    private static readonly string[] allowd = { "https://samples.bingmapsportal.com/",
                                                "http://localhost"};

    [FunctionName("GetBingMapsKey")]
    public static IActionResult Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = null)] HttpRequest req)
    {
        string referer = req.Headers["Referer"];
        if (string.IsNullOrEmpty(referer))
            return new UnauthorizedResult();

        string result = Array.Find(allowd, site => referer.StartsWith(site, StringComparison.OrdinalIgnoreCase));
        if (string.IsNullOrEmpty(result))
            return new UnauthorizedResult();

        // Get your Bing Maps key from https://www.bingmapsportal.com/
        string key = Environment.GetEnvironmentVariable("BING_MAPS_SUBSCRIPTION_KEY");

        return new OkObjectResult(key);
    }
}