.NET Core 1.0: Microsoft cambia idea sul proprio futuro

Nel 2010, parlando di Windows Phone 7, avevo scritto una frase che oggi mi fa sorridere: “noi di ideativi, malati per .net”. Non abbiamo ancora trovato una cura. :-) Ma nel frattempo è cambiato parecchio il significato di essere sviluppatori .NET. Il 27 giugno Microsoft ha rilasciato .NET Core 1.0, insieme ad ASP.NET Core 1.0 ed Entity Framework Core 1.0.

Detta così sembra la normale uscita di una nuova versione. Non lo è. .NET Core gira su Windows, OS X e Linux. È open source. È modulare.

Può essere distribuito insieme all'applicazione. Può convivere sulla stessa macchina in versioni differenti. E possiamo svilupparci non soltanto con Visual Studio, ma anche da riga di comando e con Visual Studio Code. Per un prodotto nato dentro l'ecosistema Microsoft è un cambiamento abbastanza grosso da sembrare, fino a pochi anni fa, quasi una barzelletta.

La novità non è che Microsoft abbia fatto una nuova versione di .NET. È che ha smesso di considerare Windows come una condizione necessaria per usare .NET.

Non è .NET Framework 5

Prima di tutto bisogna evitare un equivoco. .NET Core 1.0 non sostituisce .NET Framework. Microsoft stessa, nell'annuncio ufficiale, chiarisce che .NET Framework, .NET Core e Xamarin continueranno a essere prodotti importanti per scenari differenti. Il Framework tradizionale rimane il riferimento per molte applicazioni Windows esistenti. .NET Core nasce invece con obiettivi differenti:

• applicazioni web moderne;
• microservizi;
• applicazioni console;
• librerie;
• carichi cloud;
• scenari multipiattaforma.

Nel 2016 non esiste un vincitore che sostituisce l'altro: esistono piattaforme diverse per esigenze diverse.

Questa distinzione è importante perché sarebbe un errore prendere oggi una grande applicazione .NET Framework e decidere di “migrarla a Core” soltanto perché è uscito un prodotto nuovo. Prima bisogna capire perché dovremmo farlo.

.NET su Linux. Sul serio.

Per anni una delle caratteristiche più evidenti del mondo .NET è stata il legame con Windows. Certo, Mono esiste da tempo e ha dimostrato che il modello .NET può funzionare anche altrove. Ma questa volta è Microsoft stessa a pubblicare e supportare ufficialmente una implementazione multipiattaforma. .NET Core 1.0 è disponibile su:

• Windows;
• OS X;
• diverse distribuzioni Linux.

E non è una curiosità sperimentale. Microsoft ha annunciato il rilascio proprio durante Red Hat DevNation e .NET Core è disponibile anche su Red Hat Enterprise Linux e OpenShift attraverso container certificati.

• Microsoft e Red Hat.
• .NET e Linux.
• Nella stessa frase.

Se nel 2005 lo avessimo scritto su questo blog ci avrebbero accusato di aver bevuto. :-)

Open source non soltanto sopra, ma sotto

ASP.NET MVC era già open source da tempo. Ma sotto continuava a esserci il .NET Framework proprietario. Con .NET Core cambia la profondità dell'apertura.

• Runtime.
• Librerie.
• Compilatori.
• ASP.NET Core.
• Entity Framework Core.
• Documentazione.

Gran parte dello stack viene sviluppata pubblicamente. Microsoft dichiara che quasi 10.000 sviluppatori hanno partecipato in qualche forma ai repository collegati a .NET Core 1.0 e che quasi metà delle pull request relative ai progetti principali proveniva dalla community. È un cambiamento culturale oltre che tecnico. Non significa che Microsoft smetta di controllare il prodotto. Significa che lo sviluppo avviene in un ambiente molto più visibile e aperto rispetto al modello tradizionale.

Per chi sviluppa è possibile:

• leggere il codice;
• seguire le issue;
• vedere le decisioni;
• contribuire;
• compilare il runtime;
• capire cosa succede sotto una API.

“Open source Microsoft” non è più un ossimoro da usare per fare una battuta. Sta diventando una parte reale della strategia dell'azienda.

Modulare significa portarsi dietro soltanto ciò che serve

Il .NET Framework tradizionale è una piattaforma molto ampia. È installata sulla macchina. Le applicazioni utilizzano la versione presente nel sistema. .NET Core adotta un'impostazione diversa. Il runtime, le librerie e gli strumenti sono componenti separati e molte dipendenze vengono distribuite tramite NuGet.

L'obiettivo è rendere la piattaforma più modulare. Per una applicazione cloud o per un microservizio questo può essere molto interessante. Non devo necessariamente considerare .NET come un blocco monolitico installato sul server. Posso ragionare su ciò che la mia applicazione utilizza realmente. Questo permette anche di ridurre l'impronta dell'applicazione e facilita scenari come container e deployment automatizzati.

Side-by-side: una delle cose che mi piacciono di più

Chi ha amministrato applicazioni .NET su server Windows conosce bene una situazione scomoda. Aggiornare il framework della macchina può significare chiedersi: e le altre applicazioni che girano sullo stesso server? Con .NET Core Microsoft introduce un modello molto più flessibile. È possibile installare versioni differenti del runtime fianco a fianco.

Una applicazione può dichiarare quale versione utilizza. In alcuni scenari possiamo perfino distribuire il runtime insieme all'applicazione.

Applicazioni differenti possono dipendere da runtime differenti senza imporre necessariamente una singola versione globale alla macchina.

Dal punto di vista operativo è un vantaggio enorme. Riduce l'accoppiamento fra applicazioni che condividono lo stesso server. E in ambienti cloud, dove creare e distruggere istanze o container deve essere normale, questa indipendenza diventa ancora più importante.

Anche la riga di comando torna protagonista

Un'altra cosa curiosa per chi associa Microsoft a Visual Studio è la centralità della command line. Installato l'SDK possiamo creare e avviare una applicazione con comandi come:

dotnet new
dotnet restore
dotnet run

Naturalmente Visual Studio continua a essere un ambiente potentissimo. Ma .NET Core non parte più dal presupposto che Visual Studio sia l'unica porta d'ingresso possibile. Possiamo utilizzare:

• Visual Studio;
• Visual Studio Code;
• riga di comando;
• altri editor.

Questa impostazione è coerente con il fatto che il software deve girare anche dove Visual Studio non esiste. Per un ecosistema storicamente molto integrato con i propri strumenti è un altro segnale del cambio di mentalità.

ASP.NET Core cambia parecchio più di quanto suggerisca il nome

Insieme a .NET Core è arrivato anche ASP.NET Core 1.0. Microsoft lo descrive come uno degli aggiornamenti architetturali più importanti mai fatti ad ASP.NET. È più leggero. Modulare. Ottimizzato per il cloud.

Multipiattaforma. E unifica MVC e Web API dentro un unico framework di programmazione web. Questo aspetto mi interessa particolarmente perché per molti sviluppatori .NET il web è il primo scenario nel quale .NET Core può avere senso concreto.

• Possiamo sviluppare una applicazione ASP.NET Core su Windows e distribuirla su Linux.
• Oppure svilupparla su Mac.
• Possiamo usare container.
• Possiamo creare microservizi.
• Possiamo continuare a scrivere C# senza dover scegliere Windows come sistema operativo del server.

Cinque anni fa una frase del genere avrebbe richiesto molte più spiegazioni.

Attenzione: la versione è 1.0, ma non tutto è “finito”

Qui arriva la parte meno da comunicato stampa. Il runtime .NET Core è arrivato alla versione 1.0. Ma gli strumenti dell'SDK sono ancora indicati come Preview 2. Microsoft chiarisce che la parola Preview riguarda soprattutto il fatto che l'esperienza e la forma dei tool non sono ancora definitive. Questo significa che chi decide di adottare subito la piattaforma deve mettere in conto cambiamenti.

Anche Entity Framework Core 1.0 non possiede ancora tutte le funzionalità di Entity Framework 6. La stessa Microsoft consiglia EF Core soprattutto per:

• nuove applicazioni che non richiedono funzionalità ancora mancanti;
• applicazioni che devono girare su .NET Core.

Per gli altri scenari invita a valutare ancora EF6. Quindi 1.0 non significa “trasferiamo tutto domani”. Significa che la piattaforma è arrivata a un punto in cui possiamo iniziare a considerarla seriamente per la produzione, conoscendone però i limiti.

Il vero bersaglio è il cloud

Microsoft lo dice molto chiaramente. .NET Core è stato ripensato per il mondo delle:

• applicazioni distribuite;
• microservice;
• container;
• infrastrutture cloud.

È probabilmente questo il motivo per cui molte scelte acquistano senso insieme.

• Multipiattaforma.
• Deployment indipendente.
• Runtime piccolo.
• Command line.
• Versioni side-by-side.
• Open source.
• Supporto Linux.

Se il software viene distribuito su decine o centinaia di istanze, magari create automaticamente e contenute in container, dipendere da una installazione globale del framework sul sistema operativo diventa molto meno attraente. .NET Core sembra nascere pensando fin dall'inizio a quel tipo di ambiente.

Microsoft cambia perché è cambiato il mondo

Secondo me questa è la lettura più interessante. Per anni Microsoft ha avuto un vantaggio enorme nel controllo completo dello stack:

• Windows.
• Windows Server.
• IIS.
• .NET Framework.
• Visual Studio.
• SQL Server.

Era un ecosistema coerente e molto produttivo. Ma il cloud ha cambiato le regole. Linux è ovunque nei server. Le tecnologie open source sono diventate una scelta normale anche nelle grandi aziende. Gli sviluppatori lavorano su Mac.

Docker sta cambiando il modo di pensare al deployment. Node.js ha mostrato che un ambiente molto leggero può diventare estremamente popolare nello sviluppo web. Amazon domina una parte importante del cloud. In questo scenario dire: “la nostra piattaforma funziona benissimo, purché usiate tutto il nostro stack” è una strategia molto più difficile da sostenere. .NET Core è anche la risposta di Microsoft a questo cambiamento.

Microsoft non sta rendendo .NET multipiattaforma per generosità. Lo sta facendo perché oggi essere legati a una sola piattaforma è un limite competitivo.

Ed è esattamente per questo che penso sia una buona notizia.

Cosa farei oggi con un nuovo progetto

Non butterei via il .NET Framework. Non convertirei automaticamente una applicazione esistente. E non sceglierei .NET Core soltanto perché è nuovo. Ma per una nuova applicazione web valuterei seriamente alcuni fattori. Deve girare anche su Linux?

È pensata per il cloud? Può beneficiare di container? Voglio distribuire runtime e applicazione insieme? Mi interessa avere versioni side-by-side? Sto costruendo servizi piccoli e indipendenti?

Le API di cui ho bisogno sono già disponibili su Core? Se molte risposte sono sì, il nuovo stack diventa molto interessante. Se invece ho una grande applicazione Windows fortemente dipendente da tecnologie del Framework tradizionale, probabilmente non c'è alcun motivo per avere fretta. Come sempre, la tecnologia viene dopo il problema.

La cosa più strana? Che ormai non sembra più strana

• Microsoft che pubblica codice su GitHub.
• Microsoft che collabora con Red Hat.
• Microsoft che supporta Linux.
• Microsoft che crea un editor multipiattaforma.
• Microsoft che rende .NET open source.

Presi uno alla volta, negli ultimi anni ci siamo abituati a tutti questi segnali. Con .NET Core 1.0 diventano una piattaforma vera. Per questo credo che il rilascio del 27 giugno sia molto più importante del numero di versione. Non sappiamo ancora se .NET Core diventerà il centro dell'ecosistema .NET. È troppo presto.

Il Framework tradizionale ha una base installata enorme e funzionalità che Core oggi non possiede. Ma una cosa è già evidente. Essere sviluppatori .NET non significa più automaticamente essere sviluppatori Windows. Per noi “malati per .NET” è un cambiamento niente male.