The end of server management : hosting have to become a commodity

Avant dernier intervenant lors de la keynote du vendredi 10 avril, Quentin Adam, CEO de Clever Cloud (solution PaaS), a voulu lancer un cri d’alarme sur les problématiques de l’hébergement actuel.

Avec son humour et beaucoup d’illustrations, Quentin Adam a prêché certes pour sa paroisse mais surtout pour l’industrialisation de notre métier d’IT.

Il invoque la révolution industrielle nécessaire de l’hébergement informatique afin que notre métier franchisse un cap.

L’hébergement doit devenir une commodité et la responsabilité du développeur doit s’arrêter à un “git push” (svn commit, etc …).

Attention à l’interprétation de cette dernière phrase, il faut comprendre que le développeur n’a aucun droit, aucune responsabilité sur le bon fonctionnement du socle et aucune intervention directe.

Pour autant, le périmètre du développeur n’est pas réduit. Sa responsabilité s’étend à l’OS, au serveur d’application, etc (nous le verrons en détails plus loin).

C’est à contre courant du mouvement DevOps ou en tout cas une limitation de la partie Ops pour les développeurs.

Le reste étant de la responsabilité de l’hébergeur qui doit fournir un service :

• Sécurisé
• Rationalisé
• Standardisé.

Constats

Notre métier est jeune (50 ans), les technologies que nous utilisons encore plus (Linux, Java, …) et les méthodes sont des nouveau-nés (Scrum, DevOps).

Pour pouvoir affronter les évolutions futures, il faut se concentrer sur la valeur ajoutée de notre métier : proposer des services novateurs et non plus sur des taches rébarbatives et surtout largement automatisables.

Toutes les taches d’exploitation doivent être automatisées, scriptées.

Les équipes de développement ne doivent pas se préoccuper des problématiques de scaling, de sécurité, de version de composants, de backup, etc.

Actuellement, une plateforme de production est définie par :

• Un système d’exploitation (et sa version)
• Éventuellement un serveur d’application (et sa version)
• Une JVM (et sa version)
• …

Le code applicatif est (trop) souvent lié à la plateforme et une montée de version suppose des tests de régressions.

Tout cela à un coût, ce qui explique que ce n’est pas toujours fait, et les failles de sécurité qui ont tant fait parler (Heartbleed, Poodle, Shellshock, …)

Une seule application non compatible et c’est tout le SI qui est bloqué !

De même, lors d’un rachat, les SI sont confrontés alors à une problématique de fusion des plateformes d’hébergement : c’est un projet qui peut se compter en années !

La virtualisation ne répond pas au problème puisque les mêmes opérations d’exploitation persistent.

De même, il existe des outils tels que Chef ou Puppet qui permettent d’automatiser la gestion des dépendances. Ces outils réduisent la pénibilité sans traiter le problème de fond.

Il fait le parallèle avec l’électricité au début du siècle.

Avant, beaucoup d’usines produisaient elles-mêmes leur électricité.

Depuis sont apparus les services publics ou privés qui fournissent une énergie standardisée (du 220 V alternatif en Europe) et fiable.

Les équipements étaient alors compatibles avec une certaine énergie (voltage). Maintenant, tout est standardisé et on peut changer d’opérateur énergétique sans changer ses équipements.

Le service est fiable, standardisé et l’entreprise ne s’en préoccupe plus. C’est le but à atteindre pour l’hébergement de projet informatique.

Nous devons nous inspirer des méthodes des sociétés les plus en vue du moment, parties de rien et qui valent des milliards aujourd’hui.

Pour cela, nous devons nous rapprocher du business pour créer plus de valeur et nous débarrasser des taches récurrentes, sans plus values et risquées.

Nous créons ces plus-values lorsque nous concevons, nous codons des applications, pas quand nous déployons en production/intégration/recette.

Tout dans l’hébergement doit être « parfait » car une seule erreur peut avoir trop de conséquences.

C’est la fin des « Ops » tels que nous les connaissons qui doivent devenir des gestionnaires de plateforme.

Une plateforme est définie par :

• Matériel (serveur)
• Logiciels
• Services

Une plateforme doit fournir :

• Scalabilité horizontale et verticale
• Redémarrage automatique en cas de crash
• Une politique de sauvegarde
• Pas d’interruption de service en cas de déploiement d’une nouvelle version
• …

Enfin, tout ce qui concerne le build, le déploiement, doit être automatisé car les humains sont faillibles.

Pour cela, il faut utiliser les systèmes de build actuels et de déploiement continu.

Quelles sont les solutions ?

La “révolution” passe par le cloud (évidemment), des bonnes pratiques, des concertations pour définir les normes et… Docker.

Docker est un container Linux ultra léger qui permet la distribution d’applications dans un container.

Dans ce cas, le développeur fournit son image (registry privé) ou ses Dockerfiles avec tous les éléments nécessaires à l’application, aux exploitants de fournir un socle compatible et certains services d’infrastructure (LDAP, stockage, gestion centralisée des logs, …).

L’adhérence entre le socle fourni par les exploitants et les applications est très faible et les impacts (faille de sécurité, contention, …) sont restreints au container Docker.

Nous devons pouvoir changer d’hébergeur du jour au lendemain !

Les opérations quotidiennes des gestionnaires de plateformes :

• monitoring
• sauvegarde des données applicatives
• (re)déploiement de containers en fonction des performances observées,
• …

Docker n’est pas encore parfait et il y a bien sûr des progrès à attendre :

• Gestion des variables d’environnement
• Communication entre les containers Docker
• Orchestration
• Métriques exposés par Docker
• …

Impacts

Tout d’abord, l’énorme avantage de l’utilisation de Docker est que les développements, les tests et la production se déroulent tous avec le même container.

En ce qui concerne le monitoring, la responsabilité est très claire :

1. Ops : infrastructure
2. Dev : Applicatif (application, OS, JVM, etc…)

Tout comme l’utilisation du cloud, l’utilisation de Docker impose une nouvelle façon de construire les applications.

Tout d’abord les contraintes liées à la scalabilité :

• Applications Stateless
• Microservices
• …

Contraintes liées à Docker :

• Un seul process lancé au sein du container (mais il existe des contournements)

Quid des technologies Microsoft ?

Il existe certains systèmes pour lesquels le support des technologies Microsoft reste important :

• Active Directory
• Fédération d’identité (NTLM)
• …

Microsoft a annoncé le support de Docker pour le prochain Windows Server.

À Docker, Microsoft ajoutera son propre système de conteneurs, Windows Nano Server en 2016.

Le modèle préconisé :

Conclusion

Même si les avantages de cette solution sont évidents à la fois pour les exploitants et les équipes de développement, le changement est très important.

Ce que l’industrialisation de l’hébergement doit apporter à notre métier :

• Sécurisation
• Rationalisation
• Standardisation (mise en place d’un écosystème)
• Baisse des coûts.

En savoir plus

Un retour d’expérience positif sur l’utilisation de Docker en production http :// sysadvent . blogspot . fr /2014/12/ day -1- docker – in – production – reality – not . html

Un retour moins positif : https :// www . andreas – jung . com / contents / the – case – against – docker

L’avis de Joyent : https :// www . joyent . com / developers / videos / docker – and – the – future – of – containers – in – production

Blog Ippon : http :// blog . ippon . fr /2015/03/26/ orchestration – de – containers – docker – docker – compose – et – crane /

Slides de la présentation : http :// fr . slideshare . net / quentinadam / the – end – of – server – management – hosting – have – to – become – a – commodity – keynote – devoxx – fr -2015