Monolith oder Microservices: Wann sich die Zerlegung wirklich lohnt

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

# Welche Verzeichnisse aendern sich immer gemeinsam?
# Ausgabe: pro Commit die beteiligten Modulordner, danach Paare zaehlen
git log --since='12 months ago' --pretty=format:'---%h' --name-only \
  | awk '/^---/{print ""; next} {split($0,a,"/"); if (a[1]=="modules") printf "%s ", a[2]}' \
  | 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() {
        // Schlaegt 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 Abhaengigkeiten bauen
./mvnw -pl modules/billing -am test

# Laufzeit-Abhaengigkeiten pruefen: wer haengt an wem?
./mvnw dependency:tree -Dincludes=de.example.shop

# Gradle-Aequivalent
./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 erhoehen
kubectl annotate ingress shop-billing-canary \
  nginx.ingress.kubernetes.io/canary-weight=20 --overwrite

# Rueckweg: 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 Erhoehung pruefen
kubectl logs -l app=billing-service --since=1h --tail=-1 \
  | grep -c ' 5[0-9][0-9] '

# Java: Agent anhaengen, keine Codeaenderung noetig
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=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