Stéphane WOUTERS
https://stephanewouters.fr/
Cloud et Système Web
Environnement d'exécution en français
Ensemble des programmes permettant d'exécuter une application
Exemple : WAMP sur Windows
En IAAS, on obtient une VM "vierge"
On installe soi même le runtime (PHP, node.js, serveur ftp...)
La facturation est réalisée de la même manière qu'en IAAS :
L'utilisateur choisit les machines dont il a besoin. Il est facturé à l'utilisation de ressources
Le coût est souvent plus élevé qu'en IAAS pour les mêmes ressources. C'est expliqué par le service supplémentaire apporté.
Les PAAS sont compatibles avec l'auto scalling. Mais il doit être configuré par l'utilisateur.
L'application hébergée en PAAS doit être compatible Cloud et suivre les normes d'hébergement modernes.
Souvent l'application doit être légèrement modifée pour être compatible avec le PAAS (création d'un script d'initialisation, ajout de dépendances...)
Pour profiter de l'auto scalling, l'application hébergée doit être répliquable (utiliser du stockage cloud par exemple, voir cours sur S3)
En PAAS on essaie de faciliter au maximum le déploiement.
L'idée est de permettre aux développeurs de déployer à tout moment
Plusieurs méthodes :
Avantages | Inconvenients |
---|---|
"You Write Code. We Run It." L'utilisateur dépose son code sur le PAAS, il n'aura jamais besoin de se connecter à la machine |
Choix du runtime limité. En cas de besoin très spécifique (extension PHP particulière, langage très peu connu), le PAAS ne pourra pas être utilisé |
Orienté à usage des développeurs. Ne demande aucune connaissance en administration serveur | Plus coûteux qu'en IAAS |
Déploiement simplifié et automatisé | On fait confiance au prestataire pour la gestion serveur. Aucun recours possible en cas de panne. |
L'application doit être compatible "Cloud" |
C'est du PAAS ?
Oui et non :
Une révolution dans la répartition des responsabilités développeurs / opérateurs
Écrivent le code source de l'application
Développeurs
Opérateurs
Récupèrent le code source, configurent les serveurs (VM, runtime...) et assurent la maintenance (performances, scalabilité...)
Que ce soit en IAAS, PAAS, SAAS... Les responsabilités restent les mêmes
Les développeurs ne gérent pas le runtime mais ont parfois des besoins spécifiques
Développeur :
Mon application nécessite PHP 5.4 uniquement et ImageMagick-6.9.10-8
Écrire les spécifications dans un fichier texte quelque part sur le projet...
- Apache 2.4
- PHP 5.3
- ImageMagick-6.9.10-8 (attention complier uniquement avec RSVG)
- Memcached
- etc...
Tout le monde (développeurs, opérateurs) doit respecter ces versions. Aucune garantie n'est possible
C'est un changement de responsabilité entre les développeurs et les opérateurs
Le développeur crée une "image" de son application qui embarque le runtime ET le code source
Son application devient une boîte noire hébergeable sur n'importe quel serveur sans connaître son contenu (langages, code source...)
La technologie la plus populaire pour créer des containeurs :
Les opérateurs perdent en visibilité sur les applications qu'ils hébergent
Ils ne peuvent plus configurer le "runtime" et affiner la configuration sur mesure
Ils ne peuvent plus assurer la qualité de services qu'ils souhaiteraient
L'usage de container se rapproche du principe du PAAS : On pose une application sur le service du prestataire, il s'occupe de l'exécuter
Mais en général les PAAS déconseillent l'usage des containeurs car ils perdent en contrôle sur les applications
En résumé...