Microsoft released Windows Server 2022 a few weeks ago. It did so earlier than expected, which is pretty odd, but it seems that the development of new features was already complete and mature so there was no point to wait a few months more. The last sentence pretty much explains the current status of Windows Server: so few changes, albeit interesting ones, that the product can be released months earlier than planned and without much fanfare.

While generally speaking the development of new features and functionalities for server applications mostly moved out of the base operating system and while we can also concede that Windows Server has many features at the OS level so it is difficult to design new ones, the fact each new release of Windows Server keeps bringing few new features is definitely because of Microsoft errors. Server applications today are either simple, think about a website or a Web application, or complicated. In the latter case, you generally think about microservices, Kubernetes and so on.

So we might say that since a few years Windows Server became more a tool to build base infrastructures than the base for new applications. That means that you usually install something on top of Windows Server to manage and deploy applications and you don’t usually rely on OS services only to develop your application. It is safe to say that it is a common scenario because Linux too is experiencing the same transformation.

However, Microsoft could have responded to Linux popularity by upping the ante and push more innovation into Windows Server and they didn’t.

Windows Server 2022 – continued fragmentation

The new Windows Server version has some nice and neat features. Besides a better Kubernetes compatibility, which is basically mandatory today, it features and big work to improve security. Credit where is due. That improves a lot both standalone servers security but it is also a fundamental improvement when deploying clusters, the famous infrastructures.

Other improvements include TLS 1.3 enabled by default and a few improvements around SMB, all of them improve security.

There would be other two important features to mention, one of them would be very important, but surprise: they won’t be available to all customers but only to those using Azure. At least for now.

Microsoft introduced Windows Server Datacenter: Azure Edition, another attempt to fragment Windows Server but the first one to draw a line between “standard” Windows Server and Azure versions. And we cannot welcome this kind of behavior because it basically starts to leave non-Azure Windows Server installations behind in an attempt to force Windows customers to move to Azure. Quite frankly, this is indecent especially when you factor how much Windows Server costs when compared to its competitor.

Features that Microsoft is withholding from its non-Azure customers are very important.

First, there is the much awaited hot-patching, that is a way to patch Windows without rebooting. Microsoft aims to use hot-patching especially for security patches and it would be a very ground-breaking innovation when considering how many emergency updates are needed [...]

At VaiSulWeb virtualization is so pervasive that basically there aren’t physical machines other than virtualization hosts or storage since about 2008 or 2009. That means about 10 years now. And counting. Microsoft Hyper-V served us very well and over time our reliance on that technology increased with happy results. It has been solid and consistent and allowed us to scale up more and more, adding new technologies and solutions and enabling us to virtualize roles and workloads that seemed a bit difficult to virtualize.

As many other providers, we recently started integrating AMD CPUs into our infrastructure, given the terrific advantages that those could bring to the datacenter especially for generic or mixed workloads. Only a subset of our infrastructure has been migrated to the new AMD servers but things got easier because of the many advantages that the Windows Server (+ Hyper-V) platform could provide and we carefully started to fill those hosts by migrating workloads. Results have been very pleasing.

Performance improvements and security

As we had planned, we immediately started benefiting of performance improvements. Not only CPU-bound tasks were faster but also I/O performance were terrific.

One of our goals was also to improve security by using AMD technologies that showed better resiliency when dealing with security issues when compared to Intel chipsets and CPUs and we were also prepared to face a few limitations. For example, Hyper-V isolated containers are not supported on non-Intel CPUs and thus cannot be used.

We started migrating our workloads to the new servers and Hyper-V functionalities like shared-nothing live migration and live migrations made the process quite easy and straightforward. In a few days about 80% of the target workloads have been migrated with minimal or no disruption at all. So far so good.

Unexpected crashes

Then something odd happened: one of the hosts started to crash. That was surely something we rarely faced in our 10+-years-long experience with Hyper-V but that specific host was crashing up to 2-3 times per day and while it usually was back online in about 2 minutes with all of its VMs restarted, the virtual machines that it was hosting were obviously also crashing causing downtimes. That was very surprising since similar machines (basically identical since they were using the same components) were not exhibiting any issue even after running for weeks in production and even more in our labs.

That machine had been running for days without issues then started crashing 2-3 times per day with no traceable pattern. Sometimes it could run for hours (10 or more) without issues, sometimes it was crashing two times in 15 minutes. Weird. And scary.

We decided to halt our migration to ensure that we didn’t miss any incompatibility between Windows Server 2019 and those AMD servers yet other servers were not having any issue and tracing back the issues we had, that specific machine had not been exhibiting issues for days before it started crashing so often.

Diagnosing the issues

The first thing that you might want to do in such cases is to ensure [...]

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

Qualche giorno fa Microsoft ha presentato il suo nuovo sistema operativo progettato per i dispositivi IoT: Azure Sphere OS. Il nuovo sistema operativo ha come obiettivo quello di fornire una piattaforma sicura-per-default per la costruzione di servizi IoT e superare i problemi che hanno reso i dispositivi IoT così sensibili anche ad attacchi di tipo non sofisticato tanto da consentire ad organizzazioni malevole la creazione di botnet o al possibilità di compromettere la privacy degli utenti.

Il nuovo sistema operativo

Azure Sphere è una soluzione più complessa che consente la creazione di una piattaforma per l’IoT ed include anche microcontroller personalizzati che implementano le 7 regole per la sicurezza dell’IoT stabilite da Microsoft, ed un servizio basato su Azure, la piattaforma cloud di Microsoft, che si occupa di verificare lo stato di ogni dispositivo e acquisire ogni errore o possibile compromissione. Questo servizio fornirà anche gli aggiornamenti per il sistema operativo di ogni dispositivo ed anche modalità di recupero di dispositivi che non stessero funzionando correttamente.

Considerazioni

Molti utenti su Internet hanno posto l’accento sul fatto che Azure Sphere OS fosse basato su un kernel Linux modificato ma la soluzione di Microsoft è ben più complicata del solo sistema operativo. Sebbene qualcuno sia rimasto sorpreso dal fatto che Microsoft sta sostanzialmente producendo una propria distribuzione Linux, anche se questa non è certamente la prima volta che l’azienda di Redmond distribuisce una propria versione di Unix se si ricordano i vecchi tempi di Xenix, ma ci sono cose più interessanti nell’offerta di Azure Sphere del solo kernel usato per il sistema operativo.

E’ sicuramente interessante che Microsoft abbia pensato che Windows fosse troppo pesante per girare su un microcontroller e che abbia deciso di passare ad una soluzione basata su Linux. Alcuni pensano che Microsoft non sia riuscita a produrre una versione di Windows sufficientemente leggera ma io credo che l’azienda statunitense abbia deciso di scegliere Linux per ragioni più semplici: per guadagnare sufficiente fiducia e spazio nel settore dell’IoT, Microsoft doveva usare un sistema open-source e non penso proprio che volessero fornire il codice di una versione di Windows, sebbene pesantemente modificata per girare su un microcontroller. Allo stesso modo, sarebbe stato difficile portare molti partner dalla propria parte con una versione commerciale di un sistema operativo, considerando che molti di questi già usano probabilmente distribuzioni Linux gratuite e leggere, progettate ad hoc.

Inoltre, da quando ha attivato Azure, lo scopo di Microsoft è diventato più quello di fornire servizi che non quello di vendere software e per questa ragione oggi Microsoft rilascia sostanzialmente software che consenta l’adozione di Azure, qualunque sia la sua origine. Non è sorprendente quindi che per tutte queste ragioni abbia deciso di non reinventare la ruota e di usare una versione molto personalizzata di un ambiente Linux, estendendolo con “funzionalità di sicurezza ispirate da Windows”. Microsoft inoltre ha usato chip personalizzati per anni nelle proprie console Xbox.

Sarebbe stato difficile portare molti partner dalla propria parte con una versione commerciale di un sistema operativo, considerando che molti di questi già [...]

Con un post sul blog dell’apposita sezione, Microsoft ha annunciato il supporto per Kali Linux in Windows 10, in collaborazione con gli sviluppatori del progetto. Da questo momento sarà quindi possibile effettuare il download di Kali Linux dallo Store di Windows 10 ed installarlo sul proprio PC, come parte del WSL (Windows Subsystem for Linux). Kali Linux è una distribuzione basata su Debian progettata per l’uso forense e per i test di sicurezza ed include oltre 600 tool di sicurezza e testing. Si aggiunge ad altre più note, come Ubuntu, già supportate da Windows 10. Non è stato contemporaneamente annunciato il supporto per il WSL su Windows Server, disponibile dalla versione RedStone 3.