Business Driven Architectures

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.