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/
