Dans le développement cloud, nous traitons souvent le stockage comme infini. Chaque log, sauvegarde ou jeu de données que nous créons est conservé indéfiniment — pas toujours parce que c’est utile, mais parce que supprimer fait peur. Pourtant, cette mentalité augmente silencieusement à la fois les coûts et l’impact carbone.
La vérité est : la plupart des objets stockés ne devraient pas vivre éternellement. Des artefacts de build temporaires aux exportations éphémères et aux jeux de données analytiques à courte durée de vie, une grande partie des données que nous produisons a une durée de vie naturelle. Le défi est d’aligner ce cycle de vie avec nos systèmes.
Chez DownToZero.Cloud, nous avons conçu DTZ ObjectStore autour de ce principe. Il ne s’agit pas seulement de stocker les données efficacement — il s’agit de les stocker de manière responsable.
Chaque objet dans le cloud consomme plus que de l’espace disque. Il utilise :
Cette activité continue persiste même pour des données qui ne sont plus jamais consultées. En substance, notre stockage a une ombre carbone — et des cycles de vie de données non gérés la font grandir avec le temps.
Un des principaux Green Software Patterns est la gestion du cycle de vie des données — s’assurer que les ressources numériques correspondent à leur pertinence réelle.
En pratique, cela signifie :
Lorsque vous appliquez ce pattern, les bénéfices dépassent la durabilité :
Le service DTZ ObjectStore est construit avec la gestion du cycle de vie au cœur. Contrairement aux systèmes de stockage traditionnels où les TTL sont une après-pensée, DTZ intègre cette fonctionnalité dans le flux de création d’objet.
Attachez un TTL lorsque vous téléversez. Utilisez soit une durée relative (X-DTZ-EXPIRE-IN) soit un horodatage absolu (X-DTZ-EXPIRE-AT). Fournissez votre clé API en tant que X-API-KEY.
Base URL:
https://objectstore.dtz.rocks/api/2022-11-28
Upload with a 24-hour TTL (duration):
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
Upload that expires at a fixed time (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
Download an object:
curl -s \
"https://objectstore.dtz.rocks/api/2022-11-28/obj/exports/report.csv" \
-H "X-API-KEY: $DTZ_API_KEY" -o report.csv
Check metadata (including server-computed expiration):
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
List objects by prefix:
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.
Delete early (if needed):
curl -X DELETE \
"https://objectstore.dtz.rocks/api/2022-11-28/obj/exports/report.csv" \
-H "X-API-KEY: $DTZ_API_KEY"
La suppression de chaque objet est divisée en deux phases. Lorsqu’un objet atteint son heure d’expiration, il n’est plus accessible via l’API, mais il reste présent dans le système de stockage (et n’est pas facturé à ce stade). La suppression réelle est planifiée par lots pendant des fenêtres à faible empreinte carbone afin de minimiser l’impact des tâches en arrière-plan — transformant l’application des cycles de vie en un levier de durabilité, pas seulement en une tâche d’exploitation.
Le cycle de vie ne consiste pas à supprimer de manière irréfléchie — il s’agit de concevoir avec un but. Les patterns qui fonctionnent bien :
Définissez les règles une fois et laissez le système s’optimiser en continu — consommant moins, coûtant moins et accomplissant plus avec la même enveloppe énergétique.
La gestion du cycle de vie des objets reflète directement l’esprit du Green Software : supprimer les ressources de stockage inutilisées et définir des politiques de rétention par défaut — un petit acte intentionnel de gestion qui s’étend à grande échelle.
Chez DownToZero.Cloud, c’est là où la bonne ingénierie rencontre la bonne citoyenneté. Notre mission est de permettre aux développeurs de concevoir pour zéro déchet — où les données vivent seulement aussi longtemps que nécessaire, et pas plus.
La gestion du cycle de vie des objets s’intègre parfaitement dans les pipelines CI/CD. DTZ fournit des GitHub Actions dédiées pour téléverser et télécharger des objets avec prise en charge de l’expiration intégrée :
Example: Upload a build artifact with 30-day expiration
- name: Upload build artifact
uses: DownToZero-Cloud/objectstore-upload@main
with:
api_key: ${{ secrets.DTZ_API_KEY }}
name: build.zip
expiration: P30D
Cela rend simple l’application de politiques de cycle de vie directement dans vos workflows de déploiement — en assurant que les artefacts temporaires ne s’accumulent pas indéfiniment.
Le stockage devrait être dynamique, pas statique.
En intégrant la conscience du cycle de vie dans votre architecture, vous réduisez le gaspillage cloud et adoptez un pattern de conception durable qui profite à la planète, à votre plateforme et à vos utilisateurs.
DTZ ObjectStore transforme ce principe en pratique — donnant à chaque objet une histoire, un but et, surtout, une fin.