Azure Cosmos DB devient sans serveur

Cosmos DB d'Azure est l'un des fondements de la plateforme, alimentant nombre de ses services clés. Conçu dès le départ comme une base de données distribuée, il implémente un ensemble de différents modèles de cohérence vous permettant de faire un compromis entre performances et latence pour vos applications. Ensuite, il y a ses différents modèles pour travailler avec des données, des API NoSQL et SQL familières, à la prise en charge de l'API de Mongo DB, en passant par le moteur de requête de base de données de graphes Gremlin.

Il y en a suffisamment dans Cosmos DB pour prendre en charge les scénarios de développement cloud les plus courants, vous offrant une plate-forme de données cohérente qui peut partager des données à l'échelle mondiale. Microsoft la décrit souvent comme une «base de données à l'échelle planétaire», une description appropriée.

L'alternative sans serveur au débit provisionné

Pour tous les avantages, Cosmos DB a quelques inconvénients; surtout son coût. Bien qu'il existe une option gratuite relativement limitée, son exécution à grande échelle peut être coûteuse, et vous devez en tenir compte lors de la création d'applications autour d'elle. La budgétisation des unités de demande Cosmos DB est un processus complexe difficile à réaliser du premier coup, en particulier lorsque vous prenez en compte la mise à l'échelle, manuellement ou automatiquement.

Microsoft a exécuté un aperçu d'une option sans serveur pour Cosmos DB depuis un certain temps maintenant, basée sur son API SQL principale. C'est une alternative intéressante à l'option provisionnée traditionnellement. Il ne vous facture que lorsqu'il exécute une requête et suspend votre instance lorsqu'il ne se passe rien. Il y aura une latence supplémentaire dans les opérations de base de données, car votre instance doit démarrer lorsqu'elle a été suspendue. Bien sûr, le stockage est facturé, mais c'est la même chose avec n'importe quelle base de données Azure. L'essai initial a maintenant été étendu à toutes les API Cosmos DB, avec une disponibilité générale pas trop loin dans le futur.

L'ajout d'une option sans serveur à Cosmos DB a beaucoup de sens pour de nombreux types de charges de travail où vous recevez des demandes en petit nombre et par lots. Pour une petite charge de travail avec un schéma d’opérations irrégulier, un modèle de tarification basé sur la consommation a beaucoup de sens et peut permettre d’économiser une somme considérable sur le long terme car il n’ya pas d’engagement sur le débit provisionné.

Les coûts sont faibles: vous payez 0,282 USD par unité de demande sans serveur, pour jusqu'à un million d'EUR dans un cycle de facturation. Si vous avez besoin d'un serveur plus fiable, vous pouvez configurer une zone de disponibilité, bien que cela augmente les coûts de 1,25x. C'est toujours un accord raisonnable, et ce que vous perdez en prévisibilité, vous gagnez en coûts inférieurs. Les coûts de stockage restent les mêmes pour le débit provisionné manuel et automatique.

Premiers pas avec Cosmos DB sans serveur

Sauter est assez facile. Comme pour un compte Cosmos DB standard, vous devrez le provisionner dans un abonnement et ajouter votre instance sans serveur à un groupe de ressources. Ensuite, choisissez l'API que vous prévoyez d'utiliser pour les requêtes, et lorsqu'on vous demande de choisir un mode de capacité, choisissez le débit sans serveur plutôt que provisionné. Enfin, liez-le à une région, en vous rappelant que vous ne pouvez utiliser sans serveur que dans une seule région Azure; il n'y a pas d'option pour la géo-redondance. Vous ne pourrez pas non plus l'utiliser avec l'offre gratuite.

Une fois que votre instance sans serveur est en cours d'exécution, vous pouvez utiliser ses API pour charger des données et effectuer des requêtes. Comme une instance standard de Cosmos DB, vous pouvez créer des fonctions et des déclencheurs JavaScript qui s'exécutent à l'intérieur de la base de données, ainsi qu'utiliser ses nombreuses API différentes pour gérer les requêtes.

Serverless Cosmos DB devrait bientôt sortir de la préversion et ajoute la prise en charge de toutes ses API, même pour sa récente API Cassandra. Comme il s'agit d'un aperçu public, vous pouvez le configurer et explorer son fonctionnement directement à partir du portail Azure. En préversion, il n'y a pas de prise en charge d'ARM ou d'autres infrastructures en tant qu'outils de déploiement de code, bien qu'il devrait y en avoir une fois que le service est généralement disponible. Vous ne pouvez pas automatiser la configuration et le déploiement, vous ne pourrez donc pas l'utiliser dans le cadre d'un pipeline CI / CD (intégration continue / livraison continue) pour le moment, car les déploiements devront être manuels.

Code de construction avec Cosmos DB sans serveur

Un endroit où vous devriez obtenir beaucoup de valeur de Cosmos DB sans serveur est en parallèle avec Azure Functions. Les deux environnements sans serveur fonctionnent bien ensemble et sont parfaits pour les applications en rafale, à faible volume et basées sur les événements. Cosmos DB sans serveur peut rapidement passer de zéro à 5000 unités de demande par seconde, donc si vous écrivez du code qui utilise des fonctions pour suivre les conditions d'erreur ou d'autres alertes, c'est une option pour collecter et stocker rapidement des données.

Microsoft recommande de l'utiliser dans le cadre d'un environnement de développement dans lequel vous capturez des données sur les demandes dont votre application à grande échelle a besoin. Étant donné que l'approvisionnement des unités de demandes est une sorte d'art noir, une implémentation sans serveur fonctionnant avec tout votre code de base de données est un outil de développement utile. Vous pouvez configurer un environnement opérationnel, exécuter vos tests, capturer le nombre de demandes utilisées, puis utiliser ces données pour provisionner le débit d'un déploiement de production.

Comprendre les limitations sans serveur

Il existe des limitations à l'utilisation d'un compte Cosmos DB sans serveur. Le plus important est peut-être que vous n'avez pas accès aux déploiements multirégionaux, car les comptes sans serveur ne fonctionnent que dans une seule région. C'est une limitation qui a du sens: les implémentations Cosmos DB multirégion ont besoin de plusieurs instances s'exécutant en même temps pour la réplication et la cohérence interrégionales. Si les instances sans serveur ne s'exécutent que lorsqu'elles traitent des demandes, il n'y a aucune garantie qu'une autre région sera en ligne pour gérer la réplication. Par conséquent, des modifications ont été apportées à l'objectif de niveau de service Cosmos DB pour les instances sans serveur, avec des écritures de 30 ms ou moins et des lectures de 10 ms ou moins.

L'autre limitation clé est un maximum de 5 000 unités de demande par seconde. Encore une fois, cela devrait être suffisant pour la plupart des implémentations simples ou de développement, mais cela vous oblige à garder un œil sur vos applications et à être prêt à passer à une instance Cosmos DB provisionnée si vous dépassez régulièrement vos limites. Dans le même temps, chaque conteneur sans serveur ne peut stocker que 50 Go de données et d'index. Microsoft fournit des outils dans le portail Azure pour aider à surveiller les opérations, ainsi que dans Azure Monitor.

L'ajout d'une option sans serveur à Cosmos DB répond à de nombreuses questions sur le coût. Pour les scénarios à faible utilisation où vous n'avez pas besoin d'une couverture mondiale, cela devrait être votre premier choix. Passez à l'utilisation d'une instance de débit provisionné uniquement lorsque vous êtes en mesure de comprendre le modèle de demande de votre application et de budgétiser en conséquence.