Di recente, NetApp ha rivelato di utilizzare i propri servizi e dispositivi come parte del suo processo di sviluppo, un approccio che a volte viene definito "usare la propria tecnologia internamente". La loro esperienza nell'utilizzo dei propri strumenti rappresenta un interessante caso di studio per chiunque stia valutando l'adozione di NetApp. Nell'ultimo anno, l'azienda è stata un vero e proprio vulcano di nuove release e aggiornamenti. Ad esempio, il mese scorso ha lanciato il NetApp AFA EF600 , un rack per server NVMe end-to-end interamente basato su memoria flash.
Sia i team di ingegneri di SolidFire che quelli dell'infrastruttura iperconvergente (HCI) di NetApp utilizzano i dispositivi e il software HCI di NetApp come parte della loro pipeline di sviluppo. I team utilizzano Jenkins per generare build di integrazione continua (CI) e distribuzione. Queste build vengono quindi distribuite tramite NetApp Kubernetes Service (NKS) in esecuzione su dispositivi NetApp HCI con la suite di controllo del cloud ibrido abilitata. L'utilizzo di NKS consente ai team di ingegneri di inviare le proprie build al cloud pubblico che meglio si adatta alle loro esigenze in questo momento, Amazon EC2, Google Cloud Platform (GCP) o Azure. Più spesso i team utilizzano una rete di servizi Istio per distribuire build su più cloud per fornire un'applicazione multi-cloud ibrida che consenta di eseguire test su più target contemporaneamente. NetApp sostiene che questo processo ha consentito loro di ridurre di ben due ordini di grandezza il tempo impiegato per avviare nuove pipeline di integrazione continua e distribuzione continua (CI/CD) per uso interno. Si tratta di un risparmio di tempo davvero enorme e vorrei davvero che avessero reso pubblici i numeri su cui basano questa affermazione.
NetApp riconosce nel suo articolo che aveva ancora bisogno di fare del lavoro iniziale per sviluppare le pipeline di build che alimentano la loro architettura data fabric, ma avendo passato settimane a configurare io stesso le pipeline (CI/CD), la prospettiva di un risparmio di tempo e di una semplificazione così significativi per questo processo è molto interessante. Ancor di più, come una volta impostato, il trasferimento delle build sul cloud pubblico in questo modo consente alla soluzione di espandersi per gestire team di quasi tutte le dimensioni.
Amazon