NoOps: per alcuni è la fine di DevOps. Ma cos’è esattamente NoOps? I professionisti DevOps devono realmente temerlo?
Non fai in tempo ad abituarti al concetto di DevOps, che subito arriva qualcuno a parlarti di NoOps. Addirittura scopri che lo sta facendo da diversi anni. Già nel 2011, infatti, Mike Gualtieri di Forrester Research scrisse un articolo, intitolandolo I don’t want DevOps. I want NoOps. È dunque la fine del mito DevOps, prima ancora che qualcuno abbia avuto il tempo di portarne a maturità il modello? Non è detto. Forse NoOps e DevOps sono due risposte, altrettanto valide, allo stesso problema. Questione di contesto, come sempre.
In ogni caso oggi il dibattito tra le due metodologie è ancora aperto e molti professionisti DevOps si chiedono se il loro sia un ruolo ancora rilevante all’interno del mercato IT. Proviamo dunque a fare un po’ di chiarezza, cominciando dalle questioni terminologiche.
Che cosa si intende per NoOps?
Con DevOps si è assistito all’abbattimento delle barriere tra team di sviluppo e team addetto alle operations, in favore di una migliore collaborazione e comunicazione, atta a velocizzare il processo di deployment dei prodotti software e a garantirne una qualità superiore. Ne abbiamo parlato anche recentemente, qui.
Ogni rilascio del software prevede, con DevOps, un insieme di attività: monitoring, logging, testing. Le pipeline CI/CD avviano unit test; i deploy sono automatici. Sysadmin, tester e personale con mansioni gestionali sono coinvolti fin dal principio sui progetti, assicurando che tutti i controlli e gli obiettivi siano effettivi prima che il prodotto sia rilasciato e sia troppo tardi per ulteriori modifiche.
Dev + Ops = DevOps, No + Ops = NoOps
L’obiettivo di NoOps è ancora quello di migliorare il processo di deployment, ma senza che sviluppatori e system administrators debbano necessariamente collaborare e comunicare, in modo da risparmiare il tempo speso durante tali interazioni.
L’idea è che lo sviluppatore si limiti alla sola scrittura del codice (in Node, Ruby, Java, Python, …), effettui il push delle modifiche a tale codice utilizzando una CLI, Github o in generale un approccio di continuous integration, e un appropriato sistema di build produca automaticamente l’applicazione corrispondente, già pronta per essere eseguita. Quindi l’approccio al rilascio del software cambia: gli sviluppatori possono concentrarsi completamente nella creazione delle applicazioni, senza essere distratti dalle questioni riguardanti l’infrastruttura.
Come raggiungere gli obiettivi di NoOps?
Esistono già sul mercato diverse soluzioni PaaS (Platform-as-a-Service) che permettono a qualsiasi sviluppatore senza alcuna esperienza in campo operation di avviare le applicazioni senza alcun aiuto esterno: è la piattaforma stessa ad automatizzare il processo di deployment a partire dai commit.
I team di operation, dunque, si limiterebbero alla preparazione di queste infrastrutture, fornendo agli sviluppatori tutti gli strumenti di cui hanno bisogno per poter rilasciare i prodotti software in modo veloce e privo di ulteriori interventi esterni.
Tali piattaforme, in generale, si occupano di fornire un insieme di servizi per l’orchestrazione e la gestione dell’esecuzione, e scalano l’infrastruttura in risposta alle esigenze dell’applicazione.
Il prodotto può inoltre essere esteso con un’ampia varietà di funzionalità, come logging, monitoring e data storage. La piattaforma amministra tutte le risorse di elaborazione, la manutenzione dei server e dei sistemi operativi.
I casi di Heroku, CloudFoundry e AWS Lambda
Esistono già diverse soluzioni PaaS che corrispondono alle caratteristiche appena descritte.
Heroku è una piattaforma cloud che esegue le applicazioni all’interno dei cosiddetti dynos, ovvero Linux containers. Quando viene effettuato il deploy di un’app su Heroku, il codice sorgente viene impacchettato insieme alle relative dipendenze all’interno di un dynos, in modo da avere un ambiente leggero e isolato dalle altre applicazioni. Per poter effettuare il deploy, Heroku ha essenzialmente bisogno di tre elementi dallo sviluppatore: codice, lista delle dipendenze e un Procfile, ovvero un file di testo contenente il comando da lanciare per avviare l’applicazione.
Build
Il sistema di build automatico, a partire da tali elementi, produce un cosiddetto slug, contenente tutto ciò che occorre per eseguire l’applicazione, ad eccezione del sistema operativo. Per avviare l’applicazione, lo slug viene incorporato all’interno di un dyno, e viene invocato il comando specificato nel Procfile. Durante l’esecuzione, è possibile aumentare e diminuire manualmente il numero di dynos in risposta alle necessità dell’applicazione stessa: il loro lifecycle invece è completamente gestito dalla piattaforma, in modo del tutto trasparente allo sviluppatore.
CloudFoundry è una delle piattaforme più mature nell’ambito delle applicazioni container-based. In particolare, permette di effettuare il deploy di qualsiasi applicazione, scritta in qualsiasi linguaggio, su diverse infrastrutture cloud. Il vantaggio è quello di avere a disposizione tecnologie moderne come Docker e Kubernetes, che permettono di facilitare e velocizzare la gestione di prodotti software production-grade, ovvero di orchestrare i container.
Abbiamo poi AWS Lambda, un servizio di elaborazione di tipo serverless che esegue codice in risposta a determinati eventi e gestisce in modo automatico le risorse di elaborazione utilizzate, fornendo supporto anche in termini di logging, monitoraggio, scalabilità. Lo sviluppatore si limita a fornire il codice da eseguire, che nel gergo di AWS viene detto “Lambda function”. Una volta configurati i requisiti prestazionali, la funzione è attiva e pronta ad essere avviata in qualsiasi momento.
Può essere associata ad altri componenti AWS, per esempio bucket di S3, notifiche di SNS (Simple Notification Service). Al variare di tale componente, Lambda eseguirà la funzione e gestirà le risorse di elaborazione in modo da soddisfare le esigenze dettate dalle richieste in entrata.
Che cosa dobbiamo aspettarci?
Non tutte le applicazioni sono adatte alle moderne soluzioni PaaS.
Molte aziende si basano ancora su prodotti legacy e monolitici, e passare ad una completa automazione da questo punto di vista implicherebbe una serie massiva di aggiornamenti o modifiche del codice sorgente per poter rendere tali applicazioni compatibili con infrastrutture self-service, continuous integration e deployment. Inoltre, è chiaro che col tempo nasceranno anche ulteriori tecnologie, e che non tutte saranno comunque compatibili con le soluzioni fornite da NoOps.
Oltre a questa problematica, rimane forte il dubbio di molti sulla completa eliminazione dell’intervento da parte dei team di operation. La necessità di un qualcuno che si occupi della gestione delle infrastrutture rimane, pur affidandosi a un cloud provider. Rimane anche il bisogno di gestire le informazioni su chi utilizza i servizi, sul modo in cui vengono effettivamente utilizzati, e i costi correlati.
È un bene affidare tutte queste responsabilità agli sviluppatori?
Conclusioni
Sembra chiaro che i tempi con cui NoOps prenderà (eventualmente) piede non sono chiaramente definibili. Inoltre, dato che i principi che muovono NoOps ricalcano molto quelli di DevOps, non possiamo definirlo come la sua fine, ma piuttosto come una sua evoluzione, l’inizio di una serie di innovazioni basate sugli stessi obiettivi della cultura DevOps, che porteranno sì ad un cambiamento nel modo di operare, ma non riusciranno a svincolare totalmente i team di sviluppo da quelli sistemistici. NoOps non può essere definito come una nuova metodologia di ingegneria del software. È un’opportunità, un qualcosa che si può ottenere solo grazie ai progressi del software stesso.
