Home› Informatik› Themen & Methodik› Cloud & DevOps

Cloud & DevOps in der Bachelorarbeit & Masterarbeit

Docker, Kubernetes, CI/CD-Pipelines und Infrastructure as Code: So evaluieren und dokumentieren Sie Cloud-native Architekturen und DevOps-Praktiken in Ihrer Informatik-Thesis – mit konkreten Metriken, Deployment-Strategien und Evaluationsansaetzen.

Docker & Kubernetes
CI/CD-Pipelines
Infrastructure as Code
Serverless
Observability

Inhalt

Cloud & DevOps in der Thesis – Das Wichtigste

Cloud- und DevOps-Themen sind in Informatik-Theses extrem beliebt – aber die wissenschaftliche Tiefe fehlt oft. „Ich habe eine CI/CD-Pipeline gebaut" ist kein wissenschaftlicher Beitrag. Der Beitrag liegt in der Evaluation: Wie verkuerzt die Pipeline die Lead Time? Wie verbessert Kubernetes die Skalierung gegenueber manueller Konfiguration? Wie reduziert IaC die Configuration Drift? In der Thesis: Definieren Sie Metriken (DORA-Metriken, Deployment Frequency, Mean Time to Recovery), fuehren Sie Experimente durch (Lasttest, Chaos Engineering, Rollback-Szenarien) und vergleichen Sie gegen eine Baseline. Unsere Informatik-Ghostwriter unterstuetzen bei Entwurf und Evaluation.

1. Containerisierung: Docker & Kubernetes

Docker: Container-Grundlagen

Docker verpackt Anwendungen mit allen Abhaengigkeiten in isolierte Container – portabel, reproduzierbar, leichtgewichtig. In der Thesis dokumentieren: Dockerfile (Multi-Stage Build fuer kleinere Images), Docker Compose (Multi-Container-Setup), Image-Groesse, Sicherheit (Non-Root-User, Vulnerability Scanning mit Trivy).

Thesis-Evaluation: Image-Groesse vor/nach Optimierung. Start-up-Zeit Container vs. VM. Portabilitaet: Deployment auf verschiedenen Umgebungen ohne Anpassung.

Kubernetes: Orchestrierung

Kubernetes orchestriert Container im Cluster: Pods, Services, Deployments, Ingress, ConfigMaps, Secrets, HPA (Horizontal Pod Autoscaler). In der Thesis: Cluster-Architektur dokumentieren (Nodes, Namespaces), YAML-Manifeste als Anhang, Helm Charts fuer Paketierung.

Thesis-Evaluation: Auto-Scaling unter Last (HPA-Verhalten bei steigender RPS). Self-Healing: Pod-Restart nach Crash. Rolling Updates vs. Blue-Green Deployment.

Docker ≠ Kubernetes: Scope begrenzen

Fuer die Bachelorarbeit reicht Docker (+ Docker Compose) voellig aus – Kubernetes ist ein eigenes Oekosystem mit enormer Komplexitaet. Fuer die Masterarbeit ist Kubernetes angemessen, wenn Skalierung oder Orchestrierung Teil der Fragestellung ist. Begruenden Sie im Methodenteil, warum Sie K8s brauchen (oder nicht).

2. CI/CD-Pipelines: Vom Commit zum Deployment

ToolHostingStaerkeThesis-Einsatz
GitHub ActionsSaaS (GitHub)Nahtlose GitHub-Integration, grosser Marketplace, YAML-basiertStandard fuer Open-Source-Projekte und Uni-Repos
GitLab CI/CDSaaS oder Self-HostedAll-in-One (Repo + CI + Registry + Monitoring), Auto DevOpsWenn Uni GitLab bereitstellt
JenkinsSelf-HostedExtrem flexibel (Plugins), IndustriestandardWenn Enterprise-Kontext oder Legacy-Integration
ArgoCDSelf-Hosted (K8s)GitOps: Deklarative K8s-Deployments aus GitKubernetes-zentrierte Thesis

CI/CD-Pipeline in der Thesis dokumentieren

  • Pipeline-Stages: Build → Lint → Unit Test → Integration Test → SAST → Build Image → Deploy to Staging → E2E Test → Deploy to Prod
  • Trigger: Push, Pull Request, Tag, Schedule (Cron)
  • Artefakte: Docker Images, Test-Reports, Coverage-Reports
  • Secrets Management: Wie werden Credentials gespeichert? (GitHub Secrets, Vault, Sealed Secrets)
  • Pipeline-as-Code: YAML-Datei im Repository – versioniert, reviewbar, reproduzierbar

DORA-Metriken: CI/CD wissenschaftlich evaluieren

Die DORA-Metriken (DevOps Research and Assessment, Google) sind der Standard zur Evaluation von DevOps-Praktiken: (1) Deployment Frequency: Wie oft wird deployed? (2) Lead Time for Changes: Zeit vom Commit bis zum Deployment. (3) Mean Time to Recovery (MTTR): Zeit zur Wiederherstellung nach einem Ausfall. (4) Change Failure Rate: Anteil der Deployments, die einen Rollback erfordern. In der Thesis: Messen Sie mindestens 2 DORA-Metriken vor und nach der Pipeline-Einfuehrung. Das ist wissenschaftlich fundiert (Forsgren et al., „Accelerate", 2018) und gibt Gutachtern eine solide Evaluationsgrundlage.

3. Infrastructure as Code (Terraform, Ansible)

Terraform (Provisioning)

Deklarativ: Was soll existieren? Terraform erstellt und verwaltet Cloud-Ressourcen (VMs, Netzwerke, Datenbanken, K8s-Cluster) ueber Provider-APIs. State-Management, Plan/Apply-Workflow, Module fuer Wiederverwendbarkeit.

Thesis: IaC-Code im Repository, State-Handling dokumentieren (Remote State mit S3 + DynamoDB Lock), Drift Detection evaluieren.

Ansible (Configuration Management)

Imperativ/Deklarativ: Wie soll der Zustand hergestellt werden? Ansible konfiguriert Server (Packages, Configs, Services) ueber SSH – agentless. Playbooks in YAML, Idempotenz als Kernprinzip.

Thesis: Playbooks dokumentieren, Idempotenz-Tests zeigen, Vergleich manuelle Konfiguration vs. Ansible (Zeit, Fehlerrate, Drift).

4. Cloud-Dienste: AWS vs. Azure vs. GCP

Dienst-KategorieAWSAzureGCP
ComputeEC2, Lambda, ECS, EKSVMs, Functions, AKSCompute Engine, Cloud Functions, GKE
DatenbankRDS, DynamoDB, AuroraSQL Database, Cosmos DBCloud SQL, Firestore, Spanner
StorageS3, EBS, EFSBlob Storage, DiskCloud Storage, Persistent Disk
ContainerECR, ECS, EKSACR, ACI, AKSArtifact Registry, Cloud Run, GKE
CI/CDCodePipeline, CodeBuildAzure DevOps, PipelinesCloud Build, Cloud Deploy
Uni-CreditsAWS Educate / AcademyAzure for Students ($100)GCP for Education ($300)

Vendor Lock-in in der Thesis diskutieren

Wenn Sie Cloud-Dienste verwenden, gehoert Vendor Lock-in in die Diskussion: Wie abhaengig ist Ihr System vom gewaehlten Cloud-Anbieter? Welche Dienste sind proprietaer (DynamoDB, Cosmos DB), welche portabel (PostgreSQL auf RDS, K8s auf jedem Cloud-Provider)? Strategien: Abstraktion durch IaC (Terraform unterstuetzt alle Provider), container-basierte Deployments, Vermeidung proprietaerer APIs. Das zeigt Architekturkompetenz.

5. Serverless & FaaS in der Thesis

Vorteile fuer die Thesis

  • Kein Servermanagement: Fokus auf Code, nicht auf Infrastruktur
  • Auto-Scaling: Von 0 auf N automatisch – ideal fuer sporadische Workloads
  • Pay-per-Use: Kosten nur bei Ausfuehrung – im Free Tier oft kostenlos fuer die Thesis
  • Schnelles Prototyping: API in Minuten statt Stunden deployen

Herausforderungen & Evaluation

  • Cold Starts: Erste Ausfuehrung nach Inaktivitaet dauert laenger – messen und dokumentieren
  • Vendor Lock-in: Lambda, Azure Functions, Cloud Functions haben unterschiedliche APIs
  • Zustandslosigkeit: Kein lokaler State – externer Speicher noetig (S3, DynamoDB)
  • Debugging: Verteiltes System, schwieriger zu testen als Monolith

Evaluation: Cold-Start-Latenz messen (verschiedene Runtimes, Memory-Konfigurationen). Kosten vs. Always-On-Infrastruktur vergleichen. Skalierungsverhalten unter Last.

6. Observability: Monitoring, Logging, Tracing

Metrics (Prometheus + Grafana)

Zeitreihen-basiertes Monitoring: CPU, Memory, Request Rate, Error Rate, Latenz-Percentile (p50, p95, p99). In der Thesis: Grafana-Dashboards als Abbildungen, Alerting-Regeln dokumentieren, Metriken vor/nach Optimierung vergleichen.

Logging (ELK / Loki)

Zentralisierte Log-Aggregation: Elasticsearch + Logstash + Kibana (ELK) oder Grafana Loki. Structured Logging (JSON), Log Levels (ERROR, WARN, INFO, DEBUG). In der Thesis: Log-Analyse fuer Fehlerdiagnose, Korrelation mit Metriken.

Tracing (Jaeger / OpenTelemetry)

Distributed Tracing: Anfragen durch Microservices verfolgen. OpenTelemetry als Standard, Jaeger oder Zipkin als Backend. In der Thesis: Trace-Visualisierungen zeigen Engpaesse und Latenzen pro Service.

7. Haeufige Fehler bei Cloud & DevOps in der Thesis

Pipeline gebaut, aber nicht evaluiert

Die CI/CD-Pipeline wird beschrieben, aber es fehlen Metriken. Wie schnell ist der Build? Wie oft scheitert er? Wie schnell ist ein Rollback? Ohne DORA-Metriken oder aehnliche Evaluierung ist die Arbeit ein Tutorial, keine Thesis.

Kubernetes ohne Begruendung

K8s wird verwendet, obwohl ein einfacher Docker-Compose-Stack genuegen wuerde. Kubernetes ist fuer Skalierung und Orchestrierung – nicht fuer einen Einzelserver mit 3 Containern. Begruenden Sie die Wahl.

Keine Sicherheitsbetrachtung

Docker-Images mit Root-User, Secrets im Klartext im Code, keine Netzwerksegmentierung. DevSecOps gehoert in jede Cloud-Thesis – mindestens: Container Scanning, Secrets Management, RBAC. Mehr im IT-Sicherheit-Guide.

Vendor Lock-in nicht diskutiert

Proprietaere AWS-Dienste werden verwendet, ohne die Abhaengigkeit zu reflektieren. In der Diskussion: Portabilitaet bewerten, Alternativen benennen, Lock-in-Risiko einschaetzen.

Haeufig gestellte Fragen zu Cloud & DevOps in der Thesis

Brauche ich einen Cloud-Account fuer die Thesis?

Nicht zwingend. Optionen: (1) Lokal: Docker + Minikube/kind fuer K8s lokal – kostenlos, kein Cloud-Account noetig. (2) Uni-Credits: AWS Educate, Azure for Students ($100), GCP for Education ($300) – kostenlos fuer Studierende. (3) Free Tier: Alle drei Anbieter haben dauerhaft kostenlose Kontingente (AWS Free Tier, GCP Always Free). Fuer die BA: Lokal reicht meistens. Fuer die MA mit Skalierungsexperimenten: Cloud-Credits nutzen.

Docker Compose oder Kubernetes?

Docker Compose fuer: Entwicklungsumgebungen, einfache Multi-Container-Setups, BA-Prototypen, alles was auf einem einzelnen Host laeuft. Kubernetes fuer: Produktionsnahe Deployments, Auto-Scaling, Self-Healing, Rolling Updates, Multi-Node-Cluster. Faustregel: Wenn Ihr System auf einem Server laeuft und nicht horizontal skalieren muss → Docker Compose. Wenn Skalierung, Hochverfuegbarkeit oder Orchestrierung Teil der Fragestellung sind → Kubernetes.

Wie evaluiere ich eine Cloud-Migration?

Drei Dimensionen: (1) Performance: Latenz, Durchsatz, Startup-Zeit vor und nach Migration. Lasttest mit k6 oder JMeter. (2) Kosten: TCO (Total Cost of Ownership) On-Premise vs. Cloud. AWS Pricing Calculator, Azure TCO Calculator. (3) Betriebsaufwand: DORA-Metriken (Deployment Frequency, MTTR), Anzahl manueller Eingriffe, Incident-Rate. In der Thesis: Vorher-Nachher-Vergleich mit definierten Metriken. Mindestens eine quantitative und eine qualitative Dimension evaluieren.

Welche Literatur brauche ich?

DevOps: Forsgren/Humble/Kim „Accelerate" (2018) – die wissenschaftliche Grundlage fuer DORA-Metriken. Kim et al. „The DevOps Handbook" (2nd ed., 2021). Container: Burns et al. „Kubernetes: Up & Running" (3rd ed., 2022). Cloud: Kratzke „Cloud-native Computing" (2023) – deutschsprachig, wissenschaftlich. IaC: Brikman „Terraform: Up & Running" (3rd ed., 2022). Architektur: Newman „Building Microservices" (2nd ed., 2021) – fuer Microservices + DevOps. Richardson „Microservices Patterns" (2018) – fuer Pattern-basierte Architekturentscheidungen.

Was ist GitOps und sollte ich es verwenden?

GitOps macht Git zum Single Source of Truth fuer Infrastruktur und Deployments: Der gewuenschte Zustand (Kubernetes-Manifeste, Terraform-Code) liegt in Git. Ein Operator (ArgoCD, Flux) synchronisiert den Cluster automatisch mit dem Git-Repository. Aenderungen nur ueber Pull Requests – kein manuelles kubectl apply. Fuer die Thesis: GitOps ist ein starkes Thema fuer Masterarbeiten – Sie koennen die Vorteile (Auditierbarkeit, Rollback durch git revert, Drift Detection) quantitativ evaluieren. Fuer die BA ist klassisches CI/CD ausreichend.

Cloud & DevOps in Ihrer Thesis – professionell evaluiert

Ueber 200 promovierte Ghostwriter – darunter Informatiker mit Cloud- und DevOps-Expertise. Vom Pipeline-Design ueber die Infrastruktur bis zur DORA-Metriken-Evaluation.

Informatik-Ghostwriter Jetzt anfragen

Weitere Informatik-Guides

Alle Guides Software-Architektur IT-Sicherheit Machine Learning Theoretische Informatik Datenbankdesign Cyber-Physical Systems HCI & Usability Quantum Computing Test-Automatisierung Ghostwriter Bachelorarbeit schreiben lassen Masterarbeit schreiben lassen Ghostwriter Hausarbeit Ghostwriter Seminararbeit Ghostwriter Doktorarbeit
crossmenu