Ho passato gran parte della mia carriera in startup, dove spesso si lavora con budget risicati, organici sottodimensionati e una scadenza alle porte. È facilissimo cedere alla pressione e tagliare gli angoli pur di consegnare qualcosa subito, ma il prezzo è che, nel giro di un paio d'anni, ci si può ritrovare con un caos tecnologico tale da farsi odiare il proprio mestiere e portare al burnout.
Purtroppo parlo per esperienza diretta. Una volta ho fatto da solo il lavoro di tre persone e dopo tre anni a quel ritmo ero arrivato al punto in cui non m'importava più di nulla: avrei voluto soltanto fissare il soffitto in silenzio per tutto il giorno.
Niente paura, è successo parecchio tempo fa e mi sono ripreso del tutto. Anzi, con un po' di disciplina sono riuscito a evitare che si ripetesse nelle tappe successive della mia carriera. Col tempo ho distillato alcuni ingredienti chiave per tenere alta, sul lungo periodo, la voglia di innovare.
Oggi ho la fortuna di ricoprire un ruolo che mi permette di condividere la mia esperienza e aiutare gli altri a trasformare i propri sogni in azione.
Questa è la mia storia, fatta della mia esperienza. Lei avrà sicuramente la sua, e sarei curioso di ascoltarla.
Il team da sogno
Immagini un team di sviluppo software composto da 5–10 persone che:
- Rilascia nuove funzionalità con regolarità
- Si accorge dei downtime prima dei propri clienti
- Risolve i bug in fretta — e per "risolti" intendo risolti in produzione, non sul branch main di git
- Ha il tempo di fare ricerca e sperimentare nuove tecnologie
E che riesce a farlo per anni senza mai esaurire le energie!
Sembra troppo bello per essere vero? Vediamo. Ecco come imposterei oggi un nuovo progetto. Sarà un progetto cloud-based, nel mio caso su GCP.
1\. Conosca il terreno su cui costruisce
La sicurezza viene spesso trascurata. Gli sviluppatori la considerano ostica e la studiano giusto quel che basta per superare i default minimi del cloud e iniziare a costruire. In fondo, i clienti non comprano sicurezza: comprano funzionalità, e ai loro occhi la sicurezza del prodotto è data per scontata.
Purtroppo, un approccio del genere porta in fretta a brutte abitudini — "chiavi di sicurezza in un repository git pubblico", a qualcuno suona familiare? : )
Punti chiave:
- Mantenga una baseline di sicurezza nel team rispetto alla tecnologia che utilizza. Per esempio, se sta partendo su un nuovo cloud, si assicuri che tutti (e non solo le persone DevOps) ne conoscano le basi. Con GCP, ad esempio, uno sviluppatore medio può prendere dimestichezza con il modello di sicurezza in poche ore.
- Abbia una persona di riferimento che faccia mentoring sulle best practice di sicurezza. Se non la trova all'interno del team, Google, nel nostro esempio, ha partner pagati proprio per fare da cassa di risonanza su questi temi.
Ricordi il modello di responsabilità condivisa dei cloud provider: forniscono mattoni sicuri, ma sta a Lei comporli in modo sicuro.
Una volta chiariti i presupposti di sicurezza, può iniziare a progettare l'architettura.
2\. Progetti, ma con i piedi per terra
Sogniamo tutti che la nostra azienda diventi la prossima Twitter, Uber o Google. Ma nessuna di queste è nata già su scala globale.
La sfida è partire piccoli mantenendo sempre lo spazio per crescere. Per riuscirci suggerisco di costituire una piccola task force interna al team, con il compito di evitare che il gruppo si lasci troppo assorbire dal pensiero tattico — cosa che accade naturalmente quando si entra nella cadenza dello "sfornare feature". Questa task force vigilerà affinché si facciano i giusti compromessi, per esempio:
- Una volta ho sviluppato un batch-job manager per il database ElasticSearch. Realizzarlo in modalità active/active e scale-out avrebbe richiesto uno sforzo dieci volte superiore, mentre una versione singleton era in grado di reggere una crescita del carico fino a cento volte; e poco male se va offline per 10–15 minuti per un bug o un intervento di manutenzione.
In quel caso abbiamo scelto consapevolmente di avere un componente con single point of failure, perché era più che sufficiente per le nostre esigenze di business.
- Sul piano strategico, magari vuole sviluppare un prodotto cloud-agnostic. Può scegliere Kubernetes (K8s) come piattaforma applicativa, e già solo questa scelta Le permette di coprire circa l'80% dell'obiettivo. Tuttavia, dovrà comunque interfacciarsi con servizi extra-K8s del Suo cloud provider, ad esempio Load Balancer, Message Queue e così via; e spetterà alla task force di architettura assicurarsi che nessun servizio specifico di un singolo provider venga adottato nella foga di una scadenza. E quando capita, deve essere una scelta consapevole e ben documentata.
I tech lead più senior assumeranno naturalmente questo ruolo, ma è meglio formalizzarlo e fare in modo che la loro voce venga davvero ascoltata. Le discussioni post-mortem che iniziano con "te l'avevo detto sei mesi fa che si sarebbe rotto" sono il segnale che la task force di architettura ha bisogno di una messa a punto. Il tema è "fidarsi dei team".
Perché la task force di architettura funzioni e l'intero team ne tragga beneficio, è cruciale che Product Owner e management si fidino del fatto che gli sviluppatori agiscano con le migliori intenzioni. Sviluppatori responsabili tendono a cedere abbastanza facilmente alla pressione delle feature, e da lì si scivola in fretta nella modalità "te l'avevo detto…".
3\. Inizi a programmare partendo dal CI/CD
Quanto detto sopra può suonare un po' radicale, ma spero di aver catturato la Sua attenzione. La trappola classica è "prima le feature, poi i test". Sotto la pressione delle scadenze, i test sono di solito i primi a saltare.
Le racconto un aneddoto personale. Avevo un progetto con un'ottima architettura a cui mancava un solo tassello: avevamo investito zero tempo nel pensare a come testare il prodotto. Al quinto sprint scrum ci siamo accorti che spendevamo regolarmente 2–3 giorni prima della sprint review in "follia da integrazione", e la situazione peggiorava di sprint in sprint. Il nostro secondo errore è stato non riuscire a uscire dalla feature-frenzy e comunicare chiaramente al product management che dovevamo tornare al tavolo da disegno per rivedere il design lato CI (cfr. la nota sul fidarsi dei team del capitolo precedente). Un anno più tardi ci siamo ritrovati con una CI raffazzonata che si rompeva più spesso di quanto funzionasse, fonte costante di frustrazione per gli sviluppatori. Questa palla di fango era cresciuta a tal punto che, persino con carta bianca sull'investimento per sistemarla, non riuscivamo a metterci d'accordo all'interno del team sul modo migliore di riprogettarla.
Quando si integrano sia CI sia CD nel cuore della propria architettura, succedono due cose:
- Inizierà a chiederSi come fa a sapere che il sistema sta funzionando. Questo La porterà naturalmente a strumentare il codice per ottenere metriche operative.
- Quando dovrà fare il debug dei fallimenti notturni della CI, svilupperà sia le competenze sia gli strumenti (ad es. log adeguati e raccolta di dati di tracing) per analizzare e risolvere problemi già accaduti. Sono esattamente le stesse competenze e tecniche di cui il team avrà bisogno per fare debug di un disservizio in produzione.
Come effetto collaterale, avrà sistemi di logging e monitoring già operativi prima ancora di andare in produzione. Un'avvertenza sui framework di monitoring e logging: il loro costo operativo, sia in modalità SaaS sia roll-your-own, può diventare significativo molto in fretta — raccomando vivamente di stimare i costi potenziali e di tenerne conto nella decisione.
Solo quando avrà consolidato la pratica di CI in modo soddisfacente potrà occasionalmente concedersi il "prima le feature, poi i test". E per "poi" intendo "nello sprint successivo", a meno che non si tratti di una funzionalità usa e getta, una demo che disattiverà tramite feature flag.
Ogni cloud ha i propri servizi nativi di monitoring e logging che possono essere o meno la scelta migliore per Lei. Con K8s la parte CD è in gran parte semplificata, mentre la parte CI richiederà un buon lavoro di ricerca da parte Sua. Ognuno dei tre grandi hyperscaler offre strumenti di CI ma, francamente, non è il loro core business.
4\. Chi lo costruisce, lo gestisce
"You build it — you run it" è scontato nelle piccole aziende, perché semplicemente non esiste una barriera SRE oltre la quale lanciare il codice. La domanda quindi non è a chi appartiene la produzione, ma piuttosto che esperienza si fa nel farsi carico dei workloads di produzione.
Il bello è che, se ha curato i passaggi precedenti, l'ownership della produzione sarà molto naturale per il Suo team. Vediamo perché:
- È partito dalla sicurezza, quindi una separazione perimetrale dovrebbe già essere a posto. Sa dove cercare i problemi; scenari in cui il codice di sviluppo si collega per sbaglio al database di produzione e fa disastri sono semplicemente fuori discussione.
- L'architettura è realistica e tagliata sul team. È chiara e facile da capire. Per esempio, non si tira dietro sistemi distribuiti complessi a meno che non sia indispensabile e non li sappia davvero gestire. Armato dei suoi strumenti di osservabilità, può individuare rapidamente l'origine dei problemi.
- La CI è stabile e affidabile, la CD è fluida. Quando c'è un bug da risolvere, quindi, i processi di test e deploy sono rapidi, semplici e privi di carico cognitivo o stress. Questo riduce al minimo la fatica generata dai bug ed evita di scivolare nella Continuous Maintenance.
Le applicazioni hanno già l'osservabilità integrata, quindi non Le resta che configurare i dashboard di monitoring e impostare gli alert.
Un aspetto meno ovvio dell'ownership della produzione, in particolare per gli sviluppatori, è il costo di esercizio del prodotto. Personalmente credo che gli sviluppatori debbano conoscere i modelli di billing del cloud e quanto consuma il loro software, per i motivi che seguono:
Eviti sorprese in bolletta
Deve comprendere il modello di billing del cloud per progettare correttamente il sistema (bill shock, a qualcuno suona familiare?), sia a livello di architettura applicativa sia di CI/CD. Per chiudere il cerchio, imposti budget e alert di fatturazione.
Conosca il Suo Unit Cost
Per le persone di prodotto e di sales è utile conoscere lo "unit cost". Per esempio, se il Suo prodotto monitora edge device, allora lo "unit cost" è quanto ogni dispositivo monitorato pesa sulla bolletta cloud. Il dato dello unit cost è preziosissimo per costruire modelli di business e togliere ogni congettura dal capacity planning.
Con le metriche applicative già in essere, di solito è facile ricondurre la logica dell'app ai costi tramite un'analisi più approfondita dei dati di fatturazione.
5\. Le persone lavorano per le persone
Adoriamo i nostri bit, i nostri byte e la logica formale, ma alla fine siamo un gruppo di esseri umani che lavorano insieme.
Entriamo nelle startup perché crediamo in qualcosa e ne siamo entusiasti.
Manager, si fidi: i Suoi sviluppatori agiscono con le migliori intenzioni. Metta in discussione le loro idee, ma lasci loro lo spazio per innovare. Presti attenzione ai segnali di passaggio in modalità difensiva: da quel momento ogni feature diventa improvvisamente complicata da implementare e il progetto comincia a stagnare.
Possiamo parlare di cloud e tecnologia tutto il giorno, ma se il lavoro non è piacevole, l'innovazione non durerà.