ASP.NET 5 verrà eseguito su IIS attraverso il modulo HTTPPlatformHandler

Con un post su GitHub,  Damian Edwards ha annunciato che la nuova release di ASP.NET, la versione 5, non verrà più eseguita da IIS come ISAPI ma attraverso il modulo HTTPPlatformHandler che per l’occasione verrà aggiornato con alcune modifiche e reso disponibile anche per Windows Server 2008R2, la versione minima per eseguire ASP.NET 5. La modifica sarà disponibile già con la beta8 del software e quindi al prossimo aggiornamento previsto per il 5 Ottobre 2015.

ASP.NET ed IIS

A prima vista questa modifica potrebbe sembrare ininfluente ma segna un cambiamento piuttosto importante se si considera che sin dalla sua introduzione con IIS 6 e Windows Server 2003, ASP.NET è stata eseguita da IIS come ISAPI, la configurazione che garantiva le prestazioni migliori sulla piattaforma. Lo stesso avveniva ed avviene per altre tecnologie come ASP classico mentre storicamente altri framework o estensioni provenienti dal mondo Unix usavano invece una tecnologia meno sofisticata a cui si fa riferimento in generale come CGI.

Le perplessità potrebbero sorgere proprio perché da sempre l’esecuzione ISAPI è considerata la più efficiente e quella capace di fornire prestazioni di molto più elevate sulla piattaforma Windows Server, soprattutto perché la creazione di nuovi processi è in effetti una operazione onerosa sui sistemi Windows, molto più di quanto lo sia sui sistemi Unix.

In realtà sin da Windows Server 2003 Microsoft ha affinato il supporto per le tecnologie CGI, in particolare per garantire la compatibilità con framework molto popolari come PHP. La tecnologia FastCGI è in effetti l’antesignana del modulo HTTPPlatformHandler e, sebbene con FastCGI la piattaforma Windows Server abbia efficacemente ottenuto l’esecuzione di framework come PHP con prestazioni pari o addirittura superiori a quelle dei sistemi Unix, fino a poco tempo fa era considerato impossibile che Microsoft decidesse di passare ad una modalità di esecuzione diversa per le proprie tecnologie.

HTTPPlatformHandler : l’evoluzione della specie

La notizia non può che significare che Microsoft ha ormai ottenuto una parità di performance tra l’esecuzione ISAPI e quella CGI e la chiave è senza dubbio il modulo HTTPPlatformHandler. Anticipando le perplessità di qualcuno, Edwards aggiunge che Microsoft si aspetta una differenza di prestazioni tra le due modalità solo per applicazioni triviali come una Hello World, cioè piccole applicazioni che fungono più da esempio che da reali implementazioni. Per tutti gli altri casi, probabilmente Microsoft crede di raggiungere prestazioni uguali o anche maggiori a quelle ottenibili con la tecnologia ISAPI. Certamente così facendo ottiene una flessibilità notevolmente maggiore, soprattutto in un contesto nel quale ASP.NET è diventato open-source ed in teoria qualsiasi utente potrebbe compilare la propria versione della tecnologia.

Il modulo HTTPPlatformHandler è l’evoluzione di quello FastCGI che ha consentito a Windows Server di diventare una piattaforma ideale anche per PHP a partire dalla versione 2003 e da IIS 6. FastCGI risolve il problema dell’onerosità della creazione di nuovi processi con l’attivazione di una singola istanza che verrà usata in modo efficace da IIS per gestire un numero variabile di richieste, isolandole da quelle degli altri siti Web ma gestendole sempre con un processo unico. Di tanto in tanto, in modo configurabile, IIS disattiva poi questa istanza comune per attivarne un’altra, evitando che i problemi di tecnologie come PHP che funzionano efficacemente solo in modalità CGI possano poi intaccare il funzionamento del Web Server. La chiusura del processo consente di azzerare qualsiasi problema l’interprete CGI possa avere e ripartire da una situazione inziale, risolvendo il problema dell’instabilità che tecnologie come PHP potevano portare a server come IIS.

Il modulo HTTPPlatformHandler è stato pubblicato da Microsoft solo all’inizio dell’anno e rappresenta il perfezionamento di FastCGI. Al contrario di quest’ultimo, utilizzabile a fini pratici quasi esclusivamente con PHP, HTTPPlatformHandler nasce per fornire alla piattaforma Windows Server la possibilità di utilizzare tutti i framework a linea di comando. Microsoft ha creato questa tecnologia per utilizzare su Azure tecnologie come Java, Ruby on Rails (RoR), Python e molte altre. Per farlo serviva un modulo più generico di FastCGI, qualcosa che fosse adattabile a qualsiasi framework ed il nuovo modulo risolve perfettamente il problema, consentendo di eseguire in modo efficace praticamente qualsiasi framework a linea di comando, mantenendo alte le prestazioni per poter fornire una reale alternativa a piattaforme come Linux.

Il modulo viene utilizzato con successo su Azure ed è stato integrato anche da molti altri service provider per consentire l’esecuzione di Java e RoR su piattaforma Windows Server. Si tratta quindi di una tecnologia che, sebbene abbia pochi mesi di vita, ha già provato di poter fornire alte prestazioni.

 Addio Helios, soluzione di geniale ma senza futuro

Parleremo più avanti degli obiettivi della nuova versione di ASP.NET ma soffermiamoci prima su una tecnologia di collegamento che Microsoft aveva sviluppato per la nuova versione, la tecnologia che consentiva alla nuova versione di essere eseguita al posto della precedente senza danneggiare la compatibilità della piattaforma. Si chiama Helios, ed è sostanzialmente un hook con cui Microsoft consentiva alle applicazioni ASP.NET 5 di prendere il posto del framework 4.5 e 4.6 senza dover installare nulla sul server. Questa soluzione, decisamente geniale, consentiva di “delegare” l’esecuzione della richiesta corrente ad un runtime diverso, in particolare le versioni beta di ASP.NET 5 che negli scorsi mesi sono state fornite come pacchetto completo, con la possibilità quindi di usarle side-by-side. Helios consente quindi di cambiare completamente la pipeline di ASP.NET, eliminando la famosa System.Web e sostituendola con quella nuova, gestendo autonomamente l’esecuzione della richiesta da quel momento in poi.

Non sappiamo se dal punto di vista della sicurezza l’uso di Helios avrebbe complicato le cose, anche se è improbabile visto che ASP.NET 5 avrebbe comunque girato nel contesto del processo chiamante, ad ogni modo il team di ASP.NET ha deciso di passare ad una modalità di esecuzione del tipo CGI basata su Kestrel, il server Web open-source usato in molti esempi per ASP.NET 5 e riconoscibile con il file dnx.exe. Probabilmente questa scelta dipende anche dal fatto che utilizzare una singola modalità di attivazione consentirà di unificare lo sviluppo sia per Windows che per gli altri sistemi su cui ASP.NET 5 potrà essere eseguita e cioè Linux e MacOS. Inoltre, è indubbio che l’uso di una applicazione CGI alla quale IIS sostanzialmente girerà la gestione della richiesta consenta maggiori possibilità di configurazione da parte dell’utente che può decidere di utilizzare anche configurazioni diverse per applicazioni diverse, decidere quali informazioni passare alle singole richieste, modificare o sostituire il runtime in ogni momento e così via.

Da questo punto di vista i gateway CGI si sono dimostrati molto flessibili ma come succede per PHP, la possibilità di introdurre variazioni o personalizzazioni all’interno dei componenti principali della tecnologia rischia di frammentarla, introdurre incompatibilità e rendere in generale tutto più instabile. Su ASP.NET gli sviluppatori sono sempre stati abituati al fatto che ci fosse un runtime di base e poi eventuali personalizzazioni ad un livello più alto. Oggi corriamo il rischio che “la mia ASP.NET non sia più la tua ASP.NET”, anche se indubbiamente molti utenti avanzati si gioveranno delle possibilità di personalizzazione, addirittura di ricompilazione autonoma della tecnologia.

Meno preoccupante la situazione dal lato prestazioni perché è evidente che se il team ha scelto di usare HTTPPlatformHandler, le prestazioni del modulo consentiranno di eguagliare, se non superare in futuro, quelle della ISAPI.

Ci chiediamo a questo punto se IIS non vada verso una evoluzione nella quale diventerà un semplice forwarder di richieste, un proxy un po’ come nginx, più che rimanere un Web Server a tutto tondo. E’ probabile che nelle prossime versioni di Windows Server IIS possa essere sostituito da un proxy più snello oppure addirittura Nginx stesso, visto che Microsoft ha dimostrato di poter integrare tecnologie diverse, se lo riteneva utile, lasciando magari al vecchio Web Server il compito di gestire la compatibilità con i vecchi stadard, ad esempio l’autenticazione di Windows.

A questo proposito, Edwards ha dichiarato che una delle modifiche che HTTPPlatformHandler introdurrà con la nuova versione è proprio il supporto per l’autenticazione di Windows, che sarà necessario indirizzare al processo di gestione di ASP.NET, essendo ora quest’ultimo esterno al processo di IIS.

Cosa aspettarsi da ASP.NET 5

Articoli su ASP.NET 5 compariranno spesso su The Server-Side Technology da qui in avanti, soprattutto in concomitanza con il rilascio della versione definitiva prevista per il primo trimestre del prossimo anno. Un breve accenno però sulle novità di ASP.NET va fatto, come antipasto a ciò di cui parleremo nei prossimi mesi.

E’ intanto singolare che Microsoft abbia sostanzialmente separato i cicli di rilascio del framework .NET e di ASP.NET visto che fino ad adesso le due componenti sono sempre andate di pari passo. Con Visual Studio 2015 è stato invece rilasciato il framework .NET 4.6 e la beta di ASP.NET 5. Anche la non corrispondenza della numerazione (v4.6 contro v5 e nessun dettaglio sul .NET framework v5) sono particolari ma riflettono il cambio di rotta introdotto con la decisione di far diventare .NET e ASP.NET open-source.

Con ASP.NET 5 Microsoft cambia completamente l’organizzazione di ASP.NET, distanziandosi dal modello introdotto nel 2003 con la v1.0 per creare un runtime che dia più controllo allo sviluppatore. Come abbiamo accennato in precedenza, sparisce la vecchia pipeline basata su System.Web e sulla quale, incrementalmente, Microsoft aveva poi costruito tutte le altre tecnologie di ASP.NET, a vantaggio di un runtime la cui configurazione è completamente personalizzabile attraverso l’inserimento dei diversi moduli in modo esplicito. L’obiettivo di questa modifica è piuttosto evidente: consentire agli sviluppatori di lavorare solo con i moduli / servizi / tecnologie / estensioni di cui hanno bisogno per la propria applicazione, velocizzando l’esecuzione del codice grazie all’assenza di tutta quella parte del framework che non è necessaria per l’utente. ASP.NET (e .NET in generale) consentono già la distribuzione solo delle librerie usate ma questo avveniva per le estensioni al framework principale. Con ASP.NET 5 il runtime caricherà solo le componenti necessarie per l’applicazione in esecuzione.

Alcune tecnologie, come la tanto vituperata WebForms che godeva in modo immeritato davvero di cattiva stampa, spariscono del tutto e rimarranno disponibili solo nelle versioni legacy come ASP.NET 4.5. In generale tutta l’organizzazione delle applicazioni cambia, con l’introduzione di file di configurazione basati principalmente su JSON (anche se XML continuerà ad essere supportato), una più chiara separazione dei file di configurazione in modo da rendere dichiarative e configurabili molte delle funzionalità relative al funzionamento dell’applicazione. Inoltre, ci sarà una più netta separazione tra gli asset necessari per l’esecuzione Web (come immagini, CSS etc.) e la parte di codice, isolando i primi nella classica cartella wwwroot ma portando al suo esterno gli altri file. Con l’introduzione del supporto per Kestrel anche con IIS, sparirà anche il vecchio file web.config, non più necessario.

Accanto a nuget, troveremo poi l’integrazione con altre tecnologie come bower e gulp ed in generale tutta la parte di configurazione ed esecuzione dell’applicazione sarà dipendente da impostazioni gestite dallo sviluppatore piuttosto che da quelle definite a livello di amministrazione di sistema. Questo darà più controllo agli sviluppatori e li metterà meno in conflitto con i sysadmin.

Del resto, la stessa possibilità di usare un proprio runtime consente di ridurre le incompatibilità ed assicurare che ciò che lo sviluppatore crea sulla propria macchina sia poi al 100% compatibile con l’applicazione pubblicata sul server di destinazione.

Ci sono molte altre novità che fanno parte di ASP.NET 5, tra cui la possibilità di usare quel sottoinsieme del framework .NET chiamato CoreCLR che consente di assicurare la compatibilità con sistemi Linux e MacOS, ma avremo modo di parlare di queste novità in futuro.

Nel frattempo vi segnalo che potete già usare ASP.NET 5 (fino alla beta7) con uno dei pacchetti di cloud hosting offerti da VaiSulWeb. Non fatevi quindi sfuggire l’occasione per provare la nuova tecnologia ed iniziare a progettare le vostre applicazioni di nuova generazione.