Cours 24 : Tendances DevOps Émergentes

1. eBPF (Extended Berkeley Packet Filter)

Qu'est-ce que eBPF ?

eBPF est une technologie du noyau Linux qui permet d'exécuter des programmes sandboxés sans modifier le noyau ou charger des modules. C'est un "JavaScript du noyau" — programmez le comportement du kernel de manière sûre et efficace.

Comment ça marche ?

1. Le programme eBPF est écrit en C/Rust
2. Compilé en bytecode (clang/LLVM)
3. Vérifié par le verifier eBPF (sécurité)
4. Compilé JIT en instructions machine
5. Attaché à un hook kernel (syscall, réseau, fichier)

Cas d'usage majeurs

Cilium — Container Networking Interface

Cilium utilise eBPF pour remplacer kube-proxy et fournir :

• Network policies : Performantes (pas d'iptables)
• Service load balancing : Maglev + DSR (Direct Server Return)
• Observabilité : Hubble (service map, flows)
• Cluster Mesh : Multi-cluster networking
• Transparent encryption : WireGuard

Pourquoi Cilium remplace kube-proxy ?

# kube-proxy (iptables) : O(n) règles, latence
# Cilium (eBPF) : O(1), 10x plus rapide
# Avantages :
# - 3-5x moins de CPU
# - 10x moins de latence
# - Scalabilité : supporte 10x+ plus de Services

Falco — Runtime Security

Falco utilise eBPF pour détecter les anomalies au niveau système :

• Syscall monitoring : Détection des comportements anormaux
• Container drift : Nouveaux binaires dans un conteneur
• Privilege escalation : Tentatives d'élévation de privilèges
• Network anomalies : Connexions suspectes

Règles Falco typiques :

- rule: Shell in container
  desc: Detect shell spawned in container
  condition: container and proc.name in (bash, sh, zsh)
  output: "Shell spawned in container (user=%user.name)"
  priority: WARNING

Hubble — Network Observability

• Service map automatique
• Flow logs (L3/L4/L7)
• Métriques de réseau
• Intégration Prometheus

Autres projets eBPF

• Pixie : Debugging Kubernetes (New Relic)
• Tetragon : Security observability (Isovalent)
• Katran : Load balancing (Facebook)
• bpftrace : Tracing dynamique (one-liners)

Comparaison : iptables vs eBPF

Exemple : Programme eBPF pour tracer les syscalls

#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

SEC("tracepoint/syscalls/sys_enter_execve")
int trace_execve(struct trace_event_raw_sys_enter *ctx) {
    char comm[16];
    bpf_get_current_comm(&comm, sizeof(comm));
    bpf_printk("execve called by %s\n", comm);
    return 0;
}

Adoption en production

• Cilium : Dans les 3 plus gros clusters K8s connus (> 50k nœuds)
• Falco : Utilisé par Sysdig, Red Hat
• eBPF : Considéré comme la "next-generation Linux kernel technology" (LWN)

Roadmap

• 2020-2022 : Adoption massive de Cilium
• 2023 : Cilium remplace kube-proxy par défaut
• 2024-2025 : eBPF devient standard dans tous les clouds managés
• 2025+ : eBPF dans Windows ?

---

2. WebAssembly (WASI, WasmEdge)

Qu'est-ce que WebAssembly (Wasm) ?

Wasm est un format d'instruction binaire initialement conçu pour les navigateurs, qui s'étend maintenant aux serveurs (WASI) et à l'edge computing.

WASI (WebAssembly System Interface)

Interface standard qui permet à Wasm d'accéder aux ressources système :

• Filesystem
• Networking
• Clock
• Random

Pourquoi Wasm pour DevOps ?

Avantages vs conteneurs :

WasmEdge

Runtime Wasm pour edge/cloud :

• Performance : Démarrage microsecondes
• Orchestration : Kubernetes via containerd runtime
• Plugins : Extensible via WASI
• AIOps : Fonctions serverless Wasm

Kubernetes + Wasm

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wasm-app
spec:
  replicas: 3
  template:
    spec:
      runtimeClassName: wasmtime
      containers:
      - name: app
        image: myregistry/app:wasm

Cas d'usage

1. Edge Computing : Fonctions légères sur devices IoT
2. Plugin systems : Extensions sandboxées (Envoy, Istio)
3. Serverless : Cold start < 1ms
4. Platform Engineering : Templates IDP légers

Limitations actuelles

• Pénétration modérée en production
• Limitations WASI v1 (pas de threads, async)
• Écosystème moins mature que containerd/runC

---

3. Edge Computing

Définition

Edge computing déplace le calcul et le stockage au plus près des utilisateurs/data sources, réduisant la latence et la bande passante.

Architecture Edge

[Cloud] ←WAN→ [Edge Node] ←Local→ [Device/IoT]
   ↑              ↑
   |              |
[K8s Central]  [K3s / MicroK8s]

Technologies Edge pour DevOps

K3s (Rancher)

Kubernetes léger pour l'edge :

• Taille : Binaire 40MB (+ 80MB image)
• Dépendances : SQLite (pas etcd)
• Consommation : 512MB RAM, 1 vCPU
• Cas : IoT, edge, dev/test locaux

MicroK8s (Canonical)

• Taille : Snap package
• Fonctionnalités : Addons (Istio, Knative, etc.)
• HA : Multi-node supporté
• Cas : Edge à haute disponibilité

Akri (Microsoft)

• Découverte : Détection automatique des devices edge
• Protocols : OPC UA, ONVIF, udev
• Intégration : Pods éphémères par device

GitOps pour l'Edge

GitOps est crucial pour l'edge car :

1. Pas de connexion directe à chaque nœud
2. Git comme vérité unique
3. Sync automatisée (pull-based)
4. Rollback en cas d'échec

Patterns Edge

# Edge workload avec local processing
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: edge-processor
spec:
  template:
    spec:
      tolerations:
      - key: "edge"
        operator: "Exists"
      containers:
      - name: processor
        image: edge-processor:latest
        env:
        - name: DATA_LAKE_URL
          value: "http://central-lake:8080"

Challenges

• Connectivité : Réseaux intermittents
• Sécurité : Nœuds hors du datacenter
• Mise à jour : Orchestration des mises à jour
• Monitoring : Observabilité distribuée

---

4. AIOps (AI for IT Operations)

Définition

AIOps utilise le Machine Learning pour automatiser et améliorer les opérations IT, particulièrement le monitoring, l'alerte et l'incident response.

Composants d'une stack AIOps

1. Anomaly Detection

# Détection par Z-score sur métriques Prometheus
import numpy as np
from prometheus_api_client import PrometheusConnect

prom = PrometheusConnect()
data = prom.get_metric_range_data('node_cpu_percent')

values = [float(v[1]) for v in data[0]['values']]
mean, std = np.mean(values), np.std(values)
anomalies = [v for v in values if abs(v - mean) / std > 3]

2. Root Cause Analysis (RCA)

• Correlation : Cause probable d'un incident
• Graph analysis : Dépendances entre services
• Natural Language : Analyse des logs et runbooks

3. Predictive Analytics

• Capacity planning : Prédiction des besoins
• Failure prediction : Anticipation des pannes
• Cost prediction : Prévision des coûts cloud

Outils AIOps

Alert Fatigue Reduction

Avant AIOps : 1000 alertes/jour → équipe noyée Après AIOps : 20 incidents intelligents/jour

Techniques :

1. Deduplication : Une alerte = un incident
2. Correlation : Regrouper les alertes liées
3. Suppression : Maintenance / known issues
4. Intelligent Routing : Alerter la bonne équipe

Intégration avec SRE

# SLO-based alerting avec ML
slo: 99.9%
error_budget: 43m/month
# Avec ML :
# - Prédiction d'épuisement du budget (burn rate)
# - Détection des anomalies avant qu'elles ne dépassent le SLO
# - Réduction des faux positifs

---

5. GitOps 2.0

Évolution de GitOps

GitOps 1.0 (2017-2022) :

• ArgoCD / Flux
• Sync manuel ou automatisé
• Un seul cluster
• K8s-centric

GitOps 2.0 (2023+) :

• Multi-cluster / multi-cloud
• Progressive delivery
• Observabilité intégrée
• Platform Engineering
• Security (SLSA + Sigstore)

Nouvelles fonctionnalités

Progressive Delivery

apiVersion: argoproj.io/v1alpha1
kind: AnalysisRun
metadata:
  name: canary-analysis
spec:
  metrics:
  - name: success-rate
    interval: 30s
    count: 10
    failureLimit: 2
    provider:
      prometheus:
        query: |
          sum(rate(http_requests_total{status=~"5.."}[5m])) /
          sum(rate(http_requests_total[5m]))

Multi-cluster Management

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: guestbook
spec:
  generators:
  - clusters:
      selector:
        matchLabels:
          env: production
  template:
    spec:
      source:
        repoURL: https://github.com/myorg/gitops-config
        targetRevision: HEAD

GitOps + Security

• Signing : Cosign + Sigstore
• Attestations : SLSA Level 3
• Policy as Code : OPA/Gatekeeper
• SBOM : Syft + Grype

Outils GitOps 2.0

---

6. Platform Engineering & IDP

Pourquoi Platform Engineering ?

Problème : La complexité croissante du cloud-native submerge les développeurs. Solution : Une Internal Developer Platform (IDP) qui abstrait la complexité.

Stack d'une IDP moderne

┌─────────────────────────────────────┐
│     Developer Self-Service Portal    │ ← Backstage / Port / Humanitec
├─────────────────────────────────────┤
│         Software Templates           │ ← Scaffolder (Backstage)
├─────────────────────────────────────┤
│         Orchestration Layer          │ ← Crossplane / Terraform / Kubernetes
├─────────────────────────────────────┤
│     CI/CD │ Observability │ Security  │
├─────────────────────────────────────┤
│       Infrastructure (Cloud/K8s)     │
└─────────────────────────────────────┘

Backstage — Le leader open-source

Composants clés :

1. Software Catalog : Inventaire de tous les services
2. TechDocs : Documentation générée automatiquement
3. Scaffolder : Templates pour créer des services
4. Plugins : ArgoCD, Datadog, PagerDuty, etc.

Template Backstage

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: node-service
  title: Node.js Service
  description: Create a new Node.js microservice
spec:
  parameters:
  - title: Service Name
    properties:
      name:
        title: Name
        type: string
      owner:
        title: Owner
        type: string
  steps:
  - id: template
    name: Generate
    action: fetch:template
    input:
      url: ./templates/node-service
      values:
        name: ${{ parameters.name }}
  - id: publish
    name: Publish
    action: publish:github
    input:
      repoUrl: github.com/myorg/${{ parameters.name }}

Crossplane — Control Plane Cloud-Native

Crossplane permet de gérer l'infrastructure cloud via CRDs Kubernetes :

apiVersion: aws.upbound.io/v1beta1
kind: XRDS
metadata:
  name: xpostgresqlinstances.devops.example.org
spec:
  group: devops.example.org
  names:
    kind: XPostgreSQLInstance
  claimNames:
    kind: PostgreSQLInstance
  versions:
  - name: v1alpha1
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              storageGB:
                type: integer
              engineVersion:
                type: string

IDP Maturity Model

---

7. FinOps

Définition

FinOps = Finance + DevOps. Pratique qui optimise les coûts cloud en alignant la finance, l'ingénierie et les opérations.

Cycle FinOps

┌─────────┐     ┌──────────┐     ┌──────────┐
│ Inform  │────▶│ Optimize │────▶│ Operate  │
│ (Visibilité) │ (Efficacité) │ (Continuité) │
└─────────┘     └──────────┘     └──────────┘
     ▲                                    │
     └────────────────────────────────────┘

Pratiques FinOps

1. Visibility & Allocation

# Tagging strategy Terraform
resource "aws_instance" "app" {
  tags = {
    CostCenter = "team-alpha"
    Environment = "production"
    Project     = "customer-portal"
    Owner       = "devops-team"
    AutoShutdown = "false"
  }
}

2. Optimization

# Identifier les ressources inutilisées
aws resourcegroupstaggingapi get-resources
# Recommandations Rightsizing
aws ce get-rightsizing-recommendation --service EC2
# Spot instances
aws ec2 describe-spot-price-history

3. Budget & Alerts

# Créer un budget AWS
aws budgets create-budget \
  --account-id 123456789 \
  --budget '{"BudgetName":"monthly-dev", "BudgetType":"COST", "BudgetLimit":{"Amount":"5000", "Unit":"USD"}, "TimeUnit":"MONTHLY"}' \
  --notifications-with-subscribers '[
    {"Notification":{"NotificationType":"ACTUAL","ComparisonOperator":"GREATER_THAN","Threshold":80},
     "Subscribers":[{"SubscriptionType":"EMAIL","Address":"team@company.com"}]}
  ]'

Métriques FinOps

Kubernetes Cost Optimization

# VPA pour ajuster les requests/limits
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: myapp-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  updatePolicy:
    updateMode: Auto  # Applique auto les recommandations

Outils FinOps

• Cloud : AWS Cost Explorer, Azure Cost Management, GCP Cost Tools
• K8s : Kubecost, KubeCost, OpenCost
• Multi-cloud : CloudHealth, Cloudability, Apptio
• Open Source : OpenCost, Infracost

---

8. Green DevOps (GreenOps)

Pourquoi Green DevOps ?

Le numérique représente 4% des émissions mondiales de CO2 (plus que l'aviation). L'IT peut et doit réduire son impact environnemental.

Principes du Green DevOps

1. Green Infrastructure

• Choisir des régions cloud à énergie bas-carbone
• Utiliser des instances ARM (Graviton) plus efficientes
• Dimensionner au plus juste (rightsizing)
• Éteindre les ressources non utilisées (auto-shutdown)

2. Green Kubernetes

# Bin packing : maximiser l'utilisation des nœuds
# Utiliser des instances ARM (Graviton/AWS)
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: carbon-aware-scheduler
spec:
  template:
    spec:
      containers:
      - name: scheduler
        env:
        - name: CARBON_INTENSITY_API
          value: "https://api.carbonintensity.org.uk"

3. Green CI/CD

• Optimiser les pipelines (parallélisme, cache)
• Éviter les builds inutiles (skip CI si docs only)
• Utiliser des runners efficients (ARM)
• Nettoyer les artefacts obsolètes

4. Metrics Vertes

# Prometheus metrics pour le GreenOps
- name: "carbon_intensity"
  help: "Carbon intensity of electricity (gCO2eq/kWh)"
  type: gauge
- name: "energy_consumption"
  help: "Energy consumed by service (kWh)"
  type: counter
- name: "pod_efficiency"
  help: "Pod CPU utilization / request ratio"
  type: gauge

Stratégies pratiques

Auto-shutdown pour environnements non-prod

#!/bin/bash
# Cron : Arrêt des clusters dev à 19h
aws eks update-kubeconfig --name dev-cluster
kubectl scale deployment --all --replicas=0
aws ec2 stop-instances --instance-ids $DEV_INSTANCES

Choix des régions vertes

# AWS : Irlande (faible carbone)
provider "aws" {
  region = "eu-west-1"  # Faible intensité carbone
}

# GCP : utiliser des régions à energy propre
# us-west1 (The Dalles, hydro)
# europe-west4 (Pays-Bas, éolien)

Outils Green DevOps

Green DevOps Maturity Model

1. Level 1 : Mesure (SCARF, Kepler)
2. Level 2 : Optimisation (rightsizing, auto-shutdown)
3. Level 3 : Green scheduling (quand l'énergie est propre)
4. Level 4 : Architecture efficiente (ARM, serverless)
5. Level 5 : Contribution (open source, compensation)

Calcul d'impact simplifié

def estimate_carbon(instance_type, hours, region):
    # gCO2eq per kWh par région
    carbon_intensity = {
        'eu-west-1': 250,    # Irlande
        'eu-central-1': 400, # Allemagne
        'us-east-1': 350,    # Virginie
    }
    # Watts par type d'instance (exemple)
    watts = {
        't3.medium': 50,
        't3.large': 85,
        'm5.xlarge': 170,
    }
    energy_kwh = watts[instance_type] * hours / 1000
    carbon_g = energy_kwh * carbon_intensity[region]
    return carbon_g / 1000  # kgCO2eq

---

Conclusion : Les tendances qui comptent

Impact immédiat (2024-2025)

1. Platform Engineering : Route vers l'IDP
2. FinOps : Optimisation des coûts
3. AIOps : Réduction du bruit d'alertes
4. Cilium/eBPF : Standard réseau K8s

À moyen terme (2025-2027)

1. Wasm : Alternative légère aux conteneurs
2. Edge Computing : K3s et GitOps pour l'edge
3. Green DevOps : Obligation réglementaire
4. GitOps 2.0 : Multi-cluster + progressive delivery

À long terme (2027+)

1. Autonomous Ops : IA gère les opérations courantes
2. WebAssembly généralisé : Serverless everywhere
3. Carbon-aware computing : Choix automatique des régions vertes
4. Self-healing prédictif : Réparation avant la panne

Compétences à développer