Kürzlich gab NetApp bekannt, dass es im Rahmen seines Entwicklungsprozesses eigene Dienste und Geräte nutzt, was manchmal als „Essen Ihres eigenen Hundefutters“ bezeichnet wird. Ihre Geschichte darüber, wie sie ihre Tools intern nutzen, ist eine interessante Fallstudie für jeden, der über die Einführung von NetApp nachdenkt. Im vergangenen Jahr waren sie ein Dynamo für Neuerscheinungen und Updates. Um nur ein Beispiel zu nennen: Sie haben ein All-Flash-End-to-End-NVMe-Server-Rack herausgebracht, das NetApp AFA EF600, erst letzten Monat.
Kürzlich gab NetApp bekannt, dass es im Rahmen seines Entwicklungsprozesses eigene Dienste und Geräte nutzt, was manchmal als „Essen Ihres eigenen Hundefutters“ bezeichnet wird. Ihre Geschichte darüber, wie sie ihre Tools intern nutzen, ist eine interessante Fallstudie für jeden, der über die Einführung von NetApp nachdenkt. Im vergangenen Jahr waren sie ein Dynamo für Neuerscheinungen und Updates. Um nur ein Beispiel zu nennen: Sie haben ein All-Flash-End-to-End-NVMe-Server-Rack herausgebracht, das NetApp AFA EF600, erst letzten Monat.
Sowohl die SolidFire- als auch die Hyper-Converged Infrastructure (HCI)-Engineering-Teams von NetApp nutzen NetApp HCI-Appliances und -Software als Teil ihrer Entwicklungspipeline. Die Teams verwenden Jenkins, um Continuous Integration (CI)- und Deployment-Builds zu generieren. Diese Builds werden dann über den NetApp Kubernetes Service (NKS) bereitgestellt, der auf NetApp HCI-Appliances mit aktivierter Hybrid Cloud Control Suite ausgeführt wird. Mithilfe von NKS können die Entwicklungsteams ihre Builds in die öffentliche Cloud übertragen, die ihren Anforderungen derzeit am besten entspricht: Amazon EC2, Google Cloud Platform (GCP) oder Azure. Häufiger verwenden die Teams ein Istio-Service-Mesh, um Builds in mehreren Clouds bereitzustellen und so eine hybride Multi-Cloud-Anwendung bereitzustellen, die das gleichzeitige Testen mehrerer Ziele ermöglicht. NetApp behauptet, dass dieser Prozess es ihnen ermöglicht hat, den Zeitaufwand für die Einrichtung neuer CI/CD-Pipelines (Continuous Integration und Continuous Deployment) für den internen Gebrauch um bis zu zwei Größenordnungen zu reduzieren. Das ist eine wirklich enorme Zeitersparnis, und ich wünschte wirklich, sie hätten die Zahlen, auf die sie diese Behauptung stützen, öffentlich gemacht.
NetApp räumt in seinem Artikel ein, dass noch einige Vorarbeiten für die Entwicklung der Build-Pipelines, die in ihre Data-Fabric-Architektur einfließen, geleistet werden mussten, aber nachdem ich selbst Wochen damit verbracht habe, (CI/CD-)Pipelines einzurichten, besteht die Aussicht auf eine so erhebliche Zeitersparnis und Vereinfachung Dieser Prozess ist sehr ansprechend. Darüber hinaus ermöglicht die Verlagerung von Builds in die öffentliche Cloud, sobald sie eingerichtet ist, dass die Lösung auf nahezu jede Teamgröße skaliert werden kann.
Melden Sie sich für den StorageReview-Newsletter an
