Come risparmiare il 400% su un App Service con Azure

Uno dei problemi principali che avvertono tutti gli sviluppatori e le aziende che decidono di andare dal premise al cloud, è il problema dei costi.

Da un lato c’è il premise vecchio stile, con server propri in locale, all'interno della rete aziendale o comunque all'interno dell’infrastruttura aziendale, e costi tendenzialmente fissi e che non crescono proporzionalmente in base all’utilizzo, e dall’altro il cloud, nel nostro caso parliamo di Azure, che è sistema che abbiamo deciso di utilizzare ormai 10 anni fa su tutti i nostri progetti aziendali.

Il vantaggio dell’on premise è che una volta acquistate le macchine e gestiti i costi del reparto IT, non creano ulteriori spese e soprattutto non creano sorprese.

Nel senso che se ho una macchina dove all'interno c'è installato IIS, che fa girare un'applicazione, un database SQL e un Windows Service e altre risorse che girano sulla macchina, quei servizi non hanno dei costi a consumo.

Lo svantaggio è che devi manutenere queste macchine, devi manutenere questi servizi e ci sono serie possibilità che si spacchino, magari smettono di funzionare in pieno utilizzo da parte degli utenti, durante la settimana o durante il weekend o la catastrofe, mentre sei in vacanza.

Si possono danneggiare i dischi, può crashare la macchina, ed il servizio si interrompe senza possibilità di recuperare velocemente i dati e il sistema stesso.

In alcuni casi siamo stati contattati da clienti che hanno perso tutti i dati irrimediabilmente (database, contenuti, knowledge base tecnica) a causa di guasti tecnici ai server: anche passando dalla camera bianca di società specializzate nel disaster recovery, non c’è stato nulla da fare.

Con il cloud su Azure è tutta un’altra musica

Avere un uptime certificato tramite la Service Level Agreement (SLA) per alcuni progetti e alcuni clienti è requisito essenziale, significa che i sistemi devono essere su la maggior parte del tempo, tempo che ormai si aggira intorno al 99,98 o 99,97%, e ci possono essere dei momenti di down veramente molto brevi. Per essere chiari, significa che in 1 mese il servizio può non essere disponibile al massimo 14 ore, tempo comunque normalmente non accettabile per la maggior parte delle applicazioni a maggior ragione se consecutive.

Considera che con 14 ore di seguito di servizio non disponibile, la maggior parte dei nostri clienti farebbe prendere fuoco ai telefoni con chiamate in assistenza.

Il cloud ha il vantaggio di sollevare dai costi di gestione dell'infrastruttura il reparto IT dell'azienda che eroga il servizio, per contro può portare a sostenere costi molto alti e soprattutto costi non predicibili, che è il vero problema.

È come comprare una macchina in quei grandi concessionari di auto usate americani, hai presente? Quelli con le bandierine dappertutto e un venditore sempre affamato e pronto a convincerti a comprare “l’affare che hai davanti”.

Senti puzza di bruciato, ma il venditore è bravo, sa rispondere a tutte le tue obiezioni, ti mostra numeri, ti assicura che l’auto è davvero affidabile, ti mostra gli interni, i kilometri certificati, ma quando è ora di sapere il prezzo, non lo puoi sapere, ti risponde con un cartello con un grosso punto di domanda sopra.

Ti spiego subito come puoi trovare questo parallelismo su Azure, ma anche su altri servizi cloud.

Una volta entrati sul portale puoi iniziare ad attivare risorse cioè servizi come gli App Service che servono a far girare API, oppure siti web in ASP.NET MVC, e database SQL Azure, Cosmos DB, servizi di intelligenza artificiale e tutti quei bei giocattoli che mette a disposizione Azure.

Lo sviluppatore è curioso per natura, come i gatti, e inizia a pensare a come possa sfruttare questi servizi per migliorare l'applicazione o le applicazioni su cui sta lavorando.

Quindi passa a valutare nuove soluzioni architetturali come la creazione di micro-servizi o l'implementazione di parti architetturali come sicurezza l'utilizzo di intelligenza artificiale l'utilizzo di code e l'utilizzo di bus, tutti i servizi che offre.

Stai attento ai costi dell’infrastruttura cloud con Azure

Il problema in questo caso è che puoi velocemente salire con i costi, senza rendertene conto fino almeno al primo pagamento, ma anche successivamente dopo anni di utilizzo si possono avere delle brutte sorprese come è capitato a noi, a causa di servizi attivati per test, per debug piuttosto che fare scaling up per poter gestire dei momenti di carico.

Dopodiché questi servizi vengono dimenticati accesi e si sostengono costi anche molto alti, ma lo scopri solamente dopo.

Qualcuno dirà “beh ma c’è il cost analysis di Azure che permette di effettuare la predizione dei costi in base ai servizi attivati”.

È vero ma se si fanno proliferare i servizi e si continuano ad accendere senza un'organizzazione si rischia seriamente di andare incontro a dei costi assolutamente non preventivati dovuti all'attivazione di continue risorse, magari sovradimensionate e scoprire i costi reali solamente dopo.

A noi è successo con un nostro Cloud Service attivo ma che non serviva più perché avevamo sostituito con l’App Service, App Service che ha tutta una serie di vantaggi che spieghiamo all'interno del corso su “Il cloud con Microsoft Azure”.

Il trucco per spendere il 300% in meno con un App Service

Fino a qualche mese fa avevamo utilizzato esclusivamente App Service su Windows perché i prezzi su Linux erano sostanzialmente identici, ora Microsoft però sta applicando uno sconto del 66% sul gruppo B, per incoraggiarne l’adozione.

Successivamente abbiamo verificato di nuovo dal Pricing Calculator di Azure e ci sono grossi vantaggi economici, a parità di macchina divise per prestazioni in base al tipo di processore, numero di processori e quantità di memoria RAM.

Questa è la tabella di confronto di prestazioni e prezzi su Windows e Linux

Le performance sono migliori con Linux, di circa il 20%, per la maggior parte dei servizi che devono girare in cloud come API e applicazioni ASP.NET MVC.

void Main()
{
    WebsiteExtensions.RemoveConnectionsLmit();

    DownloadWebsite("https://linux.sviluppatoremigliore.com");
    DownloadWebsite("https://windows.sviluppatoremigliore.com");
}

public void DownloadWebsite(string url, int tests = 50)
{
    using (var client = new HttpClient())
    {
        var result = client.GetAsync(url).Result.Content.ReadAsStringAsync().Result;

        var stopwatch = Stopwatch.StartNew();
        var count = 0;

        Parallel.For(1, tests, x =>
        {
            result = client.GetAsync(url).Result.Content.ReadAsStringAsync().Result;
            count++;
        });

        stopwatch.Stop();

        (stopwatch.ElapsedMilliseconds / (double)count).Dump(url);
    }
}

Il tempo di risposta medio con 50 utenti contemporanei simulati

44,81 millisecondi per Windows

34,77 millisecondi per Linux

Utilizzando il pattern gateway stiamo migrando vecchie API legacy, sviluppate con ASP.NET MVC, NHibernate e Castle come sistema di IoC, verso .NET Core, con il sistema di depency injection nativa di ASP.NET Core e Entity Framework, tutto sulla versione 3.0 che è ancora più veloce della 2.2. Dai primi test abbiamo riscontrato un boost di performance veramente notevole anche del 500%.

Abbiamo fatto dei test di carico con diverse centinaia di utenti che una cosa che permette di fare anche direttamente Azure dalla gestione dell’App Service all'interno del pannello di controllo.

Pensa quanto puoi risparmiare dall'utilizzo corretto delle macchine e del loro dimensionamento se implementi un’architettura a microservizi con almeno 4 o 5 o addirittura 10 App Service.

Il deploy semplificato con gli App Service

Per poter effettuare il deploy con Linux da Visual Studio bisogna attivare Docker selezionando il progetto web e andando sul menu “Add item” e quindi selezionando “Docker support”.

Solo in quel momento si attiva la voce App Service Linux nel menu Publish che consente di fare deploy dell'applicazione, molto utile poterlo fare da Visual Studio perché fa un aggiornamento incrementale dell’applicazione, per cui se sono cambiati pochi file, come nel caso di API dove tipicamente cambiano solo alcune dll, in 2 o 3 minuti si riesce ad effettuare l’update dell’applicazione in remoto.

Per il controllo di qualità e la migliore gestione possibile usiamo la Continuous Integration e la Continuous Delivery, per cui è sufficiente fare commit da Visual Studio, perché su tutti i nuovi progetti utilizziamo GIT invece che TFS (trovi un articolo in cui spiego le differenze tra GIT e TFS) per scatenare la build automatica sul portale per gli sviluppatori di Microsoft DevOps.

Microsoft DevOps esegue diversi passaggi:

1. scarica il codice sorgente da zero su uno spazio dedicato
2. effettua il restore dei pacchetti Nuget
3. effettua la build
4. esegue i test automatici se ce ne sono
5. quindi fa il deployment dell'applicazione sull'App Service
6. infine, vengono pubblicati gli artifacts, cioè tutti i file compilati per poter eventualmente scaricare e analizzare che cosa viene prodotto

Ti consiglio assolutamente di fare test automatici e implementare unit test per fare commit sempre più sicuri, senza regressioni, potendo correggere tutti i bug con pochissimo sforzo e acquisire via via la massima confidenza con i progetti tuoi e del team.

Così elimini “l’ansia da prestazione” e arrivi alla vittoria con la massima serenità, come la recente vittoria di Novac Djokovic a Wimbledon, che ha vinto dopo 4 ore e 55 minuti di battaglia con Feder. Ha perso la calma? Mai, questo lo ha fatto vincere.

Il diavolo sta nei dettagli

Passare dall’App Service Windows a quello Linux si potrebbe pensare che sia indolore, ma la realtà è che non è così, rifare il deploy su un’altra macchina di un progetto pulito dal punto di vista del codice e dell’utilizzo di pacchetti Nuget, non è un cambio senza pene. Ci sono diversi problemi anche difficili da identificare, perché se l’applicazione non parte e non mostra eccezioni, nemmeno nei log, bisogna utilizzare l’intuito e l’esperienza.

Si passano quindi al setaccio i log di Azure e si analizza il codice per capire quali punti possono dare problemi, anche perché non è possibile fare debug da remoto di App Service su Linux, al contrario di macchine Windows.

L'esperienza fa tutta la differenza, il processo richiede magari ore di test di studio dei sistemi per poterlo utilizzare o utilizzare al meglio e soprattutto partire già da subito con delle soluzioni ottimizzate.

Puoi farlo investendo il tuo tempo e quindi i tuoi soldi o i soldi dell'azienda e fare tutti i test del caso. Oppure puoi utilizzare un boost di performance anche in questo caso, che ti permette di evitare di fare tutti quegli errori che qualcuno prima di te ha già fatto e pagato a sue spese.

Questa esperienza la trasferiamo attraverso un corso ti permette di andare molto più veloce e molto più sicuro nel passare dai servizi on premise ai servizi cloud.