In che modo il conservatorismo tecnico ci aiuta a scalare più velocemente e meglio

In Intercom, siamo concentrati sul futuro e stiamo facendo passi coraggiosi per arrivarci. Ma quando prendiamo decisioni tecniche, ci piace essere prudenti.

In pratica, essere tecnicamente prudenti sembra riutilizzare le tecnologie e i framework esistenti nel nostro stack o promuovere modelli e soluzioni collaudati. Apprezziamo questa familiarità perché comprendiamo che i problemi importanti da risolvere sono quelli che forniscono valore al cliente o al business.

Invece di valutare nuove tecnologie e dedicare tempo a problemi operativi già risolti che alla fine forniscono scarso valore per il cliente, possiamo concentrarci sul miglioramento del prodotto costruendo, rilasciando e ripetendo le soluzioni.

Questo è il sesto post di una serie che esplora i principi dei nostri prodotti . Qui, Waheed discute il nostro principio di ingegneria "Sii tecnicamente prudente".

Ci sono molti vantaggi a lungo termine per il conservatorismo tecnico

Questo principio è meglio illustrato da alcuni esempi nel corso degli anni, che dimostrano come " Sii tecnicamente prudente" ci consente di scalare velocemente senza essere un vincolo. In precedenza ho parlato della nostra esperienza nella progettazione del nostro sistema di reporting, in cui abbiamo valutato i vantaggi dell'introduzione di un nuovo datastore nel nostro stack: Redshift. Avrebbe significato introdurre nel nostro sistema un nuovo tipo di database che non era mai stato testato rispetto alla produzione. Inoltre, avremmo dovuto dedicare molto tempo all'acquisizione di conoscenze operative, al mantenimento dei cluster in produzione e alla gestione di problemi imprevisti derivanti dall'utilizzo di Redshift su larga scala.

" Abbiamo sfruttato la nostra infrastruttura esistente per accelerare il processo da circa sei mesi a sole sei settimane"

Alla fine, abbiamo deciso che un datastore familiare fosse più adatto al lavoro. Abbiamo sfruttato la nostra infrastruttura Elasticsearch esistente, che alimenta la maggior parte delle capacità di ricerca di Intercom, per accelerare il processo da circa sei mesi a sole sei settimane.

La versione iniziale del sistema di reporting è stata rilasciata alcuni anni fa, quindi abbiamo avuto l'opportunità di riflettere su alcuni dei vantaggi a lungo termine della nostra applicazione del conservatorismo tecnico in quel caso:

Abbiamo risolto il problema del cliente più velocemente

Utilizzando la nostra infrastruttura esistente abbiamo evitato di perdere tempo a familiarizzare con un nuovo datastore e ad affrontare tutti gli inevitabili intoppi. Siamo stati in grado di concentrarci immediatamente sul problema del cliente da risolvere e spedire velocemente, riducendo i tempi di consegna di oltre quattro mesi.

Abbiamo sfruttato al meglio il tempo della squadra

Il nostro team di Data Infrastructure è stato in grado di continuare a concentrarsi su un piccolo insieme familiare di tecnologie invece di essere distribuito su più tecnologie. Di conseguenza, hanno avuto, e hanno ancora, più tempo per garantire la salute dei nostri sistemi esistenti e ottimizzare il nostro uso di ciascuna tecnologia.

" Poiché il nostro insieme di tecnologie è relativamente piccolo, i miglioramenti si verificano regolarmente"

Abbiamo aumentato il valore dei miglioramenti continui

Poiché il nostro insieme di tecnologie è relativamente piccolo, i miglioramenti si verificano regolarmente. Il prodotto sfrutta queste tecnologie e quindi l'impatto di tali miglioramenti è aggravato da tutto ciò che si basa su di esse. Un piccolo miglioramento può avere un effetto a catena enorme e positivo sull'intero prodotto.

Più squadre hanno avuto più input

L'utilizzo di tecnologie comuni significa che più ingegneri e team si sentono sicuri e autorizzati a lavorare con loro. Abbiamo riscontrato frequenti miglioramenti al prodotto di reporting da parte dei team di tutta l'azienda piuttosto che da un solo team che possiede una parte particolare del sistema.

Ricorda che i principi non sono regole, sono linee guida

I principi sono un modo incredibile per allineare i team e hanno prodotto ottimi risultati per Intercom. Ma ci sono momenti in cui potrebbe avere più senso non seguirli. Man mano che un'azienda cresce, c'è il rischio che alcuni membri del team seguano i principi dogmaticamente o li interpretino in modo errato. Inadempiere al conservatorismo tecnico non dovrebbe significare che non introduciamo mai qualcosa di nuovo.

"Conservatorismo tecnico significa favorire una tecnologia che è già nel tuo stack, ma solo se è l'opzione migliore"

Conservazione tecnica significa favorire una tecnologia che è già nel tuo stack, ma solo se è l'opzione migliore. In alcune situazioni una tecnologia esistente potrebbe non essere adatta. Se non può rispondere alle seguenti domande, potremmo guardare oltre e valutare alternative:

• Il nuovo strumento consente alla tua azienda di scalare in modo più efficace?
• Consente al tuo team o alla tua organizzazione di muoversi più velocemente e fornire valore più rapidamente?
• Risolve un problema del cliente che non può essere risolto con i tuoi strumenti esistenti?

Se rispondi "sì" a uno qualsiasi di questi, potrebbe valere la pena considerare l'introduzione di quel nuovo strumento. In Intercom, c'è stato un esempio recente che ha risposto "sì" a tutte e tre le domande.

Gli utenti, oi clienti dei nostri clienti, sono il fulcro della piattaforma Intercom. Man mano che siamo cresciuti, sono cresciuti anche i nostri clienti e le loro esigenze in termini di quanti dati utente archiviano all'interno di Intercom. La grande quantità di dati utente stava causando problemi di scalabilità con il nostro attuale archivio dati utente in quel momento e, per garantire che potessimo continuare a supportare i clienti esistenti e nuovi, dovevamo ripensare la nostra soluzione attuale. Questo alla fine ci ha portato a introdurre una nuova tecnologia nel nostro stack: ecco come siamo arrivati ​​a questa decisione.

Stavamo scalando più velocemente di quanto consentisse il nostro datastore

Abbiamo utilizzato MongoDB per circa cinque anni e abbiamo avuto le cicatrici operative per dimostrarlo. Abbiamo ottimizzato ogni aspetto del possesso e dell'esecuzione, dal tipo di hardware su cui è stato eseguito, alle query che abbiamo eseguito su di esso. Eravamo sul punto di diminuire i rendimenti e stavamo vedendo forti segnali che avrebbe smesso di essere idoneo allo scopo entro un paio d'anni e che avrebbe potuto persino diventare un collo di bottiglia nella crescita dell'azienda.

“Pensa regolarmente alla traiettoria della tua attività e chiedi ' Ciò che ci ha portato qui, ci porterà lì? '. Questo ti permetterà di essere proattivo sulle tue scelte piuttosto che reattivo”

È qui che è fondamentale disporre di una strategia tecnica forte e lungimirante. A questo punto avevamo dati sufficienti per suggerire che avremmo potuto dover valutare un altro approccio e avere la pista per farlo. Pensa regolarmente alla traiettoria della tua attività e chiedi "Ciò che ci ha portato qui, ci porterà lì?". Ciò ti consentirà di essere proattivo sulle tue scelte piuttosto che reattivo e mitiga i rischi legati alle incognite sconosciute dell'introduzione di una nuova tecnologia.

La nostra tecnologia stava rallentando il nostro team

In Intercom ci sforziamo di eseguire meno software. In questo caso, anche se stavamo adottando una nuova tecnologia con incognite sconosciute, l'adozione di DynamoDB ci ha permesso di fare proprio questo.

In precedenza, gestivamo autonomamente il ridimensionamento di MongoDB insieme al codice per il bilanciamento del carico, un sovraccarico significativo per il team. Parte del vantaggio di DynamoDB era che era gestito dal fornitore, AWS. Ciò significava che, sebbene ci fosse un costo iniziale per adottarlo, alla fine sarebbe stato più economico e avrebbe fatto risparmiare al team un'enorme quantità di tempo e fatica.

"Non essere dogmatici riguardo al conservatorismo tecnico ci ha permesso di sostituire una tecnologia con grandi spese generali e capacità limitate"

Può sembrare controintuitivo, ma l'introduzione di una nuova tecnologia alla fine ci ha portato a eseguire meno software. Non essere dogmatici riguardo al conservatorismo tecnico ci ha permesso di sostituire una tecnologia con grandi spese generali e capacità limitate con una nuova tecnologia che era meno onerosa dal punto di vista operativo e più scalabile.

Siamo stati spietati riguardo ai requisiti

A volte avremmo richiesto a MongoDB di eseguire query complesse e costose che mettevano a rischio la disponibilità e le prestazioni di query più comuni ma meno complesse. Durante la valutazione di DynamoDB ci siamo resi conto che non avrebbe supportato quelle query complesse e costose, ma sarebbe stato molto meglio con quelle più semplici e comuni.

Abbiamo già utilizzato principalmente Elasticsearch per eseguire query complesse e la necessità di migrare ci ha costretto a rivedere e definire in modo più deliberato le funzionalità che richiedevamo dal nostro user store e, in definitiva, ci ha permesso di migliorare le prestazioni per il suo caso d'uso principale: recuperare i record di un singolo utente.

“Quando pensi di sostituire una tecnologia, non dare per scontato che utilizzerai la nuova tecnologia allo stesso modo”

Quando pensi di sostituire una tecnologia, non dare per scontato che utilizzerai la nuova tecnologia allo stesso modo. È probabile che i tuoi requisiti siano cambiati considerevolmente nel tempo e il resto dello stack si sarà evoluto o maturato in modo che i casi d'uso diventino più ristretti. Ciò aprirà opportunità per adottare tecnologie più mirate e performanti o scaricare alcune tecnologie per essere gestite da un fornitore.

Fai in modo che i tuoi principi funzionino per il tuo business, non il contrario

Il conservatorismo tecnico è un ottimo strumento per consentire ai tuoi team di rimanere concentrati su ciò che è importante: risolvere i problemi dei clienti e fornire valore senza spendere risorse preziose per rispondere a domande a cui è già stata data risposta.

Tuttavia, diventare troppo rigidi nella convinzione che l'introduzione di nuove tecnologie sia un male potrebbe impedirti di sfruttare le tecnologie che ti aiuteranno a eseguire meno software e scalare più facilmente e rapidamente. È importante applicare questo principio in un modo che funzioni al meglio per il tuo team e per la tua azienda a lungo termine.

Sei interessato a entrare a far parte del team di ingegneri di Intercom? Scopri di più e guarda i nostri ruoli aperti qui.