No results found
Stiamo vivendo una forte evoluzione nel mondo dello Sviluppo Software, nella quale sempre di più la figura professionale dello sviluppatore prende forza e si sta evolvendo a causa del costante arrivo sul mercato di nuove soluzioni tecnologiche, tali da facilitare allo sviluppatore il modo in cui lui lavora. Oggi lo sviluppatore può quasi fare a meno del tradizionale sistemista, tanto che a questo punto ci possiamo porre la domanda: sta arrivando la fine del ruolo del System administrator o amministratore di sistema che dir si voglia?
Prima di rispondere a questa domanda andiamo a capire quali sono le responsabilità di un sistemista attraverso: una job description, in qualche modo generica, del sistemista potrebbe vedersi in questo modo, ossia consta dei seguenti compiti:
In realtà un sistemista fa altre cose, soprattutto se la sua è una piccola realtà, ma si tratta di compiti che esulano dal discorso fatto in questa sede.
La tecnologia evolve rapidamente e bisogna innanzitutto comprendere quali sono i nuovi standard del mercato IT e quindi l’evoluzione delle soluzioni IT, perché è questa che sta cambiando il ruolo tradizionale del sistemista; le relative transizioni avvengono, in certi casi, molto rapidamente: se il passaggio dal fisico al virtuale è avvenuto in un periodo lungo, dalla virtualizzazione in poi c’è stato uno sviluppo esponenziale della relativa tecnologia, che ha visto nascere e utilizzare massicciamente i container e i loro gestori come Kubernetes, che è nato all’incirca sei anni fa e che nel tempo è stato sempre più utilizzato, sebbene sia stato preso in considerazione da poco più di due anni.
Il discorso sostanzialmente vuol dire che il tempo di adozione delle tecnologie, da quando nascono a quando diventano tanto affermate da cambiare la parte di IT cui si applicano, è molto breve, più che in altre “ere” dell’Information Technology
Ciò significa che chi fa un lavoro deve sempre essere in guardia, perché il suo ruolo può essere ridimensionato in pochi anni o scomparire del tutto. Questo discorso riguarda anche il sistemista, ed è logico chiedersi se può ritagliarsi uno spazio nel mondo e nell’era corrente, che è quella dei DevOps e dei System Architect.
Tra breve vedremo che ciò è possibile e di fatto è l’unica soluzione per il sistemista che voglia continuare a fare il proprio lavoro con profitto.
Per comprendere a pieno l’evoluzione in corso e capire se c’è ancora posto per il sistemista dobbiamo individuare quali sono i nuovi standard del mercato IT; l’immagine seguente può aiutare a capire come siamo passati dai server dedicati alle soluzioni successive e quale sarà il punto di destinazione, ovvero quale sarà l’evoluzione del mondo IT negli anni a venire.
Come vedete, siamo partiti dall’avere server fisici dove veniva fatto il deploy di un’applicazione e nel momento in cui c’era bisogno di deployare un’altra applicazione si prendeva un altro server, lo si metteva in un data center, si configurava l’insieme, lo si metteva in rete e si eseguiva su di esso la nuova applicazione.
In un secondo momento, con l’arrivo della virtualizzazione, su quello stesso server abbiamo diviso le risorse in macchine virtuali e ogni singolo progetto lo abbiamo messo su una singola macchina virtuale isolata dalle altre; la virtualizzazione ha quindi permesso di far “girare” più macchine virtuali su una reale, fisica, mantenendo distinte esse e le applicazioni che vi si eseguono.
Da questa architettura, che in un certo senso corrisponde al momento attuale, ci stiamo evolvendo verso container e microservizi, dove ci sono sempre delle macchine virtuali, però su di esse utilizziamo dei container attraverso un engine (gestore di container) che poi possono essere delle piccole macchine virtuali isolate tra loro, ovvero microservizi. L’adozione di questa tecnologia implica gli stessi vantaggi dell’utilizzo delle VM, ma con minore dispendio di risorse e tempi di avviamento ridottissimi.
Il futuro vedrà il passaggio dal punto 3 al 4 dello schema proposto, sebbene già oggi vi sia una timida adozione del serverless, ossia la fruzione di applicazioni ed ancor meglio funzioni (da qui il termine FaaS – Function as a Service, che vedete nel predetto schema) senza bisogno di preoccuparsi di un’infrastruttura IT.
Per il sistemista, il problema, già iniziato con la virtualizzazione basata su container e microservizi, si manifesta in modo palese qui, in quanto con le soluzioni serverless lo sviluppatore ha sempre meno bisogno di un sistemista; ciò perché il codice deployato su una soluzione serverless non ha bisogno di avere delle configurazioni dei server, in quanto lo sviluppatore serverless prescinde dall’elaborazione, dal sistema operativo o sistema di virtualizzazione e di containerizzazione che c’è dietro.
In questo scenario il ruolo del sistemista è fortemente ridimensionato, nel senso che lo sviluppatore praticamente non ne ha bisogno, o meglio, non quando deve sviluppare applicazioni; infatti per lo sviluppo di un progetto non servirà più il sistemista che implementa l’infrastruttura sulla base delle esigenze dello sviluppatore.
Il sistemista potrà continuare ad esistere, ma nel caso FaaS e serverless lavorerà per conto proprio, all’infrastruttura virtualizzata di un provider o farà esso stesso da provider, per far funzionare i sistemi.
Nel paradigma serverless c’è sempre un indirizzo dove caricare del codice o un’applicazione, però questa applicazione viene collocata nel Cloud: non si trova in uno storage specifico o in un database specifico creati apposta da un sistemista. Però nell’infrastruttura in cui verrà caricata ci sono comunque dei database e degli storage che si occupano di far eseguire il codice e di far andare avanti l’applicazione. Ebbene, per configurare e manuterere queste risorse serve un amministratore di sistema.
Quindi lo sviluppatore in realtà ha ancora bisogno del sistemista, ma in un modo differente: prima ne sfruttava il lavoro direttamente e in esclusiva, mentre con Cloud e FaaS tale lavoro gli serve ancora, ma indirettamente.
Stabilito che c’è un’evoluzione in corso, andiamo a vedere quali sono i motivi che spingono la tendenza a prediligere soluzioni a container e serverless, in modo da capire quale spazio può eventualmente ricavarsi il sistemista. Ebbene, tali motivi sono principalmente due:
Partiamo dal primo punto estendendo il concetto su IoT e dispositivi mobile, che impongono un incremento esponenziale nel tempo di dati prodotti da elaborare e di connessioni da gestire, che per ragioni pratiche dovranno essere centralizzate e portate in cloud e su grandi data center dove sono in esecuzione infrastrutture virtualizzate.
Le infrastrutture virtualizzate devono offrire scalabilità, per stare al passo con le richieste della clientela, ma anche resilienza, nel senso di garantire alla clientela che un servizo sul quale andrà a far eseguire le proprie applicazioni, un proprio sito ecc. sarà in grado di funzionare anche in caso di un server che va fuori uso. Qui il sistemista gioca un suo ruolo perché deve sviluppare infrastrutture scalabili e resilienti, oltre che manutenerle.
Non meno importante è la diffusione dell’automazione nelle applicazioni, finalizzata a ridurre le ore uomo e far eseguire in maniera automatizzata le attività ripetitive come il deploy; oltre che far risparmiare sull’intervento umano, l’automazione rende il lavoro più preciso in quando una volta che è stato messo a punto, un sistema di automazione fa sempre quel lavoro senza sbagliare un colpo.
Per quel che riguarda il deploy, mentre finora il sistemista è stato visto come il braccio destro dello sviluppatore, il quale quando aveva pronta un’applicazione creava il suo supporto con i file, che il sistemista prendeva, sul server che aveva già configurato per l’occasione e l’applicazione andava in esecuzione, oggi lo sviluppatore, in qualche modo, pur con l'aiuto del sistemista, tutto ciò lo sta automatizzando. Quindi oggi molti sviluppatori tendono a fare il deployment delle applicazioni da soli, ma per questo serve che un sistemista allestisca l’ambiente dove poterlo fare poi in completa autonomia.
Grazie a ciò, lo sviluppatore è in grado di sapere che una certa release che sta rilasciando, in produzione funzionerà correttamente perché prima di arrivare in produzione ha attivato un sistema di verifiche automatiche che ha già verificato che tutto quello che lui hai scritto è corretto e funziona; magari perché l’ha creato in un ambiente di test a container che gli dà la certezza che l’applicazione che gira su un container di prova (eseguito sulla macchina di sviluppo) funzionerà su altri container e in qualsiasi altra macchina che ospita la tecnologia a container.
Peraltro, anche se non si tratta di ambiente containerizzato, utilizzando la continuous integration lo sviluppatore sa già che una certa release funzionerà.
Oltre che ai cambiamenti nella tecnologia, il futuro del sistemista è vincolato ai cambiamenti negli investimenti IT da parte delle aziende. Siccome tendono ad andare in Cloud, molte aziende stanno riducendo l’acquisto di server, quindi hanno meno bisogno di sistemisti che se ne occupino, vale a dire che li installino, li configurino, ne facciano la manutenzione.
Un altro motivo del cambiamento nella destinazione degli investimenti è l’incremento delle spese in soluzioni pay-as-you-go e quindi a consumo, il che sta riducendo in pari misura le soluzioni a canone e quindi le entrate fisse per i sistemisti. Si parla quindi di soluzioni as a service, il cui mercato è ripartito in un 60% circa di SaaS (Software as a Service) di un 20÷25% di IaaS (Infrastructure as a Service) e la restante parte in PaaS (Platform as a Service). Questo significa che se un tempo si acquistava l’hardware e il software si pagava una volta o periodicamente per la licenza d’uso, ora praticamente si cerca di pagare solo l’utilizzo del software o un canone per l’affitto di un’infrastruttura.
Trasferendo questo discorso nell’ottica del sistemista, possiamo fare un esempio chiarificatore: se prima utilizzava un CRM, installandolo su un proprio server e poi andandolo a gestire a livello sistemistico, ora le aziende lo stesso CRM tendono a utilizzarlo in una modalità as a service; quindi le aziende non hanno più bisogno di avere un sistemista che venga a installare software e venga a risolvere eventuali problema o comunque necessitano il sistemista in misura minore.
Un ulteriore esempio di questo ridimensionamento del sistemista è dato da
Exchange per Office 365 e SharePoint, che hanno praticamente cancellato una figura professionale che è quella del sistemista Exchange e SharePoint.
Malgrado lo scenario delineato sinora, il sistemista non è in via di estinzione ma può ancora avere un suo mercato; sebbene la direzione che si sta prendendo va verso il Cloud, non è ancora giunta la fine del sistemista tradizionale e vediamo il perché: sicuramente è cambiato l’equilibrio tra IT tradizionale e Cloud, in quanto nel 2020 per la prima volta la spesa delle aziende destinata a servizi Cloud ha superato leggermente la spesa per IT tradizionale.
Però il sistemista esisterà ancora, almeno per due motivi, il primo dei quali e che comunque ancora per anni si sarà un numero notevole di sistemi Legacy; questo perché esistono ancora molte tecnologie che non è possibile o è sconveniente trasportare in Cloud e quindi dipendono dal sistemista di turno ed anche perché per questioni di business in molte aziende non si è pronti a un cambiamento radicale come il passaggio in Cloud. Naturalmente il sistemista tradizionale deve continuare a supportare e a gestire tali sistemi; questo è un motivo principale per cui il sistemista tradizionale ha ancora lavoro.
Cìè poi un secondo motivo un po’ più sottile, per spiegare il quale chiariamo cos’è il Cloud, fisicamente, con l’aiuto dell’immagine seguente.
Tutto quello che vedete raffigurato deve essere gestito e chi lo fa questo lavoro? Semplice: un amministratore di sistema, che però lavorerà non su macchine locali ma su infrastrutture virtuali remotizzate. Infatti se ipotizziamo di mettere un container in un qualsiasi Cloud (Coretech, AWS ecc.) tale container è una risorsa generalmente creata all’interno di una macchina virtuale, ma quella macchina virtuale è su un server fisico, che può essere clusterizzato con più macchine ridondanti tra di loro. Per funzionare, questo sistema ha bisogno di tantissime altre cose come per esempio il networking, lo storage, il firewall, il monitoring e tanto altro. Tutto questo è in una sala server, ossia in un data center e tutto questo deve essere gestito. Quindi, semplicemente il sistemista non sarà fisicamente e direttamente alle dipendenze del cliente ma di grandi infrastrutture virtualizzate, quando non sarà esso stesso a trasformarsi in provider Cloud.
Chiaramente il sistemista che opera in questo contesto è un po’ diverso, almeno sotto l’aspetto delle competenze, da quello tradizionale, perché si parla di sistemista dal lato infrastrutturale.
In vero la competenza deve andare un po’ oltre, arrivando a conoscere gli strumenti e quindi i linguaggi di programmazione impiegati nello sviluppo di codice; di seguito ne proponiamo alcuni.
Python è in un certo senso la base per lo scripting, quindi il principale linguaggio di programmazione e poi c’è anche il linguaggio dichiarativo, che nello specifico è YAML, che rappresenta uno standard di linguaggio dichiarativo utilizzato da tempo.
L’ultima tendenza nelle infrastrutture virtualizzate è gestire l’infrastruttura Cloud in qualche modo attraverso il codice (si parla anche di Infrastructure as a Code ovvero di IT managed by code) e in quest’ottica si collocano linguaggi e software di automazione e migrazione come Terraform, Ansible e Puppet, CHEF.
Attenzione che Cloud non significa solo Amazon AWS, Microsoft Azure ecc. perché quelli sono Cloud pubblici dove un’azienda può acquistare risorse e servizi; esistono anche realtà che possono, all’interno di un data center, realizzarsi un Private Cloud, ossia riservarsi dei server con rispettive risorse che sono a loro uso esclusivo (mentre nei Cloud pubblici il provider può spostare il cliente su vari server a seconda delle condizioni di carico, riassegnando le risorse) e delle quali possono affidare la gestione a un loro sistemista di fiducia, che opererà da remoto. Anche questo è un caso dove il sistemista ha senso, però deve conoscere le tecnologie del Cloud; lo stesso vale per soluzioni come il Cloud ibrido, ossia parte dell’infrastruttura IT di un’azienda è in Cloud e l’altra locale, perché anche qui il sistemista serve ancora.
Utilizzare i servizi in Cloud e lavorare con essi richiede la conoscenza delle piattaforme Cloud e quantomeno delle principali: AWS, Azure, Google Cloud. Ed anche delle soluzioni Cloud ibride, perché sono molto utilizzate in determinati ambiti.
Altre competenze che il sistemista nell’era del Cloud deve acquisire sono quelle sugli strumenti che consentono di fare la gestione IT attraverso il deploy di codice: per esempio, se abbiamo bisogno di creare molte macchine virtuali nell’ambito di un sistema di grandi dimensioni, con VMware il sistemista si crea tali macchine a mano. Invece esistono strumenti che, partendo da specifici requisiti (per esempio un tot di RAM, un certo ammontare di storage e via di seguito) sono in grado di creare le macchine automaticamente; in questo caso si parla di linguaggi dichiarativi, dove invece di indicare specifiche istruzioni da eseguire si dichiarano le proprie esigenze e questi poi realizzano qualcosa che corrisponde ad esse. Tali linguaggi sono, ad esempio, Terraform e Ansible.
Altre competenze che il sistemista dovrà avere sono la conoscenza e capacità di operare con i microservizi e container; la ragione è che non solo oggi è richiesta molta assistenza a sistemi che ne fanno uso, ma se si lavora in un’azienda che vende servizi e soluzioni Cloud, bisogna conoscere tali tecnologie e quindi il sistemista si deve trasformare in un sistemista infrastrutturale.
Le tecnologie inerenti ai container sono Docker per la creazione e Kubernetes per la gestione (orchestrazione) di container.
Quello che un moderno sistemista deve avere non è tanto la padronanza di queste queste tecnologie ma la capacità di comprenderne le potenzialità e di riflesso, un’infarinatura delle stesse.
Tutto quel che abbiamo visto (containerizzazione, utilizzo di linguaggi dichiarativi e di prodotti come Terraform) significa più automazione nei processi e in questa automazione il sistemista dovrà in qualche modo “metterci la testa”.
Un’altra competenza che il sistemista deve acquisire è la conoscenza del ciclo di vita dello sviluppo software e delle pratiche CI/CD (Continuous Integration e Continuous Delivery) ad esso correlate. Per comprendere la cosa riferiamoci all’immagine seguente, che riassume le competenze, vale a dire i compiti dello sviluppatore (DEVeloper) e del personale addetto alle operation (OPS). Come si può vedere, in realtà il lavoro è concatenato nelle fasi di creazione del pacchetto di installazione, che il developer passa all’OPS per installarlo e in quella di monitor dell’applicazione nel sistema, che coinvolge -per le considerazioni che ne possono scaturire- lo sviluppatore stesso.
I sistemisti che non lavorano nell’ambiente degli sviluppatori dei progetti vedono questo ciclo molto lontano dal loro mondo, dato che se non hanno un team di sviluppo da seguire, se non hanno dei deploy da fare, non conoscono bene di cosa si tratta. E questo in qualche modo li dissuade dal pensare ad operare in tale contesto, acquisendo le competenze dell’OPS.
Stabilito che il sistemista deve evolversi modificando il proprio modo di lavorare e acquisendo nuove skill, abbiamo ipotizzato tre percorsi che può intraprendere, che potrebbero anche essere alternativi.
Il primo è stato già accennato e riguarda il DevOps (Development and Operations) fermo restando che non è l’evoluzione naturale, ovvero non necessariamente il sistemista deve diventare DevOps; però è avvantaggiato nel farlo, perché il DevOps è un paradigma che implica grande collaborazione tra la parte di sviluppo e quella delle operations, le quali idealmente devono essere gestite da un team o da un professionista in ambito DevOps. Tale professionista deve avere competenze di sviluppo, quindi deve sapere che cosa fanno gli sviluppatori e poi andare a integrare ciò che viene sviluppato e creare dei sistemi automatizzati che faranno le verifiche, il deploy e manderanno le applicazioni in produzione. Un sistemista con competenze in programmazione e sviluppo di applicazioni può svolgere da solo l’intero ciclo di vita dello sviluppo e quindi fare il DevOps.
Andiamo al secondo possibile percorso professionale che lo sviluppatore può intraprendere: si tratta dell’SRE (Site Reliability Engineering) che è un qualcosa di ancora poco conosciuto in Italia. È un ruolo creato da Google ed è stato ormai adottato da tutte le grandi aziende americane e piano piano potrebbe diventare l’evoluzione più naturale del sistemista.
L’SRE si occupa principalmente della stabilità dei sistemi e quindi il suo compito è gestire tutta l’infrastruttura; parliamo di infrastruttura Cloud, dove si incarica principalmente di mantenere e di creare soluzioni in modo che l’applicazione sia sempre Up.
Potrebbe sembrare un Cloud Architect ma non lo è esattamente, perché l’SRE non dovrebbe dipendere molto dalla piattaforma Cloud su cui lavora ma più che altro deve strutturare e progettare dei servizi che vadano bene per qualsiasi tipo di Cloud, eventualmente anche ibrido.
Visto che lo abbiamo tirato in ballo, passiamo al Cloud Architect, che è proprio il terzo percorso professionale che il sistemista potrebbe intraprendere: si tratta di un professionista che da un certo di vista è molto verticale, nel senso che conosce molto bene una piattaforma Cloud specifica (Amazon, Google, Microsoft, IBM); quindi un Cloud Architect si può definire tale relativamente a una piattaforma, sebbene in qualche caso possa conoscere anche due piattafornme differenti, per averci lavorato. La forte specializzazione nasce dal fatto che nei Cloud non c’è molta unificazione, tanto che, ad esempio ad esempio le macchine virtuali offerte vengono chiamate Istanze da Amazon AWS, VM da Microsoft, engine da Google e via di seguito. Cambiano anche le tecnologie per la gestione dei permessi, quindi non basta solo sapere i nomi o sapere i servizi che esistono nei vari Cloud ma il System Architect si imbatte nella necessità di sviluppare un progetto Cloud in base alle esigenze del cliente, utilizzando i servizi disponibili e progettando con essi la relativa architettura in modo che sia resiliente e che rispetti certi parametri di pricing; già, perché la costruzione di una soluzione Cloud coinvolge anche la necessità di renderla competitiva sul piano economico e ciò può essere fatto solo conoscendo e ottimizzando le risorse e l’architettura. Un esempio potrebbe essere la gestione dei log, che se l’architettura prevede che non vengono mai eliminati e che si continuino a scrivere occupando storage, significano un costo via-via crescente per l’incremento continuo dello storager occupato dal cliente.
Altre aree dove un SysAdmin si può evolvere per restare al passo con i tempi e intraprendere nuovi percorsi professionali sono:
Tutti questi temi coinvolgono indubbiamente le moderne tecnologie e sono comuni agli ambienti Cloud e virtualizzati
Quindi, in conclusione si può affermare che il sistemista non è finito, ma deve semplicemente evolversi, applicando il proprio ruolo ai sistemi del futuro che le nuove tecnologie hanno messo in campo.
