Scelta di una nuova tecnologia di database serverless presso un'agenzia (caso di studio)

Questo articolo è stato gentilmente supportato dai nostri cari amici di Fauna che rendono il lavoro con i dati operativi produttivo, scalabile e sicuro per ogni team di sviluppo software. Grazie!

L'adozione di una nuova tecnologia è una delle decisioni più difficili per un tecnologo in un ruolo di leadership. Questa è spesso un'area di rischio ampia e scomoda, sia che tu stia creando software per un'altra organizzazione o all'interno della tua.

Negli ultimi dodici anni come ingegnere del software, mi sono trovato nella posizione di dover valutare una nuova tecnologia con frequenza sempre maggiore. Questo potrebbe essere il prossimo framework frontend, un nuovo linguaggio o anche architetture completamente nuove come serverless.

La fase di sperimentazione è spesso divertente ed emozionante. È qui che gli ingegneri del software sono più a loro agio, abbracciando la novità e l'euforia dei momenti "aha" mentre grokking nuovi concetti. Come ingegneri, ci piace pensare e armeggiare, ma con sufficiente esperienza, ogni ingegnere impara che anche la tecnologia più incredibile ha i suoi difetti. Semplicemente non li hai ancora trovati.

Ora, come co-fondatore di un'agenzia creativa, io e il mio team siamo spesso in una posizione unica per utilizzare le nuove tecnologie. Vediamo molti progetti greenfield, che diventano l'occasione perfetta per introdurre qualcosa di nuovo. Questi progetti vedono anche un livello di isolamento tecnico dall'organizzazione più ampia e sono spesso meno gravati da decisioni precedenti.

Detto questo, a una buona guida di agenzia viene affidato il compito di prendersi cura della grande idea di qualcun altro e di consegnarla al mondo. Dobbiamo trattarlo con ancora più cura di quanto faremmo con i nostri stessi progetti. Ogni volta che sto per fare l'ultima chiamata su una nuova tecnologia, rifletto spesso su questa saggezza del co-fondatore Stack Overflow Joel Spolski:

"Devi sudare e sanguinare con la cosa per un anno o due prima di sapere davvero che è abbastanza buono o rendersi conto che non importa quanto ci provi non puoi..."

Questa è la paura, questo è il posto in cui nessun leader tecnologico vuole trovarsi. Scegliere una nuova tecnologia per un progetto nel mondo reale è già abbastanza difficile, ma come agenzia, devi prendere queste decisioni con il progetto di qualcun altro, qualcuno il sogno di qualcun altro, i soldi di qualcun altro. In un'agenzia, l'ultima cosa che vuoi è trovare una di quelle imperfezioni vicino alla scadenza di un progetto. Tempistiche e budget ridotti rendono quasi impossibile invertire la rotta dopo aver superato una certa soglia, quindi scoprire che una tecnologia non può fare qualcosa di critico o è inaffidabile troppo tardi in un progetto può essere catastrofico.

Durante la mia carriera come ingegnere del software, ho lavorato presso aziende SaaS e agenzie creative. Quando si tratta di adottare una nuova tecnologia per un progetto, questi due ambienti hanno criteri molto diversi. C'è una sovrapposizione nei criteri, ma in generale, l'ambiente dell'agenzia deve lavorare con budget rigidi e vincoli di tempo rigorosi . Anche se vogliamo che i prodotti che costruiamo invecchino bene nel tempo, spesso è più difficile investire in qualcosa di meno collaudato o adottare una tecnologia con curve di apprendimento più ripide e spigoli vivi.

Detto questo, le agenzie hanno anche alcuni vincoli unici che una singola organizzazione potrebbe non avere. Dobbiamo tendere all'efficienza e alla stabilità. L'ora fatturabile è spesso l'unità di misura finale quando un progetto è completo. Sono stato in aziende SaaS dove passare un giorno o due per l'installazione o una pipeline di costruzione non è un grosso problema.

In un'agenzia, questo tipo di costo del tempo mette a dura prova le relazioni poiché i team finanziari vedono restringere i margini di profitto per risultati poco visibili. Dobbiamo anche considerare il mantenimento a lungo termine di un progetto e, al contrario, cosa succede se un progetto deve essere restituito al cliente. Pertanto, dobbiamo tendere all'efficienza, alla curva di apprendimento e alla stabilità nella tecnologia che scegliamo.

Quando valuto un nuovo pezzo di tecnologia, guardo a tre aree generali:

1. La tecnologia
2. L'esperienza dello sviluppatore
3. L'attività

Ognuna di queste aree ha una serie di criteri che mi piace soddisfare prima di iniziare a immergermi davvero nel codice e sperimentare. In questo articolo, daremo un'occhiata a questi criteri e useremo l'esempio di considerare un nuovo database per un progetto e rivederlo ad alto livello sotto ciascuna lente. Prendere una decisione tangibile come questa aiuterà a dimostrare come possiamo applicare questo quadro nel mondo reale.

La tecnologia

La prima cosa da considerare quando si valuta una nuova tecnologia è se quella soluzione può risolvere i problemi che afferma di risolvere. Prima di approfondire come una tecnologia può aiutare i nostri processi e le nostre operazioni aziendali, è importante stabilire che soddisfi i nostri requisiti funzionali . Questo è anche il punto in cui mi piace dare un'occhiata a quali soluzioni esistenti stiamo utilizzando e come questa nuova si confronta con loro.

Mi pongo domande del tipo:

1. Risolve almeno il problema della mia soluzione esistente?
2. In che modo questa soluzione è migliore?
3. In che modo è peggio?
4. Per le aree in cui è peggio, cosa ci vorrà per superare queste carenze?
5. Prenderà il posto di più strumenti?
6. Quanto è stabile la tecnologia?

Il nostro perché?

A questo punto, voglio anche esaminare il motivo per cui stiamo cercando un'altra soluzione. Una risposta semplice è che stiamo incontrando un problema che le soluzioni esistenti non risolvono . Tuttavia, questo è spesso raramente il caso. Abbiamo risolto molti problemi software nel corso degli anni con tutta la tecnologia di cui disponiamo oggi. Quello che succede in genere è che veniamo trasformati in una nuova tecnologia che rende qualcosa che stiamo facendo attualmente più facile, più stabile, più veloce o più economico.

Prendiamo React come esempio. Perché abbiamo deciso di adottare React quando jQuery o Vanilla JavaScript stavano facendo il lavoro? In questo caso, l'utilizzo del framework ha evidenziato come questo fosse un modo molto migliore per gestire i frontend con stato. È diventato più veloce per noi creare cose come funzioni di filtraggio e ordinamento lavorando con strutture di dati invece che con la manipolazione diretta del DOM. Questo è stato un risparmio di tempo e una maggiore stabilità delle nostre soluzioni.

Typescript è un altro esempio in cui abbiamo deciso di adottarlo perché abbiamo riscontrato aumenti nella stabilità del nostro codice e nella manutenibilità. Con l'adozione di nuove tecnologie, spesso non c'è un problema chiaro che stiamo cercando di risolvere, ma piuttosto semplicemente cercare di rimanere aggiornati e quindi scoprire soluzioni più efficienti e stabili di quelle che stiamo attualmente utilizzando.

Nel caso di un database, stavamo specificamente considerando di passare a un'opzione serverless . Abbiamo riscontrato molto successo con applicazioni e distribuzioni serverless che hanno ridotto il nostro sovraccarico come organizzazione. Un'area in cui sentivamo che ciò mancava era il nostro livello di dati. Abbiamo visto servizi come Amazon Aurora, Fauna, Cosmos e Firebase che applicavano i principi serverless ai database e volevamo vedere se era il momento di fare il salto da soli. In questo caso, stavamo cercando di ridurre il nostro sovraccarico operativo e aumentare la nostra velocità ed efficienza di sviluppo.

A questo livello è importante capire il tuo perché prima di iniziare a tuffarti in nuove offerte. Questo può essere dovuto al fatto che stai risolvendo un nuovo problema, ma molto più spesso stai cercando di migliorare la tua capacità di risolvere un tipo di problema che stai già risolvendo. In tal caso, devi fare un inventario di dove sei stato per capire cosa fornirebbe un miglioramento significativo al tuo flusso di lavoro. Basandosi sul nostro esempio di analisi dei database serverless, dovremo dare un'occhiata a come stiamo attualmente risolvendo i problemi e dove tali soluzioni non sono all'altezza.

Dove siamo stati...

In qualità di agenzia, in precedenza abbiamo utilizzato un'ampia gamma di database inclusi, a titolo esemplificativo, MySQL, PostgreSQL, MongoDB, DynamoDB, BigQuery e Firebase Cloud Storage. La stragrande maggioranza del nostro lavoro era incentrata su tre database principali: PostgreSQL, MongoDB e Firebase Realtime Database. Ognuno di questi, in effetti, ha offerte semi-serverless, ma alcune caratteristiche chiave delle offerte più recenti ci hanno fatto rivalutare le nostre ipotesi precedenti. Diamo prima un'occhiata alla nostra esperienza storica con ciascuno di questi e perché in primo luogo stiamo considerando le alternative.

In genere abbiamo scelto PostgreSQL per progetti più grandi e a lungo termine, poiché questo è il gold standard testato per quasi tutto. Supporta transazioni classiche, dati normalizzati ed è conforme ad ACID. Sono disponibili numerosi strumenti e ORM in quasi tutte le lingue e può anche essere utilizzato come database NoSQL ad hoc con il supporto della colonna JSON. Si integra bene con molti framework, librerie e linguaggi di programmazione esistenti, rendendolo un vero cavallo di battaglia ovunque. È anche open-source e quindi non ci blocca in nessun fornitore. Come si suol dire, nessuno è mai stato licenziato per aver scelto Postgres.

Detto questo, ci siamo gradualmente trovati a usare PostgreSQL sempre meno man mano che siamo diventati più un negozio orientato ai nodi. Abbiamo riscontrato che gli ORM per Node sono poco brillanti e richiedono più query personalizzate (sebbene ora questo sia diventato meno problematico) e NoSQL si è ritenuto più naturale quando si lavora in un runtime JavaScript o TypeScript. Detto questo, spesso avevamo progetti che potevano essere realizzati abbastanza rapidamente con la classica modellazione relazionale come i flussi di lavoro dell'e-commerce. Tuttavia, la gestione della configurazione locale del database, l'unificazione del flusso di test tra i team e la gestione delle migrazioni locali erano cose che non amavamo e che eravamo felici di abbandonare quando i database NoSQL basati su cloud sono diventati più popolari.

MongoDB è stato sempre più il nostro database di riferimento poiché abbiamo adottato Node.js come il nostro back-end preferito. Lavorare con MongoDB Atlas ha semplificato lo sviluppo e il test rapidi dei database che il nostro team poteva utilizzare. Per un po', MongoDB non è stato conforme ad ACID, non supportava le transazioni e scoraggiava troppe operazioni di tipo inner join, quindi per le applicazioni di e-commerce stavamo ancora usando Postgres più spesso. Detto questo, ci sono molte librerie che lo accompagnano e il linguaggio di query di Mongo e il supporto JSON di prima classe ci hanno dato velocità ed efficienza che non avevamo sperimentato con i database relazionali. MongoDB ha recentemente aggiunto il supporto per le transazioni ACID, ma per molto tempo questo è stato il motivo principale per cui abbiamo optato invece per Postgres.

MongoDB ci ha anche introdotto un nuovo livello di flessibilità. Nel bel mezzo di un progetto di agenzia, i requisiti sono destinati a cambiare. Non importa quanto duramente ti difendi, c'è sempre un requisito di dati dell'ultimo minuto . Con i database NoSQL, in generale, la flessibilità della struttura dei dati ha reso questi tipi di modifiche meno difficili. Non ci siamo ritrovati con una cartella piena di file di migrazione per gestire le colonne aggiunte, rimosse e aggiunte di nuovo prima ancora che un progetto vedesse la luce del giorno.

Come servizio, Mongo Atlas era anche abbastanza vicino a ciò che desideravamo in un servizio cloud di database. Mi piace pensare ad Atlas come a un'offerta semi -serverless poiché hai ancora un sovraccarico operativo nella sua gestione. È necessario eseguire il provisioning di un database di determinate dimensioni e selezionare una quantità di memoria in anticipo. Queste cose non verranno ridimensionate automaticamente per te, quindi dovrai monitorarlo per quando è il momento di fornire più spazio o memoria. In un database veramente serverless, tutto ciò avverrebbe automaticamente e su richiesta.

Abbiamo anche utilizzato Firebase Realtime Database per alcuni progetti. Si trattava infatti di un'offerta serverless in cui il database aumentava e diminuiva su richiesta e, con prezzi con pagamento in base al consumo , aveva senso per applicazioni in cui la scala non era nota in anticipo e il budget era limitato. Abbiamo usato questo al posto di MongoDB per progetti di breve durata che avevano semplici requisiti di dati.

Una cosa che non ci è piaciuta di Firebase è stata la sensazione di essere più lontani dal tipico modello relazionale costruito attorno a dati normalizzati a cui eravamo abituati. Mantenere piatte le strutture dei dati significava spesso avere più duplicazioni, che potevano diventare un po' brutte man mano che un progetto cresceva. Si finisce per dover aggiornare gli stessi dati in più punti o provare a unire riferimenti diversi risultando in più query che possono diventare difficili da ragionare nel codice. Sebbene ci piacesse Firebase, non ci siamo mai veramente innamorati del linguaggio di query e talvolta abbiamo trovato la documentazione poco brillante.

In generale, sia MongoDB che Firebase si concentravano in modo simile sui dati denormalizzati e, senza l'accesso a transazioni efficienti, abbiamo spesso riscontrato molti dei flussi di lavoro facili da modellare nei database relazionali, il che ha portato a codice più complesso a livello di applicazione con i relativi Controparti NoSQL. Se potessimo ottenere la flessibilità e la facilità di queste offerte NoSQL con la robustezza e la modellazione relazionale di un database SQL tradizionale, avremmo davvero trovato un'ottima corrispondenza. Ritenevamo che MongoDB avesse l'API e le capacità migliori, ma Firebase aveva il modello veramente serverless operativamente.

Il nostro ideale

A questo punto, possiamo iniziare a guardare quali nuove opzioni prenderemo in considerazione. Abbiamo definito chiaramente le nostre soluzioni precedenti e abbiamo identificato le cose che per noi sono importanti come minimo nella nostra nuova soluzione. Non solo abbiamo una linea di base o un insieme minimo di requisiti, ma abbiamo anche una serie di problemi che vorremmo che la nuova soluzione risolvesse per noi. Ecco i requisiti tecnici che abbiamo:

1. Serverless operativamente con scalabilità on demand
2. Modellazione flessibile (senza schema)
3. Nessuna dipendenza da migrazioni o ORM
4. Transazioni conformi agli ACID
5. Supporta relazioni e dati normalizzati
6. Funziona sia con backend serverless che tradizionali

Quindi ora che abbiamo un elenco di must-have possiamo effettivamente valutare alcune opzioni. Potrebbe non essere importante che la nuova soluzione raggiunga tutti gli obiettivi qui. Può darsi che raggiunga la giusta combinazione di funzionalità in cui le soluzioni esistenti non si sovrappongono. Ad esempio, se volevi flessibilità senza schema , dovevi rinunciare alle transazioni ACID. (Questo è stato il caso per molto tempo con i database.)

Un esempio da un altro dominio è se si desidera avere la convalida del dattiloscritto nel rendering del modello è necessario utilizzare TSX e React. Se scegli opzioni come Svelte o Vue, puoi averlo, parzialmente ma non completamente, attraverso il rendering del modello . Quindi una soluzione che ti desse l'ingombro ridotto e la velocità di Svelte con il controllo del tipo a livello di modello di React e TypeScript potrebbe essere sufficiente per l'adozione anche se mancasse un'altra funzionalità. L'equilibrio tra desideri e bisogni cambierà da progetto a progetto. Sta a te capire dove sarà il valore e decidere come spuntare i punti più importanti nella tua analisi.

Ora possiamo dare un'occhiata a una soluzione e vedere come viene valutata rispetto alla nostra soluzione desiderata. Fauna è una soluzione di database serverless che vanta una scala on-demand con distribuzione globale. È un database senza schema, che fornisce transazioni compatibili con ACID e supporta query relazionali e dati normalizzati come funzionalità. Fauna può essere utilizzato sia in applicazioni serverless che in backend più tradizionali e fornisce librerie per lavorare con i linguaggi più diffusi. Fauna fornisce inoltre flussi di lavoro per l'autenticazione e una multi-tenancy semplice ed efficiente. Queste sono entrambe solide caratteristiche aggiuntive da notare perché potrebbero essere i fattori di influenza quando due tecnologie sono faccia a faccia nella nostra valutazione.

Ora, dopo aver esaminato tutti questi punti di forza, dobbiamo valutare i punti deboli . Uno dei quali è Fauna non è open source. Ciò significa che esistono rischi di vincolo del fornitore o modifiche aziendali e dei prezzi che sono fuori dal tuo controllo. L'open source può essere utile perché spesso puoi aggiornare e portare la tecnologia a un altro fornitore se lo desideri o potenzialmente contribuisci al progetto.

Nel mondo delle agenzie, il vendor lock-in è qualcosa che dobbiamo guardare da vicino, non tanto per il prezzo, ma per la redditività dell'attività sottostante è importante. Dover cambiare i database su un progetto che è in via di sviluppo o che ha pochi anni è entrambi disastrosi per un'agenzia. Spesso un cliente dovrà pagare il conto per questo, che non è una conversazione piacevole da avere.

Un'altra debolezza di cui eravamo preoccupati è l'attenzione su JAMstack . Sebbene amiamo JAMstack, ci troviamo a creare più spesso un'ampia varietà di applicazioni Web tradizionali. Vogliamo essere sicuri che Fauna continui a supportare questi casi d'uso. Abbiamo avuto una brutta esperienza in passato con un provider di hosting che è andato all-in su JAMstack e alla fine abbiamo dovuto migrare una parte piuttosto ampia di siti dal servizio, quindi vogliamo essere certi che tutti i casi d'uso continueranno a vedere supporto solido. In questo momento, sembra essere così e i flussi di lavoro serverless forniti da Fauna possono effettivamente integrare abbastanza bene un'applicazione più tradizionale.

A questo punto, abbiamo fatto la nostra ricerca funzionale e l'unico modo per sapere se questa soluzione è praticabile è scendere e scrivere del codice. In un ambiente di agenzia, non possiamo semplicemente sottrarre settimane al programma affinché le persone valutino più soluzioni. Questa è la natura del lavoro in un'agenzia rispetto a un ambiente SaaS . In quest'ultimo, potresti costruire alcuni prototipi per cercare di arrivare alla soluzione giusta. In un'agenzia avrai qualche giorno per sperimentare, o forse l'opportunità di fare un progetto parallelo, ma in generale dobbiamo davvero restringere questo a una o due tecnologie in questa fase e poi mettere le dita sulla tastiera.

L'esperienza dello sviluppatore

Giudicare il lato esperienziale di una nuova tecnologia è forse la più difficile delle tre aree poiché è per natura soggettiva. Avrà anche variabilità da squadra a squadra. Ad esempio, se hai chiesto a un programmatore Ruby, un programmatore Python e un programmatore Rust le loro opinioni sulle diverse funzionalità del linguaggio, otterrai una serie di risposte. Quindi, prima di iniziare a giudicare un'esperienza, devi prima decidere quali caratteristiche sono più importanti per la tua squadra in generale.

Per le agenzie penso che ci siano due colli di bottiglia principali che emergono per quanto riguarda l'esperienza degli sviluppatori:

1. Tempo di installazione e configurazione
2. Apprendibilità

Entrambi influenzano la fattibilità a lungo termine di una nuova tecnologia in modi diversi. Mantenere sincronizzati i team temporanei di sviluppatori in un'agenzia può essere un mal di testa. Gli strumenti che hanno molti costi di installazione e configurazioni iniziali sono notoriamente difficili con cui lavorare per le agenzie. L'altro è la capacità di apprendimento e quanto sia facile per gli sviluppatori far crescere la nuova tecnologia. Analizzeremo questi in modo più dettagliato e perché sono la mia base per iniziare a valutare l'esperienza degli sviluppatori.

Tempo di installazione e configurazione

Le agenzie tendono ad avere poca pazienza e poco tempo per la configurazione. Per me, amo gli strumenti affilati, con design ergonomico, che mi consentono di lavorare rapidamente sul problema aziendale. Alcuni anni fa ho lavorato per un'azienda SaaS che aveva una configurazione locale complessa che prevedeva molte configurazioni e spesso falliva in momenti casuali nel processo di installazione. Una volta impostato, la saggezza convenzionale era di non toccare nulla e sperare di non essere stati in azienda abbastanza a lungo da doverlo riconfigurare su un'altra macchina. Ho incontrato sviluppatori che si sono divertiti molto a configurare ogni piccolo pezzo della loro configurazione di emacs e non hanno pensato a perdere qualche ora a causa di un ambiente locale danneggiato.

In generale, ho scoperto che gli ingegneri delle agenzie disprezzano questo tipo di cose nel loro lavoro quotidiano. Mentre sono a casa possono armeggiare con questi tipi di strumenti, ma quando sono in scadenza non c'è niente come strumenti che funzionano e basta. Nelle agenzie, in genere preferiremmo imparare alcune cose nuove che funzionano bene, in modo coerente, piuttosto che essere in grado di configurare ogni pezzo tecnologico secondo il gusto personale di ogni individuo.

Una cosa positiva nel lavorare con una piattaforma cloud che non è open source è che possiedono interamente l'installazione e la configurazione. Mentre uno svantaggio di questo è il blocco del fornitore, il lato positivo è che questi tipi di strumenti spesso fanno ciò per cui sono impostati per fare bene. Non c'è alcun armeggiare con gli ambienti, nessuna configurazione locale e nessuna pipeline di distribuzione. Abbiamo anche meno decisioni da prendere.

Questo è intrinsecamente il fascino del serverless . Il serverless in generale fa maggiore affidamento su servizi e strumenti proprietari. Scambiamo la flessibilità dell'hosting e del codice sorgente in modo da poter ottenere una maggiore stabilità e concentrarci sui problemi del dominio aziendale che stiamo cercando di risolvere. Noterò anche che quando sto valutando una tecnologia e ho la sensazione che potrebbe essere necessaria la migrazione da una piattaforma, questo è spesso un brutto segno all'inizio.

Nel caso dei database, l'impostazione set-it-and-forget-it è l'ideale quando si lavora con client in cui le esigenze del database possono essere ambigue. Abbiamo avuto clienti che non erano sicuri di quanto sarebbe stato popolare un programma o un'applicazione. Abbiamo avuto clienti che tecnicamente non avevamo un contratto per supportare in questo modo, ma ci hanno comunque chiamato in preda al panico quando avevano bisogno di noi per ridimensionare il loro database o applicazione.

In passato, dovevamo sempre tenere conto di cose come la ridondanza, la replica dei dati e lo sharding per ridimensionare quando abbiamo realizzato i nostri SOW. Cercare di coprire ogni scenario e allo stesso tempo essere pronti a spostare un intero libro di attività nel caso in cui un database non si stesse ridimensionando è una situazione impossibile a cui prepararsi. Alla fine, un database serverless rende queste cose più facili.

Non perdi mai dati , non devi preoccuparti di replicare i dati su una rete, né di eseguire il provisioning di un database e di una macchina più grandi su cui eseguirli: tutto funziona. Ci concentriamo solo sul problema aziendale in questione, l'architettura tecnica e la scala saranno sempre gestite. Per il nostro team di sviluppo, questa è una grande vittoria; abbiamo meno esercitazioni antincendio, monitoraggio e cambio di contesto.

Apprendibilità

C'è una classica misura dell'esperienza dell'utente, che penso sia applicabile all'esperienza degli sviluppatori, che è l'apprendimento . Quando progettiamo per una determinata esperienza utente non guardiamo solo se qualcosa è evidente o facile al primo tentativo. La tecnologia ha solo più complessità di quella la maggior parte delle volte. Ciò che è importante è la facilità con cui un nuovo utente può apprendere e padroneggiare il sistema.

Quando si tratta di strumenti tecnici, soprattutto potenti, sarebbe molto chiedere che ci sia una curva di apprendimento pari a zero . Di solito quello che cerchiamo è che ci sia un'ottima documentazione per i casi d'uso più comuni e che tale conoscenza possa essere costruita facilmente e rapidamente durante un progetto. Perdere un po' di tempo per imparare il primo progetto con una tecnologia va bene. Dopodiché, dovremmo vedere un miglioramento dell'efficienza con ogni progetto successivo.

Quello che cerco in particolare qui è come possiamo sfruttare le conoscenze e i modelli che già conosciamo per aiutare ad abbreviare la curva di apprendimento. Ad esempio, con i database serverless, ci sarà una curva di apprendimento praticamente nulla per configurarli nel cloud e distribuirli. Quando si tratta di utilizzare il database, una delle cose che mi piace è quando possiamo ancora sfruttare tutti gli anni di padronanza dei database relazionali e applicare queste conoscenze alla nostra nuova configurazione. In questo caso, stiamo imparando a utilizzare un nuovo strumento, ma non ci obbliga a ripensare la modellazione dei dati da zero.

Ad esempio, quando si utilizza Firebase, MongoDB e DynamoDB abbiamo scoperto che incoraggiava la denormalizzazione dei dati piuttosto che provare a unire documenti diversi. Ciò ha creato molti attriti cognitivi durante la modellazione dei nostri dati poiché dovevamo pensare in termini di modelli di accesso piuttosto che di entità aziendali. D'altra parte, questa Fauna ci ha permesso di sfruttare i nostri anni di conoscenza relazionale e la nostra preferenza per i dati normalizzati quando si trattava di modellare i dati.

La parte a cui dovevamo abituarci era usare gli indici e un nuovo linguaggio di query per mettere insieme quei pezzi. In generale, ho scoperto che preservare i concetti che fanno parte di paradigmi di progettazione software più ampi rende più facile il team di sviluppo in termini di apprendibilità e adozione.

Come facciamo a sapere che un team sta adottando e amando una nuova tecnologia? Penso che il miglior segno sia quando ci troviamo a chiederci se quello strumento si integra con la suddetta nuova tecnologia? Quando una nuova tecnologia raggiunge un livello di desiderabilità e divertimento tale che il team è alla ricerca di modi per incorporarla in più progetti, è un buon segno che hai un vincitore.

L'attività

In questa sezione, dobbiamo esaminare in che modo una nuova tecnologia soddisfa le nostre esigenze aziendali . Questi includono domande come:

• Quanto facilmente può essere prezzato e integrato nei nostri piani di supporto?
• Possiamo trasferirlo facilmente ai clienti?
• I clienti possono essere inseriti in questo strumento, se necessario?
• Quanto tempo fa effettivamente risparmiare questo strumento, se del caso?

L'ascesa del serverless come paradigma si adatta bene alle agenzie. Quando si parla di database e DevOps, la necessità di specialisti in queste aree presso le agenzie è limitata. Spesso stiamo consegnando un progetto quando abbiamo finito o lo supportiamo in una capacità limitata a lungo termine. Tendiamo a preferire gli ingegneri full-stack poiché queste esigenze superano di gran lunga le esigenze di DevOps. Se assumessimo un ingegnere DevOps, probabilmente trascorrerebbero alcune ore a distribuire un progetto e molte più ore in attesa di un incendio.

A questo proposito, abbiamo sempre alcuni appaltatori DevOps pronti, ma non disponiamo di personale per queste posizioni a tempo pieno. Ciò significa che non possiamo fare affidamento su un ingegnere DevOps per essere pronti a saltare per un problema imprevisto. Per noi sappiamo che possiamo ottenere tariffe migliori sull'hosting andando direttamente su AWS, ma sappiamo anche che utilizzando Heroku possiamo fare affidamento sul nostro personale esistente per il debug della maggior parte dei problemi. A meno che non abbiamo un cliente che dobbiamo supportare a lungo termine con specifiche esigenze di back-end, ci piace impostare come servizio predefinito le piattaforme gestite.

I database non fanno eccezione. Ci piace affidarci a servizi come Mongo Atlas o Heroku Postgres per rendere questo processo il più semplice possibile. Quando abbiamo iniziato a vedere sempre più stack del nostro stack in strumenti serverless come Vercel, Netlify o AWS Lambda, le nostre esigenze di database hanno dovuto evolversi di conseguenza. I database serverless come Firebase, DynamoDB e Fauna sono ottimi perché si integrano bene con le app serverless ma liberano completamente la nostra azienda dal provisioning e dal ridimensionamento.

Queste soluzioni funzionano bene anche per le applicazioni più tradizionali, dove non abbiamo un'applicazione serverless ma possiamo comunque sfruttare l'efficienza serverless a livello di database. Come azienda, è più produttivo per noi apprendere un singolo database che può essere applicato a entrambi i mondi piuttosto che al cambio di contesto. Questo è simile alla nostra decisione di adottare Node e JavaScript isomorfo (e TypeScript).

Uno degli aspetti negativi che abbiamo riscontrato con il serverless è stato il prezzo per i clienti per cui gestiamo questi servizi. In un'architettura più tradizionale, i livelli forfettari rendono molto facile tradurli in una tariffa per i clienti con circostanze prevedibili che incorrono in aumenti e eccedenze. Quando si tratta di serverless, questo può essere ambiguo. Alla gente della finanza in genere non piace sentire cose come se addebitiamo 1/10 di centesimo per ogni lettura oltre 1 milione, e così via.

Questo è difficile da tradurre in un numero fisso anche per gli ingegneri, poiché spesso costruiamo applicazioni di cui non siamo certi di quale sarà l'utilizzo . Spesso dobbiamo creare livelli da soli, ma le molte variabili che entrano nel calcolo dei costi di una lambda possono essere difficili da capire. In definitiva, per un prodotto SaaS questi modelli di prezzo con pagamento in base al consumo sono ottimi, ma per le agenzie i contabili preferiscono numeri più concreti e prevedibili.

Quando si trattava di Fauna, era decisamente più ambiguo da capire che dire un database MySQL standard con hosting a tariffa fissa per una determinata quantità di spazio. Il vantaggio è che Fauna fornisce un buon calcolatore che siamo stati in grado di utilizzare per mettere insieme i nostri schemi di prezzo.

Un altro aspetto difficile del serverless può essere che molti di questi provider non consentono una facile suddivisione di ciascuna applicazione ospitata. Ad esempio, la piattaforma Heroku lo rende abbastanza semplice creando nuove pipeline e team. Possiamo anche inserire la carta di credito di un cliente nel caso in cui non volessero utilizzare i nostri piani di hosting. Tutto questo può essere fatto anche all'interno della stessa dashboard, quindi non è stato necessario creare più accessi.

Quando si trattava di altri strumenti serverless, questo era molto più difficile. Nella valutazione dei database serverless, Firebase supporta la suddivisione dei pagamenti per progetto . Nel caso di Fauna o DynamoDB, questo non è possibile, quindi dobbiamo fare del lavoro per monitorare l'utilizzo nella loro dashboard e, se il cliente vuole lasciare il nostro servizio, dovremmo trasferire il database sul proprio account.

Infine, gli strumenti serverless offrono grandi opportunità di business in termini di risparmio sui costi, gestione ed efficienza dei processi. Tuttavia, spesso si rivelano difficili per le agenzie quando si tratta di prezzi e gestione degli account. Questa è un'area in cui abbiamo dovuto sfruttare i calcolatori dei costi per creare i nostri livelli di prezzo prevedibili o impostare i clienti con i propri account in modo che possano effettuare i pagamenti direttamente.

Conclusione

Può essere un compito difficile adottare una nuova tecnologia come agenzia. Sebbene siamo in una posizione unica per lavorare con nuovi progetti greenfield che offrono opportunità per nuove tecnologie, dobbiamo anche considerare l'investimento a lungo termine di questi. Come si esibiranno? Le nostre persone saranno produttive e si divertiranno a usarle? Can we incorporate them into our business offering?

You need to have a firm grasp of where you have been before you figure out where you want to go technologically. When evaluating a new tool or platform it's important to think of what you have tried in the past and figure out what is most important to you and your team. We took a look at the concept of a serverless database and passed it through our three lenses – the technology, the experience, and the business. We were left with some pros and cons and had to strike the right balance.

After we evaluated serverless databases, we decided to adopt Fauna over the alternatives. We felt the technology was robust and ticked all of our boxes for our technology filter. When it came to the experience, virtually zero configuration and being able to leverage our existing knowledge of relational data modeling made this a winner with the development team. On the business side serverless provides clear wins to efficiency and productivity , however on the pricing side and account management there are still some difficulties. We decided the benefits in the other areas outweighed the pricing difficulties.

Overall, we highly recommend giving Fauna a shot on one of your next projects. It has become one of our favorite tools and our go-to database of choice for smaller serverless projects and even more traditional large backend applications. The community is very helpful, the learning curve is gentle, and we believe you'll find levels of productivity you hadn't realized before with existing databases.

When we first use a new technology on a project, we start with something either internal or on the smaller side. We try to mitigate the risk by wading into the water rather than leaping into the deep end by trying it on a large and complex project. As the team builds understanding of the technology, we start using it for larger projects but only after we feel comfortable that it has handled similar use cases well for us in the past.

In general, it can take up to a year for a technology to become a ubiquitous part of most projects so it is important to be patient. Agencies have a lot of flexibility but also are required to ensure stability in the products they produce, we don't get a second chance. Always be experimenting and pushing your agency to adopt new technologies, but do so carefully and you will reap the benefits.

Ulteriori letture

• Serverless Database Wishlist - What's Missing Today
• Relational NoSQL: Yes, that is an option
• Concerning toolkits - A great piece about the merits of zero configuration on developer experience