IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

AWS annonce la prise en charge des images de conteneur, du jeu d'instruction AVX2
Et une tarification à la milliseconde

Le , par Bill Fassinou

32PARTAGES

9  0 
AWS a annoncé ce mardi l'ajout de nouvelles fonctionnalités à sa plateforme d'informatique sans serveurs Lambda. Les nouvelles fonctionnalités introduites par AWS Lambda comprennent la prise en charge du jeu d'instructions AVX2, la prise en charge des images de conteneur, et AWS Lambda est désormais en mesure de fournir des fonctions avec un stockage allant jusqu'à 10 Go de mémoire et 6 vCPU (processeurs virtuels), ce qui permettra aux développeurs de créer des fonctions plus gourmandes en calcul pour obtenir les ressources dont ils ont besoin.

AWS Lambda est une plateforme informatique sans serveur, pilotée par des événements, fournie par Amazon dans le cadre de son offre cloud Amazon Web Services. Il s'agit d'un service informatique qui exécute un code en réponse à des événements et gère automatiquement les ressources informatiques requises par ce code. Il a été introduit en novembre 2014. L'informatique sans serveur ne signifie pas qu'il n'y a pas de serveur. Cela signifie que les développeurs n'ont plus à se soucier des besoins en matière de calcul, de stockage et de mémoire, car le fournisseur de cloud, AWS dans ce cas, s'en occupe pour eux.

Cela permet aux développeurs de se contenter de coder l'application au lieu de déployer des ressources. L'objectif de AWS Lambda, par rapport à AWS EC2 (Elastic Compute Cloud), est de simplifier la construction d'applications à la demande plus petites, qui répondent aux événements et aux nouvelles informations. AWS vise à lancer une instance Lambda dans les millisecondes suivant un événement. Node.js, Python, Java, Go, Ruby, et C# (via le noyau .NET) sont tous officiellement pris en charge à partir de 2018.


Un support d'exécution personnalisé a ensuite été ajouté à AWS Lambda, donnant aux développeurs la possibilité d'exécuter un Lambda dans le langage de leur choix. AWS Lambda supporte l'exécution sécurisée d'exécutables Linux natifs en faisant appel à un runtime pris en charge, tel que Node.js. Par exemple, le code Haskell peut être exécuté en Lambda. Mardi, AWS a annoncé l'ajout de nouvelles fonctionnalités, dont en voici quelques-unes.

Prise en charge des images de conteneur (Container Image)

L'avantage de cette fonctionnalité est qu'elle permet aux utilisateurs en entreprise d'utiliser plus facilement un ensemble cohérent d'outils pour le balayage de sécurité, la signature de code, etc. Elle permet également de porter la taille maximale du package de code pour une fonction à 10 Go. Cette fonctionnalité brouille la frontière entre Lambda et les conteneurs et peut être source de confusion, il est donc prudent de commencer par comprendre ce que cette fonctionnalité est et n'est pas. Ainsi, notez que cette fonctionnalité n'est pas un remplacement pour AWS ECS (Amazon Elastic Container Service) ou AWS Fargate.

Vous ne pouvez pas exécuter de services de longue durée dans Lambda, votre code est toujours lié par le modèle d'appel de Lambda (c'est-à-dire qu'il ne s'exécute que lorsque la fonction est appelée). Les appels de fonction sont toujours liés par la même durée maximale de 15 minutes. En outre, votre image de conteneur doit interagir avec l'API Lambda Runtime pour demander des événements et envoyer des réponses, de la même manière qu'un runtime Lambda personnalisé. Cette nouvelle fonctionnalité vous permet d'expédier le contenu d'une fonction Lambda sous la forme d'une image de conteneur au lieu d'un fichier zip.

Il exécute aussi l'image de base telle quelle, vous pouvez donc utiliser votre image de base Linux préférée, comme Alpine ou Debian. Alors, comment ça fonctionne ? Vous pouvez utiliser l'une des nombreuses images de base fournies par AWS, qui comprend le système d'exploitation et tout ce dont il a besoin pour prendre en charge le modèle de programmation Lambda. Et comme les environnements d'exécution Lambda gérés, vous pouvez également trouver des bibliothèques supplémentaires, telles que le kit AWS SDK.

Vous pouvez également utiliser une image de base arbitraire. Si vous le faites, vous pouvez utiliser le client d'interface d'exécution AWS Lambda (RIC) open source pour rendre votre image de base compatible avec l'API d'exécution Lambda. Désormais, il est possible d'empaqueter des images de conteneur jusqu'à 10 Go, ce qui est nettement supérieur à la limite de 250 Mo sur la taille du package de déploiement. À l'instar d'un environnement d'exécution Lambda personnalisé, l'image du conteneur doit avoir un fichier d'amorçage qui interagit avec l'API Lambda Runtime pour demander des événements et envoyer des réponses.

« À partir d'aujourd'hui, vous pouvez allouer jusqu'à 10 Go de mémoire à une fonction Lambda. Cela représente une augmentation de plus de trois fois par rapport aux limites précédentes. La fonction Lambda alloue les ressources CPU et autres de manière linéaire, proportionnellement à la quantité de mémoire configurée. Cela signifie que vous pouvez désormais avoir accès à jusqu'à 6 vCPU dans chaque environnement d'exécution », a écrit la société dans un billet de blogue annonçant les nouvelles capacités d'AWS Lambda.

Vous pouvez spécifier l'emplacement du fichier d'amorçage à l'aide des paramètres "ENTRYPOINT" et "CMD" dans le fichier Docker. Vous pouvez également configurer le répertoire de travail à l'aide des paramètres "WORKDIR" et configurer les variables d'environnement avec le paramètre "ENV". Une fois que vous avez créé l'image Docker, vous devez déployer l'image sur Amazon Elastic Container Registry (ECR). En outre, vous devez donner au service Lambda les autorisations IAM (Identity and Access Management) nécessaires pour accéder au référentiel et obtenir l'image du conteneur.

Cycle de vie des fonctions, mises en garde et utilisation

Lorsqu'une fonction est déployée sur Lambda en tant qu'image de conteneur, elle doit d'abord subir un processus d'optimisation avant de pouvoir être appelée. Ce processus prend quelques secondes pendant lesquelles la fonction est dans un état "PENDING" et ne peut pas être appelée. Lorsque le processus d'optimisation est terminé, la fonction passe à l'état "ACTIF". Le processus de gel-dégel existant reste le même. En outre, si une fonction n'a pas été appelée pendant plus de 14 jours, le service Lambda peut récupérer la version optimisée de votre fonction et marquer la fonction comme "INACTIVE".

Lorsque cela se produit, le prochain appel échouera, mais il réactivera la fonction et elle subira à nouveau le processus d'optimisation, en passant par l'état intermédiaire "PENDING" avant d'être marquée comme "ACTIF", ce qui signifie qu'elle est à nouveau opérationnelle et peut gérer les demandes d'appel. Par ailleurs, le fait que les fonctions inactives peuvent devenir inopérantes (bien que pendant quelques secondes) après un certain temps d'inactivité est une mise en garde à laquelle il faut prêter attention. Cela est dû au fait que l'image du conteneur doit à nouveau être optimisée, car elle peut être exécutée par Lambda.

Actuellement, les fonctionnalités Lambda suivantes ne sont pas prises en charge pour les fonctions empaquetées sous forme d'images de conteneur :

  • les couches Lambda ne sont pas prises en charge ;
  • la signature de code n'est pas prise en charge ;
  • les fonctions ne sont pas automatiquement corrigées avec les mises à jour d'exécution ;
  • toutes les autres fonctionnalités et intégrations Lambda existantes continueront de fonctionner.



En ce qui concerne les cas d'utilisation, comme pour de nombreuses fonctionnalités récentes de Lambda, dont l'intégration d'EFS ou les extensions Lambda, la prise en charge des images de container est conçue pour traiter des points de douleur particuliers et présente ses propres complexités. AWS estime qu'il ne s'agit pas de quelque chose que tout le monde devrait utiliser. Mais pour certains clients, il peut lever les obstacles techniques et organisationnels à l'adoption de Lambda comme choix technologique. Par exemple, si vous devez inclure de très grandes dépendances qui ne sont pas autorisées par la limite de 250 Mo du package de déploiement.

Ou peut-être travaillez-vous dans une entreprise ou un environnement hautement réglementé où vous devez vous assurer que toutes vos applications répondent à une norme cohérente à des fins de sécurité et d'audit. Il est donc primordial que les équipes de sécurité et d'exploitation puissent utiliser un ensemble d'outils cohérent pour assurer la gouvernance et la surveillance des applications de l'ensemble de l'organisation. Dans ce cas, le fait de pouvoir utiliser les mêmes outils pour les charges de travail Lambda et celles basées sur les conteneurs fait de Lambda une plateforme viable.

Les autres nouveautés introduites par AWS Lambda

Outre la prise en charge des images de container, AWS a également annoncé mardi la prise en charge du jeu d'instructions AVX2 (Advanced Vector Extensions 2). En effet, AVX2 fournit des extensions à l'architecture du jeu d'instructions x86. Il s'agit d'un jeu d'instructions SIMD (Single Instruction Multiple Data) qui permet d'exécuter simultanément un ensemble d'opérations hautement parallèles. AVX2 permet aux CPU d'effectuer un nombre plus élevé d'opérations en nombres entiers et en virgule flottante par cycle d'horloge.

Pour les algorithmes vectorisables, cela peut améliorer les performances, ce qui se traduit par des latences plus faibles et un débit plus élevé. Selon AWS, ces nouvelles capacités d'AWS Lambda signifient que les développeurs disposent de plus de ressources pour travailler sur des technologies plus sophistiquées comme l'apprentissage automatique, les jeux et même le calcul haute performance. En outre grâce à la nouvelle forme de tarification, la tarification à la milliseconde, vous pouvez économiser de l'argent parce que vous ne payez pas pour des ressources que vous n'utilisez pas.

Vous payez seulement chaque fois que l'application nécessite un ensemble de ressources et pas plus. « À partir d'aujourd'hui, nous arrondissons la durée à la milliseconde près, sans temps d'exécution minimum », a annoncé AWS mardi à propos de la nouvelle approche de tarification. Toutes ces annonces combinées signifient que vous pouvez désormais utiliser les fonctions Lambda pour des opérations plus intensives qu'auparavant, et la nouvelle approche de facturation devrait réduire vos dépenses globales au fur et à mesure que vous faites la transition vers les nouvelles capacités.

Source : AWS Lambda

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi

Amazon Web Services veut séduire les développeurs avec Lambda pour l'exécution d'applications dans le Cloud et Aurora, un MySQL puissant

hAWS rejoint la Fondation .NET en tant que Corporate Sponsor, le géant du cloud veut davantage s'impliquer dans le futur de la plateforme de développement Microsoft

Amazon : « nous embauchons des ingénieurs en logiciels qui maîtrisent le langage de programmation Rust », AWS estime que Rust est un élément essentiel de sa stratégie à long terme

Amazon annonce la disponibilité de la préversion de Sumerian, un service pour développer des expériences 3D immersives et interactives

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 02/12/2020 à 15:17
C'est de la facturation au MIPS comme chez IBM , est-ce quelqu'un saurait dire si ça change beaucoup par rapport à la tarification "0,0000166667 USD pour chaque Go-seconde" ?
0  0