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 [...]

Sviluppando una applicazione per Azure Service Fabric e aggiungendo una libreria .NET Standard al progetto ci si potrebbe imbattere in una serie di warning di Visual Studio come questo

Warning MSB3270 There was a mismatch between the processor architecture of the project being built “MSIL” and the processor architecture of the reference “C:\[…]”, “AMD64”. This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.

Si tratta di un warning che indica che l’architettura selezionata per la CPU non è l’unica supportata da Azure Service Fabric e cioè x64. Probabilmente l’impostazione è AnyCPU e la libreria funzionerà correttamente ma per fare sparire i warning è sufficiente modificare il target di compilazione nell’apposita sezione Build di Visual Studio:

oppure impostare l’architettura target direttamente nel file .csproj del progetto:

<PropertyGroup> <TargetFramework>netcoreapp2.0</TargetFramework> <PlatformTarget>x64</PlatformTarget> <RootNamespace>Microsoft.*.Tests</RootNamespace> </PropertyGroup>

E’ sufficiente salvare il file ed effettuare una nuova compilazione : non si dovrebbero visualizzare altri warning.

Ovviamente bisogna ricordare che questa modifica renderà inutilizzabile la libreria nel contesto di una applicazione a 32bit.

Con un post sul blog di Microsoft, il gigante di Redmond ha chiarito la situazione che circonda il framework .NET e la sua relazione con .NET Core ed ha annunciato che il .NET Framework 4.8  sarà l’ultima versione del framework  che Microsoft renderà disponibile. Dopo il rilascio di .NET Core 3 la prossima major version sarà .NET Core 5 che deve essere la versione che tutti gli sviluppatori .NET useranno dopo il rilascio di .NET Core 3.

Microsoft ha anche confermato alcuni dettagli interessanti come il fatto che salterà la numerazione 4 per il framework .NET Core per evitare confusione tra gli sviluppatori quindi la prossima versione di .NET (qualsiasi piattaforma) sarà .NET Core 5 per consentire agli sviluppatori che usano il framework .NET di passare dalla 4.8 alla 5 in modo naturale. Inoltre alcune tecnologie che erano molto popolari non verrano implementate in .NET Core e, sebbene saranno comunque oggetto di aggiornamenti e manutenzione (ma per quanto tempo ? Microsoft ha iniziato a non onorare più la promessa di supporto per 10 anni delle tecnologie deprecate…), gli sviluppatori devono iniziare a pensare alla conversione delle proprie applicazioni. Tecnologie come  WebForms, WCF e Windows Worflow non saranno reimplementate , tutte tecnologie che erano molto popolari in passato nello settore Windows.

Infine, la conferma che la data di rilascio di .NET Core 3 sarà Settembre 2019, cosa che rende la prossima major version di .NET (attualmente in preview5) molto vicina.

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 [...]