La plateforme en tant que service (PaaS) est apparue en tant que force de premier plan dans la quête en constante évolution visant à rationaliser le développement de logiciels. Le PaaS remonte à 2006 avec Force.com, suivi de Heroku, AWS Elastic Beanstalk et DotCloud, qui se sont ensuite transformés en Docker.
Alors que le secteur PaaS détient une part de marché substantielle de 170 milliards de dollars au sein de l’industrie du cloud, les entreprises sont encore aujourd’hui aux prises avec un déploiement manuel et une gestion du cycle de vie des charges de travail. Alors pourquoi la plateforme en tant que service n’est-elle pas plus largement adoptée ?
Fournir une expérience PaaS sur toutes les charges de travail
Les plateformes PaaS pourraient être plus polyvalentes, et je ne parle pas de compatibilité des langages et des frameworks. Bien que le PaaS soit souvent défini comme un guichet unique pour déployer n’importe quelle application, il existe un problème. Par applications, on entend généralement ici les applications à 12 facteurs.
Cependant, de nombreuses charges de travail ne correspondent pas parfaitement au moule des applications Web classiques ; ils comportent des exigences uniques, telles que des tâches de traitement par lots, des charges de travail de calcul haute performance (HPC), des tâches gourmandes en GPU, des applications centrées sur les données ou même des charges de travail de calcul quantique.
Je ne passerai pas en revue tous les avantages qu’offre le PaaS. Néanmoins, les entreprises doivent gérer toutes leurs charges de travail de la manière la plus simple possible, et faire abstraction de leur déploiement et de leur gestion est la voie à suivre.
Un changement est nécessaire. Premièrement, les entreprises qui adoptent le paradigme PaaS doivent reconnaître qu’il n’existera pas de solution universelle en matière de charge de travail. Dans un récent discours sur le sujet, l’ancien ingénieur de Google, Kelsey Hightower, renforce l’idée selon laquelle un PaaS unique et global reste improbable.
Les entreprises qui adoptent le paradigme PaaS doivent reconnaître qu’il n’existe pas de solution universelle en matière de charge de travail.
Il a également utilisé API de charge de travail pour désigner un outil qui offre cette expérience transparente « voici mon application, exécutez-la pour moi ». J’aime le terme « API de charge de travail » car il énonce clairement l’intention : exécuter une charge de travail spécifique. Par rapport à la plateforme en tant que service (PaaS), qui doit être plus précise et conduit à cette confusion selon laquelle le PaaS est la solution miracle pour faire fonctionner quoi que ce soit. J’utiliserai ce terme pour le reste de l’article.
Le deuxième changement pour les entreprises souhaitant offrir une expérience de déploiement et de gestion transparente pour toutes leurs charges de travail consiste à considérer que chaque charge de travail doit avoir son API de charge de travail. Par exemple, Amazon Lambda pourrait être utilisé pour les tâches par lots, Vercel pour le front-end, Vertex AI pour les modèles d’apprentissage automatique et Korifi pour les applications Web.
Voyons maintenant comment choisir les API de charge de travail.