Sans serveur ou Kubernetes sur AWS

De nombreux clients AWS standardisent avec des technologies open source largement prises en charge. L'open source peut permettre à une organisation de trouver les bonnes compétences et d'éviter certains risques liés à l'enfermement. Faire les mauvais choix dans un écosystème open source peut conduire à se retrouver enfermé dans des abstractions et des intégrations locales. En outre, la responsabilité de faire fonctionner ensemble les différents composants open source incombe souvent à l'organisation qui fait le choix. Il est fréquent que les entreprises consacrent trop de temps à la maintenance des intégrations open source.

Remarques :

• Prenez en compte les sources communautaires et le soutien d'entreprises ou de fondations lorsque vous réalisez ces investissements. L'investissement dans ces projets n'est pas uniquement financier. Vous devez également investir dans la formation et l'éducation de votre équipe sur les technologies utilisées. 
• Vous pouvez également vous exposer à une certaine dette technique (en raison du travail nécessaire à la maintenance de ces intégrations), car ces composants et les intégrations associées doivent généralement être mis à jour.
  
• Consultez le blog AWS Open Source pour trouver des idées sur les implémentations open source.
  

Lorsque vous choisissez une stratégie de développement d'application moderne, il est important que votre stratégie s'adapte à divers modèles de charge de travail. Vous pouvez plus facilement faire des choix d'architecture en comprenant vos modèles de charge de travail. Par exemple, des applications web, des microservices basés sur des API, des applications basées sur des événements, de la diffusion en continu et de la messagerie, des pipelines de données, des automatisations informatiques, etc. Certaines charges de travail seront plus performantes ou plus rentables dans un environnement de calcul plutôt que dans un autre type.

Lors de la création avec les technologies sans serveur AWS, des services comme App Runner et AWS Batch sont conçus pour répondre facilement aux exigences d'un type de charge de travail donné. Les charges de travail utilisant cette approche seront plus faciles à créer, plus performantes ou plus rentables, même si cela se fait au détriment de la flexibilité.

Kubernetes assure la cohérence entre les environnements dans le cloud et sur site si votre organisation l'exige.

Les charges de travail ne fonctionnent pas de manière isolée. Les charges de travail sont prises en charge par des technologies telles que les bases de données, la messagerie, la diffusion en continu, l'orchestration et d'autres services. Une stratégie de développement d'application moderne efficace nécessite l'intégration à ces services. Les intégrations gérées simplifient les frais d'exploitation tout autant que la gestion de l'infrastructure sous-jacente.

Les options de technologie sans serveur AWS sont profondément intégrées à l'écosystème AWS. AWS Lambda peut s'abonner aux événements de plus de 200 autres services. Les extensions AWS Lambda, par exemple, permettent une intégration avec des outils de surveillance, d'observabilité, de sécurité et de gouvernance. Lambda invoque une fonction donnée dans un environnement d'exécution, ce qui fournit un environnement d'exécution sécurisé et isolé dans lequel le code de la fonction est exécuté. 

Les offres gérées par AWS pour Kubernetes fournissent des intégrations avec les offres gérées. Kubernetes dispose lui-même d'un riche écosystème de partenaires, offrant une intégration avec de nombreuses autres technologies.

De nombreux clients ont besoin de créer des expériences pour valider leurs idées. Ces prototypes peuvent être l'idée d'une nouvelle application, et/ou être abandonnés en cas d'échec. La capacité à fournir un environnement dans lequel vous pouvez rapidement écrire, déployer et valider des idées est essentielle pour un environnement sain. Cet environnement est souvent négligé lors de l'élaboration d'une stratégie de développement d'application moderne, mais la capacité d'innovation au sein de l'entreprise peut en dépendre. Permettre aux équipes d'utiliser des services permettant de créer, de tester et d'itérer rapidement est inestimable pour découvrir de nouvelles opportunités commerciales.

De nombreux clients souhaitent s'assurer que leurs applications peuvent s'exécuter dans un environnement différent et être facilement migrées ou déplacées vers celui-ci. Ils veulent pouvoir conserver leur choix de changer de fournisseur de cloud, ou d'exécuter une application à la fois sur site et dans le cloud. Cela inclut souvent la nécessité de prendre en charge des frameworks de langage et des scénarios de développement populaires. Par exemple, les développeurs Java peuvent souhaiter utiliser Spring ou Python, et les ingénieurs de données peuvent souhaiter utiliser PyTorch. Le choix d'une approche de développement d'application moderne ne suffira pas à lui seul. De bonnes pratiques et une architecture seront nécessaires pour garantir la portabilité des applications. Nous vous recommandons de développer vos compétences en matière d'architectures logicielles et de créer des empaquetages qui vous permettent de transférer plus facilement une logique métier différenciée entre les services de calcul.

Les applications créées à l'aide de certaines technologies peuvent s'exécuter plus efficacement sur certains services de calcul que sur d'autres. Les services de conteneurs constituent généralement une meilleure cible de migration pour les applications existantes que Lambda, qui nécessitera une modification de l'architecture.

Il doit y avoir une nette différence entre la portabilité des applications et celle de l'automatisation. La plupart du temps, le choix entre la technologie sans serveur AWS et AWS Kubernetes n'a en fait rien à voir avec le caractère portable ou non d'une application. Ce sont plutôt les outils utilisés par les équipes chargées de l'infrastructure et les équipes DevOps qui constituent un facteur clé. Les clients qui choisissent l'approche Kubernetes sur AWS recherchent souvent la portabilité de l'infrastructure et des outils de déploiement.

Les compétences de votre organisation représentent un facteur important lorsqu'il s'agit de décider d'adopter une approche sans serveur ou basée sur des conteneurs pour le développement d'applications modernes. Le sans serveur et les conteneurs nécessitent tous les deux d'investir dans les équipes DevOps et SRE (Site Reliability Engineer). La création d'un pipeline automatisé pour déployer des applications est courante dans la plupart des applications modernes.

Certains choix augmentent le niveau de gestion. Par exemple, certaines entreprises disposent des compétences et des ressources nécessaires pour exécuter et gérer une implémentation de Kubernetes, car elles investissent dans de robustes équipes SRE chargées de gérer les clusters Kubernetes. Ces équipes s'occupent des mises à niveau fréquentes des clusters (par exemple, Kubernetes publie trois versions majeures par an et rend obsolètes les anciennes versions).

La taille de l'organisation est un facteur clé, car les plus petites start-ups peuvent disposer d'un personnel informatique restreint composé de personnes occupant plusieurs rôles, tandis que les grandes entreprises peuvent prendre en charge des centaines de charges de travail en production à la fois.

Les décisions en matière d'architecture s'accompagnent de compromis, dont l'un est souvent le coût. Il est souvent difficile d'estimer le coût des applications modernes en raison de la nature dynamique des composants concernés. Bien que le coût d'un ensemble fixe de serveurs soit plus facile à estimer, vous payez également pour ces serveurs même s'ils n'apportent aucune valeur ajoutée à l'entreprise.

Les deux approches offrent de multiples leviers pour atteindre les objectifs de coûts pour vos charges de travail. Le choix de haut niveau entre les approches doit prendre en compte le coût non seulement des ressources, mais également des efforts nécessaires pour créer et maintenir cette stratégie. Le Calculateur de prix AWS peut être utile pour comprendre les coûts d'une charge de travail donnée.

La création à la fois avec la technologie sans serveur AWS et Kubernetes sur AWS vous permet de créer des charges de travail performantes, pouvant être mises à l'échelle et résilientes. Vous pouvez répondre aux exigences techniques dont vous avez besoin. Les services présentant les niveaux d'abstraction les plus élevés gèrent le placement dans les zones de disponibilité AWS et la mise à l'échelle de l'environnement, améliorant ainsi les performances et la résilience. Des niveaux d'abstraction plus faibles vous permettent de mieux contrôler la mise à l'échelle de votre charge de travail. Les principaux compromis sont les coûts et la complexité de la gestion.