La seule différence qui détermine votre migration
Azure Blob Storage a sa propre API, avec ses propres SDK, sa propre authentification et ses propres concepts — des conteneurs plutôt que des buckets, des blobs plutôt que des objets. Notre stockage d'objets parle l'API S3, qui est l'interface que presque tous les autres outils de l'écosystème implémentent déjà.
C'est le vrai travail dans une migration, et cela vaut la peine d'être direct à ce sujet : si votre application parle à Blob via le SDK Azure, vous changerez cette couche. Si elle parle à Blob via une couche de compatibilité, ou si vous êtes encore en train de choisir, vous choisissez simplement l'interface qui a le plus d'outillage autour d'elle — aws-cli, mc, rclone, boto3, s3cmd et tous les outils de sauvegarde qui ont un jour développé une cible S3.
Tout le reste — attentes de durabilité, objets publics ou privés, habitudes de cycle de vie — se transpose conceptuellement. L'API est la décision.
L'endroit où se trouvent les données est votre choix
Azure vous demande de choisir une région, et selon celle que vous choisissez, les données peuvent se retrouver hors de la juridiction qui importe à votre équipe juridique. La question est la même ici, et la réponse aussi : vous choisissez le pays ou la région où vos données sont stockées. Nous exploitons des nœuds de stockage en Turquie, en Europe et aux États-Unis, et vos buckets sont placés là où vous en avez besoin plutôt que là où se trouvait par hasard notre premier datacentre.
Ce choix tend à être motivé par deux besoins différents, qui tirent dans des directions opposées. La conformité veut les données dans une juridiction spécifique — pour une entreprise turque qui répond au KVKK, « en Turquie » est une réponse bien plus courte qu'un paragraphe sur les mécanismes de transfert. La latence veut les données près des personnes qui les lisent. Vous n'avez pas à résoudre les deux dans la couche de stockage : placez les objets là où la conformité l'exige, puis laissez le CDN servir les objets publics depuis la périphérie la plus proche du visiteur.
Si vous avez une exigence de juridiction, dites-le-nous avant de commencer à téléverser — placer un bucket dans la bonne région dès le premier jour ne coûte rien, et déplacer des téraoctets plus tard n'est pas gratuit.
Un CDN devant le bucket, depuis le même panneau
Sur Azure, le compte de stockage et le profil CDN sont des produits séparés que vous reliez vous-même. Ici, le bucket et le CDN sont le même compte : vous pointez un nom d'hôte vers le bucket, définissez des règles de cache pour les chemins qui le méritent, et vous purgez exactement comme vous purgeriez n'importe quelle autre origine — depuis le panneau, l'API ou la CLI.
Cela compte surtout pour les cas ennuyeux. Une image produit qui change se purge par chemin. Un dossier entier se purge par préfixe. La clé de cache est la même que celle que vos règles de diffusion définissent déjà, donc il n'y a pas de second modèle mental pour « le CDN de stockage ».
Une tarification que vous pouvez lire sans calculatrice
Les factures de stockage cloud ont tendance à arriver en morceaux : le stockage, puis la sortie de données, puis les opérations, puis une ligne séparée pour le CDN devant. Les morceaux sont individuellement petits et collectivement surprenants.
Ici, le stockage et la diffusion puisent dans un seul pool mensuel — le trafic que vous servez et le stockage que vous occupez sont comptés ensemble contre le forfait que vous avez acheté, et le prix est en livre turque sur une facture turque. Nous n'allons pas publier de tableau comparatif avec les tarifs actuels d'Azure, car ces tarifs changent et un tableau obsolète sur une page de fournisseur est pire que pas de tableau du tout. Vérifiez votre propre facture Azure du mois, puis regardez la page des forfaits ici ; cette comparaison est la seule qui vaille la peine d'être crue.
Ce qu'Azure a que nous n'avons pas
Une page de comparaison honnête doit inclure cette partie.
Azure vous donne des dizaines de régions dans le monde, pas nous ; nous offrons du stockage en Turquie, en Europe et aux États-Unis, ce qui couvre la plupart des besoins, mais pas tous. Azure a des niveaux archive et cool avec leur propre économie ; notre stockage est à un seul niveau. Azure se trouve à l'intérieur d'un écosystème où le stockage blob est une brique de base pour des dizaines d'autres services Azure ; si votre architecture s'appuie dessus, partir signifie détricoter bien plus que du stockage.
Les raisons de migrer sont spécifiques plutôt qu'universelles : vous voulez l'API S3, vous voulez choisir la juridiction et obtenir une facture turque pour cela, vous voulez le CDN et le bucket gérés ensemble, et vous n'avez pas besoin de l'écosystème environnant. Si ce n'est pas votre cas, rester sur Azure est une réponse raisonnable, et nous préférons vous le dire plutôt que de vous vendre une migration.
FAQ alternative à Azure Blob
Votre stockage est-il compatible avec l'API Azure Blob ?
Non, et aucun fournisseur compatible S3 ne l'est. Blob a sa propre API. La nôtre implémente l'API S3, donc le travail de migration se situe dans la couche de votre application qui parle au stockage. Les outils qui parlent déjà S3 — aws-cli, rclone, mc, boto3 — fonctionnent sans changement.
Comment déplacer les données existantes ?
rclone est le chemin habituel : il parle à la fois Azure Blob et S3, donc une seule tâche de copie déplace un conteneur dans un bucket. Pour de gros volumes, exécutez-le depuis une machine ayant une bonne connectivité vers les deux extrémités et vérifiez ensuite avec une passe de contrôle par checksum.
Puis-je garder mon domaine sur les fichiers ?
Oui. Pointez un nom d'hôte vers le bucket via le CDN, et les URLs publiques restent sur votre propre domaine avec SSL automatique, plutôt que sur un domaine de stockage appartenant au fournisseur.
Où les données sont-elles stockées, physiquement ?
Là où vous le choisissez. Nous avons du stockage en Turquie, en Europe et aux États-Unis, et un bucket est placé dans la région que vous demandez. Pour une entreprise turque, cela signifie généralement la Turquie, car cela transforme une question KVKK en un lieu plutôt qu'en une explication — mais si vos utilisateurs ou vos auditeurs sont ailleurs, dites-le lors de la création du compte.
Qu'en est-il des coûts de sortie de données ?
Le trafic que vous servez compte dans le même pool mensuel que le reste de votre diffusion, plutôt que d'arriver comme une ligne de sortie séparée. Si la plupart de vos objets sont publics et mis en cache en périphérie, la récupération depuis l'origine n'a lieu qu'une fois, et le trafic répété est servi depuis la périphérie.