Bonjour Léo, Je n'avais pas vu ton message, car off pendant un long moment pour des raisons perso.
Je te remercie pour ta réponse. Je suis tout à fait d'accord avec toi sur le vocabulaire et autres problèmes que tu évoques autour de l'appropriation. Le DevOps n'est une pratique tech, mais avant tout une culture. La définition et la vision de base du DevOps était claire. C'es l'absence de normalisation qui a entrainé un peut tout et n'importe quoi. C'est ce souci de normalisation que le platform engineering vient résoudre, et ce n'est pas parce qu'on essayera d'adopter des outils et/ou méthode communs, mutualisés, qu'on ne fera pas du sur mesure, ou que les experts vont sortir de leurs domaines de prédilection. Simplement ils vont non plus faire à la place des autres, mais plutôt faire pour rendre les autres autonome, à travers de l'abstraction. Kubernetes que tu as évoqué, le cloud, sont de bons exemple d'abstraction, mais ça reste des outils, qui doivent servir une vision stratégique, et non pas la vision elle-même. Le DevOps n'est pas un sujet exclusivement tech, ça doit viser avant tout l'optimisation opérationnelle de la chaîne de valeur, et le domaine du réseau n'en n'est pas exclus. On pourrait en discuter plus longuement , mais en dehors de ce thread afin de ne pas trop s'écarter de l'objet même. Merci encore pour ta réponse. Cordialement, Eugène NG Le jeu. 5 oct. 2023 à 14:36, Léo El Amri via frnog <frnog@frnog.org> a écrit : > Bonjour Eugène, > > On a bien reçu ton message, mais j'imagine que c'est un peu hors-scope > dans la FRnOG. > > Mon avis sur la question (en tant que développeur - quelqu'un qui > conçoit un logiciel (pas juste qui le programme, on appellerait ça un > programmeur sinon)), c'est que tu montres par toi-même que tout ça est > incompréhensible tant qu'on ne définit pas les termes qu'on emploie au > cas par cas. Pendant un temps on disait que les DevOps était la capacité > d'un "développeur" à faire de l'administration système, puis petit à > petit c'est devenu l'automatisation de processus de développement (tests > automatisés, vérification de la qualité de code, etc.). Pour ces > questions de vocabulaire flou, je ne peux pas réagir sur les > "anti-patterns" du DevOps. Ils peuvent être vrai ou faux en fonction de > la définition du mot. > > Le "Platform Engineering" ne change rien au problème, ça sera, à mon > avis, encore une expression utilisée à tort et à travers. > > On m'a souvent mit l'étiquette DevOps (je ne sais pas pourquoi) et je > n'ai jamais fait de "cloud" à proprement parlé, chose qui était plutôt > réservées à des équipes d'administration système (ceux qui gèrent des > hyperviseurs de VMs ou du K8S en entreprise, par exemple). Ce à presque > toute taille d'entreprise (les toutes petites ne peuvent pas se > permettre d'avoir des salariés dédiés à certaines tâches, mais les > autres semblent le pouvoir). > > En sachant que je ne suis pas admin réseau : > > Je ne pense pas que les administrateurs réseau soient spécifiquement > concernés par la question du "platform engineering". > > Pour faire du GitOps, il faut pouvoir définir ton infra par du texte, ce > qui n'est pas toujours possible. Ce n'est pas une solution miracle, tout > comme ne le sont pas le DevOps, le SecOps et autres DevNetSecOps++. > > Pour moi, faire travailler un ensemble de gens spécialisés chacun dans > un domaine, avec un outil commun et une méthode de définition d'infra > commune, c'est sympa mais pas toujours possible. Ça s'appelle l'IaaS, et > on ne le retrouve pas forcément dans tous les cloud, et dans ceux qui le > pratiquent ça ne se retrouve pas à tous les niveaux. > > Pour le reste, ce que j'ai constaté en tant qu'acteur externe aux > équipes réseau, c'est que c'est bien souvent séparés et que les équipes > réseau n'utilisent pas les outils des équipes système, qui n'utilisent > pas les outils des équipes développement logiciel. > > La seule fois où j'ai vu un système commun pour tout le monde (dans une > boite du CAC40), c'était lourd et tout le monde s'en plaignait. > > Je pense que la clef dans tout ça, serait que les admin-sys restent > experts de leur domaine, que les admins-réseau restent experts de leur > domaine, et que les développeurs soit pluridisciplinaires et aient des > connaissances de base sur le système et sur le réseau. > > Je trouve que les objets définis de base dans K8S offrent un découpage > assez raisonnable des différentes responsabilités au sein d'une SI. > > - Léo > > On 06/09/2023 16:35, Eugène Ngontang wrote: > > Hello, > > > > Mon mail a été bloqué par l'équipe de modération ou alors il est > totalement > > hors scope pour tout le monde? > > Ou bien il vaut mieux le formaliser sous forme de survey? > > > > Cordialement, > > Eugène NG > > > > Le mer. 23 août 2023 à 03:11, Eugène Ngontang <sympav...@gmail.com> a > > écrit : > > > >> Hello tout le monde. > >> > >> Je reviens sur le sujet du DevNetOps, cette fois sous le prisme de la > >> gestion du cycle de vie de développement logiciel (SDLC) en > environnement > >> cloud privé, mettant à contribution les équipes réseaux et système. > >> > >> En effet, je vais me permettre de rappeler que le DevNetOps ou NetOps ou > >> encore NetDevOps, est l'application des pratiques DevOps aux opérations > >> réseaux. Plus simplement ça vise principalement l'automatisation des > >> opérations réseaux. > >> > >> Ainsi tout comme le DevOps a ouvert la porte aux anti-patterns, le > >> DevNetOps a sûrement fait pareil. Quelques exemple d'anti-patterns : > >> > >> - Le DevOps coincé entre les Dev et les Ops > >> - le NoOps des Dev qui n’ont pas besoin d’Ops > >> - le DevOps est un outil > >> - le SysOps ou le NetOps dont on a juste changé le nom en DevOps, > >> - L’Ops intégré dans l’équipe Dev, > >> - … > >> > >> C'est pour palier à tous ces écarts que l'on parle beaucoup plus du > >> Platform Engineering (buzzword de 2023), dont le but n'est pas de > >> substituer au DevOps, mais de l'implémenter correctement. > >> > >> Cependant la tendance est toujours d'aborder ces concepts xOps avec une > >> vision cloud (public cloud) native, ce que je trouve personnellement > très > >> limitant. Alors ma question ou alors mes questions, dont les réponses > >> dépendront bien sûr des entreprises/organisations et uses cases. : > >> > >> - Quid du platform engineering pour les gurus du réseau ? > >> > >> - Est ce que vous vous contentez d'automatiser et orchestrer > >> exclusivement les flux de provisioning/déploiement réseau en > traitant le > >> réseau comme un produit, une application avec son propre SDLC? > >> > >> - Est ce que vous fournissez plutôt des landing zones : *backbone > >> fiable, hautement flexible et pérenne pour le développement > d’applications > >> et de solutions de l'entreprise, à disposition des équipes métiers, > >> systèmes, développement *? > >> > >> - Privilégiez-vous l'approche GitOps? Si oui mettez-vous en place > une > >> sorte de GitOps Self-Service UI, permettant aux équipes de disposer > >> d'environnements techniques à la demande. Et si oui qui sont vos > clients en > >> interne? Dev, Sys ou Métier? > >> > >> - Avez-vous des enjeux relatifs à la gestion du provisioning, des > >> changements, intégration (CI) et déploiement de bout en bout > incluant > >> toutes les parties prenantes : Système (VM, OS), Développeurs (code > >> logiciel)? > >> > >> - De manière plus générale : Est ce que vous vous contentez > >> d'automatiser le provisioning et la configuration du réseau avec > vos outils > >> et vos workflows à vous, indépendamment des usages, outils, > workflows des > >> équipes systèmes et développement? > >> > >> - Enfin, pourriez-vous utiliser une plateforme de services managés > en > >> ligne (PaaS) résolvant toutes ces problématiques de fluidification > et > >> d'orchestration des flux, plutôt que de construire la vôtre en > interne? Si > >> oui quelles seraient vos attentes et vos exigences en termes > d'adoption et > >> d'assurance qualité vis à vis d'une telle plateforme en ligne? > >> > >> Merci pour avance pour votre attention et vos contributions sur le > sujet. > >> > >> Très cordialement, > >> Eugène NG > >> > >> -- > >> LesCDN <http://lescdn.com> > >> engont...@lescdn.com > >> ------------------------------------------------------------ > >> *Aux hommes il faut un chef, et au* > >> > >> * chef il faut des hommes!L'habit ne fait pas le moine, mais lorsqu'on > te > >> voit on te juge!* > >> > > > > > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- LesCDN <http://lescdn.com> engont...@lescdn.com ------------------------------------------------------------ *Aux hommes il faut un chef, et au* * chef il faut des hommes!L'habit ne fait pas le moine, mais lorsqu'on te voit on te juge!* --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
