Microservices Designer

Microservices Designer

Workflow en 8 étapes

1. Cartographier le domaine (Event Storming / DDD)

• Réunir les experts métier et tech ; lister tous les domain events (faits métier passés).
• Regrouper en bounded contexts : chaque contexte a son propre modèle, son langage ubiquitaire.
• Classer : core domain (avantage concurrentiel), supporting, generic (candidat à l'externalisation/SaaS).

Exemple — e-commerce :
  Core      : Catalogue, Commande, Pricing
  Supporting: Notification, Inventaire
  Generic   : Paiement (Stripe), Auth (Keycloak)

2. Définir les services (règle de taille)

Critères de découpage — un service par bounded context SI :

• ≥ 2 équipes différentes ont besoin de déployer indépendamment
• La scalabilité requise diffère significativement (ex: Catalogue ×10 vs Commande ×2)
• Les exigences de sécurité/compliance diffèrent (PCI-DSS isolé)

Signaux de sur-découpage : appels synchrones en chaîne > 3 sauts, transactions distribuées partout, équipe < 5 devs.

3. Définir les contrats d'API

• REST : OpenAPI 3.1, versionning via URL (/v1/) ou Accept: application/vnd.api+json;version=2
• gRPC : Protobuf .proto versionné, backward-compatible (ne jamais supprimer un field)
• Events : AsyncAPI 3.0, schema registry (Confluent, AWS Glue)

# asyncapi snippet — OrderCreated
channels:
  order.created:
    publish:
      message:
        payload:
          type: object
          properties:
            orderId: { type: string, format: uuid }
            total:   { type: number }
          required: [orderId, total]

4. Choisir le pattern de communication

Règle : préférer l'asynchrone par défaut ; n'utiliser le synchrone que pour les cas UX qui exigent une réponse immédiate.

5. Données — database per service

❌ Service A ──┐
               ├── shared DB   (couplage fort, migration impossible indépendamment)
❌ Service B ──┘

✅ Service A ── DB A (Postgres)
✅ Service B ── DB B (MongoDB)
✅ Service C ── DB C (Redis)

Patterns avancés :

• CQRS : séparer Command model (write) et Query model (read-optimized, répliqué via events)
• Event Sourcing : stocker les events bruts (EventStoreDB, Kafka compacted topic) ; reconstruire l'état à la demande
• Saga : chaque step publie un event de succès ou compensation en cas d'échec

6. Résilience — checklist obligatoire

// .NET — Polly v8 (2026)
services.AddHttpClient<IOrderClient, OrderClient>()
    .AddResilienceHandler("order-pipeline", builder =>
    {
        builder.AddRetry(new HttpRetryStrategyOptions
        {
            MaxRetryAttempts = 3,
            BackoffType = DelayBackoffType.Exponential
        });
        builder.AddCircuitBreaker(new HttpCircuitBreakerStrategyOptions
        {
            SamplingDuration = TimeSpan.FromSeconds(30),
            FailureRatio = 0.5
        });
        builder.AddTimeout(TimeSpan.FromSeconds(5));
    });

• Bulkhead : thread pool séparé par dépendance critique
• Fallback : retourner une réponse dégradée plutôt qu'une erreur 500
• Idempotency key : toujours sur les endpoints mutatifs (Idempotency-Key: <uuid>)

7. Observabilité — stack minimale 2026

Traces  → OpenTelemetry SDK → Jaeger / Tempo
Métriques → Prometheus → Grafana
Logs    → structured JSON → Loki / ELK
Alertes → Alertmanager / PagerDuty

# Python — OTel auto-instrumentation FastAPI
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
FastAPIInstrumentor.instrument_app(app, tracer_provider=tracer_provider)

Règles :

• Correlation ID propagé dans tous les headers (traceparent W3C standard)
• Health checks : /healthz/live (process up) + /healthz/ready (dépendances OK)
• SLO défini par service : ex. p99 < 200 ms, error rate < 0.1 %

8. Migration d'un monolithe — Strangler Fig

Phase 1 : Façade devant le monolithe (reverse proxy / API Gateway)
Phase 2 : Extraire Service X derrière la façade, redirections progressives
Phase 3 : Supprimer le code correspondant du monolithe
Phase 4 : Répéter par service, jamais de big bang

Outils : Kong / YARP en façade, feature flags pour basculer le trafic, canary deployment (1 % → 10 % → 100 %).

Anti-patterns & pièges

Critères de décision — monolithe vs microservices

Microservices recommandés si ≥ 3 critères :
  ☐ Équipes > 2 squads avec ownership distinct
  ☐ Exigences de scalabilité très différentes par domaine
  ☐ Besoin de déploiements indépendants fréquents (> 2×/semaine par domaine)
  ☐ Technologies différentes justifiées par domaine
  ☐ Compliance / isolation sécurité obligatoire par périmètre

Sinon : Modulith d'abord (modules bien isolés dans un monolithe),
        migration service par service quand un critère se déclenche.

Bonnes pratiques 2026

• Service mesh (Istio, Linkerd, Dapr) : mTLS automatique, observabilité L7, traffic management sans code applicatif.
• GitOps : un repo par service, ArgoCD/Flux pour les déploiements Kubernetes.
• Contract testing avec Pact en CI : valider que producer et consumer restent compatibles avant merge.
• Platform engineering : fournir un Internal Developer Portal (Backstage) avec templates de service pré-configurés (OTel, health, Dockerfile, CI).
• Chaque ADR dans docs/adr/NNNN-titre.md (format Nygard) ; lier depuis le README du service.