DEV Community: Frank Wagner

Deployment Flexibility for .NET: Hosuto modules

Frank Wagner — Fri, 26 Sep 2025 10:20:25 +0000

We're committed to cloud-native architecture and microservices, but when you're building enterprise software for customers, you face a reality check: some customers want simple, one-click installations they can run on a single server, while others need cloud-native deployments that scale horizontally. Building separate monolithic and microservices versions of the same product isn't sustainable.

So we built Hosuto some years ago to solve this. It's a .NET library that lets you write modular code once and deploy it any way you need - bundled together as a monolith or distributed as microservices. We've been using it as the foundation for many of our products, from SAP integrations to open source projects like eryph.

How Hosuto Works

Hosuto enables you to build modules instead of monoliths or microservices. These modules can run together in one process or distributed across multiple services. The module code remains identical regardless of deployment configuration.

The architecture centers around a parent host (ModulesHost) that coordinates multiple modules. Each module runs within its own isolated host context (IModuleHost<T>) with its own dependency injection container, while still having access to shared services from the parent host's DI container. This design provides module isolation while enabling resource sharing - modules can't interfere with each other's services, but they can access common infrastructure like configuration, logging, and message buses.

Option 1: Bundled

Option 2: Distributed

Module Structure

A module is a C# class that defines its services and configuration:

public class OrderModule : IWebModule
{
    public string Path => "/orders";

    public void ConfigureServices(IServiceProvider serviceProvider, IServiceCollection services)
    {
        // Inject shared services from the host
        services.AddSingleton(serviceProvider.GetRequiredService<IEventBus>());

        // Configure module-specific services
        services.AddScoped<IOrderService, OrderService>();
        services.AddControllers();
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        app.UseRouting();
        app.UseEndpoints(endpoints =>
        {
            endpoints.MapControllers();
        });
    }
}

Bundled Deployment

For development or simple deployments, run all modules in one process:

// Program.cs - Everything in one process
public static IHostBuilder CreateHostBuilder(string[] args)
{
    var services = new ServiceCollection()
        .AddSingleton<IEventBus, InMemoryEventBus>()
        .AddSingleton<IOrderRepository, OrderRepository>();

    return ModulesHost.CreateDefaultBuilder(args)
        .UseServiceCollection(services)
        .UseAspNetCoreWithDefaults()
        .HostModule<OrderModule>()        // Orders API
        .HostModule<PaymentModule>()      // Payments API
        .HostModule<InventoryModule>()    // Inventory API
        .HostModule<UIModule>()           // Web UI
        .ConfigureAppConfiguration(config => config
            .AddInMemoryCollection(new Dictionary<string, string>
            {
                ["bus:type"] = "inmemory",      // In-process communication
                ["databus:type"] = "inmemory"
            }));
}

Distributed Deployment

To scale individual components, extract modules to separate services without modifying module code:

// OrderService/Program.cs - Just the Order module now
public static IHostBuilder CreateHostBuilder(string[] args)
{
    var services = new ServiceCollection()
        .AddRabbitMqEventBus()  // Distributed event bus
        .AddCosmosDbRepository(); // Shared database

    return ModulesHost.CreateDefaultBuilder(args)
        .UseServiceCollection(services)
        .UseAspNetCoreWithDefaults()
        .HostModule<OrderModule>()  // Only the Order module
        .ConfigureAppConfiguration(config => config
            .AddEnvironmentVariables("MYAPP_")
            .AddInMemoryCollection(new Dictionary<string, string>
            {
                ["bus:type"] = "rabbitmq",
                ["bus:connectionstring"] = "amqp://guest:guest@rabbitmq"
            }));
}

Production Example: SAPHub

SAPHub demonstrates Hosuto in a production environment.

SAPHub provides a REST API for asynchronous SAP data access, built with three modules:

API Module: REST endpoints for external clients
UI Module: Blazor-based management interface
SAP Connector Module: Handles SAP system integration

Module communication is determined by configuration:

Development (In-Memory):

{
  "bus": { "type": "inmemory" },
  "databus": { "type": "inmemory" }
}

Production (Distributed):

{
  "bus": {
    "type": "rabbitmq",
    "connectionstring": "amqp://guest:guest@rabbitmq"
  },
  "databus": {
    "type": "azurestorage",
    "connectionstring": "DefaultEndpointsProtocol=https;..."
  }
}

Different Ways to Deploy

Everything together:

// SAPHub.Server - Everything in one process
.HostModule<ApiModule>()
.HostModule<UIModule>()
.HostModule<SAPConnectorModule>()

API-Only Service:

// SAPHub.ApiEndpoint - Just the API
.HostModule<ApiModule>()

Connector-Only Service:

// SAPHub.SAPConnector - Just the SAP integration
.HostModule<SAPConnectorModule>()

Benefits

Hosuto provides deployment flexibility. The same module code can be deployed bundled together in a single process or distributed across multiple services, depending on your requirements.

Want to Try It?

Here's how to get started:

Install the package:

dotnet add package Dbosoft.Hosuto

Create a module:

public class MyModule : IWebModule
{
    public string Path => "/api";

    public void ConfigureServices(IServiceProvider serviceProvider, IServiceCollection services)
    {
        services.AddControllers();
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        app.UseRouting();
        app.UseEndpoints(endpoints => endpoints.MapControllers());
    }
}

Host it:

ModulesHost.CreateDefaultBuilder(args)
    .UseAspNetCoreWithDefaults()
    .HostModule<MyModule>()
    .Build()
    .Run();

When scaling requirements emerge, extract modules to separate services without code modifications.

Conclusion

Hosuto addresses the deployment flexibility challenge in enterprise software. Rather than committing to monolithic or microservices architecture upfront, teams can start with bundled deployment and transition to distributed services as requirements evolve.

Module code remains constant across deployment configurations, enabling architectural evolution without rewrites. This approach reduces both initial complexity and long-term technical debt.

Want to see Hosuto in action? Check out the SAPHub sample application or explore the Hosuto documentation to get started with your own flexible .NET applications.

[Boost]

Frank Wagner — Thu, 25 Sep 2025 10:33:23 +0000

Docker for VMs: "Works on all Machines" with eryph

Frank Wagner ・ Sep 25

#devops #docker #productivity #azure

Docker for VMs: "Works on all Machines" with eryph

Frank Wagner — Thu, 25 Sep 2025 08:59:41 +0000

The VM Config Drift Problem

Docker solved the "works on my machine" problem. With VMs, you have to build it twice: once for development and once for production. You might also need to build it for CI, test, etc.

You spend days getting the perfect development environment - services configured, databases tuned, everything working together. Then deployment time comes and your development setup has conveniences baked in: default users, insecure keys, debug tools, dev-friendly assumptions.

Production can't use any of it. You start over with a clean base image and completely different provisioning scripts, rebuilding everything you already built.

Development VMs become throwaway sandboxes that can't be used anywhere else. You perfect something in dev, then start over for production with different tools, different configs, different everything.

This creates a fundamental disconnect. Your development environment is optimized for developer convenience - default users, debug tools, development-friendly networking. Production environments need security hardening, monitoring, compliance configurations.

Current tools handle this by making development and production completely separate worlds. Vagrant excels at developer environments with convenient boxes and simple orchestration. Production uses different tools entirely - Terraform, cloud-init, enterprise orchestration platforms.

The result? You spend time perfecting configurations that require complex workarounds to reuse. Knowledge doesn't transfer easily between environments. Development becomes a sandbox that requires translation for production.

Docker Model for VM Configs

There's a new tool called eryph that takes a different approach.

Docker lets you build an image locally, push it to a registry, then pull that exact same image in production. Same layers, same configs, everything identical.

Eryph does something similar, but for VM configurations instead of container images. You create these things called "genes" that are basically reusable VM config chunks. A gene might configure nginx, another might set up your app stack. You compose them together like Docker layers.

But unlike Vagrant boxes that are environment-specific, eryph genes work everywhere. The nginx config I write for development is the exact same nginx config that runs in production.

Shared Configs in Action

Let me show you how this actually works.

Say I'm building a web app that needs nginx. In development, I want the convenience stuff - a default user I can SSH as, maybe some debug tools. In production, I need the same nginx config but with security hardening and monitoring.

In my development environment:

# dev-server.yaml
name: nginx-dev
parent: dbosoft/ubuntu-22.04/latest          # Neutral base
fodder:
  # Dev convenience 
- source: gene:dbosoft/starter-food:linux-starter
- source: gene:myorg/nginx-config            # SHARED CONFIG
- source: gene:myorg/app-stack               # SHARED CONFIG

In production, I use the exact same base and the exact same app configs:

# prod-server.yaml
name: nginx-prod
parent: dbosoft/ubuntu-22.04/latest    # Same neutral base
fodder:
- source: gene:myorg/nginx-config      # Same nginx config
- source: gene:myorg/app-stack         # Same app config
- source: gene:myorg/prod-hardening    # Production additions
- source: gene:myorg/monitoring        # Production additions

The nginx and app stack genes are identical between dev and production. Only the environment-specific stuff changes.

When I fix a bug in the nginx config or optimize something, both environments get the improvement automatically. No rebuilding production from scratch, no manual syncing, no wondering if dev and prod have drifted apart.

Why This Works Better

It's basically like Docker layers, but for VMs. Instead of rebuilding everything for each environment, you compose from shared pieces.

The traditional way wastes so much work:

Development: Vagrant box with custom scripts, throw it all away later
Production: Start over with different base image, different scripts

With eryph, you build on shared foundations:

Development: Neutral base + dev conveniences + your app configs
Production: Same neutral base + same app configs + production hardening

Try It Yourself

Want to see how this works? Let me walk through setting up a shareable config.

First, install eryph. It runs on Windows with Hyper-V:

# Run in elevated PowerShell
irm https://raw.githubusercontent.com/eryph-org/eryph/main/src/apps/src/Eryph-zero/install.ps1 | iex

If you are on MacOs/Linux you can still use eryph via powershell commands - but you need a shared machine with eryph-zero somewhere.

Now I'll create a web server config that could work in both dev and production:

# web-config.yaml
name: shared-webserver
parent: dbosoft/ubuntu-22.04/latest
fodder:
- source: gene:dbosoft/starter-food:linux-starter
- name: nginx-setup
  type: cloud-config
  content:
    package_update: true
    packages:
      - nginx
    write_files:
    - path: /var/www/html/index.html
      content: |
        <h1>Shared Config Works!</h1>
        <p>This same config runs in dev and production</p>
    runcmd:
      - systemctl enable nginx
      - systemctl start nginx

Deploy and test it:

# Deploy the VM
Get-Content web-config.yaml | New-Catlet | Start-Catlet

# Get IP and test
$ip = (Get-Catlet | `
   Where-Object Name -eq "shared-webserver" | ` 
   Get-CatletIp).IpAddress
start "http://$ip"

That web server config would work identically in production, just with different surrounding genes for hardening and monitoring.

No more maintaining separate configs that slowly drift apart. No more rebuilding the same nginx setup three different ways for dev, staging, and production.

The configs become portable and shareable, like Docker images but for full VMs. You can push your proven nginx fodder as a custom gene to the eryph genepool, someone else can pull it and layer their app on top, everyone benefits from improvements.

It works with whatever tools you're already using too. If you're a Vagrant user, there's a vagrant-eryph provider. PowerShell users get native cmdlets. There's even a GUI app if you prefer that.

The VMs built by eryph can be used directly with an on-premises Hyper-V installation or uploaded to Azure. For other platforms, the configuration is available as a generated cloud-init ISO, which is compatible with all platforms and images that support cloud-init.

Want to try it? The Quickstart has everything you need to get started, and you can browse existing configs at genepool.eryph.io. The whole thing is open source and free for development work.