DEV Community: Maykol Alfaro

Beyond the Query: Mastering AI and Vector Search in SQL Server 2025

Maykol Alfaro — Tue, 31 Mar 2026 21:28:47 +0000

The new Microsoft DP-800 SQL AI Developer Associate certification is showing a major move: SQL Server is no longer just a relational database, it’s becoming a new tool for AI-driven applications and Retrieval-Augmented Generation (RAG).

If you are preparing for the exam or modernizing your stack, here are the three AI pillars you need to take into consideration.

1. Vector Embeddings

Vector embeddings represent data as coordinates in a multi-dimensional space. This allows SQL Server to perform a Semantic Search, finding data based on meaning rather than just exact keyword matches.

Vector Search: VECTOR_DISTANCE compares how similar two items are (e.g., finding a "lightweight backpack" when a user searches for "travel bags").
Storage: In SQL Server 2025, vectors are stored using the VECTOR data type, which can handle thousands of dimensions (like the standard 1,536 dimensions used by OpenAI).
Indexing: For large datasets (millions of rows), use DiskANN indexes to enable fast, approximate nearest neighbor (ANN) searches without scanning every row.

2. External Models

You no longer need to move your data to a separate environment to run an LLM. SQL Server now acts as a kind of orchestrator that can call AI models directly via T-SQL.

CREATE EXTERNAL MODEL: This command allows you to define a reusable connection to an AI endpoint (like Azure OpenAI).
AI_GENERATE_EMBEDDINGS: function to convert text stored in columns into vectors.
Security: Uses Database Scoped Credentials to securely authenticate without hardcoding any credentials in your scripts.

3. Retrieval-Augmented Generation (RAG)

RAG solves the lack of the specific knowledge of LLMs about your private business data by:

Retrieving relevant chunks of your private data using vector search.
Augmenting the AI's prompt with this real-world context.
Generating a response that is grounded in your actual database.

Tip: To keep costs down and performance high, always chunk your data into smaller segments (e.g., 500 characters) before generating embeddings. This ensures you don't hit model token limits and keeps your search results focused.

Final Thoughts for DP-800 Candidates

As you study for this certification exam, focus on these three pillars, where I think this certification will be mainly focused. If you follow Microsoft's documentation's path, Milestone 3 is where this magic occurs.

The DLL Hell of Windows Containers: Debugging "Silent" Failures

Maykol Alfaro — Tue, 24 Mar 2026 23:11:38 +0000

In our previous posts, we talked about some techniques to dramatically lower your final image size, the experience working with Windows Containers, and why it was the most viable bridge to the cloud when trying to modernize your applications (.NET Framework). Today, we're moving from the theory of "Lift and Shift" and diving into how to solve the "it works on my machine" nightmare.

If you've spent any time with Windows Containers, you know how it feels when you run docker build, it finishes successfully, then you run docker run, and... nothing. The container exits immediately. No stack trace, no event log, just a Exit Code 1.

Debugging these type of errors require moving from the basic Docker commands and diving into the internals of the Windows kernel and subsystem.

The Entrypoint Trap

When a Windows Container crashes on startup, the logs are often lost because the container object is destroyed before the buffer flushes. To fix this, you must hijack the entrypoint.

Instead of letting your Dockerfile run its ENTRYPOINT, run it manually:

docker run -it --entrypoint powershell your-image-name:latest

Once inside the PowerShell prompt:

Navigate to your app directory (e.g., C:\inetpub\wwwroot or C:\app).
Manually execute your .exe or start the IIS service.
Monitor the console. Here is where you'll likely see a "missing DLL" or "access denied" error that the Docker daemon was hiding.

Hunting the "Ghost" DLLs and Exceptions

Windows Server Core for example is a "refactored" OS. To keep the size down, Microsoft stripped out UI components, fonts, and specific legacy APIs. If your app or one of its third-party dependencies calls one of these missing APIs, it will crash with a DllNotFoundException.

Trying to find these types of errors might be overwhelming, but there are some tools you can download and use directly in your Windows Containers. When the docker logs command is not enough, you can use something like Log Monitor, a Microsoft-supported opensource tool that bridges Windows application logs to STDOUT/STDERR. And it's configured via a config file.

As the Microsoft's documentation says, Log Monitor can either be used in a SHELL usage pattern:

SHELL ["C:\\LogMonitor\\LogMonitor.exe", "cmd", "/S", "/C"]
CMD c:\windows\system32\ping.exe -n 20 localhost

Or an ENTRYPOINT usage pattern:

ENTRYPOINT C:\LogMonitor\LogMonitor.exe c:\windows\system32\ping.exe -n 20 localhost

One tool that also helped me find hidden application specific exceptions was ProcDump. This is a command-line utility from Microsoft Sysinternals designed to monitor applications for CPU spikes, memory spikes, or unhandled exceptions and automatically generate crash dumps (DMP files). Later, you can analyze this generated files with other tools such as WinDbg which offers more modern visuals to see where your application/container is failing.

There are many other tools that you can use to generate these types of logs and try to find "Ghost" DLLs or exceptions that might be causing your containers failure, but at least these are the tools that helped me troubleshoot these scenarios. And at least all these 3 tools are from Microsoft, in case your company worries about using third-party tools that don't align with their security policies.

The Kernel Mismatch (Isolation Modes)

In Linux, the container shares the host kernel. In Windows, the "Kernel" is much more rigid. If your host is Windows 11 and your container is built on ltsc2019, they speak a slightly different "language."

The Symptom: You get an error like "The container operating system does not match the host operating system."

The Fix: Strategic Isolation
As an engineer, you need to understand the two isolation levels:

Process Isolation: The container shares the host kernel directly. It’s fast and has low overhead, but the versions must match (e.g., Host 2022 -> Container 2022).
Hyper-V Isolation: The container runs inside a tiny, optimized VM. It’s slower to start but allows you to run older containers on newer hosts.

Command Tip:

For local development try to force Hyper-V isolation, that way you can test your Windows Containers on different OS versions and don't worry about these kernel mismatches.

docker run --isolation=hyperv your-image-name

The "Invisible Text" Mystery

One of the most common issues you'll get after a "successful" deployment is: "The app runs, the PDF generates, but all the text is missing or replaced by weird squares (▯▯▯)."

This happens because in Windows Server Core Microsoft removed nearly every font you take for granted to reduce its size. If your .NET Framework code asks for "Arial" and it's not there, GDI+ won't always tell you, it will just fail silently or fall back to a font that doesn't support your character set.

On a desktop, you just drag a .ttf into C:\Windows\Fonts. In a container, that does nothing. You can't just COPY the files; you have to register them in the Windows Registry so the GDI+ engine knows they exist.

To solve this, we had to modify our Dockerfile to copy the missing fonts and register them in the Windows Registry.

 # Step 1: Copy your fonts into a temporary folder
 COPY ./my-fonts/ /fonts/  
 # Step 2: Register each font in the registry
 RUN powershell -Command \  
    $fontPath  =  'C:\fonts'; \
    $registryPath  =  'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts'; \ 
    Get-ChildItem -Path  $fontPath  -Filter *.ttf | ForEach-Object { \  
        $fontName  =  $_.BaseName; \ 
        Copy-Item  $_.FullName -Destination  'C:\Windows\Fonts'; \ 
        New-ItemProperty -Path  $registryPath  -Name  $fontName  -Value  $_.Name -PropertyType String -Force \
    }

Final Thoughts

Nobody told us dealing with Windows Containers was going to be a bit frustrating sometimes, but not imposible. At that point we didn't know what else we could do to monitor/debug our containers trying to find these errors. Just to finally see a "missing DLL" or just a "missing font" error. And "tutorials" or these guides on the internet to help you start with Windows Containers don't talk about these nuances, that's why I decided to start writing this series and help some people out there dealing with these types of issues and if you're starting, at least let you know what you will/can encounter during your containerization process.

The Size Paradox: 4 Techniques to Slim Down Windows Container Images

Maykol Alfaro — Wed, 18 Mar 2026 14:00:00 +0000

In our previous post, we discussed my experience working with Windows Containers, and why it was the most viable bridge to the cloud when trying to modernize your applications (.NET Framework).

Sometimes, in a world where Linux images are measured in megabytes, seeing a Windows build log report a 5GB image can be a bit shocking. For us, as software engineers, image size isn't just about disk space, it’s about deployment velocity. A 5GB image means slower cold starts in Kubernetes, longer CI/CD wait times, and higher egress costs. Here is how we managed to lower those numbers down by modifying our Dockerfiles.

The Base Image

One of the most important decisions is made in the very first line of the Dockerfile. Microsoft provides four primary images, and choosing the wrong one can cost you up to 4GB before you even add your code (Yes, that's true).

Base Image	Typical Size	Use Case
Nano Server	~100MB	The "Alpine" equivalent of Windows. Built for the newest .NET versions (.NET 6+). No PowerShell, no WMI.
Server Core	~1.5GB - 2GB	This is the best suite for .NET Framework 4.8. No GUI, but supports the full .NET stack and PowerShell.
Windows	5GB+	This is the largest image and has full Windows API support for workloads.
Windows Server	3GB+	It also provides the full Windows API support and allows you to use more server features. Use only if you have a strong dependency on any Windows specific feature such as GDI+ or specialized fonts.

Note: Always pin your version to the host OS LTSC (Long-Term Servicing Channel). For example, if your production nodes run Windows Server 2025, your FROM should be ltsc2025. Also, if your application for some reason has a strong dependency on a specific cumulative update you can also specify this in your FROM statement, so it should be like ltsc2025-KB5075899.

Multi-Stage Builds

If you are building a .NET Framework app, the SDK image (which includes MSBuild, NuGet, and compilers) is massive, often over 5GB. You must separate your build environment from your runtime environment. This can dramatically reduce the final image size.

# STAGE 1: The Builder
FROM mcr.microsoft.com/dotnet/framework/sdk:4.8 AS builder
WORKDIR /src
COPY . .
RUN nuget restore
RUN msbuild /p:Configuration=Release /p:OutputPath=/app/out

# STAGE 2: The Runtime
FROM mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2025
WORKDIR /inetpub/wwwroot

# We only take the binaries. Everything else (SDK, caches, source) is discarded.
COPY --from=builder /app/out/_PublishedWebsites/MyLegacyApp .

Layer "Squashing" and Atomic Commands

When you add a RUN command in your Dockerfile, it creates a new filesystem layer. In Windows, these layers are significantly heavier than in Linux.

The common mistake: Let's say you're running RUN powershell Expand-Archive app.zip and then RUN powershell Remove-Item app.zip. The ZIP file is still taking up space from the previous layer.

The fix: Use atomic commands. Download, unzip, install, and cleanup in one single layer. That way you're freeing some space and you won't end up with a huge image at the end of the process.

# Optimized Layering
RUN powershell -Command \
    $ProgressPreference = 'SilentlyContinue'; \
    Invoke-WebRequest -Uri https://example.com/installer.msi -OutFile installer.msi; \
    Start-Process msiexec.exe -ArgumentList '/i', 'installer.msi', '/quiet', '/norestart' -NoNewWindow -Wait; \
    Remove-Item installer.msi

Mastering the .dockerignore

These .NET Framework projects are known for their "hidden" folders. Visual Studio creates bin/, obj/, .vs/, and packages/ folders that can easily add several hundred MBs to your build context.

If your build context is huge, your docker build command will hang for minutes just "Sending build context to Docker daemon."

How to solve this: Create a .dockerignore file and exclude everything except your source code. This is similar to how a .gitignore file works.

# .dockerignore
**/.git
**/.vs
**/bin
**/obj
**/packages
*.user
*.suo

I know there might be more ways to optimize your Dockerfiles or your docker builds. In this section I just provided the most common use cases I faced during my "Lift-and-Shift" strategy working with this decade-old .NET Framework application, and how we approached them to successfully become the bridge we needed to get into the cloud.

Final Thoughts

Optimizing Windows images isn't just a nice-to-have feature, it’s what separates a hobbyist project from a production-ready enterprise system. By mastering multi-stage builds and atomic layer cleanup, we can turn a 10GB legacy monolithic application into a 2GB container that scales efficiently.

Windows Containers: Navigating the Path from Monolith to Cloud-Native

Maykol Alfaro — Wed, 11 Mar 2026 15:00:00 +0000

A couple of years ago, I was assigned to a project where I was in charge of containerizing a decade-old web application developed on .NET Framework 4.8. At first, this might seem like a good candidate for migration to a newer version such as .NET 8 (the latest version at that moment). But if you've ever been tasked with modernizing this type of application, you've likely hit the "Rewrite vs. Lift-and-Shift" crossroads.

This is where Windows Containers come in. I know they aren't the coolest choice, but they are often the most viable bridge to the cloud when you're trying to modernize your applications.

The "Why": Pragmatism Over Purity

I've been a software engineer for over 8 years, and something I've learned is that a full rewrite to a newer version isn't always feasible. Business requirements, tight deadlines, and complex dependencies often make a “Lift and Shift” strategy the only viable path.

Windows Containers allow you to wrap that .NET Framework 4.8 monolith in a portable, versioned environment, with minimal changes to the legacy code. You get the benefits of CI/CD and orchestration (like Azure Kubernetes Service) while keeping the application logic exactly as it is.

The Reality Check: This Isn't Linux

Before you run docker build, you need to get away from the Linux mindset. Here is what I’ve learned:

1. The Size Paradox

In Linux, a large image is 500MB. In Windows, a small Server Core image starts at 2GB to 5GB.

Here, you have to prioritize layer caching. If you don't structure your Dockerfile correctly, your CI/CD pipeline will spend 20 minutes just pulling base layers (Don't worry, I've also been there before).

2. Isolation Modes: Your New Best Friend

Windows Containers run in two modes: Process Isolation and Hyper-V Isolation.

Process Isolation shares the host kernel (blazing fast, but the host and container OS versions must match exactly).
Hyper-V Isolation runs the container in a highly optimized VM (slower, but allows you to run an older container on a newer host).

3. The "Silent" Failures

Windows Containers often fail without clear errors if a specific Windows Feature (like GDI+ or specialized fonts) is missing from the base image. Debugging usually requires you to open a PowerShell session just to realize a DLL is missing from your container.

Strategy: How to Approach Your First Build

When you start writing your Dockerfile, don't just aim for "it works." Aim for maintainability.

Use Multi-Stage Builds: Compile your code in a "heavy" SDK image, then copy only the binaries into a "slim" runtime image.
Master the .dockerignore: Windows projects are notorious for bloated bin and obj folders. Don't let them sneak into your image layers, or you'll pay for it in larger image layers and slower builds.
Forward Slashes are King: Even though you’re in a Windows environment, use "/" in your Dockerfiles. It’s cleaner, easier to read, and avoids the "escape character" mess of backslashes.

Don't worry, I know this is just a general overview of my personal experience with Windows Containers, and it doesn't dive into deep specifics. But in the next posts of this series we will discuss how to take advantage of Windows Containers and their ecosystem to architect successful applications.

Final Thoughts

Windows Containers are a bridge to modern cloud applications, but they shouldn't be the final destination. They are a great tool for engineers who need to solve real-world business problems today while preparing for the microservices of tomorrow. They come with challenges and a significant learning curve, but once you master how the isolation modes work and how to manage image layering, you’ve unlocked a massive advantage for your organization and your professional experience.