Quel est votre rôle et que faites-vous concrètement ?
Techniquement, mon expertise « verticale » est la programmation (ou « Génie Logiciel »). Je me suis ensuite spécialisé dans les applications Web, les technologies open source et les systèmes basés sur Linux. A côté de cela, j’ai acquis des compétences sur les processus de production avec une coupe plutôt technique, par exemple via le coaching. En d’autres termes, je suis en charge de la construction et de la maintenance des logiciels (et des processus) grâce auxquels les entreprises réalisent leurs bénéfices. La particularité est que c’est fais avec une série de techniques et de procédés qui ont des conditions économiques adaptées pour fonctionner à la fois à court et à long terme.
C’est un peu la figure de « Coach ». Si si je devais faire une comparaison, c’est quelque chose de similaire à l’entraîneur d’une équipe sportive, comme le football ou le volley-ball. Il n’est pas responsable d’une seule petite action ou d’un athlète (comme l’est le préparateur sportif), mais du programme de la compétition et de l’ensemble du processus.
Pour faire un logiciel qui fonctionne, il faut (au moins) deux choses : des personnes ayant un problème à résoudre et des personnes capables de le faire grâce aux technologies de l’information. Je dois m’assurer que globalement l’ensemble des choses qu’une équipe fait résout le problème du client en restant bon marché et rapide, mais en même temps, il faut s’assurer qu’il n’y a pas de revers ou de problèmes futurs. Les étapes qui conduisent l’idée d’être un programme à ses utilisateurs finaux sont appelées le « processus de production ». Si on fait un bâtiment par exemple, on va faire un projet sur papier, une étude géologique, puis des fouilles pour les fondations, on va élever les murs porteurs et ainsi de suite. À partir du moment zéro, nous sommes capables de voir de nos yeux ce qui se passe. Le problème avec les logiciels (et le travail intellectuel en général) est que tant que le travail n’est pas terminé, il n’y a aucune perception de ce qui se passe et il est très difficile de communiquer avec les autres. Vous avez donc besoin d’une série de techniques adéquates. En procédant par très petites étapes, il y a la possibilité de changer d’avis, de créer des mécanismes qui permettent d’apprendre en continu.
Comment êtes-vous arrivé à votre poste actuel ?
Je dirais par passion. J’ai abordé l’informatique comme un jeu avec l’aide d’adultes en maternelle, évidemment en jouant. Je ne sais pas comment extrapoler une raison ou un moment précis dans lequel j’ai pris une décision, je dirais plus que c’était une découverte progressive de ma passion. Puis à l’école primaire j’ai découvert qu’on pouvait aussi construire des jeux : il suffisait d’apprendre le langage informatique. A partir de là je n’ai jamais baissé les bras, j’ai juste dû « l’accepter » et persévérer. Je ne crois pas au dualisme « suivre la passion » contre « suivre la rationalité », en particulier en informatique. Cela s’applique évidemment à toutes ces professions où il faut toujours étudier, celui qui choisit cette profession se « condamne » à étudier tous les jours pendant toute sa carrière.
En ce qui concerne l’informatique, j’ai toujours été fasciné par l’idée de pouvoir construire quelque chose qui fonctionne à partir de rien et avec des opportunités d’impact potentiellement infini sur la vie des gens. Pensez à Wikipedia, Skype, eBay, Facebook, YouTube, Twitter, Whatsapp, Airbnb, etc. Rien de tel n’existait il y a quelques décennies. La vie des gens était différente, la société était différente.
Comment avez-vous abordé DevOps ? Et quelle est la chose qui vous passionne le plus dans DevOps ?
Comme déjà évoqué, j’ai abordé la programmation depuis mon enfance. Puis, quand j’avais 12 ans, j’ai commencé à fréquenter des amis plus âgés qui avaient créé un groupe d’utilisateurs Linux. Les « User Groups » existent encore aujourd’hui, même si beaucoup préfèrent les appeler Meetup. Un groupe de connaissances, d’amis ou de professionnels qui se réunissent pour le plaisir dans un certain lieu dans le but d’expérimenter, d’apprendre ou d’enseigner certains sujets (le nôtre était, en fait, Linux). Puis la passion s’est peu à peu transformée en atelier puis en métier. Cependant, à partir de là j’ai découvert Unix, j’ai appris sa façon de penser (la Unix Way), tant du côté de l’ingénieur système que de celui du programmeur (à partir du C). J’ai donc commencé à apprendre l’informatique comme si les activités « développement » et « maintenance » étaient deux domaines d’études étroitement liés. Peut-être que la mienne était l’une des dernières générations à le faire. Lorsque j’ai senti que ce changement se produisait, j’ai continué à étudier en concentrant mes forces sur les problèmes de backend et de Linux.
Avec les vagues technologiques des 20 dernières années, notre métier a beaucoup changé, la discipline s’est élargie et des figures plus précises sont apparues. En particulier, la disponibilité des infrastructures a augmenté, nous avons donc commencé à appliquer les technologies de l’information au monde des systèmes d’information, un luxe qui était auparavant réservé aux géants (je simplifie beaucoup, mais c’est l’idée). Quelques dizaines de serveurs pouvaient également être gérés « à la main », ou un serveur plus puissant était acheté une fois certaines limites atteintes.
Aujourd’hui, c’est une approche plutôt démodée et peu économique. Alors que la création d’applications est devenue plus facile et que les langues ont moins de barrières d’accès, la complexité a été cachée dans la couche inférieure, celle des infrastructures. Et donc, tout compte fait, l’ingénieur système d’aujourd’hui est devenu un programmeur spécialisé dans les systèmes d’exploitation (quand il construit des clouds) et les logiciels d’infrastructure (quand il les utilise).
Ce qui me fascine dans DevOps, c’est de voir une équipe de professionnels qui viennent publier leur logiciel, travailler par petits morceaux, peut-être des centaines par jour et toujours mieux. Cela semble évident, mais cela signifie souvent que cette équipe a réussi à mettre en place un processus d’apprentissage.
Qu’est-ce qui vous a poussé à écrire votre livre DevOps ?
Il y a vraiment beaucoup de raisons et c’est une question que je me pose encore aujourd’hui donc je ne vais mentionner que les deux premières.
La principale raison est tout simplement que je voulais écrire. J’aime écrire et je voulais me tester, c’est une habitude que je fréquente depuis l’enfance. J’ai écrit différents types de textes au fil des années, liés au monde de la fiction, de l’information, parfois du divertissement. Mais je n’avais jamais écrit un texte de vulgarisation scientifique, pas moins un livre entier. Je n’avais jamais dépassé 30-40 pages. En 2017, le GrUSP (l’une des plus grandes associations de développeurs de logiciels en Italie) cherchait des idées et des auteurs pour un nouveau livre. Je me suis proposé. Je voulais me tester en écrivant un chapitre ou deux d’un hypothétique manuel technique, code source. Cela me paraissait un challenge difficile mais à la hauteur de mes capacités. Seulement le projet est tombé dans l’oubli, mais il est revenu sous une autre forme en 2019, lorsque j’ai reçu un mail du président de l’association, qui m’a mis directement en contact avec un éditeur. Non plus une petite maison d’édition, mais un éditeur traditionnel, un colosse qui voulait un tel texte dans son catalogue. Ils venaient de tenter un projet à plusieurs, sauf que les auteurs précédents n’ont jamais livré l’ouvrage (pour diverses raisons qui ne trompent pas). L’éditeur cherchait alors un seul auteur, mais avec un parcours transversal, ce qui l’a conduit à moi. Après avoir discuté de l’orientation du livre, j’étais très sceptique et je ne savais pas si j’allais y arriver. Écrire seul un tel texte est un grand défi. C’est plus de 300 pages. Ensuite, je me suis rappelé que les opportunités sont des opportunités et je me suis lancé.
La seconde raison est que j’espère vraiment qu’il sera utile à ceux qui veulent créer des logiciels pour gagner leur vie, ou qui s’y prennent dans le mauvais sens. J’ai beaucoup aimé le sujet proposé par l’éditeur et il était proche de mon expérience jusqu’alors. Il manquait un tel texte destiné au grand public italien, ainsi que l’organisation d’un certain éventail de connaissances de base relatives au métier de programmeur. J’espère qu’au moins une personne parmi les lecteurs a pu apprendre quelque chose dont elle a besoin pour travailler un mieux que la veille.
Consultez également notre article : « Les 3 difficultés principales rencontrées par les organisations souhaitant utiliser DevOps selon Fabio Mora”
