De plus en plus on entend parler de cloud. C’est la un terme marketing pour dire que les données ou applications se trouvent sur un serveur, quelque part dans le monde, mais personne ne sait vraiment où hormis les prestataires de cloud. Il n’empêche que l’hébergement d’applications par ce moyen change radicalement la donne pour les sysadmins et autres devops, car il n’y a plus la possibilité de descendre à la salle machines voir ce qui cloche ou intervenir en direct sur les machines. Tout se fait à distance. Mais cela signifie-t’il la mort des fonctions sus-citées ?
Débloque les + belles offres tech en 10 mins
Il existe trois principaux modes de fonctionnement pour le cloud :
- Le SaaS, pour Software as a Service, qui est hors de notre périmètre. Enfin ce sont plutôt les utilisateurs des applications hébergées qui sont concernés.
- Le PaaS, pour Platform as a Service.
- L’IaaS, pour Infrastructure as a Service.
On va maintenant voir plus en détail les deux derniers.
L’IaaS
L’IaaS est quelque chose d’assez ressemblant aux techniques d’hébergement actuelles. À savoir qu’il s’agit uniquement de mettre à disposition des machines virtuelles qui fonctionnent de la même manière qu’une machine chez un hébergeur traditionnel. Il faut donc toujours installer les logiciels nécessaires au fonctionnement des applicatifs, et mettre en place un monitoring applicatif. La grosse différence vient du fait qu’en cas de plantage de la machine une interface permet de la redémarrer de manière transparente.
Parmi les grands hébergeurs de telles solutions on trouve OVH, Amazon via sa plateforme Webservices, Windows Azure et encore bien d’autres. Mais compte-tenu des éléments vus ici il est clair que ce n’est pas l’IaaS qui changera beaucoup au métier de sysadmin. La seule vraie différence est que ces derniers n’auront plus à installer la machine de zéro, mais c’est tout. Quant aux devops, aucun changement à l’horizon.
Le PaaS
Le PaaS est totalement différent de l’IaaS. En effet cette fois l’hébergeur fournit un framework sur lequel sera construite l’application. Ici il n’est plus question de savoir sur quelle machine l’application va tourner, puisque l’hébergeur s’occupe de tout : la scalabilité en cas de forte charge, mais aussi l’hébergement des données et ainsi de suite. Parmi les offres disponibles on pourra citer Google AppEngine, Amazon WebServices, ou encore Microsoft Azure.
Cependant, il y a des points à ne pas négliger avant d’opter pour une telle solution. Tout d’abord chaque hébergeur fournit son framework propriétaire, et ses contraintes. Cela signifie qu’une application développée pour une plateforme spécifique ne pourra pas facilement être déménagée ailleurs si jamais l’hébergeur venait à couper son service. Et ça arrive, ça a notamment été le cas pour CloudBees et Docker. Un autre problème, toujours lié au déménagement, est celui de la récupération des données. Par exemple si vous choisissez de les avoir dans la base de données Google je vous souhaite bien du courage pour pouvoir les récupérer dans quelque chose de plus standard. En d’autres termes le vrai problème de cette approche est le vendor lock-in. C’est d’ailleurs ce qui fait que les entreprises n’y ont à l’heure actuelle pas plus recours. D’ailleurs même Google, qui ne fournissait au départ que son AppEngine, a fini par offrir des VMs classiques qu’on trouve en IaaS.
Un autre problème à ne pas négliger est celui de la reproductibilité des bogues. Les plateformes telles que Google AppEngine fournissent bien un SDK pour développer, mais là n’est pas le problème. Le souci est qu’il n’y a aucun moyen d’avoir l’environnement exact d’exécution de l’application, or certains bugs ne peuvent être reproduits que dans ce cas précis. Je pense notamment à tout ce qui est encodage de caractères ou autres. De même certaines restrictions qui s’appliquent à la production, toujours chez Google, ne posent pas de problème en développement. Ceci explique que certaines librairies usuelles seront incompatibles avec AppEngine et que ceci ne pourra être détecté que tardivement, augmentant les coûts de développement.
Bon par contre si le PaaS se généralise, il est clair que les fonctions de devops et de sysadmins vont disparaître. Mais vu les contraintes, je n’y crois pas à moyen terme. Et il faudra toujours quelqu’un capable de surveiller l’état de la production, mais cette personne n’aura pas nécessairement besoin d’être sysadmin.
La problématique du coût
Le modèle des hébergeurs de solutions de cloud consiste à facturer à la requête, enfin plutôt par paquet de requêtes. Par exemple il pourra y avoir un coût de 0,01 cent pour mille requêtes. L’espace de stockage utilisé est aussi facturé, de même que les requêtes à cet espace. Le vrai souci est qu’avec un tel système on a tendance à perdre la maîtrise des coûts. Là où un hébergeur comme OVH facture 50 euros par mois une machine, et il s’agit là d’un coût fixe, dans le cloud ça peut être beaucoup plus… ou beaucoup moins. Alors certes l’avantage est qu’on ne paie que ce qu’on utilise, mais l’inconvénient est qu’on peut parfois avoir de très mauvaises surprises.
En bref
Le cloud va clairement changer la donne pour les sysadmins dans le cas de l’IaaS. Le travail sera différent, mais ne va pas nécessairement disparaître. Les devops eux ne seront pas impactés.
Le cas du PaaS rend par contre les fonctions sus-citées complètement caduques. Mais vu les contraintes sus-citées, je vois mal comment une entreprise pourrait y mettre une application qui est critique pour elle. Par contre pour faire un CDN fortement amélioré, le PaaS pourrait être une solution de premier choix, et alléger ainsi la charge des machines de production.
Débloque les + belles offres tech en 10 mins
Cet article vous a plu ? Vous aimerez sûrement aussi :
- Entrepreneurs, pourquoi c’est important de bien payer vos développeurs
- La sécurisation des applications web
- La démarche devops
- Les trois plus beaux bugs qu’il m’ait été donné de voir
Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.
Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
