In der Cloud-Entwicklung behandeln wir Speicher oft wie etwas Unendliches. Jeder Log, jedes Backup oder Dataset, das wir erstellen, wird unbegrenzt aufbewahrt – nicht weil es immer nützlich ist, sondern weil das Löschen riskant erscheint. Dennoch treibt diese Denkweise heimlich sowohl Kosten als auch CO2-Ausstoß in die Höhe.
Die Wahrheit ist: die meisten gespeicherten Objekte sollten nicht ewig leben. Von transienten Build-Artefakten bis zu temporären Exporten und kurzlebigen Analytics-Datasets – ein Großteil der von uns erzeugten Daten hat eine natürliche Lebensdauer. Die Herausforderung besteht darin, diesen Lebenszyklus mit unseren Systemen in Einklang zu bringen.
Bei DownToZero.Cloud haben wir DTZ ObjectStore rund um dieses 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 benötigt:
Diese laufenden Aktivitäten erfolgen auch für Daten, die nie wieder aufgerufen werden. Im Grunde hat unser Speicher einen CO2-Schatten – und unkontrollierte Datenlebenszyklen lassen ihn mit der Zeit wachsen.
Eines der Kernprinzipien der Green Software Patterns ist Daten-Lifecycle-Management – sicherzustellen, dass digitale Ressourcen mit ihrer realen Relevanz übereinstimmen.
In der Praxis bedeutet das:
Wenn Sie dieses Muster anwenden, gehen die Vorteile über Nachhaltigkeit hinaus:
Der DTZ ObjectStore-Service ist mit Lifecycle-Management im Kern gebaut. Im Gegensatz zu traditionellen Speichersystemen, bei denen TTLs eine nachträgliche Überlegung sind, bettet DTZ diese Fähigkeit direkt in den Objekt-Erstellungsworkflow ein.
Hängen Sie beim Hochladen eine TTL an. Verwenden Sie entweder relative Dauer (X-DTZ-EXPIRE-IN) oder einen absoluten Zeitstempel (X-DTZ-EXPIRE-AT). Übergeben Sie Ihren API-Schlüssel als X-API-KEY.
Basis-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 (einschließlich vom Server berechnetem 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 Präfix 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 seine Ablaufzeit erreicht, ist es über die API nicht mehr zugänglich, bleibt jedoch im Speichersystem präsent (und wird zu diesem Zeitpunkt auch nicht berechnet). Die tatsächliche Löschung wird in Chargen während Zeitfenstern mit niedriger CO2-Intensität geplant, um den Fußabdruck der Hintergrundjobs zu minimieren – so wird die Durchsetzung von Lebenszyklen zu einem Hebel für Nachhaltigkeit, nicht nur zu einer Ops-Aufgabe.
Lebenszyklus bedeutet nicht leichtfertiges Löschen – sondern zielgerichtetes Entwerfen. Muster, die gut funktionieren:
Definieren Sie die Regeln einmal und lassen Sie das System sich kontinuierlich selbst optimieren – weniger verbrauchen, weniger kosten und mehr leisten bei gleichem Energieaufwand.
Das Objekt-Lifecycle-Management spiegelt direkt die Green Software-Philosophie wider: ungenutzte Speicherressourcen löschen und standardmäßig Aufbewahrungsrichtlinien setzen – eine kleine, bewusste Maßnahme der Verantwortung, die skaliert.
Bei DownToZero.Cloud ist das der Punkt, an dem gute Technik auf gute Staatsbürgerschaft trifft. Unsere Mission ist es, Entwickelnde zu befähigen, für Null-Verschwendung zu entwerfen – Daten leben nur so lange, wie sie gebraucht werden, 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 integrierter Ablaufunterstützung bereit:
Beispiel: Ein Build-Artefakt mit 30-tägiger Ablaufzeit hochladen
- name: Upload build artifact
uses: DownToZero-Cloud/objectstore-upload@main
with:
api_key: ${{ secrets.DTZ_API_KEY }}
name: build.zip
expiration: P30D
So lassen sich Lifecycle-Richtlinien mühelos direkt in Deployment-Workflows anwenden – und stellen sicher, dass temporäre Artefakte sich nicht unendlich ansammeln.
Speicher sollte dynamisch, nicht statisch sein.
Indem Sie Lebenszyklusbewusstsein in Ihre Architektur einbetten, verringern Sie Cloud-Abfall und übernehmen ein Muster nachhaltigen Designs, das dem Planeten, Ihrer Plattform und Ihren Nutzerinnen und Nutzern gleichermaßen zugutekommt.
DTZ ObjectStore macht dieses Prinzip zur Praxis – jedes Objekt bekommt eine Geschichte, einen Zweck und, am wichtigsten, ein Ende.