Ci sono molte discussioni in corso nel mondo Monolith v/s Microservices. La maggior parte della mia carriera iniziale è stata dedicata alla costruzione di monoliti e, naturalmente, quando le architetture orientate ai servizi hanno iniziato a mettere radici, le abbiamo adottate con una buona misura di successo.

La mia esperienza

Non ho bisogno di sembrare figo qui e lanciare cose come la legge di Conway alla gente. La mia esperienza limitata mi ha insegnato che abbiamo avuto individui, piccoli team e grandi team, a cui è stato chiaramente affidato l'incarico di un particolare modulo (chiamatelo servizio se volete). Come parte della loro responsabilità, dovevano fare quanto segue:

• Dovevano possederlo
• Dovevano mantenerlo
• Dovevano comunicarlo
• Crea API interoperabili che rispettino i contratti
• Testare il proprio software
• Fai attenzione ai test di integrazione
• Essere in grado di specificare come distribuire le proprie cose negli ambienti
• Eseguire il debug e, soprattutto, tracciare una chiamata nello schema generale delle cose.

Non si tratta di Monolith o Microservizi

Non esiste davvero una pallottola d'argento. Non c'è un angolo definitivo per passare ai microservizi o andare con un monolite. Chiunque parli di andare in una direzione o nell'altra non ha alcuna intenzione sbagliata nel cercare di influenzarti, ma con il dovuto rispetto, ogni organizzazione e i suoi team di sviluppo saranno diversi, i loro requisiti saranno diversi, come devono evolversi o supportare i nuovi servizi/dispositivi saranno diversi. Dovrai essere al posto di guida per comprendere la tua organizzazione prima di adottare ciecamente qualsiasi visione di una grande azienda o influencer.

In nessun momento un'organizzazione dovrebbe sottovalutare la necessità di gestire team di persone, portando un po' di ordine, automazione, test, dando ai team la libertà e la flessibilità di scegliere gli strumenti e mantenendoli disciplinati e altro ancora.

Tieni da parte per un momento la questione dei monoliti e dei microservizi. Stai affrontando problemi fondamentali come la comunicazione di gruppo, le gerarchie, il processo decisionale, la disciplina e l'igiene dell'ingegneria del software, la copertura dei test, l'automazione, l'autonomia e altro ancora? Pensaci per un momento.

Cosa consiglio?

Nel mio libro, preferisco esaminare un'applicazione nella sua interezza e fondamentalmente perché esiste in primo luogo? Una volta che hai queste risposte, guarda quali sono i casi d'uso o i percorsi degli utenti dei clienti che gli utenti interagiscono con la tua applicazione? Per me, alla fine si riduce a quanto segue:

1. Hai bisogno di un processo efficiente (completamente automatizzato o meno) per sviluppare e distribuire la tua applicazione in vari ambienti ed essere in grado di spostare le versioni tra di loro.
2. È necessario disporre di un processo efficiente per tracciare le modifiche del codice sorgente a ciò che è stato distribuito in produzione.
3. Infine, e cosa più importante, quando succede qualcosa e cosa accadrà, hai la possibilità di tracciare e tracciare ciò che sta accadendo, individuare il componente che sta causando il problema, eseguire il debug in modo efficiente e comprendere la causa principale e quindi disporre di un processo per implementare il modifiche per mitigare gli utenti interessati.

Ora, se i monoliti e / o l'architettura dei microservizi possono aiutarti a risolverlo, dati i vincoli della tua organizzazione, segui quello. Non sei Google, Facebook, Microsoft, Amazon e loro non sono te. Non hai nemmeno bisogno di confrontarti immediatamente con altre organizzazioni, che potrebbero essere più intelligenti, agili o con una qualsiasi di queste caratteristiche.

Tutto quello che devi fare è costruire una cultura sana nella tua organizzazione che sia aperta alla discussione e inizi a misurare ciò che DORA raccomanda:

• È ora di ripristinare il servizio
• Cambia il tasso di fallimento
• Tempi di consegna per le modifiche
• Frequenza di distribuzione.

La mia osservazione conclusiva è concentrarsi su ciò che ti fa fornire il tuo software in modo efficiente (costi, operazioni e tutto incluso). Tutto il resto è come un dibattito sul telegiornale delle 21:00.