Humeur : Le PAAS et moi

Le PAAS: objectif

Platform as a service, son but est de déployer son application simplement en ayant une abstraction de l’hébergement.

On branche son environnement à un VCS comme github, gitlab … puis on définit son environnement et les étapes pour déployer son code.

Tout ça sans interruption de service … sur le papier

Le dimensionnement de l’environnement n’est limité que par le plafond de votre carte de crédit.

La promesse

• Environnement haute disponibilité
• Environnement élastique dans ses performances
• Facilité de déploiement
• Un environnement par branche.
• Construction reproductible
• Zero downtime
• Moins d’administration système et plus de développement
• Des templates d’intégration de CMS : Wordpress, Magento, Prestashop …
• Un support technique dévoué

La réalité

Attention, c’est à charge.

Sous le capot

Les environnements sont clairement sous dimensionnés à base de kvm, lxc, glusterfs.

Cela correspond en terme de performance à un lab perso.

L’isolation des ressources ne permet pas de bénéficier des caches du système de fichier, des applications ainsi que des bases de données.

La performance est donc bien dégradée en I/O.

Un build en local est plus rapide que sur ces environnements.

Le métier

Qui achètent ces plateformes ?

• le client final

Qui utilisent ces plateformes ?

• le développeur

La promesse est très belle pour le client final et puis on commence à travailler dessus.

Le report des compétences systèmes se fait sur la partie développement.

Les développeurs doivent trouver des solutions par du développement sur des problématiques liées à la faible allocation de ressources.

Les scripts de migration explosent en out of memory. Dans certains cas il est préférable de les jouer en local et de tout importer.

Au final, il ne s’adresse pas aux développeurs vu la charge de travail supplémentaire.
Du moins, le temps passé sur cette intégration est au détriment du planning global car il n’est pas quantifié.

Pour certains cas, on n’a pas de zero down time lors du déploiement. Dans ce cas quelle est la valeur ajoutée du service ?

Le schéma

Comment résoudre ces problèmes rapidement ?

On demande un accès aux outils de monitoring :

• grafana en PLS
• agrégateur de log facturé 💸
• APM beurk facturé 💸 (blackfire, newrelic …)

Tout cela pour ne rien voir.

Ce qui se passe en général : scale-up de l’environnement -> 💸

Cette augmentation des ressources induit automatiquement une augmentation de la facturation. On se dit que c’est temporaire … et ça reste.

L’agacement se fait ressentir pour le développeur :

• Difficulté d’intégration
• Temps de de build et deploy plus long qu’en local
• Instabilité
• Performance ridicule
• Perte de confiance du client final
• Énervement

Une fois en production :

• pas de visibilité sur la supervision système
• pas de responsabilité sur le fonctionnement global

Si l’application a des soucis de performances, la seule réponse est de reporter la responsabilité sur les développeurs ou de proposer une gamme supérieure de l’hébergement. Aucune investigation est proposée et le support ne connaît pas le contexte client, ni son métier.

Au final, tout le monde se renvoie la balle. L’observabilité étant limitée, les investigations sont très compliquées.
On se retrouve dans une situation où l’application fonctionne très mal et chacun se cache derrière son contrat.

C’est d’un triste.

> To be continued …

Combien pour tout ça ?

Le rapport performance/investissement n’est pas là.

On a, sur une infrastruture à base de bare-metal, 5x plus de puissance pour un coût divisé par 10.

Ce qui est cool : ce n’est pas le développement qui est responsable des mauvaises performances.

Ce qui est moins cool : le client final pense que le développement ou son intégration est responsable.

La solution d’hébergement est juste moisie.

> To be continued …

Quelques solutions PAAS visitées

• platform.sh sans zero down time.
• clever cloud avec du zero down time.
• artifakt vient de déposer son bilan.

Pour l’instant c’est un gros Nop !!

> To be continued …