Team Darwin: i futurologi di Engineering
Ricercano, implementano e armeggiano: Il team Darwin di digitec engineering è la fonte del futuro del web shop. Uno sguardo dietro le quinte del nostro sito web.
"Sono stato in vacanza solo per quindici giorni", dice l'ingegnere Michal Nebes, "non riconoscevo più il mio lavoro".
I compagni del Team Darwin ridono.
I suoi compagni del Team Darwin ridono. Sì, dice uno di loro, è stato un prototipo sprint mentre Michal era in vacanza. In seguito, nulla è stato più come prima.
Il Team Darwin è un'azienda che si occupa di prototipi.
Il Team Darwin è uno dei team di ingegneri più giovani di Digitec Galaxus AG. Il loro compito è quello di costruire il negozio web del futuro.
"Non sappiamo ancora esattamente come funzionerà", dice Daniel Zürrer, ingegnere junior.
Il compito di Darwin è quello di capire a livello tecnologico come utilizzerai digitec e Galaxus nel prossimo futuro e come il sito reagirà alle tue esigenze. Ecco perché la pianificazione nel team assomiglia più a degli appunti. Si discutono i metodi, si confrontano le soluzioni e di tanto in tanto qualcosa viene completamente scartato.
L'intelligenza nelle nuvole
Darwin è operativo da sei mesi e non è insolito solo per il suo compito. Il team è anche uno dei pochi che non porta il nome dei film di James Bond. Le squadre Skyfall, Octopussy, Spectre, Goldeneye, Goldfinger e Thunderball possono lavorare proprio accanto a noi, ma Darwin sta andando avanti.
Al lavoro si attengono agli sprint di due settimane e sono sempre sotto pressione. Poi i cinque ingegneri backend, i due designer dell'esperienza utente, l'ingegnere frontend, il proprietario del prodotto e il ricercatore dell'esperienza utente - in altre parole, l'intero team - si siedono insieme e discutono. Cosa ha funzionato? Cosa non ha funzionato? Dove si potrebbe adattare qualcosa.
"Lavoriamo con molte incognite e in un territorio inesplorato", afferma Daniel Zürrer.
Ecco perché Sviluppo Agile è perfetto per Darwin.
Agility è un approccio incrementale e iterativo in cui un progetto viene sviluppato in piccoli passi. Lo stato attuale viene rivisto dopo ogni fase e possono essere apportate eventuali modifiche. In questo modo, Darwin rimane sufficientemente flessibile da adattarsi agli sviluppi, alle tendenze, alle best practice e agli standard di sicurezza attuali.
Darwin ha iniziato il suo lavoro lo scorso agosto. L'obiettivo sembra ancora utopico: nel negozio ti dovrebbero essere mostrate solo le cose che ti interessano. Quando tuo fratello o tua sorella accedono al negozio, vedranno cose completamente diverse da te. Questo significa un sacco di analisi dei dati e un sacco di pensiero astratto.
Prima che Darwin si avventurasse nel negozio, tuttavia, i nove membri del team hanno iniziato a costruire un recommender nel cloud per i blog. Un proof of concept (PoC).
"Volevamo spingere le raccomandazioni nel cloud per i blog.
"Volevamo inviare gli eventi di visualizzazione a Google PubSub, da dove sarebbero stati elaborati con Cloud Dataflow e archiviati in BigQuery. Per il calcolo, si avviava un job Cloud Dataproc notturno che leggeva i dati da BigQuery, eseguiva un filtro collaborativo e salvava il risultato per cliente in Cloud Datastore. Per leggere i dati calcolati, il piano prevedeva un'istanza di AppEngine a cui si accede tramite un endpoint del cloud e che legge i risultati dal Datastore. Il tutto verrebbe poi registrato centralmente in Stackdriver", scrive il team sul sito di sviluppo.
Poco dopo: "La versione attuale di gennaio 2018 ha un aspetto un po' diverso. Cloud Dataflow si è rivelato eccessivo, ed è per questo che ora abbiamo un'applicazione .net core leggera che gira in un container Docker ed elabora i messaggi PubSub e li archivia in BigQuery, tra le altre cose. Abbiamo dato a questo componente il nome di Efesto, dal nome del dio greco dei fabbri, in quanto si occupa anche di forgiare i messaggi PubSub in nuovi formati. Il calcolo funziona ancora in Dataproc come previsto in origine, ma abbiamo anche un'immagine Docker di .net core che configura l'ambiente per Dataproc, avvia il lavoro e lo smonta di nuovo alla fine.
Come previsto, utilizziamo un endpoint del cloud per leggere i risultati. Questo semplifica la registrazione e la sicurezza. Tuttavia, dopo diverse iterazioni di Appengine, il backend è stato sostituito con un'applicazione ASP.net core, che a sua volta gira su Kubernetes."
In tedesco: Per Darwin non è sufficiente utilizzare la tecnologia per risolvere il problema. Si tratta di trovare una soluzione che funzioni al meglio e che sia anche il più leggera possibile. Perché più una soluzione è leggera, meno risorse sono necessarie, più veloce è l'officina e meno fallimenti vengono registrati.
Con il PoC del lettore del blog, Darwin ha dato un nome all'area centrale del suo lavoro: Il cloud. Archiviazione dei dati decentralizzata, distribuita su diversi sistemi ridondanti. Più stabilità, più uptime, tutto meglio. Tutto meglio?
Il problema del cloud
La migrazione dei negozi di cui Darwin sta sviluppando il futuro presenta una serie di problemi. Il documento di progettazione e sviluppo descrive altre sfide che il team sta affrontando, oltre alla desiderata leggerezza del sistema.
Al momento, Darwin sta sviluppando il suo futuro in cloud.
Al momento, Darwin è particolarmente preoccupata per Pythia. "Pythia è più visibile nel contesto dello sviluppo agile", scrive il team. Questo perché Pythia - che prende il nome dall'oracolo di Delfi dei miti greci - è il gestore di tutte le raccomandazioni e, per la maggior parte, rappresenta un adattatore per un datastore.
L'idea di Pythia è stata sviluppata da Darwin.
Il concetto di Pythia era semplice all'inizio. Basandosi sulle nuove Cloud Functions di Google, Darwin voleva utilizzare le applicazioni Node.js senza server. Perché le Funzioni sarebbero state perfette per i loro scopi.
Poi il mondo si è ribellato.
Poi il mondo ha messo i bastoni tra le ruote: attualmente le Cloud Functions possono essere ospitate solo negli Stati Uniti. Ciò significa che i dati aziendali critici della giurisdizione svizzera dovranno essere trasferiti oltre confine se Pythia viene utilizzato con le Cloud Functions. Ma non è tutto:
- Dopo alcune ricerche, è emerso che le Funzioni non sono compatibili con gli Endpoint Cloud
- La latenza oltreoceano è semplicemente troppo alta
- Digitec Galaxus avrebbe dovuto implementare autonomamente l'autenticazione e il logging
In breve: le funzioni cloud sono da escludere.
Ma la missione è ancora valida. È necessario trovare un'alternativa. La soluzione si chiama attualmente AppEngine. AppEngine offre un ambiente semplice per ospitare progetti software in linguaggi che vanno da Python e Go a Java e C#. Il motore rappresenta quindi una via di mezzo tra le funzioni cloud minime e le intere macchine virtuali nel cloud.
Darwin inizia a lavorare: AppEngine nella versione standard con Python 2.7, poiché la versione 3 non è supportata e lo sviluppo incontra un muro. Le Google Python Libraries for Cloud Endpoints semplicemente non vanno d'accordo con il Datastore. "Si potrebbe pensare che le librerie di Google siano compatibili tra loro, ma purtroppo non è sempre così."
Ma non è tutto: l'incompatibilità è aggravata dalla necessità di utilizzare il Cloud Endpoint Framework, che richiede la creazione di definizioni API swagger dal codice. Questa creazione è stata programmata (da Google) in Python ed era terribilmente instabile.
Dopo il deploy è prima del deploy
"Nessun problema" è ancora l'opinione prevalente nel Team Darwin. La soluzione:
- Python 3
- AppEngine Flex
I tecnici possono definire l'endpoint in JSON. Il backend Python lo segue. O meglio, lo farebbe. Perché Python è considerato troppo costoso. "Esattamente, costoso quanto Docker", ammettono gli ingegneri. Adesso lavorano con C# e Docker.
Ora
Si sta già discutendo di ulteriori sviluppi durante le riunioni. Lontano dalla tecnologia. Perché è lì che le persone tendono a impantanarsi, secondo il team. Invece, si discute su dove dovrebbe portare il percorso. Quali sono le funzioni da avere in negozio? Come possono essere implementate in modo snello, veloce e affidabile?
Perché dopo il deploy è prima del deploy. Darwin continua la sua ricerca. Perché gli ingegneri del team sanno una cosa: il futuro viene dal loro ufficio.
A proposito: il Team Darwin vuole farti sapere che il nostro team di ingegneri sta cercando rinforzi. Se vuoi partecipare, dai un'occhiata alle seguenti offerte di lavoro:
Inoltre, ci sono altre posizioni di ingegneria qui.
Se vuoi saperne di più su come sviluppiamo, dai un'occhiata qui.
Giornalista. Autore. Hacker. Sono un contastorie e mi piace scovare segreti, tabù, limiti e documentare il mondo, scrivendo nero su bianco. Non perché sappia farlo, ma perché non so fare altro.