Monolith oder Microservices: wann sich die Zerlegung lohnt

# Welche Dateien ändern sich am häufigsten?
git log --since='12 months ago' --name-only --pretty=format: \
  | grep -E '\.(java|go|ts)$' \
  | sort | uniq -c | sort -rn | head -20

# Welche Verzeichnisse ändern sich immer gemeinsam?
# Ausgabe: je Commit die beteiligten Modulordner (jeder nur einmal),
# danach gleiche Kombinationen zählen
git log --since='12 months ago' --pretty=format:'---' --name-only \
  | awk -F/ '/^---/{if (line != "") print line; line=""; split("", seen); next}
             $1=="modules" && !seen[$2]++ {line = line " " $2}
             END{if (line != "") print line}' \
  | awk 'NF > 1' | sort | uniq -c | sort -rn | head -20

import org.springframework.modulith.core.ApplicationModules;
import org.junit.jupiter.api.Test;

class ModulTest {

    static final ApplicationModules MODULE = ApplicationModules.of(ShopApplication.class);

    @Test
    void modulgrenzenSindEingehalten() {
        // Schlägt fehl, sobald ein Modul auf interne Klassen eines anderen zugreift
        MODULE.verify();
    }

    @Test
    void dokumentationErzeugen() {
        new org.springframework.modulith.docs.Documenter(MODULE)
            .writeModulesAsPlantUml()
            .writeIndividualModulesAsPlantUml();
    }
}

# Nur ein Modul samt seiner Abhängigkeiten bauen
./mvnw -pl modules/billing -am test

# Laufzeit-Abhängigkeiten prüfen: wer hängt an wem?
./mvnw dependency:tree -Dincludes=de.example.shop

# Gradle-Äquivalent
./gradlew :modules:billing:test

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-billing-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "5"
spec:
  ingressClassName: nginx
  rules:
    - host: shop.example.de
      http:
        paths:
          - path: /api/billing
            pathType: Prefix
            backend:
              service:
                name: billing-service
                port:
                  number: 8080

# Anteil erhöhen
kubectl annotate ingress shop-billing-canary \
  nginx.ingress.kubernetes.io/canary-weight=20 --overwrite

# Rückweg: gesamter Verkehr wieder auf den Monolithen
kubectl annotate ingress shop-billing-canary \
  nginx.ingress.kubernetes.io/canary-weight=0 --overwrite

# Fehlerrate des neuen Dienstes vor jeder Erhöhung prüfen
kubectl logs -l app=billing-service --since=1h --tail=-1 \
  | grep -c ' 5[0-9][0-9] '

# Java: Agent anhängen, keine Codeänderung nötig
export OTEL_SERVICE_NAME=billing-service
export OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector.observability:4317
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_TRACES_SAMPLER=parentbased_traceidratio
export OTEL_TRACES_SAMPLER_ARG=0.1
export OTEL_RESOURCE_ATTRIBUTES=deployment.environment.name=prod,service.version=2.4.1

java -javaagent:/opt/otel/opentelemetry-javaagent.jar -jar billing.jar

# Go: Endpunkt und Dienstname werden vom SDK aus denselben Variablen gelesen
OTEL_SERVICE_NAME=catalog-service \
OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector.observability:4317 \
  ./catalog-service