Meilleures Alternatives Elastic Beanstalk Pour Les Startups En 2022

Les développeurs des startups sont presque toujours confrontés à la question de la manière la plus rentable d'obtenir les avantages du cloud sans avoir à gérer les systèmes sous-jacents. Il y a des années, lorsque nous construisions encore des monolithes et utilisions des instances EC2 , Elastic Beanstalk (ou Google App Engine et Azure App Service) était un choix tentant pour les jeunes startups cherchant à se déployer rapidement.

Même alors, Elastic Beanstalk (EB) ne convenait qu'aux applications non critiques qui nécessitaient une configuration et des déploiements standard. (Voici quelques témoignages de vrais développeurs qui se brûlent les mains avec EB). En outre, Elastic Beanstalk n'a pas connu de mise à jour majeure depuis un certain temps , alors devriez-vous l'utiliser même pour des applications non critiques ? Quelles sont les alternatives modernes à Elastic Beanstalk en 2022 ?

Une grande partie des informations existantes sur les alternatives d'EB répertorie également les PaaS hérités d'autres fournisseurs de cloud ou se comparent à Heroku, qui stagne. Et ils évaluent rarement les alternatives du point de vue des startups avec une équipe maigre ou pas d'équipe opérationnelle du tout. Cet article tente de répertorier et de comparer les options d'Elastic Beanstalk en 2022. Il vous sera utile si :

• Vous êtes une startup en pleine croissance qui a besoin de créer et de mettre à l'échelle des applications critiques. Des aspects tels que le temps de déploiement, la latence et le dépannage sont vitaux pour vous.
• Vous avez actuellement assemblé manuellement votre infrastructure et vos processus. Et vous évaluez quel PaaS vous convient le mieux.
• Vous utilisez déjà EB, mais vous souhaitez en migrer car maintenant, à mesure que vous évoluez, les limites d'EB vous nuisent : déploiements instables et lents et manque de transparence concernant les échecs et les mises à jour, pour n'en nommer que quelques-uns.
• Vous souhaitez que vos applications fonctionnent sans embaucher une équipe d'exploitation ou avec seulement une équipe d'exploitation allégée.

Maintenant, nous réalisons que la lecture de cet article ne vous aidera pas à affiner le PaaS pour votre startup - car on ne peut décider qu'après avoir pris en compte les nuances de son cas d'utilisation, les compétences de l'équipe et les coûts associés. Cependant, nous espérons que ce blog vous aidera à naviguer à travers les différentes technologies qui peuvent vous aider à résoudre votre problème en pleine croissance.

Des alternatives qui ne font pas la coupe

Par conséquent, cet article ne reconnaît pas les éléments suivants comme des alternatives pratiques à l'EB :

• Heroku : Malgré son expérience de développeur inégalée, nous ne recommandons plus de démarrer sur Heroku car il est souvent beaucoup plus cher à grande échelle que toute autre alternative, et il n'a pas publié de mises à jour notables depuis de nombreuses années. Par exemple, il ne prend toujours pas en charge HTTP/2 .
• IaaS : IaaS vous oblige à configurer vous-même vos serveurs, à spécifier des règles de mise en réseau, à gérer l'autoscaling, les mises à jour de sécurité, etc. Bien que cette méthode vous donne plus de contrôle et de flexibilité qu'un PaaS comme Elastic Beanstalk, cela a un coût considérable d'embaucher une grande équipe d'opérations spécialisées.
• FaaS : Faas convient à l'exécution de tâches asynchrones et d'applications événementielles telles que RESTful. Et dans bon nombre de ces cas d'utilisation, le FaaS est un spin-off de votre application principale, et non celle de base. Pour les cas d'utilisation compatibles FaaS, il peut également s'agir de votre application principale lorsque vous démarrez et que vous rencontrez des pics de trafic incohérents. Mais cet article s'adresse aux startups avec des cas d'utilisation beaucoup plus larges que ceux adaptés au FaaS.

Passons aux alternatives.

PaaS entièrement géré sur les clouds publics

Il existe 2 solutions PaaS, chacune proposée par les deux principaux fournisseurs de cloud : Google et Microsoft, qui sont presque équivalentes à Elastic Beanstalk :

• App Engine de Google
• Service d'application d'Azure

Le principal avantage de l'utilisation de l'offre PaaS de n'importe quel fournisseur de cloud, qu'il s'agisse d'Elastic Beanstalk, d'App Engine ou d'App Service, est un délai de mise sur le marché plus rapide en éliminant les frais généraux liés à la gestion des détails de déploiement, de provisionnement de capacité, d'équilibrage de charge, de sécurité, de mise à l'échelle et surveillance de la santé des applications.

Alors, comment les évaluez-vous les uns par rapport aux autres ?

Google App Engine

Bien qu'il soit aussi riche en fonctionnalités et testé au combat, Google lui-même considère maintenant App Engine comme un produit hérité . Nous l'avons inclus comme alternative parce que certains d'entre vous nous ont peut-être demandé pourquoi si nous ne l'avions pas fait. Aujourd'hui, Google lui-même recommande aux développeurs d'App Engine de passer au Cloud Run plus moderne , le service frère d'App Engine. (Plus d'informations plus tard)

Service d'applications Azure

Si votre application utilise des technologies Microsoft telles que .NET, il est simplement plus facile d'exécuter votre application sur App Service que sur EB ou App Engine. Mais encore une fois, comme Elastic Beanstalk et App Engine, il s'agit d'un PaaS hérité. Vous feriez mieux d'évaluer les offres PaaS plus modernes de Microsoft.

Notre recommandation

Elastic Beanstalk, App Engine et App Service sont tous les mieux adaptés pour exécuter des applications Web simples ou des backends d'applications mobiles sur une plate-forme sans serveur. Ce sont également des offres héritées. Bien qu'ils reçoivent des mises à jour régulières, peu de fonctionnalités notables leur ont été ajoutées au cours des dernières années. Que vous cherchiez à choisir votre premier PaaS ou une alternative à une configuration Elastic Beanstalk existante, nous vous recommandons fortement de continuer à lire pour en savoir plus sur les options modernes entièrement gérées et sans serveur qui sont également évolutives.

Cependant, si vous pensez toujours qu'un de ces PaaS est juste suffisant pour votre cas d'utilisation et que vous souhaitez en choisir un, voici ce que nous avons à dire. Les fonctionnalités ou l'implémentation sous-jacente décideront rarement de celle que vous choisirez, car vous pouvez accomplir n'importe quel cas d'utilisation avec n'importe laquelle d'entre elles (avec ou sans solutions de contournement). Il y aurait donc deux façons de penser à votre décision :

• Si vous utilisez déjà Elastic Beanstalk d'AWS, migrer vers un autre cloud (mais pas inconnu) uniquement pour leur PaaS (App Engine ou App Service) serait rarement un choix idéal, à moins que l'expertise de votre équipe ne soit maintenant avec un autre fournisseur de cloud, ou qu'il n'y ait une différence de coût significative dans l'utilisation des fonctionnalités qui vous intéressent.
• Si vous choisissez votre premier PaaS, effectuez une analyse coûts-avantages des services que vous souhaitez exécuter, de la manière dont ils interagiront et de l'expérience de votre équipe avec ce fournisseur de cloud spécifique.

Remarque : d'autres petits fournisseurs de cloud comme DigitalOcean offrent des services similaires avec un support client probablement bien meilleur et à moindre coût, mais l'étendue des cas d'utilisation que vous pouvez gérer avec eux est limitée par rapport au PaaS d'autres fournisseurs de cloud.

Passons aux alternatives modernes .

PaaS sur Cloud Privé

Une classe d'offres PaaS récentes telles que Fly , Render et Railway a vu le jour pour combler le vide créé par un Heroku stagnant et le paysage de plus en plus complexe des offres des fournisseurs de cloud public.

Fly vs Render vs Railway

Bien que Render, Fly et Railway soient souvent opposés lors de la recherche d'une expérience de type Heroku, ils ne sont pas presque équivalents. Alors d'abord, comparons-les entre eux:

• Le rendu est beaucoup plus semblable à Heroku, c'est-à-dire raffiné dans son expérience de développeur et ses capacités telles que la documentation, les tableaux de bord, la CLI, etc., que Fly ou Railway.
• Render prend en charge beaucoup moins de régions que Fly . Il n'y a aucune information sur les régions prises en charge par Railway.
• La tarification de Fly and Render est complexe. Agréablement, la tarification de Railway est basée sur l'utilisation avec un niveau gratuit généreux.
• (À partir de maintenant) Fly et Render fournissent Postgres entièrement géré. Railway prend en charge l'intégration sans configuration avec Postgres et quelques autres bases de données, mais aucune de ces intégrations n'est entièrement gérée.
• Aucune des files d'attente de support Fly, Render ou Railway. Ils ne conviennent donc pas aux cas d'utilisation nécessitant ces fonctionnalités.
• Render et Railway prennent en charge Monorepos ; Fly ne le fait pas.

Notre recommandation

Si vous utilisez déjà Elastic Beanstalk et que vous envisagez de migrer pour plus de flexibilité ou pour gérer plus d'échelle, aucun de Fly, Render ou Railway ne vous convient. En fait, ils pourraient être plus limitatifs.

Mais si vous cherchez votre premier PaaS, vous devez savoir ce qui suit :

• Fly est optimisé pour les applications Edge comme aucun autre PaaS et est un concurrent de premier plan si vous créez une telle application.
• (Pour l'instant) Fly, Render ou Railyway conviennent parfaitement à des cas d'utilisation tels que l'exécution d'un site Web statique, la création d'une application CRUD simple ou une application qui ne nécessite pas de base de données (en supposant que votre environnement d'exécution est pris en charge).
• Comme ils prennent tous en charge les images Docker, votre verrouillage est assez limité à leurs fonctionnalités propriétaires. Ainsi, le verrouillage ne devrait pas être une préoccupation lors de leur évaluation.
• À moins que vous ne cherchiez à utiliser les fonctionnalités Fly uniquement, Render and Railway est plus convivial pour les développeurs et pourrait être plus évolutif.
• La tarification simple de Railway justifie de l'essayer avant tout le monde.

PaaS natif de conteneur sur les clouds publics

Le PaaS natif de conteneur est un service sans serveur entièrement géré pour déployer des applications et des API conteneurisées.

Comme pour l'ancien PaaS, vous pouvez fournir le code source ou une image de conteneur. Ils s'occupent du déploiement, des mises à niveau, de l'équilibrage de charge, de la mise à l'échelle, de la sécurité, etc., afin que vous puissiez vous concentrer sur la création de valeur commerciale.

Mais contrairement aux PaaS hérités , ils sont optimisés pour créer et héberger non seulement des applications Web et mobiles, mais également des API, des microservices, des processus de longue durée, des tâches en arrière-plan et des applications pilotées par des événements.

Il existe trois PaaS entièrement gérés natifs de conteneurs remarquables sur les clouds publics : Google Cloud Run (généralement disponible à partir de novembre 2019), AWS App Runner ( lancé en mai 2021 ) et Azure Container Apps (généralement disponible — mai 2022).

Cloud Run contre App Runner contre applications de conteneur

• Bien qu'ils puissent tous être déployés à partir d'images de conteneur et de code source, ils ont chacun des contraintes différentes sur le type d'images, les référentiels de code source et les runtimes de langage pris en charge.
• Cloud Run prend en charge plus de langues que Container Apps et App Runner .
• Cloud Run et les applications de conteneur sont compatibles avec HTTP/2, WebSockets et gRPC, mais pas App Runner .
• Cloud Run et Container Apps prennent en charge la mise à l'échelle jusqu'à 0, contrairement à App Runner .
• La prise en charge des tâches en arrière-plan n'est pas idéale dans App Runner et Cloud Run , mais Container Apps prétend les prendre en charge.
• Cloud Run prend en charge les déploiements bleu/vert, Canary et progressifs. Les applications de conteneur ne prennent en charge que les déploiements bleu/vert et Canary . Mais App Runner ne prend en charge aucun de ces éléments.
• Les applications de conteneur prennent en charge plusieurs conteneurs dans un seul service, contrairement à Cloud Run et App Runner.
• Verrouillage
• Pratiquement aucun verrouillage Cloud Run : il est basé sur KNative, qui est open source. Cloud Run n'est qu'une couche au-dessus de KNative, qui est open source. Ainsi, vous pouvez déployer votre conteneur dans n'importe quel cluster K8S à l'aide de définitions KNative.
• Application conteneur : votre seul investissement consiste à créer l'image du conteneur, puis à exécuter quelques commandes pour la déployer. De plus, il est alimenté par Kubernetes, qui est open source. Donc, si vous choisissez de migrer, vous pourrez le faire relativement facilement.
• App Runner : il fonctionne sur ECS Fargate, qui est une offre AWS propriétaire, mais votre investissement se limite à fournir l'image du conteneur pendant qu'il s'occupe du reste (étant un PaaS). Il y a donc peu d'efforts perdus si vous choisissez de migrer.
• L'autoscaling dans Cloud Run est prêt à l'emploi, sans que vous ayez à spécifier de règle, en fonction de son comportement par défaut consistant à créer une instance dupliquée toutes les 100 requêtes simultanées. Cependant, App Runner et Container Apps vous obligent à spécifier des règles de mise à l'échelle automatique.

Notre recommandation

• Chaque App Runner, Container Apps, Cloud Run, Fly et Render sont des PaaS relativement nouveaux et n'ont donc pas été testés au combat.
• Bien qu'ils soient tous relativement nouveaux, Fly et Render seront inévitablement plus restrictifs que leurs homologues de cloud public natifs de conteneurs, car les clouds publics disposent d'un ensemble complet d'offres que vous pouvez utiliser pour résoudre à peu près n'importe quel cas d'utilisation. Ce n'est peut-être pas une bonne façon de le résoudre, mais cela ne vous bloquera pas. Au contraire, une fois que vous avez atteint un mur avec leurs capacités avec Fly ou Render, vous devez migrer hors d'eux.
• Si vous recherchez votre premier PaaS, ils doivent tous être évalués en fonction de votre cas d'utilisation et des compétences de votre équipe.
• Cependant, si vous cherchez à migrer d'Elastic Beanstalk pour plus de flexibilité à grande échelle, évaluez App Runner et le CaaS d'AWS (plus à ce sujet plus tard) .

Conteneurs en tant que service (CaaS) sur les clouds publics

Toutes les options PaaS ci-dessus vous permettent de développer et de déployer des applications sans avoir à créer, gérer et entretenir une infrastructure. Le PaaS natif de conteneur est presque identique au CaaS, sauf que dans certains cas, comme nous le verrons, le CaaS offre plus de contrôle.

Cette abstraction du PaaS natif de conteneur fonctionne parfaitement au début pour la plupart des startups, mais si à un moment donné vous avez besoin de plus de contrôle, vous devrez évaluer la seule autre offre CaaS notable : ECS. Jetons un coup d'œil à certains de ses avantages et inconvénients notables :

AWS ECS (avec ou sans Fargate)

• Nécessite l'assemblage de dizaines de pièces avant de pouvoir déployer quoi que ce soit dessus. Ainsi, l'expérience utilisateur est désagréable.
• La configuration de la mise à l'échelle automatique sur ECS est compliquée (comme le reste de l'expérience d'utilisation).
• Est entièrement propriétaire et vous oblige à vous fier entièrement à AWS ; le nombre de ressources que vous devez créer et le format d'écriture des définitions d'application garantissent que nous sommes enfermés dans AWS. Il vous sera extrêmement difficile de déménager si vous le choisissez. Mais encore une fois, le verrouillage doit être évalué par rapport à ce qu'il vous facilite.
• Sa nature exclusive a également conduit à son manque de soutien communautaire.

Remarque : Nous n'avons pas inclus Azure Container Instances (ACI) comme alternative, car il ne prend pas en charge la mise à l'échelle automatique horizontale. La mise à l'échelle verticale est également purement manuelle. Tout ce que vous pouvez faire est d'exécuter des instances uniques isolées les unes des autres. Par conséquent, ACI ne peut être utilisé en production pour aucune application à moins qu'une seule instance de l'application soit suffisante dans votre cas d'utilisation.

Notre recommandation

• Quel que soit votre cas d'utilisation, ignorez complètement ACI.
• Si vous êtes déjà sur AWS et que votre cas d'utilisation n'est pas adapté à Kubernetes, évaluez ECS par rapport à App Runner pour l'exécution de conteneurs gérés.
• ECS offre plus de flexibilité par rapport à App Runner au prix de plus de travail administratif de votre part. Par exemple, il peut exécuter plusieurs conteneurs dans un seul service alors que App Runner ne le peut pas.
• L'expérience de développeur médiocre d'ECS nécessite un temps de configuration important. Vous devez être préparé mentalement à cela.
• Si votre objectif est d'embaucher zéro ops, ECS n'est pas recommandé.
• Si AWS n'est pas une contrainte, Cloud Run est le plus convivial pour les développeurs pour le déploiement d'applications conteneurisées. Il est livré avec le moins de verrouillage et constitue le moyen le plus pratique d'exécuter des conteneurs sans serveur et gérés. Nous vous recommandons vivement de l'évaluer.

Kubernetes en tant que service (KaaS) ou Kubernetes géré

Logiquement, CaaS serait la prochaine étape si l'on voulait migrer hors d'un PaaS pour plus de flexibilité et d'évolutivité. Mais certains cas d'utilisation justifient également la prise en compte de Kubernetes. KaaS ou Managed Kubernetes Services, tels que GKE , EKS et AKS , suppriment la gestion du plan de contrôle et sont donc plus faciles à utiliser que d'utiliser Kubernetes directement.

Mais que devez-vous savoir à ce sujet pour pouvoir prendre une décision plus éclairée ?

• Kubernetes est un système d'orchestration de conteneurs open source. CaaS, comme ECS, dispose d'un système d'orchestration de conteneurs propriétaire - leur principal inconvénient par rapport à Kubernetes. (Cependant, Cloud Run et Azure Container Apps n'en souffrent pas car Kubernetes les alimente)
• La grande chose à propos de KaaS est qu'il s'agit de Kubernetes - qui est open source, bénéficie d'un soutien communautaire considérable et d'un écosystème croissant d'outils pour résoudre les cas d'utilisation courants - il y a donc un verrouillage minimal et une évolutivité infinie.
• Bien que KaaS simplifie la gestion du plan de contrôle, il vous laisse toujours l'administration des nœuds de travail, tels que les mises à niveau et la mise en réseau. Ces énormes frais généraux nécessitent une équipe dédiée avec des connaissances spécialisées sur Kubernetes.

Notre recommandation

• Évaluez si Kubernetes est requis pour votre cas d'utilisation ou si les conteneurs fonctionnent parfaitement pour vous (via PaaS ou CaaS natif de conteneur).
• Si vous décidez d'aller de l'avant avec Kubernetes, évaluez si vous avez l'équipe pour exploiter KaaS comme GKE, EKS et AKS.
• En général, GKE est le KaaS le plus mature à ce jour, et c'est aussi ce que nous recommandons.

Si vous n'avez pas le temps et les ressources à consacrer à KaaS aujourd'hui, mais que vous décidez de suivre la voie Kubernetes, il existe peut-être un juste milieu entre KaaS, CaaS et PaaS.

 

Un juste milieu entre PaaS, CaaS et KaaS

Un terrain d'entente entre PaaS, CaaS et Kaas reprendrait les meilleures caractéristiques de chacun d'eux et n'aurait pas leurs limites respectives.

• Contrairement à KaaS ou CaaS, et précisément comme PaaS, il sera entièrement géré et sans serveur.
• Contrairement au CaaS ou au PaaS propriétaire, il est basé sur un outil open source tel que Kubernetes.
• Cela ne vous lie pas à un fournisseur de cloud spécifique ou à ses outils.
• Cela vous donne la possibilité d'intégrer et de tirer parti du vaste écosystème d'outils tiers pour la journalisation, la surveillance, le stockage, etc.

Chez Argonaut , nous essayons de construire une telle plateforme. Argonaut est une couche d'orchestration (abstraction) au-dessus de votre compte cloud. En d'autres termes, il gère votre compte cloud.

• C'est entièrement géré
• C'est natif du conteneur
• Il dispose d'une prise en charge native pour travailler avec KaaS ou Kubernetes gérés comme EKS (prise en charge de GKE à venir dans quelques semaines) et FaaS comme AWS Lambda (prise en charge de Cloud Functions à venir).
• Vous pouvez exécuter n'importe quel diagramme de barre sur les applications déployées avec Argonaut.
• Il dispose d'un écosystème en expansion de modules complémentaires tiers, que ce soit pour la surveillance, la journalisation, la recherche, etc. Les exemples incluent Datadog , Prometheus , ELK , etc.

De conclure

Lorsque vous passez à une nouvelle façon d'exploiter l'infrastructure à l'aide d'un PaaS ou d'un CaaS, une bonne règle d'or consiste à utiliser le niveau d'abstraction le plus élevé qui résoudra votre problème sans imposer de limitations inutiles à la charge de travail. Si vous êtes un ops-noobs ou un ingénieur d'application, nous vous recommandons ce qui suit :

• Commencez avec un PaaS natif de conteneur et passez lentement à un CaaS ou KaaS opiniâtre. Cela vous aide à démarrer rapidement, à amorcer vos connaissances, à réduire les obstacles à l'adoption de technologies optimales et à apprendre les bonnes pratiques grâce aux valeurs par défaut intégrées.
• Au fil du temps, à mesure que vos connaissances augmentent, vous pouvez commencer à jouer avec les paramètres par défaut ou même utiliser directement la technologie native.

Notes de bas de page

1. La tarification d'Heroku est par dyno, c'est-à-dire les conteneurs qu'Heroku utilise pour s'exécuter sur EC2 au niveau du backend. Étant donné que Heroku n'exploite pas la pile d'infrastructure sous-jacente (sur AWS), vous payez un total de Heroku pour les dynos et AWS pour l'infrastructure. Contrairement à Cloud Run, Container Apps ou App Runner, vous ne payez que pour la charge de travail exécutée par votre tâche et non pour le trafic. Et par conséquent, ils sont beaucoup moins chers que Heroku.

Lien : https://medium.com/faun/the-top-elastic-beanstalk-alternatives-for-startups-in-2022-f09f2c636260

#devops #aws #kubernetes #aruze 

What is GEEK

Buddha Community

How This Cybersecurity Startup Is Using Machine Learning

The COVID pandemic has massively escalated the surge of cyberattacks and data breaches despite having robust security controls, software, and solutions abundantly available in the market. A lot of this could be attributed to the vulnerability businesses offer the cybercriminals to take advantage of the situation quickly. While the conventional cybersecurity approach has benefited many, having cybersecurity without cyber-intelligence and necessary awareness can put the security professionals off-guarded to more complicated and novel threats.

Furthermore, with limited cybersecurity resources, businesses need to prioritise their efforts to strengthen cyber posture effectively; however, many organisations do not have an anchor point or a guiding principle, to begin with. With cyber-intelligence inputs missing from cybersecurity capabilities like incident management, vulnerability management, risk assessment and brand monitoring, businesses end up running their security practice in silos instead of an integrated approach.

And, thus, in an attempt to revolutionise the cyber threat visibility and intelligence market, CYFIRMA, a cyber analytics startup assists businesses to understand the relevance of the current threat landscape. Not only it provides insights on threat actors and indicators, emerging threats and digital risks, but also automatically applies intelligence into cyber posture management. To dig deeper, Analytics India Magazine got in touch with the chairman and CEO of the company, Kumar Ritesh, to understand how the company uses a predictive intelligence-driven approach to discover cyber threats.

#startups #cyber security startup india #cybersecurity startup #machine learning #startup #startups

Meilleures Alternatives Elastic Beanstalk Pour Les Startups En 2022

Les développeurs des startups sont presque toujours confrontés à la question de la manière la plus rentable d'obtenir les avantages du cloud sans avoir à gérer les systèmes sous-jacents. Il y a des années, lorsque nous construisions encore des monolithes et utilisions des instances EC2 , Elastic Beanstalk (ou Google App Engine et Azure App Service) était un choix tentant pour les jeunes startups cherchant à se déployer rapidement.

Même alors, Elastic Beanstalk (EB) ne convenait qu'aux applications non critiques qui nécessitaient une configuration et des déploiements standard. (Voici quelques témoignages de vrais développeurs qui se brûlent les mains avec EB). En outre, Elastic Beanstalk n'a pas connu de mise à jour majeure depuis un certain temps , alors devriez-vous l'utiliser même pour des applications non critiques ? Quelles sont les alternatives modernes à Elastic Beanstalk en 2022 ?

Une grande partie des informations existantes sur les alternatives d'EB répertorie également les PaaS hérités d'autres fournisseurs de cloud ou se comparent à Heroku, qui stagne. Et ils évaluent rarement les alternatives du point de vue des startups avec une équipe maigre ou pas d'équipe opérationnelle du tout. Cet article tente de répertorier et de comparer les options d'Elastic Beanstalk en 2022. Il vous sera utile si :

• Vous êtes une startup en pleine croissance qui a besoin de créer et de mettre à l'échelle des applications critiques. Des aspects tels que le temps de déploiement, la latence et le dépannage sont vitaux pour vous.
• Vous avez actuellement assemblé manuellement votre infrastructure et vos processus. Et vous évaluez quel PaaS vous convient le mieux.
• Vous utilisez déjà EB, mais vous souhaitez en migrer car maintenant, à mesure que vous évoluez, les limites d'EB vous nuisent : déploiements instables et lents et manque de transparence concernant les échecs et les mises à jour, pour n'en nommer que quelques-uns.
• Vous souhaitez que vos applications fonctionnent sans embaucher une équipe d'exploitation ou avec seulement une équipe d'exploitation allégée.

Maintenant, nous réalisons que la lecture de cet article ne vous aidera pas à affiner le PaaS pour votre startup - car on ne peut décider qu'après avoir pris en compte les nuances de son cas d'utilisation, les compétences de l'équipe et les coûts associés. Cependant, nous espérons que ce blog vous aidera à naviguer à travers les différentes technologies qui peuvent vous aider à résoudre votre problème en pleine croissance.

Des alternatives qui ne font pas la coupe

Par conséquent, cet article ne reconnaît pas les éléments suivants comme des alternatives pratiques à l'EB :

• Heroku : Malgré son expérience de développeur inégalée, nous ne recommandons plus de démarrer sur Heroku car il est souvent beaucoup plus cher à grande échelle que toute autre alternative, et il n'a pas publié de mises à jour notables depuis de nombreuses années. Par exemple, il ne prend toujours pas en charge HTTP/2 .
• IaaS : IaaS vous oblige à configurer vous-même vos serveurs, à spécifier des règles de mise en réseau, à gérer l'autoscaling, les mises à jour de sécurité, etc. Bien que cette méthode vous donne plus de contrôle et de flexibilité qu'un PaaS comme Elastic Beanstalk, cela a un coût considérable d'embaucher une grande équipe d'opérations spécialisées.
• FaaS : Faas convient à l'exécution de tâches asynchrones et d'applications événementielles telles que RESTful. Et dans bon nombre de ces cas d'utilisation, le FaaS est un spin-off de votre application principale, et non celle de base. Pour les cas d'utilisation compatibles FaaS, il peut également s'agir de votre application principale lorsque vous démarrez et que vous rencontrez des pics de trafic incohérents. Mais cet article s'adresse aux startups avec des cas d'utilisation beaucoup plus larges que ceux adaptés au FaaS.

Passons aux alternatives.

PaaS entièrement géré sur les clouds publics

Il existe 2 solutions PaaS, chacune proposée par les deux principaux fournisseurs de cloud : Google et Microsoft, qui sont presque équivalentes à Elastic Beanstalk :

• App Engine de Google
• Service d'application d'Azure

Le principal avantage de l'utilisation de l'offre PaaS de n'importe quel fournisseur de cloud, qu'il s'agisse d'Elastic Beanstalk, d'App Engine ou d'App Service, est un délai de mise sur le marché plus rapide en éliminant les frais généraux liés à la gestion des détails de déploiement, de provisionnement de capacité, d'équilibrage de charge, de sécurité, de mise à l'échelle et surveillance de la santé des applications.

Alors, comment les évaluez-vous les uns par rapport aux autres ?

Google App Engine

Bien qu'il soit aussi riche en fonctionnalités et testé au combat, Google lui-même considère maintenant App Engine comme un produit hérité . Nous l'avons inclus comme alternative parce que certains d'entre vous nous ont peut-être demandé pourquoi si nous ne l'avions pas fait. Aujourd'hui, Google lui-même recommande aux développeurs d'App Engine de passer au Cloud Run plus moderne , le service frère d'App Engine. (Plus d'informations plus tard)

Service d'applications Azure

Si votre application utilise des technologies Microsoft telles que .NET, il est simplement plus facile d'exécuter votre application sur App Service que sur EB ou App Engine. Mais encore une fois, comme Elastic Beanstalk et App Engine, il s'agit d'un PaaS hérité. Vous feriez mieux d'évaluer les offres PaaS plus modernes de Microsoft.

Notre recommandation

Elastic Beanstalk, App Engine et App Service sont tous les mieux adaptés pour exécuter des applications Web simples ou des backends d'applications mobiles sur une plate-forme sans serveur. Ce sont également des offres héritées. Bien qu'ils reçoivent des mises à jour régulières, peu de fonctionnalités notables leur ont été ajoutées au cours des dernières années. Que vous cherchiez à choisir votre premier PaaS ou une alternative à une configuration Elastic Beanstalk existante, nous vous recommandons fortement de continuer à lire pour en savoir plus sur les options modernes entièrement gérées et sans serveur qui sont également évolutives.

Cependant, si vous pensez toujours qu'un de ces PaaS est juste suffisant pour votre cas d'utilisation et que vous souhaitez en choisir un, voici ce que nous avons à dire. Les fonctionnalités ou l'implémentation sous-jacente décideront rarement de celle que vous choisirez, car vous pouvez accomplir n'importe quel cas d'utilisation avec n'importe laquelle d'entre elles (avec ou sans solutions de contournement). Il y aurait donc deux façons de penser à votre décision :

• Si vous utilisez déjà Elastic Beanstalk d'AWS, migrer vers un autre cloud (mais pas inconnu) uniquement pour leur PaaS (App Engine ou App Service) serait rarement un choix idéal, à moins que l'expertise de votre équipe ne soit maintenant avec un autre fournisseur de cloud, ou qu'il n'y ait une différence de coût significative dans l'utilisation des fonctionnalités qui vous intéressent.
• Si vous choisissez votre premier PaaS, effectuez une analyse coûts-avantages des services que vous souhaitez exécuter, de la manière dont ils interagiront et de l'expérience de votre équipe avec ce fournisseur de cloud spécifique.

Remarque : d'autres petits fournisseurs de cloud comme DigitalOcean offrent des services similaires avec un support client probablement bien meilleur et à moindre coût, mais l'étendue des cas d'utilisation que vous pouvez gérer avec eux est limitée par rapport au PaaS d'autres fournisseurs de cloud.

Passons aux alternatives modernes .

PaaS sur Cloud Privé

Une classe d'offres PaaS récentes telles que Fly , Render et Railway a vu le jour pour combler le vide créé par un Heroku stagnant et le paysage de plus en plus complexe des offres des fournisseurs de cloud public.

Fly vs Render vs Railway

Bien que Render, Fly et Railway soient souvent opposés lors de la recherche d'une expérience de type Heroku, ils ne sont pas presque équivalents. Alors d'abord, comparons-les entre eux:

• Le rendu est beaucoup plus semblable à Heroku, c'est-à-dire raffiné dans son expérience de développeur et ses capacités telles que la documentation, les tableaux de bord, la CLI, etc., que Fly ou Railway.
• Render prend en charge beaucoup moins de régions que Fly . Il n'y a aucune information sur les régions prises en charge par Railway.
• La tarification de Fly and Render est complexe. Agréablement, la tarification de Railway est basée sur l'utilisation avec un niveau gratuit généreux.
• (À partir de maintenant) Fly et Render fournissent Postgres entièrement géré. Railway prend en charge l'intégration sans configuration avec Postgres et quelques autres bases de données, mais aucune de ces intégrations n'est entièrement gérée.
• Aucune des files d'attente de support Fly, Render ou Railway. Ils ne conviennent donc pas aux cas d'utilisation nécessitant ces fonctionnalités.
• Render et Railway prennent en charge Monorepos ; Fly ne le fait pas.

Notre recommandation

Si vous utilisez déjà Elastic Beanstalk et que vous envisagez de migrer pour plus de flexibilité ou pour gérer plus d'échelle, aucun de Fly, Render ou Railway ne vous convient. En fait, ils pourraient être plus limitatifs.

Mais si vous cherchez votre premier PaaS, vous devez savoir ce qui suit :

• Fly est optimisé pour les applications Edge comme aucun autre PaaS et est un concurrent de premier plan si vous créez une telle application.
• (Pour l'instant) Fly, Render ou Railyway conviennent parfaitement à des cas d'utilisation tels que l'exécution d'un site Web statique, la création d'une application CRUD simple ou une application qui ne nécessite pas de base de données (en supposant que votre environnement d'exécution est pris en charge).
• Comme ils prennent tous en charge les images Docker, votre verrouillage est assez limité à leurs fonctionnalités propriétaires. Ainsi, le verrouillage ne devrait pas être une préoccupation lors de leur évaluation.
• À moins que vous ne cherchiez à utiliser les fonctionnalités Fly uniquement, Render and Railway est plus convivial pour les développeurs et pourrait être plus évolutif.
• La tarification simple de Railway justifie de l'essayer avant tout le monde.

PaaS natif de conteneur sur les clouds publics

Le PaaS natif de conteneur est un service sans serveur entièrement géré pour déployer des applications et des API conteneurisées.

Comme pour l'ancien PaaS, vous pouvez fournir le code source ou une image de conteneur. Ils s'occupent du déploiement, des mises à niveau, de l'équilibrage de charge, de la mise à l'échelle, de la sécurité, etc., afin que vous puissiez vous concentrer sur la création de valeur commerciale.

Mais contrairement aux PaaS hérités , ils sont optimisés pour créer et héberger non seulement des applications Web et mobiles, mais également des API, des microservices, des processus de longue durée, des tâches en arrière-plan et des applications pilotées par des événements.

Il existe trois PaaS entièrement gérés natifs de conteneurs remarquables sur les clouds publics : Google Cloud Run (généralement disponible à partir de novembre 2019), AWS App Runner ( lancé en mai 2021 ) et Azure Container Apps (généralement disponible — mai 2022).

Cloud Run contre App Runner contre applications de conteneur

• Bien qu'ils puissent tous être déployés à partir d'images de conteneur et de code source, ils ont chacun des contraintes différentes sur le type d'images, les référentiels de code source et les runtimes de langage pris en charge.
• Cloud Run prend en charge plus de langues que Container Apps et App Runner .
• Cloud Run et les applications de conteneur sont compatibles avec HTTP/2, WebSockets et gRPC, mais pas App Runner .
• Cloud Run et Container Apps prennent en charge la mise à l'échelle jusqu'à 0, contrairement à App Runner .
• La prise en charge des tâches en arrière-plan n'est pas idéale dans App Runner et Cloud Run , mais Container Apps prétend les prendre en charge.
• Cloud Run prend en charge les déploiements bleu/vert, Canary et progressifs. Les applications de conteneur ne prennent en charge que les déploiements bleu/vert et Canary . Mais App Runner ne prend en charge aucun de ces éléments.
• Les applications de conteneur prennent en charge plusieurs conteneurs dans un seul service, contrairement à Cloud Run et App Runner.
• Verrouillage
• Pratiquement aucun verrouillage Cloud Run : il est basé sur KNative, qui est open source. Cloud Run n'est qu'une couche au-dessus de KNative, qui est open source. Ainsi, vous pouvez déployer votre conteneur dans n'importe quel cluster K8S à l'aide de définitions KNative.
• Application conteneur : votre seul investissement consiste à créer l'image du conteneur, puis à exécuter quelques commandes pour la déployer. De plus, il est alimenté par Kubernetes, qui est open source. Donc, si vous choisissez de migrer, vous pourrez le faire relativement facilement.
• App Runner : il fonctionne sur ECS Fargate, qui est une offre AWS propriétaire, mais votre investissement se limite à fournir l'image du conteneur pendant qu'il s'occupe du reste (étant un PaaS). Il y a donc peu d'efforts perdus si vous choisissez de migrer.
• L'autoscaling dans Cloud Run est prêt à l'emploi, sans que vous ayez à spécifier de règle, en fonction de son comportement par défaut consistant à créer une instance dupliquée toutes les 100 requêtes simultanées. Cependant, App Runner et Container Apps vous obligent à spécifier des règles de mise à l'échelle automatique.

Notre recommandation

• Chaque App Runner, Container Apps, Cloud Run, Fly et Render sont des PaaS relativement nouveaux et n'ont donc pas été testés au combat.
• Bien qu'ils soient tous relativement nouveaux, Fly et Render seront inévitablement plus restrictifs que leurs homologues de cloud public natifs de conteneurs, car les clouds publics disposent d'un ensemble complet d'offres que vous pouvez utiliser pour résoudre à peu près n'importe quel cas d'utilisation. Ce n'est peut-être pas une bonne façon de le résoudre, mais cela ne vous bloquera pas. Au contraire, une fois que vous avez atteint un mur avec leurs capacités avec Fly ou Render, vous devez migrer hors d'eux.
• Si vous recherchez votre premier PaaS, ils doivent tous être évalués en fonction de votre cas d'utilisation et des compétences de votre équipe.
• Cependant, si vous cherchez à migrer d'Elastic Beanstalk pour plus de flexibilité à grande échelle, évaluez App Runner et le CaaS d'AWS (plus à ce sujet plus tard) .

Conteneurs en tant que service (CaaS) sur les clouds publics

Toutes les options PaaS ci-dessus vous permettent de développer et de déployer des applications sans avoir à créer, gérer et entretenir une infrastructure. Le PaaS natif de conteneur est presque identique au CaaS, sauf que dans certains cas, comme nous le verrons, le CaaS offre plus de contrôle.

Cette abstraction du PaaS natif de conteneur fonctionne parfaitement au début pour la plupart des startups, mais si à un moment donné vous avez besoin de plus de contrôle, vous devrez évaluer la seule autre offre CaaS notable : ECS. Jetons un coup d'œil à certains de ses avantages et inconvénients notables :

AWS ECS (avec ou sans Fargate)

• Nécessite l'assemblage de dizaines de pièces avant de pouvoir déployer quoi que ce soit dessus. Ainsi, l'expérience utilisateur est désagréable.
• La configuration de la mise à l'échelle automatique sur ECS est compliquée (comme le reste de l'expérience d'utilisation).
• Est entièrement propriétaire et vous oblige à vous fier entièrement à AWS ; le nombre de ressources que vous devez créer et le format d'écriture des définitions d'application garantissent que nous sommes enfermés dans AWS. Il vous sera extrêmement difficile de déménager si vous le choisissez. Mais encore une fois, le verrouillage doit être évalué par rapport à ce qu'il vous facilite.
• Sa nature exclusive a également conduit à son manque de soutien communautaire.

Remarque : Nous n'avons pas inclus Azure Container Instances (ACI) comme alternative, car il ne prend pas en charge la mise à l'échelle automatique horizontale. La mise à l'échelle verticale est également purement manuelle. Tout ce que vous pouvez faire est d'exécuter des instances uniques isolées les unes des autres. Par conséquent, ACI ne peut être utilisé en production pour aucune application à moins qu'une seule instance de l'application soit suffisante dans votre cas d'utilisation.

Notre recommandation

• Quel que soit votre cas d'utilisation, ignorez complètement ACI.
• Si vous êtes déjà sur AWS et que votre cas d'utilisation n'est pas adapté à Kubernetes, évaluez ECS par rapport à App Runner pour l'exécution de conteneurs gérés.
• ECS offre plus de flexibilité par rapport à App Runner au prix de plus de travail administratif de votre part. Par exemple, il peut exécuter plusieurs conteneurs dans un seul service alors que App Runner ne le peut pas.
• L'expérience de développeur médiocre d'ECS nécessite un temps de configuration important. Vous devez être préparé mentalement à cela.
• Si votre objectif est d'embaucher zéro ops, ECS n'est pas recommandé.
• Si AWS n'est pas une contrainte, Cloud Run est le plus convivial pour les développeurs pour le déploiement d'applications conteneurisées. Il est livré avec le moins de verrouillage et constitue le moyen le plus pratique d'exécuter des conteneurs sans serveur et gérés. Nous vous recommandons vivement de l'évaluer.

Kubernetes en tant que service (KaaS) ou Kubernetes géré

Logiquement, CaaS serait la prochaine étape si l'on voulait migrer hors d'un PaaS pour plus de flexibilité et d'évolutivité. Mais certains cas d'utilisation justifient également la prise en compte de Kubernetes. KaaS ou Managed Kubernetes Services, tels que GKE , EKS et AKS , suppriment la gestion du plan de contrôle et sont donc plus faciles à utiliser que d'utiliser Kubernetes directement.

Mais que devez-vous savoir à ce sujet pour pouvoir prendre une décision plus éclairée ?

• Kubernetes est un système d'orchestration de conteneurs open source. CaaS, comme ECS, dispose d'un système d'orchestration de conteneurs propriétaire - leur principal inconvénient par rapport à Kubernetes. (Cependant, Cloud Run et Azure Container Apps n'en souffrent pas car Kubernetes les alimente)
• La grande chose à propos de KaaS est qu'il s'agit de Kubernetes - qui est open source, bénéficie d'un soutien communautaire considérable et d'un écosystème croissant d'outils pour résoudre les cas d'utilisation courants - il y a donc un verrouillage minimal et une évolutivité infinie.
• Bien que KaaS simplifie la gestion du plan de contrôle, il vous laisse toujours l'administration des nœuds de travail, tels que les mises à niveau et la mise en réseau. Ces énormes frais généraux nécessitent une équipe dédiée avec des connaissances spécialisées sur Kubernetes.

Notre recommandation

• Évaluez si Kubernetes est requis pour votre cas d'utilisation ou si les conteneurs fonctionnent parfaitement pour vous (via PaaS ou CaaS natif de conteneur).
• Si vous décidez d'aller de l'avant avec Kubernetes, évaluez si vous avez l'équipe pour exploiter KaaS comme GKE, EKS et AKS.
• En général, GKE est le KaaS le plus mature à ce jour, et c'est aussi ce que nous recommandons.

Si vous n'avez pas le temps et les ressources à consacrer à KaaS aujourd'hui, mais que vous décidez de suivre la voie Kubernetes, il existe peut-être un juste milieu entre KaaS, CaaS et PaaS.

 

Un juste milieu entre PaaS, CaaS et KaaS

Un terrain d'entente entre PaaS, CaaS et Kaas reprendrait les meilleures caractéristiques de chacun d'eux et n'aurait pas leurs limites respectives.

• Contrairement à KaaS ou CaaS, et précisément comme PaaS, il sera entièrement géré et sans serveur.
• Contrairement au CaaS ou au PaaS propriétaire, il est basé sur un outil open source tel que Kubernetes.
• Cela ne vous lie pas à un fournisseur de cloud spécifique ou à ses outils.
• Cela vous donne la possibilité d'intégrer et de tirer parti du vaste écosystème d'outils tiers pour la journalisation, la surveillance, le stockage, etc.

Chez Argonaut , nous essayons de construire une telle plateforme. Argonaut est une couche d'orchestration (abstraction) au-dessus de votre compte cloud. En d'autres termes, il gère votre compte cloud.

• C'est entièrement géré
• C'est natif du conteneur
• Il dispose d'une prise en charge native pour travailler avec KaaS ou Kubernetes gérés comme EKS (prise en charge de GKE à venir dans quelques semaines) et FaaS comme AWS Lambda (prise en charge de Cloud Functions à venir).
• Vous pouvez exécuter n'importe quel diagramme de barre sur les applications déployées avec Argonaut.
• Il dispose d'un écosystème en expansion de modules complémentaires tiers, que ce soit pour la surveillance, la journalisation, la recherche, etc. Les exemples incluent Datadog , Prometheus , ELK , etc.

De conclure

Lorsque vous passez à une nouvelle façon d'exploiter l'infrastructure à l'aide d'un PaaS ou d'un CaaS, une bonne règle d'or consiste à utiliser le niveau d'abstraction le plus élevé qui résoudra votre problème sans imposer de limitations inutiles à la charge de travail. Si vous êtes un ops-noobs ou un ingénieur d'application, nous vous recommandons ce qui suit :

• Commencez avec un PaaS natif de conteneur et passez lentement à un CaaS ou KaaS opiniâtre. Cela vous aide à démarrer rapidement, à amorcer vos connaissances, à réduire les obstacles à l'adoption de technologies optimales et à apprendre les bonnes pratiques grâce aux valeurs par défaut intégrées.
• Au fil du temps, à mesure que vos connaissances augmentent, vous pouvez commencer à jouer avec les paramètres par défaut ou même utiliser directement la technologie native.

Notes de bas de page

1. La tarification d'Heroku est par dyno, c'est-à-dire les conteneurs qu'Heroku utilise pour s'exécuter sur EC2 au niveau du backend. Étant donné que Heroku n'exploite pas la pile d'infrastructure sous-jacente (sur AWS), vous payez un total de Heroku pour les dynos et AWS pour l'infrastructure. Contrairement à Cloud Run, Container Apps ou App Runner, vous ne payez que pour la charge de travail exécutée par votre tâche et non pour le trafic. Et par conséquent, ils sont beaucoup moins chers que Heroku.

Lien : https://medium.com/faun/the-top-elastic-beanstalk-alternatives-for-startups-in-2022-f09f2c636260

#devops #aws #kubernetes #aruze 

The Novice's Guide To Side-Hustles

I don’t know about you but in my view, work culture seems to have taken a 360- degree turn since the time I got into the workforce in 2012. For years before that, I saw people stay in the same job for years.

They often left their comfort zones and hometowns to immigrate to new cities and countries in search of that one perfect opportunity — in which they then stayed all the way till retirement. Say for my father and many other relatives who stayed in the same job for more than 20 years.

Nothing wrong with that however the times have changed since then. In recent times people have started changing jobs more frequently owing to COVID more and more people, as well as, companies are looking for gig workers and contractors.

#startup-lessons #side-hustle #startup-advice #web-monetization #startup #startups #startups-top-story #entrepreneurship

How to Use AWS Elastic Beanstalk to Reduce Risk of Deployment Downtime

You can use AWS Elastic Beanstalk to create and deploy an updated or upgrated application version with blue-green deployment using cloned configs.

In this piece, I’ll be demonstrating how AWS Elastic Beanstalk can simplify deployments by doing all the hard work for you – and with no risk of downtime – by employing a Blue/Green deployment strategy.

Using AWS means combining a large number of tools to complete projects. Personally, I choose to streamline this process by using Elastic Beanstalk, as it enables me and the rest of the dev team to control the AWS resources which power the applications we support and gives us full access to the underlying resources at any time.

#cloud #aws #elastic beanstalk #aws tools #aws elastic beanstalk

How This Startup Is Building A Language Understanding Engine

According to Research and Markets reports, Artificial Intelligence for speech recognition market in India is anticipated to expand at a compound annual growth rate (CAGR) of ~65.17% during the forecast period (2019-2024) and is expected to reach a value of INR 14.61 Bn by 2024.

The increasing demand for smart speakers and voice-enabled devices, coupled with rising penetration of speech recognition technology in customer care services are driving this growth, further stimulating development and innovation in the space.

#startups #ai startup india #chatbots #indian nlp startup #language understanding #speech recognition #startup india #vernacular.ai #voice automation