In der Cloud-Entwicklung behandeln wir Speicher oft wie unendlich. Jedes Log, jedes Backup oder Dataset, das wir erstellen, wird unbegrenzt aufgehoben - nicht weil es immer nützlich ist, sondern weil Löschen riskant erscheint. Doch diese Denkweise treibt heimlich sowohl Kosten als auch CO2-Emissionen in die Höhe.
Die Wahrheit ist: die meisten gespeicherten Objekte sollten nicht für immer existieren. Von flüchtigen Build-Artefakten bis zu temporären Exporten und kurzlebigen Analyse-Datasets hat ein Großteil der erzeugten Daten eine natürliche Lebensdauer. Die Herausforderung besteht darin, diesen Lebenszyklus mit unseren Systemen in Einklang zu bringen.
Bei DownToZero.Cloud haben wir DTZ ObjectStore nach diesem Prinzip entworfen. Es geht nicht nur darum, Daten effizient zu speichern - sondern sie verantwortungsvoll zu speichern.
Jedes Objekt in der Cloud verbraucht mehr als nur Plattenplatz. Es erfordert:
Diese fortlaufenden Aktivitäten laufen weiter, selbst für Daten, die nie wieder aufgerufen werden. Im Wesentlichen hat unser Speicher einen CO2-Schatten - und unkontrollierte Datenlebenszyklen lassen ihn mit der Zeit wachsen.
Eines der zentralen Green Software Patterns ist Daten-Lifecycle-Management - dafür zu sorgen, dass digitale Ressourcen mit realer Relevanz übereinstimmen.
In der Praxis bedeutet das:
Wenn Sie dieses Pattern anwenden, reichen die Vorteile über Nachhaltigkeit hinaus:
Der DTZ ObjectStore-Dienst ist mit Lifecycle-Management im Kern gebaut. Anders als traditionelle Speichersysteme, in denen TTLs eine nachträgliche Ergänzung sind, integriert DTZ diese Fähigkeit direkt in den Objekt-Erstellungs-Workflow.
Hängen Sie beim Hochladen eine TTL an. Verwenden Sie entweder eine relativen Dauer (X-DTZ-EXPIRE-IN) oder einen absoluten Zeitstempel (X-DTZ-EXPIRE-AT). Geben Sie Ihren API-Schlüssel als X-API-KEY an.
Base URL:
https://objectstore.dtz.rocks/api/2022-11-28
Hochladen mit 24-Stunden-TTL (Dauer):
curl -X PUT \
"https://objectstore.dtz.rocks/api/2022-11-28/obj/logs/builds/2025-11-05.json" \
-H "X-API-KEY: $DTZ_API_KEY" \
-H "X-DTZ-EXPIRE-IN: P1D" \
--data-binary @build-output.json
Hochladen, das zu einer festen Zeit abläuft (RFC-3339):
curl -X PUT \
"https://objectstore.dtz.rocks/api/2022-11-28/obj/exports/report.csv" \
-H "X-API-KEY: $DTZ_API_KEY" \
-H "X-DTZ-EXPIRE-AT: 2025-12-01T00:00:00Z" \
--data-binary @report.csv
Ein Objekt herunterladen:
curl -s \
"https://objectstore.dtz.rocks/api/2022-11-28/obj/exports/report.csv" \
-H "X-API-KEY: $DTZ_API_KEY" -o report.csv
Metadaten prüfen (inklusive serverberechnetem Ablaufdatum):
curl -I \
"https://objectstore.dtz.rocks/api/2022-11-28/obj/exports/report.csv" \
-H "X-API-KEY: $DTZ_API_KEY"
# Look for headers like:
# X-DTZ-EXPIRATION: 2025-12-01T00:00:00Z
Objekte nach Prefix auflisten:
curl -s \
"https://objectstore.dtz.rocks/api/2022-11-28/obj/?prefix=logs/builds/" \
-H "X-API-KEY: $DTZ_API_KEY" \
| jq .
# Response includes per-object fields like key, size, lastModified, and expiration.
Frühzeitig löschen (falls nötig):
curl -X DELETE \
"https://objectstore.dtz.rocks/api/2022-11-28/obj/exports/report.csv" \
-H "X-API-KEY: $DTZ_API_KEY"
Die Löschung jedes Objekts ist in zwei Phasen aufgeteilt. Wenn ein Objekt sein Ablaufdatum erreicht, ist es über die API nicht mehr zugänglich, bleibt aber im Speichersystem vorhanden (und wird zu diesem Zeitpunkt nicht mehr berechnet). Die tatsächliche Entfernung wird in Batches während kohlenstoffarmer Zeitfenster geplant, um den Fußabdruck von Hintergrund-Jobs zu minimieren - so wird Lifecycle-Durchsetzung zu einem Hebel für Nachhaltigkeit, nicht nur zu einer Betriebsaufgabe.
Lifecycle bedeutet nicht rücksichtsloses Löschen - sondern bewusstes Entwerfen. Muster, die gut funktionieren:
Definieren Sie die Regeln einmal und lassen Sie das System sich kontinuierlich selbst optimieren - weniger Verbrauch, geringere Kosten und mehr Leistung mit demselben Energiehaushalt.
Objekt-Lifecycle-Management spiegelt direkt die Green-Software-Philosophie wider: ungenutzte Speicherressourcen löschen und Aufbewahrungsrichtlinien standardmäßig setzen - eine kleine, bewusste Handlung der Fürsorge, die skaliert.
Bei DownToZero.Cloud ist das der Punkt, an dem gute Technik auf gute Bürgerschaft trifft. Unsere Mission ist es, Entwickler zu befähigen, für null Verschwendung zu entwerfen - wo Daten nur so lange leben, wie sie müssen, und nicht länger.
Das Objekt-Lifecycle-Management lässt sich nahtlos in CI/CD-Pipelines integrieren. DTZ stellt dedizierte GitHub Actions zum Hoch- und Herunterladen von Objekten mit eingebauter Ablaufunterstützung bereit:
Beispiel: Lade ein Build-Artefakt mit 30-tägiger Ablaufzeit hoch
- name: Upload build artifact
uses: DownToZero-Cloud/objectstore-upload@main
with:
api_key: ${{ secrets.DTZ_API_KEY }}
name: build.zip
expiration: P30D
So lässt sich Lifecycle-Policy direkt in Ihre Deployment-Workflows einbinden - und stellt sicher, dass temporäre Artefakte sich nicht unkontrolliert ansammeln.
Speicher sollte dynamisch, nicht statisch sein.
Indem Sie Lifecycle-Bewusstsein in Ihre Architektur einbetten, reduzieren Sie Cloud-Verschwendung und übernehmen ein nachhaltiges Design-Pattern, das dem Planeten, Ihrer Plattform und Ihren Nutzern zugutekommt.
DTZ ObjectStore macht dieses Prinzip zur Praxis - jedes Objekt erhält eine Geschichte, einen Zweck und, am wichtigsten, ein Ende.