Architettura software scalabile: best practice per piccoli team

I piccoli team (da 2 a 5 sviluppatori) hanno un superpotere: la comunicazione veloce. Tutti sanno cosa stanno facendo gli altri. L’architettura software per questi team deve migliorare questa agilità e non creare burocrazia.

Se hai un team piccolo, copiare l'architettura di Google è un suicidio. Hai bisogno di un'architettura che ti consenta di offrire valore con poche persone.

Serverless (il migliore amico del piccolo team)

Serverless (AWS Lambda, Google Cloud Functions) è l'architettura definitiva per piccoli team.

Manutenzione zero: non c'è nessun server da aggiornare, nessun sistema operativo a cui applicare patch.
Costo per utilizzo: Se nessuno lo utilizza nelle prime ore del mattino, paghi zero.
Scala infinita: se 1 milione di persone vi accedono, il cloud aumenta di 1 milione di funzioni.

Il tuo team si concentra al 100% sulla scrittura della funzione ("richiesta di salvataggio") e allo 0% sul mantenimento del server in esecuzione.

Automazione estrema (CI/CD)

Con poche persone, non è possibile avere un "QA" (tester) manuale che fa clic su tutto prima della distribuzione.

Deploy Pipeline: ogni commit nel ramo main deve andare in produzione automaticamente dopo aver superato i test.
Test automatizzati: scrivi test di integrazione (che testano il funzionamento dell'API) invece di concentrarti troppo su test unitari microscopici. Testa ciò che conta per l'utente.

Documentazione "Viva" (Codice autoesplicativo)

I piccoli team odiano scrivere documentazione in Word (che non è aggiornato in 1 settimana).

OpenAPI (Swagger): utilizza strumenti che generano documentazione API dal codice.
Suggerimento sul tipo: utilizzare TypeScript (se JS) o la digitazione Python. Questo serve come documentazione di "cosa questa funzione si aspetta di ricevere".

Evita la "sindrome dell'invenzione qui"

Non scrivere il tuo [sistema di autenticazione. Non scrivere il tuo framework CSS.

Utilizza Auth0 o Firebase Auth.
Utilizza Tailwind o Bootstrap.
Utilizza librerie standard.

Il codice più scalabile è il codice che non è stato necessario scrivere (e che non è necessario mantenere).

Conclusione