Au secours, le métier d’Ops va disparaître !

Posted by

Echo au post d’Olivier Poncet, version Ops

Il y a une semaine, Olivier Poncet a posté un long article intitulé Je fais partie d’une espèce menacée d’extinction, dans lequel il raconte, entre autres choses, qu’il ne reconnaît plus son métier.

Je vous conseille d’aller le lire, il y parle de beaucoup de choses qui sont vraies pour tous les métiers de l’IT.

Un des sujets qu’Olivier aborde est l’arrivée des magiciels, du cloud et du NoCode. Vous savez, tous ces bidules magiques qui vous promettent de pouvoir faire un business dans l’IT sans en faire (de l’IT).

En filigrane, les développeurs sont nuls et le nocode permet de copier Airbnb en 1 week end

N’étant pas développeur (je bidouille du Python pour le fun), l’article a pour autant réveillé en moi un article similaire que je rumine depuis des années. Ce brouillon avec ses premières phrases traîne depuis 2016 si on en croit la date dans WordPress…

On va rentrer tout de suite dans le vif du sujet : ça fait des années qu’on nous prédit la fin du métier d’Ops (ou tout autre variante, Sysadmin, NetOps, DBA, …). C’est vraiment pas de bol que j’en ai fais mon métier (passion).

TL;DR. je ne crois pas une seule seconde que le métier d’Ops va disparaître.

The end is nigh!

Retour en arrière.

On est en 2013. Je commence tout juste à être un admin correct, à savoir à peu près de quoi je parle et être pertinent sur 2-3 sujets niches (Vulture, Shinken, …). Je me décide à créer un compte Twitter pour pouvoir en discuter avec mes pairs.

Et là, c’est le drame. Un des premiers tweets que je lis, que je n’ai malheureusement pas su retrouver, qui disait :

Sysadmins, you should learn how to code quickly. With cloud adoption, you will soon be out of a job.

Et c’est drôle, car c’est littéralement le pitch de l’article d’Olivier Poncet, qui a l’impression que l’industrie lui explique qu’il appartient à une espèce en voie d’extinction.

STEVEN SPIELBERG: « You’re out of a job »

Back to my tweet

En lisant le tweet de 2013 qui me prédisait une fin proche et douloureuse, sur le moment, je me suis dit : "comment quelqu’un qui travaille dans l’IT peut écrire un truc aussi stupide ?" (En bien moins poli).

Et pourtant, les années passant, il faut se rendre à l’évidence. Même dans un monde où on prône* le DevOps depuis plus de 10 ans, cette croyance est finalement assez bien ancrée dans une partie de la communauté.

*Une des premières personnes que j’ai follow sur Twitter, @bitfield en parle depuis 2009 et je suis sûr que d’autres en parlent depuis bien plus longtemps…

Les Ops, ces techosses chevelus confinés au sous-sol, à la IT crowd, sont voués à disparaitre.

Hello IT. Have you tried turning it off and on again?

Avant-hier, l’automatisation

D’abord, on nous a promis que les Ops allaient disparaître à cause de l’automatisation de l’infrastructure.

Chef, Puppet, Ansible, … plus besoin d’être un Ops pour faire de l’Ops. Je peux installer/mettre à jour des softs en quelques lignes de YAML !

Dans l’absolu, ouais… D’ailleurs, j’ai même donné une conf à BDX.IO là-dessus, avec comme titre "Ami développeur, deviens un ops sans effort avec Ansible".

Mais c’était plus pour avoir un titre accrocheur qu’autre chose, car une fois installé, qui va gérer l’infra en cas de problème ?

Même pour régler un problème aussi trivial qu’un filesystem rempli par des logs, il va falloir que quelqu’un fasse de l’opérationnel : vider les logs, le temps de corriger la verbosité de l’appli… Et on est bien d’accord que dans la vraie vie ça sera pas aussi simple tous les jours.

C’est la raison pour laquelle je ne conseille pas Ansible lorsqu’un Ops junior me demande s’il peut commencer à apprendre le métier comme ça. Ansible, que j’utilise tous les jours, nécessite a minima de comprendre comment ça marche, sous le capot.

C’est comme un mécanicien qui apprendrait uniquement à se servir de la valise et pas comment marche un moteur ou le circuit de refroidissement (attention, semi-troll).

Sans cette compréhension, propre à quelqu’un qui a déjà fait une fois à la main, le temps gagné lors du déploiement sera perdu 10 fois (100 fois ?) quand il y aura un bon gros plantage.

Hier le cloud

Quand on parle de la fin des Ops, le suspect n°1 qui revient le plus souvent est sans aucun doute le Cloud.

Mais c’est quoi, le Cloud ?

Je vous passe la vision des non techniciens, à qui on a vendu que le cloud, c’était le stockage de leurs photos de vacances sur leur iPhone partout dans le monde. Ce n’est pas de leur faute, c’est BFMTV qui leur a dit.

Mais même dans le monde IT, pour beaucoup d’experts (autoproclamés ?), le cloud, ça se limite à une idée floue, à mi-chemin entre le SaaS et le IaaS, qu’il existe une solution magique pour tous les workloads, prête à l’emploi et à payer à l’usage.

Dans ces conditions-là, c’est vrai, les Ops ne servent plus à grand-chose…

J’exagère ? Il y a même une personne, de passage sur un de mes articles, qui a pris le temps de chercher l’email du blog, pour venir m’écrire :

De nos jours, avec la montée en puissance du cloud, comment un architecte système comme toi s’en sort, alors qu’il suffit d’un clic pour obtenir une instance système ?

Il faut dire aussi que les gros cloud providers n’hésitent pas à entretenir cette idée (ça les arrange !), comme par exemple dans ce Manga (officiel) édité par Microsoft Azure :

Day 2 operations

Le truc, c’est que, une fois que vous l’avez, cette "instance système" (notez le terme ultra flou), ou cette webapp vous en faites quoi ?

La question, elle est vite répondue

Désolé de casser vos rêves, jeunes entrepreneurs. Cette solution magique fantasmée, elle n’existe pas.

Au mieux, ce qu’on appelle vulgairement "le cloud", c’est une collection hétéroclite de services, qui, mis bout à bout, vous permettent de faire tourner votre appli. Soit.

Mais :

  1. Personne ne va les mettre "bout à bout" pour vous.
  2. Personne ne va s’assurer que tout fonctionne parfaitement, h24…

Je ne vais pas vous détailler la complexité de mon métier (maintenir en ligne des services accessibles dans le monde entier). Pour que vous puissiez appréhender le problème, il me suffit de citer cet excellent article sur la panne en cours depuis jeudi dernier chez Garmin.

https://www.nakan.ch/wp/2020/07/24/indisponibilite-de-garmin-connect-chronique-dune-catastrophe/

Il n’y a qu’à voir la complexité qu’une entreprise mondiale a pour remettre en ligne Garmin Connect pour comprendre que sans une armée d’Ops, ça ne peut pas marcher, même dans le cloud.

Il y a carrément des pans entiers de nos métiers qui auront disparu en 2024

Bon… venant de so-called expert sur LinkedIn ou d’un visiteur sur mon blog,… Admettons.

Mais même Gartner (entreprise de conseil dans les domaines techniques) s’y met !

Stockage : les analystes urgent les ingénieurs de changer de carrière

Le cloud et l’hyperconvergence ont à ce point réduit la demande pour des spécialistes du stockage que, d’ici à cinq ans, il sera tout simplement impossible de trouver un tel profil sur le marché de l’emploi. — Operations & Cloud Strategies de Gartner, fin 2019.

Carrément. "tout simplement impossible"

Gartner, nous explique, droit dans les yeux, que dans 4 ans il n’y aura plus dans le monde de baies de stockage opérées par des humains.

Mais alors, ils vont devenir quoi les "ingé sto" ?

Plus personne n’a vocation à devenir administrateur ou ingénieur en stockage. Les nouvelles générations préfèrent désormais s’orienter vers des carrières de développeurs.

Aaah voilà. On y est ! Les Ops c’est has been, il faut devenir Dev maintenant monsieur. On en revient au tweet du début de l’article, la boucle est bouclée, je suis moi aussi membre d’une espèce en voie d’extinction.

Dans son article Kubernetes présent partout, visible nulle part), Didier Girard le VP Engineering de SFEIR nous dit :

L’infrastructure est le domaine en voie de disparition. Il existe actuellement des racks d’ordinateurs dans des pièces fermées à clé, avec des lumières clignotantes et mystérieuses et beaucoup de ventilateurs qui vibrent.

On retrouve le champ lexical de l’espèce menacée, les clichés à la IT Crowd (blip, blip… double blip),…

Si vous lisez l’article, vous verrez que c’est un peu plus nuancé que cette phrase, sortie de son contexte. Mais l’image, elle, est bien présente et selon moi elle alimente dans l’inconscient collectif l’idée que les Ops vont disparaître.

Incrédulité

Je ne comprends pas que des pros (Gartner) puissent écrire des choses pareilles…

Comment peut-on imaginer les équipes d’infra vont disparaître au profit du tout sur le cloud, dans un monde où il existe encore un nombre incalculable d’entreprises (banques inclues) fonctionnent encore avec ce type de systèmes informatiques avec des interfaces vert/noir 640×480 :

https://fr.wikipedia.org/wiki/System_i#/media/Fichier:IBM_AS400.JPG

Si jamais il y a une transition, n’imaginez pas que ça ait lieu avant 20-30 ans (de manière progressive).

Et c’est pas fini !

Et quand on pense que ça peut pas être pire, il y a toujours un esprit malin pour venir inventer autre chose…

Roulement de tambour

Maintenant on nous vend du serverless ! Plus besoin de serveurs pour faire marcher votre code, vous l’uploadez sur Internet et à vous les millions ! Enfin débarrassé des Ops…

Hum… vraiment ?

En vrai, on est d’accord qu’il y a bien un serveur pour faire tourner votre code, hein ? Vous n’avez juste plus la main sur la façon dont il est lancé : ce serveur, il est géré par votre fournisseur de service.

  • Êtes vraiment sûr que cette personne vous aidera quand vous aurez un gros problème de perf, a mi-chemin entre le code (vous) et la plateforme (eux) ?
  • Avez-vous vraiment confiance dans le fait que l’opérateur n’analysera pas votre trafic ou les données que vous traitez ?
  • Êtes-vous certains que vous n’aurez jamais besoin de modifier un paramètre système ou applicatif, géré par votre hébergeur (qui pourra vous répondre : "non j’ai pas envie") ?

On pourrait continuer longtemps… Si le serverless, comme n’importe quel outil, a des usecases qui lui sont particulièrement favorables, les usecases où il ne vaut mieux pas en faire sont pour l’instant encore nombreux…

Toujours plus…

Et dans la courbe de la hype, on peut monter plus haut.

Depuis quelque temps je vois aussi tourner des articles sur le NoOps. Si vous ne voyez pas de quoi il s’agit ce n’est pas grave, personne ne s’accorde vraiment sur ce que c’est. Moi je le vois comme l’évolution dystopique du DevOps dans laquelle les Devs ne parlent même plus avec les Ops puisqu’il n’y en a plus :-p.

Pas encore assez hype ?

Pas de souci, je vous ajoute de l’IA et vous avez maintenant de l’AIOps

Artificial intelligence for IT operations (AIOps) refers to the automation of IT operations tasks through artificial intelligence (AI). AIOps platforms free ITOps and drive better business outcomes, by ingesting operations data to identify and resolve issues automatically.

Il ne manque plus que la blockchain et on peut crier Bingo !

Je vais même pas argumenter, je pense que c’est du même niveau que le no-code dont nous parle Olivier Poncet.

Pourquoi tant de haine ?

Derrière ces formules chocs qui m’annoncent la fin de mon métier, se cache, je pense, une part de méconnaissance de celui-ci et une part de gloubiboulga marketing.

Ça ne se limite pas au métier d’administrateur système, je pense que tous les métiers avec une "fonction support" (RH, juridique, etc) ont tendances à être vus négativement par les "utilisateurs" qui les sollicitent.

Et ça s’explique.

Les "utilisateurs" ne se préoccupent de l’infrastructure (ou autre) que quand il y a un problème. Ça génère forcément de l’agacement de tous les côtés. Les utilisateurs qui veulent qu’on les dépanne d’un côté, les admins qui doivent gérer le stress qu’on leur transmet tout en résolvant les problèmes vite mais sans empirer la situation de l’autre.

Mais il y a aussi les directions, qui considèrent parfois que ces fonctions "support" n’apportent pas de valeur à l’entreprise (contrairement au dev, qui développe de nouvelles features, monnayables).

Je le redis, ce dénigrement n’est pas limité aux admins. Tout métier "support" vit ce genre de situation, parfois injuste. Combien de fois j’ai entendu dire :

Les gens ne viennent que pour se plaindre, jamais nous remercier quand ça fonctionne…

On ne communique pas super bien non plus…

Bon, une fois que c’est dit, faut pas se voiler la face non plus.

Si on est incompris, c’est peut être un peu dû au fait que la réputation des admins barbus et peu amènes n’est pas toujours injustifiée ;-).

On manque très probablement aussi de bons communicants pour expliquer notre métier, ainsi que pourquoi tout ce que je vous ai cité plus tôt, c’est pour l’instant du bullshit en barre.

Pour avoir passé pas mal de temps en conf, mon opinion, c’est qu’il y a trop peu d’Ops en conf de Dev. Et pour ne rien arranger, il y a peu de conférences Ops (en France) du niveau de qualité et de diversité des sujets traités que dans les conférences de Dev.

Exception faite des conférences de libristes et/ou sécurité qui elles sont souvent très bien, les conférences "connues" d’Ops, c’est au mieux des retours d’expériences, au pire, l’événement d’un constructeur/éditeur (VMware, Microsoft, whatever). Dans ces dernières, on ne parle de rien d’autre que des nouveaux produits géniaux dudit constructeur/éditeur (SAP 29, Exchange 730)…

Pas de quoi intéresser un développeur, encore moins un manager.

J’ai rien prévu pour demain, mais… c’est déjà bien d’y penser.

Je vais pas me la jouer prédicateur… Quand je regarde comment l’informatique a changé depuis 2010, difficile de deviner ce que sera le métier en 2030. Pour autant, je suis quand même optimiste.

Il y a 10 ans, on m’a promis la fin du métier d’Ops. Force est de constater qu’aujourd’hui, c’est loin d’être vrai. Je dirais même que c’est le contraire, je pense qu’on n’a jamais autant eu besoin des Ops.

Oui, c’est maintenant trivial de déployer un serveur. Du coup, beaucoup de projets informatiques qui n’auraient pas pu se lancer (ou beaucoup moins vite), faute d’Ops pour bootstraper l’infra, se lancent. Toutes les tâches "sans valeur ajoutée" disparaissent peu à peu.

Mais pour autant, dès qu’un projet prend de l’ampleur, la réalité revient au galop : déployer, c’est facile ; maintenir, c’est une autre paire de manche ! Le fameux "Day 2 operations" que je vous ai cité un peu plus haut.

Pire ! Pour palier à la pénurie d’Ops, on a tendance à mettre en place des systèmes de plus en plus complexes (loadbalancers, clusters, virtualisation, multicloud, Kubernetes pour les plus foufous). Et plus les systèmes sont complexes, plus on se rend compte qu’il faut d’Ops pour les maintenir.

Roald Dahl à la rescousse

J’ai lu quelque part une comparaison qui m’a fait sourire car ça m’a rappelé mon enfance quand je lisais du Roald Dahl.

Au début du film de Tim Bruton Charlie à la chocolaterie, adapté du livre de Roald Dahl, le père de Charlie perd son travail à l’usine, remplacé par une machine (je sais plus si cette scène existe aussi dans le livre, sorry).

Le cloud et l’infrastructure as code sont 2 moteurs qui font évoluer de manière rapide le métier d’administrateur systèmes. Une partie toujours plus importante des tâches d’hier sont en train de disparaître (doucement) : le plus simple, le plus automatisable. D’où le fantasme que le métier va disparaître.

Mais en réalité, c’est que cela ne va pas nous conduire à moins de systèmes à maintenir, mais des systèmes plus complexes.

A la fin du film, le père de Charlie retrouve un emploi à l’usine, en tant que réparateur de la machine qui l’a remplacé.

Je le concède volontiers, cette comparaison est un peu triviale, mais je pense qu’il y a du vrai dans cette image, car c’est ce que je vis depuis 10 ans.

Cette transition vers moins de tâches à faible valeur ajoutée va nous permettre de dégager le temps des admins pour se concentrer sur tout ce qui a vraiment de la valeur ajoutée : l’architecture, l’amélioration continue, l’expertise lors de crises.

Alors, en attendant la fin du métier d’Ops, have fun ;)


Vous aimez ce blog ? Partagez-le avec vos amis !   Twitter Facebook Linkedin email

Vous pouvez également soutenir le blog financièrement :
Tipeee

19 comments

  1. Bonjour,

    Etant également dans l’Ops, je pense tout de même que plus les années passeront et moins nous serons nombreux alors effectivement pas au point de disparaître totalement. Mais l’automatisation, l’hybridation puis le cloud, viendront sans aucun doute diminuer nos effectifs et forcément réorienter certains dans de nouvelles carrières.

    1. Hello,

      Merci pour ton retour :)

      Si vraiment les effectifs diminuent (et ça sera très progressif), ça sera probablement sur les premiers niveaux (n0, n1). Soit ces personnes devront faire une montée en compétence (vers du n2 généraliste ou du n1 sur une techno cloud) soit ils devront faire autre chose, on est d’accord.

      Mais aujourd’hui, on est pas du tout dans ce cas de figure. Le métier est encore en tension extrême, bien plus qu’en 2010 d’ailleurs. C’est particulièrement vrai sur les postes avec le plus de technicité (ou senior). Donc avant qu’on ait besoin de passer sur d’autres types de métiers, je pense qu’il va se passer du temps.

  2. Hello,

    DEV puis SYSADMIN+DEV puis SYSADMIN depuis la fin du siècle dernier (je suis un dinosaure?), je confirme et je partage tes réflexions.
    On nous abreuve de nouvelles technologies qui la plupart du temps ne sont que de nouvelles implémentations (certes plus universelles et communautaires) de ce qu’on faisait déjà souvent (mais avec nos outils propres).
    Les « non Ops » veulent plus de pouvoir sur la production mais dès qu’il y a un problème il n’y a plus personne car pas de maitrise technique des infrastructures sous-jacentes.
    L’intégration, façon Lego, des différentes briques composant l’application se fait sans aucune maitrise de ces composants et généralement en oubliant l’intégration des mises à jours de ces composants dans les tests automatiques et la chaine CICD …

    Pour les fonctions « historiques », elles sont laissées à l’abandon (ça n’intéresse plus personne, c’est pas des technos valorisables sur le CV) ce qui mène au désastre pour l’entreprise quand elles rencontrent un problème.

    Effectivement on communique souvent mal, ce qui nous amène dans des situations ou les responsables ne voient qu’un centre de coût qu’il faut optimiser (entendre réduire)…
    D’ailleurs dans ces situations, si on fait un effort et qu’on présente les risques associés, il se trouvera souvent un porteur du risque pour l’accepter, qui se retournera vers vous de toute façon en cas de problème pour des actions en mode « pompier ».

    En tout cas merci pour le partage d’expérience.

  3. Ah ah on dit la même chose du métier de dev depuis 30 ans … on attend toujours le super système qui permettra d’exprimer ses idées devant le micro et transformera tout ça en 0 / 1.

    D’ailleurs ma conviction c’est qu’avec l’avènement de la fibre, les services vont se relocaliser. Tout comme on a connu le passage de l’ère du mainframe à celui de l’ordi individuel, pour internet on va connaître le passage de l’ère du cloud à autre chose, comment l’appeler ? L’informatique en bulles peut-être ? -> Et là pas de souci à te faire pour ton métier…

  4. Comme dans tous les domaines, l’automatisation va supprimer les postes les moins qualifiés. Les ingénieurs, capables de suivre la vague, seront encore plus utiles, moins nombreux, et mieux payés. On a déjà perdu les pupitreurs il y a très longtemps. Ensuite, ç’a été le tour des analystes programmeurs et de plein de petits métiers du mainframe. Avec cette disparition, on a envoyé au chômage plein de techniciens, max bac + 2. Regarde les annonces d’infra aujourd’hui, c’est bac + 5 minimum pour presque tout !

    Avec le cloud, ce qui va morfler, c’est les boulot d’administration système N1/N2. Des gens qui font du MCO, du petit dépannage et escaladent ensuite aux N3 qui font l’analyse de fond et planifient les évolutions nécessaires. Cette population va diminuer. Doucement, bien sûr, mais les stats sont là : en passant sur des services managés et/ou kubernetes, tu divises ton taux d’incidents par 2, 5 ou 10. Ton directeur, il voit les stats Jira tous les mois et il calcule son budget en fonction.

    1. Oui c’est le risque en effet. Mais bon, on disait déjà ça en 2010, et il fallait déjà minimum un bac+5 pour aller modifier des mots de passes root sur des instances de Dev à la chaîne chez Sogeti (je sais car je l’ai fais).

      Il y aura toujours des N0/N1, mais effectivement pour la majorité il va falloir peut être monter en compétence.

  5. Depuis le temps que n’en parle. Merci pour le coup de com’.
    Le code tel qu’il est fait dans le monde professionnel est une catastrophe. En plus de plus en plus d’entreprises balancent leurs applications sur le cloud américain. Ils ne maîtrisent plus rien et donnent un pouvoir immense aux GAFAM. C’est complètement stupide sur le long terme par contre sur le court terme effectivement ça rapporte au DSI.

  6. Il y a aussi une chose que je remarque dans les grandes entreprises c’est qu’il y a un fossé entre les DevOps experts systèmes et les DevOps experts automatisation/algorithmique. Souvent les n3 qui bossaient avec moi faisaient les malins avec des codes complexes mais venaient pleurer dès qu’il fallait entrer dans le système. C’est pas avec le cloud que ça va s’arranger, le petits jeunes que je vois connaissent le vocabulaire imbitable AWS, Azure, Gcloud mais sont des quiches en système Linux.

  7. Pour terminer, j’ai bossé dans le plus grand groupe de sécu / défense informatique de France voire d’Europe. Et ben les gars sont tellement à l’arrache au niveau système qu’ils s’étaient « enfermés dehors » avec des règles pam qui se contredisaient. J’en rigole encore, ils galéraient depuis deux ans avant que j’arrive et règle le prb en deux jours. Donc je vous le dis clairement oui on va vers le tout dev, vers le tout Cloud MAIS ÇA VA ETRE UNE CATA.

  8. GPT-3 arrive, il va mettre par terre le OPS, le DEV, le SEC, tout tout tout

    Il ne restera plus qu’une grande matrice, qui poursuivra des DEVOPS en panique

  9. Merci Zwindler pour ce billet,

    Lorsque j’ai lu il y a quelques jours l’article d’Olivier, j’ai presque voulu ouvrir un blog pour exprimer exactement ce ressenti. Et tu l’as fait !
    En plus de couter de l’argent sans en produire (Centre de cout), nous sommes une contrainte et un calvaire pour tous les devs qui souhaitent toucher à la production. La sécu, c’est la même chose et clairement, nous ne communiquons pas assez sur l’importance de nos métiers.

    Quand le DG demande aux devs pourquoi la feature n’est toujours pas livrée, c’est toujours de la faute des SecOps, alors inventer, proposer et vendre un système sans Ops, une culture sans Ops (du DevOps/NoOps/AiOps) et permettre aux Devs de faire tout, tout seul et surtout comme ils veulent, c’est l’idée Marketing du siècle et des 10 ans à venir, ça marche tellement bien …

    Mais les limites et la réalité reviennent toujours très vite, surtout lorsqu’il y a un problème, allo les pompiers …
    Encore merci pour cet article !

    1. :)
      Non, je ne suis pas d’accord, la sécu, eux, nous empêche vraiment de travailler qu’on soit ops ou dev voir même sec ! ( Blague )
      :)

  10. Très bon article en effet j’aurais par contre quelques remarques : l’ops tel qu’il existait en grande majorité dans les 1980/1990 a disparue (comme le dev d’ailleurs). C’est toujours nommé ops mais c’est clairement pas le même métier !

    Et je pense pas que ce soit un problème de « les ops sont un coût », versus les devs. La majorité des boîtes voient l’IT comme un coût, et un coût ça se réduit, point!

    Ensuite je dirais qu’on voit en IT la même chose que dans plein d’autres métiers : une dichotomie de plus en plus marqué entre les gens hyper compétents et les gens très peu compétents. Je vois pas les n0/n1 disparaître, ils parlent au clients… Ce sera juste plus du tout des ops! Et de l’autre côté on aura des mecs hyper compétents capables de gérer la complexité des systèmes informatiques qu’on crée aujourd’hui. Et c’est le milieu qui disparaîtra (ce qui est déjà pas mal le cas).

    Comme tu le dis plein de gens semblent dire qu’on peut faire disparaître la complexité d’un système. Ce qui est faut.
    Le chemin du micro service c’est enlever de la complexité dans le dev de features pour la mettre dans du côté ops/software factory. Ou les tâches simples sont de plus en plus automatisées.

    Quand j’ai commencé l’info comme dev, ne pas savoir comment fonctionneait ton compilateur de ton langage était presque impossible. Aujourd’hui combien de devs JavaScript, python, etc savent comment fonctionne leur langage?

    Si on continue sur cette lancée les ops ou les devs ne disparaîtront pas, c’est jusqu’il y aura des mecs supra compétents payés une fortune car rare et des armées « d’intégrateur » ayant très de compétences et donc de valeur.

  11. Si je te dis que je vois les ops un peu comme des « devs infra », tu me prends pour un troll ou tu vois l’image ?
    Le boulot ne va pas disparaitre tout de suite, il va bien évoluer (comme depuis le début), et je te rejoins totalement sur le day 2. Pour beaucoup de gens/projets, le managé est largement suffisant et ils n’ont pas besoin de maitriser ce qu’il y a sous le capot. Pour les boites avec des projets conséquents, il est indispensable d’avoir des gens compétents pour tuner le système, et gérer les problèmes.
    La notion de centre de cout, ça me fait penser à la démarche qualité (madame en a fait son métier), ça coute cher jusqu’à ce que ça serve, après, c’est cadeau par rapport à ce que ça a évité ;). C’est un peu comme une assurance, sans vouloir être réducteur.

  12. Bonjour,
    « L’histoire de la poule et de l’oeuf ! »

    Il ne faut pas oublier que des Ops, il y en a dans les boîtes qui proposent leurs services « Cloud ».

    Pour proposer des services automatisés simplifiés, simplificateurs voir simplistes, il a bien fallut les créer, les développer, les déployer et puis les maintenir, les upgrader, … par des Ops, des DevOps, …
    Les services externalisés ne sont que des anciens services internes, qui ont été repris à coût de promesses d’économies faramineuses ! Pour bien moins de fonctionnalités au final, parce que sinon il faudra faire un avenant Monsieur le client…

    Les entreprises qui font du « on promise », ne se rendent pas compte de la richesse, de la souplesse, du dévouement de leurs employés. Oui ça coûte ces services internalisés mais c’est flexible, c’est performant, les compétences se consolident au fil du temps. Ah oui il faut des bons managers, des bonnes organisations pour que ça marche.
    Quand on achète du service, on ne sait pas ce qu’il y a derrière (boîte noire) : compétences, ressources, infra, confidentialité… On oublie bien souvent la gestion à long terme : documentation, retour-arrière, réversibilité… au profit du prix, des indicateurs colorés tout jolies…
    Mais tout cela n’est qu’un éternel recommencement : centralisation, décentralisation, cent…
    Pour finir, on oublie bien souvent que derrière ces mutations, il y a des gens et des vies, et pas seulement du matos.
    Ces personnes ne peuvent pas si facilement se « reformater » pour devenir quelqu’un d’autre du jour au lendemain !
    Seb

Leave a Reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.