Introduzione
La digital transformation ha esasperato il concetto di digital experience, oggi ogni azienda / organizzazione di qualsiasi dimensione deve confrontarsi con la reale percezione che hanno i propri dipendenti e clienti nell’utilizzo quotidiano delle applicazioni e dei servizi erogati. Ovviamente esistono business più sensibili di altri a questa tematica, ma i concetti alla base prescindono dalla tipologia degli stessi che sono invece in larga parte dipendenti dalle tecnologie più o meno complesse, distribuite ed integrate che li caratterizzano.
Quotidianamente il mio lavoro mi porta ad interagire con clienti di svariate dimensioni con organizzazioni interne più o meno strutturate ma tutti con la medesima necessità, acquisire le informazioni necessarie per valutare in piena autonomia quale soluzione adottare per consentire a ciascuno di raggiungere i propri obbiettivi interni.
Le diverse soluzioni
Non è affatto facile districarsi nelle innumerevoli soluzioni offerte dal mercato, tra soluzioni open source, soluzioni commerciali, ibride, on-premises, in cloud e potrei continuare, ma soprattutto direi che la difficoltà maggiore è che spesso e volentieri ci sono diverse sovrapposizioni tra una soluzione ed un’altra, ognuna magari con una feature più accattivante di un’altra ma mancante di altre altrettanto importanti, quindi in sostanza la difficoltà sta nel riuscire a fare sintesi.
Spesso i clienti per cercare di individuare la soluzione migliore per le loro necessità fanno dei POC, generalmente tra due/tre diverse soluzioni, ma anche in questo caso la scelta non è affatto facile, perché non sempre è possibile mettere a confronto le diverse soluzioni nel medesimo istante temporale, al fine di consentire la medesima valutazione da parte di ogni soluzione al presentarsi di una particolare situazione, soprattutto quando le informazioni ottenute devono anche supportare un eventuale fase di troubleshooting.
In conclusione i POC possono risultare complessi da dover gestire oltre che ovviamente costosi sia in termini di risorse da dedicare che costi.
Last but not least, le terminologie utilizzate dai diversi vendors, nonché le metriche utilizzate, spesso e volentieri rappresentano un ulteriore difficoltà, perché non necessariamente c’è uniformità di interpretazione e modalità di calcolo comuni.
Observability
Un’altra funzionalità di cui si sente molto parlare è il concetto di “Observability”, a mio avviso al di la del nome, la consapevolezza che fosse necessario correlare diverse informazioni, acquisite in modalità diverse al fine di avere una chiara comprensione di ciò che si stava osservando è qualcosa che era già stata riconosciuta come tale e che alcuni vendors avevano già introdotto svariati anni or sono. L’avvento dei cosiddetti Analytics ha accelerato notevolmente il tutto fornendo maggiori capacità di integrazione e correlazione di eventi.
Al fine di rendere più esplicito quanto sin qui espresso e consentire a ciascuno di farsi un idea sul tema, della complessità e delle diverse opzioni possibili per perseguire un certo obbiettivo, utilizzeremo uno scenario creato in lab.
Lo scopo di questi test non è quello di determinare la soluzione migliore rispetto ad un’altra, bensì quello di evidenziare i diversi approcci ed i risultati che si possono ottenere in un modo piuttosto che con un altro.
Utilizzeremo uno scenario molto semplice ma al contempo molto comune, sia on-premises che in ambiente cloud, ovvero una banale applicazione web a cui accederanno dei client, l’applicazione è bilanciata da un Network Load Balancer che distribuirà le richieste ricevute dai client su due server di backend.
Il bilanciatore, un NGINX, è anche il terminatore delle sessioni SSL/TLS e il traffico diretto verso i due server di backend sarà http.
I clients, un PC Windows e un PC MAC, ricaricheranno tramite i loro browser una pagina web che conterrà delle immagini, giusto per creare un po’ di traffico.
L’architettura è stata creata in un ambiente VMware e la soluzione adottata per copiare il traffico e metterlo a fattor comune alle diverse soluzioni che ne necessitavano una copia è la soluzione GigaVUE Cloud Suite di Gigamon.
Architettura di test
Questo è l’elenco dei prodotti utilizzati per i test :
- OpenSearch (vs 2.8.0) – prodotto opensource
- GigaVUE Cloud Suite di Gigamon (vs 6.1.00) – prodotto commerciale
- Alluvio AppResponse di Riverbed (vs 11.16.0) – prodotto commerciale
- vStream e nGeniusONE di Netscout (vs 6.3.4) – prodotto commerciale
- Packetbeat di ElasticSearch (vs 8.3.0) – prodotto opensource
- Metricbeat di ElasticSearch (vs 8.6.2) – prodotto opensource
- Filebeat di ElasticSearch (vs 7.17.6) – prodotto opensource
- Heartbeat di ElasticSearch (vs 8.4.0) – prodotto opensource
- APM RUM-JS Agent di ElasticSearch (vs 5.12.0) – prodotto opensource
- APM-Server di ElasticSerach (vs 7.17.9 ) – prodotto opensource
- Chrome Extension di Netperf Consulting
- Firefox Extension di Netperf Consulting
Per continuare a leggere :