NetApp gab kürzlich bekannt, dass das Unternehmen eigene Services und Appliances im Entwicklungsprozess einsetzt – ein Vorgehen, das mancherorts als „eigene Produkte im Einsatz“ bezeichnet wird. Die Art und Weise, wie NetApp seine Tools intern nutzt, bietet eine interessante Fallstudie für alle, die den Einsatz von NetApp erwägen. Im vergangenen Jahr hat das Unternehmen zahlreiche neue Produkte und Updates veröffentlicht. So brachte NetApp beispielsweise erst letzten Monat den NetApp AFA EF600 auf den Markt, ein durchgängiges NVMe-Server-Rack mit Flash-Speicher.
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.
Amazon