Skip to main content

🏗️ Architecture

This section explains the core technical structure of the Variant Development Platform. It covers how storage, Azure resources, services, deployments, and messages are organized and managed.

🆕 Subscription Identifier​

When a new customer subscription is created, the customer must choose an 8 to 14 character lowercase string.

  • This string becomes the customer's Subscription ID.

  • It is used to name all Azure resources created by Variant for that customer.

  • Example: If you choose mycompany, resources will be named like:

    • `com-mycompany-rg
    • commycompanysa
    • devmycompanysa
    • dev-mycompany-identity

✅ Consistent naming based on your subscription ID ensures clear, traceable resource organization across all environments.

☁️ Customer Azure Subscription Structure​

When a new customer subscription is created, Variant provisions and manages resources directly inside the customer's own Azure subscription, giving full data isolation and ownership.

Two main Azure Resource Groups are created automatically:

  • com-mycompany-rg (Development Management Group)

    • Storage Account: commycompanysa (stores service source code, configuration, packages, environment artifacts)

    • Managed Identity: com-mycompany-identity (for platform access to storage and resources)

  • dev-mycompany-rg (Development Runtime Group)

    • Storage Account: devmycompanysa (used by deployed services for runtime storage of blobs, queues, fileshares, tables)

    • Managed Identity: dev-mycompany-identity (for services to access Azure resources)

    • Key Vault: dev-mycompany-kv (secure secret, config, key management)

    • Application Insights: dev-mycompany-ai (logging, monitoring, telemetry)

✅ All customer service data, configurations, deployments, and runtime artifacts stay fully isolated within their own Azure resources.

🛠️ Infrastructure as Code (IaC) Capabilities​

Variant includes native Infrastructure as Code (IaC) capabilities, allowing users to fully script, customize, and update the default environment and service resource structures.

  • Variant.DevOps Service: Automatically included when a subscription is created.

  • Infrastructure Scripting:

    • Define environment-level resources (e.g., storage, key vaults, App Insights, identities) using Y# YAML scripts.
    • Define service-specific deployments (e.g., function app templates, configuration artifacts) using Y#.

  • IaaS Scripting Power:

    • Y# scripting offers equivalent capabilities to Terraform and Ansible for creating and managing infrastructure.
    • Full control to create, modify, and automate Azure resources and services.

✅ The default architecture created by Variant is completely user-extensible and customizable — allowing customers to update and evolve their infrastructure easily through Variant's powerful Y# scripting language.

🛢️ Storage Architecture​

Variant separates service configuration and operational data into two Azure Storage Accounts per customer:

  • commycompanysa (Development Storage)

    • Holds service source code, YAML pipelines, packages, release artifacts.

    • Contains folders:

      • apps/ (services by environment)
      • packages/ (extension packages)
      • infrastructure/ (artifacts, environment state)
      • backups/ (source control backup points)

  • devmycompanysa (Runtime Storage)

    • Holds runtime artifacts like blobs, queues, tables, and file shares used by deployed services.

✅ All service files (except backups) are under Git-style version control managed by Variant.

🏗️ Azure Resources per Environment​

When additional environments are created (e.g., UAT, SIT, PROD), Variant provisions the same resource structure for each environment:

  • Resource Group: <env>-mycompany-rg
  • Storage Account: <env>mycompanysa
  • Managed Identity: <env>-mycompany-identity
  • Key Vault: <env>-mycompany-kv
  • Application Insights: <env>-mycompany-ai

✅ Test and Production environments can also be deployed to separate Azure subscriptions for maximum security and separation.

⚙️ Service Architecture​

A Variant Service is made up of:

  • Variant Runtime Assemblies: Core platform functionality.
  • Extension Packages: Additional connectors, pipes, strategies.
  • YAML Code Files: Define service logic, connectors, pipelines, and endpoints.
  • Configuration Files: appsettings.json, site-config.yaml

When deployed:

  • All artifacts are zipped into a deployable package.
  • Services run as Azure Function Apps (containerized deployments in Beta).
  • Connectors initialize listeners (e.g., HTTP endpoints, timers).
  • Pipelines process messages via sequences of pipes and strategies.

🔄 Update and Deployment Model​

  • YAML Code Changes: Instantly reflected in the deployed service.
  • Extension Package Updates: Require full redeployment.
  • Configuration Changes: (e.g., appsettings.yaml, environments.yaml)
    • Must press Update Settings in the UI.
    • Triggers full overwrite of app settings and an immediate service restart.

✅ Fast developer feedback with minimal downtime.

🧬 LokiMessage Core Model​

All pipelines in Variant operate on a standard message object: LokiMessage.

Main features:

  • Headers: Key-value pairs for routing, tracking, metadata.
  • Payload: Main body of the message.
  • Spawned Messages: Allows a single message to generate child messages for parallel processing.
  • Transactional Awareness: Track correlation and flow.

✅ LokiMessage ensures a consistent, predictable model across all services and pipelines.