“L’unico fascino del passato è che è passato”.

– Oscar Wilde

L’ispirazione per arrivare ad una soluzione è la gestione della configurazione di SpringBoot, e si basa su alcuni semplici prerequisiti che un’applicazione moderna dovrebbe avere:

• PREREQUISITO 1. Deve essere resiliente

  Se la configurazione non è presente o incompleta, l’applicazione deve comunque avviarsi con dei valori di default arbitrari ma sensati.

• PREREQUISITO 2. Deve poter essere configurata velocemente

  In base all’infrastruttura di installazione deve essere configurabile nel modo più semplice e veloce possibile.

• PREREQUISITO 3. Deve potersi adattare a varie infrastrutture di installazione

  La stessa applicazione deve poter essere installata su un server, in docker, in cloud (AWS, Azure…), lanciata direttamente come eseguibile.

• PREREQUISITO 4. Deve poter essere scalato su più nodi

  Per garantire facilmente una serie di parametri comuni a tutti e alcuni specifici per i singoli nodi.

A questo punto la domanda da porsi è: “quale tra tutti i sistemi visti precedentemente è il migliore per garantire i vincoli che ci si pone?”
La risposta, sebbene in contrasto con il principio KISS, di cui abbiamo già parlato e che nel nostro campo si rivela quasi sempre essenziale, è semplice: tutti i sistemi visti sono adatti, ma usati assieme.

Prendiamo un esempio pratico: la nostra applicazione deve generare dei file in una cartella, quindi necessita di una impostazione per decidere il percorso di questa cartella di salvataggio.

A questo punto il parametro viene letto dall’applicazione in queste posizioni e in quest’ordine:

• Una variabile scolpita nel codice con un default

  – prerequisito 1

• Un valore in un file di configurazione (magari con vari formati), cercando il file all’interno dell’applicazione stessa, poi in una serie di cartelle predeterminate (cartella corrente, cartella di sistema, cartella utente…) o nel classpath dell’application server

  – prerequisito 1, 2 e 3

• Database

  – soprattutto prerequisito 2

• Variabili d’ambiente (nominati secondo uno standard in modo che sia facile farli corrispondere ai valori nel file di configurazioni)

  – prerequisito 3

• Parametri da riga di comandi (con la stessa convenzione per la nomenclatura)

  – prerequisito 3

Le varie fonti da cui proviene la configurazione sovrascrivono la precedente (se non c’è il parametro da riga di comando uso la variabile d’ambiente, poi il file di configurazione e così via),in modo che chi lancia o installa l’applicazione possa scegliere il metodo più adatto alla necessità immediata.
Ecco come viene garantito il prerequisito 4.

Un esempio pratico:
Un’applicazione che in sviluppo viene lanciata da un IDE, quindi prende le configurazioni da un file di configurazione (stiamo comunque ricompilando il sorgente ogni volta, quindi non è un particolare problema), mentre poi in test è lanciata in un container docker che passa i parametri da riga di comando per poter essere rilanciato in più istanze, senza dover ricreare un binario ogni volta, e in produzione è installata in AWS, dove prende i parametri da variabili d’ambiente.

Può sembrare uno sforzo eccessivo solamente per alcuni parametri di configurazione, ma la libertà e la flessibilità che permettono al sistema finale sono impagabili ed esistono sempre più librerie che aiutano a gestire il tutto in modo semi-automatico.