Abdelfetah Sghiouar, est Ingénieur Cloud chez Google, et était l'un des conférenciers de l'événement Devops2020. Nos Squadians ont eu le plaisir de l'interviewer. Nous avons discuté des dernières tendances DevOps et Cloud, ainsi que de ce que l'avenir réserve aux organisations qui ont commencé leur cheminement vers une infrastructure basée sur le cloud.
Squad a eu la chance d'assister à ta conférence lors du DevOps 2020 sur la plateforme Google Cloud. Quelles seront les grandes tendances du cloud dans les prochaines années ?
Ces derniers temps, c’est le sujet tendance. Si on lit les articles des médias spécialisés comme Gartner, on verra « En 2020, toutes les entreprises seront dans le Cloud ».
J’ai remarqué une chose, les CTO et CIO ont une meilleure compréhension des enjeux. L’activité principale de l’entreprise n’est pas de faire de l’IT, il n’y a aucune raison de se lancer dans l’IT. Il vaut mieux laisser quelqu’un d’autre de qualifier s’en occuper et se tourner vers une infrastructure cloud.
C’est moins cher, plus résilient, et plus sécurisé, parce-que tu ne peux pas embaucher des experts en sécurité comme Google ou Amazon qui ont les capacités de le faire.
Les entreprises, comme les fournisseurs de services, veulent être de plus en plus en conformité, avec le passage de plusieurs certifications, notamment pour se rapprocher des besoins des entreprises.
Donc, il y a une réelle valeur ajoutée à se lancer dans le Cloud. Si on regarde 20 ans en arrière le cycle de vie de l’IT était différent. Tout commençait par l’achat de plusieurs serveurs pour quelques millions d’euros, vous les consommez, vous achetez les infrastructures, vous embauchez, vous les exploitez et cinq ans plus tard, votre infrastructure devient obsolète. Donc, vous devez en achetez plus, et vous entrez dans un nouveau cycle.
Les entreprises, si elles n’ont pas les moyens financiers, ne pourront pas acheter plus d’infrastructures au bout de 5 ans, notamment si elles sont trop vieilles.
Grâce au cloud, le modèle « Pay As you Go » permet de payer uniquement ce que vous utilisez. Vous pouvez réduire ou augmenter votre budget et c’est plus facile que d’avoir des serveurs dans son propre data center.
Quelles sont les limites selon toi ?
Aujourd’hui, le problème que je vois, c’est que le Cloud requière beaucoup de choses, pas seulement sur les aspects techniques, mais cela demande un grand changement dans la culture de l’entreprise.
C’est pour cela que l’on parle réellement d’un « périple » vers la transition Cloud, car ce n’est pas comme si on devait faire un pile ou face. C’est une transformation lente, car tous les systèmes IT ne sont pas optimisés et les fournisseurs n’offrent pas tout ce que vous souhaiteriez avoir dans un datacenter.
Une autre tendance, c’est que les fournisseurs de cloud essayent d’apporter le cloud chez le client. On voit des entreprises offrir un service que vous pouvez mettre en place dans votre infrastructure physique, tout en étant gérée depuis une plateforme Cloud. Ce qu’on appelle communément une plateforme « hybride » ou « multi-cloud ».
C’est un aspect intéressant et un enjeu pour les prochaines années, car en faisant ça, il y a une réelle valeur ajoutée dans le sens où les clients pourront effectuer leur transformation plus « lentement ».
Il y a d’autres aspects : les grandes entreprises qu’on n’imaginait pas se tourner vers le cloud sont en train d’y aller. Lufthansa, une des plus grandes compagnies aériennes et qui existe depuis des centaines d’années, ont un très vieux SAP (* Systems Applications and Products).
Ils comprennent l’intérêt de se lancer dans une transition vers le Cloud. Nous verrons beaucoup de ces grands noms se choisir le cloud. Ce n’est qu’une question de temps comme je l’ai dit précédemment à propos des anciens systèmes et serveurs que les entreprises possèdent aujourd’hui.
À propos des difficultés organisationnelles, penses-tu que l’une des plus grandes difficultés du DevOps, c’est plutôt une transition organisationnelle ou transition technique pour l'équipe opérationnelle ?
Je pense que c'est un peu des deux. Mais je dirais que c'est plutôt une transition organisationnelle et culturelle qu'une transition technique parce qu'en fin de compte, c'est juste du code, n'est-ce pas ? Ce ne sont que des lignes de codes.
La mise en œuvre n'est pas la partie difficile. La partie difficile est, à mon avis, d'adopter la culture DevOps.
Il y a trop de choses à dire sur le sujet. Il y a la compréhension organisationnelle et ensuite la volonté organisationnelle.
La compréhension organisationnelle consiste à comprendre ce qu’est le DevOps, ce qui occupe 50 % de mon temps. Parce que l'un des problèmes que j'ai personnellement, c’est que le « DevOps », mis hors du contexte, n’a plus aucun sens.
Il existe des tas de pratiques, mais laquelle a du sens pour l'organisation ? C'est donc en quelque sorte la définition de ce que sera le DevOps au sein de votre organisation.
La deuxième difficulté, c’est la volonté des personnes à changer leur façon de faire, car tout changement dans une entreprise signifie beaucoup de travail.
Jusqu’à quel point sont-ils prêts à consacrer du temps et de l’argent pour relever le défi ?
Le DevOps est-il le futur pour les développeurs de logiciels et tous les ingénieurs d’exploitation ?
Je ne pense pas, bien que les entreprises aient adopté le DevOps. Partons de cet exemple.
Google est l'un des pionniers de cette culture « DevOps ». Nous avons un SRE qui ressemble à une implémentation du DevOps, ils partagent des aspects similaires en termes d'automatisation et de méthode de travail.
Nous avons tellement de SRE qui ne s’occupent pas de l’ingénierie logicielle. Ils ont des rôles et des responsabilités distinctes.
Il y a des cas où nous avons besoin d’ingénieurs logiciels et d’autres où nous avons besoin d’eux seulement sur un aspect particulier.
Les ingénieurs logiciels qui créent des solutions bancaires sont donc des personnes avec des compétences très spécifiques, qui ne sont pas uniquement des compétences techniques, mais ils ont une compréhension de l'entreprise et du secteur bancaire, ainsi que toutes les exigences et des règles, des aspects qui font un logiciel bancaire, un « logiciel bancaire ».
Sortir ces personnes de leur travail pour les convertir au DevOps n’apporte aucune valeur, car elles doivent se spécialiser dans ce qu'elles font. Il en va de même pour les personnes qui font de l'IA, de l'apprentissage automatique et de la science des données…
Je pense donc qu’un ingénieur logiciel avec une spécialité verticale, doit le rester, alors qu’un ingénieur logiciel sans spécialité ou proche de l'automatisation devra se diriger vers le DevOps.
Squad a pris le virage DevOps et DevSecOps en aidant ses employés à développer leur expertise avec des formations et des retours d'expérience. Penses-tu qu’il s’agit d’une bonne stratégie ?
C’est certainement une bonne stratégie s'il y a une demande. Squad est une société de conseil et il existe un réel besoin. La formation ou l'enseignement de l’ingénierie logiciel, sur la conception du CD/CI est incontestablement utile.
Les personnes font du CI/CD sans vraiment savoir qu’ils le font depuis très longtemps et ceux qui le font depuis un certain temps écrivent simplement des scripts Python ou Bash qui font toute la construction et le déploiement en leur nom, car ces scripts sont déclenchés par un système et non par l'homme.
Donc, comprendre que la mise en place d'une pipeline CI / CD, pour la laisser faire sans y penser, signifie pour un développeur qu’il sera plus concentré sur l’écriture du code que sur le débogage de l'infrastructure. Et cela a une valeur et c’est une bonne stratégie.
Si une organisation a des ingénieurs spécialisés dans un seul métier, dans une grande organisation, c’est probablement plus productif, car ils peuvent construire cette infrastructure commune pour les ingénieurs logiciels, ils n'ont donc pas à le faire eux-mêmes. Dans une grande entreprise, il y a une valeur-ajoutée.
Dans une petite société, vous n'avez pas nécessairement le luxe de le faire parce que vous avez probablement 10 ou 20 salariés.
Donc, intégrer le DevOps, avec des responsabilités communes, est probablement la voie à suivre jusqu'à atteindre une taille significative qui vous permettra d'avoir des équipes spécialisées.
Aujourd'hui, nous travaillons avec des entreprises de différentes tailles et l’un des aspects, qui est en quelque sorte lié au DevOps lorsqu'il s'agit de communautés, est la gestion de clusters de communautés.
C'est plus efficace, c'est potentiellement plus sûr. Par exemple, nous avons des clients de grandes organisations, qui une fois que nous sommes là-bas, veulent créer 20 groupes de communautés, parce qu'ils veulent un micro service par cluster. Et je leur dis « pourquoi vous voulez faire ça, c'est tellement peu productif » et « nous allons répartir vos connaissances entre 20 équipes ».
Nous essayons de pousser ces clients là où il y a des opérations centralisées et des équipes de DevOps travaillant sur des logiciels d'infrastructure en tant que développeur : juste du code, un fichier Docker, une commande, et ensuite ces développeurs n’ont pas à se soucier de la façon dont il arrive en production.
C'est donc ce que j'appellerais « le développement fait à la Google », car c'est comme ça que ça marche. Le développeur de Google est productif dès le premier jour. Il a des modèles CI, des tests intégrés et des fonctionnalités de sécurité. Il n’a rien à faire de tout ça. Il devra probablement écrire un petit fichier de configuration, mais c'est tout.
Pour les petites entreprises, il faut intégrer davantage ce type de connaissances dans l'ensemble de l'équipe afin que chacun ait la responsabilité de mettre en œuvre les pratiques DevOps, puis d'y penser lors du développement des applications.
