Recentemente, NetApp ha rivelato che utilizza i propri servizi e dispositivi come parte del suo processo di sviluppo, qualcosa che a volte viene definito come "mangiare il proprio cibo per cani". La loro storia su come utilizzano i propri strumenti internamente costituisce un caso di studio interessante per chiunque stia pensando di adottare NetApp. L'anno scorso sono stati una dinamo di nuove versioni e aggiornamenti. Tanto per fare un esempio, hanno rilasciato un server rack NVMe end-to-end all-flash, il NetApp AFA EF600, proprio il mese scorso.
Recentemente, NetApp ha rivelato che utilizza i propri servizi e dispositivi come parte del suo processo di sviluppo, qualcosa che a volte viene definito come "mangiare il proprio cibo per cani". La loro storia su come utilizzano i propri strumenti internamente costituisce un caso di studio interessante per chiunque stia pensando di adottare NetApp. L'anno scorso sono stati una dinamo di nuove versioni e aggiornamenti. Tanto per fare un esempio, hanno rilasciato un server rack NVMe end-to-end all-flash, il NetApp AFA EF600, proprio il mese scorso.
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.
Iscriviti alla newsletter di StorageReview
