Nous avons le plaisir de vous annoncer le lancement de la préversion du plan Premium Azure Functions, notre tout nouveau modèle d'hébergement de Functions !
Nous avons le plaisir de vous annoncer le lancement de la préversion du plan Premium Azure Functions, notre tout nouveau modèle d'hébergement de Functions ! Ce plan comprend une suite d'options de mise à l'échelle et de connectivité qui étaient très attendues, sans compromettre la mise à l'échelle basée sur les événements. Avec le plan Premium, vous pouvez utiliser des instances chauffées au préalable pour exécuter votre application sans délai après une période d'inactivité, vous pouvez exécuter des instances plus puissantes, et vous pouvez vous connecter à des réseaux virtuels, tout en procédant automatiquement à la mise à l'échelle en réponse au chargement.
Un grand merci à tous ceux qui ont participé à notre préversion privée ! Symantec Corporation et Volpara Solutions ne sont que quelques-unes des entreprises qui bénéficieront des nouvelles fonctionnalités du plan Premium.
Voir ci-dessous une comparaison de la façon dont le plan Premium améliore notre plan de mise à l'échelle dynamique existant, le plan Consommation.
La taille de l'instance peut maintenant être spécifiée avec le plan Premium. Vous pouvez sélectionner jusqu'à quatre cœurs de série D et 14 Go de mémoire. Ces instances sont nettement plus puissantes que celles de la série A accessibles aux fonctions qui utilisent le plan Consommation, ce qui vous permet d'exécuter beaucoup plus de charges de travail gourmandes en mémoire ou nécessitant un usage intensif du processeur dans le cadre d'appels individuels.
Désormais, le nombre maximal d'instances peut également être spécifié avec le plan Premium. Cette fonctionnalité était l'une des plus demandées. Elle vous permet de limiter la montée en charge maximale de votre plan Premium. Une restriction de la montée en charge maximale vous permet d'éviter que vos fonctions ne submergent les ressources situées en aval et de prévoir votre facture mensuelle maximale possible.
Le nombre minimal d'instances peut être spécifié dans le plan Premium pour vous permettre d'effectuer une mise à l'échelle préalable de votre application avant la demande prévue. Si vous craignez qu'une campagne par e-mail, une vente ou tout autre événement ponctuel n'entraîne une mise à l'échelle trop rapide pour reconstituer les instances chauffées au préalable, vous pouvez augmenter le nombre minimal d'instances afin de précharger la capacité.
Nous avons créé un exemple de fonction durable qui déplacera n'importe quelle fonction entre les plans Consommation et Premium avec des instances chauffées au préalable selon un calendrier, ce qui vous permettra de bénéficier d'une optimisation au meilleur coût.
Le plan Premium permet aux fonctions de mise à l'échelle dynamique de se connecter à un réseau virtuel et d'accéder en toute sécurité aux ressources d'un réseau privé. Auparavant, cette fonctionnalité n'était disponible qu'en exécutant Functions dans le cadre d'un plan App Service ou App Service Environment. Désormais, elle est disponible dans un modèle de mise à l'échelle dynamique à l'aide du plan Premium. Cliquez ici pour en savoir plus sur l'intégration d'un réseau virtuel.
Avec le plan Premium Azure Functions, nous proposons une solution permettant d'annuler le délai qui accompagne le premier appel d'une application serverless : les instances chauffées au préalable. Ce délai est généralement appelé « démarrage à froid », et il s'agit de l'un des problèmes les plus courants rencontrés par les développeurs serverless. Pour plus de détails sur le démarrage à froid et ses causes, reportez-vous au billet de blog « Comprendre le démarrage à froid serverless ».
Le plan Premium offre la possibilité de spécifier un certain nombre d'instances chauffées au préalable et de les maintenir au chaud avec votre code prêt à être exécuté. Lorsque votre application a besoin d'une mise à l'échelle, elle utilise d'abord une instance chauffée au préalable sans démarrage à froid. Votre application préchauffe immédiatement une autre instance en arrière-plan pour reconstituer la mémoire tampon des instances chauffées au préalable. Ce modèle vous permet d'éviter tout délai dans l'exécution de la première requête adressée à une application inactive, ainsi qu'à chaque point de mise à l'échelle.
Aujourd'hui, nous n'autorisons qu'une seule instance chauffée au préalable par site, mais nous prévoyons de relever ce nombre dans les semaines à venir.
Outre les solutions de contournement existantes, le maintien au chaud d'un pool d'instances chauffées au préalable constitue l'un des principaux avantages. Aujourd'hui, dans le cadre du plan Consommation, de nombreux développeurs contournent le démarrage à froid en implémentant un « émetteur de commandes ping » qui envoie constamment des commandes ping à leur application pour la maintenir au chaud. Cette solution fonctionne pour la première requête, mais les applications avec émetteur de commandes ping connaîtront toujours un démarrage à froid à mesure qu'elles monteront en charge, car les nouvelles instances extraites pour exécuter l'application ne seront pas prêtes à exécuter le code immédiatement. Nous conservons toujours le nombre d'instances chauffées au préalable que vous avez spécifié en mémoire tampon afin d'éviter tout délai lié au démarrage à froid à condition que le rythme de vos mises à l'échelle soit inférieur à celui nécessaire pour réchauffer les instances.
Essayez la préversion du plan Premium Azure Functions dès aujourd'hui ! Pour en savoir plus, suivez les conseils ci-dessous :
