Observability - cos'è e perchè usarla

Sempre più spesso le aziende stanno adottando microservizi per l'architettura del proprio software, estendendo e rimpiazzando i vecchi monoliti.

Ci sono indubbi benefici in questa architettura, facilità di sviluppo, deployment, scaling, ma l'avere un gran numero di microservizi che parlano tra loro può portare problemi nell'individuare la causa di un malfunzionamento o di una latenza.

Per risolvere questa situazione si è sentita quindi la necessità di reperire e combinare i dati di monitoraggio delle varie applicazioni, così da avere la visibilità dell'intero sistema.

Questa è conosciuta come Observability

La Observability si compone di metrics, logs e distributed tracing

Le metrics misurano un valore temporale, ad esempio la quantità di CPU usata da un'applicazione nel tempo

I logs servono a salvare messaggi dell'applicazione in un determinato istante. Possono contenere un errore che l'applicazione ha ricevuto, piuttosto che un'informazione utile ai fini del debug.

Una trace rappresenta i dettagli su una transazione, come quanto tempo ci è voluto per chiamare una specifica funzione. Una trace è divisa in span, cioè in operazioni tra segmenti contigui di lavoro.

Nel distributed tracing ogni servizio contribuisce al suo span o set di span.

Esistono strumenti diversi per ognuno dei 3 aspetti dell'Observability, con protocolli diversi e librerie proprietarie.

Per uniformare questi tre aspetti si è dunque deciso di farli afferire sotto un protocollo comune, detto OpenTelemetry. La Cloud Native Computing Foundation ha creato il progetto OTEL, un insieme di API, SDK e Tools per la gestione delle metriche.

A valle del collettore ci sono strumenti open source come Jaeger, Prometheus, Loki e Grafana, piuttosto che soluzioni proprietarie che permettono il salvataggio dei dati, la visualizzazione e anche un sistema di alerting

Creare un progetto React con Vite

 Sto cercando di capire, vincendo la mia ostilità verso la UI, come funziona React, la libreria di Meta per la UI

Mi sono accorto che React, diversamente da Angular che ha angular-cli, non ha un suo ambiente a gestione totale, ma lascia molta libertà nella scelta degli strumenti per il templating e per l'organizzazione del progetto.

Ho scoperto che esiste Vite, che mette a disposizione l'environment di sviluppo per i vari framework.

Lo so, per chi fa sviluppo frontend quotidianamente queste sono le basi, ma per me non è così scontato.

Dicevamo che Vite mette a disposizione tutta una serie di template per creare progetti con diversi Framework. Nel caso di React ho trovato interessante il fatto che il template parta da una pagina HTML, invece che da un file Javascript, come negli esempi React.

Questo mi permette di fare più semplicemente il deploy su un server o un container con NGinx od Apache, invece che col server Node.js

Ho quindi usato il comando

npm create vite@latest . -- --template react-ts

per creare un progetto nella directory corrente da un template React con typeScript

Da qui sarà una lunga strada, ma il primo passo è fatto

Node.js Version Manager for Windows

Recentemente ho avuto bisogno di avere 2 installazioni di Node.js sulla mia macchina.

Una, decisamente datata, per gestire un vecchio progetto Legacy, ed una aggiornata per creare nuove cose.

Mi sono quindi chiesto come poter fare.

Ho scoperto che esiste un tool fatto proprio per questo scopo.

Non riuscirà a far girare le versioni di Node.js contemporaneamente, ma potrà far switchare tra diverse versioni in un attimo.

Il tool si chiama nvm, Node Version Manager, per l'appunto.

Esiste una versione di questo tool per Unix/MacOs ormai da un po' di tempo, non sapevo se esistesse per Unix.

Poi fortunatamente l'ho trovato qui!

A questo punto posso affrontare il futuro senza incasinare il passato.

Connecting Azure to the International Space Station with Hewlett Packard Enterprise

 https://azure.microsoft.com/it-it/blog/connecting-azure-to-the-international-space-station-with-hewlett-packard-enterprise/

Log4Net e Microsoft.Extensions.Logging

Per .Net Core, e ancor i più in .Net 5, Microsoft ha introdotto nuove api per il logging, Microsoft.Extensions.Logging

Queste Api forniscono un layer di astrazione e delle interfacce per il logging, ma lasciano aperta l'implementazione vera  e propria: Microsoft offre un pacchetto nuget anche per il .Net Framework, oltre che per .Net Core

Microsoft consiglia l'utilizzo di Serilog come provider. Serilog ha già un'estensione pronta per agganciarsi alle nuove api di logging.

Ho provato ad usare questa estensione, ma ho rilevato problemi di compatibilità con le api Microsoft nell'uso dell'ultima versione. Ho dovuto fare un downgrade delle Api per poter compilare.

Un'altra estensione già pronta all'uso è NLog: è molto simile a log4Net, che finora era il framework più usato per il logging.

Anche in questo caso esiste una estensione già pronta per le nuove api Microsoft.

Ho provato a integrare anche questo sistema, ma anche qui è stato necessario fare un downgrade delle librerie Microsoft

Come dicevo prima, nei progetti un po' più vecchi usualmente il logging veniva gestito tramite log4Net.

Se si cerca poi di distribuire un progetto Web su una piattaforma Cloud tipo Azure il semplice log su file è molto limitante, mentre è molto più comodo poter avere log su strumenti come Application Insight e simili.

Non parliamo poi di compilare in Net Standard. log4Net supporta Net Standard 1.3 (vedi qui), quindi tutta la parte Ado.Net, che è supportata in Net Standard 2.1 da dei gran bei warning.

Tocca quindi fare un pianto ed un lamento e far evolvere il log: mica banale, visto che tante, se non tutte le classi che abbiamo scritto (se siamo stati dei bravi sviluppatori) fanno uso del log!

Si, però vorremmo anche salvaguardare i nostri files di configurazioni in log4net, perché nel tempo ce li siamo personalizzati al millimetro, con i livelli di log giusti, escludendo classi che non ci interessano, enfatizzandone altre ecc ecc. Inoltre è troppo lungo trasformare tutto in una sola volta. Va fatto in maniera progressiva, quindi i 2 ambienti devono poter convivere per un periodo di tempo.

Per far convivere i 2 ambienti bisogna scrivere un provider per log4Net. A quel punto le nostre configurazioni in log4net sono salve e possiamo, in maniera incrementale, sfilare classe per classe log4net e mettere Microsoft.Extensions.Logging.

E infatti è quello che mi son divertito a fare, e devo dire che funziona.

L'implementazione e i test relativi a tutti i metodi di log si trovano qui

https://bitbucket.org/andreapalloni/log4netprovider/src/master/

Creare una stazione radio da PC

In questi giorni di reclusione forzata, mi sono divertito un po' a capire come poter fare broadcast audio on line dal proprio PC.

Cominciamo intanto dalla teoria. Per fare streaming ci vuole un server che irradi lo streaming verso internet. Questo server può essere privato, e quindi vi dovrete attrezzare sia con Hardware che con la connessione dati, oppure in hosting da qualche provider specializzato e qui basta poter raggiungere il provider.
Ci sono vari provider specializzati in webcast: io ne ho provati un paio, ed hanno tutti i loro pro e i loro contro.
Ho provato Spreaker ad esempio, che ha una buona grafica, un bell'appeal, strumenti anche da mobile per poter trasmettere, ma che, a livello free, non offre gratuitamente il broadcasting, ma solo la possibilità di caricare podcast. Il livello entry costa 4€ al mese, un'inezia, anche se ha un tempo limitato di live broadcast.

Poiché volevo provare l'ebrezza del broadcat "live" ho trovato Caster.fm, un fornitore di servizio sicuramente più di nicchia, anche meno "appealable", ma che permette di fare live.
E ora un'altra nota tecnica: i broadcast audio nel mondo sono di 2 tipi: Shoutcast ed Icecast. Shoutcast, ora alla versione 2, è il protocollo proprietario inventato da WinAmp (ah, che bei tempi), che può considerarsi lo standard per il broadcast.
Icecast è un'implementazione open per un protocollo di streaming audio.
I nostri amici di Caster, ed anche Spreaker a quanto ho visto dalle documentazioni, utilizzano il protocollo IceCast per la trasmissione.

Ed ora veniamo al software: quale DJ console usare?
Anche qui ci sono varie alternative, addirittura Spreaker mette a disposizione una console sia su PC che su tablet, e devo dire che è fatta piuttosto bene.
Un'alternativa pababile è VirtualDJ, una DJ console parzialmente free, ma che non è gratuita proprio per il broadcast.
L'alternativa open a tutto ciò, ed è quella che ho usato io, è Mixxx, un bel software per il Mixing, semplice e ormai robusto che può girare su Win, Mac e Linux.

Fatte tutte queste premesse andiamo a configurare Mixxx su Caster.fm.
Niente di più semplice! Basta seguire le istruzioni ed il gioco è fatto.
In pratica bisogna installare in locale l'encoder lame, che Mixxx non si porta dietro per questioni di licenza, e poi configurare il broadcast verso Caster con i parametri che ci vengono dati, in particolare la password.
Fatto questo si accende il server (che viene spento una volta al mese) e, schiacciato il tasto su Mixxx si va in onda.
Buon ascolto!

Arduino Cli

Se, come me, usate Arduino fuori dall'Ide e vorreste poter compilare i vostri progetti via batch (e magari in un processo DevOps), finalmente stanno sviluppando Arduino CLI .