ms-ai-architect/skills/ms-ai-engineering/references/mlops-genaiops/mlops-fundamentals-overview.md

# MLOps Fundamentals - Lifecycle and Principles

**Last updated:** 2026-06-19
**Verified:** MCP 2026-06-19
**Status:** GA
**Category:** MLOps & GenAIOps

---

**Verified:** MCP 2026-06-19

## Introduksjon

Machine Learning Operations (MLOps) er anvendelse av DevOps-prinsipper på machine learning-prosjekter. Målet er å automatisere og effektivisere hele ML-livssyklusen – fra eksperimentering og trening, via deployment, til overvåking og retrening. MLOps bygger på etablert DevOps-praksis som continuous integration (CI), continuous deployment (CD), version control, og infrastructure as code (IaC), men legger til ML-spesifikke utfordringer som data versioning, model tracking, feature engineering, og drift detection.

I motsetning til tradisjonell applikasjonsutvikling, hvor kode er deterministisk, opererer ML-modeller med data som en kjerneavhengighet. Dette introduserer ekstra kompleksitet: modeller må retrenes når data endrer seg, modellytelse kan degradere over tid (model decay), og reproduserbarhet krever versjonering av både kode, data, og miljøer. MLOps adresserer disse utfordringene ved å tilby strukturerte prosesser og verktøy for model lifecycle management.

Microsoft tilbyr Azure Machine Learning som primærplattform for MLOps, med integrert støtte for pipelines, model registries, automated retraining, monitoring, og integrasjon med Azure DevOps og GitHub Actions. MLOps-modenhet måles typisk langs en 5-nivåskala (Level 0-4), hvor organisasjoner gradvis beveger seg fra manuelle prosesser til fullautomatisert CI/CD/CT (Continuous Training).

## Kjernekomponenter

MLOps-livssyklusen består av flere distinkte faser, ofte kategorisert som "inner loop" (data science-fokusert) og "outer loop" (engineering/operations-fokusert).

### Inner Loop (Data Science)

| Komponent | Beskrivelse | Ansvarlig rolle |
|-----------|-------------|-----------------|
| **Data Collection** | Innhenting og aggregering av treningsdata fra produksjonskilder | Data Engineer |
| **Data Preparation** | Rensing, validering, transformasjon, og feature engineering | Data Scientist + Data Engineer |
| **Model Training** | Eksperimentering, hyperparameter tuning, modellutvikling | Data Scientist |
| **Model Evaluation** | Validering av modellytelse mot acceptance criteria | Data Scientist |

### Outer Loop (ML Engineering)

| Komponent | Beskrivelse | Ansvarlig rolle |
|-----------|-------------|-----------------|
| **Model Packaging** | Containerisering av modell med dependencies (Docker) | ML Engineer |
| **Model Registration** | Versjonering og lagring i model registry | ML Engineer |
| **Model Deployment** | Utrulling til inference endpoints (batch/online) | ML Engineer + DevOps |
| **Model Monitoring** | Overvåking av ytelse, drift, og data quality | ML Engineer + Data Scientist |
| **Model Retraining** | Automatisk eller manuell retrening ved degradering | Data Scientist + ML Engineer |

### MLOps Capabilities (Azure ML)

1. **Reproducible ML Pipelines** – Definere gjenbrukbare steps for data prep, training, scoring
2. **Reusable Environments** – Version-controlled conda/pip environments for consistency
3. **Model Registry** – Sentralisert lagring med metadata (hvem, hva, når, hvorfor)
4. **Lineage Tracking** – Full sporbarhet fra raw data til deployed model
5. **Event-Driven Automation** – Azure Event Grid for lifecycle events (training complete, drift detected)
6. **Monitoring & Alerting** – Sentralisert innsamling av metrics (model performance, data drift, infrastructure)
7. **CI/CD Integration** – Azure Pipelines, GitHub Actions, eller andre CI/CD-verktøy

## Arkitekturmønstre

MLOps-arkitekturen følger typisk fire hovedfaser: **Data Estate**, **Administration & Setup**, **Model Development (Inner Loop)**, og **Model Deployment (Outer Loop)**.

### Pattern 1: Manual MLOps (Level 0)

**Scenario:** Ingen formalisert MLOps-prosess. Data scientists jobber isolert, leverer modeller som filer.

**Karakteristikker:**
- Manuell datahenting og modelltrening
- Ingen eksperiment tracking eller version control
- Modeller deployes manuelt av data scientist
- Ingen sentralisert monitoring

**Når bruke:**
- POC/prototyping-faser
- Små team uten dedikert ML engineering
- Lav modell refresh-frekvens

**Risiko:** Ikke-reproduserbar, vanskelig å skalere, høy avhengighet av individer.

### Pattern 2: Automated Training (Level 2)

**Scenario:** Treningsprosessen er automatisert og sporbar, men deployment er fortsatt manuell.

**Karakteristikker:**
- Automatiserte data pipelines
- Managed compute (Azure ML Compute)
- Experiment tracking (MLflow)
- Model registry med versioning
- Scheduled eller event-driven retrening
- Manuell release til produksjon

**Når bruke:**
- Team med data scientists + data engineers, men begrenset DevOps-kapasitet
- Moderat modell refresh-frekvens (ukentlig/månedlig)
- Kontrollert release-prosess med QA gates

**Teknologi:** Azure ML Pipelines, Azure Event Grid, Managed Feature Store.

### Pattern 3: Full CI/CD/CT (Level 4)

**Scenario:** Fullautomatisert end-to-end MLOps med zero-touch deployment og self-healing.

**Karakteristikker:**
- Automatisk datapipeline og modelltrening
- Automatisk A/B testing og blue-green deployment
- Policy-basert model promotion (registries)
- Drift detection trigger automatic retraining
- Sentralisert monitoring med auto-alerting
- Infrastructure as Code (Bicep/Terraform)

**Når bruke:**
- Store team med dedikert ML Platform Engineering
- Høyfrekvent modell refresh (daglig/real-time)
- Kritiske produksjonssystemer med SLA-krav

**Teknologi:** Azure ML CLI/SDK v2, Azure DevOps, Event Grid, Azure Monitor, ML Registries.

## Beslutningsveiledning

### Velge riktig modenhetsnivå

| Kriterium | Level 0-1 | Level 2 | Level 3-4 |
|-----------|-----------|---------|-----------|
| **Team size** | 1-3 personer | 3-10 personer | 10+ personer |
| **Modeller i prod** | 1-2 | 3-10 | 10+ |
| **Refresh-frekvens** | Månedlig/kvartalsvis | Ukentlig | Daglig/kontinuerlig |
| **Compliance-krav** | Lave | Moderate | Høye (regulerte sektorer) |
| **DevOps-kapasitet** | Ingen | Begrenset | Dedikert team |
| **SLA-krav** | Best effort | 95% uptime | 99%+ uptime |

### Vanlige feil (Anti-patterns)

| Feil | Konsekvens | Løsning |
|------|------------|---------|
| **Ingen data versioning** | Umulig å reprodusere modeller | Bruk Azure ML Datasets med versioning |
| **Manuell deployment** | Høy risiko for feil, ingen rollback | Implementer CI/CD med automated tests |
| **Ingen drift monitoring** | Modeller degraderer uoppdaget | Implementer data drift detection + alerting |
| **Tight coupling** | Endringer i én komponent bryter hele systemet | Bruk modular pipelines med klare interfaces |
| **Manglende lineage** | Umulig å spore root cause ved feil | Aktiver full lineage tracking i Azure ML |

### Røde flagg

- **"Vi retrainer modellen når noen husker det"** → Ingen scheduled retraining
- **"Modellen ligger på data scientist sin laptop"** → Ingen model registry
- **"Vi vet ikke hvilke data som ble brukt til trening"** → Ingen data lineage
- **"Deployment tar 2 uker"** → Ingen CI/CD automation
- **"Vi oppdager model decay når brukere klager"** → Ingen proactive monitoring

## Integrasjon med Microsoft-stakken

### Azure Machine Learning

**Primærplattform for MLOps.** Tilbyr:
- **Azure ML Pipelines** – Orchestration av training/deployment workflows
- **Model Registry** – Sentralisert model versioning + promotion
- **Managed Endpoints** – Online (real-time) og Batch inference
- **Environments** – Reproducible conda/docker environments
- **Compute Targets** – Managed compute clusters (CPU/GPU)

**Integrasjonspunkter:**
- **Azure DevOps** – CI/CD pipelines via Azure Pipelines extension
- **GitHub Actions** – GitHub integration for MLOps workflows
- **Azure Event Grid** – Event-driven automation (model registered, drift detected)
- **Azure Monitor** – Centralized logging + alerting

### Azure DevOps

**CI/CD orchestration.** Bruk for:
- **Azure Pipelines** – Automated testing, model training, deployment
- **Azure Repos** – Source control for training code, pipeline definitions
- **Azure Boards** – Agile planning (sprints, backlog)

**Sample pipeline (YAML):**
```yaml
trigger:
- main

variables:
  service-connection: 'ml-service-connection'
  resource-group: 'ml-rg'
  workspace: 'ml-workspace'

jobs:
- job: SubmitMLJob
  pool:
    vmImage: ubuntu-latest
  steps:
  - task: UsePythonVersion@0
    inputs:
      versionSpec: '>=3.10'
  - bash: |
      az extension add -n ml
    displayName: 'Add Azure ML CLI'
  - task: AzureCLI@2
    inputs:
      azureSubscription: $(service-connection)
      scriptType: bash
      inlineScript: |
        az ml job create --file pipeline.yml \
          -g $(resource-group) \
          -w $(workspace)
```

### GitHub Actions

**Alternative til Azure DevOps.** Bruk for:
- Open source-prosjekter
- Team som allerede bruker GitHub
- Enklere setup for mindre team

**Sample workflow:**
```yaml
name: Train and Deploy ML Model
on:
  push:
    branches: [main]
jobs:
  train:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}
    - run: |
        az extension add -n ml
        az ml job create --file pipeline.yml
```

### Azure AI Foundry

**For generative AI workloads.** MLOps-prinsipper gjelder, men med tillegg:
- **Prompt versioning** – Prompt engineering som kode
- **RAG pipelines** – Vector ingestion + indexing automation
- **Safety monitoring** – Content filtering + responsible AI metrics
- **Token cost tracking** – GenAIOps-spesifikk

**Husk:** GenAIOps er *supplement* til MLOps, ikke erstatning. Bruk MLOps Maturity Model + GenAIOps Maturity Model separat.

## Offentlig sektor (Norge)

### Compliance og revisjon

**Riksrevisjonen og Difi-krav** krever:
- **Full sporbarhet** – Hvem trente modellen, med hvilke data, når?
- **Reproducerbarhet** – Kunne gjenskape nøyaktig samme modell
- **Auditability** – Logging av alle endringer i model lifecycle
- **Explainability** – Kunne forklare modellbeslutninger (GDPR Art. 22)

**Azure ML støtter:**
- **Lineage tracking** – Automatisk logging av data → model → deployment
- **Model interpretability** – SHAP, LIME integration
- **Audit logs** – Azure Monitor + Log Analytics
- **Tags og metadata** – Custom tags for organisasjonsspesifikke krav

### Datahåndtering

**Personvern (GDPR/Datatilsynet):**
- Data må lagres i EU/Norge (Azure Norway East/West)
- Samtykke må versjoneres sammen med data
- Rett til sletting må implementeres (data deletion pipelines)

**Anbefaling:** Bruk Azure ML Datasets med:
- **Data versioning** – Immutable snapshots
- **Access control** – RBAC på dataset-nivå
- **Encryption** – At rest (Storage Account) + in transit (HTTPS)

### Dokumentasjonskrav

**For hver modell i produksjon:**
- **Model Card** – Beskrivelse av modell, use case, limitations
- **Training Data Spec** – Hvilke data, tidsperiode, pre-processing
- **Performance Metrics** – Accuracy, precision, recall, etc.
- **Bias Assessment** – Fairness metrics per demografisk gruppe
- **Retraining Policy** – Når og hvorfor modellen retrenes

**Automatiser:** Generer Model Cards automatisk som del av CI/CD pipeline.

## Kostnad og lisensiering

### Azure Machine Learning prising

**Compute Costs (primær kostnad):**
- **Training Compute** – Azure ML Compute Clusters (pay-per-use)
  - CPU: ~3-15 NOK/time (avhengig av VM size)
  - GPU: ~50-300 NOK/time (NC-series, ND-series)
- **Inference Compute** – Managed Online Endpoints
  - CPU: ~2-10 NOK/time
  - GPU: ~40-200 NOK/time
- **Batch Inference** – Samme som training compute (pay-per-job)

**Storage Costs:**
- **Azure Blob Storage** – ~0.15 NOK/GB/måned (standard tier)
- **Model Registry Storage** – Inkludert i Blob Storage

**Optimaliseringstips:**
- Bruk **auto-shutdown** på compute clusters (idle timeout)
- Bruk **low-priority VMs** for ikke-kritiske training jobs (60-80% rabatt)
- Implementer **model caching** for å unngå retraining
- Bruk **serverless compute** for mindre workloads (ny funksjon)

### DevOps-verktøy


### DevOps for Machine Learning — Azure DevOps Integration (Verified MCP 2026-04)

**Azure Pipelines + Azure ML** (how-to-devops-machine-learning):

Automate the ML lifecycle via Azure DevOps pipelines:
1. Data preparation (ETL)
2. On-demand scale-out training
3. Model deployment (public/private web service)
4. Monitoring (performance, data drift)

**Prerequisite**: Python >=3.10 required for Azure ML SDK v2 scripts. Install [Azure Machine Learning extension for Azure Pipelines](https://marketplace.visualstudio.com/items?itemName=ms-air-aiagility.azureml-v2) from VS Marketplace.

**Authentication options** (Verified MCP 2026-04):
- **Azure Resource Manager service connection** (recommended) — use with `AzureMLJobWaitTask@1` from Azure ML extension
- **Generic service connection** — use with `InvokeRESTAPI` task calling REST API directly (api-version: `2024-04-01`)

**Azure DevOps pipeline YAML pattern** (ARM service connection):
```yaml
- task: AzureCLI@2
  name: submit_azureml_job_task
  inputs:
    azureSubscription: $(service-connection)
    scriptType: bash
    inlineScript: |
      job_name=$(az ml job create --file pipeline.yml -g $(resource-group) -w $(workspace) --query name --output tsv)
      echo "##vso[task.setvariable variable=JOB_NAME;isOutput=true;]$job_name"

- job: WaitForJobCompletion
  pool: server  # Server job — no agent costs, runs on pipeline machine
  dependsOn: SubmitAzureMLJob
  steps:
  - task: AzureMLJobWaitTask@1  # From Azure ML extension (not "classic")
    inputs:
      serviceConnection: $(service-connection)
      resourceGroupName: $(resource-group)
      azureMLWorkspaceName: $(workspace)
      azureMLJobName: $(azureml_job_name_from_submit_job)
```

**Note**: `AzureMLJobWaitTask@1` runs as a server job (no agent pool costs). Max wait: 2 days (Azure DevOps hard limit). Use `AzureMLJobWaitTask@1`, not the legacy "Machine Learning (classic)" extension.

**MLOps maturity model**: Manual → Partial automation → Full CI/CD → Full MLOps with monitoring

**Key automation operations** (Azure DevOps):
- Infrastructure deployment (Terraform / Bicep)
- Component registration and versioning
- Model training on compute clusters
- Online/batch endpoint deployment
- Production monitoring alerts


| Verktøy | Kostnad | Anbefaling |
|---------|---------|-----------|
| **Azure DevOps** | Gratis for 5 brukere + 1800 min/mnd pipeline | Bruk Basic plan for mindre team |
| **GitHub Actions** | Gratis for public repos, 2000 min/mnd private | Vurder ved open source |
| **Azure Event Grid** | ~0.50 NOK per 100k events | Neglisjerbar for de fleste |
| **Azure Monitor** | ~25 NOK/GB ingested logs | Konfigurer log retention policies |

### TCO-sammenligning

**Scenario: 10 modeller i produksjon, retrening ukentlig**

| Komponent | Level 0 (Manuell) | Level 2 (Automated Training) | Level 4 (Full MLOps) |
|-----------|-------------------|------------------------------|----------------------|
| **Compute** | ~5 000 NOK/mnd | ~8 000 NOK/mnd | ~12 000 NOK/mnd |
| **Storage** | ~500 NOK/mnd | ~1 000 NOK/mnd | ~2 000 NOK/mnd |
| **Tooling** | 0 NOK | ~500 NOK/mnd | ~1 500 NOK/mnd |
| **FTE-kostnad** | 2 FTE (manuelt arbeid) | 1 FTE + 0.5 FTE | 0.5 FTE (automated) |
| **Total/år** | ~3M NOK (inkl. FTE) | ~1.5M NOK | ~800K NOK |

**ROI breakpoint:** Full MLOps lønner seg typisk ved 5+ modeller i produksjon med månedlig/ukentlig refresh.

## For arkitekten (Cosmo)

### Spørsmål å stille kunden

1. **Hvor mange modeller planlegger dere i produksjon innen 12 måneder?**
   → Indikerer om Level 0-1 holder, eller om CI/CD er nødvendig.

2. **Hvor ofte må modellene retrenes?**
   → Daglig = krev Level 3-4, månedlig = Level 2 kan holde.

3. **Har dere dedikert ML Engineering eller DevOps-kapasitet?**
   → Nei = start med Level 1-2, Ja = sikt mot Level 3-4.

4. **Hvilke compliance-krav har dere? (GDPR, ISO, Riksrevisjonen)**
   → Høye krav = krev lineage tracking, explainability fra dag 1.

5. **Hva er acceptable downtime for modell-inference?**
   → <1% = krev blue-green deployment + automated rollback (Level 4).

6. **Bruker dere allerede Azure DevOps eller GitHub?**
   → Tilpass MLOps-stack til eksisterende tooling.

7. **Har dere data scientists uten engineering-bakgrunn?**
   → Vurder Azure ML Designer (low-code pipelines) eller Databricks.

8. **Er dette discriminative models (klassisk ML) eller generative AI?**
   → GenAI = legg til prompt versioning, RAG pipelines, safety monitoring.

### Fallgruver per modenhetsnivå

**Level 0-1:**
- **Feil:** "Vi starter med manuelt, automatiserer senere"
  **Risiko:** Teknisk gjeld, umulig å migrere uten rewrites
  **Anbefaling:** Implementer minimum version control + experiment tracking fra dag 1.

**Level 2:**
- **Feil:** "Vi automatiserer trening, men deployment er QA-gated manuelt"
  **Risiko:** Bottleneck i deployment, modeller ligger udeployed i uker
  **Anbefaling:** Automatiser deployment til staging, men behold manual approval til prod.

**Level 3-4:**
- **Feil:** "Vi automatiserer alt, inkludert prod-deployment uten human-in-the-loop"
  **Risiko:** Dårlige modeller deployes automatisk, ingen rollback
  **Anbefaling:** Implementer **automated quality gates** (min accuracy threshold) + **canary deployment** (gradvis rollout).

### Anbefalinger per scenario

| Scenario | Anbefalt Level | Kritisk komponent | Verktøy |
|----------|----------------|-------------------|---------|
| **POC/Prototyping** | Level 0-1 | Experiment tracking | Azure ML Studio + Notebooks |
| **Første produksjonsmodell** | Level 2 | Model registry + monitoring | Azure ML + GitHub Actions |
| **5-10 modeller, moderat refresh** | Level 2-3 | Automated training + CI/CD | Azure ML + Azure DevOps |
| **10+ modeller, høy refresh** | Level 4 | Full automation + drift detection | Azure ML + Event Grid + Monitoring |
| **Regulert sektor (finans, helse)** | Level 3+ (compliance) | Lineage + explainability | Azure ML + Model Cards + Audit Logs |
| **Generative AI (RAG, LLM)** | Level 2+ GenAIOps | Prompt versioning + safety | Azure AI Foundry + Prompt Flow |

### Quick Decision Tree

```
Er dette en POC?
├─ Ja → Level 0-1 (manuelt, men med experiment tracking)
└─ Nei → Er det <3 modeller?
    ├─ Ja → Level 2 (automated training)
    └─ Nei → Er det høyfrekvent retrening (ukentlig+)?
        ├─ Ja → Level 3-4 (full CI/CD/CT)
        └─ Nei → Level 2-3 (automated training + manual deployment)
```

### Red Flags som krever eskalering

- Kunde vil "bygge egen MLOps-platform" → **Styr mot Azure ML, ikke reinvent the wheel**
- Ingen data governance → **Blokkerer production-readiness, fiks data management først**
- "Vi trenger ikke monitoring, modellen er ferdig trent" → **Model decay er uunngåelig, påkrev monitoring**
- Team uten ML Engineering → **Vurder Databricks (managed platform) eller bygg kapasitet**

## Kilder og verifisering

### Microsoft Learn (Verified via MCP)

1. **MLOps Maturity Model**
   https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/mlops-maturity-model
   *Confidence: Verified* – Offisiell dokumentasjon på modenhetsnivåer 0-4.

2. **MLOps Model Management with Azure ML**
   https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-management-and-deployment?view=azureml-api-2
   *Confidence: Verified* – Core MLOps capabilities, lifecycle management.

3. **MLOps and GenAIOps for AI Workloads**
   https://learn.microsoft.com/en-us/azure/well-architected/ai/mlops-genaiops
   *Confidence: Verified* – Workload operations lifecycle, automation, monitoring.

4. **Concepts - MLOps for AI/ML Workflows (AKS)**
   https://learn.microsoft.com/en-us/azure/aks/concepts-machine-learning-ops
   *Confidence: Verified* – DevOps principles applied to MLOps, inner/outer loop.

5. **Azure ML Pipelines Overview**
   https://learn.microsoft.com/en-us/azure/machine-learning/concept-ml-pipelines?view=azureml-api-2
   *Confidence: Verified* – Pipeline orchestration, reproducibility.

6. **Introduction to MLOps (Training Path)**
   https://learn.microsoft.com/en-us/training/paths/introduction-machine-learn-operations/
   *Confidence: Verified* – Learning path covering DevOps for ML, source control, automation, CD.

7. **Machine Learning Operations v2 Architecture**
   https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/machine-learning-operations-v2
   *Confidence: Verified* – MLOps v2 architectural pattern, classical ML, CV, NLP.

8. **GenAIOps for Organizations with MLOps Investments**
   https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/genaiops-for-mlops
   *Confidence: Verified* – GenAIOps maturity model vs MLOps maturity model.

### Code Samples (Verified via MCP)

- **Azure ML Pipeline Definition (Python SDK)**
  https://learn.microsoft.com/en-us/azure/machine-learning/how-to-create-component-pipeline-python?view=azureml-api-2
  *Confidence: Verified* – Python decorator pattern for pipeline orchestration.

- **Azure DevOps YAML Pipeline for Azure ML**
  https://learn.microsoft.com/en-us/azure/machine-learning/how-to-devops-machine-learning?view=azureml-api-2
  *Confidence: Verified* – CI/CD integration with Azure Pipelines.

### Konfidensnivå per seksjon

| Seksjon | Confidence | Kilde |
|---------|------------|-------|
| **Introduksjon** | Verified | Microsoft Learn MLOps concepts |
| **Kjernekomponenter** | Verified | Azure ML capabilities documentation |
| **Arkitekturmønstre** | Verified | MLOps Maturity Model (Level 0-4) |
| **Beslutningsveiledning** | Baseline | Utledet fra maturity model + best practices |
| **Integrasjon med MS-stack** | Verified | Azure ML, DevOps, GitHub docs + code samples |
| **Offentlig sektor** | Baseline | GDPR/Datatilsynet + Azure compliance docs |
| **Kostnad** | Baseline | Azure Pricing Calculator (februar 2026) |
| **For arkitekten** | Baseline | Cosmo's domain expertise + maturity model |

### Sist verifisert

Alle kilder verifisert via `microsoft-learn` MCP-server **2026-06-19**.
Azure ML dokumentasjon gjelder **API v2 (current)** med mindre annet er nevnt.