La cosa più importante da ricordare con i microservizi è che non si tratta principalmente di risolvere problemi tecnici ma di problemi organizzativi. Pertanto, quando esaminiamo se un'organizzazione deve utilizzare i microservizi e come vengono distribuiti tali servizi, dobbiamo verificare se l'organizzazione ha i problemi che lo stile dei microservizi risolve.
La risposta alla tua domanda sulla tua architettura, quindi, dipenderà principalmente dalle dimensioni del tuo team tecnologico, dalla struttura organizzativa, dall'età del tuo prodotto, dalle tue attuali pratiche di implementazione e da come queste potrebbero cambiare nel medio termine.
Ad esempio, se la tua organizzazione:
- ha meno di 25 dipendenti tecnici,
- organizzato in 1 o 2 squadre,
- ognuno dei quali funziona su qualsiasi parte del prodotto,
- che ha meno di 12 mesi,
- e viene distribuito tutto in una volta su base regolare (ad esempio giornaliero, settimanale, mensile),
- e l'organizzazione non sta per crescere rapidamente,
allora quasi sicuramente ti dimenticherai dei microservizi per ora. In una situazione come questa, il team è ancora nuovo nell'imparare il dominio, quindi probabilmente non sa tutto ciò che dovrebbe sapere per capire davvero quale sarebbe un ottimo modo per suddividere il sistema in un'architettura distribuita. Ciò significa che se lo dividono ora, probabilmente vorranno cambiare i confini in un secondo momento, e questo diventa molto costoso quando si dispone già di un sistema distribuito, pur essendo molto più semplice in un monolite. Inoltre, con solo un piccolo team in grado di lavorare (e supportare) qualsiasi parte del sistema, ci sono poche ragioni per investire nella costruzione di una piattaforma in cui i singoli team possono implementare e mantenere singoli servizi. Un'organizzazione in questa fase sarà in genere molto più interessata a trovare clienti e iterare rapidamente il prodotto, forse persino a far perno sul prodotto, anziché a rendere i team autonomi e a costruire un'architettura su larga scala e resiliente. Un'architettura monolitica ha senso a questo punto, ma amonolito ben progettato , con chiari confini dei componenti imposti dalle API e accesso incapsulato ai dati, che semplifica l'estrazione dei servizi in processi separati in seguito.
Diamo un'occhiata un po 'più avanti e consideriamo un'organizzazione che è ...
- oltre 50 addetti tecnologici,
- organizzato in 7 squadre,
- ognuno dei quali funziona solo su aree specifiche del prodotto,
- che ha 3 anni,
- e ha team che vogliono distribuire il proprio lavoro indipendentemente da ciò che fanno gli altri team.
Una tale organizzazione dovrebbe sicuramente costruire un'architettura distribuita. In caso contrario, e invece tutti questi team lavorano in un monolito, si imbatteranno in tutti i tipi di problemi organizzativi, con i team che devono coordinare il loro lavoro, i rilasci vengono ritardati mentre il team termina il QA sulla sua nuova funzionalità, patch si rivela una seccatura per il personale e i clienti. Inoltre, con un prodotto maturo, l'organizzazione dovrebbe conoscere abbastanza bene il dominio per poter dividere sensibilmente sia il dominio che i team (in questo ordine; vedi la Legge di Conway) in unità sensibili e autonome che possono fare progressi minimizzando il coordinamento.
Sembra che tu abbia già scelto i microservizi. A seconda di dove ti siedi sulla bilancia sopra, forse vuoi rivisitare quella decisione.
Se vuoi continuare a sviluppare con i microservizi ma implementandoli tutti in un unico contenitore, sappi che non c'è nulla di sbagliato in questose si adatta al modo in cui la tua organizzazione lavora al momento. In futuro creerà problemi per la struttura del tuo progetto? Bene, se hai successo e la tua organizzazione cresce, probabilmente arriverà un momento in cui questa distribuzione a contenitore singolo non è più la soluzione migliore, in particolare quando i team iniziano a possedere i servizi e vogliono distribuire solo il loro servizio senza distribuire l'intera applicazione . Ma tale autonomia arriverà a scapito del lavoro extra e della complessità, e potrebbe non darti alcun vantaggio in questo momento. Solo perché non sarà l'approccio giusto per il tuo sistema in futuro non significa che non sia l'approccio giusto per oggi. Il trucco sta nel tenerlo d'occhio e sapere quando fare l'investimento extra.