CodeBytes - The Curious Engineer

Agent Skills, Plugins and Marketplace: The Complete Guide

Thu, 26 Mar 2026 00:00:00 +0000

Extending GitHub Copilot with reusable, shareable AI capabilities

Introduction

GitHub Copilot’s extensibility story has evolved rapidly. From custom instructions to MCP servers, the platform has steadily added ways to customize how the AI assistant works. But until recently, sharing those customizations across projects and teams remained painful - submodules, manual file copying, and constant drift.

That changes with three interconnected features: Agent Skills, Plugins, and Marketplaces. Together, they form a complete ecosystem for creating, packaging, distributing, and discovering AI-powered developer tooling.

This post covers what each piece does, how they fit together, and how to build your own.

Agent Skills: Teaching Copilot New Tricks

Agent Skills were introduced in December 2025. They let you teach Copilot how to perform specialized tasks in a specific, repeatable way.

What Is a Skill?

A skill is a folder containing:

A SKILL.md file with instructions and metadata
Optional supporting scripts, templates, and reference files
Tool and model configuration

When Copilot determines a skill is relevant to your prompt, it automatically loads the instructions and follows them.

Skill Structure

.github/skills/
 csv-analysis/
 SKILL.md # Instructions (required)
 scripts/
 analyze.py # Supporting scripts
 templates/
 report.md # Output templates

Writing a SKILL.md

The SKILL.md file is the entry point. It uses YAML frontmatter for metadata and markdown for instructions:

---
name: csv-analysis
description: Analyze CSV files and generate statistical reports
tools:
 - powershell
 - view
 - create
---

## Instructions

When asked to analyze a CSV file:
1. Read the file and identify columns
2. Compute summary statistics per column
3. Detect missing values and outliers
4. Generate a markdown report with tables and findings

Where Skills Are Discovered

Skills follow an open standard (agentskills.io) shared across leading AI coding tools. Each tool looks in slightly different locations:

Location	Tool	Scope
`.github/skills/`	Copilot CLI, VS Code	Repository
`.claude/skills/`	Claude Code, Copilot	Repository
`.agents/skills/`	Codex CLI	Repository
`.gemini/skills/`	Gemini CLI	Repository
`~/.copilot/skills/`	Copilot CLI	User-level
`~/.claude/skills/`	Claude Code	User-level
`~/.agents/skills/`	Codex CLI	User-level
`~/.gemini/skills/`	Gemini CLI	User-level
Installed plugins	All tools	Global

The SKILL.md format is identical across all tools - write once, discovered everywhere. If you’ve set up skills for Claude Code in .claude/skills/, Copilot picks them up automatically. Skills also work with the Copilot Coding Agent on GitHub.com.

Key Design Principle: On-Demand Loading

Skills load only when relevant. You can define dozens of skills in a project, and Copilot will only load the ones that match the current task. This keeps context windows focused and avoids unnecessary token usage.

Plugins: Package Management for Copilot

While skills solve the “how do I teach Copilot something new?” problem, plugins solve the “how do I share it?” problem.

What Is a Plugin?

A plugin is a distributable package that bundles Copilot customizations into a single installable unit. Think of it as npm for your Copilot configurations.

A plugin can contain any combination of:

Component	File Pattern	Purpose
Custom Agents	`agents/*.agent.md`	Specialized AI assistants with defined personas
Skills	`skills/*/SKILL.md`	Discrete callable capabilities
Hooks	`hooks.json`	Event handlers for agent lifecycle
MCP Servers	`.mcp.json`	Model Context Protocol integrations
LSP Servers	`lsp.json`	Language Server Protocol integrations

Creating a Plugin

Every plugin needs a plugin.json manifest in a .github/ subdirectory:

my-plugin/
 .github/
 plugin.json # Required manifest
 agents/
 my-agent.agent.md
 skills/
 my-skill/
 SKILL.md
 hooks.json

The manifest declares what the plugin contains. Here’s the real plugin.json from the agent-skills demo repo:

{
 "name": "document-tools",
 "description": "Document processing toolkit with CSV analysis, report generation, and data profiling capabilities",
 "version": "1.0.0",
 "author": {
 "name": "Chris Ayers",
 "email": "noreply@chris-ayers.com"
 },
 "license": "MIT",
 "keywords": ["data", "csv", "analysis", "reporting"],
 "agents": [
 "./agents/data-analyst.agent.md"
 ],
 "skills": [
 "./skills/csv-analysis/"
 ]
}

Important details:

The name field should only contain letters, numbers, and dashes
File paths are relative to the plugin root, not the .github/ directory
When layering a plugin onto an existing repo, paths may need ../../ navigation

Why Plugins Over Manual Config?

Feature	Manual Configuration	Plugins
Scope	Single repository	Any project
Sharing	Copy/paste files	`copilot plugin install`
Versioning	Git history	Marketplace versions
Discovery	Searching repositories	Marketplace browsing
Updates	Manual tracking	`copilot plugin update`

Marketplaces: App Stores for Plugins

A marketplace is a Git repository that serves as a registry for available plugins. It’s a lightweight app store - a marketplace.json file that lists plugins with metadata.

Default Marketplaces

Both VS Code and Copilot CLI ship with two marketplaces pre-configured:

Marketplace	Description
copilot-plugins	Official GitHub plugins
awesome-copilot	Community-contributed plugins

Creating a Marketplace

Create .github/plugin/marketplace.json in a Git repository:

{
 "name": "my-team-plugins",
 "owner": {
 "name": "My Team",
 "email": "team@example.com"
 },
 "metadata": {
 "description": "Internal team plugin registry",
 "version": "1.0.0"
 },
 "plugins": [
 {
 "name": "dev-toolkit",
 "description": "Full-stack development tools",
 "version": "1.0.0",
 "source": "./plugins/dev-toolkit"
 }
 ]
}

Push to GitHub and you have a working marketplace.

Versioning with External Sources

Plugins can reference external repositories with specific tags:

{
 "name": "external-tool",
 "version": "2.0.0",
 "source": {
 "source": "url",
 "url": "https://github.com/org/tool-plugin",
 "ref": "v2.0"
 }
}

This lets your marketplace curate plugins from multiple repositories, each pinned to a specific version.

Cross-Tool Compatibility

One of the most powerful aspects of the emerging plugin ecosystem is cross-tool portability. The SKILL.md format follows an open standard shared across multiple AI coding tools.

Compatibility Matrix

Capability	Copilot CLI	VS Code	Claude Code	Codex CLI	Gemini CLI
Skills (SKILL.md)	Yes	Yes	Yes	Yes	Yes
Custom Agents	Yes	Yes	Yes	Partial	Partial
Plugin Manifest	`.github/plugin.json`	`.github/plugin.json`	`.claude-plugin/plugin.json`	N/A	Extensions
Marketplace	Yes `marketplace.json`	Yes Same	Yes Same concept	`$skill-installer`	`gemini extensions`
Hooks	Yes	Yes	Yes	No	No
MCP Servers	Yes	Yes	Yes	No	Yes
LSP Servers	Yes	Yes	Yes	No	No

Making Plugins Work Everywhere

To maximize compatibility, include both plugin manifests:

my-plugin/
 .github/
 plugin.json # Copilot CLI + VS Code
 .claude-plugin/
 plugin.json # Claude Code
 agents/
 my-agent.agent.md # Shared across tools
 skills/
 my-skill/
 SKILL.md # Universal format
 hooks.json # Copilot + Claude

For Codex CLI and Gemini CLI users, also provide skills at the repo root:

my-repo/
 .agents/skills/ # Codex CLI discovery
 my-skill/
 SKILL.md
 .gemini/skills/ # Gemini CLI discovery
 my-skill/
 SKILL.md
 plugins/
 my-plugin/ # Full plugin for Copilot + Claude
 .github/plugin/
 marketplace.json # Marketplace registry

Key Takeaway

Skills are the most portable - the SKILL.md format works identically across all five tools. Plugins require dual manifests (.github/ + .claude-plugin/) for full Copilot and Claude support. Codex uses .agents/skills/ and community registries, while Gemini uses .gemini/skills/ and its own extensions system.

Installing and Managing Plugins

Copilot CLI

# Browse default marketplaces
copilot plugin marketplace list
copilot plugin marketplace browse awesome-copilot

# Add a custom marketplace
copilot plugin marketplace add my-org/internal-plugins

# Install from a marketplace
copilot plugin install dev-toolkit@awesome-copilot

# Install directly from a repository
copilot plugin install user/repo
copilot plugin install user/repo:plugins/subfolder

# Manage installed plugins
copilot plugin list
copilot plugin update my-plugin
copilot plugin uninstall my-plugin

VS Code

Set chat.plugins.enabled to true in settings

Add marketplaces to chat.plugins.marketplaces:

{
 "chat.plugins.marketplaces": ["my-org/my-plugins"]
}

Browse with @agentPlugins in the Extensions view
Or use Command Palette then Chat: Plugins

Tip: Marketplace settings must be at the user level - workspace settings won’t work.

Runtime Behavior

After installation, components integrate automatically:

Agents appear in your agent selection
Skills load when relevant to your task
Hooks fire at lifecycle events
MCP servers extend the available tool set

No additional configuration needed.

Where Plugins Are Stored

Source	Location
Marketplace plugins	`~/.copilot/installed-plugins/MARKETPLACE/PLUGIN/`
Direct installs	`~/.copilot/installed-plugins/_direct/PLUGIN/`
VS Code (macOS)	`~/Library/Application Support/Code/agentPlugins/`
VS Code (Windows)	`%APPDATA%/Code/agentPlugins/`

Knowing where plugins land is useful for debugging — if a plugin isn’t loading, check these paths to verify installation succeeded.

Building a Plugin: Step by Step

The agent-skills repo demonstrates a complete working example. Here’s the workflow:

1. Create the structure

mkdir -p my-plugin/.github
mkdir -p my-plugin/agents
mkdir -p my-plugin/skills/csv-analysis

2. Write the plugin manifest (my-plugin/.github/plugin.json)

Note: paths are relative to the plugin root, not the .github/ directory, so they start with ../.

3. Define an agent — a persona with specific tools and a workflow (see agents/data-analyst.agent.md in the demo repo for a full example).

4. Define a skill — a focused, on-demand capability with a SKILL.md frontmatter declaring its name, description, and required tools.

5. Add a hooks.json to fire notifications or setup steps at lifecycle events:

{
 "hooks": {
 "subagentStart": [
 {
 "command": "echo 'Document tools plugin loaded — data analysis capabilities active'",
 "description": "Notify when document tools plugin activates"
 }
 ]
 }
}

6. Publish as a marketplace — push the repo to GitHub, then anyone can register it:

copilot plugin marketplace add codebytes/agent-skills
copilot plugin install document-tools@agent-skills

That’s it. The agent and skills are now available across every project.

Security Considerations

The plugin system operates within Copilot’s standard permission framework:

Folder trust - Repository-level hooks only load after user confirms trust
Tool permissions - Standard approval prompts for plugin tools
skipPermission - Authors can mark known-safe operations to skip prompts
MCP allowlists - Restrict servers with MCP_ALLOWLIST feature flags
Review before install - Always inspect unfamiliar plugins before installing

Best Practices

Start with existing plugins - Browse awesome-copilot and copilot-plugins before building your own
Keep plugins focused - “Rails development” is better than “everything”
Test with CLI first - Better error messages than VS Code for debugging
Version with tags - Pin external sources to specific refs
Use for team standards - Publish internal plugins for consistent tooling
Update regularly - copilot plugin update for latest improvements
Review what you install - Plugins run code on your machine

Known Limitations (Preview)

As of early 2026, these features are still in preview:

VS Code settings scope: Marketplaces must be user-level, not workspace
Dev containers: Plugin installation may not work inside containers
Silent failures: Manifest errors cause feeds to silently not appear
Aggressive caching: VS Code caches feed details; may need reload or alternate URL format
Branch installs: CLI doesn’t yet support installing from specific branches directly

Use VS Code Insiders for the latest fixes, and validate with Copilot CLI before VS Code.

The Big Picture

The ecosystem follows a clear layering:

Skills teach Copilot specific tasks
Agents provide specialized personas
Plugins package everything together
Marketplaces make it all discoverable

Resources

Demo Repo: codebytes/agent-skills — Complete working plugin + marketplace example
GitHub Docs: About CLI Plugins
awesome-copilot: Installing and Using Plugins
GitHub Changelog: Agent Skills
copilot-plugins Registry
awesome-copilot Marketplace

Microsoft Certification Renewals - March 2026

Mon, 02 Mar 2026 00:00:00 +0000

I just renewed six Microsoft certifications, keeping my skills current across Azure architecture, security, networking, and AI.

Why Renewals Matter

I started pursuing certifications early in my career as a consultant at a professional services company. They encouraged it, and it helped with competencies and career growth. When you’re helping customers adopt a technology, having the certification carries authority - it shows you’ve put in the work to understand the platform deeply.

Beyond the professional benefits, certifications force you to learn. The renewal process keeps you up to date with the latest features and changes, and it pushes you into areas of a technology that you might not use day to day. You end up with a much more complete understanding of the platform, not just the parts you happen to work with.

Staying Current

Microsoft role-based and specialty certifications require periodic renewal to ensure credential holders stay up to date with the latest technologies. Rather than retaking full proctored exams, Microsoft offers free online renewal assessments through Microsoft Learn. These assessments cover the latest updates and features added since the last renewal cycle.

On March 2, 2026, I completed renewal assessments for all six of my expiring certifications in a single session.

Certifications Renewed

Expert Level

Microsoft Certified: Cybersecurity Architect Expert - Designing and evolving cybersecurity strategy for an organization, including zero-trust architecture, governance, risk, and compliance (GRC), and security operations
Microsoft Certified: Azure Solutions Architect Expert - Designing and implementing solutions on Azure, including compute, network, storage, monitoring, and security

Associate Level

Microsoft Certified: Security Operations Analyst Associate - Investigating, searching for, and mitigating threats using Microsoft Sentinel, Microsoft Defender for Cloud, and Microsoft Defender XDR
Microsoft Certified: Azure AI Engineer Associate - Designing and implementing Azure AI solutions using Azure AI services, Azure AI Search, and Azure OpenAI
Microsoft Certified: Azure Network Engineer Associate - Designing, implementing, and maintaining Azure networking solutions including hybrid networking, connectivity, routing, and security
Microsoft Certified: Azure Security Engineer Associate - Implementing security controls, managing identity and access, and protecting data, applications, and networks in Azure

For anyone considering Microsoft certifications, the renewal process is straightforward and free. You can complete the assessments at your own pace on Microsoft Learn, and they cover the latest updates since your last renewal cycle.

MITRE ATT&CK for Developers: Beyond OWASP

Sat, 28 Feb 2026 00:00:00 +0000

Most developers know the OWASP Top 10, but fewer know MITRE ATT&CK. OWASP tells you what can break. ATT&CK tells you how attackers actually operate. Together, they give you a complete picture of application security.

I’ll be presenting this topic at NDC Security 2026 in Oslo, March 2-5. If you’re attending, come check out my talk — MITRE ATT&CK for Developers — on Wednesday, March 4 at 10:20.

The Security Challenge

Modern applications have a massive attack surface — APIs, microservices, cloud resources — every one a potential entry point. Attackers chain multiple techniques across stages, adapting as they go. Traditional defenses focus on single points of failure, but sophisticated attacks slip through.

The uncomfortable truth: attackers iterate faster than our defenses.

What is OWASP

OWASP is a community-driven organization that publishes security standards for web applications. The OWASP Top 10 catalogs the most critical risks:

#	Category
A01	Broken Access Control
A02	Cryptographic Failures
A03	Injection
A04	Insecure Design
A05	Security Misconfiguration
A06	Vulnerable and Outdated Components
A07	Identification and Authentication Failures
A08	Software and Data Integrity Failures
A09	Security Logging and Monitoring Failures
A10	Server-Side Request Forgery (SSRF)

OWASP’s strength is prevention — it tells you what vulnerabilities exist and how to fix them.

What is MITRE

MITRE is a not-for-profit, vendor-neutral organization founded in 1958. They maintain an ecosystem of interlocking cybersecurity frameworks:

CVE - catalogs specific vulnerabilities in software
CWE - classifies underlying weakness types in code
CAPEC - documents attack patterns
ATT&CK - maps real-world adversary behavior
D3FEND - catalogs defensive countermeasures
ATLAS - covers AI and machine learning threats

What is MITRE ATT&CK

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a knowledge base of adversary behavior based on real-world cyber attacks. Born from a 2013 experiment at Fort Meade, it catalogs what attackers actually do across the full attack lifecycle.

The Enterprise Matrix has 14 tactics, over 200 techniques, and 400+ sub-techniques.

How It Is Organized

Tactics - the “why” (the adversary’s goal)
Techniques - the “how” (the method used)
Sub-techniques - specific implementations
Procedures - real-world examples from threat actors

The 14 Tactics

Phase	Tactics
Pre-Attack	Reconnaissance, Resource Development
Get In	Initial Access, Execution, Persistence, Privilege Escalation
Stay In	Defense Evasion, Credential Access, Discovery, Lateral Movement
Act	Collection, Command and Control, Exfiltration, Impact

OWASP vs ATT&CK: Why You Need Both

These frameworks are complementary, not competitive:

	OWASP	MITRE ATT&CK
Focus	Vulnerabilities	Adversary behavior
Perspective	What breaks	What attackers do
Approach	Prevention-first	Detection-oriented
Scope	Application layer	Full attack lifecycle

“OWASP prevents vulnerabilities. ATT&CK detects adversary behavior.”

A single OWASP vulnerability can enable multiple ATT&CK techniques:

OWASP Category	ATT&CK Techniques
Broken Access Control	T1078 (Valid Accounts), T1098 (Account Manipulation), T1068 (Privilege Escalation)
Injection	T1190 (Exploit Public-Facing App), T1059 (Command Injection)
Security Misconfiguration	T1552 (Unsecured Credentials), T1082 (System Info Discovery)
Cryptographic Failures	T1555 (Credentials from Password Stores), T1565 (Data Manipulation)
Authentication Failures	T1087 (Account Discovery), T1110 (Brute Force)

Why Developers Should Care

You already use MITRE data. Tools like Dependabot, Snyk, and Trivy report CVEs and CWEs under the hood. Understanding the ecosystem helps you make better decisions about what to fix and why.

Shared vocabulary. When your SOC team says “we detected T1190,” you’ll know they mean exploitation of a public-facing application and can reason about which services might be affected.

Your code is the detection layer. The logs and telemetry you emit feed directly into ATT&CK-based detection systems. Better observability means faster threat detection.

Attack Chains Are Real

Attackers chain multiple techniques together. A supply chain attack might unfold like this:

Attacker publishes a typosquatted npm package
Post-install script executes a payload
Payload harvests credentials from environment variables
Stolen credentials provide production access
Attacker creates a backdoor IAM user for persistence
Customer data is exfiltrated

Six techniques, six tactics, one continuous attack. Defend only at the perimeter and you miss five of six detection opportunities. Real attacks also loop and backtrack — ATT&CK captures this reality with a matrix rather than a linear chain.

What You Can Do Today

Start with three high-impact techniques:

T1078 - Valid Accounts — monitor authentication patterns for credential stuffing
T1539 - Steal Web Session Cookie — secure session management with fingerprinting and short expiration
T1213 - Data from Information Repositories — behavioral analytics to detect unusual data access

Then build from there:

Map features to techniques — identify which ATT&CK techniques each feature could enable
Tag logs with technique IDs — so your SIEM can correlate events
Use the ATT&CK Navigator — visualize coverage and gaps
Include ATT&CK in threat modeling — consider how attackers would chain techniques
Review code for both — OWASP vulnerabilities AND technique resistance

Resources

Conclusion

OWASP and ATT&CK are two sides of the same coin — prevent what you can, detect what you cannot. Understanding how attackers operate makes you a better developer. Start small, pick a few high-impact techniques, and build from there.

NDC Security 2026

Sat, 28 Feb 2026 00:00:00 +0000

I’m excited to be speaking at NDC Security 2026 in Oslo, March 2-5! I’ll be presenting MITRE ATT&CK for Developers — showing how developers can go beyond the OWASP Top 10 and use the ATT&CK framework to think like attackers and build stronger defenses.

About NDC Security

NDC Security is a dedicated security conference for software developers, held at the Radisson Blu Scandinavia Hotel in Oslo. With 66 sessions and over 60 speakers, it bridges the gap between development and security — designed for developers who want to build secure software and security professionals who want to understand modern development practices.

This year features an all-new OWASP x NDC Security track, bringing OWASP content directly into the conference lineup.

My Talk: MITRE ATT&CK for Developers

Wednesday, March 4 at 10:20 — Room 3

Most developers know the OWASP Top 10, but fewer know the MITRE ATT&CK framework. In this talk, I’ll cover how ATT&CK complements OWASP, walk through real attack chains with code examples in Python, C#, and JavaScript, and show practical detection patterns you can implement in your applications. The goal: think like an attacker, build like a defender.

For a preview, check out my blog post on MITRE ATT&CK for Developers: Beyond OWASP.

Conference Highlights

Keynote

Michael Howard opens the conference with 25 Years of the Microsoft SDL — a look back at how the Security Development Lifecycle has shaped how we build secure software.

Workshops (March 2-3)

The conference kicks off with two days of hands-on workshops:

Bulletproof APIs: Hands-On API Security — Philippe De Ryck
Hack Yourself First: How to Go on the Cyber-Offence — Scott Helme
Identity and Access Control for Modern Applications using ASP.NET 10 — Anders Abel
Building and Deploying Secure AI: Practical Strategies for Developers — Jim Manico
Attack and Secure AI Apps - Wargame Edition — Davide Cioccia
Full-Stack Pentesting Laboratory — Dawid Czagan

Notable Sessions

A few talks I’m looking forward to:

Prompt Injection Attacks in LLM-Powered Applications — Magno Logan
ASP.NET Core Meets OWASP Top 10 2025 — Anders Abel
Securing Model Context Protocol (MCP) — Jim Manico
Getting Authorization Right in .NET — Michele Leroux Bustamante
Beyond the Commit: Weaponizing and Hardening GitHub Actions — Niek Palm
Your Website Is Running Code You’ve Never Seen — Scott Helme

See You There

If you’re attending NDC Security, come say hello! You can check out the full agenda and grab tickets at ndcsecurity.com.

Promoted to Principal Software Engineer at Microsoft

Mon, 23 Feb 2026 00:00:00 +0000

I’m thrilled to share that I’ve been promoted to Principal Software Engineer at Microsoft!

The Journey

It’s been an incredible four and a half years at Microsoft, and this milestone still feels a bit surreal. When I joined Microsoft in October 2021 as a Senior Customer Engineer on the Fast Track for Azure (FTA) team, I was living a dream I’d had since childhood. I never imagined the journey would bring me here.

During my time on the FTA team, I worked directly with customers adopting Azure, helping them architect and build cloud-native solutions. It was an amazing experience - every engagement brought new challenges, new architectures, and new opportunities to learn and teach.

In late 2024, I moved to the Azure Reliability (AzRel) Risk SRE team, a shift that pushed me into entirely new territory. As the lead for the Platform Reliability Pillar, I dove into outage analysis, building AI-driven tooling with OpenAI and Semantic Kernel to help engineers understand failures and strengthen Azure’s reliability at scale. It was a big change, but it reinforced something I’ve always believed - growth comes from stepping into the unfamiliar.

Looking Forward

As a Principal Software Engineer, I’m continuing to focus on Azure reliability - building tools and systems that help keep the platform running smoothly for millions of users worldwide. I’m also doubling down on the things I’m passionate about:

Building - AI-powered tooling for reliability engineering, distributed systems, and cloud-native applications
Speaking - sharing what I’ve learned at conferences around the world, from NDC and Techorama to DevSum and Aspire Conf
Community - organizing DevOps Days Tampa Bay, active with Tampa Devs and multiple local meetups, mentoring, and contributing to open source
Writing - more blog posts, more samples, more sharing

What Does Principal Mean at Microsoft

For those curious about what this level means at Microsoft, I wanted to share some context. At Microsoft, engineering levels form a career ladder, and the jump from Senior to Principal represents a meaningful shift in scope, impact, and expectations.

A Senior Software Engineer (levels 63-64) typically executes complex features, leads projects within a single team, designs components, reviews code, and mentors team members. The focus is largely on the how - delivering high-quality work within established frameworks.

A Principal Software Engineer (levels 65-67) operates differently. The role shifts toward strategic technical leadership - defining architecture across multiple teams, solving organization-wide problems, and aligning technology decisions with business goals. The focus moves to the why - long-term strategy, navigating high ambiguity, and innovating beyond existing solutions.

Some of the key differences:

Scope of Impact - Senior engineers own projects within a team. Principals influence entire organizations, divisions, or large-scale technical strategies
Technical Focus - Principals handle high ambiguity and innovate beyond existing solutions. Seniors work within established frameworks to deliver features
Leadership - Principals guide technical direction, manage stakeholders, and mentor other senior engineers. Seniors focus more on day-to-day implementation and mentoring junior staff

For me, this promotion reflects the way I’ve been working - constantly sharing knowledge, educating the team, and helping set technical direction. Whether it’s building alignment across orgs and teams, driving architecture decisions, or connecting people and ideas across organizational boundaries, the Principal role formalizes what I believe great engineering looks like at scale.

At its core, it comes down to a growth mindset. The willingness to step into ambiguity, learn continuously, and lift others up along the way. That’s what got me here, and it’s what I’ll keep doing.

Gratitude

None of this happens alone. I’m grateful for the incredible teammates and mentors I’ve had on both teams, the managers who championed my growth, and the community that keeps pushing me to learn and share. And of course, my family - who support all the late nights, conference travel, and the constant tinkering.

If you’re on your own career journey, here’s what I’d say: don’t be afraid to take the leap into unfamiliar territory. The skills you’ve built are more transferable than you think, and the best growth happens outside your comfort zone.

Here’s to the next chapter. Let’s build something great.

Aspire CLI Part 3 - MCP for AI Coding Agents

Sun, 22 Feb 2026 00:00:00 +0000

In Part 1, we covered creating and running Aspire apps. In Part 2, we explored deployment and CI/CD. Now let’s look at one of Aspire’s most exciting features: MCP (Model Context Protocol) support for AI coding agents.

Aspire MCP enables AI coding agents to understand and interact with your distributed applications. Your AI assistant can query resource states, debug with real-time logs, and investigate telemetry across your entire system — without you having to copy/paste anything.

What is Aspire MCP?

The Aspire MCP server is a local Model Context Protocol server that connects your AI coding assistants to your running distributed application. Starting with Aspire 9.0, MCP support has been available through manual dashboard configuration, and Aspire 13.1 added the aspire mcp init command for automatic setup.

Note: The aspire mcp commands are being renamed to aspire agent in a future release. The generated configs already use aspire agent mcp. See the MCP sample for a complete working example with Postgres, Redis, and pre-configured AI agent support.

It bridges the gap between your running distributed application and AI coding assistants like GitHub Copilot, Claude Code, Cursor, and OpenAI Codex.

With Aspire MCP, your AI assistant can:

Query resources — Get resource states, source, endpoints, health status, and available commands
Debug with logs — Access real-time console logs from any resource
Investigate telemetry — Analyze structured logs and distributed traces across services
Execute commands — Run resource commands directly
Discover integrations — Find and understand available Aspire hosting integrations

This transforms your AI assistant from a code generator into a development partner that understands your running system.

Two Transport Modes

Before setting up MCP, it helps to understand the two transport modes:

STDIO (CLI approach) — The AI assistant launches aspire mcp start as a subprocess. No URL or API key needed. This is the recommended approach for Aspire 13.1+.
HTTP (manual/dashboard approach) — The Aspire dashboard exposes an HTTP endpoint with URL + API key authentication. This is the approach for Aspire 9.0-13.0 or when you need more control.

Getting Started

Option 1: Using the Aspire CLI (Recommended)

Starting with Aspire 13.1, the aspire mcp init command detects supported AI assistant environments and creates the appropriate configuration files:

cd your-aspire-project
aspire mcp init

The command detects supported AI assistants in your environment and generates configuration files. Currently supported assistants for automatic setup:

Visual Studio Code — Generates .vscode/mcp.json
GitHub Copilot CLI — Generates Copilot CLI configuration
Claude Code — Generates .claude/ configuration
OpenCode — Generates OpenCode configuration

The generated config uses STDIO transport, launching aspire mcp start as a subprocess. For example, Visual Studio Code gets a .vscode/mcp.json like:

{
 "servers": {
 "aspire": {
 "type": "stdio",
 "command": "aspire",
 "args": ["mcp", "start"]
 }
 }
}

If you don’t already have an AGENTS.md file in your project, one is created automatically with context about your Aspire application to help AI assistants understand your project.

Option 2: Manual Configuration (Aspire 9.0-13.0)

For older Aspire versions, or when you need more control:

Run your Aspire app with aspire run
Open the Aspire dashboard
Click the MCP button in the top right corner
Use the displayed settings to configure your AI assistant

The dashboard provides these settings for HTTP-based MCP:

Setting	Description
`url`	Aspire MCP endpoint address
`type`	`http` (streamable-HTTP MCP server)
`x-mcp-api-key`	HTTP header for securing access

This approach supports additional assistants including Visual Studio, Cursor, and OpenAI Codex. Consult your tool’s MCP documentation for configuration details.

MCP Tools Available

Once connected, your AI assistant gains access to several powerful tools:

Resource Management

list_resources — Lists all resources with state, health status, source, endpoints, and commands
execute_resource_command — Executes commands on specific resources

Logging and Telemetry

list_console_logs — Gets console logs for a resource
list_structured_logs — Retrieves structured logs, optionally filtered by resource
list_traces — Lists distributed traces, optionally filtered by resource name
list_trace_structured_logs — Gets structured logs for a specific trace

Integration Discovery

list_integrations — Shows available Aspire hosting integrations with package IDs and versions
get_integration_docs — Retrieves documentation for a specific integration package

AppHost Management

list_apphosts — Lists all AppHost connections, showing which are within the working directory scope and which are outside
select_apphost — Switches context to a specific AppHost

Example Prompts

After configuring MCP, try these prompts with your AI assistant:

“Are all my resources running?”
“Show me the last 50 log entries from the API service”
“Analyze HTTP request performance for the webfrontend”
“What traces show errors in the last 5 minutes?”
“Restart unhealthy resources”
“What Aspire integrations are available for Redis?”

Excluding Resources from MCP

You may have resources with sensitive data that shouldn’t be exposed to AI assistants. Annotate them in your AppHost:

var builder = DistributedApplication.CreateBuilder(args);

var apiservice = builder.AddProject<Projects.Api>("api")
 .ExcludeFromMcp(); // This resource hidden from MCP

builder.AddProject<Projects.Web>("web")
 .WithReference(apiservice);

builder.Build().Run();

This excludes the resource and its associated telemetry from all MCP results.

A Practical Example

Consider a polyglot application using the Aspire CLI with AI-assisted development. Here’s a sample AppHost from the Aspire 13 samples:

#:package Aspire.Hosting.OpenAI@13.0.0
#:package Aspire.Hosting.Python@13.0.0
#:package Aspire.Hosting.Docker@13-*
#:sdk Aspire.AppHost.Sdk@13.0.0

var builder = DistributedApplication.CreateBuilder(args);

builder.AddDockerComposeEnvironment("dc");

var openai = builder.AddOpenAI("openai");

builder.AddUvicornApp("ai-agent", "./agent", "main:app")
 .WithUv()
 .WithExternalHttpEndpoints()
 .WithEnvironment("OPENAI_API_KEY", openai.Resource.Key);

builder.Build().Run();

After running aspire mcp init and aspire run, you can ask your AI assistant things like:

“Is the ai-agent resource healthy?”
“Show me any errors in the agent logs”
“What OpenTelemetry traces have the longest duration?”

The AI sees the Python service, the OpenAI connection, health check status, logs, and traces — all in real time. No more copying log output into chat windows.

Supported AI Assistants

Assistant	`aspire mcp init`	Manual (Dashboard)	Docs
Visual Studio Code Copilot	✅	✅	MCP servers
GitHub Copilot CLI	✅	✅	Add MCP server
Claude Code	✅	✅	MCP configuration
OpenCode	✅	✅	OpenCode docs
Visual Studio	—	✅	MCP configuration
Cursor	—	✅	Installing MCP servers
OpenAI Codex	—	✅	MCP setup

Securing the API Key

When using the manual/HTTP configuration, the x-mcp-api-key secures access to MCP. Your AI assistant needs access to this key — use your tool’s secure storage to avoid committing it to source control.

Visual Studio Code Example — Use input variables to prompt for the key at connection time rather than hardcoding it in mcp.json.

Note: If you’re using aspire mcp init (STDIO transport), there’s no API key to manage — authentication is handled by the subprocess communication.

Troubleshooting

Self-Signed Certificate Issues

Some AI assistants don’t support self-signed HTTPS certificates. If you encounter connection issues:

If you use the http launch profile, you’re already set
For HTTPS, configure just the MCP endpoint to use HTTP in launchSettings.json:

{
 "profiles": {
 "https": {
 "environmentVariables": {
 "ASPIRE_DASHBOARD_MCP_ENDPOINT_URL": "http://localhost:16036",
 "ASPIRE_ALLOW_UNSECURED_TRANSPORT": "true"
 }
 }
 }
}

Caution: This removes transport security from MCP communication.

Data Size Limits

AI models have context limits. Aspire MCP automatically:

Truncates large data fields (like exception stack traces)
Omits older items from large telemetry collections

Why This Matters

Traditional AI coding assistants work with static code. Aspire MCP connects them to your running system. This enables scenarios like:

“Why is the checkout service slow?” - The AI can analyze traces and identify the bottleneck
“Debug this 500 error” - The AI accesses structured logs to find the root cause
“Is my database connection healthy?” - The AI checks resource health status directly

Instead of asking you to describe your system, the AI can observe it directly.

Learn More

Wrapping Up

Aspire MCP represents a shift in how we interact with distributed applications during development. By giving AI assistants real-time access to your running system, you unlock debugging and development workflows that weren’t possible before.

Try aspire mcp init in your next project and see how it transforms your AI-assisted development experience.

Until next time, happy Aspiring!

Aspire CLI Part 2 - Deployment and Pipelines

Sat, 21 Feb 2026 00:00:00 +0000

In Part 1, we covered the basics of the Aspire CLI: creating projects with aspire new, adding Aspire to existing apps with aspire init, running with aspire run, and managing integrations with aspire add and aspire update. Now let’s dive into deployment and CI/CD pipelines.

Prerequisite: Aspire 13 requires .NET SDK 10.0.100 or later. Make sure you have it installed before using the commands in this post.

The Publish and Deploy Model

Aspire separates deployment into two distinct phases:

Publish (aspire publish) — Generates intermediate, parameterized deployment artifacts (Compose files, Kubernetes manifests, Bicep templates, etc.)
Deploy (aspire deploy) — Resolves parameters and applies those artifacts to a target environment

This separation is intentional. Published assets contain placeholders instead of concrete values — secrets and environment-specific configuration are injected later at deploy time. This keeps sensitive data out of your artifacts and enables the same published output to target multiple environments.

`aspire publish` - Generate Deployment Artifacts

The aspire publish command generates deployment artifacts based on the compute environments configured in your AppHost. A compute environment represents a target platform and determines what gets generated.

aspire publish -o ./artifacts

The output depends on which hosting integration packages you’ve added:

NuGet Package	Target	Publish	Deploy
`Aspire.Hosting.Docker`	Docker Compose	✅ Yes	🧪 Preview
`Aspire.Hosting.Kubernetes`	Kubernetes	✅ Yes	🧪 Preview
`Aspire.Hosting.Azure.AppContainers`	Azure Container Apps	✅ Yes	✅ Yes (Preview)
`Aspire.Hosting.Azure.AppService`	Azure App Service	✅ Yes	✅ Yes (Preview)

If no integration supports publishing, aspire publish will tell you:

No resources in the distributed application model support publishing.

Parameterized Output

Published artifacts contain placeholders rather than concrete values. For example, a Docker Compose publish might generate:

services:
 pg:
 image: "docker.io/library/postgres:17.2"
 environment:
 POSTGRES_PASSWORD: "${PG_PASSWORD}"
 ports:
 - "8000:5432"
 api:
 image: "${API_IMAGE}"
 environment:
 ConnectionStrings__db: "Host=pg;Port=5432;Username=postgres;Password=${PG_PASSWORD};Database=db"

Notice ${PG_PASSWORD} and ${API_IMAGE} are not resolved during publish. You supply their values at deploy time — through environment variables, .env files, or CI/CD pipeline secrets.

Docker Compose Example

The most common pattern from the Aspire samples uses Docker Compose as the compute environment. See the Docker Compose sample for a complete working example.

#:package Aspire.Hosting.Docker@13-*
#:sdk Aspire.AppHost.Sdk@13.0.0

var builder = DistributedApplication.CreateBuilder(args);

builder.AddDockerComposeEnvironment("dc");

var postgres = builder.AddPostgres("postgres")
 .WithDataVolume()
 .WithPgAdmin();
var db = postgres.AddDatabase("db");

builder.AddCSharpApp("api", "./api")
 .WithHttpHealthCheck("/health")
 .WithExternalHttpEndpoints()
 .WaitFor(db)
 .WithReference(db);

builder.Build().Run();

Then the standard workflow is:

aspire run # Run locally
aspire publish -o ./artifacts # Generate Docker Compose files
aspire deploy # Deploy to Docker Compose
aspire do docker-compose-down-dc # Tear down the deployment

Azure Container Apps Example

For Azure, add the Azure Container Apps environment. See the Azure Container Apps sample for a complete working example.

#:package Aspire.Hosting.Azure.AppContainers@13.0.0
#:package Aspire.Hosting.Azure.Storage@13.0.0
#:sdk Aspire.AppHost.Sdk@13.0.0

var builder = DistributedApplication.CreateBuilder(args);

builder.AddAzureContainerAppEnvironment("env");

var storage = builder.AddAzureStorage("storage")
 .RunAsEmulator();

var blobs = storage.AddBlobContainer("images");

builder.AddProject<Projects.Api>("api")
 .WithExternalHttpEndpoints()
 .WithReference(blobs);

builder.Build().Run();

Publishing this generates Bicep templates that you can review, customize, and deploy:

aspire publish -o ./azure-artifacts # Generates Bicep files
aspire deploy # Deploys to Azure Container Apps

Kubernetes Example

For Kubernetes, add the hosting package and configure a compute environment. See the Kubernetes sample for a complete working example.

var builder = DistributedApplication.CreateBuilder(args);

var k8s = builder.AddKubernetesEnvironment("k8s");

var api = builder.AddProject<Projects.Api>("api")
 .WithExternalHttpEndpoints();

builder.Build().Run();

Generate and deploy:

# Generate Kubernetes manifests
aspire publish -o ./k8s-output

# Apply with kubectl or Helm
kubectl apply -f ./k8s-output

Multiple Compute Environments

If you add multiple compute environments, Aspire needs to know which resource goes where. Use WithComputeEnvironment to disambiguate:

var k8s = builder.AddKubernetesEnvironment("k8s-env");
var compose = builder.AddDockerComposeEnvironment("docker-env");

builder.AddProject<Projects.Frontend>("frontend")
 .WithComputeEnvironment(k8s);

builder.AddProject<Projects.Backend>("backend")
 .WithComputeEnvironment(compose);

Without this, Aspire throws an ambiguous environment exception at publish time.

`aspire deploy` - Deploy to a Target

The aspire deploy command resolves parameters and applies published artifacts to a target environment. This command is in preview and under active development.

aspire deploy

Note: The deploy command may change as it matures. Keep an eye on the .NET Blog and the Aspire deployment docs for updates.

What happens depends on your compute environment:

Docker Compose — Builds images, resolves variables, runs docker compose up
Azure Container Apps — Provisions Azure resources, builds and pushes container images, deploys apps
Kubernetes — Generates manifests and applies them

For Docker Compose deployments, the workflow from the official samples is straightforward:

aspire run # Run locally
aspire deploy # Deploy to Docker Compose
aspire do docker-compose-down-dc # Teardown

For Azure deployments, aspire deploy prompts for:

Azure sign-in and subscription selection
Resource group creation or selection
Location for Azure resources

The command then provisions infrastructure, builds containers, pushes to ACR, and deploys — all in one step.

For non-interactive deployment (CI/CD), set these environment variables to skip the prompts:

Azure__SubscriptionId=<your-subscription-id>
Azure__Location=<azure-region>
Azure__ResourceGroup=<resource-group-name>

`aspire do` - Pipeline Automation

The aspire do command executes pipeline steps defined by hosting integrations. Use aspire do diagnostics to discover what steps are available and their dependencies:

# List available pipeline steps
aspire do diagnostics

# Tear down a Docker Compose deployment
aspire do docker-compose-down-dc

# The naming convention is: docker-compose-down-{environment-name}

Well-known pipeline steps include build, push, publish, and deploy. Resources can contribute custom steps — for example, Docker Compose adds teardown steps. This command is particularly useful in CI/CD pipelines and for managing environment lifecycle.

`aspire exec` - Run Commands in Resource Context

The aspire exec command runs commands in the context of a specific resource with the correct connection strings and environment variables. This command is disabled by default — enable it first. See the exec sample for a complete working example with Postgres and Redis.

# Enable the exec feature
aspire config set features.execCommandEnabled true

Then use the --resource (or -r) flag to specify the target:

# Run EF Core migrations
aspire exec --resource mydb -- dotnet ef database update

# Open an interactive shell in a container
aspire exec --resource redis -- redis-cli

# Start a dependency and then run against it
aspire exec --start-resource mydb -- dotnet ef migrations add Init

The --start-resource (or -s) flag is useful when you need to start a resource (and its dependencies) before running a command against it.

Azure Developer CLI (azd) Integration

For production Azure deployments, the Azure Developer CLI (azd) has first-class Aspire support and is the more mature deployment path:

# Initialize azd in your project directory
azd init

# Provision infrastructure and deploy in one command
azd up

During azd init, you’ll:

Select which services to expose to the internet
Name your environment (e.g., dev, prod)
Choose your Azure subscription and location

The azd up command handles the full lifecycle: azd package → azd provision → azd deploy. Projects are packaged into containers, Azure resources are provisioned via Bicep, and containers are pushed to Azure Container Registry and deployed to Container Apps.

Generated files:

azure.yaml — Maps Aspire AppHost services to Azure resources
.azure/config.json — Active environment configuration
.azure/{env}/.env — Environment-specific overrides
.azure/{env}/config.json — Public endpoint configuration

GitHub Actions

Using azd (Recommended for Azure)

name: Deploy Aspire App

on:
 push:
 branches: [main]

jobs:
 deploy:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4

 - name: Setup .NET
 uses: actions/setup-dotnet@v4
 with:
 dotnet-version: '10.0.x'

 - name: Install azd
 uses: Azure/setup-azd@v2

 - name: Log in to Azure
 uses: azure/login@v2
 with:
 creds: ${{ secrets.AZURE_CREDENTIALS }}

 - name: Provision and Deploy
 run: azd up --no-prompt
 env:
 AZURE_ENV_NAME: ${{ vars.AZURE_ENV_NAME }}
 AZURE_LOCATION: ${{ vars.AZURE_LOCATION }}
 AZURE_SUBSCRIPTION_ID: ${{ vars.AZURE_SUBSCRIPTION_ID }}

Using Aspire CLI

name: Deploy with Aspire CLI

on:
 push:
 branches: [main]

jobs:
 deploy:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4

 - name: Setup .NET
 uses: actions/setup-dotnet@v4
 with:
 dotnet-version: '10.0.x'

 - name: Install Aspire CLI
 run: curl -fsSL https://aspire.dev/install.sh | bash

 - name: Publish artifacts
 run: aspire publish -o ./artifacts
 working-directory: ./src/MyApp.AppHost

 - name: Deploy with Docker Compose
 run: |
 cd ./artifacts
 docker compose up --build -d

Legacy Manifest Format

Starting with Aspire 9.2, the single deployment manifest is being phased out in favor of the aspire publish / aspire deploy model with hosting integration extensibility. The legacy manifest is still available for debugging:

aspire do publish-manifest --output-path ./diagnostics

This produces a manifest snapshot for inspecting resource graphs and troubleshooting, but it’s not the primary deployment path.

Learn More

Wrapping Up

The publish/deploy model gives you flexibility: publish generates parameterized artifacts, and deploy resolves values and applies them. Whether you’re targeting Docker Compose for local staging, Kubernetes for container orchestration, or Azure Container Apps for managed hosting, the workflow is consistent.

For production Azure deployments, I recommend azd for its mature infrastructure-as-code capabilities. For Docker Compose and local deployment workflows, aspire deploy is increasingly capable as it matures.

In Part 3, we explore one of Aspire’s most exciting features: MCP (Model Context Protocol) integration, which lets AI coding agents like GitHub Copilot and Claude understand and interact with your running Aspire applications.

Until next time, happy Aspiring!

Migrating from Jekyll to Hugo Part 3: Deployment and Lessons Learned

Sun, 25 Jan 2026 00:00:00 +0000

In the final part of this series, I cover deploying Hugo to GitHub Pages and share the challenges I encountered.

GitHub Actions Workflow

Here’s the workflow I use to deploy Hugo to GitHub Pages:

name: Deploy Hugo site to Pages

on:
 push:
 branches: [main]
 workflow_dispatch:

permissions:
 contents: read

concurrency:
 group: "pages"
 cancel-in-progress: true

jobs:
 build:
 runs-on: ubuntu-latest
 permissions:
 contents: read
 pages: write
 id-token: write
 env:
 HUGO_VERSION: 0.154.5
 steps:
 - name: Checkout
 uses: actions/checkout@8e8c483db84b4bee # v6.0.2
 with:
 fetch-depth: 0
 persist-credentials: false
 submodules: recursive

 - name: Setup Hugo
 uses: peaceiris/actions-hugo@75d2e847 # v3.0.0
 with:
 hugo-version: ${{ env.HUGO_VERSION }}
 extended: true

 - name: Setup Pages
 id: pages
 uses: actions/configure-pages@983d7736 # v5.0.0

 - name: Cache Hugo resources
 uses: actions/cache@8b402f58 # v5.0.3
 with:
 path: |
 ${{ runner.temp }}/hugo_cache
 resources/_gen
 key: hugo-${{ runner.os }}-${{ hashFiles('content/**', 'config/**', 'assets/**') }}
 restore-keys: |
 hugo-${{ runner.os }}-

 - name: Build with Hugo
 env:
 HUGO_CACHEDIR: ${{ runner.temp }}/hugo_cache
 HUGO_ENVIRONMENT: production
 TZ: America/New_York
 run: |
 hugo \
 --gc \
 --minify \
 --baseURL "${{ steps.pages.outputs.base_url }}/"

 - name: Upload artifact
 uses: actions/upload-pages-artifact@7b1f4a76 # v4.0.0
 with:
 path: ./public

 deploy:
 needs: build
 runs-on: ubuntu-latest
 permissions:
 pages: write
 id-token: write
 environment:
 name: github-pages
 url: ${{ steps.deployment.outputs.page_url }}
 steps:
 - name: Deploy to GitHub Pages
 id: deployment
 uses: actions/deploy-pages@d6db9016 # v4.0.5

Key points:

SHA-pinned actions - Every action is pinned to a commit SHA, not a mutable tag — critical for supply chain security
Scoped permissions - Minimal permissions declared per-job, not at the workflow level
submodules: recursive - Required for the theme submodule
fetch-depth: 0 - Needed for .GitInfo and .Lastmod
persist-credentials: false - Security best practice for checkout
Pinned Hugo version - HUGO_VERSION env var ensures reproducible builds
Caching - Both hugo_cache and resources/_gen are cached to speed up builds
--gc --minify - Clean up unused cache entries and optimize output

Linting with Super-Linter

In addition to the deploy workflow, I added a Super-Linter workflow that runs on every PR:

name: Super-Linter

on:
 pull_request: null

concurrency:
 group: ${{ github.workflow }}-${{ github.ref }}
 cancel-in-progress: true

jobs:
 build:
 name: Lint
 runs-on: ubuntu-latest
 permissions:
 contents: read
 packages: read
 statuses: write
 steps:
 - name: Checkout code
 uses: actions/checkout@8e8c483db84b4bee # v6.0.1
 with:
 fetch-depth: 0
 persist-credentials: false

 - name: Super-linter
 uses: super-linter/super-linter@d5b0a2ab # v8.3.2
 env:
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 VALIDATE_ALL_CODEBASE: 'false'
 # Auto-fix formatting on PR
 FIX_CSS_PRETTIER: 'true'
 FIX_HTML_PRETTIER: 'true'
 FIX_JSON_PRETTIER: 'true'
 FIX_MARKDOWN_PRETTIER: 'true'
 FIX_YAML_PRETTIER: 'true'
 # Disable linters that don't apply
 VALIDATE_JSCPD: 'false'
 VALIDATE_PYTHON: 'false'
 # Use repo markdownlint config
 MARKDOWN_CONFIG_FILE: '.markdownlint.yml'
 # Don't lint the theme submodule
 FILTER_REGEX_EXCLUDE: 'themes/.*'

This catches markdown issues, YAML errors, and formatting problems before they hit main. The FIX_* options automatically commit formatting corrections back to the PR branch, which saves a lot of manual cleanup. I exclude the themes/ directory since that’s third-party code.

I also keep linting config files in the repo root:

.markdownlint.yml - Disables rules like MD013 (line length) and MD033 (inline HTML — needed for Hugo shortcodes)
.yaml-lint.yml - Warns on formatting issues without blocking
.textlintrc - Terminology checks
.eslintrc.yml - JavaScript linting for any custom scripts

Challenges and Solutions

Challenge 1: Preserving URLs

Jekyll and Hugo generate different URL structures. To avoid breaking existing links, I used Hugo aliases:

# In front matter
aliases:
 - /category/development/my-old-post-url/

For bulk redirects, I created static/_redirects for Netlify-style redirects (works with some hosts).

Challenge 2: Theme Version Compatibility

I hit this warning early on:

WARN Module "blowfish" is not compatible with this Hugo version

Solution: Pin both Hugo and theme versions:

# In GitHub Actions
env:
 HUGO_VERSION: 0.154.5

# Pin theme to specific tag
cd themes/blowfish
git checkout v2.97.0

Challenge 3: Date Formatting

Hugo uses Go’s reference time format. This tripped me up — Go doesn’t use YYYY-MM-DD style format strings. Instead, it uses a specific reference time:

Go reference time: Mon Jan 2 15:04:05 MST 2006

So in Hugo templates, you format dates like this:

{{/* Long date */}}
{{ .Date.Format "January 2, 2006" }}
{{/* Output: January 25, 2026 */}}

{{/* ISO date */}}
{{ .Date.Format "2006-01-02" }}
{{/* Output: 2026-01-25 */}}

{{/* With time */}}
{{ .Date.Format "Jan 2, 2006 3:04 PM" }}
{{/* Output: Jan 25, 2026 12:00 AM */}}

The magic is that every component of the format is a specific number: month=1, day=2, hour=3, minute=4, second=5, year=6, timezone=7 (MST). Once you internalize that, it clicks.

Challenge 4: Custom Layouts

Some Jekyll layouts needed recreation. Hugo’s template lookup order:

layouts/<type>/<layout>.html
layouts/_default/<layout>.html
Theme equivalents

I started by copying theme layouts to my layouts/ folder and customizing.

Challenge 5: Split Config Files

Hugo supports splitting configuration across multiple files. Rather than one monolithic config.toml, I use a config/_default/ directory:

config/_default/
├── hugo.toml # Core site settings
├── languages.en.toml
├── markup.toml # Goldmark, syntax highlighting
├── menus.en.toml
├── module.toml
└── params.toml # Theme parameters

This keeps things organized — especially as Blowfish has many configurable params. One thing that helped: setting buildFuture = true in hugo.toml so scheduled posts show up locally during development.

Challenge 6: RSS Feed URLs

Jekyll’s feed was at /feed.xml, but Hugo defaults to /index.xml. To avoid breaking existing subscribers, I configured Hugo to output both:

# hugo.toml
[outputs]
 home = ["HTML", "RSS", "FEED", "JSON"]

# Legacy feed.xml for backward compatibility with Jekyll
[outputFormats.FEED]
 mediaType = "application/rss+xml"
 baseName = "feed"

The custom FEED output format needs a matching template, so I copied the theme’s rss.xml into my layouts:

cp themes/blowfish/layouts/_default/rss.xml layouts/_default/feed.xml

Now both /index.xml and /feed.xml are generated — existing subscribers keep working, and Hugo’s default feed works too.

Tips for Your Migration

Start fresh - Create new Hugo site, don’t convert in place
Migrate incrementally - Move posts in batches, test as you go
Use hugo server -D - Shows drafts with hot reload
Read theme docs - Blowfish has excellent documentation
Test all pages - Especially taxonomy and archive pages
Check mobile - Verify responsive design works
Validate feeds - Test RSS/Atom with a feed reader

Before and After

Metric	Jekyll	Hugo
Build time	30+ seconds	< 1 second
Dependencies	Ruby, Bundler, gems	Single binary
Hot reload	Slow	Instant
Theme options	Limited	Extensive

Conclusion

The migration took a weekend of focused work, but it was absolutely worth it. Hugo’s speed and flexibility have made maintaining this blog much more enjoyable.

The key is taking it step by step:

Set up Hugo with your chosen theme
Migrate content in batches
Fix shortcodes and assets
Set up deployment
Test thoroughly before switching DNS

If you’re considering the switch, I hope this series helps. Feel free to reach out with questions!

Resources

Migrating from Jekyll to Hugo Part 2: Content Migration

Sun, 18 Jan 2026 00:00:00 +0000

In Part 1, I covered why I switched from Jekyll to Hugo. Now let’s dive into the actual content migration.

Front Matter Conversion

Most Jekyll posts work with minimal changes, but there are key differences:

# Jekyll
---
layout: post
title: "My Post"
date: 2024-01-15
categories: development
tags: [docker, containers]
mermaid: true
---

# Hugo
---
title: "My Post"
date: 2024-01-15
categories:
 - Development
tags:
 - Docker
 - Containers
---

Key changes I made:

Removed layout: post - Hugo infers layout from content location
Converted tags/categories to arrays - YAML list format
Standardized capitalization - Consistent taxonomy naming
Removed mermaid: true - Blowfish auto-detects mermaid shortcodes

Tip: Run hugo server while migrating so you can preview each converted post immediately and catch front matter issues early.

Shortcode Conversions

Jekyll uses Liquid templates while Hugo has its own shortcode system.

Images and Figures

<!-- Jekyll -->
{% include figure.html src="/images/photo.jpg" caption="My caption" %}

<!-- Hugo -->
{{< figure src="/images/photo.jpg" caption="My caption" >}}

Here’s the Hugo figure shortcode in action:

The Hugo logo rendered with the figure shortcode

Mermaid Diagrams

This was a bigger change. Jekyll with the mermaid plugin uses fenced code blocks:

<!-- Jekyll -->
```mermaid
graph TD
 A --> B
```

Hugo with Blowfish requires the mermaid shortcode:

<!-- Hugo -->
{{< mermaid >}}
graph TD
 A --> B
{{< /mermaid >}}

I wrote a quick script to find and convert these across all posts. Here’s what a real mermaid diagram looks like after migration:

flowchart LR
 A["Jekyll Post\n(.md + Liquid)"] -->|migrate| B["Hugo Post\n(.md + Shortcodes)"]
 B --> C{"hugo build"}
 C --> D["Static HTML"]
 C --> E["Processed Images"]
 C --> F["Minified CSS/JS"]

Code Blocks

Standard fenced code blocks work the same, but Hugo adds features:

<!-- Hugo with line numbers -->
{{< highlight go "linenos=table,hl_lines=3" >}}
func main() {
 fmt.Println("Hello")
 fmt.Println("Highlighted!")
}
{{< /highlight >}}

Here’s what that looks like rendered with Hugo’s syntax highlighting and line numbers:

1
2
3
4


func main() {
 fmt.Println("Hello")
 fmt.Println("Highlighted!")
}

Static Assets

Jekyll and Hugo organize assets differently:

Jekyll	Hugo
`assets/images/`	`static/images/`
`_data/`	`data/`
`_includes/`	`layouts/partials/`

For images referenced in posts, I kept paths like /images/photo.jpg which maps to static/images/photo.jpg.

Watch out: Hugo’s assets/ folder is for files processed by Hugo Pipes (SCSS, image resizing, fingerprinting). Use static/ for files served as-is. Mixing them up leads to 404s.

Handling Excerpts

Jekyll uses excerpt_separator in config or  in posts. Hugo works the same way with :

---
title: "My Post"
---

This appears in the summary.

<!--more-->

This is the full content.

Taxonomy Cleanup

I took the opportunity to consolidate tags:

Merged similar tags (vscode → VSCode)
Standardized capitalization
Removed unused categories

Bulk Migration Script

“The best migration is the one you automate. Don’t hand-edit 60 posts when a script can do it in seconds.”

For 60+ posts, I used a simple PowerShell script:

Get-ChildItem "content/posts/*.md" | ForEach-Object {
 $content = Get-Content $_.FullName -Raw
 
 # Remove layout: post
 $content = $content -replace "layout: post\r?\n", ""
 
 # Remove mermaid: true
 $content = $content -replace "mermaid: true\r?\n", ""
 
 Set-Content $_.FullName $content
}

Note: The PowerShell script above covers the basics, but you may need additional passes for things like Liquid {% raw %} blocks or custom Jekyll includes. Test thoroughly!

What’s Next

In Part 3, I’ll cover deployment with GitHub Actions and the challenges I encountered along the way.

Resources

Migrating from Jekyll to Hugo Part 1: Why I Made the Switch

Sun, 11 Jan 2026 00:00:00 +0000

After years of running this blog on Jekyll, I finally made the switch to Hugo. Here’s why.

Why I Made the Switch

Static site generators have evolved a lot since Jekyll first popularized the idea of building blogs from Markdown. Jekyll served me well for a long time, but as my site grew and my workflow matured, a few pain points became impossible to ignore:

Build times: As my site grew, Jekyll builds slowed to a crawl. Waiting 30+ seconds for a rebuild made local development feel sluggish.
Ruby dependencies: Managing Ruby versions, gems, and Bundler across machines and CI environments was a recurring frustration.
Theme flexibility: I wanted a more modern design system, better dark mode support, and a theme ecosystem that felt alive.

Hugo promised faster builds, a single binary with no external dependencies, and a more modern templating system. Once I started experimenting, the difference was immediate.

Why Hugo Is a Better Fit

Fast builds

Hugo compiles entire sites in milliseconds, and the dev server hot reload feels instant. That alone dramatically improves the writing and editing experience.

No dependency headaches

Hugo is just one binary. No Ruby, no Bundler, no gem conflicts, no version juggling. It works the same on every machine and every CI pipeline.

A more powerful templating system

Hugo’s Go-based templating is far more flexible than Liquid. It supports:

Rich built-in functions
Complex content structures
Custom taxonomies
Shortcodes
Image processing
Multilingual content

Many things that require plugins in Jekyll are built directly into Hugo.

A modern ecosystem

Hugo’s theme community is active, innovative, and built around modern tooling. This is where Blowfish really shines.

Choosing a Theme

I settled on the Blowfish theme for several reasons. Honestly, it is one of the best examples of what Hugo makes possible.

Clean, modern design

Blowfish looks great out of the box, with thoughtful typography, spacing, and layout options.

Dark mode support

Automatic dark and light mode, user-selectable themes, and customizable color palettes are all built in.

Feature-rich components

Blowfish includes components like:

Callouts
Cards
Tabs
Accordions
Grids
Footnotes
Copy-to-clipboard code blocks

These let you build richer content without custom HTML.

Built-in image optimization

Thanks to Hugo’s image pipeline, Blowfish can automatically resize, crop, optimize, lazy-load, and serve responsive images. This is something Jekyll cannot match without external tooling.

Taxonomies and structure

Categories, tags, sections, menus, and breadcrumbs work cleanly and consistently.

Active development and documentation

Blowfish is well maintained, well documented, and constantly improving.

Tailwind CSS for customization

If you want to tweak the design, Tailwind makes it straightforward.

Jekyll vs. Hugo (with Blowfish): A Practical Comparison

Feature / Area	Jekyll	Hugo (with Blowfish)
Build Speed	Slow on larger sites; rebuilds often 20-60 seconds	Extremely fast; rebuilds typically under 1 second
Dependencies	Requires Ruby, Bundler, gems, and version management	Single binary, no external dependencies
Templating System	Liquid (simple but limited)	Go templates (powerful, flexible, feature-rich)
Image Processing	Not built in; requires external tools or plugins	Native image pipeline: resize, crop, optimize, responsive images
Theme Ecosystem	Many themes, but many feel dated or unmaintained	Modern themes with active development; Blowfish is a standout
Dark Mode Support	Theme-dependent; often limited	Built-in automatic dark/light mode plus user theme switching
Content Components	Limited; requires plugins or custom HTML	Blowfish includes cards, callouts, tabs, accordions, grids, and more
Search	Requires external JS libraries or plugins	Blowfish includes fast, built-in client-side search
Multilingual Support	Plugin-based, inconsistent	First-class multilingual support built into Hugo
Taxonomies	Basic categories/tags	Flexible taxonomies, sections, menus, breadcrumbs
Asset Pipeline	Basic; often requires plugins	Built-in minification, fingerprinting, and processing
Customization	Varies by theme; often requires manual CSS	Blowfish uses Tailwind for easy, modern customization
Documentation	Good but plugin-heavy	Excellent docs; Blowfish has strong theme documentation
Local Development	Slower reloads; can feel laggy	Instant hot reload; smooth editing experience
CI/CD	Slower builds; Ruby setup required	Fast builds; no setup beyond Hugo binary
Learning Curve	Easy to start, harder to extend	Easy to start, powerful as you grow

Results

After migrating, a few wins stood out:

Build time: Dropped from 30+ seconds to under 1 second
No dependencies: Just the Hugo binary, nothing else
Better DX: Hot reload is nearly instant
Modern design: Blowfish looks great on all devices
More flexibility: Shortcodes, components, and image processing make content creation easier

Overall, the site feels faster, cleaner, and more maintainable.

What’s Next

In Part 2, I’ll cover the actual migration process:

Converting posts
Fixing front matter
Replacing Jekyll shortcodes
Handling images and static assets
Structuring content for Hugo’s taxonomy system

If you’re considering making the switch yourself, the migration is easier than you might think.

Resources

Getting Started with the Aspire CLI - A Complete Guide

Thu, 11 Dec 2025 00:00:00 +0000

This blog was posted as part of the C# Advent Calendar 2025. Make sure to check out everyone else’s work when you’re done here

The Aspire CLI is a cross-platform tool for creating, managing, and running polyglot Aspire projects. This post covers the core commands you’ll use day-to-day.

What is Aspire?

Aspire is an opinionated, cloud-ready stack for building observable distributed applications. Think: a C# AppHost that models your topology, plus integrations and tooling.

Polyglot by Design

While Aspire started in the .NET ecosystem, Aspire 13.0 made Python and JavaScript first-class citizens.

.NET projects - ASP.NET Core APIs, Blazor apps, Worker Services, Azure Functions
Python applications - Flask, FastAPI, Django, or any Python script
JavaScript/Node.js apps - Express, Next.js, or any Node.js application
Containers - Any Docker image you need

The AppHost (orchestrator) is written in C#, but it can coordinate services written in any language.

That said, .NET remains the sweet spot for Aspire because you get the richest integration and tooling.

The Problem Aspire Solves

Coordinating multiple services usually means lots of config, hardcoded URLs, and fragile startup order. Aspire helps by giving you:

Orchestration - Model resources and dependencies in code
Integrations - Standard components for common infrastructure
Tooling - A dashboard + CLI to run and debug the system

Dashboards and Telemetry

Aspire includes a local dashboard that helps you understand what’s running: resource status, endpoints, logs, traces, and metrics.

Telemetry is typically emitted via OpenTelemetry (the ServiceDefaults project wires a lot of this up for .NET services). By default this is a local developer experience. Data only goes to an external backend if you configure an exporter to send it there.

The AppHost: Your Application’s Control Plane

At the heart of every Aspire application is the AppHost. It defines resources and dependencies (and can include health checks and external endpoints).

var builder = DistributedApplication.CreateBuilder(args);

// TODO: Add resources here

builder.Build().Run();

ServiceDefaults: Shared Configuration

The ServiceDefaults project is a shared library for observability and resilience (health checks, OpenTelemetry, logging, etc.).

Each service references ServiceDefaults and calls two methods:

var builder = WebApplication.CreateBuilder(args);
builder.AddServiceDefaults();

var app = builder.Build();
app.MapDefaultEndpoints();
app.Run();

This ensures consistent observability across all services without duplicating configuration.

Aspire vs Docker Compose

If you’re currently using Docker Compose, here’s the mental model shift.

Docker Compose:

services:
 postgres:
 image: postgres:latest

 api:
 build: ./api
 depends_on:
 - postgres

 web:
 build: ./web
 depends_on:
 - api

Aspire equivalent:

var builder = DistributedApplication.CreateBuilder(args);

var postgres = builder.AddPostgres("postgres")
 .AddDatabase("mydb");

var api = builder.AddProject<Projects.Api>("api")
 .WithReference(postgres);

var web = builder.AddProject<Projects.Web>("web")
 .WithReference(api)
 .WaitFor(api);

builder.Build().Run();

Why Aspire often feels better:

Less config glue - Model topology in code
Service discovery by default - Fewer hardcoded URLs
Built-in dashboard - Logs, traces, and metrics in one place
Integrations - Common infra with sensible defaults
Polyglot - C#, Python, JavaScript, containers

Why the Aspire CLI?

The Aspire CLI helps you scaffold, run, and evolve an Aspire application without a pile of scripts and config.

What you’ll use it for:

Create or Aspireify a solution
Run the apphost and open the dashboard
Add integrations and keep packages current

Key takeaways:

aspire new for greenfield projects with full scaffolding
aspire init to add Aspire to existing solutions incrementally
aspire run for development with the built-in dashboard
aspire add to easily integrate databases, caches, and queues
aspire update to keep packages current

Prerequisites

Before installing the Aspire CLI, ensure you have the following:

Requirement	Details
.NET 8+ SDK	Required for Aspire 13.0+. Run `dotnet --info` to verify. The CLI needs the SDK even if your apps target .NET 8 or 9.
Editor/IDE	Visual Studio Code with C# Dev Kit and Aspire extensions, Visual Studio 2022 17.13+, or JetBrains Rider.
Optional	GitHub Codespaces or Dev Containers for cloud-based development.

Installing the Aspire CLI

The install scripts download the CLI and add it to your PATH.

Platform	Install command
Windows (PowerShell)	`irm https://aspire.dev/install.ps1 \| iex`
macOS and Linux (Bash)	`curl -fsSL https://aspire.dev/install.sh \| bash`

If aspire isn’t found, open a new terminal and try again.

Core CLI Commands

The Aspire CLI provides several commands for different stages of the development lifecycle. Here’s a practical rundown of the core commands.

`aspire new` - Create a New Solution

Use aspire new for greenfield projects.

Basic usage:

# Interactive mode - prompts for template, name, and output
aspire new

# Non-interactive with explicit options
aspire new aspire-starter -n AspireApp -o AspireApp

What gets created:

AspireApp/
├── AspireApp.sln
├── AspireApp.AppHost/ # Dev-time orchestrator
│ ├── AppHost.cs
│ └── AspireApp.AppHost.csproj
├── AspireApp.ServiceDefaults/ # Shared configuration
│ ├── Extensions.cs
│ └── AspireApp.ServiceDefaults.csproj
├── AspireApp.ApiService/ # Mock weather data API
│ ├── Program.cs
│ └── AspireApp.ApiService.csproj
└── AspireApp.Web/ # Blazor frontend
 ├── Program.cs
 └── AspireApp.Web.csproj

You get an AppHost, ServiceDefaults, and a small starter app you can run immediately.

`aspire init` - Add Aspire to Existing Apps

Already have a codebase? aspire init adds an AppHost so you can orchestrate what you already have (including Python and JavaScript).

# Navigate to your solution directory
cd /path/to/your-solution

# Initialize Aspire support
aspire init

The command runs in interactive mode and will create apphost.cs plus minimal run configuration.

After running aspire init:

Your project root gets a file-based AppHost:

my-saas-app/
 apphost.cs # (new) orchestration code
 apphost.run.json # (new) local run configuration
 api/
 main.py
 pyproject.toml
 frontend/
 app.py
 requirements.txt
 worker/
 worker.py
 requirements.txt

The initial apphost.cs is minimal:

#:sdk Aspire.AppHost.Sdk@13.0.0

var builder = DistributedApplication.CreateBuilder(args);

// TODO: Add resources here

builder.Build().Run();

Example: reference a Python API from a Python worker

If you’re orchestrating Python services, add the Python hosting integration to your AppHost:

aspire add python

Then wire resources in the AppHost using AddUvicornApp (for FastAPI, Flask, and other ASGI apps) and AddPythonApp for a worker. WithReference(...) declares the dependency and Aspire injects the connection info as environment variables.

var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddUvicornApp("api", "./api", "main:app")
 .WithUv()
 .WithHttpHealthCheck("/health");

var worker = builder.AddPythonApp("worker", "./worker", "worker.py")
 .WithUv()
 .WithReference(api); // Worker gets API_HTTP and API_HTTPS env vars

builder.Build().Run();

`aspire new` vs `aspire init`

Scenario	Command	Why
Starting fresh with a new project	`aspire new`	Scaffolds everything: solution, AppHost, ServiceDefaults, sample projects
Adding Aspire to existing code	`aspire init`	Preserves your existing projects, adds only orchestration layer
Polyglot app (C#, Python, JS)	`aspire init`	Works with existing multi-language repos
Learning Aspire	`aspire new`	Get a working example immediately

`aspire run` - Run the Distributed App

aspire run builds and starts your resources and opens the dashboard.

# From your solution directory
aspire run

What happens:

Finds the AppHost
Builds and starts resources
Prints the dashboard URL

Example output:

Dashboard: https://localhost:17068/login?t=ea559845d54cea66b837dc0ff33c3bd3
Logs: ~/.aspire/cli/logs/apphost-13024-2025-10-31-19-40-58.log

A note on the dashboard and telemetry

The dashboard is where you’ll see status, logs, traces, and metrics for the running app.

`aspire add` - Add Integrations

aspire add adds official integration packages to your AppHost.

# Interactive mode - shows list of available integrations
aspire add

# Add a specific integration by name
aspire add redis

After adding an integration, wire it in your AppHost:

var builder = DistributedApplication.CreateBuilder(args);

// Add Redis resource
var cache = builder.AddRedis("cache");

// Share Redis with your API
var api = builder.AddProject<Projects.YourApi>("api")
 .WithReference(cache)
 .WithHttpHealthCheck("/health");

builder.Build().Run();

Then add the client library to your consuming project:

dotnet add YourApi package Aspire.StackExchange.Redis

Then configure the client in your service (for example, builder.AddRedisClient("cache")).

`aspire update` - Update Packages and Templates

The aspire update command keeps your Aspire projects current by detecting and updating outdated packages and templates.

aspire update

If you want to update the CLI itself (instead of just your solution packages), use:

aspire update --self

Practical Workflow

Here’s a typical workflow for a new project:

# 1. Create a new solution
aspire new

# 2. Run it
aspire run

# 3. Add an integration
aspire add redis

# 4. Update packages (and optionally the CLI)
aspire update
aspire update --self

Learn More

Wrapping Up

There is too much to cover here, so check out the follow-up posts on deployment and AI-assisted development:

Part 2 - Deployment and Pipelines — aspire publish, aspire deploy, and CI/CD with GitHub Actions
Part 3 - MCP for AI Coding Agents — Connect AI assistants to your running Aspire applications

Until next time, happy Aspiring!

Building a Flexible AI Provider Strategy in .NET Aspire

Sun, 06 Jul 2025 00:00:00 +0000

How I architected a single codebase to seamlessly switch between Azure OpenAI, GitHub Models, Ollama, and Foundry Local without touching the API service

When building my latest .NET Aspire application, I faced a common challenge: how do you develop and test with different AI providers without constantly rewriting your API service? The answer turned out to be surprisingly elegant - a configuration-driven approach that lets you switch between four different AI providers with zero code changes.

The Problem: A Wide Variety of AI Choices

Modern AI development presents us with a wide variety of options. You might want to:

Develop locally with Ollama for offline work
Prototype quickly with Microsoft’s Foundry Local
Test cheaply with GitHub Models’ free tier
Deploy to production with Azure OpenAI’s enterprise features

The traditional approach would be to write separate implementations for each provider, but that leads to code duplication and maintenance headaches. Instead, I built a system that treats AI providers as interchangeable services.

The Solution: Configuration-Driven Architecture

The key insight was to abstract the AI provider selection entirely out of the API service. Here’s how it works:

{
 "AI": {
 "Provider": "foundrylocal",
 "DeploymentName": "chat",
 "Model": "phi-3.5-mini"
 }
}

That’s it. Change a few lines in your configuration, or swap configurations/environments and your entire application switches AI providers. The result is a seamless transition with no code changes, recompilation, or deployment complexities.

The Four Pillars of AI Provider Flexibility

Provider	Best Use Case	Free Tier	Hardware Needs	Deployment
Azure OpenAI	Production workloads	No	N/A (Cloud)	Cloud
GitHub Models	Prototyping & Testing	Yes (Generous)	N/A (Cloud)	Cloud
Ollama	Offline & Local Dev	Yes	Local CPU/GPU	Local
Foundry Local	Offline High-Perf Local Dev	Yes	Local CPU/GPU	Local

1. Azure OpenAI - The Enterprise Choice

Azure OpenAI is my go-to for production workloads. It’s reliable, scalable, and integrates seamlessly with Azure’s ecosystem:

{
 "AI": {
 "Provider": "azureopenai",
 "Model": "gpt-4o"
 }
}

Why I choose Azure OpenAI for production:

Enterprise SLAs and support
Built-in compliance and security features
Seamless integration with Azure services
Predictable pricing and billing

2. GitHub Models - The Developer’s Friend

GitHub Models surprised me with its generous free tier and extensive model catalog. Based on community feedback and my own testing, it’s proven reliable for development and staging environments.

{
 "AI": {
 "Provider": "githubmodels",
 "Model": "gpt-4o-mini"
 }
}

Perfect for:

Early development and prototyping
Testing different models without cost commitment
Open source projects with budget constraints
Experimenting with cutting-edge models

3. Ollama - The Privacy Champion

For local development and sensitive workloads, Ollama can’t be beat:

{
 "AI": {
 "Provider": "ollama",
 "Model": "llama3.2"
 }
}

When I reach for Ollama:

Working on airplanes or in poor connectivity
Handling sensitive data that can’t leave the premises
Developing features without API costs
Testing with models that aren’t available elsewhere

Mac Performance Note: If you’re on Apple Silicon, avoid running Ollama in Docker containers. Docker on Mac cannot access the Metal GPU due to Apple’s virtualization framework limitations. Instead, install Ollama natively on macOS to take advantage of Metal GPU acceleration. This gives you significantly better performance compared to CPU-only Docker containers. The CommunityToolkit’s Ollama Integration defaults to docker, though you can use a connection string to point it to a native Ollama installation.

4. Foundry Local - The Microsoft Stack Choice

Microsoft’s Foundry Local offers the best of both worlds - local deployment with enterprise-grade models:

{
 "AI": {
 "Provider": "foundrylocal",
 "Model": "phi-3.5-mini"
 }
}

Foundry Local shines when:

Local deployment is required but you want recent models
You’re already invested in the Microsoft AI ecosystem
You want to leverage hardware acceleration on your machine

My Personal Favorite: After testing all four providers extensively, Foundry Local running on-device has become my go-to choice for local AI development. Unlike Ollama in Docker, Foundry Local takes full advantage of your hardware - whether that’s Apple Silicon’s Metal GPU, NVIDIA cards, or CPU optimization. The performance is consistently excellent, and it handles the complexity of hardware acceleration automatically.

The Architecture Behind the Magic

The beauty of this approach lies in its simplicity. The API service never knows which AI provider it’s using-it just calls the abstracted AI service interface. This is all made possible by the Microsoft.Extensions.AI library, which provides the core IChatClient abstraction. The complete source code for this project is available on my GitHub.

%%{init: {'theme': 'default'}}%%
graph TD
 subgraph title[Configuration-Driven AI Provider Architecture]
 A[appsettings.json] --> B{AI Provider Config};
 B --> C{AddAIServices};
 C --> D{IChatClient};
 subgraph API Service
 D --> E[Your Service Code];
 end
 subgraph Provider Implementations
 C --> F[AzureOpenAIClient];
 C --> G[OllamaApiClient];
 C --> H[GitHubModels Client];
 C --> I[FoundryLocal Client];
 end
 end

Here’s how I structured it.

The Secret Sauce: Configuration-Driven Service Registration

The magic happens in the AIServiceExtensions.cs file. A single call in Program.cs kicks everything off:

// In your Program.cs
var builder = WebApplication.CreateBuilder(args);

// This one line does it all
builder.AddAIServices();

The AddAIServices extension method reads the configuration and registers the correct IChatClient implementation. At its heart is a simple switch statement that delegates to a specific registration method for each provider:

public static IHostApplicationBuilder AddAIServices(this IHostApplicationBuilder builder)
{
 var aiSettings = AIConfiguration.GetSettings(builder.Configuration);
 builder.Services.AddSingleton(aiSettings);

 switch (aiSettings.Provider)
 {
 case AIProvider.Ollama:
 builder.AddOllamaAIServices(aiSettings);
 break;
 case AIProvider.AzureOpenAI:
 builder.AddAzureOpenAIServices(aiSettings);
 break;
 case AIProvider.GitHubModels:
 builder.AddGitHubModelsAIServices(aiSettings);
 break;
 case AIProvider.FoundryLocal:
 builder.AddFoundryLocalAIServices(aiSettings);
 break;
 default:
 throw new InvalidOperationException($"Unsupported AI provider: {aiSettings.Provider}");
 }
 return builder;
}

Provider-Specific Implementations

Each provider has a slightly different setup.

Azure OpenAI and Ollama

For Azure OpenAI and Ollama, the setup is straightforward thanks to .NET Aspire’s built-in support. A single line is enough to register the client:

private static void AddAzureOpenAIServices(this IHostApplicationBuilder builder, AISettings aiSettings)
{
 builder.AddAzureOpenAIClient("ai-service")
 .AddChatClient(aiSettings.DeploymentName);
}

private static void AddOllamaAIServices(this IHostApplicationBuilder builder, AISettings aiSettings)
{
 builder.AddOllamaApiClient(aiSettings.DeploymentName)
 .AddChatClient();
}

GitHub Models and Foundry Local

GitHub Models and Foundry Local require a bit more manual configuration. They both use the standard OpenAIClient but pointed at different endpoints.

For GitHub Models, we create an OpenAIClient pointing to the models.inference.ai.azure.com endpoint:

private static void AddGitHubModelsAIServices(this IHostApplicationBuilder builder, AISettings aiSettings)
{
 var githubToken = builder.Configuration["GITHUB_TOKEN"] ??
 builder.Configuration["ConnectionStrings:GitHubModels"];

 builder.Services.AddSingleton<IChatClient>(serviceProvider =>
 {
 var openAIClient = new OpenAIClient(
 new System.ClientModel.ApiKeyCredential(githubToken),
 new OpenAIClientOptions { Endpoint = new Uri("https://models.inference.ai.azure.com") }
 );
 return openAIClient.GetChatClient(aiSettings.Model).AsIChatClient();
 });
}

For Foundry Local, the code first starts the local model server using FoundryLocalManager and then creates an OpenAIClient that points to the local endpoint it provides.

private static void AddFoundryLocalAIServices(this IHostApplicationBuilder builder, AIConfiguration.AISettings aiSettings)
{
 builder.Services.AddSingleton<IChatClient>(serviceProvider =>
 {
 var manager = FoundryLocalManager.StartModelAsync(aliasOrModelId: aiSettings.Model).GetAwaiter().GetResult();
 var modelInfo = manager.GetModelInfoAsync(aliasOrModelId: aiSettings.Model).GetAwaiter().GetResult();

 var openAIClient = new OpenAIClient(
 new System.ClientModel.ApiKeyCredential(manager.ApiKey),
 new OpenAIClientOptions { Endpoint = manager.Endpoint }
 );
 return openAIClient.GetChatClient(modelInfo?.ModelId ?? aiSettings.Model).AsIChatClient();
 });
}

Your API service code remains blissfully unaware of this complexity. It simply requests an IChatClient and starts making calls, confident that the correct provider is handling the request.

Real-World Switching Techniques

Technique 1: Environment-Based Switching

My favorite approach is to use environment-specific configuration files:

// appsettings.Development.json
{
 "AI": {
 "Provider": "foundrylocal",
 "Model": "phi-3.5-mini"
 }
}

// appsettings.Production.json
{
 "AI": {
 "Provider": "azureopenai",
 "Model": "gpt-4o"
 }
}

This means developers get fast, local AI by default, while production gets the reliability of Azure OpenAI.

Technique 2: Feature Flag-Style Switching

Want to test a new provider with just a subset of users? Environment variables make this trivial:

# Test GitHub Models for 10% of traffic
export AI__Provider="githubmodels"
export AI__Model="gpt-4o-mini"

Technique 3: Command-Line Override

Perfect for debugging or one-off tests:

dotnet run --project src/BuildWithAspire.AppHost -- --AI:Provider=ollama --AI:Model=llama3.2

Building for Resilience: Error Handling and Health Checks

A flexible provider strategy also requires robust error handling. What happens if your primary provider goes down or a local model crashes?

I recommend implementing a few key patterns:

Health Checks: Use .NET Aspire’s health check features to monitor the status of your AI provider endpoints. This allows you to detect failures quickly and potentially route traffic away from an unhealthy provider.
Retry Policies: Implement a retry policy (e.g., with Polly) to handle transient network issues.
Fallback Strategy: For critical applications, consider a fallback mechanism. If a request to your primary provider fails, you could automatically retry with a secondary provider. This can be implemented within a custom IChatClient wrapper.

These strategies ensure your application remains resilient, even when individual components fail.

Lessons Learned from Production

What Works Well

GitHub Models exceeded my expectations. The free tier is generous, and the model selection is impressive. I’ve been using it for all my development work, and it’s become my go-to for prototyping.

Ollama is fantastic for air-gapped environments. When I need to demo on a flight or work with sensitive data, Ollama ensures I’m never blocked by connectivity issues.

Foundry Local surprised me with its performance. While I haven’t run formal benchmarks, my experience shows that first-token response times are significantly faster with Foundry Local on my machine compared to cloud-based providers. It’s become my default choice for local AI development.

What Caught Me Off Guard

Token usage varies dramatically between providers. The same conversation might cost 10x more on one provider than another. I learned to monitor token usage carefully, especially when switching between providers.

Model behavior isn’t always consistent. GPT-4o on Azure OpenAI behaves slightly differently than on GitHub Models. It’s not a problem, but it’s worth testing your specific use cases when switching.

Local providers need warm-up time. Ollama and Foundry Local can take a few seconds to respond to the first request after being idle. I added a simple warm-up call during application startup.

Mac users, beware the Docker trap. I learned this the hard way: running Ollama in Docker on Apple Silicon is painfully slow because Docker can’t access the Metal GPU. Apple’s virtualization framework blocks GPU exposure to containers, so you get CPU-only performance. The solution? Run Ollama natively or use Foundry Local on macOS for Metal acceleration.

The Cost-Optimization Strategy

Here’s how I use different providers throughout my development lifecycle:

Development: Foundry Local or Ollama (free, fast iteration)
Testing: GitHub Models (free tier covers most testing needs)
Staging: GitHub Models or Azure OpenAI (depending on expected load)
Production: Azure OpenAI (enterprise features, SLAs)

This approach has cut my AI development costs by roughly 80% while maintaining flexibility.

The One-Line Provider Switch

The most satisfying part of this architecture is how easy it is to switch providers. Whether you’re responding to a service outage, testing a new model, or optimizing costs, it’s always just a simple configuration change or command line override.

No code changes. No redeployment. Just a quick update and restart.

A Note on Versioning

The AI landscape is evolving rapidly. For this project, I used .NET 9 with .NET Aspire 9.3. If you’re implementing a similar solution, be sure to check for the latest versions and any potential breaking changes.

What’s Next?

I’m excited about the future of AI provider flexibility. Some ideas I’m exploring:

Intelligent routing based on request type or user tier
Cost-based switching that automatically chooses the most economical provider
A/B testing different models for the same conversation
Hybrid approaches that use multiple providers for different parts of the same workflow

The configuration-driven approach makes all of these possibilities simple to implement.

Final Thoughts

Building AI applications doesn’t have to lock you into a single provider. With the right architecture, you can have the best of all worlds: local development, cost-effective testing, and enterprise-grade production deployment.

The key is to think of AI providers as interchangeable services from day one. Your future self will thank you when you need to switch providers for cost, performance, or compliance reasons.

Have you built something similar? I’d love to hear about your experiences with multi-provider AI architectures. Drop me a line on Blue Sky or LinkedIn.

Headless CMS Without a PC on GitHub Pages

Thu, 26 Jun 2025 00:00:00 +0000

Headless CMS Without a PC on GitHub Pages

I’ve been running my site on GitHub Pages - no server, just git and GitHub Actions. But I still want a CMS that works on mobile, without dragging around a laptop or doing a Git clone. Enter Sveltia CMS + Sveltia CMS Auth on Cloudflare Workers. Here’s how to glue it together.

Why This Setup?

No paid services like Netlify.
I edit blog posts from my phone-even waiting in line for coffee.
No git install, no desktop.

A solution exists: Sveltia’s Cloudflare Workers-based authenticator makes GitHub-backed CMS possible on GitHub Pages.

🎯 Step 1: Add Sveltia CMS to Your Site

In your /admin/index.html, include Sveltia, a lightweight, modern CMS:

<!DOCTYPE html>
<html>

<head>
 <meta charset="utf-8" />
 <meta name="viewport" content="width=device-width, initial-scale=1.0" />
 <meta name="robots" content="noindex" />
 <title>Content Manager</title>
</head>

<body>
 <script src="https://unpkg.com/@sveltia/cms/dist/sveltia-cms.js"></script>
</body>

</html>

No heavy JS, no React-just Svelte. Touch support, dark mode, fast. It handles GitHub directly via your browser or the auth worker.

🔐 Step 2: Deploy the Sveltia-CMS-Auth Worker

Fork or import sveltia-cms-auth into Cloudflare Workers.
Deploy it; grab the Worker URL.
Register a GitHub OAuth App, using the Worker URL plus /callback for the redirect.
Add client credentials and your domain to Workers environment variables. Deploy again.

Now your site has its own auth client-it communicates with GitHub when you click Login.

🛠 Step 3: Wire It All Up in Your Config

In your Sveltia admin/config.yml, under backend:

backend:
 name: github
 repo: <OWNER>/<REPO> # Path to your GitHub repository
 # optional, defaults to master
 branch: main
 base_url: https://<WORKER>.workers.dev
# This line should *not* be indented
media_folder: "assets/uploads" # Media files will be stored in the repo under images/uploads

That base_url points Sveltia’s OAuth to your Worker. Push the change, and your /admin/ loads Sveltia. Clicking “Login” redirects to GitHub via your Worker, and you’re ready to edit.

📱 Step 4: Edit From Your Phone

Visit yourgithubpages.com/admin/ on your mobile device. The UI is responsive and built for touch. I’ve easily edited blog posts without needing VS Code or Terminal. Sveltia handles commit and push transparently.

Quick FAQ

Q: Why not Decap CMS or Netlify CMS?
A: They typically rely on external OAuth providers. Sveltia + Cloudflare Workers solves that neatly.

Q: Does it require a PC?
A: Only initial setup needs a desktop. Afterward, your CMS runs entirely in-browser, even mobile.

Q: Self-hosted?
A: GitHub Pages hosts the static site. The CMS runs client-side, and auth is on Cloudflare’s free tier.

TL;DR

Goal	Tool
GitHub-only hosting	GitHub Pages (no server)
Modern, touch-ready UI	Sveltia CMS
OAuth via GitHub	Sveltia-CMS-Auth Worker
Zero laptop edits	Fully mobile browser-compatible

This combo gives me a mobile-friendly CMS experience without extra hassle. If you’re editing your Jekyll-based GitHub Pages blog without a PC, this setup hits the mark.

Related Resources

Understanding AI and Prompting Techniques Part 1

Sun, 25 May 2025 00:00:00 +0000

Understanding AI and Prompting Techniques Part 1

Artificial Intelligence (AI) has rapidly evolved from science fiction to an integral part of our daily lives, transforming how we interact with technology and reshaping industries worldwide. Whether you’re using ChatGPT to draft emails, asking Copilot to write code, or generating images with DALL-E, understanding how to effectively communicate with AI systems has become an essential skill.

In this first part of our series, we’ll explore foundational concepts of AI, machine learning, deep learning, and generative AI, then dive deep into the art of prompting-the key to unlocking AI’s full potential.

What is AI?

Artificial Intelligence is a branch of computer science dedicated to creating intelligent machines capable of performing tasks that typically require human intelligence. These tasks include problem-solving, decision-making, language understanding, and perception.

Evolution of AI

AI has evolved through distinct phases, each building upon the previous:

1950s - Artificial Intelligence: The foundational era where pioneers like Alan Turing and John McCarthy laid the groundwork for machines that could simulate human reasoning and problem-solving.
1980s-1990s - Expert Systems: Rule-based systems that captured human expertise in specific domains, marking the first practical AI applications.
1997 - Machine Learning Breakthrough: IBM’s Deep Blue defeated world chess champion Garry Kasparov, showcasing the power of algorithms that could learn and improve.
2012 - Deep Learning Revolution: The ImageNet competition demonstrated that neural networks with multiple layers could dramatically outperform traditional methods in image recognition.
2017 - Transformer Architecture: The introduction of the “Attention Is All You Need” paper revolutionized natural language processing, leading to modern AI models.
2022-2024 - Generative AI Explosion: Models like ChatGPT, GPT-4, and Claude brought AI to mainstream audiences, enabling creation of text, images, code, and more from simple prompts.

Key AI Terms

To effectively engage with AI, it’s essential to understand some fundamental terms.

AI Models

AI models are the engines that power modern artificial intelligence. A model is a system trained on large datasets to recognize patterns, make predictions, or generate new content. The quality and capabilities of an AI system depend heavily on the underlying model.

How Models Work

Training: Models are trained using vast amounts of data and advanced algorithms.
Learning Patterns: Through training, models learn to identify trends, relationships, and structures in data.
Making Predictions: Once trained, models can process new data to make predictions, classify information, or generate content.

Popular AI Models (2025)

Company/Organization	Model	Specialization	Key Features
OpenAI	GPT-4o, GPT-4o mini, o1	Language, reasoning	Advanced reasoning, multimodal capabilities
Microsoft	Phi-4, Copilot	Code, productivity	Optimized for efficiency, integrated tools
Anthropic	Claude 3.5 Sonnet, Claude 3.5 Haiku	Conversational AI	Constitutional AI, safety-focused
Meta	Llama 3.1, Llama 3.2	Open-source language	Available for research and commercial use
Google	Gemini Pro, Gemini Ultra	Multimodal AI	Strong integration with Google services
DeepSeek	DeepSeek-R1	Reasoning	Specialized in logical reasoning tasks

These models differ significantly in their architecture, training data, and intended use cases. For example:

GPT-4o excels at complex reasoning and multimodal tasks (text, images, audio)
Claude 3.5 Sonnet is known for its helpful, harmless, and honest responses
Phi-4 is optimized for efficiency while maintaining strong performance
Llama 3.1 offers powerful open-source alternatives for developers

“The choice of model determines the capabilities and limitations of your AI-powered application.”

Tokens: The Language of AI

Tokens are the fundamental units that AI models use to process and understand language. Think of tokens as the “words” in AI’s vocabulary, though they don’t always correspond directly to human words.

Understanding Tokenization

When you submit text to an AI model, it first breaks your input into tokens through a process called tokenization. Here’s what you need to know:

Size: One token roughly equals 4 characters of English text
Conversion: 100 tokens ≈ 75 English words
Variability: Common words might be single tokens, while rare words or technical terms might be split into multiple tokens
Languages: Different languages have different tokenization patterns (e.g., Chinese characters often require more tokens per word)

Why Tokens Matter

Understanding tokens helps you:

Optimize prompts: Stay within model token limits
Manage costs: Many AI services charge per token
Improve efficiency: Craft concise prompts that convey maximum information

Token Limits in Practice

Most AI models have token limits for both input and output:

GPT-4o: Up to 128,000 input tokens
Claude 3.5 Sonnet: Up to 200,000 input tokens
Gemini Pro: Up to 1,000,000 input tokens

Pro Tip: Use online token counters to estimate your prompt length before submitting to AI models, especially for complex tasks or long documents.

Prompting

Prompting is the art of communicating with AI models to achieve useful and relevant responses. The effectiveness of a prompt depends on clarity, context, and the role you assign to the model. Well-crafted prompts can dramatically improve the quality and relevance of AI outputs.

Why Prompting Matters

Clear prompts reduce ambiguity and help the model understand your intent.
Providing context ensures the AI tailors its response to your needs.
Assigning roles guides the model’s tone, expertise, and style.

Components of a Good Prompt

Component	Description	Example
Instruction	What you want the AI to do	Summarize this article in 3 sentences.
Context	Background or specifics	The article is about renewable energy trends in 2025.
Role	Persona or expertise	You are an energy policy analyst.
Format	Desired output style	Respond in bullet points.
Constraints	Limits or requirements	Use no more than 100 words.

Practical Prompting Tips

Be specific: Vague prompts lead to vague answers. Specify what you want.
Add context: Include relevant details, such as audience, purpose, or scenario.
Set a role: Tell the AI who it should act as for more targeted responses.
Request a format: Ask for lists, tables, or summaries if needed.
Iterate: Refine your prompt if the output is not what you expect.

Prompting Examples

Without context:

“Write an email inviting people to a meeting.”

With context and role:

“You are a project manager at Contoso. Write a formal email inviting the Azure Reliability team to a kickoff meeting next Thursday at 2 PM ET to discuss outage analysis improvements using AI.”

The second prompt produces a much more targeted and useful response because it provides:

Role clarity: Project manager perspective
Specific context: Company name, team, meeting purpose
Clear details: Date, time, topic
Tone guidance: Formal communication

The Power of Context and Roles

Why Context Matters

Context provides the background information that transforms generic AI responses into tailored, relevant outputs:

Audience awareness: Specify who will read/use the output (executives, developers, students)
Purpose clarity: Define what you want to achieve (inform, persuade, educate, troubleshoot)
Constraints: Include relevant limitations (time, budget, technical requirements)
Domain specifics: Provide industry or technical context when needed

Effective Role Assignment

Assigning roles gives the AI a persona and expertise focus:

Professional roles: “You are a cybersecurity expert,” “Act as a technical architect,” “Respond as a UX designer”
Communication styles: “Explain like I’m 5,” “Use formal business language,” “Write in a conversational tone”
Perspective shifts: “From a customer’s viewpoint,” “Consider the developer experience,” “Think like a project manager”

Example of role impact:

Generic prompt: “How do I optimize this SQL query?”

Role-specific prompt: “You are a senior database administrator. Review this SQL query for a high-traffic e-commerce site and suggest optimizations that prioritize read performance while maintaining data consistency.”

Advanced Prompting Techniques

Beyond the basics, here are some powerful techniques for getting better results:

Chain of Thought Prompting

Ask the AI to “think step by step” or “show your reasoning”:

Analyze this code for security vulnerabilities. Think step by step:
First, identify potential input validation issues
Then, check for authentication and authorization flaws
Finally, look for data exposure risks

Few-Shot Learning

Provide examples of the desired output format:

Convert these technical terms to plain English:

API → Application Programming Interface (a way for software to communicate)
SDK → Software Development Kit (tools for building apps)
Docker → [Your task: explain this term]

Prompt Chaining

Break complex tasks into smaller, sequential prompts:

“Summarize this 50-page document into key themes”
“For each theme, identify 3 actionable recommendations”
“Create a presentation outline based on these recommendations”

Understanding AI Model Limitations

While AI models are powerful, it’s crucial to understand their limitations:

Statelessness and Memory

Most AI models are stateless-they don’t remember previous interactions unless explicitly provided with conversation history. Each request is independent, which means:

No persistent memory: The model won’t remember what you discussed earlier unless you include it in your current prompt
Context windows: Models can only “see” a limited amount of text at once (their context window)
Application responsibility: Chat applications maintain conversation history and send it with each new request

Other Key Limitations

Knowledge cutoffs: Models are trained on data up to a specific date and don’t know about events after that
Hallucinations: Models may generate plausible-sounding but incorrect information
Bias: Training data biases can influence model outputs
Reasoning limitations: While improving, models can struggle with complex logical reasoning

Best Practice: Always verify important information from AI models, especially for critical decisions or factual claims. “Effective prompting combines clear instructions, relevant context, and well-defined roles to guide AI models toward your desired outcome.”

What’s Next?

In this series, we’ll dive deeper into advanced prompt engineering techniques, including:

Prompt patterns and templates for common use cases
Multi-modal prompting with images, audio, and code
Prompt optimization strategies for better performance
Real-world case studies from software development, content creation, and data analysis
Safety and ethical considerations in AI prompting

Whether you’re a developer looking to integrate AI into your applications, a content creator exploring AI-assisted workflows, or simply curious about maximizing your productivity with AI tools, the next part will provide practical techniques you can apply immediately.

“Mastering AI prompting is like learning a new language-the better you communicate, the more powerful the results.”

Stay tuned for Part 2, where we’ll put these concepts into practice with hands-on examples and advanced strategies!

Aspiring .NET & Resilience @ NDC Oslo 2025

Sat, 24 May 2025 00:00:00 +0000

As I’m flying from Oslo to Amsterdam, I’m still buzzing with energy and inspiration from NDC Oslo 2025. It was an incredible week of learning, sharing, and connecting with some of the brightest minds in technology. From thought-provoking keynotes that challenged our assumptions to the epic The Linebreakers concert at Brewgata, every moment reinforced why each NDC conference but NDC Oslo remains one of the premier developer conferences in the world.

A Journey of Learning and Sharing

NDC Oslo 2025 brought together over 2,000 developers, architects, and technology leaders from across the globe. The conference’s unique blend of deep technical content and community spirit created an atmosphere where learning happened not just in sessions, but in every conversation.

As a speaker at this year’s event, I had the privilege of presenting two sessions that reflect the current evolution of our industry:

Aspiring .NET with Azure OpenAI and Ollama

During the Community Days event, I showcased practical AI integration patterns for .NET developers:

Building semantic search capabilities using Azure OpenAI embeddings
Running local LLMs with Ollama for development and testing
Implementing responsible AI practices including content filtering and rate limiting
Creating conversational interfaces that enhance rather than replace existing applications

The recently updated samples for .NET Aspire 9.3 sparked discussions about the future of AI in enterprise applications.

Resilient by Design

In this session, I explored how to build systems that don’t just survive failure-they thrive despite it. We dove into:

Chaos engineering principles and how to implement them safely in production
Circuit breaker patterns with real-world examples from Azure deployments
Graceful degradation strategies that maintain user experience during partial outages
Observability practices that make resilience measurable and improvable

The engaged room had questions demonstrated just how critical resilience has become in our cloud-native world.

Engaging with Diverse Perspectives

What makes NDC Oslo special is its commitment to showcasing the full spectrum of modern technology. This year’s program delivered exceptional content across multiple tracks:

AI and Machine Learning

Beyond the hype, speakers demonstrated practical AI implementations that solve real business problems. Sessions ranged from building RAG (Retrieval-Augmented Generation) systems to implementing ethical AI governance frameworks.

Cloud Architecture

The cloud track featured battle-tested patterns for building distributed systems at scale. Highlights included:

Event-driven architectures using Azure Service Bus and Event Grid
Multi-region deployment strategies with zero-downtime deployments
Cost optimization techniques that saved companies millions

Developer Experience

A refreshing focus on making developers’ lives better, with sessions covering:

Modern debugging techniques for distributed systems
AI-powered code review tools
Creating effective development environments with DevContainers

Performance and Optimization

Deep technical dives into making applications faster and more efficient:

.NET performance improvements and how to leverage them
Database query optimization strategies
Frontend performance patterns for modern SPAs

Security and Best Practices

Critical discussions on protecting modern applications:

Zero-trust architecture implementation
Supply chain security for containerized applications
OWASP Top 10 for cloud-native applications

Psychology and Soft Skills

Perhaps the most impactful track, addressing the human side of technology:

Building psychologically safe teams
Managing technical debt without burnout
Effective communication strategies for technical leaders

Conference Highlights

Keynotes That Inspired

Laila Bougria’s “CTRL+SHIFT+(BUILD) PAUSE” was a masterclass in presentation excellence. Her exploration of using AI in our daily workflow and the importance of not giving way too much control resonated deeply. The way she wove personal stories with technical insights created a narrative that was both educational and emotionally compelling.

David Whitney’s “The Unbearable Weight of Architecture” challenged us to think beyond technical perfection. His emphasis on pragmatic architecture decisions and the importance of designing with intentionality struck a chord with the audience. His discussion of how wrong decisions cast long shadows over systems-dooming maintainers to endless toil-was both sobering and enlightening.

Rendle’s closing keynote “Reasons To Be Cheerful: 0, 1, 2…” sent us home with renewed optimism. His journey through technology’s evolution reminded us how far we’ve come and painted an exciting picture of where we’re heading.

Beyond the Sessions

The true magic of NDC Oslo happened between the scheduled talks:

Coffee Conversations: Where a casual chat about microservices turned into a deep dive on event sourcing
Lightning Talks: 10-minute bursts of inspiration that often packed more value than hour-long sessions
Workshop Deep Dives: Hands-on learning that transformed theory into practice

The Legendary NDC Party

The conference’s social highlight deserves special mention. The evening began with fascinating presentations on space technology (who knew satellite communication could be so entertaining?), followed by a nostalgic journey through the Demo Scene that had everyone reminiscing about their first coding experiences.

The Phil Nash Karaoke session was legendary-complete with a full chorus of developers providing hyena sound effects for “Be Prepared” from The Lion King. It perfectly captured the conference’s spirit: serious about technology, but never taking ourselves too seriously.

Key Takeaways

Reflecting on NDC Oslo 2025, several themes emerged that will shape my work in the coming year:

AI Integration is Now Table Stakes The question is no longer whether to integrate AI, but how to do it responsibly and effectively. Every application can benefit from intelligent features, but success requires thoughtful implementation and clear value propositions.
Resilience Through Simplicity The most resilient systems aren’t necessarily the most complex. Sessions repeatedly emphasized that simple, well-understood patterns often outperform clever solutions when things go wrong.
Community Amplifies Individual Impact The connections made at NDC Oslo will generate more value than any single session. The mix of experienced architects sharing war stories with eager newcomers created a learning environment that benefits everyone.
Practical Beats Theoretical The most successful sessions focused on “here’s how we actually did it” rather than “here’s how it should work in theory.” Real-world case studies and live coding demonstrations drove the most engagement.
The Human Element Remains Central Despite all our technological advances, the sessions on team dynamics, communication, and mental health drew the largest crowds. Technology is ultimately about people, and NDC Oslo never forgot that.

Looking Ahead

The conversations started at NDC Oslo will continue through blog posts, open-source contributions, and community meetups.

For those considering attending future NDC events, I cannot recommend them highly enough. Whether you’re a seasoned architect or just starting your development journey, you’ll find sessions, workshops, and conversations that challenge and inspire you.

The technology landscape continues to evolve at breakneck speed, but events like NDC Oslo remind us that we’re not navigating these changes alone. We’re part of a global community of builders, thinkers, and problem-solvers, all working to create a better technological future.

Thank you, NDC Oslo, for another unforgettable experience. See you next year!

Aspiring .NET & Resilience @ Techorama Belgium 2025

Tue, 06 May 2025 00:00:00 +0000

I’m thrilled to announce that I’ll be delivering two sessions at Techorama Belgium 2025! Join me as we explore the cutting edge of .NET, AI, and cloud resilience with actionable strategies, demos, and real-world insights. Techorama Belgium is a premier tech conference that brings together developers, architects, and IT professionals to share knowledge and network with industry leaders. This year, I’m excited to be part of the lineup!

My Sessions at Techorama Belgium 2025

Aspiring .NET with Azure OpenAI and Ollama

Discover how you can unlock the potential of AI in your .NET applications. In this session, you’ll learn how to integrate Azure OpenAI and Ollama to build intelligent, modern .NET solutions. Through hands-on demos, code walkthroughs, and practical guidance, you’ll see how conversational AI, large language models, and generative capabilities can enhance your projects.

You’ll also explore .NET Aspire, a modern framework designed to simplify building cloud-native applications. .NET Aspire provides streamlined APIs, built-in observability, and simplified deployment, making it easier to develop, test, and scale your applications efficiently.

Additionally, you’ll learn about Microsoft.Extensions.AI, a powerful library that integrates AI services directly into your .NET applications. It provides standardized interfaces and extensions, enabling you to easily connect to AI models like Azure OpenAI and Ollama, manage AI configurations, and incorporate advanced AI capabilities without extensive changes to your existing code.

Key topics:

.NET Aspire and the future of cloud-native .NET applications
Microsoft.Extensions.AI for seamless integration with Azure OpenAI and Ollama
Building AI-powered features in your .NET applications
Deploying and scaling AI solutions in the cloud

Session details

Resilient by Design

I’ll also be delivering this session on Azure Resiliency at NDC Oslo, and I’m excited to bring it to Techorama Belgium as well!

In cloud environments, failures are inevitable. This session explores how to build systems that not only survive but thrive amid disruptions. We’ll examine practical resilience patterns, architectural approaches, and Azure-native tools that help maintain reliability when components fail.

Key topics:

Cloud resilience fundamentals and failure modes
Multi-region architecture strategies
Built-in Azure resilience capabilities
Testing for resilience with Azure Chaos Studio
Implementing resilience patterns in .NET applications

Session details

Join Me in Belgium

I look forward to meeting you and diving into the art and science of AI-powered and Resilient By Design solutions in Azure and .NET. Don’t miss this chance to level up your engineering strategy-see you at Techorama Belgium!

Resilient by Design @ NDC Oslo 2025

Tue, 06 May 2025 00:00:00 +0000

I’m excited to preview my upcoming NDC Oslo talk, “Resilient by Design”, where I’ll share how to architect Azure systems that not only survive failure but continue running smoothly when disruptions occur (NDC). Join me on to explore core resilience principles, Azure-native tools, and proven best practices for maintaining high availability in real-world scenarios (Microsoft Azure, Microsoft Learn). Whether you’re new to Azure or looking to optimize an existing environment, this session will equip you with actionable strategies to anticipate, mitigate, and recover from failures (Microsoft Learn).

Why Resilience Matters

In cloud-native environments, failure is inevitable-hardware degrades, networks fluctuate, dependencies falter-and without resilience built in, even minor glitches can cascade into major outages (Microsoft Azure, Azure Well-Architected). Designing for resilience means embracing failure modes and planning recovery paths proactively rather than reacting when things break (Microsoft Learn, Azure Well-Architected). By prioritizing resilience, organizations can uphold service-level objectives (SLOs) and deliver reliable experiences to users, even under adverse conditions (Microsoft Learn, Azure Well-Architected).

Core Resilience Principles

Design for Redundancy: Build duplicate components and failover paths to eliminate single points of failure, leveraging availability zones and regions as your foundation (Microsoft Learn, Azure Well-Architected).
Implement Multi-Region Strategies: Use active-active or active-passive architectures across regions to maintain service continuity during regional outages (Microsoft Learn, Azure Well-Architected).
Leverage Failure Mode Analysis: Proactively identify and prioritize potential failure scenarios to focus mitigation efforts where they matter most (Microsoft Learn, Azure Well-Architected).
Plan for Geo-Redundancy: Configure geo-redundant storage and services (e.g., GRS/RA-GRS) to ensure critical data remains accessible if a primary region becomes unavailable (Azure documentation, Azure Well-Architected).

Azure Resilience Toolkit

Azure Chaos Studio: Inject controlled faults to validate and harden your applications against real-world issues before they impact customers (Azure Chaos Studio).
Traffic Management & Load Balancing: Use Azure Traffic Manager and Front Door to intelligently route traffic and failover quickly under load spikes or regional failures (Microsoft Learn, Azure Well-Architected).
App Service Reliable Web App Pattern: Implement retry, circuit breaker, and cache-aside patterns to improve application reliability and performance efficiency (Microsoft Learn, Azure Well-Architected).
Well-Architected Framework: Apply the Reliability pillar’s design principles and assessment checklists from Microsoft’s Well-Architected Framework to ensure consistent resilience across workloads (Azure Well-Architected).

Real-World Strategies

We’ll cover real-world strategies for maintaining uptime under pressure, such as automated failover drills, disaster recovery runbooks, and self-healing infrastructure practices (NDC). You’ll see examples of how teams integrate chaos experiments into CI/CD pipelines and leverage telemetry-driven insights to continuously refine their resilience posture (Azure Chaos Studio, Azure Well-Architected).

Join Me in Oslo

I look forward to meeting you and diving into the art and science of building resilient-by-design solutions in Azure. Don’t miss this chance to level up your resilience strategy-see you at NDC Oslo!

Stir Trek 2025 and Multiple Dev Containers

Sun, 04 May 2025 00:00:00 +0000

This month at Stir Trek 2025, I presented on Dev Containers and GitHub Codespaces, demonstrating how these tools streamline both local and cloud-based development workflows. The session covered the essentials of creating portable development environments, customizing containers with features and extensions, and launching Codespaces directly from your repository. A lively Q&A followed, with attendees asking about strategies for running and working with multiple containers. Below, I’ve distilled those discussions and provided a deeper dive into shared container configurations across multiple projects-including folder structures, Docker Compose setups, VS Code workflows, and advanced tips you can apply in your own work.

Recap: Dev Containers and Codespaces

Dev Containers are Docker-based environments enriched with development-specific tooling, settings, and startup tasks as defined in a devcontainer.json file. They enable you to use a container as a full-featured development environment-isolating dependencies, standardizing tool versions, and enabling reproducible setups locally or remotely (Dev Containers).

GitHub Codespaces builds on Dev Containers by providing cloud-hosted environments that spin up in seconds with configurable CPU, memory, and storage. Codespaces leverages the same open specification as Dev Containers, making your devcontainer.json a first-class citizen whether you connect via VS Code, IntelliJ, or directly in the browser (GitHub Docs).

Q&A: Running Multiple Containers

Can I connect to multiple containers at once?

By default, VS Code allows only one container per window, but you can open additional windows and attach each to a different container to work on multiple services in parallel (Visual Studio Code).

What about using a single window for multiple containers?

If you use Docker Compose, define multiple services in your docker-compose.yml and create separate devcontainer.json configurations for each service-each referencing the common Compose file. VS Code will then list each configuration in its Dev Container picker, letting you reopen the current window to connect to a different service without duplicating your Compose setup (Dev Containers).

How do I configure separate containers for multiple projects?

To maintain isolation and clarity, place each container configuration in its own subdirectory under .devcontainer, following the pattern .devcontainer/<project>/devcontainer.json. Tools supporting the spec recognize this layout and list all found configurations in the Codespaces or VS Code Dev Container dropdown (containers.dev, GitHub Docs).

Shared `.devcontainer` Folder Structure

Centralize your container configurations in a single root directory:

dev-container/
├─ .devcontainer/
│ ├─ .env
│ ├─ docker-compose.yml
│ ├─ project-a-node-js/
│ │ └─ devcontainer.json
│ ├─ project-b-node-js/
│ │ └─ devcontainer.json
│ ├─ project-c-python/
│ │ └─ devcontainer.json
│ └─ project-d-go-lang/
│ └─ devcontainer.json
├─ project-a-node-js/
├─ project-b-node-js/
├─ project-c-python/
└─ project-d-go-lang/

This layout lets all projects share a single Compose definition and environment variables-reducing duplication and easing updates (containers.dev).

Common Docker Compose File

In .devcontainer/docker-compose.yml, define every project service alongside shared dependencies:

services:
 project-a-node-js:
 image: mcr.microsoft.com/devcontainers/base:latest
 volumes:
 - ..:/workspaces:cached
 ports:
 - "8001:8000"
 command: sleep infinity

 project-b-node-js:
 image: mcr.microsoft.com/devcontainers/base:latest
 volumes:
 - ..:/workspaces:cached
 ports:
 - "8002:8000"
 depends_on:
 - postgres

 project-c-python:
 image: mcr.microsoft.com/devcontainers/base:latest
 volumes:
 - ..:/workspaces:cached
 ports:
 - "8003:8000"
 depends_on:
 - postgres

 project-d-go-lang:
 image: mcr.microsoft.com/devcontainers/base:latest
 volumes:
 - ..:/workspaces:cached
 ports:
 - "8004:8000"

 postgres:
 image: postgres:latest
 volumes:
 - postgres-data:/var/lib/postgresql/data

volumes:
 postgres-data:

Each service listens on port 8000 internally and is mapped to a unique host port (8001-8004) to prevent collisions (Visual Studio Code).

Workspace Mounts & Folder Mapping

Mounting the root-level folder into /workspaces in each container gives uniform access to all projects. In each devcontainer.json, point workspaceFolder at the specific subdirectory:

"workspaceFolder": "/workspaces/project-b-node-js"

This ensures your editor is scoped appropriately when connected (Dev Containers).

Per-Project `devcontainer.json`

Each project’s configuration references the shared Compose file and specifies its service:

{
 "name": "Project B Dev Container",
 "dockerComposeFile": ["../docker-compose.yml"],
 "service": "project-b-node-js",
 "workspaceFolder": "/workspaces/project-b-node-js",
 "shutdownAction": "none"
}

Using "shutdownAction": "none" keeps all containers running when you close one window, so you don’t inadvertently tear down shared services (Dev Containers).

Building & Switching Between Containers

Open the root folder (dev-container/) in VS Code.
Reopen in Container: Run Dev Containers: Reopen in Container and select your desired project.
Switch Container: Later, use Dev Containers: Switch Container to hop to another project without restarting the Docker stack (Visual Studio Code, GitHub Docs).

Advanced Multi-Project Strategies

Environment-Specific Overrides

Layer additional Compose files for environment-specific tweaks:

docker-compose -f docker-compose.yml \
 -f docker-compose.override.yml \
 -f docker-compose.dev.yml up -d

Overrides can redefine images, ports, mounts, or feature flags per environment (Visual Studio Code).

Isolated Networks & Namespaces

Define separate Docker networks to segment traffic:

networks:
 dev-a: {}
 dev-b: {}

services:
 project-a-node-js:
 networks: [dev-a]
 project-b-node-js:
 networks: [dev-b]
 postgres:
 networks: [dev-a, dev-b]

This prevents unintended inter-service communication between project environments (Visual Studio Code).

GitHub Codespaces Integration

Codespaces recognizes the same .devcontainer layout:

Configuration Dropdown: Multiple devcontainer.json files under .devcontainer/ are automatically listed when creating a Codespace (GitHub Docs).
Port Forwarding: Host-mapped ports (8001-8004) surface as forwarded ports in the Codespaces UI.
Pre-builds & Secrets: Enable pre-builds in devcontainer.json and leverage repository or organization secrets instead of a local .env file (The GitHub Blog).

Lifecycle Customization

Use Dev Container lifecycle hooks per project to automate setup:

"postCreateCommand": "cd /workspaces/project-a-node-js && npm ci",
"postStartCommand": "npm run migrate",
"initializeCommand": "git submodule update --init"

These commands ensure each container is fully prepared for development immediately (Dev Containers).

Troubleshooting Tips

Stuck at “Rebuilding container…”: Clear the Docker build cache or raise VS Code’s Docker logging level.
Ports not forwarding: Verify forwardPorts in devcontainer.json or check Codespaces port settings.
Volume performance issues: On macOS/Windows, consider isolating cache directories (e.g., node_modules) in named volumes to speed up I/O (Some Natalie’s corner of the internet, pamela fox’s blog).

Conclusion

By centralizing Dev Container configurations and sharing a unified docker-compose.yml, you eliminate duplication, streamline dependency management, and enable seamless switching between multiple projects-both locally and in GitHub Codespaces. This pattern scales from a handful of services to extensive microservice landscapes, delivering consistent, reproducible developer environments across your entire workspace.

Copilot or Rubber Ducky?

Thu, 24 Apr 2025 00:00:00 +0000

Rubber Duck Debugging in the Age of AI

Ever found yourself explaining your code to a little rubber duck perched on your desk? If so, you’re in good company. This quirky practice, known as rubber duck debugging, has helped countless developers articulate problems and discover solutions. The idea is simple: by forcing yourself to explain your code, line by line, to an inanimate duck, you often stumble upon the bug or insight you needed. It’s like having a silent pair programmer who patiently listens as you work through the logic. But what if your rubber duck could talk back and offer suggestions? Modern AI coding assistants (like GitHub Copilot) are becoming the new interactive rubber ducks, and that means a lot for debugging, brainstorming ideas, and reviewing code.

What is Rubber Duck Debugging?

Rubber duck debugging (or “rubberducking”) is a tried-and-true method for debugging code by explaining it aloud in plain language. The term comes from a story in The Pragmatic Programmer where a developer carries around a rubber duck and debugs issues by describing code to the duck (Rubber duck debugging - Wikipedia). The act of verbalizing your problem-even to an object that can’t respond-often makes the solution obvious. By describing what your code is supposed to do versus what it actually does, any mismatch or flaw becomes apparent. Many programmers have experienced that “aha!” moment while explaining a bug to a colleague; rubber ducking achieves the same effect without needing to interrupt anyone else.

This technique works because teaching or explaining forces you to view the problem from a different perspective. You slow down and examine your code step-by-step. In doing so, you might catch off-by-one errors, incorrect assumptions, or forgotten conditions that you overlooked before. It’s surprisingly effective-sometimes the mere act of stating the problem out loud is enough to trigger a solution.

From Silent Duck to AI Assistant

Traditional rubber duck debugging gives you a listener, but in modern development we now also have interactive helpers. Enter AI pair programming tools like GitHub Copilot, OpenAI’s ChatGPT, and others. These AI assistants serve as a kind of rubber duck that talks back, offering hints, explanations, and even code suggestions in real time. It’s as if the duck on your desk suddenly gained a brain and a voice (though fortunately, not an actual quacking sound).

GitHub Copilot, for example, integrates into your editor and can suggest the next line of code or help fill in functions as you type. Ask it a question (via a comment or chat interface) and it can suggest a solution or explain a chunk of code. Similarly, ChatGPT and other AI chatbots can analyze a piece of code you provide and discuss it with you. This transforms the debugging process into an interactive dialogue. You describe the problem-just like you would to a rubber duck-but now you get a response that might point out the bug or offer a fresh approach.

Using an AI assistant feels a bit like pair programming with a knowledgeable colleague who’s always available. The AI can highlight inconsistencies or recommend best practices on the fly, helping you stay in the flow state of coding. In other words, you spend less time stuck on trivial issues or searching through documentation, and more time building solutions. The core benefit is the same as rubber duck debugging: you’re clarifying your own understanding. The difference is that the “duck” (the AI) can actively contribute to the conversation.

Practical Use Cases for an AI Rubber Duck

How exactly can AI tools enhance your development workflow? Let’s look at a few concrete scenarios where an AI assistant shines as a debugging and coding partner:

1. Debugging with Interactive Assistance

When you hit a perplexing bug, an AI assistant can act as a debugging buddy. Instead of just explaining the issue to a silent duck, you can describe the problem to an AI and get immediate feedback. For example, if a function isn’t returning the expected output, you might ask the AI, “Here’s my function and what it’s supposed to do. Can you spot why it’s returning the wrong value?” The AI can analyze your code and point out, say, a missed edge case or a variable that wasn’t updated correctly. This is like the duck not only listening, but actually highlighting the error in your explanation.

Modern tools like Copilot Chat (the chat interface of GitHub Copilot) go even further: they integrate with your development environment’s debugger. This means the AI can access the call stack, variable values, and error messages while you’re debugging. You can literally ask, “Why did this null pointer exception occur?” and the AI, aware of the context, can suggest what might be null and where it came from. It’s an extension of the rubber duck method into a two-way conversation. By engaging in this dialogue, you still reap the benefit of thinking through the problem clearly, but you also get targeted hints and potential fixes in real time.

2. Brainstorming and Idea Generation

Beyond bug squashing, AI “ducks” are fantastic for brainstorming solutions and generating ideas. Let’s say you’re starting a new feature or unsure how to implement a particular algorithm. In the past, you might talk it out to your duck or jot ideas on a whiteboard. Now, you can bounce ideas off an AI. For instance, you could ask, “What are some ways to optimize this search algorithm?” or “Can you suggest a design pattern for this use-case?” The AI can enumerate a few approaches, outline code snippets, or even highlight pros and cons of each approach.

This is like having an ever-helpful colleague who has read every Stack Overflow post and documentation page out there. The AI might surface an approach you hadn’t considered or remind you of edge cases you might have overlooked. Even if you don’t directly use the AI’s suggestion, it can spark new thoughts-much like a brainstorming session with a team. Idea generation with an AI assistant can be especially useful for things like: finding the best name for a function or variable, exploring different algorithms or libraries to solve a problem, or generating test cases you might not have thought of. It’s an interactive creativity boost that complements your own knowledge.

3. AI as a Code Reviewer

Code review is a critical part of development, and here too an AI sidekick can help. Think of it as preliminary rubber duck code review. Before you even send your code to a teammate for review, you can ask an AI to take a look. For example, you might prompt the AI with, “Here’s my function (or pull request). Do you see any issues or improvements I can make?” The AI will examine the code and might point out potential bugs, performance issues, or stylistic inconsistencies. It could catch things like a missed null check, an inefficient loop, or a confusing variable name, and suggest a clearer alternative.

This use case turns the AI into a tireless, instant code reviewer. Of course, AI won’t replace your human colleagues’ feedback-humans have context and intuition that AI might lack-but it’s a great way to screen your code for obvious problems and refine it before others see it. In essence, you’re explaining your code to the AI (just as you would to a duck or a colleague) and seeing what it flags. The process encourages you to double-check logic and consider improvements. It’s like having a second set of eyes on demand, helping you write cleaner, more robust code.

Engaging the AI, Preserving the Process

While AI tools are powerful, it’s important to note that they amplify rather than replace the core benefits of rubber duck debugging. The true magic of the rubber duck method lies in the process of articulating your thoughts. When using AI, you still need to clearly explain the problem or ask the right question-doing so forces you to understand the problem better, just as talking to the duck would. In fact, sometimes just formulating a question for ChatGPT or Copilot can make you realize the answer before the AI even replies!

The advantage of AI assistants is that they can respond with insights, which can save time and validate your thinking. They help you catch mistakes faster, explore more ideas, and learn new techniques. But you, the developer, are still in the driver’s seat. It’s your reasoning and intuition guiding the conversation. Think of the AI as an extension of the rubber duck: an extra knowledgeable duck that can provide feedback, but one that still relies on your direction and understanding.

Conclusion

The rubber duck debugging method has long been a secret weapon for developers, enabling us to solve problems by simply explaining them. Today, with AI-based tools like GitHub Copilot acting as interactive rubber ducks, we have an even more powerful ally at our disposal. These AI assistants can listen to our problems and actually respond with useful answers-helping debug code, spark new ideas, and review our work. By combining the old practice of articulating our thoughts with the new capabilities of AI, we get the best of both worlds: clarity of thought and immediate expert feedback.

In the end, whether you’re talking to a plastic duck or a digital assistant, the goal is the same: to understand the problem better and craft a solution. So don’t toss out your trusty rubber duck just yet-it has taught us the value of thinking aloud. But do consider inviting an AI partner into your workflow. You might be surprised at how engaging and insightful this “conversation” can be. After all, two heads (even if one is silicon-based) can be better than one. Happy debugging, and quack on!

New Team, New Focus

Fri, 21 Mar 2025 00:00:00 +0000

I wanted to share a quick work update and also explain why I’ve been posting less frequently lately. Previously, I was on the Fast Track for Azure (FTA) team at Microsoft, part of the Customer Experience Program (CXP) within Azure Engineering (C+AI). In October, my team was reorganized and I was moved into the Azure Reliability (AzRel) group.

I’m now part of the AzRel Risk SRE team, focusing specifically on risks related to Azure Platform Reliability. My new role brings with it a significantly different skill set and area of focus, requiring a deep dive into new concepts, tools, and approaches. I’ve been fully engaged in learning and adapting, and I’ve also been actively developing new applications and solutions to address challenges faced by my new team.

As the lead for the Platform Reliability Pillar, I’m utilizing advanced technologies like LLMs using OpenAI and SemanticKernel for comprehensive Outage Analysis. My role involves driving detailed cross-team analysis, fostering collaboration, and innovating solutions to improve the reliability and performance of the Azure platform. It’s a busy but exciting time, and I’m thrilled by the opportunity to make a meaningful impact with my new team and role. How often do you get to say that you help keep the Azure platform running smoothly?

Additionally, I’m continuing to speak at conferences around the world, sharing insights and staying connected with the community. As I find my new rhythm, expect to see more frequent posts and lots of interesting content coming your way.

Thank you for your patience and support as I navigate this new chapter and continue to learn and grow in my career!

When Technology Fails, GitHub Codespaces Saves the Day

Fri, 30 Aug 2024 00:00:00 +0000

Last week, I spoke at the Copenhagen Developers Festival about using GitHub Codespaces for cloud-based development. This is an amazing conference with an incredible lineup. I’ve done this talk plenty of times, sharing how flexible and convenient cloud development environments can be. But this time, things didn’t go as planned.

I arrived early, as usual, to set up and greet attendees. When I tried to connect my laptop to the screen, though, nothing appeared. It wasn’t a simple projector issue either; the recording equipment was more complicated than I expected. I had two adapters with me, and the conference staff handed me two more, but none of them worked. I rebooted, resized my display, tried everything I could think of-still nothing.

By now, I was a few minutes into my time slot, and the presentation seemed in jeopardy. I borrowed a local laptop, only to discover it was in Danish. Cue the comedy of errors! Finding the * for my password and the / for URLs was a nightmare. I ended up copying and pasting the / multiple times just to get around. Hopefully, the audience found it more amusing than I did.

Despite the keyboard struggles, I managed to pull it off. I used the browser to present my slides, which are hosted on GitHub Pages at http://chris-ayers.com/dev-containers. We discussed the Dev Containers spec, hosted at containers.dev. Then, I launched GitHub Codespaces using my repository https://github.com/codebytes/dev-containers and a few others (cpython and Home Assistant) to demonstrate its capabilities.

What could have been a total disaster turned into a great example of how powerful and resilient modern development tools are. GitHub Codespaces didn’t just save my presentation; it became the star of the show, proving that with the right tools, we can roll with the punches and keep going.

So, the next time technology decides not to cooperate, just remember-if your work’s in the cloud, you’re always just a few clicks away from getting back on track.

Writing Regex with Copilot

Tue, 09 Apr 2024 00:00:00 +0000

I had a real world example today that I wanted to share about copilot helping me with a coding problem. A friend reached out asking if I knew regex. Its been a bit, but I was happy to help because I thought we could figure it out.

The Problem

Her use case was that she had a string and she wanted to match a word only if another word appeared before it. She works at a University and is doing improvements to the CMS templates. They needed to do some updates to a Template only if it included certain tags. She was able to give me a sample that I could work with.

She was able to boil it down to a simple example. Given the sample, ‘I think puppies are super cute, but turtles are super cute too.’ make a regex that matches turtles only if puppies appears before it.

The Solution

Its been a while so I used GitHub Copilot Chat to help me out.

Given the sample, ‘I think puppies are super cute, but turtles are super cute too.’ Make a regex that matches turtles only if puppies appears before it.

Sure, here is a regular expression that matches “turtles” only if “puppies” appears before it in the text:

puppies.*turtles

This regular expression works as follows:

puppies matches the characters “puppies” literally. .* is a special sequence that matches any character (except for a newline) 0 or more times. turtles matches the characters “turtles” literally.

So, this regular expression will match any string that has “turtles” somewhere after “puppies”.

We are using regexer.com to test out the regexes. The result was close but we got in a back and forth refining the regex.

I want to match and return only the word turtles, not additional text. To match and return only the word “turtles”, but only if “puppies” appears before it in the text, you can use a lookahead assertion in your regular expression. Here’s how you can do it:

(?<=puppies.*)(turtles)

This regular expression works as follows:

(?<=puppies.*) is a positive lookbehind assertion that checks for the presence of “puppies” followed by any characters before the main expression. (turtles) is the main expression that matches the word “turtles”. So, this regular expression will match the word “turtles” only if it appears somewhere after the word “puppies”, but it will only return “turtles”.

Awesome!

Done, Or Are We?

My friend then threw a curveball at me. She wanted to match turtles only if puppies appears even if there are line breaks or other paragraphs. Like in this sample:

‘I think puppies are super cute,
but turtles are super cute too.’

Let’s see if we can modify the regex to match this.

Given the sample, ‘I think are super cute, but puppies turtles are super cute too.’ and the regex (?<=puppies.*)(turtles) I would like this to match turtles only if puppies appears even if there are line breaks or other paragraphs.. Like in this sample: ‘I think puppies are super cute, but turtles are super cute too.’

The regular expression (?<=puppies.*)(turtles) you provided uses a positive lookbehind (?<=puppies.*) to check if “turtles” is preceded by “puppies”. However, the . character does not match line breaks in regular expressions.

To match “turtles” only if “puppies” appears before it, even if there are line breaks or other paragraphs, you can use the [\s\S]* pattern instead of .*. The [\s\S] pattern matches any character including line breaks. Here’s how you can modify your regex:

(?<=puppies[\s\S]*)(turtles)

This will match “turtles” only if “puppies” appears before it, regardless of line breaks or other paragraphs. For example, it will match “turtles” in the following text:

I think puppies are super cute, but turtles are super cute too.

Lets try this out.

Everything looks like its working.

Conclusion

At this point, my friend had told me she had spent over an hour on stack overflow and other sites trying to figure this out. She had been hesitant to use GitHub Copilot but I think this was her aha moment. We literally solved her problem in under 5 minutes.

I have been using it for a while now and I am happy with the results. I don’t worry as much about syntax, I’m really more focused on WHAT I want to do and not HOW to do it. I think this is a game changer for me. I’m excited to see how this tool evolves.

If you haven’t tried out GitHub Copilot, I would recommend it. https://github.com/features/copilot

Containerizing .NET - Part 2 - Considerations

Mon, 19 Feb 2024 00:00:00 +0000

This is part 2 of the Containerizing .NET series. You can read the series of articles here:

Considerations

Welcome to the second installment in our series on containerizing .NET applications. Building on the foundation laid in our first article-where we introduced Dockerfiles and the dotnet publish command-this piece delves into pivotal considerations for transitioning .NET applications into containers. As containers become a cornerstone of the ecosystem, understanding these factors is critical for developers aiming to enhance application deployment in containerized environments.

Architectural Alignment and Security

Architectural Considerations in Containerization

As we delve into containerizing .NET applications, it’s essential to recognize that the architectural style-whether you’re working with a microservices pattern or a monolithic design-plays a pivotal role in shaping the containerization strategy. However, regardless of the architecture chosen, there are several critical considerations that universally impact the transition to a containerized environment.

CI/CD and Deployment Strategies

The move to containers necessitates a reevaluation of your Continuous Integration/Continuous Deployment (CI/CD) pipelines and deployment strategies. Containers offer the advantage of immutable deployment artifacts, which can streamline the CI/CD process by ensuring consistency across different environments. However, this also means adapting your pipelines to handle container image building, storage, and deployment, which may involve new tools and practices. I will dive into those in a future article.

Scalability Concerns

Ensuring Scalable Design

Your application must be architected to support horizontal scaling, allowing for the addition or removal of container instances based on demand. This scalability is crucial for optimizing resource use and maintaining performance across varying loads.

Session State Management

In containerized architectures, statelessness is paramount. Containers, designed to be ephemeral, should not maintain session states internally, as this can impede scalability. Opt for external storage solutions like Redis, SQL databases, or distributed caches to handle session states, ensuring your application remains scalable and responsive to load changes.

Dependency Management Strategies

Linux Compatibility

Migration to containerized environments often involves transitioning from Windows to Linux-based containers. Ensure that your application’s dependencies and libraries are compatible with Linux, and that your Dockerfile and container environment are configured accordingly.

Handling Internal Dependencies

Ensure all necessary libraries and components are either bundled within the container or accessible via network endpoints, enabling your application to function seamlessly in its containerized form.

Integrating with External Services

Containerization demands a dynamic approach to connecting with external services like databases and messaging systems. Implement configurations that allow for flexible service discovery and connections through environment variables or specialized discovery tools.

File and Network Access

File Access Considerations

The encapsulated filesystem within containers requires a strategic approach to file access. Unlike traditional deployments where applications might directly access local file paths, containerized applications should be designed with portability and flexibility in mind. Here are some strategies to consider:

Volume Mounts: Use Docker volumes or Kubernetes persistent volumes to persist data outside containers, enabling state persistence across container restarts and deployments. This approach is particularly useful for databases, logs, or any data that needs to survive beyond the container’s lifecycle.
Cloud Storage Services: For applications that require access to large amounts of data or need to share data across multiple instances, integrating with cloud storage services (like Azure Blob Storage, Amazon S3, or Google Cloud Storage) provides a scalable and secure solution. This not only decouples your application from the underlying infrastructure but also enhances scalability by leveraging the cloud provider’s global network.
File Permissions and Security: Carefully manage file permissions within the container to prevent unauthorized access. Ensure that your application runs with the least privileges necessary to access only the files it needs, enhancing security within the containerized environment.

Network Configuration and Service Discovery

Containers often run in orchestrated environments where networking is dynamically managed, and services discover each other through service discovery mechanisms rather than static IP addresses or hostnames. Consider these aspects to ensure robust network configurations:

Service Discovery: Utilize service discovery tools provided by container orchestration platforms (like Kubernetes DNS or Docker Swarm’s embedded DNS) to dynamically discover and communicate with other services within the cluster.
Container Networking Models: Familiarize yourself with the container network models (such as bridge, overlay, or host networks) and choose the appropriate model based on your application’s needs. For instance, overlay networks facilitate communication between containers across different hosts in a cluster.
Port Configuration and Exposition: Explicitly define and manage which ports are exposed by your container and how they are mapped to the host system. This is crucial for ensuring that your application’s services are accessible as intended while maintaining control over network security.

Identity and Authentication Adjustments

In containerized environments, traditional methods of managing identity and authentication may not directly apply. Here are ways to adapt:

Managed Identities for Azure Resources: Azure offers managed identities, automatically handling the management of credentials for accessing Azure services. This eliminates the need to store sensitive credentials in your application code or configuration.
OAuth and OpenID Connect: Implement OAuth 2.0 and OpenID Connect protocols to manage user identities and authenticate against identity providers. This approach is effective for applications that require user authentication and can be integrated with most identity providers.
Secrets Management: Use a secrets management tool (like Azure Key Vault, AWS Secrets Manager, or HashiCorp Vault) to securely store and access API keys, database connection strings, and other sensitive information. Modern container orchestration platforms, such as Kubernetes, offer native secrets management capabilities, allowing you to inject secrets into containers at runtime securely.
Role-Based Access Control (RBAC): Implement RBAC within your application and infrastructure to ensure that only authorized users and services can perform specific actions. This is particularly important in microservices architectures where different services may have different access requirements.

Configuration Management

Efficient configuration management emerges as a critical component in the containerization of .NET applications. The dynamic nature of containerized environments necessitates a flexible and secure approach to configuring applications, ensuring they can adapt to different environments without necessitating changes to the container images themselves.

The .NET ecosystem offers various strategies for managing configurations effectively, aligning with cloud-native best practices. There are configuration providers for reading settings from environment variables, JSON files, and other sources, enabling applications to adapt to different environments seamlessly. Here are some strategies to consider:

Environment Variables

Dynamic Configuration: Utilize environment variables to externalize configuration settings, enabling applications to adapt to various environments (development, staging, production) seamlessly.
Best Practices: Define environment variables in container orchestration configurations, such as Kubernetes manifests or Docker Compose files, to inject settings at runtime.

Configuration Files

Externalized Settings: Store configuration settings in external files (e.g., appsettings.json for .NET applications) that can be mounted into containers at runtime.
Volume Mounts: Use Docker volumes or Kubernetes ConfigMaps and Secrets to mount configuration files into containers, ensuring sensitive information is managed securely.

Centralized Configuration Services

Cloud Services: Leverage cloud-based configuration services like Azure App Configuration or AWS Parameter Store to centralize and manage application settings.
Service Discovery: Integrate service discovery mechanisms to dynamically locate services and resources, reducing the need for hard-coded configurations.

Secrets Management

Secure Storage: Utilize dedicated secrets management tools (e.g., Azure Key Vault, HashiCorp Vault) to securely store and manage sensitive configuration data such as passwords, tokens, and connection strings.
Runtime Injection: Automate the injection of secrets into containers at runtime using platforms like Kubernetes Secrets, CSI Secret Store, or specific cloud provider integrations.

Immutable Configurations

Immutable Infrastructure: Adopt an immutable infrastructure mindset, where configuration changes require redeploying containers rather than modifying running containers. This approach enhances consistency, reliability, and auditability across environments.

Configuration Drift Prevention

Version Control: Keep configuration files and definitions under version control to track changes and prevent configuration drift.
Continuous Integration: Integrate configuration management into the CI/CD pipeline, ensuring configurations are tested and validated before deployment.

Incorporating these configuration management strategies within the containerization process for .NET applications not only enhances flexibility and scalability but also bolsters security and compliance, aligning with best practices for cloud-native development.

Security and Compliance

In the realm of containerization, adherence to stringent security and compliance frameworks becomes paramount. The encapsulated nature of containers introduces unique security considerations:

Vulnerability Scanning: Implementing automated tools to scan container images for known vulnerabilities at each stage of the CI/CD pipeline ensures that only secure images are deployed.
Non-Root Privileges: Running containers as non-root users minimizes the risk of privileged escalations if a container is compromised. This practice is essential for limiting the attack surface and safeguarding the underlying host system.
Secrets Management: Securely handling secrets necessitates moving away from embedding sensitive information within container images or environment variables. Utilizing dedicated secrets management tools or services, such as Kubernetes Secrets, HashiCorp Vault, or Azure Key Vault, allows for dynamic, secure injection of credentials and keys at runtime.
Network Policies and Firewall Rules: Enforcing strict network policies and firewall rules to control inbound and outbound traffic to containers can prevent unauthorized access and mitigate potential attacks.
Read-Only Filesystems: Where applicable, configuring containers with read-only filesystems can prevent malicious attempts to alter the runtime environment, further enhancing security posture.
Continuous Monitoring and Logging: Implementing real-time monitoring and logging mechanisms to detect unusual activities and potential security breaches. Tools like Prometheus, Grafana, and ELK stack play a pivotal role in observing container behavior and ensuring operational integrity.

Tools, Frameworks, and Ecosystems

Distributed Application Runtime (DAPR)

DAPR (Distributed Application Runtime) has emerged as a transformative tool, simplifying the development of distributed applications. DAPR abstracts complex tasks such as state management, service discovery, and messaging into straightforward, consistent APIs, enabling developers to focus on business logic rather than infrastructure concerns. This abstraction is particularly beneficial in a containerized environment, where applications must be flexible, scalable, and capable of running across diverse platforms.

DAPR’s cloud-agnostic design ensures seamless integration with various cloud services, including Azure, without locking developers into a specific ecosystem. It supports dynamic configuration and facilitates local development, mirroring cloud environments on developers’ machines. By decoupling application logic from infrastructure intricacies, DAPR enhances portability and eases the transition of .NET applications into the cloud-native landscape, making it an indispensable tool for developers navigating the complexities of modern application development.

Azure Developer CLI

The Azure Developer CLI (azd) significantly streamlines the journey of containerizing and deploying .NET applications to the cloud. A pivotal feature, azd init, automates the scaffolding process, generating Dockerfiles and Azure resource definitions tailored to your project’s needs. This command is instrumental for developers seeking to swiftly prepare their applications for Azure, ensuring an optimized setup for either Azure Container Apps (ACA) or Azure Kubernetes Service (AKS). By abstracting the complexities of Docker and Kubernetes, azd allows developers to concentrate on building their applications, while effortlessly integrating with Azure’s robust cloud infrastructure.

.NET Aspire

.NET Aspire equips developers with an opinionated framework tailored for crafting observable, distributed .NET applications that are primed for cloud environments. It simplifies the development process by offering a curated collection of NuGet packages, each addressing specific cloud-native application challenges such as service integration, state management, and messaging. .NET Aspire stands out by facilitating the creation of microservices and distributed applications, enabling seamless service connections and promoting architectural best practices. This framework not only accelerates the development of cloud-ready .NET applications but also ensures they are scalable, resilient, and maintainable, aligning with the principles of modern, cloud-native development.

Conclusion

The journey to containerizing .NET applications is paved with considerations that span architecture, security, performance, and beyond. By addressing these aspects thoughtfully, developers can harness the full potential of containerization, ensuring their .NET applications are efficient, secure, and poised for the cloud-native future. Stay tuned for subsequent articles, where we’ll explore strategies and tools to navigate these considerations, empowering your .NET applications to excel in a containerized landscape.

Dev Containers - Part 1

Wed, 27 Dec 2023 00:00:00 +0000

This article is part of the Festive Tech Calendar 2023. For more articles in the series by other authors, visit https://festivetechcalendar.com/.

Dev Containers can revolutionize the way we approach development environments, offering a fast, consistent setup across different projects. As a developer who uses Dev Containers in VS Code for various projects, I’ve experienced firsthand the benefits of having an environment that’s ready to go as soon as I clone a project.

I use Dev Containers in VS Code or GitHub Codespaces for all my development work. I have a Dev Container for each project I work on. This ensures that I have a consistent environment for each project. It also allows me to quickly get up and running with a new project. I don’t have to worry about installing dependencies or setting up my environment. I can simply clone the project and start coding.

What are Dev Containers?

Dev Containers, or Development Containers, are an innovative tool for modern software development. They leverage the power of containerization technology, similar to Docker, to create isolated, consistent, and fully equipped development environments. Here’s what sets them apart:

Environment Isolation: Each Dev Container operates in its own isolated environment. This means that it can have its own set of tools, software dependencies, and settings, separate from the host machine and other containers. This isolation reduces “it works on my machine” problems, ensuring that the environment is consistent across all developers’ machines.
Flexibility and Versatility: Dev Containers can be tailored to support various programming languages, frameworks, and tools. They can range from simple environments with just a basic editor and runtime to more complex setups with databases, compilers, debuggers, and other tools.
Integration with Development Tools: Perhaps one of the most powerful features of Dev Containers is their integration with popular development tools like Visual Studio Code. This integration allows developers to use the rich features of their favorite IDEs, like IntelliSense, debuggers, and extensions, inside the container.

Why Use Dev Containers?

The adoption of Dev Containers in your development process can bring numerous advantages:

Rapid Onboarding and Consistency: New team members can get up and running quickly. Instead of spending time setting up their development environment, they can simply pull the Dev Container configuration and start coding. This process ensures that every team member works in an environment that is consistent with production and their peers, reducing “works on my machine” issues.
Reproducible Environments: Dev Containers ensure that the development environment is reproducible. This is critical when working with complex applications that require specific configurations, tools, or dependencies. With a Dev Container, these configurations are codified, making it easy to recreate the environment anytime.
Seamless CI/CD Integration: Dev Containers can be integrated with Continuous Integration and Continuous Deployment (CI/CD) pipelines. This ensures that the applications are built and tested in the same environment in which they were developed, leading to fewer surprises when moving from development to production.
Platform Independence: Developers can work on different operating systems or platforms without worrying about compatibility issues. The containerized environment abstracts away the underlying platform, allowing for a seamless development experience across Windows, macOS, and Linux.
Focus on Coding, Not Configuration: Dev Containers abstract away the need for developers to manage their development environment. This allows developers to focus on writing code, rather than spending time configuring and troubleshooting their local setup.

Solving Version Conflicts with Dev Containers: A Real-World Scenario

The Challenge of Multiple Projects with Different Dependencies

In software development, it’s common to work on multiple projects simultaneously. However, this can lead to significant challenges, particularly when these projects depend on different versions of languages or tools. Let’s consider an example involving Python or Node.js.

Imagine working on two separate projects: Project A and Project B. Project A requires Node.js 18, while Project B needs Node.js 20. Setting up these projects on the same development machine traditionally leads to version conflicts. Installing the dependencies for Project B might break Project A, and vice versa. This is a common headache for developers, leading to a lot of time spent on managing and troubleshooting environments rather than coding.

How Dev Containers Provide a Solution

Dev Containers offer an elegant solution to this problem. With Dev Containers, each project runs in its own isolated containerized environment. This isolation means you can have different versions of Python, Node.js, or any other dependencies in each container without them conflicting with each other

Isolation: Each Dev Container provides an isolated environment. You can configure Project A’s container with Node.js 18, and Project B’s container with Node.js 20.
Consistency: The environments remain consistent regardless of other projects. Setting up Project B won’t affect Project A at all.
Ease of Switching: Switching between projects is as simple as switching containers. There’s no need to reconfigure your environment or worry about conflicting versions.
Replicability: These containerized environments can be replicated across different machines or team members, ensuring that everyone is working in the same setup.
Specialized Configurations: Dev Containers can include specific configurations for each project, such as extensions, settings, and tools.

Real-World Applications of Dev Containers: CPython and Home Assistant

CPython: Streamlining Python Development

The CPython project, the source code of the Python programming language itself, is an excellent example of Dev Containers in action. CPython’s GitHub repository features a devcontainer.json file, which simplifies the setup process for contributors. This file specifies a Docker image tailored for Python development, ensuring that contributors have all the necessary tools and dependencies.

Key Features of CPython’s Dev Container

Specific Docker Image: The container uses an image with all dependencies required to build and test Python.
VS Code Extensions: Extensions like Python, C++, and Test Explorer are pre-configured, streamlining the development experience.
Consistent Settings: Settings are predefined to match the project’s coding standards, ensuring consistency across all contributions.

Home Assistant: Facilitating Smart Home Development

Home Assistant, an open-source home automation platform, also leverages Dev Containers to provide a consistent development environment. Their repository includes a devcontainer.json file, which sets up an environment with all the necessary dependencies and extensions for development.

Advantages for Home Assistant Contributors

Custom Docker Image: Ensures that all the specific requirements for developing Home Assistant are met, including the right versions of Python and other dependencies.
Predefined Extensions and Settings: The Dev Container includes extensions like pylint and pylance to align with the project’s development practices.
Ease of Contribution: New contributors can quickly set up a development environment that is consistent with the project’s standards, facilitating easier and more efficient contributions.

Tool Support for Dev Containers

Dev Containers are supported by a range of tools and services, each enhancing the development experience in unique ways. Here’s an overview of some of the key tools and integrations:

Visual Studio Code and Dev Containers Extension

Integrated Development Environment: Visual Studio Code, along with its Dev Containers extension, is a key component in the Dev Container ecosystem. It provides a full range of features for containerized development, including IntelliSense, debuggers, and various extensions.
Docker Integration:
- Local Connection: The extension seamlessly integrates with local Docker installations, allowing developers to easily build and manage containers on their machine.
- Remote Connection: Supports connecting to Docker in remote environments, such as VMs or cloud-hosted servers, enabling development in complex, distributed architectures.
Enhanced Workflow: This integration simplifies workflows by managing container lifecycles, port forwarding, and providing a consistent development environment regardless of the host system.

GitHub Codespaces

Cloud-Based Environments: Offers a range of VM options from 2 to 32 cores and up to 64 GB of memory for versatile cloud development.
Remote Access: Easily accessible for coding via the browser or Visual Studio Code.
Quick Setup: Features pre-configured environments for immediate project start-up and branch-specific setups from GitHub imports.
Editor Compatibility: Supports various editors, including the Codespaces web editor and Visual Studio Code.
Customizable Configurations: Tailor environments using devcontainer.json, with specific GitHub Codespaces properties.
Secure and Integrated: Ensures a secure development experience in ephemeral VMs, integrated with numerous development tools.

Visual Studio

C++ Project Support: Visual Studio 2022 version 17.4 and later includes Dev Containers support for C++ projects, enhancing workflows in Linux and embedded development contexts.

IntelliJ IDEA

Early Dev Containers Support: Offers preliminary support for Dev Containers, enabling both remote operation via SSH and local usage with Docker.

CodeSandbox

Web-Based and Cloud Development: CodeSandbox offers both an online IDE for rapid web development and cloud development environments running on a microVM architecture. It supports a range of specs and multiple editors, including the CodeSandbox web editor, VS Code, and the CodeSandbox iOS app.

DevPod

Flexible Environment Creation: DevPod is a client-only tool that creates reproducible developer environments based on devcontainer.json, compatible with various backends such as local machines, Kubernetes clusters, remote machines, or cloud VMs.

Dev Container CLI

Reference Implementation: The Dev Container CLI acts as the standard implementation for the Dev Container Spec, facilitating the creation and management of Dev Containers, particularly in CI/DevOps scenarios.

Building a Dev Container

You can build a Dev Container using the Command Palette in VS Code. This process involves choosing the right Dev Container for your project based on your needs.

Templates and Customizations

Dev Containers come with various templates and customization options:

Templates: Choose from base templates like Alpine, Debian, Ubuntu, or focus on specific languages or tools. Full list of templates.
Dockerfile or Docker Compose: You can use a Dockerfile or Docker Compose file to define and configure your Dev Container.
Customizations: Include features, extensions, settings, startup tasks, and networking configurations specific to your project.

Features

You can add various features to your Dev Container:

CLIs for cloud platforms like Azure, GitHub, GCP, AWS.
Tools like Terraform, Kubernetes.
Runtimes including Node, Python, Go, Java, .NET, PHP, Ruby, Rust, C/C++, C#.
Full list of features.

Samples

The vscode-remote-try-* repositories include sample Dev Containers for various languages and tools. These repositories are a great place to start if you’re new to Dev Containers.

Resources

Incorporating Dev Containers into your workflow can streamline development, ensuring consistency and efficiency. For more information, check out the following resources:

Dev Container Templates
Dev Container Features
VSCode: Dev Containers Tutorial
Beginner’s Series to Dev Containers
My Talk on Dev Containers: Codebytes/Dev-Containers

Containerizing .NET - Part 1

Sun, 03 Dec 2023 00:00:00 +0000

This article is part of C# Advent 2023. For more articles in the series by other authors, visit https://www.csadvent.christmas/.

This is the first in a series of articles on containerizing .NET applications. We’ll explore how to containerize .NET applications using Dockerfiles and dotnet publish. Containers have become an essential part of the DevOps ecosystem, offering a lightweight, portable, and scalable solution for deploying applications. This process is crucial for developers looking to streamline app deployment in containerized environments, focusing on efficiency, security, compliance, and more.

You can read the series of articles here:

What are Containers?

Containers are a lightweight, virtualized environment that provide an isolated space for running applications. Unlike traditional virtual machines that require a full-fledged operating system, containers share the host system’s kernel but encapsulate an application’s code, dependencies, and libraries in a self-contained unit. This encapsulation ensures uniform and consistent application performance across different computing environments.

Containers offer numerous benefits. They are efficient in terms of resource utilization, smaller in size, and require less overhead than virtual machines. Containers also enhance the portability of applications, enabling developers to easily move applications from local development machines to production servers. This portability, combined with their isolated nature, facilitates continuous integration and continuous deployment (CI/CD) practices, making containers a cornerstone of modern DevOps workflows. Moreover, containers help ensure software runs reliably when moved from one computing environment to another, mitigating the “it works on my machine” problem.

Dotnet with a Dockerfile

Building and packaging dotnet applications into Docker images has been straightforward and well-documented. The dotnet documentation provides an excellent starting point. A simple Dockerfile can build a dotnet application and package it into a Docker image, using multi-stage builds to keep the final image size small.

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build-env
WORKDIR /App

# Copy everything
COPY . ./
# Restore as distinct layers
RUN dotnet restore
# Build and publish a release
RUN dotnet publish -c Release -o out

# Build runtime image
FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /App
COPY --from=build-env /App/out .
ENTRYPOINT ["dotnet", "DotNet.Docker.dll"]

We can build this docker image by running the following command, where dotnet-docker is the name of the image.

docker build -t dotnet-docker .

I won’t go into all the details of a dockerfile or registries right now. We’ll cover that in a future article. However, while this approach is great for those wanting full control over the image-building process, it can be daunting for newcomers to containers or those who prefer to focus on building applications rather than managing Docker images.

Containerizing .NET with dotnet publish

.NET has a built-in mechanism for building and packaging applications into Docker images. This approach is ideal for those who want to focus on application development rather than managing Docker images. We’ll explore how to containerize .NET applications using dotnet publish. This method doesn’t require a Dockerfile. Instead, it uses a set of publish properties to build and package applications into Docker images.

Starting from scratch, we’ll containerize a simple dotnet application using the dotnet CLI.

Create a new dotnet console application

dotnet new console -o hello-containers

Let’s add the required nuget package, Microsoft.NET.Build.Containers

dotnet add package Microsoft.NET.Build.Containers

Now we can build and package our application into a docker image

dotnet publish -t:PublishContainer

At this point you should see something like the following:

MSBuild version 17.8.3+195e7f5a3 for .NET
 Determining projects to restore...
 All projects are up-to-date for restore.
 hello-containers -> /workspaces/dotnet-containers/hello-containers/bin/Release/net8.0/hello-containers.dll
 hello-containers -> /workspaces/dotnet-containers/hello-containers/bin/Release/net8.0/publish/
 Building image 'hello-containers' with tags 'latest' on top of base image 'mcr.microsoft.com/dotnet/runtime:8.0'.
 Pushed image 'hello-containers:latest' to local registry via 'docker'.

Notice that we didn’t have to create a Dockerfile, we didn’t have to manage dependencies, and we didn’t have to package our application into a docker image. Let’s compare the docker image we just created with the one we created earlier. The following is the docker image we created earlier using a Dockerfile.

$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
hello-containers latest 83963b52892f 5 seconds ago 193MB
dotnet-docker latest 2d24bdc0b15d 57 seconds ago 217MB

Making it Smaller

To make our images smaller, we have a few options. The first is to choose a smaller base image. Popular choices include Alpine, a lightweight Linux distribution, and Ubuntu Chiseled, a lightweight version of Ubuntu. Using these base images can significantly reduce the final image size.

By introducing the -p:ContainerFamily parameter, we can specify the image family; And the -p:ContainerRepository parameter we can name our image. By leveraging image families like Alpine and Ubuntu Chiseled, we can significantly reduce the final image size without trimming or optimizing via Native AOT (Ahead of Time compilation). We’ll cover those optimization techniques in a future article.

Alpine

Alpine Linux is a highly favored choice for container images, known for its lightweight nature and security-focused architecture. Its minimal footprint significantly enhances efficiency in resource usage, making it ideal for streamlined container images. This results in reduced overhead and improved performance in containerized applications. However, it’s important to consider certain aspects when using Alpine:

Resource Optimization: Alpine’s small size optimizes resource consumption.
Compliance: Minimal dependencies make it compliance-friendly.
Compatibility Note: Alpine uses musl libc instead of glibc, potentially leading to compatibility issues with glibc-dependent applications.

When using dotnet publish to containerize an application with Alpine, you can specify the container family as alpine to use this lightweight base image:

$ dotnet publish -t:PublishContainer -p:ContainerFamily=alpine -p:ContainerRepository=hello-containers-alpine
MSBuild version 17.8.3+195e7f5a3 for .NET
 Determining projects to restore...
 All projects are up-to-date for restore.
 hello-containers -> /workspaces/dotnet-containers/hello-containers/bin/Release/net8.0/hello-containers.dll
 hello-containers -> /workspaces/dotnet-containers/hello-containers/bin/Release/net8.0/publish/
 Building image 'hello-containers-alpine' with tags 'latest' on top of base image 'mcr.microsoft.com/dotnet/runtime:8.0-alpine'.
 Pushed image 'hello-containers-alpine:latest' to local registry via 'docker'.

The resulting base image, mcr.microsoft.com/dotnet/runtime:8.0-alpine, is smaller compared to the standard mcr.microsoft.com/dotnet/runtime:8.0. Here’s a comparison of image sizes:

$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
hello-containers-alpine latest 60a63389d474 18 seconds ago 82.7MB
hello-containers latest ae96d4d7ac36 23 seconds ago 193MB

This demonstrates that Alpine can significantly reduce image size, enhancing the efficiency of .NET containerized applications.

Ubuntu Chiseled

Ubuntu Chiseled is a lightweight, container-optimized version of the popular Ubuntu Linux distribution. Featuring ultra-small OCI images, it includes only the application and its runtime dependencies, leading to several key benefits:

Streamlined Design: The reduced footprint of Ubuntu Chiseled images enables lightweight maintenance and efficient resource utilization.
Enhanced Security: The focus on essential components minimizes security risks by reducing potential vulnerabilities.
Size Reduction: Compared to traditional Ubuntu images, Chiseled images are significantly smaller, comparable in size to Alpine, and offer glibc compatibility.
Fewer Components: With fewer components, there’s a reduced CVE exposure, aligning well with development and production environments.
Strong Support: Developed through a collaboration between Canonical and Microsoft, these images offer robust support, particularly suitable for .NET versions 6, 7, and 8.

The following example demonstrates containerizing a .NET application using Ubuntu Chiseled, showcasing the notable reduction in image size:

$ dotnet publish -t:PublishContainer -p:ContainerFamily=jammy-chiseled -p:ContainerRepository=hello-containers-chiseled
MSBuild version 17.8.3+195e7f5a3 for .NET
 Determining projects to restore...
 All projects are up-to-date for restore.
 hello-containers -> /workspaces/dotnet-containers/hello-containers/bin/Release/net8.0/hello-containers.dll
 hello-containers -> /workspaces/dotnet-containers/hello-containers/bin/Release/net8.0/publish/
 Building image 'hello-containers-chiseled' with tags 'latest' on top of base image 'mcr.microsoft.com/dotnet/runtime:8.0-jammy-chiseled'.
 Pushed image 'hello-containers-chiseled:latest' to local registry via 'docker'.

Notice how the base image was changed from mcr.microsoft.com/dotnet/runtime:8.0 to mcr.microsoft.com/dotnet/runtime:8.0-jammy-chiseled. This is a smaller base image, which results in a smaller final image. Let’s take a look at the size difference between the images.

$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
hello-containers-chiseled latest bfdb924079ab 6 seconds ago 85.7MB
hello-containers-alpine latest cde2172a1f17 6 minutes ago 82.7MB
hello-containers latest 83963b52892f 16 minutes ago 193MB
dotnet-docker latest 2d24bdc0b15d 17 minutes ago 217MB

The comparison illustrates how Ubuntu Chiseled effectively reduces the container image size, making it an efficient choice for cloud and containerized environments.

Streamlining with Project File Properties

Streamlining the deployment process in .NET can be achieved by integrating publish properties directly into the project file. This approach enhances compliance and security while reducing the likelihood of errors. Consider a typical .csproj file:

<Project Sdk="Microsoft.NET.Sdk">

 <PropertyGroup>
 <OutputType>Exe</OutputType>
 <TargetFramework>net8.0</TargetFramework>
 <ImplicitUsings>enable</ImplicitUsings>
 <Nullable>enable</Nullable>
 </PropertyGroup>

 <ItemGroup>
 <PackageReference Include="Microsoft.NET.Build.Containers" Version="8.0.100" />
 </ItemGroup>

</Project>

To streamline, we add container-specific properties directly into the .csproj:

<PropertyGroup>
 <!-- Existing properties -->
 <ContainerFamily>jammy-chiseled</ContainerFamily>
 <ContainerRepository>hello-containers-chiseled</ContainerRepository>
</PropertyGroup>

Our final csproj file looks like this:

<Project Sdk="Microsoft.NET.Sdk">

 <PropertyGroup>
 <OutputType>Exe</OutputType>
 <TargetFramework>net8.0</TargetFramework>
 <ImplicitUsings>enable</ImplicitUsings>
 <Nullable>enable</Nullable>
 <ContainerFamily>jammy-chiseled</ContainerFamily>
 <ContainerRepository>hello-containers-chiseled</ContainerRepository>
 </PropertyGroup>

 <ItemGroup>
 <PackageReference Include="Microsoft.NET.Build.Containers" Version="8.0.100" />
 </ItemGroup>

With these additions, the deployment command simplifies to:

dotnet publish -t:PublishContainer

This method eliminates the need to specify publish properties each time, as they are already defined in the project file. It ensures a consistent and repeatable process, making deployments smoother and more efficient.

Conclusion

Publishing .NET console apps as container images offers a range of options, like targeting specific Linux distributions or families. Each method has unique benefits in terms of size, security, compliance, composability, compatibility, and support. This approach signifies a move towards more specialized, purpose-built container images, shaping the future of cloud applications.

Thank you for joining me on this exploration of .NET and containers. Stay tuned for more insights and guides on containerizing .NET!

Resources

Two Incredible Years at Microsoft

Sun, 29 Oct 2023 00:00:00 +0000

Two Incredible Years at Microsoft: A Journey of Growth, Connection, and Remote Collaboration

As I sit at my desk, keyboard beneath my fingertips, I’m reminded that it’s been two years since I first embarked on my journey with Microsoft. Joining during COVID meant that I did not get the onboarding experiences of a lot of Microsoft employees, a trip and onboarding in Redmond. Today, as I write this reflection, I’m filled with a mixture of nostalgia and pride over how much I, and the team I belong to, have grown-despite the miles that separate us.

Virtual Teamwork

Even before my first day, I was living in Teams. I interviewed over Teams, went through NEO Training and onboarding over Teams. My day to day, my virtual office, is in Teams.

While I use and prefer Microsoft Teams over other tools, we do share a classic love-hate relationship. Some days, it’s the camera playing hide-and-seek, on others, it’s the audio doing the silent treatment or the occasional unexpected crash just to keep me on my toes. I’ve learned to embrace these quirks, and they’ve become an integral part of my remote work experience. For our team, Teams is a space where ideas, laughter, and solutions flow freely. We’ve faced challenges, celebrated victories, and everything in between, all while being fully remote.

My Evolving Team

When I joined Microsoft, I was brought on board with the Fast Track for Azure team, an integral part of Azure CXP, which is led by Billy Anders. Our team operates under the broader umbrella of C+AI, a division headed by Scott Guthrie. Being nestled within Azure engineering, our team plays a pivotal role in the larger organization that designs and nurtures Azure.

Earlier this year, our team felt the ripple effects of the widespread industry layoffs. Amidst these challenges, we embarked on a transformative journey, evolving into what we internally call Fast Track Gen 3. This transition is shifting our focus to Adoptability and resiliency challenges that our customers face. Through these times, we’ve solidified our bond, becoming more cohesive and even more dedicated to offering the best for our customers. In collaboration with various leaders across Microsoft, we’ve refined our focus, aiming for an enhanced experience for our clientele. I love how we’ve incorporated the principles of DevOps, especially methodologies like feedback loops, enhancing our processes and upscaling our deliverables.

The Power of Initiatives

Throughout these years, I’ve had the privilege of contributing to several groundbreaking initiatives-all from the comfort of my home:

Customers: Working with customers has been a truly enriching experience. I’ve had the opportunity to collaborate with several customers, helping them navigate the Azure ecosystem. I’ve been involved in several projects, from helping a customer migrate their on-premises infrastructure to Azure to assisting another customer in their journey to the cloud. We’ve helped customers with their DevOps journey, guiding them through the intricacies of Azure DevOps and pipelines. I’ve also been involved in several customer workshops, helping them understand the nuances of Azure and its offerings. I’ve taken their feedback and submitted it to our PGs building Azure. These interactions have been a great learning experience, and I’m grateful for the chance to work with such a diverse clientele.
Mentoring and Culture: My journey at Microsoft has been one of continuous growth and learning. One of the greatest privileges has been the chance to mentor several newcomers. Witnessing their progress and seeing them carve out their niches has been deeply rewarding. Beyond individual mentorship, I’ve been deeply involved in numerous cultural initiatives, particularly those focused on Diversity and Inclusion. My active participation in ERGs (Employee Resource Groups) like Blacks At Microsoft (BAM) and The Hispanic and Latinx Organization of Leaders in Action (HOLA) has been both enlightening and fulfilling. Taking what I’ve learned about allyship, I crafted a talk that I’ve been honored to present at multiple conferences. Every event and initiative reaffirms my pride in being part of a team that genuinely values diversity and inclusion.
Azure Architecture Center: Crafting content for the Azure Architecture Center, I delved deep into the intricacies of Azure, ensuring that our users have a clear roadmap. Each article, each tutorial felt like building bridges in the vast ecosystem of Microsoft’s offerings.
FTA Live: Engaging with our customers virtually brought both challenges and exhilaration. This was a great opportunity to scale our reach and connect with a wider audience. I’m proud to have been part of this initiative, which has now become a staple of our team.
WAF (Well Architected Framework): Being part of WAF reinforced my belief in creating robust and efficient architectures. I contributed to a few different areas in the past 2 years, like IoT, Security, and Operational Excellence. I’m excited to see how this initiative will evolve in the future.
IoT Training Pack: This was a great opportunity to collaborate with our IoT team and create a comprehensive training pack for some production scenarios. I feel it really helped plug a gap in some of our IoT offerings.

The AI Revolution

The past year has been a whirlwind in terms of AI shaping our daily routines. OpenAI’s creations, ChatGPT and Dalle, have found their way into many of our processes, making tasks smoother.

One tool that’s genuinely changed my workflow is GitHub Copilot. It’s not just another fancy tool on the list - I genuinely use Copilot every day. Its code suggestions often feel like having a co-developer beside me. Beyond just using these tools, I’ve delved deeper into the AI realm, learning about concepts like the semantic kernel, diving into prompt engineering, and even building internal AI tools and copilots. This continual learning and exploration at the forefront of technology is truly invigorating. And as Microsoft ventures further into the AI domain, it’s evident we’re all part of this exhilarating journey of technological evolution.

Future Focus: Content & Enablement

Looking ahead, my trajectory is clearly marked by two guiding stars: Content and Enablement. I am driven to produce content that not only explains Azure but also empowers its users. Beyond just explaining, I aim to unravel complex topics, making them accessible and comprehensible to all. I want to showcase the application of DevOps principles, from infrastructure as code (IaC), pipelines, to automation - demystifying these critical aspects of modern cloud computing.

Security, reliability, and scalability are pillars of any robust cloud service, and my goal is to enlighten users on best practices around these elements. Parallel to this, I’m passionate about championing enablement initiatives. My aspiration is to ensure that anyone interacting with Azure feels well-supported and is fully equipped to leverage its vast capabilities. Using the platform every day, I’m intimately familiar with its nuances and intricacies. Sharing this knowledge, making it accessible and actionable, is what drives me.

Speaking My Heart Out

One of the unexpected joys of this remote journey has been the myriad of speaking opportunities on Teams. From giving lightning talks during our weekly team sessions to presenting at FTA Live, these platforms have been avenues for both sharing and absorbing knowledge. More than just presentations, they’ve been a medium to assist coworkers, to exchange insights, and to foster a culture of continuous learning. Every virtual interaction, every blog post, and every lightning talk reinforces the fact that, thanks to technology, distances have become negligible and our world, smaller and more interconnected. The support and encouragement from my team to voice ideas and share experiences has been invaluable, proving that every member’s insights are cherished and essential.

Looking Ahead

As another year beckons, I’m energized by our past achievements and the endless horizon of future possibilities. Physical boundaries have been rendered irrelevant, and it’s the bond of purpose, our shared mission, that keeps us united.

I would be remiss if I didn’t extend my deepest gratitude to my incredible team, knowledgeable coworkers, and supportive managers. Your guidance, camaraderie, and unwavering support have been the backbone of every success and the silver lining in every challenge.

Thank you, Microsoft, for an unforgettable two years. To my team and everyone who’s been a part of this journey, thank you for making it truly special. Here’s to many more years filled with innovation, growth, and limitless connections!

Enhancing Your Workflow with the GitHub Actions VSCode Extension

Tue, 29 Aug 2023 00:00:00 +0000

In today’s dynamic software development landscape, every second counts. Maximizing efficiency and ensuring error-free processes are top priorities for developers. GitHub Actions has already revolutionized workflow automation, and the game has just been upped with the introduction of its new Visual Studio Code (VSCode) extension. This article will explore these innovative features, shedding light on how they can supercharge your development workflow.

GitHub Actions: Automating Software Workflows Efficiently

GitHub Actions stands as one of the most versatile tools in the developer’s toolkit, allowing for comprehensive automation of software workflows. Its strength lies in its seamless integration with GitHub, offering flexible and potent Continuous Integration/Continuous Deployment (CI/CD) capabilities without the reliance on external platforms. This integration ensures that developers can focus on coding while GitHub Actions takes care of the build, test, and deployment processes. From facilitating automated build checks to executing comprehensive test suites and ensuring smooth deployments, GitHub Actions is the one-stop solution for developers looking to enhance their CI/CD workflows.

Uniting VSCode with GitHub: An Enhanced Development Experience

Visual Studio Code (VSCode) is more than just a lightweight source code editor-it’s a hub that caters to developers’ evolving needs. Its extensive ecosystem of extensions ensures that its capabilities extend far beyond basic editing.

Merging the intuitive features of VSCode with the collaborative and version control strengths of GitHub transforms the development process. This integration allows developers to clone repositories, adjust code, stage commits, and push updates, all within a singular, cohesive environment. The outcome is a workflow designed for maximum efficiency and streamlined operations.

Introducing the New VSCode Extension for GitHub

The new VSCode extension for GitHub takes this integration a step further, providing you with a set of tools to manage and author workflows directly within your editor. The extension enables you to keep track of your workflows, view the run history, and get instant feedback about your workflow status.

Managing Workflows and Monitoring Workflow Runs

The new extension provides an interactive interface for managing your workflows. You can monitor the runs for workflows in your repository, cancel and re-run them, or even trigger new ones for manually triggered workflows, all within your editor.

Imagine you have a continuous integration workflow that runs for every pushed branch. You can edit your code, push it to GitHub, and then monitor the status of your workflows directly in VSCode. You can investigate failures by drilling down from runs to jobs to steps and even view logs without having to leave your editor. This immediate feedback allows you to quickly identify and fix issues, enhancing your productivity.

Workflow Authoring

The new VSCode extension for GitHub also significantly improves the process of authoring workflows. It provides syntax highlighting for workflows and expressions, integrated documentation for the workflow schema, expression functions, and even event payloads. This helps reduce the required context switches and speeds up workflow editing.

Streamlined Variable Handling

The extension’s simplified interface focuses on easy variable interactions. Whether you’re initiating a fresh workflow or adjusting a current one, adding or editing variables is straightforward.

For example, if you’re working with a deployment workflow that varies based on development stages, you can swiftly toggle between ‘development’, ‘staging’, or ‘production’ settings using defined variables. By making these adjustments directly in VSCode, you ensure that your workflows can adapt to different conditions without diving deep into complex configurations.

Conclusion

Combining GitHub Actions with VSCode simplifies a developer’s workflow, making it easier to manage and run projects. The new VSCode extension for GitHub is like adding a Swiss army knife to your toolset, allowing you to tackle various tasks in one place. This not only streamlines the coding process but also ensures that developers can easily adapt to new challenges. In essence, with these tools hand in hand, we’re better equipped for the future of software development.

References & Further Reading

Embedding Draw.io Diagrams in VSCode

Thu, 18 May 2023 00:00:00 +0000

If you’re like me, you love discovering new ways to boost your productivity and workflows. One of my favorite tools is Draw.io. I’ve used the desktop tool and the site, but I found a new integration that has significantly elevated my VSCode experience: the Draw.io Integration extension.

Draw.io

In the world of diagramming software, Draw.io really shines. It enables users to convert complex concepts and detailed workflows into clear, easy-to-understand diagrams. Its user-friendly interface combined with a wide-ranging set of features makes it an ideal choice for anyone needing to visually represent information.

Draw.io provides a wide variety of diagramming options. Whether you’re creating a basic flowchart, process diagram, org chart, UML, ER diagram, or network diagram, Draw.io has got you covered. Its versatility is one of the many reasons why it’s a reliable tool for users with diverse needs.

Draw.io is also incredibly user-friendly. Regardless of whether you’re new to diagramming or a seasoned pro, Draw.io is accessible and straightforward to navigate. It’s designed to help you quickly and accurately capture your ideas without requiring extensive training or having to navigate a steep learning curve.

Another significant aspect of Draw.io is its collaborative capabilities. It’s a fantastic choice for team projects as it allows you to share your diagrams and collaborate with others, fostering a cooperative environment and ensuring everyone stays on the same page.

And the cherry on top? All these fantastic features come at no cost. Draw.io is free to use, making it a universally accessible tool for individuals and teams.

The Draw.io Integration Extension by Henning Dieterichs

Draw.io’s reputation for ease of use and an extensive set of features is well-deserved. The Draw.io Integration extension brings this powerful functionality right into your VSCode environment, allowing you to create and edit diagrams without needing to switch back and forth between your code editor and a separate diagramming tool. This integration is a productivity booster, maintaining the flow of your workflow.

A standout feature of the Draw.io Integration extension is its unique approach to saving diagrams. You can save diagrams as drawio.png or drawio.svg files. These formats not only store the diagram as an image but also preserve the diagram data within the image metadata. This innovative feature means you can share diagrams as images viewable in any standard image viewer. If the recipients also use Draw.io or the hediet.vscode-drawio extension, they can even edit the diagrams, thanks to the original diagram data preserved in the image file.

Tips

To truly maximize the use of Draw.io within VSCode, you should not only leverage the diagramming functionality but also manage and integrate your diagrams effectively into your projects. Here are a few tips and tricks:

Save diagrams as drawio.png or drawio.svg files: Regularly saving your diagrams in these formats ensures you don’t lose your work. These formats also allow you (or others) to edit the diagrams later, courtesy of the diagram data stored within the image metadata.

Integrate diagrams into your Git repository: After saving your diagrams as drawio.png or drawio.svg files, you can conveniently add them to your Git repository. This integration allows you to version control your diagrams alongside your code and share them with others through the repository.
Reference diagrams directly in your Markdown files: Once your diagrams are stored in your Git repository, they can be directly referenced in your Markdown files. This includes README files, blog posts, or MARP presentations. To do this, use the standard Markdown image syntax, ![Alt text](url), where url is the path to your drawio.png or drawio.svg file in the repository. This technique enables a seamless integration of visual content into your written material.
Explore Draw.io’s extensive shape and icon libraries: Draw.io provides a vast library of shapes and icons that can help make your diagrams visually appealing and intuitive. Different shapes can represent various elements in your diagrams, enhancing their readability.
Use color and style strategically: Utilizing different colors and styles can aid in distinguishing between different elements in your diagrams. Strategic use of these features can improve the clarity of your diagrams and make them easier to interpret.

By adopting these tips and tricks, you can effectively manage your diagrams and seamlessly integrate them into your development workflow. This not only enhances communication within your team but also promotes a better understanding of the concepts you’re working with.

Other Features

Besides the features I’ve covered so far, the Draw.io Integration extension also provides a host of other functionalities. These include:

Offline support: By default, the extension uses an offline version of Draw.io.
Themes: Multiple Draw.io themes are available for users to choose from.
Collaboration: The extension supports collaborative editing of diagrams using VS Code Liveshare. Users can edit and present diagrams remotely, with participants able to see each other’s cursors and selections.
Code link feature: The extension includes a code link feature where users can enable or disable linking nodes/edges with code spans. Double-clicking on a node with a label starting with “#” performs a workspace search for a matching symbol, allowing users to jump to its source code.

Conclusion

The Draw.io Integration extension supports the integration of Draw.io into VSCode, providing a powerful and efficient way to create and manipulate diagrams. This feature-rich extension enables developers and other professionals to visualize their ideas and workflows without leaving their coding environment. Furthermore, the unique drawio.png and drawio.svg file formats ensure that your diagrams remain visually accessible and editable, making sharing and collaboration easier. This integration is a shining example of the flexibility and extensibility of the VSCode platform, demonstrating its ability to cater to a wide range of user needs, well beyond just writing code.

Optimizing VSCode Startup Time with Profiles

Tue, 16 May 2023 00:00:00 +0000

Visual Studio Code (VS Code) is a popular code editor that offers a wide range of extensions to enhance its functionality. However, having too many extensions installed can increase the startup time of the editor, which can be very annoying. In this blog post, we’ll explore how to optimize the startup time of VS Code by using profiles, a feature introduced in VS Code earlier this year.

What are VS Code Profiles?

In Visual Studio Code (VS Code), profiles are a feature that allows users to create sets of customizations for the editor. VS Code has a vast array of settings, thousands of extensions, and numerous ways to adjust the user interface layout in order to personalize the editor according to the user’s preferences. With VS Code Profiles, users can create and save different sets of customizations, and then quickly switch between them as needed. Additionally, users can share their profiles with others, making it easier to collaborate with a consistent development environment

Why Use Profiles?

VS Code Profiles can be used for various purposes, including the following:

Optimizing Multiple Work Scenarios: Users juggling diverse projects ranging from work assignments to personal open-source contributions and side gigs can leverage VS Code Profiles. These profiles permit the creation and swapping of distinct configurations, each tailored to meet the unique requirements of different tasks.
Facilitating Collaborative Coding: Profiles can standardize the coding environment across a team, mitigating configuration discrepancies and ensuring everyone works with the same set of tools.
Streamlining Training and Onboarding: Organizations can expedite the setup process for new hires or trainees by creating VS Code Profiles equipped with the requisite tools and configurations.
Managing Visual Preferences: For users fond of alternating between themes or appearances based on tasks or time, profiles can ease this transition.
Tailoring Language-Specific Environments: Developers dealing with multiple programming languages can create a profile for each, complete with relevant extensions, linters, and settings, promoting a more fluid workflow.
Supporting Learning of New Technologies: When embarking on learning a new technology or language, users can set up a separate profile equipped with all necessary tools and configurations, thereby fostering a more focused learning environment.
Enriching Educational Experiences: Profiles allow educators to craft VS Code setups, replete with specific extensions and settings suitable for particular classes such as computer science. Students can then access these custom setups, aiding in a more effective learning process.

Overall, VS Code Profiles provide a convenient way to manage and switch between different sets of customizations, ensuring that users have the optimal development environment for their current task or project.

Tips for Organizing Profiles

Keep a “Default” Profile: You may want to have a “default” profile with commonly used extensions that you find useful across all projects. This profile can serve as your go-to for general development tasks. Mine has my common font and color settings, as well as extensions like Dev Containers, Live Share, and GitHub Copilot.
Name Profiles Descriptively: Choose descriptive names for your profiles to make it easier to remember what each profile is intended for. For example, “Web Dev,” “Python,” or “Markdown Editing.”
Create Task-Specific Profiles: Consider creating profiles for specific tasks, such as web development, Python development, or Markdown editing. Include only the extensions relevant to each task in their respective profiles.

Profile	Extensions and Settings
.NET Development	C# Extension, NuGet Package Manager GUI, REST Client
Azure Development	Azure Extensions, AZ CLI, Azure Terraform, ARM Visualizer
Python Development	Python Extension, Pylance, Jupyter, Azure Functions
Markdown Editing	Markdown All in One, Markdown Preview Enhanced, Markdownlint

How to Create and Use Profiles

To create a new profile in VS Code, you can use two different methods.

Via the Settings Menu you can create, delete, export, and import profiles
Via the Command Palette, follow these steps:

Open the Command Palette (Ctrl+Shift+P or Cmd+Shift+P on macOS) and search for the “Profile:” command.
You can create, delete, export, and more from here.

To switch between profiles, use the “Profile: Switch Profile” command from the Manage menu or Command Palette and select the desired profile. This will activate the selected profile and reload the editor with the specified extensions and settings.

Suggestions

In my experience, creating a profile from scratch tends to reset various elements such as themes, custom fonts, and other personalized settings. As a workaround, I typically maintain my Default profile with my preferred configurations. When I need a new profile, I simply clone the Default one and then tailor it to my specific needs.

Conclusion

By using profiles in VS Code, you can optimize the startup time of your editor and ensure that only the necessary extensions are activated for each project or task. This not only improves performance but also helps you stay organized and focused on the task at hand. Give profiles a try, and experience a more streamlined coding environment!

Secure Terraform - Part 5 - Terraform State

Wed, 05 Apr 2023 00:00:00 +0000

This is part 5 of the Secure Terraform series. You can read the series of articles here:

Introduction

Terraform is an immensely popular Infrastructure as Code (IaC) tool that allows you to manage and provision infrastructure resources using configuration files and automation tools.

Securing your Terraform state is crucial for maintaining the integrity and security of your infrastructure. The state file contains a wealth of sensitive information, including resource configurations, connection details, and even secret values such as API keys and passwords. In the hands of bad actors, this data could be exploited to gain unauthorized access, launch attacks, or cause irreparable damage to your infrastructure. To protect your organization from these threats, it’s essential to understand the importance of securing your Terraform state and implement best practices that safeguard your infrastructure’s state data.

Why Secure Your Terraform State?

Securing your Terraform state is crucial for several reasons:

Prevent Unauthorized Access: A secure Terraform state prevents unauthorized individuals from gaining access to sensitive information about your infrastructure, which could be used for malicious purposes.
Maintain Infrastructure Integrity: By securing your Terraform state, you can ensure that your infrastructure remains in a consistent state and prevent unauthorized changes.
Avoid Infrastructure Drift: Securing your Terraform state helps prevent infrastructure drift, which can lead to inconsistencies and potential security vulnerabilities.
Safeguard Sensitive Data: Your Terraform state may contain sensitive data, such as API keys, passwords, and other secrets. Securing this data is essential to protect your organization from data breaches and other security risks.

Best Practices for Securing Terraform State

Here are some best practices to follow when securing your Terraform state:

1. Use Remote State Storage

Storing your Terraform state file remotely is a vital step in securing it. Remote state storage options, such as Azure Blob Storage, Amazon S3, or Google Cloud Storage, offer built-in encryption for data at rest and provide access control features that can help secure your Terraform state.

2. Enable Encryption at Rest

When using remote state storage, ensure that encryption is enabled for data at rest. This will protect your Terraform state from unauthorized access and prevent sensitive data from being exposed.

3. Implement Access Control

Implement access control mechanisms, such as role-based access control (RBAC), to limit who can access your Terraform state file. This will ensure that only authorized users can view or modify your infrastructure’s state.

4. Use Versioning

Enable versioning for your remote state storage. This allows you to maintain a history of your Terraform state and makes it possible to roll back to a previous state if necessary.

5. Lock Your State

When working with a team, it’s essential to lock your Terraform state during operations. This prevents multiple users from making changes simultaneously and causing conflicts or inconsistencies in your infrastructure’s state.

6. Perform Regular Audits

Regularly audit your Terraform state to ensure that it remains secure and up-to-date. This can help identify potential vulnerabilities and ensure that your infrastructure is compliant with your organization’s security policies.

Conclusion

Securing your Terraform state is a critical aspect of managing your infrastructure with Terraform. By following the best practices outlined above, you can protect your organization from unauthorized access, maintain the integrity of your infrastructure, and safeguard sensitive data. By doing so, you can ensure that your infrastructure remains secure and reliable throughout its lifecycle.

Unleash Your Creativity with Marp Presentation Customization

Fri, 31 Mar 2023 00:00:00 +0000

This is part 2 of the MARP series. You can read the series of articles here:

Introduction

Marp is a powerful Markdown presentation framework that enables you to create stunning slides effortlessly. By using simple text-based formatting, you can easily customize your presentations to suit your unique needs and style. Although Marp provides built-in themes and configurations, the true potential of this framework can be realized by customizing your presentations to suit your unique needs and style. In this blog post, we will delve into some of the key customization options available in Marp and guide you through the process of creating a truly standout presentation.

Built-in Themes

Marp comes with three built-in themes that you can use to get started. The three themes, Default, Gaia, and Uncover, are shown below along with the frontmatter to use them and a few inverted examples.

Default Theme

Default - Normal

---
marp: true
theme: default
---

Default - Inverted

---
marp: true
theme: default
class:
 - invert
---

Gaia Theme

Gaia Normal

---
marp: true
theme: gaia
---

Gaia - Lead / Invert

---
marp: true
theme: gaia
class:
 - invert
 - lead
---

Uncover

Uncover Normal

---
marp: true
theme: uncover
---

Directives

Directives are commands that you can use to customize your slides. They allow you to control the appearance, layout, and behavior of your presentation. Many of the directives apply globally to the entire presentation, but some are local and only apply to the current slide. A few of the directives include:

fit
backgroundColor
color
header
footer
class
paginate
many more…

To learn more about the directives and see more examples, check out the Marp documentation.

Custom Themes

Marp’s built-in themes serve as an excellent starting point. In the marp-slides-template repository, we demonstrate how you can extend a theme. Let’s take a look at the CSS file, custom-default.css:

/* custom-default.css */
/* @theme custom-default */

@import 'default';

section {
 /* Override default background */
 background: #fff;
}

The crucial aspect for the Marp theme engine is the theme directive: @theme custom-default. This theme name is what you’ll use in your slides. To link it to your Markdown file, apply the theme option in the front matter:

---
marp: true
theme: custom-default
---

In your CSS file, override or extend Marp’s default styles to craft your unique appearance. For instance, you can modify the background color, font, or slide transitions. For a comprehensive list of available style properties, refer to the Marp documentation: https://marpit.marp.app/theme-css.

Backgrounds and Images

Backgrounds

Adding custom backgrounds and images can make your presentation more engaging and visually appealing. To add a background image to a specific slide, use the following syntax:

![bg](path/to/your/background-image.jpg)

You can also use keywords to control how the background shows up. For instance, you can you left or right:

![bg right](path/to/your/background-image.jpg)

![bg left](path/to/your/background-image.jpg)

Another option is to specify a percentage, like if you wanted the image to only take up a smaller percentage.

![bg left:35%](path/to/your/background-image.jpg)

Marp left background - 35%

There are also a bunch of filters that you can apply to your images to get various styles, like grayscale, sepia, blur, and opacity.

These filters apply to not only backgrounds, but regular images. You can also combine them.

You can also add background colors and gradients using CSS.

Inline CSS

Another thing I’ve done is add inline CSS to my slides. I’ve also enabled HTML tags in my slides, so I can use divs and classes besides the standard Markdown syntax. To do this, you can use the following syntax in your frontmatter.

---
marp: true
theme: default
style: |
 .columns {
 display: grid;
 grid-template-columns: repeat(2, minmax(0, 1fr));
 gap: 1rem;
 }
---

We can then use these classes in our slides and mix and match Markdown and HTML if needed.

---

![bg opacity](https://picsum.photos/800/600?image=53)

## Slide 5

<div class="columns">
<div>

## Left

- 1
- 2

</div>
<div>

## Right

- 3
- 4

</div>
</div>

In this example, I’m adding a grid layout to my slides so I have have split columns. You can add any CSS you want here.

Font Awesome

Font Awesome is a great resource for designers, developers, and content creators who want to add visual elements to their projects without having to create them from scratch. Font Awesome provides a library of over 2,000 free icons that you can use to enhance your presentations.

To do this, you can use the following syntax in your frontmatter to import and style icons.

---
marp: true
theme: default
style: |
 .fa-twitter { color: aqua; }
 .fa-mastodon { color: purple; }
 .fa-linkedin { color: blue; }
 .fa-window-maximize { color: skyblue; }
 @import 'https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.3.0/css/all.min.css'
---

And then in your slides, you can use the following syntax to add icons.

## Slide 6

<i class="fa-brands fa-twitter"></i> Twitter:
<i class="fa-brands fa-mastodon"></i> Mastodon:
<i class="fa-brands fa-linkedin"></i> LinkedIn:
<i class="fa fa-window-maximize"></i> Blog:
<i class="fa-brands fa-github"></i> GitHub:

Mermaid Support

Marp also supports Mermaid, a JavaScript library for generating diagrams and flowcharts from text. Mermaid provides an easy way to create visual representations of complex ideas and concepts, and it integrates seamlessly with Markdown syntax.

To use Mermaid diagrams in your Marp presentation, you need to add the following script to your Markdown file:

<!-- Add this anywhere in your Markdown file -->
<script type="module">
 import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs';
 mermaid.initialize({ startOnLoad: true });
</script>

You can then create Mermaid diagrams using the div element with the mermaid class. For example:

# Mermaid

<div class="mermaid">
graph TD;
 A-->B;
 A-->C;
 B-->D;
 C-->D;
</div>

Marp will automatically convert this code into a diagram, which you can then style using CSS. By default, Mermaid diagrams are quite small, but you can adjust their size using CSS. This CSS code will make your Mermaid diagrams larger and easier to read. You can add this code to the frontmatter section of your Markdown file.

svg[id^='mermaid-'] {
 min-width: 480px;
 max-width: 960px;
 min-height: 360px;
 max-height: 600px;
}

And we get the following:

Note that out of the box, VS Code doesn’t support Mermaid diagrams with a preview, but you can add this feature using the Markdown Preview Mermaid Support extension. This extension adds support for Mermaid diagrams in the preview pane of VS Code.

Speaker Mode

Marp comes with a built-in speaker mode that allows presenters to view their notes and upcoming slides while giving a presentation. To enable speaker mode:

Export your presentation to HTML (you can also use my template and leverage GitHub Pages).
Open your Marp presentation file in your browser.
Press “P” on your keyboard or click on the icon for speaker mode.

A new window will open, displaying the current slide, next slide, and speaker notes.

Adding Speaker Notes

To add speaker notes to your Marp slides, use the following syntax:

---
<!-- Your speaker notes go here. -->

<!--
Or Your speaker
notes go here.
-->
---

This will create a hidden area for your speaker notes, which will be visible only in speaker mode. You can also export them to PowerPoints and PDF.

Conclusion

In conclusion, Marp is a powerful and flexible presentation tool that can help you create stunning slides with ease. Unlike traditional presentation tools like PowerPoint, Marp uses Markdown, a lightweight markup language that allows you to focus on your content without getting bogged down in formatting details. With Marp, you can easily customize your presentations with custom themes, images, CSS, and other features, making your slides truly stand out. Additionally, Marp is free and open-source, so you don’t have to worry about licensing fees or vendor lock-in. Overall, Marp is a fantastic alternative to traditional presentation tools, and we encourage you to give it a try!

Get started today by using the Marp Slides Template to create your own Marp presentation!

References

Marp - Create Presentations with Markdown

Sun, 26 Mar 2023 00:00:00 +0000

This is part 1 of the MARP series. You can read the series of articles here:

Introduction

Marp is a powerful and user-friendly presentation framework that simplifies the process of creating visually appealing slide decks using Markdown. In this blog post, we’ll explore what Marp is, why you might want to use it, how to get started. I’ll share my process and show you how you can automate hosting your presentations on GitHub Pages using GitHub Actions.

What is Marp?

Marp is an open-source presentation framework that allows you to create beautiful, customizable slide decks using the simplicity and flexibility of Markdown. By harnessing the power of Markdown, Marp enables you to focus on your content and message without getting bogged down in complex formatting and design choices. Marp has CLI and VS Code extensions, and it supports exporting presentations to various formats, including HTML, PDF, and PowerPoint.

Why Use Marp?

There are several reasons why you might want to consider using Marp for your presentations:

Simplicity: Marp allows you to write your presentations in plain text using the intuitive Markdown syntax, which is easy to learn and use.
Focus on content: With Marp, you can concentrate on your message and content without worrying about complex formatting and design choices.
Customizable: Marp offers a range of customization options, allowing you to create presentations that align with your personal style and preferences.
Integration with Visual Studio Code: Marp seamlessly integrates with the popular Visual Studio Code editor, providing real-time previews and a smooth workflow for creating and editing presentations.
Export options: Marp supports exporting presentations to various formats, including HTML, PDF, and PowerPoint.

Working with Marp

For me, the ideal way to interact and work with Marp is through the Marp for VS Code extension. This extension provides a seamless workflow for creating and editing presentations in Visual Studio Code. It also offers real-time previews, allowing you to see your presentation as you write it.

To get started, install the Marp for VS Code extension and open a new Markdown file. You can then start writing your presentation. A sample presentation is shown below:

---
marp: true
---

# My Presentation

---

## Slide 1

- Item 1
- Item 2
- Item 3

---

## Slide 2

![Image](https://picsum.photos/800/600)

---

## Slide 3

> This is a quote.

---

## Slide 4

| Column 1 | Column 2 |
| -------- | -------- |
| Item 1 | Item 2 |
| Item 3 | Item 4 |

Once you’ve added the content to VSCode with Marp, your presentation will look like this:

Official Themes and Resources

Marp comes with a few built-in themes that you can use as a starting point for your custom themes or as inspiration for your own designs. You can also refer to the Marpit documentation for more information on styling Marp presentations. There is good documentation on image sizing and positioning on the Marp site.

GitHub Pages and Marp

I have created a GitHub repository for each of my talks. For each talk, I have a slides folder that contains the Markdown files for the presentation. All images are stored in slides/img. I use GitHub Pages to host the HTML files, which allows me to share the presentation with others. I use a GitHub Actions workflow that automatically builds and publishes the presentation to GitHub Pages whenever I push changes to the slides folder. This workflow is shown below:

name: Deploy marp site to Pages

on:
 # Runs on pushes targeting the default branch
 push:
 branches: ['main']

 # Allows you to run this workflow manually from the Actions tab
 workflow_dispatch:

# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
 contents: read
 pages: write
 id-token: write

# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
concurrency:
 group: 'pages'
 cancel-in-progress: false

jobs:
 # Build job
 build:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 - name: Copy images
 run: mkdir build && cp -R slides/img build/img

 - name: Marp Build (README)
 uses: docker://marpteam/marp-cli:v1.7.0
 with:
 args: slides/Slides.md -o build/index.html --html
 env:
 MARP_USER: root:root
 - name: Setup Pages
 uses: actions/configure-pages@v3
 - name: Upload artifact
 uses: actions/upload-pages-artifact@v1
 with:
 # Upload entire repository
 path: 'build'
 - name: Deploy to GitHub Pages
 id: deployment
 uses: actions/deploy-pages@v1

Marp Template

I’ve created a marp-slides-template, which provides a minimal template to create a Marp site that can be built and published on GitHub Pages. This template comes with a GitHub Pages / Actions workflow, allowing you to easily build and publish your Marp presentation on GitHub Pages. With this template, you can quickly create and customize your presentation, preview it in Visual Studio Code using the Marp extension, and then share it with the world by publishing it to GitHub Pages. You can use the template by clicking on the link or visiting the repository and clicking on the “Use this template” button.

Conclusion

Marp is a powerful, flexible, and user-friendly presentation framework that simplifies the process of creating visually appealing slide decks. By harnessing the simplicity of Markdown and offering a range of customization options, Marp enables you to focus on your content and message without getting bogged down in complex formatting and design choices. With its seamless integration into Visual Studio Code and various export options, Marp is an excellent choice for anyone looking to streamline their presentation creation process. Check out the official documentation and repositories to get started on creating your next presentation with Marp today.

Resources

Some of my Marp Presentations

Official Repos and Docs

For more information on Marp and to dive deeper into its features and capabilities, check out the following resources:

CommonMark Markdown syntax: https://commonmark.org/help/
Marp Official Repository: https://github.com/marp-team/marp
Marp Official Documentation: https://marpit.marp.app/markdown
Marp for VS Code Documentation: https://marketplace.visualstudio.com/items?itemName=marp-team.marp-vscode

Secure Terraform - Part 4 - checkov

Fri, 24 Mar 2023 00:00:00 +0000

This is part 4 of the Secure Terraform series. You can read the series of articles here:

Introduction

In this fourth installment of our Secure Terraform series, we’ll discuss Checkov, a powerful open-source static code analysis tool supported by Bridgecrew. Checkov supports Terraform, Kubernetes, Dockerfiles, AWS CloudFormation, and other Infrastructure as Code (IaC) frameworks. It focuses on security best practices, policy compliance, and industry standards. You can find Checkov’s documentation and samples at https://www.checkov.io/.

Checkov Installation and CLI

Checkov can be easily installed using pip, a package installer for Python:

pip install checkov

Alternatively, you can install Checkov using Docker:

docker pull bridgecrew/checkov

Once installed, Checkov provides a command-line interface (CLI) to scan your IaC files. To scan your Terraform code, navigate to your project’s root directory and run the following command:

checkov -d .

Checkov will then analyze your Terraform files, checking for security and compliance issues. It will output the results, including the test status (PASSED or FAILED), file paths, resource types, and relevant information about the issue.

You can customize the output format using the –output flag. Checkov supports various output formats, including JSON, JUnit XML, and SARIF:

checkov -d . --output json

Checkov extensions for VS Code

Checkov provides extensions for VS Code and other IDEs, allowing you to scan your Terraform code directly from your code editor. This is a convenient way to scan your code as you write it, ensuring that you don’t introduce any security or compliance issues.

To install the Checkov extension for VS Code, search for “Checkov” in the Extensions tab or install it from the marketplace.

You can scan your code and view the results in the Checkov Output tab. You can also view the results in the Problems tab, which provides a convenient way to navigate to the specific line of code that caused the issue.

And if you hold your cursor over the issue, you can see the violations and links to the related checks.

If you click on the check, you’ll get a pop-up and follow the link to the Checkov documentation.

This is an amazing developer experience, allowing you to scan your code as you write it and fix any issues immediately.

Checkov in CI/CD Pipelines

Integrating Checkov into your CI/CD pipeline helps ensure that your infrastructure is secure and compliant with every code change. Here’s an example of how to integrate Checkov into a GitHub Actions pipeline:

name: Checkov
on:
 push:
 branches:
 - main
jobs:
 build:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v2
 - name: Set up Python 3.8
 uses: actions/setup-python@v1
 with:
 python-version: 3.8
 - name: Test with Checkov
 id: checkov
 uses: bridgecrewio/checkov-action@master
 with:
 directory: example/examplea
 framework: terraform

This example workflow triggers on push and pull_request events for the main branch. It checks out the repository, sets up Python, installs Checkov, and runs a scan on the specified Terraform files.

Custom Policies and Suppressions

Checkov supports custom policies written in Python or Yaml. You can create a custom policy by following these steps:

Create a new directory for your custom policies, e.g., custom_policies.
Inside the custom_policies directory, create a new Python or Yaml file for your custom rule, e.g., my_custom_rule.py or my_custom_rule.yaml.
Write your custom rule using Python or the Yaml language. Refer to the Checkov documentation for guidance on writing custom policies.

In addition to custom policies, Checkov allows you to suppress specific checks or resources using inline comments in your Terraform code.

This can be useful when you want to exclude certain resources from specific checks. To suppress a check, add the following comment above the resource block:

# checkov:skip=CKV_AZURE_123:This check is not applicable for this resource
resource "azurerm_storage_account" "example" {
 # ...
}

In this example, the CKV_AZURE_123 check will be skipped for the azurerm_storage_account resource with a reason “This check is not applicable for this resource.”

Conclusion

Checkov serves as a robust tool to bolster the security and compliance of your Terraform code. By seamlessly integrating Checkov into your development workflow, CI/CD pipeline, and leveraging it with your code editor, you can proactively tackle potential security risks and policy violations during the development stage itself.

The adaptability of Checkov, with its support for custom policies and the ability to selectively suppress checks, empowers organizations to customize the tool to align with their specific security objectives.

Utilizing tools like Checkov, along with others like tfsec and Terrascan, plays a pivotal role in creating and sustaining a secure and compliant infrastructure in today’s rapidly evolving landscape, where Infrastructure as Code has become a fundamental component of modern development practices.

Secure Terraform - Part 3 - terrascan

Wed, 22 Mar 2023 00:00:00 +0000

This is part 3 of the Secure Terraform series. You can read the series of articles here:

Introduction

Terrascan is another great tool for terraform security from tenable.

Terrascan is an open-source static code analysis tool for security compliance of your Infrastructure as Code (IaC). It has rules for various platforms, including Kubernetes, Dockerfile, AWS, Azure, GCP, and Terraform. It is developed in GoLang and has a CLI, API, and Jenkins plugin. Terrascan can be used to scan your IaC files for security vulnerabilities and policy violations. It can help you identify security issues before you deploy your code, and it can also help you enforce compliance policies.

You can see a lot of relevant documentation at: runterrascan.io.

Terrascan CLI

In addition to tfsec, there is another static code analysis tool for Terraform called Terrascan. Terrascan is open source and supported by tenable.

You can download the Terrascan CLI from the official GitHub repository: https://github.com/accurics/terrascan/releases.

It is available for Windows, macOS, Linux, and docker.

Once you have the Terrascan CLI installed, you can use it to scan your Terraform code. Terrascan comes with a number of pre-built policies that you can use. Policies define a set of rules that you want to enforce on your Terraform code. You can also create your own custom policies.

To scan your Terraform code using Terrascan, navigate to the root directory of your project and run the following command:

terrascan scan

By default, Terrascan will scan all Terraform files in the current directory and its subdirectories. You can specify a different directory by passing the --path option:

terrascan scan --path=path/to/terraform/files

Terrascan will output a list of violations that it found in your code. Each violation will have a rule ID, a description, and a severity level. The severity level can be either HIGH, MEDIUM, or LOW. The output will also include the filename, line number, and column number where the violation was found.

You can specify a different output format using the --format option. Terrascan supports a number of output formats, including JSON, YAML, and JUnit. Here’s an example of how to output the results in JSON format:

terrascan scan --format=json > output.json

You can also specify a policy path using the --policy-path option. By default, Terrascan will use the policies that are included with the tool. However, you can also use your own custom policies by specifying a policy path:

terrascan scan --policy-path=path/to/policies

Terrascan also supports scanning remote Terraform modules. You can use the --remote option to scan a remote module:

terrascan scan --remote=github.com/tenable/terrascan

Terrascan supports a number of other options and flags that you can use. You can view the full list of options by running terrascan help scan.

Terrascan in CI/CD Pipelines

Integrating Terrascan into your CI/CD pipeline is an essential step in ensuring the security of your infrastructure. By adding Terrascan to your pipeline, you can automatically scan your Terraform code for security vulnerabilities and policy violations every time you commit changes.

Here’s an example of how to integrate Terrascan into a GitHub Actions pipeline:

name: terrascan
on:
 push:
 branches:
 - main
 pull_request:

permissions:
 checks: write
 pull-requests: write

jobs:
 terrascan_job:
 runs-on: ubuntu-latest
 name: terrascan-action
 steps:
 - name: Checkout repository
 uses: actions/checkout@v2
 - name: Run Terrascan
 id: terrascan
 uses: tenable/terrascan-action@main
 with:
 iac_type: 'terraform'
 #iac_version: 'v14'
 #policy_type: 'azure'
 only_warn: false
 #scm_token: ${{ secrets.ACCESS_TOKEN }}
 verbose: true
 sarif_upload: true
 #non_recursive:
 #iac_dir: demos
 #policy_path:
 #skip_rules:
 #config_path:
 #find_vulnerabilities:
 #webhook_url:
 #webhook_token:

In this example, the workflow is triggered on push and pull_request events for the main branch. The workflow checks out the repository, sets up Go, installs Terrascan, and then runs a scan on the specified Terraform files.

Custom Policies and Rules

Terrascan allows you to create custom policies and rules to enforce specific security and compliance requirements. You can write custom policies in Rego, a high-level declarative language used by the Open Policy Agent (OPA) project.

To create a custom policy, follow these steps:

Create a new directory for your custom policies, e.g., custom_policies.
Inside the custom_policies directory, create a new Rego file for your custom rule, e.g., my_custom_rule.rego.

Write your custom rule using the Rego language. Refer to the OPA documentation for guidance on writing Rego policies.

package accurics

azureKeyVaultSoftDeleteRetentionDays[resource.id] {
 resource := input.azurerm_key_vault[_]
 resource.type == "azurerm_key_vault"
 properties := resource.config
 properties.soft_delete_retention_days < 14
}

Create the Rule json metadata file

{
 "name": "azureKeyVaultSoftDeleteRetentionDays",
 "file": "azureKeyVaultSoftDeleteRetentionDays.rego",
 "policy_type": "azure",
 "resource_type": "azurerm_key_vault",
 "template_args": {},
 "severity": "MEDIUM",
 "description": "Key Vault Soft Delete Retention Days should be more than 14 days",
 "category": "Data Protection",
 "version": 1,
 "id": "AC_AZURE_1000"
}

Once you have created your custom policy, you can use the --policy-path option with Terrascan to include your custom policies in the scan:

terrascan scan -p custom_policies/ -p ~/.terrascan/pkg/policies/opa/rego

If there are errors, you should get output like the following:

Conclusion

Terrascan is a powerful tool that can help you improve the security and compliance of your Terraform code. By integrating Terrascan into your development process, including your CI/CD pipeline and using it alongside your code editor, you can catch potential security vulnerabilities and policy violations early on.

With its support for custom policies, Terrascan allows you to tailor its scanning capabilities to meet your organization’s specific requirements.

In conclusion, using tools like Terrascan, alongside others like tfsec, is an essential part of maintaining a secure and compliant infrastructure in a world increasingly reliant on Infrastructure as Code.

Secure Terraform - Part 2 - tfsec Customization

Sun, 29 Jan 2023 00:00:00 +0000

This is part 2 of the Secure Terraform series. You can read the series of articles here:

Introduction

In the previous article, we discussed tfsec, a static code analysis tool for Terraform. We also learned how to use it in VSCode and GitHub Actions to scan our Terraform code. We learned how to override the severity of rules. In this article, we will learn how to customize the rules and add our own rules.

Customizing tfsec Rules

Tfsec allows you to customize the rules that are used to scan your Terraform code. You can do this by creating a file ending in _tfchecks.json or _tfchecks.yaml in the .tfsec folder in the root of project. You can also put these files in a different folder and pass the option --custom-check-dir or --custom-check-url to the tfsec command. This is covered in the documentation: https://aquasecurity.github.io/tfsec/v1.28.1/guides/configuration/custom-checks/.

The documentation references a tool called tfsec-checkgen that you can install. This tool will validate your check file or help perform tests to ensure that it is valid for use with tfsec. I found that the tool helped me create and validate checks but not run the test-check action.

In this post, we will take a look at how to create a few different custom rules. The first rule we’ll work on is for a required tag for our Azure resources. There is an example of this in the tfsec documentation, but its for AWS.

---
checks:
 - code: CUS001
 description: Custom check to ensure the CostCentre tag is applied to EC2 instances
 impact: By not having CostCentre we can't keep track of billing
 resolution: Add the CostCentre tag
 requiredTypes:
 - resource
 requiredLabels:
 - aws_instance
 severity: ERROR
 matchSpec:
 name: tags
 action: contains
 value: CostCentre
 errorMessage: The required CostCentre tag was missing
 relatedLinks:
 - http://internal.acmecorp.com/standards/aws/tagging.html

Lets look at my Azure example and discuss the tweaks and how to use it.

---
checks:
 - code: tags-resources
 description: Custom check to ensure the CostCenter tag is applied to Azure Resources
 impact: By not having CostCenter we can't keep track of billing
 resolution: Add the CostCenter tag
 requiredTypes:
 - resource
 requiredLabels:
 - azurerm_subscription
 - azurerm_resource_group
 - azurerm_linux_web_app
 - azurerm_windows_web_app
 - azurerm_storage_account
 - azurerm_service_plan
 - azurerm_app_service
 severity: HIGH
 matchSpec:
 name: tags
 action: contains
 value: CostCenter
 errorMessage: The required CostCenter tag was missing
 relatedLinks:
 - https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-tagging

I’ve changed the name to tags-resources to make it more descriptive. I’ve also changed the requiredLabels to include the resources I want to check for the tag. This rule will only trigger on the resource types listed under requiredLabels. I’ve also changed the severity to HIGH. I’ve also added a link to the Azure Best Practices for Resource Tagging.

This is saved to .tfsec/custom_tfchecks.yaml. The tfsec vscode extension we installed before will automatically pick up the new rule. We can see it highlighting the code with an issue and showing up in the results screen.

Issues also show up as problems at the bottom of the screen for you to see, click on, and navigate to the right code section.

A Custom Rule for Naming

Let’s try something a little more complex. We can try to enforce a naming scheme for our resources. I want to enforce a naming scheme that all resource groups must follow a pattern of rg-app-env-region. This will help us identify which resources belong to which applications or environments. This is a great way to enforce a naming scheme and keep things organized.

- code: rg-naming-pattern
 description: Custom check to check resource group naming
 impact: resource groups should be named consistently
 resolution: use the pattern rg-app-env-region
 requiredTypes:
 - resource
 requiredLabels:
 - azurerm_resource_group
 severity: HIGH
 matchSpec:
 name: name
 action: regexMatches
 value: '^rg-[a-zA-Z]+-[a-zA-Z]+-[a-zA-Z]+'
 errorMessage: improperly named resource group
 relatedLinks:
 - https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming

This rule, only checks against resource groups as identified by the requiredLabels property containing azurerm_resource_group. The matchSpec uses the regexMatches action. I am able to provide my regular expression and the error message. There are a bunch of provided check actions that you can use to develop your custom checks.

Custom Checks for Deprecated Resources

Tfsec also allows you to create custom checks for deprecated resources. This is a great way to keep up with the latest changes in Terraform and Azure. I’ve created a custom check for the deprecated azurerm_app_service resource. This resource has been deprecated in favor of azurerm_linux_web_app and azurerm_windows_web_app. I’ve created a custom check to warn us when we use the deprecated resource.

- code: app-service-deprecated
 description: Custom check to warn on deprecated app service
 impact: using deprecated app service resource instead of azurerm_linux_web_app or azurerm_windows_web_app
 resolution: Use azurerm_linux_web_app or azurerm_windows_web_app
 requiredTypes:
 - resource
 requiredLabels:
 - azurerm_app_service
 severity: WARN
 matchSpec:
 name: azurerm_app_service
 action: isPresent
 errorMessage: Using a deprecated resource - azurerm_app_service
 relatedLinks:
 - https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/app_service

This time I’m using the isPresent action to check if the resource is present. I’ve also added a link to the documentation for the resource.

Rego Policies

What about Rego policies?

We can create a folder to hold all of our rego policies. I created a file called keyvault_softdeleteretentiondays.rego and added the following code.

package custom.azure.keyvault.softdeleteretentiondays

deny[msg] {
 kv := input.azure.keyvault.vaults[_]
 kv.softdeleteretentiondays.value < 14
 msg := "Key Vault Soft Delete Retention Days is less than 14 days"
}

To understand the json input going into the rego policy, you can use the following command:

tfsec --print-rego-input

This will give you a ton of output that you can filter with jq to find the specific resource you are looking for. For example, to find the keyvault resource, you can use the following command:

vscode ➜ /workspaces/secure-terraform-on-azure/ (main) $ tfsec --print-rego-input | jq '.azure.keyvault'{
 "vaults": [
 {
 "__defsec_metadata": {
 "endline": 52,
 "explicit": false,
 "filepath": "workspaces/secure-terraform-on-azure/custom_checks_examples/keyvault/fail/main.tf",
 "managed": true,
 "resource": "azurerm_key_vault.example",
 "startline": 20
 },
 "enablepurgeprotection": {
 "endline": 27,
 "explicit": true,
 "filepath": "workspaces/secure-terraform-on-azure/custom_checks_examples/keyvault/fail/main.tf",
 "managed": true,
 "resource": "azurerm_key_vault.example.purge_protection_enabled",
 "startline": 27,
 "value": true
 },
 "networkacls": {
 "__defsec_metadata": {
 "endline": 34,
 "explicit": false,
 "filepath": "workspaces/secure-terraform-on-azure/custom_checks_examples/keyvault/fail/main.tf",
 "managed": true,
 "resource": "network_acls",
 "startline": 31
 },
 "defaultaction": {
 "endline": 33,
 "explicit": true,
 "filepath": "workspaces/secure-terraform-on-azure/custom_checks_examples/keyvault/fail/main.tf",
 "managed": true,
 "resource": "network_acls.default_action",
 "startline": 33,
 "value": "Deny"
 }
 },
 "softdeleteretentiondays": {
 "endline": 26,
 "explicit": true,
 "filepath": "workspaces/secure-terraform-on-azure/custom_checks_examples/keyvault/fail/main.tf",
 "managed": true,
 "resource": "azurerm_key_vault.example.soft_delete_retention_days",
 "startline": 26,
 "value": 7
 }
 }
 ]
}

I used this output to develop the policy. I had a few issues with the samples from the docs, and there is an open GitHub issue. To run the rego policies with tfsec, you have to pass the --rego-policy-dir command like this:

vscode ➜ /workspaces/secure-terraform-on-azure (main) $ tfsec --rego-policy-dir ./tfsec_rego_policies/ ./custom_checks_examples/keyvault/

Result #1 Key Vault Soft Delete Retention Days is less than 14 days
───────────────────────────────────────────────────────────────────────────────────────────────
───────────────────────────────────────────────────────────────────────────────────────────────
 fail Rego Package custom.azure.keyvault.softdeleteretentiondays
 Rego Rule deny
───────────────────────────────────────────────────────────────────────────────────────────────

You can see the results of the rego policy in the output.

Conclusion

While rego policies support are nice, I think the yaml policies are more flexible and easier to use. Having the ability to use a URL for custom checks allows you to share your checks with others.

I wanted to show how to do checks in Azure because I didn’t see a lot of examples or docs on Azure resources specifically.

I hope this deeper dive into custom checks was helpful.

Secure Terraform - Part 1 - tfsec

Thu, 29 Dec 2022 00:00:00 +0000

This blog was posted as part of the Festive Tech Calendar 2022. I really want to thank the organizers for helping set this up!

Look for the hashtag #FestiveTechCalendar2022 on social media! Make sure to check out everyone else’s work when you’re done here

This is part 1 of the Secure Terraform series. You can read the series of articles here:

Introduction

Securing Terraform starts before we even deploy anything. Our tooling is a great place to start! We can leverage one or more static code analyzers to look for misconfigurations, security issues, and other problems. Many of these great tools not only plug into our CI/CD pipeline, they also work within our IDEs. This allows us to catch issues while we work. We can also leverage pre-commit hooks to catch things before we even commit our code. With Cloud infrastructure, its easy to make mistakes, and these tools can help us catch them.

Today we are going to look at a one of these tools, tfsec, and how we can leverage it to secure our Terraform code. I’ll work through the rest of the ones in the list in follow on posts, but there are many more out there. I encourage you to check them out and see which ones work best for you.

tfsec

Let’s start with tfsec by aquasecurity. Aquasecurity supports multiple amazing tools like trivy and tfsec. Tfsec is an open-source tool available on GitHub at https://github.com/aquasecurity/tfsec. The docs are hosted at: https://aquasecurity.github.io/tfsec/. There are some great guides for installing it and configuring it for GitHub Actions. Tfsec even has an integration with GitHub Advanced security to show the results of the scan in the security tab of the repository.

Installation

We can run tfsec from a docker container or we can install it locally via homebrew, chocolatey, go, or the releases page.

After tfsec is installed (or docker is setup), we can run it against our Terraform code. Running it with defaults is quite easy, just invoking the command tfsec will run it against the current directory. If it finds files it will scan them and output the results. By default it checks all rules and outputs all severities found.

Running tfsec

Let’s take a look at the output of tfsec against a simple Terraform file:

resource "azurerm_storage_account" "sa" {
 name = "samplesa${random_uuid.uuid.result}"
 resource_group_name = azurerm_resource_group.rg.name
 location = azurerm_resource_group.rg.location
 account_tier = "Standard"
 account_replication_type = "LRS"
}

Running tfsec against this file produces the following output:

$ tfsec

Result #1 CRITICAL Storage account uses an insecure TLS version.
─────────────────────────────────────────────────────────────────────────────────────────
 insecure-terraform/main.tf:8-14
─────────────────────────────────────────────────────────────────────────────────────────
 8 resource "azurerm_storage_account" "sa" {
 9 name = "samplesa${random_uuid.uuid.result}"
 10 resource_group_name = azurerm_resource_group.rg.name
 11 location = azurerm_resource_group.rg.location
 12 account_tier = "Standard"
 13 account_replication_type = "LRS"
 14 }
─────────────────────────────────────────────────────────────────────────────────────────
 ID azure-storage-use-secure-tls-policy
 Impact The TLS version being outdated and has known vulnerabilities
 Resolution Use a more recent TLS/SSL policy for the load balancer

 More Information
 - https://aquasecurity.github.io/tfsec/latest/checks/azure/storage/use-secure-tls-policy/
 - https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/storage_account#min_tls_version
─────────────────────────────────────────────────────────────────────────────────────────


 timings
 ──────────────────────────────────────────
 disk i/o 28.432µs
 parsing 509.357µs
 adaptation 93.3µs
 checks 5.59119ms
 total 6.222279ms

 counts
 ──────────────────────────────────────────
 modules downloaded 0
 modules processed 2
 blocks processed 12
 files read 7

 results
 ──────────────────────────────────────────
 passed 7
 ignored 0
 critical 1
 high 0
 medium 0
 low 0

 7 passed, 1 potential problem(s) detected.

As you can see, tfsec found a potential problem with the TLS version being used. This could be a critical issue and should be addressed. We can see the ID of the rule, the impact, and the resolution. We can also see a link to the documentation for the rule and the link to the documentation for the resource.

I can also apply a custom configuration to tfsec to fine tune how I want to scan my code. This can be either a file I pass to tfsec or a config.json or config.yml inside a .tfsec directory. We could override the minimum severity to only show critical issues, or we could ignore a specific rule.

If I had misconfigured my storage account to accept traffic on http instead of HTTPS, tfsec would have found that as well. But maybe I don’t agree with the default severity of that rule. I can override the severity of the rule to be critical instead of high.

severity_overrides:
 azure-storage-enforce-https: CRITICAL
minimum_severity: MEDIUM

I’ve got a few simple misconfigurations checked into my sample repository at secure-terraform-on-azure. They aren’t on the main branch, but the demos branch.

VSCode

What about adding tfsec to VSCode? Well, we can install the tfsec extension. This will use the installed version of tfsec to scan our code. It will also show the results so we can see them right in our editor and go to the line where the issue is.

Great! Now we can see the issues right in our editor. But what if we forget to check the problems? How do we catch the issues and resolve them in our pipeline?

GitHub Actions

Aquasecurity has provided a few GitHub Actions and sample workflows to scan our terraform during every pull request. We can use the tfsec-action to scan our code.

name: tfsec
on:
 push:
 branches:
 - main
 pull_request:
jobs:
 tfsec:
 name: tfsec
 runs-on: ubuntu-latest

 steps:
 - name: Clone repository
 uses: actions/checkout@master
 - name: tfsec
 uses: aquasecurity/tfsec-action@v1.0.0

Now because I’ve got some tf nested, I added the following line:

additional_args: --force-all-dirs

All of the available options and parameters are documented on the actions page.

This will run tfsec against our repository on every check-in to main and every pull request. If we have insecure code, it will fail the workflow.

There is another action, tfsec-pr-commenter-action that is supposed to automatically add comments to the pull request with the results of the scan. I haven’t been able to get it to work because of my file nesting, but I’m sure it will be fixed soon.

Pre-commit Hooks

The last thing I want to talk about is pre-commit hooks. Pre-commit hooks are a way to run a script or command before you commit your code. This is a great way to make sure you don’t commit any code that doesn’t pass your checks.

There is a great framework for running pre-commit hooks called pre-commit. It is a python package that you can install with pip. Once you have it installed, you can add a .pre-commit-config.yaml file to your repository. This file will contain the hooks you want to run.

There is a project for setting up pre-commit hooks to scan terraform. It is called pre-commit-terraform. It will run tfsec against your code and fail the commit if there are any issues.

This runs BEFORE you code gets committed and before it gets pushed to GitHub. Your CI/CD workflow will never run if the pre-commit hook blocks the commit.

Conclusion

Terraform is a great tool for infrastructure as code. Leveraging smart tools like tfsec at various places in the development cycle can help you find and fix those issues before they become a problem. Join me again soon as we look at more tools to help you secure your infrastructure.

Multiple Domains on GitHub Pages

Tue, 27 Dec 2022 00:00:00 +0000

Something I found out after moving from WordPress to GitHub Pages is that out of the box you can only host a single domain for a repository with GitHub Pages. This is a problem for me because I have a number of domains I was hosting at WordPress that I wanted to point at my GitHub Pages.

Official Docs and the limitation

So officially, GitHub pages doesn’t support multiple domains. The docs here https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/troubleshooting-custom-domains-and-github-pages#custom-domain-names-that-are-unsupported state:

Make sure your site does not

Use more than one apex domain. For example, both *example.com* and *anotherexample.com*. Use more than one www subdomain. For example, both *www.example.com* and *www.anotherexample.com*. Use both an apex domain and custom subdomain. For example, both *example.com* and *docs.example.com*.

This means for example, I can setup www.chris-ayers.com and chris-ayers.com for my repository and nothing else. If I want another domain to point to it, like chrisayers.me, I would probably need to fork the repository and setup the new repository for the additional domain.

So how do we solve this? There has to be another way. There is! We can use Cloudflare to redirect the additional domains to the GitHub Pages domain. It seems this has been an issue for everyone since 2018. I found a few articles that helped me figure this out:

Cloudflare

Cloudflare is a DNS provider that has a free tier. It also has a feature called Page Rules that allows you to setup custom rules for your domain. This is what we will use to redirect the additional domains to the GitHub Pages domain.

Setup

First, we need to setup Cloudflare. This is a pretty simple process. You just need to create an account and add your domain. You can do this by following the steps here: https://developers.cloudflare.com/fundamentals/get-started/setup/

Create an account (if you don’t already have one)
Add your domain
I chose the free plan for each of my domains
I reviewed all the entries and made sure they were correct (I removed most of them)
I updated the DNS nameservers for my domain to the ones provided by Cloudflare

I decided that my primary domain would be https://chris-ayers.com. As part of the normal GitHub Pages DNS setup, you add the domain name to GitHub Pages then add A records to your DNS domain. The directions are in the GitHub docs. I’ve added the needed A records to my domain on CloudFlare.

Next I need to setup my other domains. For each domain, I added it to Cloudflare. I then setup 3 CNAME entries. Let’s look at my configuration for chrisayers.dev as an example. I setup the following CNAME entries:

With this configuration, I’m saying that pretty much everything should point to https://chris-ayers.com.

Type	Name	Content
CNAME	*	chris-ayers.com
CNAME	chrisayers.dev	chris-ayers.com
CNAME	www	chris-ayers.com

Now I need to setup the Page Rules. These are main thing that makes it all work.

Cloudflare Page Rules

This is where it gets a little more complicated. Continuing with my example before, adding chrisayers.dev, I setup the following Page Rules:

The main thing is to note the special characters (*) and variables in the rules.

Field	Value
URL (required)	`chrisayers.dev/`
Forwarding URL	`301 - Permanent Redirect`
Destination URL	`https://chris-ayers.com/$2`

After a little bit, everything should redirect to the GitHub Pages domain and work. I was fiddling a lot for the first domain or two, and they took a little while to start working. I’m not sure if it was just a propagation issue or what. But after a few hours, everything started working.

The other domains I did (I have around 10) were pretty quick. I think it was just the first ones that took a while because I was trying to figure out the process.

Conclusion

I’m pretty happy with the results. I was able to get all my domains to point to my GitHub Pages site. I’m not sure if this is the best way to do it, but it works. I’m sure there are other ways to do it, but this is the way I figured out. I hope this helps someone else out there.

Customizing the Jekyll Theme

Fri, 23 Dec 2022 00:00:00 +0000

I haven’t done a lot with jekyll in the past, but I’m a big fan of Markdown everything. For me that usually means I’m taking notes in Markdown Obsidian, doing diagrams in mermaid in Azure DevOps or https://mermaid.live/. I’ve even started turning my talk slides into Markdown with a tool called MARP.

Understanding when I use standard Markdown or some sort of templating language (jekyll uses Liquid) has been fun. I’ll do something in HTML or Markdown, then find out that Jekyll or my theme already has helpers to render that (like gists, videos, and figures). Sometimes rendering more advanced things takes a little tweaking of Jekyll and the theme.

Lets take Mermaid for example. If I want to render mermaid, it won’t work out of the box with jekyll or my theme. I need to tweak things and initialize things manually. If I want to render a graph, this won’t work out of the box.

 '''mermaid
 graph TD;
 A-->B;
 A-->C;
 B-->D;
 C-->D;
 '''

So to make it work, I had to override the base theme. To start, I looked at the themes layouts. They live in the _layout folder of the theme on GitHub. These are the base structure of a page and most reference either Archive or Default.

Fortunately Archive also refers to Default so I can focus my changes there if I want to override it.

Looking at this file, there are a few includes defined. One of which is the footer/custom.html and one is scripts.html. I looked through the scripts.html and it has a lot of logic I’d prefer not to duplicate. I’m already using the header-custom file to define some css/scripts. I’ve found Mermaid needs its init to run in the body, so i’ll probably want to leverage the footer/custom.html for this. It’s an empty file in the theme, making it any easy choice to override.

I created a footer folder in my local project _includes and a custom.html file. I added some simple logic to only add the mermaid logic if I added a mermaid:true flag at the top of the page.

So lets set that!

At this point, everything should work and embedded mermaid in my Markdown posts renders properly!

graph TD;
 A-->B;
 A-->C;
 B-->D;
 C-->D;

I’ve done a few other minor customizations so far. Like adding some custom CSS and some JavaScript for app insights. Both of those involved a similar process of adding head/custom.html and assets/css/custom.css.

I used a few different sources to get things to work for me. Please check those out as well to see if they can help you:

Thanks for following along on this journey. I hope this helps those starting their Jekyll journey or hosting on GitHub Pages.

Migrating from WordPress to GitHub Pages

Tue, 20 Dec 2022 00:00:00 +0000

I’ve been hosting on WordPress for a while. I wanted something that worked pretty well and was easy to work with. I picked a decent theme, added some plugins, pointed my domains and was up and running. I would work on blogs in Markdown, and then paste the txt into a Markdown. I could upload a few images and move them around in a wysiwyg.

Lately, I’ve been doing a lot more in Markdown. All my conference talks were in PowerPoint but I’ve started switching over to Markdown slides using MARP. I should probably do a post on MARP sometime (I did :-) ). I wanted to reduce my overhead of WordPress Hosting and get back into more direct styling and coding of my theme. I decided to switch my hosting to Jekyll on GitHub Pages.

Setting Up GitHub Pages

There are great docs on how to setup Jekyll with GitHub Pages.

https://docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll

First this is I setup a repository to host my page. My username is codebytes, so I made a repository for codebytes.github.io.

https://docs.github.com/en/pages/getting-started-with-github-pages/creating-a-github-pages-site#creating-a-repository-for-your-site

Knowing that I’m going to be using this repository for a Jekyll based site, I setup a dev container so that I could quickly have all the tools setup and configured.

https://docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll/creating-a-github-pages-site-with-jekyll

Setting Up Jekyll

I used the Jekyll theme called “Minimal Mistakes”.

https://mademistakes.com/work/jekyll-themes/minimal-mistakes/.

I used the Jekyll-import. Because of the plan I was using on WordPress.com, I couldn’t install custom extensions. That eliminated many export/import options. There is a free option for importing things into Jekyll-import using a Wordpress.xml export file.

https://import.jekyllrb.com/docs/wordpressdotcom

Since I’m using a devcontainer for my local blog, I setup Jekyll-import and its dependencies. I added the dependencies to the local gemfile and ran bundle install.

 gem "hpricot"
 gem "open_uri_redirections"
 gem "safe_yaml"
 gem "jekyll-import"

bundle install

On Wordpress.com I exported all my posts via the export functionality.

I then Exported everything which downloads as a single file.

This provides an download that’s a ZIP file with an xml file. I ran the import command:

bundle exec jekyll import wordpressdotcom --source wordpress.export.xml --assets_folder assets/

I imported all my posts from Wordpress.com (about 20). It also imported all my images, but they had many duplicates. Some image URLs had both normal URLs ("/blah/image.jpg") but some had other URLs ("/blah/image.jpg@60px"). After this import process, I touched up each post and image.

For each post I had to resolve the front matter at the top of each post. Imported it looked like this:

---
layout: post
title: 'ARM - Part 1: Azure Resource Manager'
date: 2019-05-11 23:53:57.000000000 +00:00
type: post
parent_id: '0'
published: true
password: ''
status: publish
categories:
 - DevOps
tags:
 - arm
 - arm templates
 - azure
 - cli
 - infrastructure
 - Microsoft
 - PowerShell
 - scripts
meta:
 _wpas_skip_571772: '1'
 _publicize_done_21771511: '1'
 publicize_linkedin_url: ''
 _publicize_job_id: '30717764168'
 timeline_notification: '1557633304'
 _publicize_done_external: a:2:{s:7:"twitter";a:1:{i:22482724;s:60:"https://twitter.com/Chris_L_Ayers/status/1127421911250677761";}s:8:"facebook";a:1:{i:22482726;s:52:"https://facebook.com/482199522523634_482213102522276";}}
 _wpas_done_22482724: '1'
 publicize_twitter_user: Chris_L_Ayers
 _publicize_done_21771513: '1'
 _wpas_done_22482728: '1'
 _publicize_done_21801094: '1'
 _wpas_done_22482726: '1'
author:
 login: chrislayers
 email: EMAIL
 display_name: Chris Ayers
 first_name: Chris
 last_name: Ayers
permalink: '/2019/05/11/arm-azure-resource-manager/'
---

After cleaning it up the front matter is much clearer.

---
title: 'ARM - Part 1: Azure Resource Manager'
date: 2019-05-11 23:53:57.000000000 +00:00
type: post
categories:
 - DevOps
tags:
 - arm
 - arm templates
 - azure
 - cli
 - infrastructure
 - Microsoft
 - PowerShell
 - scripts
permalink: '/2019/05/11/arm-azure-resource-manager/'
---

I similarly had to clean up some of the HTML in the imported posts. Mainly I removed a bunch of the commented HTML and converted it all to Markdown.

<p><!-- wp:heading {"level":3} --></p>
<h3>The Journey Begins</h3>
<p><!-- /wp:heading --></p>

That got cleaned up to and looking good in with Markdown preview:

### The Journey Begins

Finally, I reviewed each image and cleaned up the references.

<p><!-- wp:image {"id":151} --></p>
<figure class="wp-block-image">
 <img
 src="/images/newresourcegroup-3.png"
 alt=""
 class="wp-image-151"
 />
</figure>
<p><!-- /wp:image --></p>

The theme Minimal Mistakes has great helpers for figures and images. I converted the HTML to Markdown using the figure helper like this:

Update: I didn’t realize this was rendering wrong, I had to turn off liquid rendering with raw/endraw tags, or you could replace { with { and } with } to get the same effect.

I spent a few hours, fixed all the front matter and naming, converted all HTML to Markdown, then removed and renamed old images.

I was able to test locally by running running jekyll serve and checking how everything looked in a browser.

bundle exec jekyll serve

As part of setting up things with GitHub Pages, there is also a workflow that helps build and release the jeykll site to GitHub pages.

I’ll follow this up with another post on some of my customizations for monitoring and dns. Out of the box, GitHub pages only allow 1 custom dns domain. There are a few ways to host multiple domains on a single GitHub Pages site (check out chrislayers.com, chrisayers.me, or chris-ayers.com).

Validating .NET Configuration

Sat, 03 Dec 2022 00:00:00 +0000

This blog was posted as part of the C# Advent Calendar 2022. I really want to thank Matthew D. Groves and Calvin Allen for helping set this up! Look for #csadvent on Twitter! Make sure to check out everyone else’s work when you’re done here

One of the great things about the configuration system in .NET is the type safety, dependency injection, and model binding. Something we can take advantage of is to validate our configuration on startup and fail if it doesn’t pass validation. Having that fast failure is awesome when working with containers and applications that have liveness and readiness probes.

I have some examples of the amazing configuration system in my GitHub repository I use for my .NET Configuration in Depth conference talk. Feel free to take a look at the samples found there.

But let’s get to the topic at hand. How do we validate our configuration in .NET?

Let’s start with some configuration we’ll be wanting to validate and actually fail on startup if its not there.

 "WebHook": {
 "WebhookUrl": "http://example.com/event",
 "DisplayName": "DevOps",
 "Enabled": true
 }

And let’s have a strongly typed class to hold that configuration.

using System.ComponentModel.DataAnnotations;

public class WebHookSettings
{
 public string WebhookUrl { get; set; }
 public string DisplayName { get; set; }
 public bool Enabled { get; set; }
}

Now how do we KNOW our URL is valid? We can add some validation to our application pretty easily leveraging Data Annotations! This lets us mark fields as required as well as doing other validation. There are a ton of build in attributes, like StringLength, Range, EmailAddress, and more. You can find some of them listed in the documentation if you’re curious.

Let’s extend our class to add that basic validation.

using System.ComponentModel.DataAnnotations;

public class WebHookSettings
{
 [Required, Url]
 public string WebhookUrl { get; set; }
 [Required]
 public string DisplayName { get; set; }
 public bool Enabled { get; set; }
}

For my example, I’m using minimal APIs, and I can enable validation using just a few lines of code to invoke a few extension methods.

using System.ComponentModel.DataAnnotations;
using Microsoft.Extensions.Options;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddOptions<WebHookSettings>()
 .BindConfiguration("WebHook")
 .ValidateDataAnnotations()
 .ValidateOnStart();

This will not only validate the DataAnnotations on my configuration class, it will also run that validation on startup.

We can see what happens if I mangle my configuration and try to start my application. With this configuration below…

"WebHook": {
 "WebhookUrl": "",
 "DisplayName": "DevOps",
 "Enabled": true
 }

Running the application fails with this error.

Unhandled exception. Microsoft.Extensions.Options.OptionsValidationException: DataAnnotation validation failed for ‘WebHookSettings’ members: ‘WebhookUrl’ with the error: ‘The WebhookUrl field is required.’.

Now its complaining about the field being blank while required. What if we populate the URL field with a bad value that isn’t a Url?

 "WebHook": {
 "WebhookUrl": "BADVALUE",
 "DisplayName": "DevOps",
 "Enabled": true
 }

We we run the app with this value, we get a different validation error.

We can take this a step further, with additional custom validation if we choose. Let’s reset our configuration to something reasonable, but insecure..

 "WebHook": {
 "WebhookUrl": "http://example.com/event",
 "DisplayName": "DevOps",
 "Enabled": true
 }

How do we validate we’re always using https? Let’s add custom validation to our application.

builder.Services.AddOptions<WebHookSettings>()
 .BindConfiguration("WebHook")
 .ValidateDataAnnotations()
 .Validate(webHookSettings =>
 {
 return webHookSettings.WebhookUrl.StartsWith("https://");
 }, "WebHookUrl must start with https://")
 .ValidateOnStart();

Now we can validate the normal DataAnnotations as well as any custom validation logic we would like to include on startup!

Unhandled exception. Microsoft.Extensions.Options.OptionsValidationException: WebHookUrl must start with https://

If we fix everything with our validation, like so…

 "WebHook": {
 "WebhookUrl": "https://example.com/event",
 "DisplayName": "DevOps",
 "Enabled": true
 }

The application starts successfully!

$ dotnet run
Building...
info: Microsoft.Hosting.Lifetime[14]
 Now listening on: https://localhost:7090
info: Microsoft.Hosting.Lifetime[14]
 Now listening on: http://localhost:5268
info: Microsoft.Hosting.Lifetime[0]
 Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
 Hosting environment: Development

As you build your applications, think about adding validation to ensure your applications have a valid configuration at startup. Having runtime errors due to configuration is an annoying and sometimes hard problem to troubleshoot.

Please dive into the amazing documentation on the .NET Configuration system and look into the Options Pattern documentation as well!

Tools for working with Kubernetes

Thu, 17 Nov 2022 00:00:00 +0000

I’ve been in a number of internal and external calls where tooling to help work with Kubernetes keeps coming up. I thought I would share some of these cool tools in case you weren’t aware of them.

Tools

K9S
kubectx and kubens
fzf

K9S

K9S is a terminal based UI for interacting and managing Kubernetes Clusters. You can find k9s at https://github.com/derailed/k9s or their site https://k9scli.io/.

Kubectx and Kubens

These tools are amazing at quickly switching context and namespaces while working with kubernetes. You can find k9s at https://github.com/ahmetb/kubectx or the author’s site https://ahmet.im/blog/kubectx/.

kubectx can show you the multiple contexts available, switch between them quickly, and create aliases.

kubens can show you the multiple namespaces available, switch between them quickly, and create aliases.

fzf

fzf is a different type of tool. This makes your other tools better. It works on a variety of platforms but what is allows you to do is get an interactive filter. kubectx and kubens will show the list and let you pick what you want instead of runnig multiple commands. You can leverage fzf to pick files to edit more quickly.

It works with lots of things, like vi.

Conclusion

If you work daily with Kubernetes you might already know about these tools. If you haven’t tried them, give them an install and play around.

Presenting Best Practices - Part 1

Sun, 02 Jan 2022 00:00:00 +0000

Presenting and speaking are skills that require practice to hone. I was a consultant for many years presenting to clients and customers of all levels and sizes. In addition, I started speaking and presenting at meetups, user groups, and conferences. Over the years, I practiced, I read, and I gave a lot of presentations. I’d like to share some of the learnings and best practices I’ve found in that time. I plan multiple posts, starting with Preparation. I’ll have more on slide design, and presentation tips.

Preparation

If you are building a presentation for a conference or work, it is tempting to just dive in and put everything on a few slides. But you need to prepare by understanding the audience and the message. Presentations should support your communication, not BE your communication. It is important to know not only WHAT you want to say, but WHO you are saying it to. It all starts with knowing your audience.

Know Your Audience

Who are you presenting to: Engineers, Sales, Managers, C-Suites (CEO, CIO, CTO, CFO)? Each group has a set of unique needs and wants. What questions or areas are they going to be interested in? If it is a diverse audience, you will still need to be able to communicate with all of them. You should always keep your audience in mind when building content and presenting.

Why are they here?

Why are they here? What do they think they’re going to get out of this presentation? An engineer might be here for a technical presentation, a salesperson might be here to learn features to sell a product, a manager might be here to help a team stay on track, the C-Suite might be here to understand costs or timelines. Showing value early keeps people engaged. One of the first things you should do is tell your audience what’s in it for them.

Familiarity with the Content

How familiar are they with the content? Are these team members you have been collaborating with? Are they new to the topic and here for updates? The level of familiarity will determine the use of terms, acronyms, and jargon. Using jargon with a general audience can cause confusion and create a barrier to communication. If you use jargon, it can be helpful to define it. If people are having difficulty following the terms and jargon, they will lose interest and stop listening.

What is the value?

What is the value? Is this a collaboration meeting with Engineers working on an issue or problem? A status report to management on the progress of implementation? What are the attendees looking to get from this presentation? The core message might be the same for different audiences, but how you present that message and the value the audience gets from it might be different.

Know your message

So, you know who you are presenting to and a high-level idea of what you are trying to convey. Now you need to know your message in depth. What are the points you are trying to get across?

Intent

What is the intent of the presentation? Is it to inform, to persuade, or to instruct the audience? Each of these types of presentations has a different flow, style, and outcome.

Informational

For instance, an informational presentation aims to inform the audience about a specific topic. Think of it as a written report presented verbally. In business, these are the most common types of presentations. The goal is to share information, with an emphasis on clear and concise communication. You should limit your presentation to 3-4 key messages. Any more than that can be too much information and overload the audience.

Persuasive

A persuasive speech aims to move, motivate, or change the audience. You want the audience to perform a certain action or convince them to adopt the belief or opinion of the speaker. This might be a sales pitch, a recommendation for an architectural approach, or adopting a new practice. Persuasion has been studied by experts and they have observed what works and what doesn’t.

Instructional

If it is an instructional presentation, how much detail do you need to put into the presentation? A fun example is this great YouTube video, Exact Instructions Challenge - THIS is why my kids hate me. Josh Darnit, where a father is trying to follow the exact instructions for how to make a peanut butter and jelly sandwich. Finding the right level of detail in the instructions is important and knowing your audience can help.

Level of Content

What is the level of content? This can be difficult because it is hard to know what others know. Let’s say you are presenting to beginner engineers. The Curse of Knowledge means that you might struggle, because you intuitively assume that things that are obvious to you are also obvious to the engineers. Finding that right balance is important.

Conclusion

I realize this post was light in specifics, but knowing your audience is the #1 best practice for presenting. If you know the audience, the next recommendation is knowing your goal or intent of the presentation. These might seem like basic recommendations, but they can turn an average presenter into a great presenter.

Until Next Time.

Recommendations

I would like to give a few recommendations that will go deeper into many of these topics. These books are great additions for thinking about not only content, but how to present it.

Time to follow my Dream - I'm joining Microsoft!!!!

Sun, 10 Oct 2021 11:02:22 +0000

I’m so excited to announce that I’m joining Microsoft! I’ll be joining the Fast Track for Azure - Apps team as a Senior Customer Engineer. My first day will be October 25th, the 20th anniversary of the release of Windows XP. It’s been quite a journey to get here.

I’ve been enthralled with technology since my parents brought home our first computer in the mid 1980’s. I’ve had lots of different roles over the years, though it feels like the last 5-6 years really started me on the trajectory to Microsoft.

The change for me started with joining a consulting firm. I got more exposure to different solutions and technologies. I started attending MeetUps, User Groups, and conferences. I started speaking and blogging. I really found a passion for sharing with others.

While on a long-term project, I met Esteban Garcia, someone I now consider a mentor. He was helping setup our DevOps pipelines, and I was impressed by how he helped everyone. After a few years I joined him at Nebbia Technology, his small 12 person consulting company focused on DevOps and Azure. Esteban had a phenomenal team with an amazing culture that I was able to join and learn from.

Nebbia Technology was acquired by New Signature, a 500 employee consulting company focused on the Microsoft ecosystem. Esteban continued to lead our team as it grew into the Intelligent Cloud (Azure, DevOps, App Mod) team of New Signature. As our team grew, I talked with Esteban about growing as a leader. He helped motivate me, guide me, and offered feedback on how to be a better consultant and team member. I became our DevOps Capability Lead, doing pre-sales, building technical offerings and standards.

New Signature was acquired by Cognizant in 2020, along with 10th Magnitude (another consulting firm), forming the new Cognizant Microsoft Business Group. As Esteban moved to another role in New Signature, they needed a replacement to lead the team. This was a time of amazing growth for me. With Esteban’s help, I transitioned into the Regional Lead for Intelligent Cloud.

The last year has been a huge change for me. I broadened my knowledge in a lot of areas, and got a lot better at presenting. I focused on being a good leader for my team. Some of the team came with me from Nebbia, some from New Signature, and some I hired, but we came together. Culture has always been the key for me: caring for family, transparency, honesty, seeing beyond the work, and growth. I’ve made sure the team has opportunities to learn, grow, and pursue their dreams. I consider all of the friends.

I will be available to mentor them even as I follow my dream. This role takes me back into delivery. I get to help customers as they adopt azure, educating them, and gathering their feedback. I get to work with the Azure product teams. I also get to keep blogging, creating documentation, and samples that can help everyone. All the things I love to do, it feels like such a good fit for me.

I’M. GOING. TO. MICROSOFT. I can’t stop smiling.

And it wouldn’t be possible without my family, my friends, my mentor, and my team.

Thank you all.

Containers and VMs: What is the difference?

Mon, 16 Aug 2021 12:01:41 +0000

Containers are a very big topic right now, but they also cause a lot of confusion for people. Before we discuss containers, containerization, and container orchestration; we should address the question of how containers differ from virtual machines (VMs).

Both are built on the concept of Virtualization. Virtualization is the process of creating a virtual computing environment as opposed to a physical environment. Both technologies have their uses, and even today many solutions leverage both VMs and containers, sometimes leveraging VMs to host containers.

What are VMs?

A virtual machine (VM) is virtual infrastructure with its own virtual CPU, memory, network interface (NIC), and storage. A host machine runs VMs. The VMs that run on the host are called guests. The resources of the host are managed by a hypervisor.

The hypervisor is software that creates and runs VMs. The hypervisor gives each virtual machine the resources that have been allocated and manages the scheduling of VM resources against the physical resources. VMs are isolated from the rest of the system, and multiple VMs can exist on a single host. Because they are isolated, VMs can run different operating systems like Linux or Windows.

Workloads or applications running on a VM contain the entire operating system (Linux, Windows, …) as well as all the services, dependencies, and libraries needed to run and administer applications or workloads. Because VM images contain the entire operating system, they can range in size from hundred of megabytes up to several gigabytes. Starting a VM or application can also take several seconds to minutes

Advantages	Disadvantages
VMs support diverse OS requirements for multiple applications on a single infrastructure	VM image size results in longer backup or migration durations between platforms
VMs replicate comprehensive computing environments, easing portability and migration between on-premises and cloud platforms	Duplicate copies of files (OS or libraries) are common among multiple VMs on a system
VMs provide superior isolation and security across systems	Limited VM support on a physical server compared to containers, due to full server encapsulation
A robust VM ecosystem and marketplace exists, featuring industry leaders	VM start-up times can be lengthy, as the OS and kernel need to fully initialize

What are Containers?

Containers are lightweight, isolated, packages of software. The containers bundle libraries, configuration, scripts, and application binaries. There is a standard for containers images, The Open Container Initiative - OCI, for allowing interoperability of different container engines. Containers run on top of an OS and a Container Engine, like Docker, CRI-O, or LXD. The Container Engine pulls images from a container registry and runs applications.

Advantages	Disadvantages
Containers are lightweight with images in megabytes, compared to VMs in gigabytes	Steeper learning curve for containers
Containers offer high portability across on-premises and cloud environments	Containers require a uniform OS, limiting OS diversity or version mixing
Reduced IT resources needed for container deployment, operation, and management	Potential security concerns due to shared OS in containers compared to VMs
Rapid container start-up times in seconds	Containers are a newer technology with an evolving ecosystem

Next Steps

While VMs emulate entire machines, Containers are great for packaging applications and their dependencies. Next time we’ll look at the parts of a container image, how they are defined, and how they are run.

Scripting Winget

Sun, 01 Aug 2021 10:21:12 +0000

When I reset my PC or setup a new test machine, I always have to download a lot of software. In the past, I’ve used Chocolatey, Boxstarter, or just installed everything by hand.

I’ve played with winget, as part of the Windows Insider program. It was first announced in 2020 but was highlighted during Build 2021. With the release of Windows 11, I’ve setup machines a few times and wanted to automate the process using the new winget command.

What is Winget?

WinGet is the command-line tool for the Windows Package Manager, found on GitHub. For a while, the only way to install it was to be a Windows Insider. I’ve also been able to use winget after fully updating a Windows 10 machine. You can also install it directly from GitHub.

What can Winget do?

Winget allows you to easily search for and install software. You can upgrade and remove software as well.

Searching for Packages

Let’s say i’m not sure what packages there are. I can run winget search and get a full list of available packages, or I can filter that by searching for a package name or partial name.

Showing Package information

You can then show more details about a package, including publisher, URL, and hash.

Installing, Uninstalling and Updating Packages

Installing packages is very easy, typically I just winget install X. This are options for using monikers (vscode) or full IDs (Microsoft.VSCode) as well.

For some apps there might be popups or gui installers. I usually use winget install --silent X when installing multiple apps. It prevents the popups on most installers.

Similarly, upgrading and uninstalling packages is done through the winget upgrade X and winget uninstall X commands with similar options to the install command.

Older Method

I originally started writing this a few months ago, before its 1.0 release. Since that time things have gotten much easier.

If you update Windows 10 (1807 or higher) with all the normal patches, and you update the store Apps (including App Installer), you get winget
winget added an import/export set of commands, allowing you to quickly install a series of apps on a second machine (or the same machine) and it will detect those already installed.

Please keep reading though if you find scripting and automation interesting. The script I walk through below can be found at Gist: Codebytes/DevMachineSetup.ps1.

Scripting the install

While scripting the install, I ran into a few issues. For older versions of Windows, the latest versions from GitHub would not install due to missing dependencies. I also had to install the VC++ v14 Desktop Framework Package. Both of those steps are handled by the setup script below.

 #Install WinGet
 #Based on this gist: https://gist.github.com/crutkas/6c2096eae387e544bd05cde246f23901
 $hasPackageManager = Get-AppPackage -name 'Microsoft.DesktopAppInstaller'
 if (!$hasPackageManager -or [version]$hasPackageManager.Version -lt [version]"1.10.0.0") {
 "Installing winget Dependencies"
 Add-AppxPackage -Path 'https://aka.ms/Microsoft.VCLibs.x64.14.00.Desktop.appx'

 $releases_url = 'https://api.github.com/repos/microsoft/winget-cli/releases/latest'

 [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
 $releases = Invoke-RestMethod -uri $releases_url
 $latestRelease = $releases.assets | Where { $_.browser_download_url.EndsWith('msixbundle') } | Select -First 1

 "Installing winget from $($latestRelease.browser_download_url)"
 Add-AppxPackage -Path $latestRelease.browser_download_url
 }
 else {
 "winget already installed"
 }

After getting it installed, I added some configuration to support the windows store. This is an experimental setting documented on GitHub: https://github.com/microsoft/winget-cli/blob/master/doc/Settings.md.

 #Configure WinGet
 Write-Output "Configuring winget"

 #winget config path from: https://github.com/microsoft/winget-cli/blob/master/doc/Settings.md#file-location
 $settingsPath = "$env:LOCALAPPDATA\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json";
 $settingsJson =
 @"
 {
 // For documentation on these settings, see: https://aka.ms/winget-settings
 "experimentalFeatures": {
 "experimentalMSStore": true,
 }
 }
 "@;
 $settingsJson | Out-File $settingsPath -Encoding utf8

Finally I built up a list of packages to install. I’m using the winget command to install the packages. I originally had a simple list of packages, but added the optional source parameter to support installing from the Windows Store. Winget also doesn’t short circuit the install if the package is already installed, so I added a check for that. Winget today doesn’t output PowerShell objects or easily parseable output, so I just joined all the lines into 1 string and checked the contents.

 #Install New apps
 $apps = @(
 @{name = "Microsoft.AzureCLI" },
 @{name = "Microsoft.PowerShell" },
 @{name = "Microsoft.VisualStudioCode" },
 @{name = "Microsoft.WindowsTerminal"; source = "msstore" },
 @{name = "Microsoft.AzureStorageExplorer" },
 @{name = "Microsoft.PowerToys" },
 @{name = "Git.Git" },
 @{name = "Docker.DockerDesktop" },
 @{name = "Microsoft.dotnet" },
 @{name = "GitHub.cli" }
 );
 Foreach ($app in $apps) {
 #check if the app is already installed
 $listApp = winget list --exact -q $app.name
 if (![String]::Join("", $listApp).Contains($app.name)) {
 Write-host "Installing:" $app.name
 if ($app.source -ne $null) {
 winget install --exact --silent $app.name --source $app.source --accept-package-agreements
 }
 else {
 winget install --exact --silent $app.name --accept-package-agreements
 }
 }
 else {
 Write-host "Skipping Install of " $app.name
 }
 }

Removing Packages

We can also remove unused windows applications that are installed by default. I combined some of the script found here as well: Uninstalling windows store apps using PowerShell. I don’t usually use the 3D printing apps, or the mixed reality stuff so they can go. And I don’t care about the solitaire collection.

 #Remove Apps
 Write-Output "Removing Apps"

 $apps = "*3DPrint*", "Microsoft.MixedReality.Portal"
 Foreach ($app in $apps)
 {
 Write-host "Uninstalling:" $app
 Get-AppxPackage -allusers $app | Remove-AppxPackage
 }

Running the script

The script can be found at Gist: Codebytes/DevMachineSetup.ps1.

I learned how to run PowerShell from a gist from this great article: Run a PowerShell script directly from GitHub Gist.

You can get and run the entire script on a new machine by invoking the following command.

 PowerShell -NoProfile -ExecutionPolicy Bypass -Command "iex ((New-Object System.Net.WebClient).DownloadString('https://gist.githubusercontent.com/Codebytes/29bf18015f6e93fca9421df73c6e512c/raw/'))"

Note: After running this, you might need to restart your terminal or reboot the computer.

Clearing NuGet Caches

Mon, 05 Jul 2021 20:29:11 +0000

What is NuGet?

NuGet is an essential packaging tool used in the .NET ecosystem. NuGet is how packages for .NET are created, hosted, and consumed, along with the tools for each of those roles. For many, NuGet is used through Visual Studio to install and manage packages.
The dotnet CLI also provides functionality for adding packages, updating packages, and creating packages.

NuGet has changed over the years, originally downloading packages into a project folder where they could be checked in. Today, we don’t typically check packages into our source control. This is where caching comes in.

NuGet Caches

NuGet manages several folders outside of your project structure when installing, updating, or restoring packages. The locations of the folders vary by platform but the use case is the same. Microsoft has a detailed document on the caches: Managing the Global Packages and Cache Folders.

Name	Description
global‑packages	This is where NuGet installs any downloaded package.
http‑cache	The Visual Studio Package Manager (NuGet 3.x+) and the dotnet tool store copies of downloaded packages in this cache (saved as .dat files), organized into subfolders for each package source.
temp	A folder where NuGet stores temporary files during its various operations.
plugins-cache	A folder where NuGet stores the results from the operation claims request.

Viewing the cache locations can be done with the dotnet CLI or the nuget cli:

# Display locals for all folders: global-packages, http cache, temp and plugins cache
dotnet nuget locals all --list
nuget locals all -list

http-cache: C:\Users\user1\AppData\Local\NuGet\v3-cache
global-packages: C:\Users\user1\.nuget\packages\
temp: C:\Users\user1\AppData\Local\Temp\NuGetScratch
plugins-cache: C:\Users\user1\AppData\Local\NuGet\plugins-cache

Why do we want to Clear the Caches?

There are a few reasons you might want to clear caches.

Maybe you’re seeing strange behavior in your builds. I’ve cleared all my caches to make sure I’m downloading the same versions as the build agent
Upgrading versions of .NET. I’ve had errors (and warnings) from restoring packages into a new version of .NET that were restored in previous versions.

Clearing Caches

To clear the caches, you can pick the method that works best for you.

In Visual Studio 2017 and beyond, there is a button in the NuGet section of the options dialog (Tools->Options):

Using the dotnet or nuget CLI, you can clear specific caches or all caches. The commands are:

# Clear the 3.x+ cache (use either command)
dotnet nuget locals http-cache --clear
nuget locals http-cache -clear

# Clear the 2.x cache (NuGet CLI 3.5 and earlier only)
nuget locals packages-cache -clear

# Clear the global packages folder (use either command)
dotnet nuget locals global-packages --clear
nuget locals global-packages -clear

# Clear the temporary cache (use either command)
dotnet nuget locals temp --clear
nuget locals temp -clear

# Clear the plugins cache (use either command)
dotnet nuget locals plugins-cache --clear
nuget locals plugins-cache -clear

# Clear all caches (use either command)
dotnet nuget locals all --clear
nuget locals all -clear

Installing NuGet.exe

NuGet.exe is not installed by default on Windows. Visual Studio 2017 and above include nuget package manager functionality via the NuGet Package Manager (GUI and console), but not nuget.exe.

If you install newer versions of the DotNet CLI, it does include dotnet nuget funcationality but not nuget.exe.

The NuGet.exe doesn’t have an installer, and the instructions on the site usually involve downloading the exe and adding it to your path.

There are other ways to install NuGet.exe.

winget install Microsoft.NuGet
choco install nuget.commandline
I’ve got a script that downloads it and adds it to your path, you can find it here: Nuget-Install.ps1

Conclusion

In conclusion, understanding and managing NuGet caches is essential for maintaining a healthy development environment, especially when dealing with build issues or upgrading .NET versions. Clearing caches can help resolve strange behavior in your builds and ensure consistency with build agents. With the methods outlined in this post, you can easily clear specific or all caches using Visual Studio, the dotnet CLI, or the nuget CLI. By mastering these cache management techniques, you’ll be well-equipped to tackle any cache-related challenges that come your way, ultimately contributing to a more efficient and reliable development process.

DevOps - The Stakeholders

Sat, 05 Jun 2021 16:55:36 +0000

When I talk about DevOps, I usually don’t focus on the things like pipelines or automation. While these topics and activities can be part of DevOps, there is so much more to it. I’m sure this will be a multipart blog series so lets get started.

The Definition

Let’s make sure we are all on the same page. The definition of DevOps that I love and subscribe to was coined by Donovan Brown at Microsoft.

DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.

This definition and the thought process behind it really drives how I was taught about DevOps and try to practice it today. DevOps is a culture or mindset that really should drive how value is delivered at an organization. DevOps should not be a Developer only or “DevOps” only activity, this mindset should permeate the organization. DevOps is not about pipelines, automation, or a job title.
DevOps is about continuous delivery of value to our end users. End users don’t care about story points. End users don’t care about tests passing in QA. End users care about value, which could mean anything like features, stability, or performance.

The Stakeholders

So where do we start? With Stakeholders. For culture and mindset shifts, buy in from all levels is important. This really is “The First Way” from the Phoenix Project and Lean Methodology. We need to think of how the whole system (the organization) delivers value to our end users.

Stakeholders collaborate and cooperate in the development, delivery, and maintenance of software and value With a DevOps mindset and culture. Stakeholders and leaders can influence and encourage the mindset needed for organizations to succeed. The Shared Goals need to be understood by everyone, with the end result clearly communicated. Silos hurt the delivery of value by limiting communication and collaboration. Historically where there were silos, there are walls slowing things down.

This type of collaboration usually requires change. Change takes time. Culture takes time. A piece of software or a job title won’t be a silver bullet. But after helping multiple organizations of all sizes embrace the DevOps culture and mindset, one of the key things to keep in mind is patience.

I’ll be back to dive more into this topic.

Shared Focus - Using The First Way with DevOps

Thu, 27 Feb 2020 08:00:09 +0000

A common issue I see when discussing DevOps with teams or organizations is the presence of Organizational Silos. Organizational Silos are made up of all types of people. Sometimes its a job type, like developers, qa, or infrastructure. Sometimes its a department, like accounting, or hr. Whatever the composition of these silos, they usually impact organizational performance and the ability to deliver value to end users.

This happens over time, with members of the silo identifying with each other, viewing those not in the silos as outsiders. Depending on the business, the silos can lose trust in the business overall and tighten ranks around their silo. The silos can turn into walled fortresses. When the silos get in the way, the silos are more focused on their own success than the success of the organization.

This can also happen with leaders. Leaders trying to turn their areas into fiefdoms. Leaders concerned about their power, responsibilities, or bragging rights. Either way, like the silos, situations like this can lead to groups concerned about their success, instead of the success of the organization.

Common Goals

To really succeed, to improve and to grow as an organization, everyone needs to share some common goals and shared focus across the organization. How do we bring value to users? Sure, Dept A can release X feature or function, but if it depends on Dept B to work, it brings no value. If developers can write lots of code, does that benefit the user if it isn’t tested? If that code doesn’t have resources to run on? If you’re writing code no-one wants? Or systems are built and configured but there’s nothing to run.

When everyone is working towards common goals and have a shared focus, the whole is greater than the sum of the parts. I was introduced to some of these ideas as “The First Way”. I read about this in “The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win” by Gene Kim and “The DevOps Handbook”. The ways were also in a blog by Gene Kim called “The Three Ways”. If you haven’t read either of these books, please go read The Phoenix Project.

How Do You Boil the Ocean?

Wed, 26 Feb 2020 00:46:31 +0000

This is a phrase I end up using a lot while talking with clients. I used to use a different phrase about elephants but moved away from that language to be more respectful. Let’s start with what it means, at least in the context I use it, and why this phrase is so useful when talking about Devops.

The Meaning

I’ve seen and heard a few meanings and usages of the phrase, “Boil(ing) the Ocean”. I’ve heard many negative contexts like: to undertake an impossible task or project. I usually use it in this context, Here is a big task with lots to do, how do you get started and make progress?

Applied to DevOps

So how, and why do I apply this strange phrase to DevOps? Because as I work with clients, educating them and enabling them, they start getting excited. Depending on where they are in their DevOps journey, they might have a bigger or smaller list of things they want help with. Maybe its Infrastructure as Code (IaC), and a pipeline to help release it consistently and repeatedly. Maybe they are using a centralized version control system and are interested in moving to git and picking a branching strategy to work more effectively. When they release those cool new features, do they have monitoring and observability in place to know if and how their users are using those features? I could go on for a while, there are so many things that can impact an organization’s software delivery performance. And like “boiling the ocean” it seems like that can be an impossible task.

So how do you “boil the ocean”? One cup at a time. Iteratively make progress. Progress over perfection. Don’t choose to do nothing because its not perfect. Make an improvement, any improvement. Pay attention to the results, take that feedback and make another improvement. Just like a pot of water, the ocean won’t go from cold to boiling, it takes time.

Snake Oil DevOps - BEWARE!

Mon, 24 Feb 2020 20:06:49 +0000

As a DevOps Consultant a lot of what I do is spent on People and Processes. If you remember the definition of DevOps that I love is from Donovan Brown, “DevOps is the union of People, Processes, and Products to continuously deliver value to our end users”. I want to keep reiterating this, continuously deliver value to our end users. I bring this up because my job as a DevOps Consultant is to delivering value to my end users. But not all of us do. My amazing coworker (@_s_hari) and I have discussions about this quite a bit. As far as I know, he coined the term and gave me his blessing to blog about it.

A lot of what I do is focused on enablement. I don’t want to come in and setup 2 pipelines for a user, or just do board customizations on 3 board. I want to educate my end users. I want them to learn and apply it after I’m gone. I want to see the lightbulb go off, and the gears turning. I want them to continue on their journey and call me back at the next roadblock miles down the road, not the same one 5 feet away. I might focusing on training, or streamlining the workflow. Whatever is going to help them the most at that point in time.

Snake Oil

But, like days of old, there are those trying to make a buck at any cost. We come across them or hear about them from customers time to time. People and Processes aren’t part of the discussion. Instead the discussion centers on the tool. Snake Oil, The secret sauce, the magic technology, the silver bullet, the tool that will solve all your problems.

Have you ever heard any of theses statements/promises/lies?

If you buy this list of tools, you’ll be/have/do DevOps.
You can’t do DevOps without X tool.
You need to do Containers to do DevOps
Jira/Service Now/GitLab/Azure DevOps/GitHub/Excel/Post-its is the only way to track work
If you buy this monitoring tool all your bugs will get caught

Notice the lack of discussion about the company/business/team. What the business, what is important to the end users? How do you work? What are the processes to take a new idea, let the team work on it, and get that code into production? How do you know its running OK in production? Do you know if the end user uses your new feature?

When someone just focuses on the tool, they don’t care about helping you to improve, your journey, or the actual outcome. They want to continuously deliver the value of your wallet into theirs.

What is DevOps?

Sun, 23 Feb 2020 18:41:35 +0000

What Isn’t DevOps?

Before I define DevOps, let’s get started with what DevOps isn’t. DevOps isn’t just a title, or a guy, or a department. DevOps isn’t just automating everying, and isn’t just logging everything. DevOps isn’t dozens of alerts every day, and isn’t an on-call rotation. DevOps isn’t agile or small releases. DevOps is a mindset.

What Is DevOps?

The best definition I’ve seen is from Donovan Brown, “DevOps is the union of People, Processes, and Products to continuously deliver value to our end users”. Donovan breaks down his word choice and what it means to him. To me, DevOps is a mindset that should be adopted company wide. Because of delivering value to our end users, you need a Production-First mindset. It’s not about delivering story points, delivering user stories, or deploying to qa.

Half Measures

Have you ever been at a company that “Bought the Agile”? Doing Standups and Sprints but not understanding the why behind it. Agile is a promise of more work from fewer people, right? Have you ever heard,“Why are we doing retrospectives, that’s not a feature”.

DevOps can be the same way. Perform a number of actions and activities but not adopt the mindset. Why are we automating things? Why and what should we log or alert on? How do we use this data or improve our processes and products?

Some Tools to Help Present Git

Sun, 23 Feb 2020 00:27:33 +0000

I’m presenting soon on Advanced Git. I feel a lot of Developers and DevOps engineers know enough git to the job, but sometimes that’s it. I want to help people be more comfortable with the git command-line, and help alleviate some fear or hesitation in dealing with git edge cases.

While researching things, I came across a few neat tools I’m using to help describe things.

GitGraphJS

What is great about this tool is that I can draw git commit graphs pretty easily to describe what is happening as you execute commands. It helps create great graphs like this:

I’ve got a project where i can have each example laid out for discussion, and because its JavaScript, I can change things and show the result easily. This tools is great for slides and lecturing, but I also like having people put hands on keyboards and try things.

Windows Terminal

I do a lot of development on windows. CMD.exe isn’t the best experience to use or present with. The same can be said of regular powershell. I’ve leveraged git bash in the past, it works pretty well. But I have completely fallen in love with the Windows Terminal. Multiple profiles (for bash, wsl, powershell, cmd), a great font, and nice scalability, I’ve finally found a nice shell on windows.

Oh My _______

If you aren’t familiar with Oh My Posh (powershell), Oh My Bash (bash), or Oh My Zsh (zsh) please pay attention. These tools add some awareness to your shell experience. If you ‘cd’ into git folders, it can show the branch, how far ahead or behind you are, and many other details. It gives you situational awareness about where you are and your current state. There are also many themes to tweak and customize your command-line.

Git GUIs

I don’t use git GUIs in my day to day workflow. I typically interact with git via a command-line. But there are some times when a gui is very helpful. Complex merges and rebases can be made clearer via gui, as well as a clear visualization of the git history. Don’t get me wrong, I can do that via command-line:

git log --pretty=oneline --graph --decorate --all

But these tools make it much cleaner, clearer, and prettier.

I’m a big fan of tools that help me share ideas more effectively and these are a few that I think will help me explain git state.

WSL2, Docker, and Time

Thu, 23 Jan 2020 11:42:30 +0000

I’m running on a Windows Insider Slow build so that I can leverage WSL 2, the Windows Subsystem for Linux v 2. Its pretty incredible, because there’s now a Linux kernel inside Windows. Ubuntu is fast, its a wonderful development experience all my favorite linux tools. I can’t wait for this to be out of preview this year and in the mainstream windows releases.

I’m also using the latest version of Docker Desktop, with WSL2 support. What this means is that instead of using Hyper-V to run a Moby Linux VM, docker runs directly on WSL2. It also has built-in Kubernetes support.

If you haven’t guessed, I’ve been doing some container development. The experience so far as been great, with VS Code and the Remote Development Extension pack. I recently ran into some issues though. Here are some examples from bug posts opened about it:

While updating Ubuntu: E: Release file for http://security.ubuntu.com/ubuntu/dists/bionic-security/InRelease is not valid yet (invalid for another 14h 47min 54s). Updates for this repository will not be applied.
Getting metadata from plugin failed with error: invalid_grant: Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe. Check your iat and exp values and use a clock with skew to account for clock differences between systems.
kubectl x509 certificate has expired or is not yet valid #1152
Az storage blob copy start failed #9995

I tried resolving the issue by syncing my time clock and restarting but I kept having issues. I figured it out today. Turns out, WSL2 has a issue (being worked on) with skewed clocks. Even though my Windows time was correct, the time in my WSL was off. It was not syncing with local system time and was probably based on the first time I powered it up.

There are a few open issues on GitHub regarding the problem, so I know they’re aware and working on a fix.

Time not synced in WSL2 - causing TLS issues - https://github.com/microsoft/WSL/issues/4149
system date is not same with windows (WSL 2) - https://github.com/microsoft/WSL/issues/4245
WSL2: Clock skewed? - https://github.com/microsoft/WSL/issues/4677

For me i first fixed the symtom, then followed the recommendation and actually solved the problem.
Treating the symptom:

sudo ntpdate pool.ntp.org

But the actual recommendation from the team I used is:

sudo hwclock -s

I hope this helps someone until this goes GA. Thanks for your time!

Dependency Injection, Architecture, and Testing

Sun, 01 Dec 2019 23:27:53 +0000

This blog was posted as part of the Third Annual C# Advent. Make sure to check out everyone else’s work when you’re done here

Dependency Injection, or DI, is a Software Architecture Design Pattern. DI is something that comes up during discussions on SOLID, IoC (Inversion of Control), testing, and refactoring. I want to speak on each of these briefly because DI touches all of these. But before I really dive into things, I want to define what a dependency is. A dependency is any object that another object requires. So all of those classes, services, and libraries that we use to build our applications are dependencies.

Dependency Injection - What is it?

At its heart, Dependency Injection is right there in the name, you inject your dependencies. I want all the dependencies for my class called out in the constructor, parameter list, or somewhere I can easily see them. Without Dependency Injection, any time I need a class, service, database connection, I just new it up. This can make code untestable, hard to use safely, and very brittle. Lets see what this looks like in a small example. Imagine the hidden dependencies and hard to test logic in a bigger class.

 public class ClientService
 {
 private ClientRepository _clientRepository;

 public ClientService()
 {
 //allocated in constructor but can't test or use a different repository without a code change
 _clientRepository = new ClientRepository();
 }

 public void Delete(int id)
 {
 //hidden dependency to the delete method, newed up here
 var audit = new AuditService();
 audit.LogDelete(id);

 _clientRepository.Delete(id);

 //a hidden static dependency, very hard to test with
 EmailProvider.SendDeleteConfirmation(id);
 }
 }

Untestable

I said not using DI would make the code untestable. Why? There are a lot of reasons in this example. I’ll go through them one at a time.

Isolation / Coupling

When you are writing unit tests, you want to isolate a class for testing. Some people call it the “System Under Test” (SUT) or “Class Under Test” (CUT). How can we isolate just the logic in ClientService from the logic in its dependencies? Our service is tightly coupled to the repository, the audit service and the email provider. I can’t easily put in a fake/mocked email provider or audit service to test what my class is doing. This type of code pushes a lot of developers to skip unit tests and just rely on integration tests.

Database

Another issue is I/O, like files, databases, network connections. In this example, I’m using the Repository pattern to wrap/abstract my database. This could be a file, mysql, or Azure CosmosDB, I don’t care. But, in this case, it’s getting created in the constructor of my service. When I want to unit test my business logic, it will be touching the database. More of an integration test than a unit test. Unit tests should be fast. Ludicrous speed fast. Sure I could create a local or testing database, but again, that is integration, not unit testing.

Statics

Statics are always a problem because statics can’t be mocked or faked. Another issue is that its hard to tell side effects of those classes and methods. When I’m reviewing a class or method, I usually check the constructor, parameters, or variables at the top to see what a piece of code depends on. Static methods can be buried inside a block of code and be missed. It means that it can be a hidden dependency.

Interfaces

I feel it is very important to have interfaces define the contracts between layers and systems. Having FOO depend on BAR means that FOO might change every time we modify the implementation of BAR. If FOO depends on IBAR, the API contract of BAR, we can have multiple implementations, change the implementation or mock it. The interface insulates FOO from the changes in BAR. In addition to reducing coupling between modules, it will help with testability and refactoring down the road.

Types of Dependency Injection

Let’s look at a few types of dependency injection. The type I usually prefer, and my default, is Constructor Injection. This lists all the dependencies for a class in its constructor. There are times where this isn’t a good idea, when you have the expensive creation of dependencies that are only used in infrequent edge cases in the class. In those instances, Parameter Injection works well, injecting the dependency as a parameter into the methods that need it. Finally there is property injection which I dislike. I’ve seen people use it because of tutorials online, but I HIGHLY recommend avoiding this if possible.

Constructor Injection

This involves moving dependencies to the constructor where possible. This is a lot of times the place where people end up, but if you’re refactoring older code, you won’t get here right away. Notice I moved from having private variables of the concrete classes to the interfaces. Also notice, looking at the class constructor, you know exactly what this class depends on.

 public class ClientService : IClientService
 {
 private readonly IClientRepository _clientRepository;
 private readonly IAuditService _auditService;
 private readonly IEmailProvider _emailProvider;

 public ClientService(IClientRepository clientRepository, IAuditService auditService, IEmailProvider emailProvider)
 {
 _clientRepository = clientRepository;
 _auditService = auditService;
 _emailProvider = emailProvider;
 }

 public void Delete(int id)
 {
 _auditService.LogDelete(id);
 _clientRepository.Delete(id);
 _emailProvider.SendDeleteConfirmation(id);
 }
 }

Parameter Injection

This involves moving dependencies to where they are used. Looking at the interface to the service or the methods, you can see what dependencies are needed for some of the methods. Like I mentioned before, if there are some dependencies that are really expensive to create or maybe incur some type of cost, you can limit their creation to only when they are used.

 public class ClientService : IClientService
 {
 private readonly IClientRepository _clientRepository;

 public ClientService(IClientRepository clientRepository)
 {
 _clientRepository = clientRepository;
 }

 public void Delete(int id, IAuditService auditService, IEmailProvider emailProvider)
 {
 auditService.LogDelete(id);
 _clientRepository.Delete(id);
 emailProvider.SendDeleteConfirmation(id);
 }
 }

Property Injection

Use property injection only for optional dependencies. That means your service should be able to properly work without these dependencies provided. After you instantiate the class, you need to assign the properties with objects. This can cause confusion because you can’t always tell what a classes true dependencies are just looking at the constructor. It can also cause confusion during testing.

 public class ClientService : IClientService
 {
 public IEmailProvider EmailProvider { get; set; }

 private readonly IClientRepository _clientRepository;
 private readonly IAuditService _auditService;

 public ClientService(IClientRepository clientRepository, IAuditService auditService)
 {
 _clientRepository = clientRepository;
 _auditService = auditService;
 }

 public void Delete(int id)
 {
 _auditService.LogDelete(id);
 _clientRepository.Delete(id);
 EmailProvider?.SendDeleteConfirmation(id);
 }
 }

DI Containers

Having all our dependencies in the constructor is nice, but who is going to new up our services? With most DI frameworks, you register your interfaces and services at program startup with a DI container, and everything is wired up for you. You can control the wiring process. Should service A be a singleton? Should service B be instantiated on every call? Dotnet core has built-in support for DI containers. And before dotnet core, the .Net Framework had a lot of different libraries and frameworks to help with dependency injection. You might have heard of Ninject, Autofac, Castle, or Unity. Dotnet core has some good documentation around their implementation, but if you want to you something else you can.

 services.AddScoped<IMyDependency, MyDependency>();
 services.AddTransient<IOperationTransient, Operation>();
 services.AddScoped<IOperationScoped, Operation>();
 services.AddSingleton<IOperationSingleton, Operation>();

Testing

I just briefly wanted to discuss testing. Using some of the techniques I’ve discussed, testing services and classes is much easier. By having interfaces for all my major services, constructor injection in place, and a mocking framework, I can isolate classes for testing.

 private BookService _bookService;
 private Mock<IBookRepository> _mockBookRepository;
 private Mock<IBookEntityDomainAdapter> _mockBookEntityDomainAdapter;

 [TestInitialize]
 public void TestInitialize()
 {
 _mockBookRepository = new Mock<IBookRepository>();
 _mockBookEntityDomainAdapter = new Mock<IBookEntityDomainAdapter>();

 _bookService = new BookService(_mockBookRepository.Object, _mockBookEntityDomainAdapter.Object);
 }

 [TestMethod]
 public void GetAll_ItemsInRepository_ReturnsSameNumberOfItems()
 {
 //arrange
 var sampleData = Enumerable
 .Repeat(new BookEntity(), 5)
 .ToList();
 _mockBookRepository.Setup(x => x.GetAll())
 .Returns(sampleData);

 //act
 var result = _bookService.GetAll();

 //assert
 Assert.AreEqual(sampleData.Count(), result.Count());
 }

Where to Go from here - Refactoring

Taking legacy code, code without tests (essentially the same thing), or code written without dependency injection and refactoring it into testable, decoupled code is not as easy as installing a nuget package. If you are just getting started and you have a ton of new ServiceX() and ServiceY.action() sprinkled throughout your code, code review the docs at: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-3.0. Have interfaces for your classes. When you have dependencies, instantiate them in your constructor if you can’t setup DI, it will help with readability and maintainability.

Conclusion

Dependency Injection is a pattern that everyone should be using. It makes the code more readable, maintainable, and testable. I know a lot of people think that this is something we’ve solved and everyone uses, but we’re not. Too many people aren’t setting up DI, they aren’t using interfaces, they aren’t registering dependencies. We need to keep discussing this because people are constantly starting out, learning, and growing in this field.

There is some sample code at: https://github.com/Codebytes/DependencyInjectionDemo

Presenting with VS Code - Screencast mode

Sun, 06 Oct 2019 11:58:28 +0000

I have been starting to speak and present a lot more, and was looking into great tools like Carnac and KeyPosé. But I just found out today about a feature I didn’t know existed inside Visual Studio Code, Screencast mode. This was introduced in January 2019. How did I miss it?

To enable and use Screencast mode, Open the command palette, Ctrl + Shift + P.

When first enabled, Screencast Mode is not what I wanted. It shows EVERY keypress. It also shows a little higher on the screen that I prefer. It also puts a little red circle everywhere I click the mouse, which is nice. Let’s configure it and see if we can clean up some of that. Open the command palette again (Ctrl + Shift + P) and go to the user settings.

There aren’t a lot of options right now, but I only want to see keyboard shortcuts.. Ctrl+C, Ctrl+V, Alt+Shift+F. So I’ll check that, and I want it a little lower on the screen, so I lowered the default from 20 down to 5. Let’s see the finished product:

Awesome. I can now go on a mac, linux, or windows machine and have a consistent experience with sharing my keypresses and mouse clicks. If you present, live code, or give demos, this is a great feature to enable and I encourage you to do so. Seeing all the keyboard shortcuts people use is a great thing to learn.

RESTful API Versioning

Mon, 02 Sep 2019 22:26:57 +0000

I’ve been a developer for a long time, writing APIs and clients to consume them. When an API is around long enough, it needs to change. I’ve versioned APIs in the past using a number of different techniques. Some successful, some painful. Now I realize this discussion is like the VI/Emacs conflict, the Tab/Space wars, and the Spanish Inquisition, but it is a good topic to look at. There are a few main styles when it comes to API versioning:

URL
Query Parameter
Accept header
Custom request header

URL

This is where a lot of people start, you might have seen it out there. You can easily see the version of the API you are calling. And a lot of times behind the scenes, the base API points to the latest version. The issue a number of people have with this, myself included, is that a URL in RESTful APIs should represent an entity, not a version of an entity. For example, /api/v1/users/27 and /api/v2/users/27 are not two different users. As you add new versions, you break permalinks to resources. And you’re tying the URL of a resource, not to a version of it.

/api/users -> /api/v2/users
/api/v1/users
/api/v2/users

Query Parameter

Another way people can version APIs is by Query Parameter. This keeps the URL consistent, but adds an extra parameter. This is fine by my book, you’re adding extra info to the request, not the resource. It can change per request, and doesn’t change the permalink or URL of the resource.

/api/users -> /api/users?api-version=1.0
/api/users?api-version=1.0
/api/users?api-version=2.0

Accept Header

The third way I’ve seen API versioning is an accept header on the http(s) request. Accept headers describe how you’ld like to receive the data. Being part of the http headers, this can be taken into effect during caching, and if not specified explicitly can return the latest version. I like this method quite a bit, the client is telling the server how it wants to receive the data, the format and the version.

GET api/users HTTP/1.1
host: localhost
accept: application/json;v=2.0

Custom Header

The last way I’ve seen is to define a custom http header. Just adding the requested version as a header to the request. This isn’t as easily compatible with clients as the other methods.

api-version: 1.0

Implementation

In the past, I’ve had to roll my own. I started with URL versioning. As I worked with RESTful APIs, I realized there was a better way and started moving towards either the Query parameter or an Accept Header. There are some pretty good libraries that will handle a lot of this for you today.

Microsoft has a library that works with .Net Framework 4.5 and .Net Core. It’s called ASPNet API Versioning, https://github.com/microsoft/aspnet-api-versioning . They also released libraries to work with Swagger for API documentation. Honestly, its pretty nice and supports a number of methods for versioning that you can customize pretty well. This follows the Microsoft REST API Guidelines.

There are some more references to check out at http://apistylebook.com/design/topics/versioning

ARM - Part 3: Hook up the Pipes

Tue, 28 May 2019 18:30:31 +0000

I’ve got a template straight from Microsoft. I want this wired into a CI/CD pipeline to I can play around and get quick feedback. I’m going to use Azure DevOps to help make all this possible. Let’s get those templates into a repository to get started. New repository, initialize it, add new files.

Next, I’m going to create a new resource group to play around with my web app resources.

Now we need to make sure DevOps has permission to create and update resources in Azure. This can be done in a few different ways as described here: https://docs.microsoft.com/en-us/azure/devops/pipelines/library/connect-to-azure?view=azure-devops.

I’m going to setup a service connection from DevOps to Azure. In Azure Devops, I’m going to go to my project settings:

And go to Service Connections:

We’ll create a new Azure Resource Manager service connection.

We just need to pick the right Subscription, Sign in, and point it at our resource group. There are more complex setups, and we’ll get into those in the future, but for now we’ll just point it at that resource group I created earlier. Now for this to work properly, you have to be able to grant rights to the connector.

Now we’ve got a connector to deploy to Azure. We’ll finish this up next time.

ARM - Part 2: Azure Quickstart Templates

Mon, 13 May 2019 20:59:03 +0000

Time to Dive in

I’m one of those guys that likes to learn by doing. Reading the documentation is great, and I do that a lot. But for me to really grok something, I need to play with it, run it, and probably blow it up.

If you missed part 1, read along and come back. I need a WebApp setup for my sample project. I realized I can do it a few ways. Some of the ways are very manual, some are repeatable, but one stood out to me.

Create the resources in the Azure Portal
Create the resources in Visual Studio when I right-click Publish
Create the resources via a Powershell script
Create the resources via the Azure CLI
Create an ARM Template, create the resources on deploy, or via the CLI

Let’s Write an ARM Template

I know what I want to do, write an ARM Template. Do I have any idea what I’m doing or where to start at this point? No. Fortunately for me, Microsoft provides a BUNCH of resources to get you started. There is an entire searchable quickstart page with examples (backed by a GitHub repository) as well the Microsoft Docs on ARM Templates.

Well, I found one in the quickstart: https://learn.microsoft.com/en-us/azure/app-service/quickstart-arm-template?pivots=platform-windows. From this quickstart, I can click Deploy to Azure, fill out some information and I’ve got an App Service Plan and a Web App. This is so cool. Now to tear this thing apart and figure out what it is.

OK, Lets play with an ARM Template

In the GitHub repository it looks like there are 2 or 3 files that make up the ARM Template.

Dissection

Lets dissect azuredeploy.json. Schema, version, blah…

Parameters

My eye is drawn to the Parameters section. I recognize some of these from when I deployed to Azure. Getting a feel for parameters I see you can have metadata describing them, types, lengths, and default values. This gives me lots of ideas and options.

Variables

This isn’t your mama’s json. That looks like a function to me! Looks like somebody got their code in my json. I like it. A quick google later and I see a huge list of template functions in Microsoft’s documentation. I’ll come back to that. In the mean time, those variables look a lot like the name of the webapp and AppServicePlan. I can work with this.

Resources

Meat and potatoes. Jackpot. This looks like where the resources are defined. Only a few properties on each, an apiVer, type, name, location, sku, and a few others. I also notice one has a “dependsOn” property, I bet I can build up what depends on what and it will do everything in the right order.

Next Steps

I’ve got an ARM Template now that works. I’ve poked at it a little. Time to make this thing fly. Lets setup an Azure repository on DevOps and see about trying to deploy this thing and create my webapp on release. I want to be able to check in a change and have it create/update my resources in azure. Next time, we start the feedback loop.

ARM - Part 1: Azure Resource Manager

Sat, 11 May 2019 23:53:57 +0000

The Journey Begins

I’ve been an azure developer for years. Originally I worked with “Classic Mode” and Cloud Services. Then I moved to ARM and Web Apps. Lately I’ve been doing DevOps but I only recently started working with ARM Termplates. First, let’s dive into a little history.

History

Azure has grown and changed since it was first introduced. Originally, it was a research project called, “Project Red Dog”. Azure has been commercially available since 2010. For four years, there was a limited way to interact with Azure, ASM the Azure Service Manager.

The Old Thing (Classic Mode) - ASM Azure Service Manager

The big problem with ASM was that all the resources were disconnected and separate. If you had multiple things you were creating, you had to keep track of them, create them in the right order, and make sure you deleted them all when things were removed. You were also limited in capabilities, like policies, tagging, and security. I remember the deployment scripts that you would write to check if things existed, poll when they got created, and you would have to keep tweaking to get it to run properly. Powershell was the language and script of choice.

The New Thing - ARM Azure Resource Manager

ARM was released in 2014. ARM is a great change. Instead of writing scripts to poll and make sure things were created, you can deploy and manage resources as a group. It opens the door for repeated deployments and templates. It lets you define the deployment order and apply tags and policies. You can still write Powershell, the but there are new modules for ARM (Azure-RM*). But you can also use Azure CLI, Rest APIs and client SDKs. I will definitely be diving into the Azure CLI in the future. Right now, the part I’m loving, is that I can define my infrastructure as code.

ARM Templates

ARM Templates are amazing. I plan on diving deep into this over the next few blog posts. But what is awesome is that I can have my project source code and the infrastructure it runs on checked into the same repository. Those files can then be built and deployed together. I can continuously deploy my environment and the deployment can apply the differences as needed. Microsoft has some great documentation on ARM Templates. They also have a great quickstart resource: Azure Quickstart Template. I’ll be diving into those topics next time in part 2.

Blog Incoming

Tue, 30 Apr 2019 21:26:33 +0000

Time to get back to it.