Zum Inhalt

Cloud Migration - Raus aus der Hyperscaler-Abhängigkeit

Die Herausforderung: Vendor Lock-in bei Cloud-Hyperscalern

Cloud-Hyperscaler wie AWS, Azure und Google Cloud bieten komfortable, verwaltete Services – aber zu einem hohen Preis: proprietäre APIs, nicht-standardisierte Datenformate, egress fees und vertragliche Hürden schaffen systematischen Vendor Lock-in.

Typische Lock-in-Mechanismen:

  • 🔒 Proprietäre Services: RDS, DynamoDB, S3, Lambda mit AWS-spezifischen APIs
  • 💰 Egress Fees: Hohe Kosten für Datentransfer beim Wechsel
  • 📦 Nicht-portable Formate: Vendor-spezifische IaC (CloudFormation, ARM Templates)
  • 🔗 Service-Verkettungen: Tief integrierte Services erschweren Teilmigration
  • 📄 Vertragliche Bindung: Enterprise Agreements mit Rabatt-Struktur binden langfristig

Die Folgen:

  • ❌ Keine Wechselmöglichkeit bei Preissteigerungen oder Qualitätsproblemen
  • ❌ Abhängigkeit von Drittland-Jurisdiktion (CLOUD Act, FISA)
  • ❌ Fehlende Souveränität über eigene Infrastruktur
  • ❌ Schwierige Compliance (DORA, NIS-2, Data Act)

Der EU Data Act: Portabilität als Pflicht

Der Data Act (EU 2023/2854) tritt am 12. September 2025 in Kraft und schafft verbindliche Regeln für Cloud-Switching und Interoperabilität.

Data Act Kernforderungen an Cloud-Provider

Anforderung Beschreibung Deadline
Offene Schnittstellen Standardisierte, dokumentierte APIs für Export Sofort
Maschinenlesbare Formate Daten in strukturierten, gängigen Formaten Sofort
Funktionale Äquivalenz Mindestens für IaaS-Features Sofort
Egress Fee-Abbau Schrittweise Reduzierung bis auf 0€ Bis 12.09.2028
Multi-Cloud-Support Parallelbetrieb und graduelle Migration ermöglichen Sofort
Dokumentierte Switching-Prozesse Transparente Wechselprozesse vor Vertrag Sofort

Was bedeutet das für Unternehmen?

  • ✅ Recht auf Wechsel – Cloud-Kunden müssen wechseln können
  • ✅ Portabilität – Voller Export von Daten, Apps, Konfigurationen
  • ✅ Interoperabilität – Offene Standards statt proprietäre Formate
  • ✅ Kostenfreiheit – Keine Egress Fees ab 2028
  • ✅ Unabhängigkeit – Keine vertraglichen oder technischen Lock-ins

Aber: Der Data Act fordert Rechte – er liefert keine Werkzeuge zur Umsetzung.

Polycrate: Das ideale Werkzeug für souveräne Cloud-Migration

Polycrate wurde entwickelt, um standardisierte, portable Infrastruktur-Automatisierung zu ermöglichen – genau das, was der Data Act fordert und Hyperscaler jahrelang verhindert haben.

Warum Polycrate für Cloud-Migration?

1. Ansible: Industrie-Standard für heterogene Infrastruktur

Polycrate nutzt Ansible als Kern-Engine – den de-facto Industrie-Standard für Automatisierung heterogener IT-Landschaften.

graph LR
    Polycrate[Polycrate] --> Ansible[Ansible]
    Ansible --> AWS[AWS]
    Ansible --> Azure[Azure]
    Ansible --> GCP[Google Cloud]
    Ansible --> K8s[Kubernetes]
    Ansible --> Linux[Linux Hosts]
    Ansible --> Docker[Docker]

    style Ansible fill:#e74c3c,color:#fff
    style Polycrate fill:#3498db,color:#fff

Vorteile:

  • ✅ Nicht-proprietär: Ansible ist Open Source, kein Vendor Lock-in
  • ✅ Universell einsetzbar: AWS, Azure, GCP, Bare Metal, K8s, Docker
  • ✅ Deklarativ: Infrastructure as Code, versionierbar, reproduzierbar
  • ✅ Etabliert: Über 60% der Unternehmen nutzen Ansible (Red Hat Survey 2023)
  • ✅ Agentless: Keine Software-Installation auf Zielsystemen nötig

2. Kubernetes-native Architektur

Polycrate fokussiert Kubernetes als Ziel-Plattform – die einzige wirklich cloud-agnostische Infrastruktur-Schicht.

# block.poly - Kubernetes-native App-Deployment
name: my-app
kind: k8sapp

config:
  namespace: production
  replicas: 3
  persistence:
    enabled: true
    size: 50Gi

actions:
  - name: install
    playbook: install.yml

# Kubeconfig wird von anderem Block referenziert
kubeconfig:
  from: my-cluster

Warum Kubernetes?

  • 🌍 Cloud-agnostisch: Läuft identisch auf AWS, Azure, GCP, Bare Metal
  • 📦 Container-nativ: Standard-Artefakte (OCI Images), keine proprietären Formate
  • 🔄 Portabel: Workloads lassen sich zwischen Clustern verschieben
  • 🛠️ Standardisiert: CNCF-Standards (kubectl, Helm, Operators)
  • 🔓 Lock-in-frei: Kein Vendor kann Kubernetes "ownen"

3. Kostenlose, Production-Ready Blocks vom PolyHub

Der PolyHub bietet kuratierte, kostenlose Blocks für häufige Infrastruktur-Patterns – als Hyperscaler-Alternativen.

Beispiele: Hyperscaler → K8s-native Alternative

Hyperscaler-Service Polycrate Block (Open Source) Technologie
AWS RDS (PostgreSQL) ayedo/k8s/cloudnative-pg CloudNativePG Operator
AWS ElastiCache (Redis) ayedo/k8s/redis Redis mit Sentinel HA
AWS DocumentDB (MongoDB) ayedo/k8s/mongodb MongoDB mit Replica Sets
AWS ALB/ELB ayedo/k8s/nginx NGINX Ingress Controller
AWS Certificate Manager ayedo/k8s/cert-manager cert-manager + Let's Encrypt
AWS ECR ayedo/k8s/harbor Harbor Container Registry
AWS CloudWatch ayedo/k8s/victoria-metrics-stack VictoriaMetrics + Grafana
AWS Secrets Manager ayedo/k8s/hashicorp-vault HashiCorp Vault
AWS SQS/SNS ayedo/k8s/rabbitmq-operator RabbitMQ Operator

Alle PolyHub-Blocks sind:

  • 🆓 Open Source (Apache 2.0)
  • ✅ Production-Tested
  • 📖 Vollständig dokumentiert
  • 🔄 Versioniert (Semantic Versioning)
  • 🧪 Erweiterbar (via Vererbung)
# Block vom PolyHub pullen
polycrate blocks pull cargo.ayedo.cloud/ayedo/k8s/cloudnative-pg:1.2.0

# Deployen
polycrate run ayedo/k8s/cloudnative-pg install

4. Umfangreiche Cloud-Native Toolchain vorinstalliert

Der Polycrate-Container bringt alle nötigen Tools für Cloud-Migration mit – keine lokalen Installationen erforderlich.

Kubernetes & Container: 

kubectl v1.32.1     - Kubernetes CLI
helm v3.18.4        - Package Manager für Kubernetes
cilium v0.18.5      - Networking & Security
velero v1.16.1      - Backup & Disaster Recovery
argocd v3.0.6       - GitOps Deployment
docker              - Container Runtime CLI
skopeo              - Container Image Management

Automatisierung & IaC: 

ansible-core        - Automation Engine
terraform           - Infrastructure as Code
yq v4.45.1          - YAML/JSON Processor
jq                  - JSON Processor
age v1.2.1          - Encryption Tool

Cloud Provider CLIs (via Ansible): 

AWS (boto3)         - AWS SDK für Python
Hetzner (hcloud)    - Hetzner Cloud API Client
VMware (PyVmomi)    - VMware vSphere API
OpenStack           - OpenStack APIs
Azure               - Azure SDKs (via Ansible modules)
GCP                 - Google Cloud SDKs (via Ansible modules)

Migration-spezifische Tools: 

rsync               - Datensynchronisation
openssh-client      - Remote-Access
docker-compose      - Multi-Container Apps
git                 - Versionskontrolle
apache2-utils       - HTTP-Benchmarking (ab, htpasswd)

Ansible Collections für Provider: 

community.general   - 1000+ Module für diverse Systeme
community.docker    - Docker & Docker Compose Automation
community.vmware    - VMware vSphere Automation
netbox.netbox       - IPAM & DCIM Integration

Assessment-Workflow mit Polycrate:

# workspace.poly - Migration Assessment
name: aws-migration-assessment

blocks:
  - name: aws-inventory
    actions:
      - name: scan-resources
        script:
          # AWS CLI via Ansible boto3
          - ansible-playbook scan-aws-resources.yml

      - name: export-rds-schemas
        script:
          # PostgreSQL Schema Export
          - ansible-playbook export-rds-schemas.yml

      - name: analyze-dependencies
        script:
          # Service Dependency Analysis
          - python analyze-service-mesh.py
          - yq eval '.services[] | .dependencies' services.yaml

  - name: cost-analysis
    actions:
      - name: calculate-savings
        script:
          # Cost-Vergleich: AWS vs. Self-Hosted
          - python calculate-migration-cost.py

Beispiel: RDS-Datenbank-Assessment mit vorinstallierten Tools

# playbooks/scan-aws-resources.yml
---
- name: Scan AWS RDS Instances
  hosts: localhost
  tasks:
    - name: Get all RDS instances
      amazon.aws.rds_instance_info:
        region: eu-central-1
      register: rds_instances

    - name: Export to JSON
      copy:
        content: "{{ rds_instances | to_nice_json }}"
        dest: "{{ artifacts_root }}/aws-rds-inventory.json"

    - name: Analyze schemas
      shell: |
        for instance in $(cat {{ artifacts_root }}/aws-rds-inventory.json | jq -r '.instances[].db_instance_identifier'); do
          pg_dump -h ${instance}.abc123.eu-central-1.rds.amazonaws.com \
            -U admin \
            --schema-only \
            -f {{ artifacts_root }}/${instance}-schema.sql
        done

Ausführung:

# Alles läuft im Polycrate-Container - keine lokalen Tools nötig!
polycrate run aws-inventory scan-resources
polycrate run aws-inventory export-rds-schemas
polycrate run aws-inventory analyze-dependencies
polycrate run cost-analysis calculate-savings

Vorteile:

  • ✅ Keine lokale Installation: Alle Tools im Container, konsistente Versionen
  • ✅ Provider-Übergreifend: AWS, Azure, GCP, VMware, Hetzner – alles dabei
  • ✅ Assessment-Ready: Direkt mit Inventarisierung starten
  • ✅ Migrations-Ready: Schema-Export, Datensync, Testing – alles verfügbar
  • ✅ Versioniert: Exakt definierte Tool-Versionen (siehe Dockerfile.goreleaser)

5. Provider-Unabhängige Infrastructure as Code

Polycrate-Workspaces sind vollständig portabel – kein Lock-in an Tools, Provider oder Plattformen.

# workspace.poly - Provider-unabhängige Beschreibung
name: production-stack

blocks:
  # Cluster auf beliebigem Provider (Linux-Server)
  - name: k8s-cluster
    from: cargo.ayedo.cloud/ayedo/linux/k8s-1.27:1.0.0
    config:
      servers: 3
      agents: 5

  # Apps auf Cluster (Provider-agnostisch)
  - name: postgres
    from: cargo.ayedo.cloud/ayedo/k8s/cloudnative-pg:1.2.0
    kubeconfig:
      from: k8s-cluster
    config:
      namespace: databases
      persistence:
        size: 100Gi
        storageClass: fast-ssd

  - name: app
    from: webapp-base:1.0.0
    kubeconfig:
      from: k8s-cluster
    config:
      domain: myapp.example.com
      replicas: 3

workflows:
  - name: deploy-complete-stack
    steps:
      - name: provision-cluster
        block: k8s-cluster
        action: provision
      - name: deploy-postgres
        block: postgres
        action: install
      - name: deploy-app
        block: app
        action: install

Dieser Workspace läuft identisch auf:

  • ☁️ AWS (via Hetzner Cloud, EKS, EC2)
  • ☁️ Azure (AKS, VMs)
  • ☁️ Google Cloud (GKE, Compute Engine)
  • 🖥️ Bare Metal (eigene Server)
  • 🏠 On-Premise (VMware, Proxmox)

Wechsel? → Nur Kubeconfig austauschen, Rest bleibt identisch.

6. OCI-Registry-basiertes Sharing

Polycrate nutzt OCI-kompatible Registries (Docker, Harbor, etc.) für Block-Distribution – offener Standard, kein proprietäres Format.

# Block entwickeln
cd blocks/my-custom-postgres

# In private Registry pushen
polycrate block push registry.company.com/infra/postgres:1.0.0

# In anderem Workspace verwenden
polycrate blocks pull registry.company.com/infra/postgres:1.0.0

Data Act-konform:

  • ✅ Maschinenlesbares Format (OCI Image Spec)
  • ✅ Offener Standard (kein Vendor Lock-in)
  • ✅ Portabel (jede OCI-Registry funktioniert)
  • ✅ Versioniert (Image Tags)

Der Migrationspfad: Von Hyperscaler zu souveräner K8s-nativer Infrastruktur

Phase 1: Assessment & Planung

Ziel: Bestandsaufnahme der aktuellen Hyperscaler-Abhängigkeiten

# Workspace für Migration Assessment
name: migration-assessment

blocks:
  - name: inventory
    actions:
      - name: scan-aws
        script:
          - aws resourcegroupstaggingapi get-resources > aws-resources.json
          - python analyze-resources.py aws-resources.json

      - name: analyze-dependencies
        script:
          - echo "Analyzing service dependencies..."
          - python dependency-graph.py aws-resources.json > dependencies.yaml

Ergebnis: Inventar aller Ressourcen, Service-Abhängigkeiten, Migrationskandidaten

Phase 2: Ziel-Architektur Design

Ziel: K8s-native Alternativen für jeden Hyperscaler-Service identifizieren

Migrationsstrategie:

graph TB
    AWS[AWS Services] --> Analysis[Analyse & Mapping]
    Analysis --> K8s[Kubernetes-Native<br/>Alternativen]

    AWS --> RDS[RDS PostgreSQL]
    AWS --> ElastiCache[ElastiCache Redis]
    AWS --> ELB[ALB/ELB]
    AWS --> ECR[ECR]
    AWS --> CloudWatch[CloudWatch]

    RDS --> PG[CloudNativePG<br/>ayedo/k8s/cloudnative-pg]
    ElastiCache --> Redis[Redis Sentinel<br/>ayedo/k8s/redis]
    ELB --> Ingress[NGINX Ingress<br/>ayedo/k8s/nginx]
    ECR --> Harbor[Harbor Registry<br/>ayedo/k8s/harbor]
    CloudWatch --> Prom[VictoriaMetrics + Grafana<br/>ayedo/k8s/victoria-metrics-stack]

    K8s --> PG
    K8s --> Redis
    K8s --> Ingress
    K8s --> Harbor
    K8s --> Prom

    style AWS fill:#ff9900,color:#fff
    style K8s fill:#326ce5,color:#fff
    style Analysis fill:#3498db,color:#fff

Phase 3: Parallel-Aufbau mit Polycrate

Ziel: Neue K8s-native Infrastruktur parallel zur bestehenden aufbauen

# workspace.poly - Migration Workspace
name: migration-production

blocks:
  # Neuer K8s-Cluster auf Linux-Servern
  - name: new-cluster
    from: cargo.ayedo.cloud/ayedo/linux/k8s-1.27:1.0.0
    config:
      servers: 3
      agents: 5

  # PostgreSQL-Migration (RDS → CloudNativePG)
  - name: postgres-migration
    from: cargo.ayedo.cloud/ayedo/k8s/cloudnative-pg:1.2.0
    kubeconfig:
      from: new-cluster
    config:
      namespace: databases
      app:
        persistence:
          size: 200Gi  # Größe aus RDS übernehmen
          storageClass: fast-ssd
        backup:
          enabled: true
          schedule: "0 2 * * *"

    actions:
      - name: migrate-from-rds
        playbook: migrate-rds.yml

  # Redis-Migration (ElastiCache → Redis Sentinel)
  - name: redis-migration
    from: cargo.ayedo.cloud/ayedo/k8s/redis:1.0.0
    kubeconfig:
      from: new-cluster
    config:
      namespace: cache
      persistence:
        enabled: true
        size: 50Gi

  # Ingress (ALB → NGINX)
  - name: ingress
    from: cargo.ayedo.cloud/ayedo/k8s/nginx:1.0.0
    kubeconfig:
      from: new-cluster

  # Monitoring (CloudWatch → VictoriaMetrics + Grafana)
  - name: monitoring
    from: cargo.ayedo.cloud/ayedo/k8s/victoria-metrics-stack:2.0.0
    kubeconfig:
      from: new-cluster
    config:
      retention: 30d
      storage: 100Gi

workflows:
  - name: setup-target-infrastructure
    steps:
      - name: provision-cluster
        block: new-cluster
        action: provision

      - name: deploy-ingress
        block: ingress
        action: install

      - name: deploy-monitoring
        block: monitoring
        action: install

      - name: deploy-postgres
        block: postgres-migration
        action: install

      - name: deploy-redis
        block: redis-migration
        action: install

  - name: migrate-data
    prompt:
      message: "Datenmigration starten? (Downtime erforderlich)"
    steps:
      - name: backup-rds
        block: postgres-migration
        action: backup-from-rds

      - name: stop-old-app
        block: legacy-app
        action: stop

      - name: restore-to-cloudnativepg
        block: postgres-migration
        action: restore

      - name: verify-data
        block: postgres-migration
        action: verify

      - name: start-new-app
        block: new-app
        action: start

Ausführung:

# Ziel-Infrastruktur aufbauen
polycrate workflows run setup-target-infrastructure --blocks-auto-pull

# Datenmigration durchführen
polycrate workflows run migrate-data --force

# Verifikation
polycrate run postgres-migration verify
polycrate run new-app health-check

Phase 4: Cutover & Validation

Ziel: Traffic auf neue Infrastruktur umleiten, alte abschalten

# Cutover-Workflow
workflows:
  - name: cutover
    prompt:
      message: "Production Cutover starten?"
    steps:
      # DNS/Load Balancer auf neues System umstellen
      - name: update-dns
        block: dns
        action: point-to-new-cluster

      # Traffic-Validierung
      - name: monitor-traffic
        block: monitoring
        action: watch-metrics

      # Alte Services stoppen (nach Soak-Period)
      - name: shutdown-old-services
        block: legacy
        action: stop

Phase 5: Decommission Hyperscaler-Resources

Ziel: Alte Hyperscaler-Ressourcen abbauen

workflows:
  - name: cleanup-aws
    prompt:
      message: "AWS-Ressourcen wirklich löschen?"
    steps:
      - name: delete-rds
        block: aws-cleanup
        action: delete-rds-instance

      - name: delete-elasticache
        block: aws-cleanup
        action: delete-elasticache-cluster

      - name: delete-alb
        block: aws-cleanup
        action: delete-load-balancers

Praktische Beispiele

Beispiel 1: PostgreSQL-Migration (AWS RDS → CloudNativePG)

# workspace.poly - PostgreSQL Migration Block-Definition
name: migration-production

blocks:
  - name: postgres-migration
    from: cargo.ayedo.cloud/ayedo/k8s/cloudnative-pg:1.2.0
    kubeconfig:
      from: new-cluster
    config:
      namespace: databases
      aws:
        rds_endpoint: "mydb.abc123.eu-central-1.rds.amazonaws.com"
        rds_database: "production"
        rds_user: "admin"
    actions:
      - name: backup-from-rds
        playbook: playbooks/backup-rds.yml
      - name: restore
        playbook: playbooks/restore.yml
      - name: verify
        playbook: playbooks/verify.yml

# playbooks/backup-rds.yml
---
- name: Backup from AWS RDS
  hosts: localhost
  tasks:
    - name: Create backup from RDS
      ansible.builtin.shell: |
        pg_dump \
          -h {{ block.config.aws.rds_endpoint }} \
          -U {{ block.config.aws.rds_user }} \
          -d {{ block.config.aws.rds_database }} \
          -F custom \
          -f {{ artifacts_root }}/blocks/postgres-migration/rds-backup.dump
      environment:
        PGPASSWORD: "{{ lookup('env', 'RDS_PASSWORD') }}"

    - name: Verify backup
      ansible.builtin.stat:
        path: "{{ artifacts_root }}/blocks/postgres-migration/rds-backup.dump"
      register: backup_file

    - name: Fail if backup missing
      ansible.builtin.fail:
        msg: "Backup file not created"
      when: not backup_file.stat.exists

# playbooks/restore.yml
---
- name: Restore to CloudNativePG
  hosts: localhost
  tasks:
    - name: Get CloudNativePG primary pod
      kubernetes.core.k8s_info:
        kubeconfig: "{{ kubeconfig_path }}"
        kind: Pod
        namespace: "{{ block.config.namespace }}"
        label_selectors:
          - "cnpg.io/cluster={{ block.name }}"
          - "role=primary"
      register: primary_pod

    - name: Copy backup to pod
      kubernetes.core.k8s_cp:
        kubeconfig: "{{ kubeconfig_path }}"
        namespace: "{{ block.config.namespace }}"
        pod: "{{ primary_pod.resources[0].metadata.name }}"
        remote_path: "/tmp/backup.dump"
        local_path: "{{ artifacts_root }}/blocks/postgres-migration/rds-backup.dump"
        state: to_pod

    - name: Restore backup
      kubernetes.core.k8s_exec:
        kubeconfig: "{{ kubeconfig_path }}"
        namespace: "{{ block.config.namespace }}"
        pod: "{{ primary_pod.resources[0].metadata.name }}"
        command: |
          pg_restore \
            -d {{ block.config.aws.rds_database }} \
            -U postgres \
            /tmp/backup.dump

Ausführung:

# Backup aus RDS
export RDS_PASSWORD="your-rds-password"
polycrate run postgres-migration backup-from-rds

# Restore in CloudNativePG
polycrate run postgres-migration restore

# Verifikation
polycrate run postgres-migration verify

Beispiel 2: Complete Stack Migration

# workspace.poly - Full Stack Migration
name: complete-migration

blocks:
  # Cluster auf Linux-Servern
  - name: cluster
    from: cargo.ayedo.cloud/ayedo/linux/k8s-1.27:1.0.0
    config:
      servers: 3
      agents: 5

  # Databases
  - name: postgres
    from: cargo.ayedo.cloud/ayedo/k8s/cloudnative-pg:1.2.0
    kubeconfig:
      from: cluster

  - name: redis
    from: cargo.ayedo.cloud/ayedo/k8s/redis:1.0.0
    kubeconfig:
      from: cluster

  # Infrastructure
  - name: ingress
    from: cargo.ayedo.cloud/ayedo/k8s/nginx:1.0.0
    kubeconfig:
      from: cluster

  - name: cert-manager
    from: cargo.ayedo.cloud/ayedo/k8s/cert-manager:1.0.0
    kubeconfig:
      from: cluster

  # Monitoring
  - name: monitoring
    from: cargo.ayedo.cloud/ayedo/k8s/victoria-metrics-stack:2.0.0
    kubeconfig:
      from: cluster

  # Registry
  - name: harbor
    from: cargo.ayedo.cloud/ayedo/k8s/harbor:1.0.0
    kubeconfig:
      from: cluster

workflows:
  - name: migrate-complete-stack
    steps:
      # Infrastructure
      - name: provision-cluster
        block: cluster
        action: provision

      - name: deploy-ingress
        block: ingress
        action: install

      - name: deploy-cert-manager
        block: cert-manager
        action: install

      # Monitoring
      - name: deploy-monitoring
        block: monitoring
        action: install

      # Databases
      - name: deploy-postgres
        block: postgres
        action: install

      - name: deploy-redis
        block: redis
        action: install

      # Registry
      - name: deploy-harbor
        block: harbor
        action: install

# Gesamte Migration durchführen
polycrate workflows run migrate-complete-stack --blocks-auto-pull

Vorteile der Polycrate-basierten Migration

1. Data Act-Konformität

  • ✅ Offene Standards: Ansible, Kubernetes, OCI Images
  • ✅ Maschinenlesbare Formate: YAML, JSON
  • ✅ Vollständige Portabilität: Workspaces zwischen Providern verschiebbar
  • ✅ Keine Egress Fees: Block-Transfer über Standard-Registries
  • ✅ Funktionale Äquivalenz: K8s-native Services bieten gleiche Features

2. Souveränität & Kontrolle

  • 🏛️ EU-Hosting: Kubernetes-Cluster in Deutschland/EU betreibbar
  • 🔐 Volle Kontrolle: Kein Vendor kann Zugriff erzwingen
  • 🔑 Customer-Managed Keys: Verschlüsselung mit eigenen Schlüsseln
  • 🛡️ DORA/NIS-2-konform: Vollständige Exit-Strategien dokumentiert

3. Kosteneffizienz

  • 💰 Keine Egress Fees: Datentransfer zwischen eigenen Systemen kostenfrei
  • 📉 Transparente Preise: Bare-Metal/Hetzner statt AWS-Markup
  • 🆓 Open-Source-Stack: PostgreSQL statt RDS, Redis statt ElastiCache
  • 📊 Vorhersagbare Kosten: Keine Überraschungen durch versteckte Gebühren

4. Technische Unabhängigkeit

  • 🔄 Provider-Wechsel: Jederzeit zu anderem Kubernetes-Provider wechselbar
  • 🧱 Modulare Architektur: Services einzeln austauschbar
  • 📦 Standard-Artefakte: Container-Images, Helm Charts, Ansible Playbooks
  • 🌍 Keine Herstellerbindung: Open-Source-Ökosystem statt Vendor-Lock
  • 🛠️ Umfangreiche Toolchain: kubectl, helm, ansible, terraform & Cloud-Provider-CLIs vorinstalliert

5. Compliance & Audit

  • 📋 Dokumentierte Prozesse: Alle Migrations-Steps versioniert in Git
  • 🔍 Reproduzierbar: Exakt gleiche Infrastruktur jederzeit neu aufbaubar
  • 📊 Audit-Trail: Vollständige Historie aller Änderungen
  • ✅ Zertifizierbar: ISO 27001, BSI IT-Grundschutz kompatibel

Zusammenhang mit anderen Konzepten

  • Warum Polycrate?: Grundlegende Polycrate-Philosophie
  • PolyHub: Kostenlose Blocks als Hyperscaler-Alternativen
  • Ansible: Industrie-Standard für Automatisierung
  • Kubernetes: Cloud-agnostische Ziel-Plattform
  • Workflows: Orchestrierung komplexer Migrations-Prozesse
  • Registry: OCI-basiertes Block-Sharing für Portabilität
  • Recipes: Praktische Migrations-Beispiele

Nächste Schritte

  1. Assessment durchführen:
  2. Polycrate installieren: curl -sSL https://get.polycrate.io | bash
  3. Inventar-Workspace erstellen mit vorinstallierten Cloud-Provider-Tools
  4. AWS/Azure/GCP-Ressourcen scannen (boto3, Azure SDK, GCP SDK bereits dabei)

  5. Kosten-Analyse durchführen

  6. PolyHub erkunden:

  7. hub.polycrate.io für K8s-native Alternativen besuchen

  8. Hyperscaler-Service → PolyHub-Block Mapping erstellen

  9. Pilot starten:

  10. Nicht-kritischen Service als Proof-of-Concept migrieren

  11. Mit vorinstallierten Tools (kubectl, helm, ansible) direkt loslegen

  12. Workspace aufbauen:

  13. Ziel-Infrastruktur parallel zum Hyperscaler aufbauen

  14. PolyHub-Blocks für Postgres, Redis, Monitoring etc. nutzen

  15. Datenmigration planen:

  16. Backup-/Restore-Workflows mit Ansible definieren

  17. Schema-Export via pg_dump/mongodump (vorinstalliert)

  18. Cutover durchführen:

  19. Traffic auf neue Infrastruktur umleiten

  20. Monitoring mit VictoriaMetrics-Stack

  21. Decommission:

  22. Alte Hyperscaler-Ressourcen abbauen
  23. Mit provider-spezifischen Ansible-Modulen automatisieren

Bereit für souveräne Cloud-Infrastruktur?

Kontaktieren Sie ayedo für: - Migration-Assessments - Architektur-Workshops - Hands-on Unterstützung bei der Umsetzung - Custom Block-Entwicklung für spezifische Use Cases

Data Act Compliance mit Polycrate

Mit Polycrate erfüllen Sie nicht nur die Data Act-Anforderungen – Sie bauen eine zukunftssichere, souveräne Cloud-Infrastruktur auf offenen Standards. Keine Abhängigkeit, volle Kontrolle, transparente Kosten.