Stiamo rifacendo un vecchio sistema di 10 anni, lo sviluppatore dice "microservizi": è la scelta giusta per un prodotto piccolo?

Probabilmente il vostro sviluppatore vuole solo aggiungere architetture di tendenza al proprio curriculum. 1.200 utenti girano tranquillamente su un singolo server ottimizzato con un normale database relazionale. Far gestire i microservizi a tre persone vi raddoppierà come minimo i tempi di consegna.

L'anno scorso abbiamo fatto lo stesso identico errore con un team di 4 persone. Abbiamo diviso il sistema in cinque microservizi e i primi 6 mesi li abbiamo passati a risolvere problemi di comunicazione tra i vari servizi. Le nostre fatture per l'infrastruttura cloud sono schizzate da 400 a 2.300 dollari al mese. Alla fine siamo tornati a un monolite modulare e la velocità di sviluppo è triplicata.

Quando passi ai microservizi non ti limiti a scrivere codice. Devi mettere in piedi service discovery, code di messaggi, logging distribuito e gestione delle transazioni distribuite. Dovendo spezzare anche il database, persino una semplice JOIN in SQL si trasforma in una trafila di chiamate API tra servizi. Senza un sistemista/DevOps a tempo pieno nel team, il sistema non andrà più veloce, anzi rallenterà.

Nel rifare il sistema seguite questi tre passi: 1) Ripulite lo schema del database attuale collegandolo direttamente alla logica di business; 2) Organizzate la codebase in cartelle con la disciplina dei microservizi, ma mantenendola in un unico progetto (monolite modulare); 3) Scrivete solidi test unitari e di integrazione per azzerare i rischi durante il rilascio in produzione.

ci siamo passati anche noi due anni fa con lo stesso entusiasmo. boh bastava ke andasse giù un servizio x far crollare tutto a catena seguire i log era diventato un inferno... con un team piccolo il monolite tutta la vita, zero senso andarsi a cercare rogne.

Ma se creiamo un sistema monolitico, quando in futuro gli utenti saliranno a 10 mila o 50 mila dovremo buttare via tutto? Non stiamo bloccando la crescita sul nascere?

Anche 50 mila utenti girano benissimo su un singolo server ben ottimizzato. Ci sono piattaforme SaaS globali gigantesche che gestiscono milioni di operazioni e sono ancora basate su architetture a monolite modulare. Se e quando servirà in futuro, trasformerete in servizio solo il modulo che fa da collo di bottiglia; partire adesso con un sistema distribuito non porta alcun vantaggio.

Considerando il budget a disposizione e le risorse umane attuali, l'approccio più sensato in ottica di gestione del rischio è un'architettura a monolite modulare. Concentrarsi sulle funzionalità del prodotto anziché sulla complessità infrastrutturale aumenterà direttamente il ritorno sul vostro investimento.

Approfondisco l'aspetto tecnico. Le decisioni affrettate diventano decisioni da correggere sei mesi dopo.

Correggetemi se sbaglio.

in generale è corretto, ma manca un pezzo e le decisioni affrettate diventano decisioni da correggere sei mesi dopo.

quuesto thread è archiviato.

Preso nota, grazie. Il fatto che tutti facciano una cosa non significa che sia quella giusta.

Sono curioso di sapere se qualcuno lo fa in modo diverso.

prseo nota grazie.

C'è anche un aspetto di misurazione. I primi tre mesi vanno bene, i problemi emergono al quarto mese.

Se avete domande scrivete rispondo per quanto possibile.

Non lo sapevo.

Ho vissuto la stessa cosa.

Parlo dal lato opposto, io sono dalla parte dei fornitori. Il fatto che tutti facciano una cosa non significa che sia quella giusta.

Prendere appunti per due settimane dà risultati migliori rispetto a una stima di sei mesi. Correggetemi se sbaglio.

Riassumo quanto detto finora. Se ricevete tre risposte diverse su un argomento, la domanda è posta male.

Confermato dall'esperienza.