If not, how do you decide whether micro services are appropriate for your environment?
Semplicemente tramite pain . Sembra insolito, ma dal mio punto di vista è un indicatore valido, che qualcosa sta andando storto.
Se osservi i motivi, perché microservices sono di gran moda, c'è una dimensione storica che svolge un ruolo importante.
In genere i progetti di successo sono fatti così:
-
Inizia con un prototipo
-
Prototipo di carne
-
Fai carriera
-
Enorme crescita che si traduce in
a. Un gran numero di funzionalità sono fuori servizio
b. Crescita di codice oltre il controllo
-
PAIN inizia : la pianificazione delle distribuzioni diventa un incubo, i sottosistemi dipendenti non possono essere distribuiti separatamente
-
RELIEF Microservizi FTW
Dividere l'intera base di codice in componenti facili da implementare.
La domanda che stai ponendo è un buon indicatore, che non stai vivendo dolore a un tale livello, che sarebbe necessario per passare ai microservizi.
Fare microservizi non è senza un prezzo. Il tuo sistema aumenterà definitivamente in termini di complessità.
-
Quando hai un monolite, il tuo mondo è semplice: »Chiama un metodo, fai cose, ottieni risultati dopo un intervallo di tempo precalcolabile«
-
Quando hai a che fare con microservices , vai dritto nel fango dei sistemi distribuiti: »Chiamami forse«
Le cose che sono certe in un monolite, diventano incerte in un mondo di microservizi .
Il motivo, perché l'approccio microservice è stato scelto da molte grandi aziende è semplice : trattare i problemi dei sistemi distribuiti è stato più semplice del ridimensionamento del loro monolito.
Ovviamente: da un punto di vista architettonico, un gruppo di unità separate sembra più pulito (sulla carta) di un bulbo di un monolito.
I lead a team of developers and one of them insists that we adopt a micro services approach to architecture.
Gli chiederei cosa cambierebbe (bene o male) nel tuo concreto scenario.
We won't ever be servicing millions of users and there's only 5 of us so it's not like we're going to have full teams dedicated to such fine-grained services.
Non vedo un problema (diretto) qui. La suddivisione della base di codice in parti distaccabili separate non ha nulla a che fare con le dimensioni della squadra. Il codebase in quanto tale sarebbe quasi lo stesso. Se il tuo team gestisce ora la base di codici, dovrebbe essere possibile farlo dopo la migrazione.
Ciò che è necessario, oltre a dividere il codice base, è: educare la tua squadra in termini di come affrontare i problemi dei sistemi distribuiti . Questo è un investimento da fare.
We won't ever be servicing millions of users and there's only 5 of us so it's not like we're going to have full teams dedicated to such fine-grained services.
I wouldn't call these micro services as they're a bit more coarse than the fine-grained responsibilities that micro services appear to have.
I microservizi non hanno nulla a che fare con milioni di utenti, anche se con problemi di distribuzione di un codebase di fronte a un milione di utenti. Altro: nonostante il termine »micro«, i "servizi" non devono essere solo di 100 righe o così - che è uno , ma non il solo solo motivo per chiamarlo " micro".
Mi piace il termine "servizio focalizzato" molto di più. Ecco di cosa si tratta: in termini di »separazione delle preoccupazioni« un tale servizio tratta un argomento.
tl; dr
Se non si verificano problemi durante l'esecuzione del sistema attuale, non si dovrebbe effettuare alcuna commutazione.