Platform as a service
Stéphane WOUTERS
https://stephanewouters.fr/
Cloud et Système Web
PAAS
PLATFORM AS A SERVICE
PAAS est un niveau de cloud
Qu'est ce que le runtime ?
Environnement d'exécution en français
Ensemble des programmes permettant d'exécuter une application
Exemple : WAMP sur Windows
différence avec IAAS
En IAAS, on obtient une VM "vierge"
On installe soi même le runtime (PHP, node.js, serveur ftp...)
Avantages du runtime auto-géré
- Les versions maintenues par l'opérateur
- Les mises à jour de sécurité sont réalisées par l'opérateur
- L'opérateur a l'expertise pour configurer et optimiser le runtime correctement
Facturation en PAAS
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é.
Auto scalling
Les PAAS sont compatibles avec l'auto scalling. Mais il doit être configuré par l'utilisateur.
Compatibilité
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)
Déploiement
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 :
- Connecté au GIT
- Par dépôt FTP
| 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" |
Et les hébergement web mutualisés ?
- Les serveurs sont auto gérés
- & On dépose le code par FTP
C'est du PAAS ?
Oui et non :
- Auto scaling non disponible
- Souvent compatible uniquement PHP
- Souvent trop limité en ressources pour les applications plus lourdes (symfony...)
Marché
Mise en pratique
Avec clever cloud
PAAS
Les containeurs
Une révolution dans la répartition des responsabilités développeurs / opérateurs
Classiquement
É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
Responsabilité des parties
Problème...
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
Comment décrire le runtime ?
É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
Une solution à ce problème
Les containeurs
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 :
DOCKER
Démo docker
Les avantages sont nombreux
- Environnements (local/dev/recette/prod) ISO
- Si ça fonctionne en local => ça fonctionne en production
- Facilité des déploiements
- Gain de temps sur les échanges entre développeurs/opérateurs sur le runtime
Mais crée de nombreux problèmes philosophiques
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
Containeurs et PAAS
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é...
PAAS
By doelia
PAAS
WIS3 / Cloud et système web
