La prima scelta che è stato necessario prendere mentre progettavamo il design di Skynet era ovviamente il framework o i framework da usare per lo sviluppo. Le soluzioni sono moltissime e sicuramente ognuno ha delle ragioni specifiche per pensare a questa o quella soluzione in modo da semplificare il lavoro ed ottenere magari una piattaforma aperta che possa includere altre tecnologie o soluzioni. Un esempio tipico è quello di partire da un progetto opensource o magari disegnare un frontend basato su WordPress e sviluppare estensioni e moduli per integrare le funzionalità che servono. Con tutte le tecnologie che esistono, non c’è un modo giusto o sbagliato ma semplicemente una preferenza in base ad alcune valutazioni che si fanno internamente e che dipendono anche dall’esperienza che il team ha acquisito nonché dall’integrazione che è possibile o meno con altre tecnologie che magari sono già presenti in azienda e che si vogliono riutilizzare o estendere.

I requisiti di Skynet

Come sempre, si parte da quelli che sono i requisiti del progetto. Il design di Skynet deve avere alcune caratteristiche che derivano dalla nostra esperienza nell’uso di decine o anche centinaia di tecnologie tra orchestration, pannelli di controllo, sistemi di gestione e così via.

Multipiattaforma

La tecnologia di cui avevamo bisogno doveva essere multipiattaforma in modo da consentire la gestione e soprattutto l’automazione dei sistemi più diffusi e quindi Windows e Linux. L’uso di un framework multipiattaforma doveva consentire anche il riutilizzo massiccio del codice che prevedevamo di scrivere per le decine di componenti che comporranno Skynet.

C’è inoltre da fare una ulteriore divisione all’interno del codice, prevedendo codice applicativo, che sarà indirizzato alle componenti principali, e un layer di interazione con i sistemi da gestire con i quali non sempre la scelta migliore è quella di usare un software ma spesso è più pratico affidarsi alle tecnologie di scripting. Inoltre, un layer di scripting consente – se messo in sicurezza – di prevedere anche un modo veloce per far evolvere singole funzionalità senza costringere al deployment dell’intero software.

Prevalentemente asincrono e durevole

Un sistema di gestione e di orchestrazione come quello che stiamo progettando deve necessariamente prevedere la possibilità di comunicare con diversi moduli che possano trovarsi non solo su sistemi diversi ma addirittura in datacenter diversi e distribuiti geograficamente e persino interagire con sistemi esterni alla nostra infrastruttura. Per la loro stessa natura queste interazioni non possono essere considerate come affidabili o parte di una rete costantemente connessa ma si deve dare per scontato che che questi sistemi possano essere saltuariamente disconnessi, ad esempio a causa di un temporaneo errore di rete, o incapaci di completare le azioni richieste al primo tentativo magari per un sovraccarico dei sistemi coinvolti o un altro problema saltuario.

Per questa ragione il framework che è stato scelto deve avere una forte impronta asincrona e non può essere basato su workflow che si aspettano di completare le operazioni in pochi secondi e senza una logica di retry/fail. Questo significa anche che i workflow che vengono eseguiti devono poter gestire questi possibili errori [...]

Come service provider VaiSulWeb ha sempre gestito al proprio interno un numero di tecnologie molto elevato e ci siamo sempre avvalsi di tanti strumenti, a volte più semplici da integrare, altre volte meno. C’è una tendenza molto diffusa oggi nel delegare ai cloud provider ipermassivi come Microsoft Azure o Amazon AWS la gestione di tante tecnologie, soprattutto quelle più complesse e principalmente da parte dei provider più piccoli. A VaiSulWeb abbiamo sempre gestito le nostre infrastrutture proprietarie e non prevediamo di cambiare questa visione che per noi è strategica tuttavia è cambiato lo scenario anche rispetto a pochissimi mesi fa e se prima veniva considerata probabile una crescita incontrastata dei provider cloud ipermassivi, oggi si ritiene che un approccio ibrido sia quello che verrà scelto dalla maggior parte delle aziende.

VaiSulWeb ha sempre integrato molti strumenti diversi ma la complessità di questi nuovi scenari, nei quali si fondono insieme gestione on-premise e la partnership con molte aziende diverse anche nell’ambito di confini della singola applicazione (si pensi ad esempio ai servizi di AI o cognitivi integrati in applicazioni ospitate all’interno di altre infrastrutture) rende necessaria la creazione di strumenti che non solo consetano di gestire questa complessità ma che rendano possibile anche una personalizzazione di tali strumenti per allinearli con gli obiettivi aziendali. L’ingresso nel mercato dei servizi di aziende che avevano operato nella produzione di software, come Microsoft, ha infatti reso necessario lo sviluppo di strumenti indipendenti che non risentano degli obiettivi – a questo punto spesso conflittuali – tra i service provider come VaiSulWeb e quelli che sono i produttori dei software che abbiamo usato per fornire i nostri servizi ai clienti, ora trasformatisi anch’essi in fornitori di servizi e che, come tali, perseguono i propri obiettivi.

Se fino ad ora VaiSulWeb, come molti altri provider, ha operato spesso integrando le piattaforme di diversi produttori di software, la trasformazione di questi produttori in fornitori di servizi spesso comporta anche un differente approccio verso lo sviluppo di tali software e le loro possibilità di integrazione, con l’obiettivo (legittimo) di favorire i servizi del produttore stesso ma con l’effetto a catena di ridurre la qualità e la semplicità dell’integrazione di tali software in ambienti di service provider diversi. Diventa quindi strategico lo sviluppo di uno strumento completamente indipendente che consenta l’integrazione, l’orchestration, la gestione, il monitoraggio e la personalizzazione di molteplici tecnologie anche per garantire ai nostri clienti la sicurezza di una infrastruttura completamente indipendente e resistente ad eventuali mutamenti di condizioni da parte di fornitori che per buona parte sono oggi anche competitor.

La nuova piattaforma di VaiSulWeb

Per tutte queste ragioni abbiamo deciso quindi di investire nello sviluppo di una piattaforma tecnologica completamente indipendente e abbiamo deciso di procedere ad  uno sviluppo aperto, condividendo le nostre riflessioni, le nostre scelte tecnologiche e spunti che possano magari essere interessanti per altre realtà. Questa sezione di The Server-Side Technology seguirà quindi questo processo. Ad oggi non prevediamo di rilasciare l’intera piattaforma come open-source ma di rendere disponibili singoli elementi che abbiano un potenziale uso [...]