PaaS, CaaS ou FaaS? Comment choisir

Imaginez entrer dans une épicerie spécialisée dans les hamburgers - toutes sortes de hamburgers, mais seulement des hamburgers. En ce qui concerne les hamburgers, cependant, les options du magasin sont infinies. 

Si vous êtes un chef cuisinier de hamburgers, allez dans l'allée 1 pour trouver le bœuf, le poulet et d'autres options de protéines, ainsi que tous les fromages, types de pain, légumes, condiments et autres ingrédients que vous voudrez peut-être pour créer votre propre hamburger et côtés. Il existe même une sélection d'assiettes et de contenants pour emballer le repas.

Si vous manquez de temps, de compétences ou d'intérêt pour assembler vous-même le hamburger, dirigez-vous vers l'allée deux où vous pouvez acheter l'un des hamburgers-en-kit. Outre les options classiques, il existe un kit pour un hamburger bio, une option végétalienne et même un régime céto. Suivez simplement les instructions du kit et vous devriez avoir un délicieux hamburger.

Également en vedette dans cette série:

  • Les conteneurs entrent dans le courant dominant ()
  • Conteneurs et Kubernetes: 3 histoires de réussite transformationnelle (CIO)
  • Kubernetes rencontre le monde réel ()
  • Points essentiels à savoir sur la mise en réseau de conteneurs (Network World)
  • Comment Visa a construit sa propre solution de sécurité des conteneurs (CSO)
  • Des conteneurs sur le bureau? Vous pariez - sur Windows 10X (Computerworld)

Seulement alors, alors que vous êtes dans la file d'attente, votre patron vous appelle. Elle dit que vous devez préparer 300 hamburgers de types différents dans les deux heures précédant le déjeuner. De plus, en plus de préparer les hamburgers, vous devez opérationnaliser un processus pour les servir et être payé. Vous devrez faire attention car certains clients veulent des commandes spéciales et d'autres essaieront de couper la file et de voler leur déjeuner.

Enfin, il y aura une inspection de santé et de sécurité pendant le déjeuner, donc quoi que vous fassiez, respectez mieux la réglementation. Et désolé, mais vous n'aurez que quelques personnes qui travaillent avec vous, et elles ont aussi peu d'expérience avec ce type d'opération.

Faire le cloud burger

La sélection parmi les architectures cloud ressemble beaucoup à cette opération de hamburger improvisée et, à bien des égards, beaucoup plus compliquée. Les développeurs, les ingénieurs, les architectes et les responsables informatiques ont de nombreuses considérations en matière de plate-forme, de performances, de réglementation et autres lorsqu'ils examinent les architectures cloud à opérationnaliser.

Quelle architecture offrira une meilleure expérience aux clients et produira un produit de meilleure qualité? Qu'est-ce qui sera plus facile à opérationnaliser et à respecter votre échéance? Quel chemin permettra de mieux gérer les problèmes de support, de conformité et de sécurité? Enfin, quelle approche pouvez-vous mettre en œuvre au moindre coût? 

Les ingénieurs peuvent sélectionner une option de conteneur en tant que service (CaaS) et des applications de conteneurisation, ce qui équivaut à ce que le chef crée et opérationnalise son repas dans l'allée un. S'ils n'ont pas cette expertise, les options de plate-forme en tant que service (PaaS) équivalent à choisir un kit dans l'allée deux et à suivre les instructions et les contraintes liées à son utilisation.

Ni CaaS ni PaaS ne répondent à vos besoins? Eh bien, vous pouvez tout construire à partir de zéro (infrastructure en tant que service ou IaaS) ou déployer des fonctions dans des environnements sans serveur (fonction en tant que service, ou FaaS).

FaaS est un type d'informatique sans serveur conçu pour répondre à une seule tâche. Par exemple, un FaaS peut être utilisé pour authentifier un utilisateur, effectuer une vérification orthographique sur un corps de texte ou effectuer un calcul mathématique.

De toute évidence, il existe de nombreuses options architecturales pour héberger, configurer, gérer et déployer du code dans le cloud. Les choses se compliquent encore plus lorsque l'on considère les différentes offres de produits. Les options PaaS incluent Azure App Service, AWS Elastic Beanstalk, Google App Engine, Red Hat OpenShift et Heroku de Salesforce, pour n'en nommer que quelques-uns. Si vous explorez les solutions CaaS, Amazon, Google et Amazon ont chacun leur propre service Kubernetes géré avec leur propre acronyme (EKS, GKE et AKS, respectivement). De plus, il existe d'autres options telles que VMware, IBM, Oracle, Rackspace et autres.

Bien sûr, il existe encore plus d'options sans serveur. Azure Serverless a des fonctions sans serveur, des pods Kubernetes et des environnements d'application. AWS propose actuellement des options sans serveur plus larges et divise son sans serveur en catégories fonctionnelles pour l'informatique, le stockage, les magasins de données, les proxys API, etc. Google Cloud prend la définition la plus étendue du sans serveur et inclut des services tels que BigQuery et AutoML.

Principales considérations relatives à CaaS, PaaS, FaaS et sans serveur

Il y a plusieurs considérations lors de l'examen de ces différentes architectures cloud. 

  • Public cible - Les options PaaS et FaaS ciblent d'abord les développeurs en rendant la solution facile à configurer et à intégrer aux pipelines CI / CD pour le déploiement. Les conteneurs paramétrent l'environnement d'exploitation et la configuration de la plate-forme, de sorte que ces outils s'adressent généralement aux opérateurs et aux administrateurs système.
  • Configurabilité versus agilité - En général, CaaS est l'option la plus configurable, offrant aux opérateurs la plus grande flexibilité pour sélectionner les plates-formes et les configurations à conteneuriser. Les options PaaS et FaaS se concentrent sur l'agilité et aident les développeurs à déployer et tester le code plus rapidement.
  • Certaines solutions PaaS sont  opinions bien arrêtées - solutions PaaS et Faas par la conception sont Présélectionner, ce qui signifie que vous êtes déjà enfermés dans leur choix de plate - forme et les options de configuration. Ces solutions sont conçues sur la base des opinions du concepteur sur ce que veulent les développeurs, les meilleures pratiques et les caractéristiques de performances cibles. Pour les opérateurs qui préfèrent plus de flexibilité ou plus de contrôles, un PaaS ou FaaS avisé peut être trop contraignant. 
  • Compétences et courbe d'apprentissage - Une généralisation juste est que les solutions CaaS ont une courbe d'apprentissage plus raide et nécessitent plus de compétences que les solutions PaaS et FaaS.
  • Verrouillage du fournisseur - Les solutions CaaS sont généralement développées sur Kubernetes et sont portables sur différentes options d'hébergement cloud. Même si les solutions PaaS et FaaS peuvent être conçues avec Kubernetes comme base, elles n'exposent généralement pas la couche Kubernetes aux utilisateurs finaux et présentent à la place des configurations plus simplifiées. Ces configurations sont propriétaires de la solution PaaS et FaaS et sont souvent conçues pour s'exécuter sur un seul cloud. Certains responsables informatiques trouvent cela problématique et craignent à juste titre d'être enfermés dans le fournisseur de cloud. 

Questions pour guider vos recherches et prototypage

Face à autant d'options, certaines organisations effectueront un minimum de recherche et de prototypage et sélectionneront le chemin le plus rapide. D'autres investiront beaucoup de temps, d'énergie et d'argent pour rechercher des options, consulter des experts et sélectionner des options pour des implémentations robustes.

Ces deux approches sont meilleures que votre organisation devenant paralysée par la multitude d'options, n'en choisissant aucune et n'allant nulle part. Dans le monde en évolution rapide où chaque entreprise essaie d'obtenir un avantage technique, être trop conservateur et maintenir le statu quo ne fera qu'inhiber les opportunités d'une entreprise. 

J'ai donc consulté des experts pour identifier certaines questions clés qui devraient aider à réduire les options et les règles du jeu:

  1. Vous êtes une petite équipe avec seulement quelques applications? Dans ces cas, vous devriez envisager les options PaaS et sans serveur plus simples où vous pouvez obtenir la plupart de la plate-forme requise préconfigurée et sans investir beaucoup de temps et d'expertise. DJ Navarrete, directeur de l'architecture de plate-forme chez AvidXchange, suggère: «Pour les petites et moyennes entreprises qui peuvent avoir besoin de plus de support de gestion du changement pour réussir, et celles qui cherchent à augmenter rapidement la maturité, la stabilité et la vitesse, le PaaS est attrayant car il offre une voie plus rapide vers la mise en œuvre et des gains d'efficacité. »
  2. Avez-vous des charges utiles épisodiques, mais devez-vous encore évoluer lorsque cela est nécessaire? La portée pourrait être un microservice ou une fonction, mais pourrait également devenir des applications et des bases de données complètes. Ces cas d'utilisation sont parfaitement adaptés à l'informatique sans serveur, où vous ne payez que pour l'utilisation requise.
  3. Avez-vous une obligation de conformité ou une norme réglementaire qui vous oblige à signaler des options ou des paramètres sous-jacents spécifiques dans le conteneur d'exécution, l'application, la base de données, le système d'exploitation ou l'infrastructure? Wayne Anderson, architecte de la sécurité et de la conformité pour le centre d'excellence de Microsoft en milieu de travail moderne, explique que c'est une raison essentielle pour laquelle les options sans serveur sont exclues. Les exigences de conformité PCI et autres sont généralement interprétées par les services juridiques ou les auditeurs comme exigeant une preuve des paramètres de l'environnement informatique.
  4. Utilisez-vous de nombreuses plates-formes spécialisées ou applications héritées? Dans ces cas, il peut être difficile de trouver des options PaaS commerciales compatibles. Dans le même temps, le développement de conteneurs peut simplifier le déploiement et la gestion des dépendances.
  5. Êtes-vous une grande organisation ou une entreprise opérant dans plusieurs clouds et avec diverses plates-formes d'applications et de données en production? Ces organisations peuvent choisir de standardiser sur les conteneurs, car cela offre la plus grande flexibilité pour prendre en charge plusieurs plates-formes et options de configuration. Le sans serveur peut toujours être une considération si la conformité n'est pas un facteur. Les entreprises peuvent s'éloigner des options PaaS si elles ont suffisamment de compétences et de capacités pour développer l'étendue des options sur Kubernetes. Les organisations ayant une échelle et des compétences techniques suffisantes, telles que Shopify, peuvent choisir de concevoir leur propre PaaS avec Kubernetes et des conteneurs comme base.
  6. Développez-vous des microservices et standardisez-vous sur une architecture de microservices basée sur le cloud? Mark Heath suggère que les conteneurs ou FaaS sont de bonnes options, tout comme les fonctions d'hébergement dans des conteneurs. Selon Heath, les fonctions sans serveur peuvent être plus faciles à configurer et moins coûteuses à prendre en charge, tandis que les conteneurs peuvent simplifier le développement local et fournir plus d'options pour sécuriser les points de terminaison. 
  7. Le consultant cloud Sarbjeet Johal aime savoir si vous créez des plates-formes, des applications ou des services, et si l'audience est interne à l'entreprise, externe ou client, ou consommable par la machine. Connaître le type d'application et le type d'utilisateur final vous permet d'anticiper les besoins et exigences futurs. Par exemple, Johal dit: «Pour les applications externes, vous voulez enregistrer beaucoup plus de contrôle d'accès, les volumes de données peuvent augmenter de manière imprévisible et l'application peut avoir une longévité plus étendue par rapport aux applications internes. Si un service ou une plate-forme est un consommable de la machine, vous aurez peut-être besoin d'un comptage. » La prévision de la feuille de route et des besoins futurs devrait aider à promouvoir certaines options et à en exclure d'autres.

Une fois que vous avez réduit les options, une meilleure pratique consiste à effectuer une preuve de concept. Vous ne cuisinez pas de hamburgers pour 300 sans tester la recette.