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 senza che questo comporti l’annullamento generale del workflow soprattutto perchè vi sono alcune operazioni (si pensi alla cancellazione delle risorse) che non posso più essere eseguite coerentemente in una seconda fase. In poche parole, il framework deve consentire anche workflow durevoli sia a livello di gestione centralizzata che, come vederemo, a livello di singola entità (macchina, servizio, cluster, datacenter…).
Predisposizione per l’implementazione di API
Skynet è stato progettato per entrare in contatto e gestire diverse entità, dalle singole macchine (virtuali, fisiche o cluster) ai servizi esterni o API di terze parti. Si pensi per esempio ai servizi di integrazione con i diversi datacenter che usiamo e le loro API. Il framework che abbiamo scelto deve quindi consentire di interagire e soprattutto implementare facilmente e comunque in modo sicuro API che consentano l’interazione con i suoi diversi componenti o moduli. In particolare, gli agent che spesso verrano installati sulle macchine per la loro gestione devono consentire l’implementazione e la gestione di API e supportare i protocolli di comunicazione più spesso utilizzati: REST e gRPC, con un occhio alla possibilità di avere bisogno di supportare anche i WebService (WS-*).
Questa necessità rende ancora più importante la capacità del framework di essere multipiattaforma e armonizzare quindi tutte queste forme di comunicazione oltre che riutilizzare il più possibile il codice prodotto.
Alta disponibilità e scalabilità
Uno dei requisiti fondamentali della piattaforma è ovviamente la capacità di integrare funzionalità di alta disponibilità e anche di alta scalabilità. La prima è chiaramente fondamentale per un sistema di gestione di centinaia o migliaia di servizi perchè un suo blocco porterebbe a diversi problemi sia all’interno che all’esterno. Le soluzioni per questo tipo di problemi sono moltissime ma idealmente la migliore è quella che propone un nuovo paradigma di sviluppo che sia già progettato per l’alta disponibilità e per l’alta scalabilità e che quindi non richieda la gestione parallela di soluzioni disconnesse.
Per fare un esempio pratico, la persistenza dei dati in database relazionali tradizionali è sicuramente una alternativa ma costringe poi ad elaborare strategie di scalabilità ed alta disponibilità che sono proprie di quella tecnologia e del prodotto software usato. Inoltre queste soluzioni sono più difficilmente implementabili quando la topologia dei servizi sia distribuita e magari multi-datacenter. Il framework che abbiamo scelto doveva essere un cittadino di prima classe di un nuovo paradigma di sviluppo di soluzioni geo-distribuite ed alta disponibilità. La soluzione scelta verrà poi esaminata in un altro post.
Semplificazione del frontend
In generale la piattaforma adottata doveva includere il supporto per le tecnologie di sicurezza più comuni, specialmente quelle legate alla gestione delle API ma uno dei requisiti fondamentali era la semplificazione del frontend. Gli utenti si aspettano delle funzionalità molto avanzate nelle interfacce utente attuali e spesso questo porta all’integrazione, a volte cieca, di decine di librerie Javascript e la necessità di gestire le possibili vulnerabilità che possono introdurre a livello di interfaccia, senza contare i tanti problemi di compatibilità.
Obbiettivo della nostra scelta era quello di semplificare il frontend e, idealmente come bonus, anche qui condividere il più possibile il codice con la linea principale di sviluppo.
La nostra scelta: .NET Core
La scelta del framework da usare per lo sviluppo di Skynet è caduta quindi su .NET Core. Ovviamente tale scelta è stata influenzata anche dal nostro background sulla piattaforma Windows Server e sulle tecnologie di Microsoft ma in generale tutte le caratteristiche che abbiamo elencato le possiamo ritrovare nel nuovo nato in casa Redmond a partire dalla possibilità di essere usato sia su piattaforma Windows che Linux ma anche dalla possibile interazione con un’altra tecnologia multi-piattaforma di Microsoft: l’eccellente Powershell che dalla versione 6 supporta anche Linux.
L’integrazione tra queste due tecnologie fornisce un importante aumento di produttività per sistemi complessi come è Skynet e .NET Core supporta o integra inoltre numerose tecnologie di nuova generazione che rispondono alle esigenze che abbiamo descritto in precedenza e di cui parleremo in post successivi.
Leave a Response