Récemment, NetApp a révélé utiliser ses propres services et équipements dans son processus de développement, une pratique parfois qualifiée de « tester sa propre nourriture pour chien ». Leur utilisation interne de ces outils constitue une étude de cas intéressante pour quiconque envisage d'adopter NetApp. L'année dernière, l'entreprise a été particulièrement dynamique en matière de nouvelles versions et de mises à jour. À titre d'exemple, elle a lancé le mois dernier le NetApp AFA EF600 , un rack serveur 100 % flash NVMe de bout en bout.
Les équipes d'ingénierie SolidFire et d'infrastructure hyperconvergée (HCI) de NetApp utilisent les appliances et les logiciels NetApp HCI dans le cadre de leur pipeline de développement. Les équipes utilisent Jenkins pour générer des builds d'intégration continue (CI) et de déploiement. Ces versions sont ensuite déployées via NetApp Kubernetes Service (NKS) exécuté sur des appliances NetApp HCI avec la suite de contrôle de cloud hybride activée. L'utilisation de NKS permet aux équipes d'ingénierie de pousser leurs builds vers le cloud public qui répond le mieux à leurs besoins du moment, Amazon EC2, Google Cloud Platform (GCP) ou Azure. Le plus souvent, les équipes utilisent un maillage de services Istio pour déployer des builds sur plusieurs clouds afin de fournir une application hybride multi-cloud permettant de tester sur plusieurs cibles à la fois. NetApp affirme que ce processus leur a permis de réduire de deux ordres de grandeur le temps consacré à la création de nouveaux pipelines d'intégration et de déploiement continus (CI/CD) pour leur usage interne. C'est un gain de temps vraiment énorme, et j'aurais vraiment aimé qu'ils rendent publics les chiffres sur lesquels ils fondent cette affirmation.
NetApp reconnaît dans leur rédaction qu'ils avaient encore besoin de faire un travail initial pour développer les pipelines de construction alimentant leur architecture de structure de données, mais après avoir passé des semaines à configurer moi-même des pipelines (CI / CD), la perspective d'un gain de temps et d'une simplification aussi importants pour ce processus est très attrayant. D'autant plus qu'une fois mis en place, pousser les builds vers le cloud public de cette manière permet à la solution de s'adapter à presque toutes les tailles d'équipe.
Amazon