In questo articolo continuiamo ad esplorare il concetto di architetture Business Driven, tenendo in considerazione gli aspetti più concreti di questo tipo di architetture.

Nell'Information Tecnology il modello X as a Service è facile da comprendere. Ci indica che alcuni servizi vengono forniti da un fornitore di terze parti oppure internamente gestendoli come se fossero servizi esterni.

Utilizzando un'architettura a microservizi dovremmo operare questo cambiamento di prospettiva per ogni servizio. Il modello infatti garantisce, indipendenza al team che lo gestisce e un modello di utilizzo chiaro e ben documentato per i team che lo utilizzeranno.

Identity as a Service

Adottare un servizio di Identity as a Service è probabilmente una delle prime necessità per supportare questo tipo di architetture.

Le applicazioni / servizi devono poter contare su un servizio che gli consenta di condividere le utenze.

Le alternative presenti sul mercato sono molteplici e generalmente fanno utilizzo di protocolli di autenticazione standard (OAuth2, Open ID Connect 1.0, SAML, AD/LDAP). Questo ci garantisce un certo margine di portabilità tra una soluzione e l'altra.

Scegliere un fornitore di terze parti (Okta, Auth0, AWS Cognito, ...) che si occupi di tutto il lavoro, ad esempio in caso di assenza di competenze interne, necessità di scaling su larga scala, riduzione dei costi, compliance con normative e regolamenti.

In base alle necessità e qualora si decida di eseguire carichi sulla propria infrastruttura si potrebbe optare per la gestione diretta del servizio.
Anche in questo caso ci sono diverse alternative su cui indirizzare la nostra scelta, citiamo ad esempio Ory Hydra , Keycloak e CAS oltre a quella di crearne uno da zero.

Se il nostro obiettivo non è quello di rivendere il servizio di Identity, l'implementazione personalizzata è poco praticabile, non avremmo possibilità di acquistare supporto, una community che identifichi bug e migliori il prodotto.
Scegliendo invece un prodotto occorre essere pragmatici e valutare adeguatamente pro e contro di ognuno di essi. Ory Hydra e CAS ad esempio offrono ampi margini di personalizzazione ma richiedono un costo di integrazione più elevato, Keycloak invece è una soluzione sicuramente più completa ma può in alcuni casi risultare più vincolante per alcuni aspetti. (fixme Federation, Spid, TFA)

A prescindere da quale soluzione si scelga occorre ragionare attentamente sul processo di adozione che deve coinvolgere progressivamente applicazioni/servizi  pre-esistenti o da creare. Percorrere questa strada richiede un impegno notevole, occorre prevedere migrazioni di utenze, librerie o componenti di integrazione per applicazioni pre-esistenti, documentazione e supporto adeguato.

Su questi temi facciamo un po' di auto-promozione ai nostri contributi opensource:

GitHub - iad-os/nightswatch: ⚔️Night’s Watch, the OIDC Relying Party that guards the realms

⚔️Night’s Watch, the OIDC Relying Party that guards the realms - GitHub - iad-os/nightswatch: ⚔️Night’s Watch, the OIDC Relying Party that guards the realms

GitHubiad-os

GitHub - iad-os/react-ghost-auth

Contribute to iad-os/react-ghost-auth development by creating an account on GitHub.

GitHubiad-os

GitHub - iad-os/aemon-oidc-introspect: I am a maester of the Citadel, bound in service to Castle Black and the Night’s Watch... And I introspect OIDC Tokens in the spare time!

I am a maester of the Citadel, bound in service to Castle Black and the Night's Watch... And I introspect OIDC Tokens in the spare time! - GitHub - iad-os/aemon-oidc-introspect: I am a maester ...

GitHubiad-os

Event-Driven Architecture

Le architetture a microservizi e quelle serverless richiedono l'utilizzo di architetture event driven per:

• rendere l'esperienza utente reactive e interattiva (notifiche, chat, collaborazione online, etc)
• applicare il pattern  "Inversion of Control" tra i singoli servizi, consentendo una maggiore coesione e un basso accoppiamento tra di essi.
  Chi scatena l'evento non è a conoscenza di quali saranno i suoi utilizzatori, quindi un cambiamento su uno di questi servizi non produce nessun effetto su chi lo ha generato;
• implementare la Consistenza Eventuale: L'impossibilità di avere transazioni ACID su un sistema distribuito (CAP Theorem), nelle situazioni dove non è stato possibile risolvere il problema attraverso un'oculata scelta dei contesti transazionali ci porta a considerare soluzioni capaci di convergere ad una situazione di consistenza, consistenza eventuale appunto.
  Questi meccanismi utilizzano eventi per raggiungere questo traguardo;
• utilizzare gli eventi per produrre informazioni aggregate utili a fini di monitoring, alerting e BI.

Le principali caratteristiche di un sistema adeguato alle nostre necessità dovrebbe:

• gestire un numero adeguato di eventi e connessioni
• garantire una durabilità degli eventi stessi
• essere facile da integrare e con il supporto ai principali modelli di utilizzo (es. publish/subscribe, request/reply, queue group, ...)

A seconda delle necessità esistono diverse soluzioni da poter metter in campo. La scelta deve avvenire in base alle necessità effettive di progetto.

NATS, è una soluzione opensource che fornisce performance elevate, scalabilità, sicurezza e resilienza nella gestione di sistemi "hyperconnected".
Il punto di forza di NATS è nella sua "ergonomicità" di utilizzo. In altre parole consente agli sviluppatori di gestire diversi casi d'uso con estrema semplicità.

Apache Kafka è una piattaforma di event streaming utilizzata per applicazioni con data pipeline ad elevate performance, streaming analytics, data integration e applicazioni mission-critical.
La sua robustezza e le performance lo rendono adatto alla creazione di requisiti complessi. Purtroppo la sua natura non gli consente di avere la stessa "ergonomicità" di NATS e la sua gestione operativa è molto più complessa rispetto alle altre soluzioni.

GitOps

Il GitOps è una metodologia che ci consente di gestire il deployment di applicazioni Cloud Native. Lo sviluppatore viene messo in condizione di poter gestire direttamente l'infrastruttura utilizzando gli strumenti con cui ha già familiarità, incluso Git e i tools di Continuous Deployment

GitOps: versioned CI/CD on top of declarative infrastructure. Stop scripting and start shipping.

— Kelsey Hightower

Attraverso il GitOps è possibile ottenere allo stesso tempo automazione e controllo. Questo risultato viene ottenuto utilizzando un approccio dichiarativo in tutti i livelli.

Tutti i passaggi necessari, dal provisioning infrastrutturale (es. IaaS) fino ad arrivare al rilascio in produzione, sono descritti all'interno di un repository Git.

Per creare un nuovo ambiente o effettuare il rilascio di una singola commit non serve più ingaggiare il gruppo di operations.

Gli interventi una volta sottoposti ad un processo di approvazione supervisionato o automatico, vengono accettati e realizzati direttamente dal sistema.
Il modello di contribuzione stesso viene inserito in questi repository, per convenzione denominato CONTRIBUTING.md.

In questo modo i singoli team possono disegnare la loro infrastruttura di base, lasciando ai gruppi di Operations l'opportunità di adattarle in una fase successiva.
I singoli team non hanno nemmeno accesso diretto agli ambienti dove verranno eseguiti i loro workload, stabilendo un livello di sicurezza elevato.

Uno degli strumenti che ci consente di applicare questa metodologia è ArgoCD.

Why ArgoCD?
Application definitions, configurations, and environments should be declarative and version controlled. Application deployment and lifecycle management should be automated, auditable, and easy to understand.

Conclusioni

Questi sono solo alcuni dei problemi e i relativi strumenti su cui occorre fare una riflessione.
Senza questi strumenti le architetture orientate al Business sono quasi impossibili da gestire e proibitive nei costi operativi e di gestione.
Anche se si può procedere ad un'adozione incrementale che vada di pari passo con il nostro business, avere già un obiettivo e una strategia di breve e medio termine ci consente di non precludere l'utilizzo di questi strumenti.

Evolvere il processo produttivo in qualsiasi campo di applicazione è una sfida che ci pone di fronte a nuove opportunità ma anche a nuovi problemi.

L'impulso che dà vita all'evoluzione è sempre un'opportunità o un problema.
Problema o opportunità è spesso un punto di vista. Sono entrambe un qualcosa che in un modo o nell'altro ci consente di crescere.

Come accennavamo nel precedente articolo Business Driven Architectures - Parte 1, i problemi da affrontare sono diversi e trasversali.

Visti sotto questa luce rappresentano anche delle opportunità ad esempio, inserirsi in nuovi mercati, strappare o riconquistare dai competitor quote di mercato.
Avere come obiettivo principale il valore dei servizi offerti, coincide con l'obiettivo del business.

In questo articolo cerchiamo di analizzare meglio la situazione da diverse angolazioni.

Automazione vs Burocrazia

Spesso l'evoluzione di un sistema software viene inibita dal contesto e se ci è ostile può dissuadere o far fallire chiunque.

Un contesto è ostile se: ogni intervento richiede montagne di ticket e gerarchie da scalare, la sua notevole complessità fa si che ogni intervento sia enormemente costoso, i benefici di ogni intervento non sono mai all'altezza dei costi, i team che lavorano sul progetto non operano con una visione di insieme e si limitano alle loro responsabilità, quando il sistema è fragile e quindi si ha paura di introdurre nuove funzionalità,  ... (la lista è ancora molto lunga ).

Se queste situazioni vi sono anche in parte familiari, occorre effettuare una decisa inversione di rotta, ripensando, rimuovendo o intervenendo in modo tale da consentire al sistema "azienda" di poter evolvere su tutti i livelli.

L'automazione è uno strumento non sufficiente ma sicuramente necessario a correggere la situazione. Il motto è "Automate Everything" ed è solo uno dei principi che consentono di instaurare un processo meglio noto come DevOps e le sue declinazioni (DevSecOps , GitOps).

IaaS (Infrastructure as a Service)

Ridurre al minimo o rimuovere tutte le interazioni che non aggiungono valore per il cliente finale richiede che alcuni processi vengano descritti con un approccio più dichiarativo che ne descriva il "cosa" non il "come".

Ordinando al ristorante non ci interessano tutti i passaggi necessari per ottenere un piatto, possiamo essere interessati agli ingredienti utilizzati per eventuali intolleranze o possiamo ordinarne in base alla necessità (cena per due o rimpatriata con tutti gli amici delle elementari e rispettivi familiari).

Ottenendo a servizio le componenti necessarie a eseguire i nostri carichi di lavoro, possiamo contare su un'infrastruttura virtualmente infinita, self-service (replicabile per esigenze specifiche e anche di brevissima durata), ridurre i costi di acquisto e gestione, gestire i minimizzare rischi associati senza aver paura di intervenire.

Tra principali fornitori di servizi IaaS ci sono AWS (Amazon) , Azure ( Microsoft ), GCS ( Google ), Digital Ocean che possono provvedere a tutte le necessità infrastrutturali operando a servizio. In caso di necessità (es. localizzazione dei dati, strategia aziendale, ...)  si può decidere di sostenere i costi di un'infrastruttura on-premises, rapportandosi con essa come si farebbe per un fornitore del servizio IaaS. In questa configurazione si possono prevedere anche scenari ibridi ( Cloud Provider + On Premises) che possano sfruttare entrambe le soluzioni.

Cloud Native Applications

Con una semplice e poco costosa operazione Lift-and-shift (Migrazione senza modifiche), si possono: aumentare scalabilità e performance, migliorare la sicurezza, ridurre i costi di esecuzione di applicazioni e carichi di lavoro.

Questa migrazione però riprodurrà in Cloud, gli stessi problemi di operatività che avevamo prima, un processo batch potrà passare da ore di lavoro a minuti di lavoro e non potrà comunque fornire informazioni utili in real time agli utenti, i costi di sviluppo rimarranno invariati o aumenteranno in funzione della complessità aggiunta dal IaaS.

Occorre portare questo concetto nelle applicazioni stesse. Utilizzare tecniche, strumenti e metodologie che ci permettano di ottenere vantaggi sempre maggiori.

Da qui il concetto di Cloud Native Applications.
Le Cloud Native Applications sono tutte quelle applicazioni che seguono una serie di principi finalizzati a renderle adatte per il raggiungimento di questi obiettivi.

L'esperienza di Heroku, uno dei primi fornitori del servizio Platform as a Service (PaaS). Opera su questo mercato sin dal 2007 ha riassunto la sua esperienza in questo documento The Twelve Factors App.

Le applicazioni che rispettano i principi del documento:

• utilizzano un formato dichiarativo per l’automazione della configurazione, minimizzando tempi e costi;
• possono essere utilizzate sui vari ambienti di esecuzione;
• sono progettate per diminuire la necessità di server e amministrazioni di sistema;
• hanno omogeneità tra gli ambienti di esecuzione (sviluppo/produzione) per una massima “agilità” del processo di rilascio;
• possono scalare significativamente senza troppi cambiamenti ai tool, all'architettura e al processo di sviluppo.

Microservices Architecture

Le architetture a microservizi sono naturalmente correlate ai principi delle Applicazioni Cloud Native.

Dividere le applicazioni originali in una serie di microservizi, ci consente di ottenere numerosi vantaggi, ad esempio i singoli servizi: sono più piccoli e gestiti in autonomia dai diversi team; possono essere scalati, rilasciati e testati in modo indipendente da tutte le altre componenti.

Questi vantaggi generano anche però un aumento della complessità del sistema, si passa dal singolo applicativo (monolite) ad una moltitudine di servizi più piccoli ( microservizi) da dover gestire.

Saper gestire queste architetture può non essere banale, richiede di utilizzare  architetture adeguate, strumenti e processi automatizzati.

Containers

Anche se esistono differenti modi di gestire i carichi di lavoro principalmente hardware dedicato o virtual machine, l'approccio alla conteinerizzazione permette di ottenere gli stessi risultati in modo più leggero e meno costoso.

I container non sono altro che dei processi adeguatamente isolati e connessi, che vengono eseguiti direttamente sul sistema operativo della macchina che li esegue.
Oltre ad ottenere un sistema di gestione dei carichi molto più efficiente in termini risorse consumate, si ha anche uno strumento progettato specificamente per eseguire carichi Cloud Native.

La scelta dei container consente quindi di avere ambienti di lavoro standard, testati e subito operativi per gli sviluppatori, fino a raggiungere la parità tra sviluppo e produzione. Inoltre, come dicevamo, si adatta perfettamente alle esigenze dei 12 Factor / Cloud Native apps.

Container as a Service (CaaS)

Questi container devono essere gestiti dichiarativamente in modo simile a quello utilizzato per IaaS, in questo ambito ci sono diverse alternative la più nota è Kubernetes, supportato da una vasta community e dai principali operatori del settore attraverso la CNCF (Cloud Native Computing Foundation).

L'Architettura che si viene a creare con questi strumenti e metodologie richiederà inoltre di spostare o introdurre delle logiche prima gestite individualmente dai singoli applicativi a componenti infrastrutturali.

Nel prossimo articolo (Business Driven Architectures - Parte 3) proviamo ad individuare quali sono i servizi e gli strumenti che possono aiutarci a gestire il processo di adozione.

Business e IT sono legati alle stesse sorti. La loro è una relazione spesso difficile, dove si cerca di convergere sullo stesso obiettivo.

Le architetture, la progettazione,  lo sviluppo e l'operatività di un prodotto (con particolare riferimento al software) vengono spesso viste come una necessità tecnica, come un costo necessario che sottrae risorse a processi mirati a valorizzare il business.

In questo articolo proviamo a mettere in evidenza come l'utilizzo di principi architetturali e di progettazione possono invece determinare il successo di un prodotto e quindi del nostro business.

Il successo di un prodotto, è in ultima analisi, determinato dalla capacità di soddisfare le necessità e le aspettative del cliente finale.

Il concetto è semplice, ma le sue implicazioni non lo sono affatto. Conservare o creare la propria base utenti è già complicato e oggi può non essere sufficiente. Una volta raggiunto questo obiettivo la strada da percorrere è ancora in salita.

Aumentare il Valore del tuo prodotto

Sia che si tratti di un prodotto nuovo o di un'evoluzione, gli architetti software devono fin da subito tenere in considerazione una serie di requisiti non funzionali che serviranno per migliorare, correggere ed infine aumentare il valore del prodotto nel tempo.

Un utente che si avvicina al nostro prodotto, prima di diventare cliente o anche se lo è già, terrà sicuramente in considerazione:

• Funzionalità presenti
• Semplicità di utilizzo
• Affidabilità e Fluidità del prodotto
• Capacità di adattamento alle sue esigenze
• Costo di apprendimento
• Costi di acquisto/licenza

Questa valutazione è continua e non si esaurisce nel momento della sua trasformazione a cliente. Nel tempo, bisogna continuare a conquistarne la fiducia e l'interesse.

Queste necessità dovrebbero essere parte progettazione della soluzione. Aumentare il valore del servizio offerto è un'esigenza da cui nessuno può prescindere.

Rimanere al passo dei tuoi clienti

“La vita è come guidare una bicicletta. Per mantenere l'equilibrio devi continuare a muoverti”
– Albert Einstein

Capacità di comunicazione e marketing non sono più sufficienti per garantire il successo di un prodotto.
In un mercato aggressivo come Internet, mantenere e far crescere le proprie quote, è diventato a tutti gli effetti un requisito non funzionale alla base di ogni applicazione.

Nel bene o nel male, la tecnologia è ormai parte di quasi ogni aspetto della nostra quotidianità. Tutte le informazioni e i prodotti sono letteralmente a portata di mano, l'utenza è più coinvolta e si aspetta che le applicazioni siano stabili, facili da usare ma soprattutto in grado di sorprendere l'utente migliorando il servizio offerto.

Anche in mercati meno competitivi, un servizio di qualità è importante per mantenere o aumentare il proprio vantaggio competitivo.
La progettazione di un prodotto deve necessariamente tenere in considerazione questi aspetti.

Il mondo sta cambiando e anche le aziende devono scegliere se adattarsi oppure essere prima o poi travolte dal cambiamento.

Il valore dei Dati

I dati sono considerati al giorno d'oggi il bene più prezioso How Much Is Your Data Worth?.
Questo risorsa è strategica per preservare e aumentare il successo della nostra attività.

Generare dati di valore in modo preciso, veloce e intuitivo è l'obiettivo da centrare. Le informazioni ci aiutano a costruire  applicazioni migliori per i nostri clienti, ma anche ad intervenire in funzione delle loro reali necessità e quindi di quelle del mercato.
Per sperimentare nuove funzionalità o cercare di migliorare quelle esistenti, occorre avere dei dati su cui valutare i risultati ottenuti.

Comprendere il valore di queste informazioni e metterlo a frutto richiede un cambiamento a tutti i livelli, compresa l'adozione di architetture e metodologie adeguate.

Conclusioni

Il mercato ci indica chiaramente che per aver successo bisogna avere un buon piano, ma occorre anche saper utilizzare al meglio gli strumenti disponibili per ottenere un buon risultato.

Le aziende che sono state capaci di sopravvivere ma anche prosperare su questi mercati, hanno saputo rimodellare il loro modo di fare business, incentrandolo sul valore fornito al cliente.

Procedere su questa strada, o continuare per la propria rappresenta una scelta importante.
Prima di fare il prossimo passo, qualsiasi esso sia, occorre riflettere molto attentamente sulle reali necessità del vostro business.

Parliamo del proprietario di una catena di parcheggi che nasce da lontano. Il loro successo e dovuto alla continua cura per le auto depositate e alla ricerca di servizi innovativi che come piace dire a lui "coccolino" l'utente.

Ovvio che tutti i servizi dovranno essere comodamente acquistati dall'app scaricabile su tutti i cellulari. L'app sarebbe stata resa accattivante rendendo disponibili tutte le informazioni sulla propria auto oltre a avvisi per i controlli di manutenzione, tasse automobilistiche e per finire anche  il proprio conto dettagliato con le promozioni sui piani annuali.

Con questa app si possono controllare veramente tantissimi dettagli della propria auto. Si possono vedere cose come, il livello di carburante, lo stato degli interni, della batteria fino alla pressione dei pneumatici.
Insieme a ognuno di questi dettagli vengono offerti i servizi extra del parcheggio come quello per il servizio di sostituzione.

Delle tante proposte innovative ricevute il proprietario ne ritiene veramente adatte alla sue ambizioni solamente due. Ne aveva adocchiate tra quelle scartate che erano veramente interessanti ma purtroppo non si adattavano bene al suo caso. Si è messo la coscienza apposto dicendosi che le avrebbe riprese in considerazione.

Proposta del Team SeQueL

Ogni volta che entra una macchina nel parcheggio, i robots impiegati nel parcheggio la disassemblano in parti più piccole.

Ogni robot sa in quale reparto del parcheggio dovrà mettere le componenti dello stesso tipo, motori con motori, ruote con ruote e cosi via... .

Dall' app il cliente avrebbe potuto chiedere lo stato delle sue gomme, in poco tempo il reparto gomme del parcheggio le avrebbe recuperate per inviare le informazioni sullo schermo del cliente.
Nel caso in cui i pneumatici risultino usurati, l'utente potrà acquistare il servizio di sostituzione pneumatici offerto dal parcheggio come extra direttamente dal suo telefono.
Disponendo le componenti per reparto il proprietario potrà anche facilmente calcolare quante ruote in totale sono presenti nel parcheggio o se ce ne sono di particolari dimensioni o marca e fare ordini per il magazzino.

Proposta del Team "No SeQueL"

Dopo aver spiegato che il nome scelto per il loro team "No SeQueL"non è un consiglio a non scegliere la proposta del team "SeQueL", ma indica che le due strategie utilizzano principi di differenti e risolvono e creano problemi diversi, proprio opposti e quindi No+SeQueL.

La proposta del team NoSeQueL non richiede di disassemblare la macchina, il loro motto è "come as you are".
La macchina tutta intera sarà inserita in un posto auto ordinato per numero di targa.

Se ad esempio all'ingresso viene letta la targa AA 000, l'auto viene inserita nel reparto AA alla posizione 000, all'arrivo della targa AA 001 , stesso reparto AA  posto 001, subito sulla destra della  AA 000, e cosi via per tutte le targhe.

Questo avrebbe aiutato nel trovare velocemente l'auto del cliente, mostrargli lo stato dei suoi pneumatici e proporre il servizio di sostituzione.
Per soddisfare questa richiesta il parcheggio provvede alla ricerca del veicolo utilizzando il numero di targa, per poi collegarsi con il posto auto robotizzato (es. AA 000) che fornisce le informazioni su tutte le componenti dell'auto.

Gli fanno notare che questa strategia ha anche un altro grande vantaggio, non dover ri-assemblare le vetture ogni volta che l'utente vorrà ritirare la sua auto per andare a lavoro.
Anche se è corretto dire che i robot utilizzati dall'altro team sono efficientissimi nel loro compito, assemblano e disassemblano in pochissimo tempo. Quando non ci sono tante richieste di ritiro e deposito sono veloci come il tempo impiegato dalla soluzione "NoSeQueL" che deve solo recuperare l'auto.
C'è da dire che il vero collo di bottiglia non sono i robot che assemblano e disassemblano ma il tempo necessario al recupero di tutte le singole parti delle auto.

Il team "NoSeQueL" si comporta comunque correttamente e riconosce che la soluzione del Team SeQueL è sicuramente più efficiente nelle richieste incrociate dove si utilizzano più auto per raccogliere informazioni, ad esempio: Quante auto nel parcheggio hanno bisogno di sostituire i pneumatici? La risposta a questa domanda avrebbe permesso di acquistare delle scorte a prezzi vantaggiosi con alta probabilità di vendita del servizio, un bel vantaggio.
Nella soluzione NoSeQueL sarebbe servito collegarsi a tutti i posti auto del parcheggio per soddisfare la stessa richiesta invece del solo reparto pneumatici.

Il proprietario del parcheggio non riesce a decidersi e vede pregi e difetti delle due soluzioni, cosi decide di provarle entrambe.

Fatto strano, il proprietario decide di chiamare i parcheggi con i nomi dei due team o quasi, il suo reparto marketing gli ha detto che SeQueL è difficile da scrivere e se si tolgono le minuscole la pronuncia è sempre la stessa, quindi SQL. Stesso per il team NoSeQueL ma in questo caso gli è stata lasciata la "o" NoSQL.

TO BE CONTINUED ...

Quali sono i vantaggi di un'applicazione in grado di dimensionarsi dinamicamente?

Riduzione dei costi di Infrastruttura IT

Variando il numero delle repliche, variano anche le risorse impiegate da ogni singolo applicativo / microservizio.

Acquistando risorse in base all'effettivo tempo di utilizzo come avviene nei Public Cloud la matematica è piuttosto semplice (repliche per costo al minuto)

Quando invece le risorse sono di proprietà e si parla di Private Cloud o più in generale infrastrutture private, la riduzione dei costi può essere ottenuta attraverso la condivisione.

In generale per dimensionare le risorse necessarie all'esecuzione di un applicativo si prende come riferimento il caso peggiore dove si ipotizza un traffico / carico massimale e si acquistano risorse capaci di gestire quel carico.
Se la stima è stata eseguita correttamente, l'utilizzo effettivo sarà molto inferiore alle capacità acquistate. Un pò come avere una Ferrari per girare in città, al semaforo tutti rimarranno impressionati dall'accelerazione, ma il motore sarà raramente al massimo della potenza.

La virtualizzazione consente di mitigare questo overprovisioning allocando risorse virtuali in quantità superiore a quelle reali.
Questo scenario nei casi comuni prevede un numero di repliche stabili che hanno un effettivo utilizzo di risorse anche quando queste non vengono utilizzate (spazio disco, allocazione ram).

Se l'applicazione invece è in grado di diminuire o aumentare le repliche senza produrre effetti collaterali apprezzabili e quindi di scalare, le risorse nuovamente disponibili possono essere ridistribuite attribuendo delle priorità ai carichi di lavoro: Transazioni OnLine > Analisi Dati > Processi Batch

Business Continuity

Un'applicazione progettata per operare su apparati non affidabili è nativamente in grado di spostare i suoi carichi di lavoro da un centro di calcolo ad un altro.

Se questa applicazione ad esempio viene eseguita in un Hybrid Cloud è facile immaginare che in caso di interruzione del servizio nella parte Private i carichi di lavoro possano essere assorbiti nella parte Public e viceversa.

Attraverso i principali Public Cloud provider è anche possibile distribuire le applicazioni su diverse region (aree geografiche) o all'interno della stessa region su più availability zone (suddivisioni indipendenti delle region inter-connesse con link a bassissima latenza) per ridondanza.

Utilizzando gli accorgimenti architetturali necessari e avvalendosi di questi strumenti è perciò possibile garantire livelli di business continuity molto elevati senza aumentare i costi ( es connettività con SLA elevati, apparati in standby , costi di gestione, etc)

Aggiornamenti e Miglioramenti Infrastrutturali

Le applicazioni non sono statiche e più o meno velocemente aggiungono nuove funzionalità, aumentano la base degli utenti e gli apparati utilizzati per eseguire i carichi di lavoro sono soggetti ad obsolescenza.

L'infrastruttura su cui questi carichi applicativi vengono eseguiti può essere gestita seguendo due principi Pet (animale domestico) o Cattle (Bestiame).

Nell'approccio Pet, le infrastrutture sono gestite in modo diretto ed eventualmente differenziato in relazione ai carichi di lavoro. Questo situazione crea una sorta di legame tra applicazione e server, (es. struttura del filesystem, indirizzi di rete, configurazione dei permessi, servizi di sistema, etc) difficile da spezzare.

In contrapposizione l'approccio Cattle chiede ai carichi di lavoro di astrarre tutte le risorse necessarie. Le applicazioni non possono fare affidamento su un ambiente particolare ma solo su risorse astratte che una qualsiasi infrastruttura può  "implementare" e rendere disponibili ai carichi applicativi.
In pratica si chiede alle applicazioni di considerare le risorse come volatili ed effimere (pezzi di ferro), che in caso di problemi non vengono sistemate ma semplicemente rimpiazzate.

Seguendo questa filosofia, effettuare un aggiornamento infrastrutturale diventa semplice la cancellazione di una replica, nell'attesa che questa venga ricreata in automatico su apparati di nuova generazione.

Performance e Scalabilità

Quando si dimensiona un sistema in base al caso peggiore,  il business spera sempre di sbagliare per difetto.

Il sogno proibito di ogni imprenditore è quello di dover correre ai ripari dopo aver sbagliato una previsione di circa 1.000 utenti paganti a fronte di 100.000 reali.
Anche se questo è quello che potremmo definire come Happy Problem dal punto di vista tecnologico e architetturale potrebbe diventare un vero e proprio incubo.

Adeguare un applicativo progettato o costruito con strumenti non adatti a scalare di ordini di grandezza (es. database relazionali ) può essere una operazione assai ardua, composta da una serie di interventi che possono essere costosi , rischiosi o complicati.

In queste situazioni, le architetture a microservizi si comportano molto bene permettendoci di:

• scalare indipendentemente ciascun servizio (es. il servizio di Ricerca Articoli può essere sicuramente più congestionato di un servizio registrazione utenti )
• aggiungere e rimuovere server per far fronte ad un carico immediatamente (anche senza intervento manuale)  pagandoli al minuto o acquistandoli solo in momenti successivi

Conclusioni

Cloud Computing, Virtualizzazione, Containerizzazione, Progettazione a risorse infinite, etc,  sono strumenti indispensabili per la costruzione di applicazioni performanti, scalabili, localizzate su una singola regione o distribuite su scala mondiale ed utilizzare ( pagando l'effettivo utilizzo) infrastrutture di ultima generazione.

La vita quotidiana ci insegna che possedere uno strumento non ci permette automaticamente di godere di tutti i benefici/servizi che questo può offrire, se non li si utilizza adeguatamente si rischia di avere effetti potenzialmente devastanti.

Utilizzare le tecniche architetturali e le tecnologie pensate per sfruttare al massimo questi strumenti non è banale e richiede una formazione costante.

La scelta, delle -ilities architetturali, di un'approccio a microservizi o monolitico, coreografia o orchestrazione, ACID o consistenza eventuale sono solo alcuni esempi delle domande che ci si dovrebbe porre per sfruttare al meglio gli strumenti a nostra disposizione.

Sono proprio queste scelte frutto delle conoscenza della creatività  che influenzano il successo o l'insuccesso di un progetto, quelle pennellate di un quadro che in altri contesti chiamiamo arte.

Lo scopo finale è quello di creare un canale WebSocket che sia in grado di mandare lo stesso messaggio in real-time a più client connessi al medesimo WebSocket Server.

Cosa è una WebSockect

Una WebSocket viene utilizzata per creare un canale bidirezionale che permette di instaurare una comunicazione real-time tra Client e Server

(1 min) Creiamo il progetto (NodeJS)

Se avete già installato NodeJS avete già tutto il necessario, altrimenti (Nodejs).

$ npm init -y

(3 min) Come aprire una WebSocket Server

Per questo progetto utilizzeremo la Libreria ws che ci permetterà di implementare una WebSocket lato Client e Server in modo semplice e immediato. Installiamo la libreria con il comando:

$ npm install ws

Creiamo su un file ws.js un semplice WebSocket Server nel quale viene aperta la porta 8080 in attesa di nuove connessioni.

const WebSocket = require("ws");
const wss = new WebSocket.Server({port: 8080});
module.exports = wss;

Creiamo un file server.js e importiamo il modulo ("./ws"). Utilizziamo il metodo .on di wss per intercettare gli eventi di connessione che producono delle WebSocket, ovvero, i canali di comunicazione tra il server e chi si è connesso alla WebSocket.

Ogni qual volta viene scatenato l’evento di connessione e di conseguenza il Client si connette al Server Websocket viene aggiunto il canale di comunicazione tra Server e Client all’array connectedClients.

const wss = require("./ws");
const connectedClients = [];
wss.on("connection", ws => { connectedClients.push(ws);});

Creiamo un nuovo file generator.js che utilizzeremo per generare una stringa di 4 emoji casuali da un array di emoji. Definiamo una funzione generator che prende come parametro un oggetto composto dalla funzione callback, che come vedremo in seguito si occuperà di inviare la stringa ai Client connessi, e dal maxTime che definisce l’intervallo di tempo tra un invio e l’altro.

const dictionary = ["😎", "🥝", "🚀", "💥", "🐳", "⚽️", "💩", "🔌", "🐛"];

function generator({ callback, maxTime }) {  
let emoString = generateRandom();  
callback(emoString);  

setInterval(() => {    emoString = generateRandom();  
callback(emoString);  }, Math.floor(Math.random() * maxTime));

function generateRandom() {    
return `${pickEmojii()}${pickEmojii()}${pickEmojii()}${pickEmojii()}`;  }

function pickEmojii() {    return dictionary[Math.floor(Math.random() * dictionary.length)];  }}

module.exports = generator;

Quindi nel file server.js importiamo il modulo  ("./generator"). E richiamiamo la funzione generator, passiamo l'oggetto come parametro e definiamo le proprietà maxTime e callback.

( 3 min ) Gestire l'aggiornamento su tutti i client

Ragionamento che spiega come modificare il server per aggiornare tutti i ws ogni volta che la emoString cambia

Nella callback andremo a scorrere l’array connectedClients e per ogni connessione invieremo la stessa stringa di emoji.

Il file server.js  quindi apparirà in questo modo:

const wss = require("./ws");
const generator = require("./generator");
const connectedClients = [];

wss.on("connection", ws => {  
connectedClients.push(ws);
});

generator({  maxTime: 20000,  callback: emoji => {    		         			connectedClients.forEach(ws => {
      ws.send(emoji);     
     });  
}});

Quindi  per avviare il server che sarà in ascolto sulla porta 8080, da terminale eseguire il comando:

$ node server.js

(3 min ) il Client (w/StackBlitz )

StackBlitz è un editor online per Web apps.

Su StackBlitz, si possono creare nuovi progetti e ottenere l'embed code dal link "Share" nella barra di navigazione in questo modo:

Il lato Client della websocket è su StackBlitz
Con il file  index.js creiamo la connessione WebSocket sulla porta 8080, socket.addEventListener si mette in ascolto della realizzazione dell’evento message. Con l’ event.data prendiamo i dati dell’evento, e quindi il contenuto del messaggio. All’interno di .data sarà presente la stringa di emoji inviata dal Server.

// Import stylesheets
import "./style.css";

// Write Javascript code!
const appDiv = document.getElementById("app");
// Create WebSocket connection.
const socket = new WebSocket("ws://localhost:8080/");

// Connection opened
socket.addEventListener("open", function(event) {
  socket.send("Hello Server!");
});

// Listen for messages
socket.addEventListener("message", function(event) {
  appDiv.innerHTML = event.data;
});

creiamo un file index.html per la visualizzazione delle emoji:

Risultato finale:

( 1 min ) Compiacersi del lavoro fatto  💪🏻

+ (ngrok, codice sorgente e bonus vari)

Per esporre il nostro localhost utilizzeremo Ngrok. Ngrok ti consente di esporre su Internet un server web in esecuzione sul tuo computer locale. Basta dire a Ngrok su quale porta il tuo server Web è in ascolto con il comando:

$  ngrok http 8080

In questo modo viene creato un tunnel tra il server messo a disposizione da Ngrok e l’eseguibile che gira sulla tua macchina localmente. Tutto quello che arriva sull’host di Ngrok viene girato sulla porta 8080.

all'avvio Ngrok, verrà visualizzata un'interfaccia utente nel tuo terminale con l'URL pubblico del tunnel e altre informazioni sullo stato delle connessioni effettuate.

Nella parte inferiore della User Interface sono presenti tutte le chiamate HTTP che vengono effettuate dai client.

+ Nei prossimi episodi

Creare un gioco con i Ws