Architettura della piattaforma Lokad
La piattaforma di Lokad è una soluzione SaaS multi-tenant ospitata su cloud. Questa pagina presenta l’architettura ad alto livello della piattaforma. Sebbene la pagina sia destinata a un pubblico IT, un praticante esperto di supply chain potrebbe trovare interessanti queste informazioni, poiché questa architettura riflette la nostra visione tecnologica per l’ottimizzazione predittiva delle supply chain.
Panoramica dell’architettura
Lokad si presenta come un ambiente per sviluppare e gestire app di ottimizzazione predittiva destinate a problemi di supply chain. Al suo centro si trova un linguaggio specifico del dominio (DSL) chiamato Envision, sviluppato da Lokad. Envision è accessibile agli utenti finali e la maggior parte delle funzionalità viene fornita attraverso di esso. Sebbene Envision implichi la programmazione, Lokad è destinato a specialisti di supply chain, non a specialisti IT o ingegneri software.
La piattaforma Lokad è multi-tenant: la stessa app serve tutti i nostri clienti e include una breve serie di servizi. La granularità della suddivisione è principalmente motivata da requisiti divergenti in termini di affidabilità, sicurezza e prestazioni di ciascun servizio, piuttosto che da una suddivisione puramente funzionale. Infatti, il livello di accoppiamento che esiste tra questi servizi è relativamente alto. Questi servizi condividono lo stesso repository di codice Git e vengono aggiornati insieme con frequenza.
Il nostro codice è implementato in F#, C# e TypeScript con poche dipendenze di terze parti oltre a .NET, un framework open-source sviluppato da Microsoft. Inoltre, a parte .NET stesso, abbiamo poche altre dipendenze (circa un ordine di grandezza inferiore rispetto alla norma).
Questa architettura si discosta ampiamente dalle architetture “usuali” che si trovano tra le app enterprise, e per buoni motivi. L’app enterprise comune dipende da dipendenze pesanti ed estese; ogni dipendenza pesa tipicamente più di 1 milione di righe di codice. Lokad, tuttavia, non ha dipendenze di terze parti nelle seguenti aree:
- Database relazionale: al suo posto, utilizziamo uno store di eventi insieme a uno store indirizzabile dal contenuto.
- Sistema di caching: al suo posto, collocalizziamo il calcolo e lo storage transitorio.
- Gestore di pipeline: al suo posto, abbiamo il nostro scheduler (dettagliato di seguito).
- Motore di analisi: al suo posto, il nostro DSL chiamato Envision fornisce funzionalità di analisi.
- Toolkit di machine learning: al suo posto, il DSL fornisce anche funzionalità di ML.
- Toolkit di visualizzazione dei dati: al suo posto, abbiamo sviluppato il nostro, con un’integrazione stretta del DSL.
Va notato che, sebbene sviluppiamo internamente in modo estensivo la nostra piattaforma, ci affidiamo intenzionalmente ed esclusivamente a componenti di terze parti per tutti i nostri componenti di sicurezza, come gli algoritmi crittografici.
Il front-end
Il front-end si riferisce agli elementi accessibili agli utenti finali, inclusi gli agenti automatizzati utilizzati per spostare i dati da e verso Lokad. La maggior parte di queste interazioni avviene tramite un browser web tramite HTTPS, anche se Lokad supporta anche i protocolli FTPS e SFTP per spostare i file.
go.lokad.com
Questo servizio ospita React, il framework front-end dell’app web di Lokad, implementato come un’applicazione single-page (SPA). Questo front-end dipende dalle API (interfacce di programmazione delle applicazioni) fornite dagli altri servizi.
Questo servizio serve esclusivamente contenuti statici, principalmente JavaScript. Non ci sono parti in movimento lato server e, in particolare, nessuna persistenza dei dati. Questo design è intenzionale poiché l’uptime è la priorità più importante per questo servizio; indipendentemente dal servizio a cui si accede tramite il web, il servizio go.lokad.com deve essere disponibile.
Dashboard
Il servizio dashboard, come suggerisce il nome, si occupa di renderizzare i dashboard analitici web forniti da Lokad.
Ogni dashboard è il risultato di uno script Envision eseguito. I dashboard sono ampiamente pre-calcolati, anche se vengono offerte alcune capacità interattive. Il design di Envision stesso garantisce che le interazioni lato client rimangano problemi di small data, indipendentemente dalle dimensioni del set di dati originale.
Lato client, tutti i dati necessari per il primo rendering del dashboard vengono ottenuti tramite una singola richiesta HTTPS. Questo design a singola richiesta serve a ridurre al minimo l’overhead di latenza. L’impacchettamento binario e la compressione riducono al minimo il consumo di larghezza di banda.
Lato server, i dati associati a un determinato dashboard vengono impacchettati dal content store. Anche in questo caso, l’impacchettamento è essenziale per mantenere il numero totale di richieste di rete molto basso, di solito inferiore a mezza dozzina, indipendentemente dalla complessità del dashboard.
I dashboard interattivi danno all’utente finale la possibilità di accedere a grandi set di dati, oltre a quanto sarebbe possibile trasferire e visualizzare tramite un browser. Passare da una vista all’altra richiede al massimo una singola richiesta lato client (e pochissime richieste lato server).
Lokad vs mainstream
Il design del tempo di rendering costante di Lokad differisce dalle soluzioni di business intelligence (BI) e da altri strumenti analitici mainstream. I dashboard che si trovano in tali strumenti sono inevitabilmente composti da una lista di riquadri, talvolta chiamati blocchi o widget. Il modo standard per gestire questi riquadri prevede 1 richiesta lato client per ogni riquadro, seguita da un numero non specificato/non garantito di richieste lato server. Purtroppo, questo design porta a dashboard lente con un ritardo evidente per ogni riquadro. Inoltre, la visualizzazione completa di tutti i riquadri del dashboard richiede spesso diversi secondi.
Lokad elimina questo problema facendo sì che il compilatore Envision produca una strategia di impacchettamento dei dati utilizzati per renderizzare il dashboard, garantendo così sia richieste a due cifre lato client, sia ancora meno lato server. Dal nostro punto di vista, le prestazioni dei dashboard iniziano al momento della compilazione, con gli script che supportano i dashboard.
Inoltre, la maggior parte degli strumenti analitici posticipa una grande parte del calcolo fino a quando non viene richiesto un dashboard (talvolta chiamato report). Purtroppo, il design porta inevitabilmente a problemi di prestazioni quando il numero di utenti finali simultanei aumenta, poiché c’è un conflitto inevitabile per le risorse di calcolo lato server che sono mutualizzate per servire tutti gli utenti finali.
Lokad mitiga ampiamente questo problema pre-calcolando i dashboard. Il nostro design riduce al minimo le risorse lato server necessarie - su richiesta dell’utente finale - per servire un dashboard, lasciando il content store come il principale (ma intenzionale) collo di bottiglia per servire i dati del dashboard. Questo design garantisce che un gran numero di utenti finali possa essere servito contemporaneamente con un degrado minimo delle prestazioni.
Progetti
Il servizio progetti gestisce script e lavori batch (chiamati sequenze). Questo servizio presenta una gerarchia di progetti. Gli utenti finali, che hanno i diritti di accesso appropriati, possono visualizzare, modificare ed eseguire progetti. Un’app di ottimizzazione predittiva personalizzata implementata da Lokad include tipicamente un elenco di progetti.
Viene utilizzato l’event sourcing per persistere le voci degli utenti, sfruttando l’event store dettagliato qui. Ogni singolo comando o interazione emesso al servizio viene registrato e trasformato in un evento risultante. L’interfaccia utente presenta lo stato ottenuto raccogliendo tutti gli eventi. Questo approccio è noto come modello CQRS+ES. CQRS sta per Command and Query Responsibility Segregation, mentre ES sta per Event Source.
Il modello CQRS+ES fornisce per design una completa storicizzazione di tutte le modifiche introdotte nell’applicazione. Nel caso specifico di Lokad, fornisce una versione simile a Git di tutte le modifiche mai apportate agli script Envision che esistono all’interno dell’account.
Lokad vs mainstream
In termini di UI e UX, il servizio progetti segue l’approccio mainstream. Sotto il cofano, tuttavia, viene utilizzato il modello CQRS+ES come alternativa al modello CRUD (create, read, update, delete) utilizzato per la maggior parte del software aziendale. Questo modello sostituisce il database relazionale con un event store (discusso di seguito).
L’approccio CQRS+ES offre molti vantaggi rispetto al modello CRUD. Ad esempio, offre una semantica superiore, una tracciabilità superiore e, nel caso di Lokad, prestazioni superiori in quanto ci consente di personalizzare ampiamente la strategia di persistenza utilizzata per archiviare e recuperare il codice sorgente Envision. Infatti, la maggior parte dei dati da persistere nel servizio progetti consiste nel codice sorgente Envision.
Codice
Il servizio codice offre un IDE (ambiente di sviluppo integrato) dedicato al linguaggio Envision. Questo IDE basato sul web ha tutte le funzionalità e le funzionalità previste da un ambiente di sviluppo moderno, come la colorazione del codice, il completamento automatico e una serie di azioni sul codice (ad esempio, la rinominazione delle variabili), rese possibili attraverso l’analisi statica del codice.
La complessità principale del servizio codice risiede nel suo backend del language server che fornisce un feedback in tempo reale: suggerimenti per il completamento automatico, errori o azioni sul codice ad ogni pressione di un tasto. In particolare, una delle principali sfide tecniche consiste nel mantenere una bassa latenza per questa funzione, poiché i ritardi sarebbero piuttosto evidenti considerando il ritmo delle normali interazioni con la tastiera.
File
Ogni account presso Lokad ha il proprio spazio per archiviare i file. Il servizio file offre un sistema di file distribuito e versionato che viene utilizzato per gestire i suoi file. Questo sistema di file può essere accessato tramite un’interfaccia web e i protocolli SFTP e FTPS. Concettualmente, questo sistema di file è in gran parte simile a un repository Git, tranne che è destinato a file piatti di dimensioni gigabyte.
La versioning dei file è garantito attraverso il modello CQRS+ES, che integra la presentazione di una sequenza di “commit”, riflettendo l’evoluzione del sistema di file stesso. La persistenza del contenuto dei file è garantita attraverso un content store (discusso di seguito).
Versionando sia il codice (script Envision) che i dati, Lokad offre una riproducibilità completa dei comportamenti passati per le app di supply chain implementate sulla sua piattaforma. Da una prospettiva di supply chain, questa capacità è importante per assicurarsi che ogni risultato anomalo generato dall’app di supply chain possa essere risolto.
Lokad vs mainstream
Il servizio file è strettamente integrato con il linguaggio Envision (fornendo vantaggi di correttezza), l’IDE Envision (fornendo vantaggi di produttività) e l’ambiente di runtime Envision (fornendo vantaggi di prestazioni). Questi vantaggi sarebbero difficili da ottenere con un sistema di file generico, un componente software che è prima di tutto un compagno del kernel.
Inoltre, molti dei vantaggi del servizio file si ottengono facendo meno di un sistema di file generico. Ad esempio, il servizio file non consente a un file di essere aggiornato contemporaneamente da diversi processi. Tali funzionalità, nel contesto specifico delle app di supply chain, espongono solo i professionisti della supply chain a problemi e complessità legati all’IT senza fornire un valore in cambio.
Account
La gestione dell’identità e dell’accesso (IAM) del servizio account è una delle parti più diffuse di Lokad. Gestisce gli account Lokad, gli utenti Lokad, l’autenticazione (idealmente, autenticazione delegata) e l’ACL (Access Control List) che controlla cosa gli utenti possono o non possono fare con un account Lokad.
Questo servizio sfrutta anche il pattern CQRS+ES, che offre registri di audit completi di tutte le operazioni IAM - operazioni che sono sempre sensibili alla sicurezza a causa della natura stessa di IAM. L’utilizzo della sorgente degli eventi come registro di audit rimuove anche intere classi di problemi di sicurezza, come il compromesso del registro di audit per non aver registrato gli eventi selezionati.
Il livello di persistenza
Il livello di persistenza, come suggerisce il nome, garantisce la persistenza di tutti i dati gestiti da Lokad. Questi dati si presentano in due diverse varianti: in primo luogo, i file - caricati dai clienti su Lokad o generati tramite script Envision; in secondo luogo, gli eventi derivanti dalle operazioni degli utenti (compresi gli agenti automatizzati, come uno script di caricamento file). Lokad persiste entrambe le varianti di dati tramite Azure Blob Storage che funge da archivio chiave-valore.
Event Store
L’event store persiste gli eventi generati da tutti i servizi della piattaforma Lokad. Questo store rappresenta il database di transizione di stato di Lokad. Abbiamo rilasciato il codice sorgente del nostro event store come open source.
Questo componente è semplice: persiste e fornisce eventi in modo affidabile, sfruttando un archivio chiave-valore distribuito sottostante (Azure Blob Storage). Ci si aspetta che gli eventi siano di piccole dimensioni - limitati a 512 kB, ma tipicamente inferiori a 1 kB.
Non ci sono funzionalità “intelligenti”, come l’analisi in streaming o la gestione delle proiezioni. Ancora una volta, facendo meno, Lokad rimuove intere classi di problemi, come gli attacchi di SQL injection, che sorgono a causa delle capacità del livello di persistenza.
Content Addressable Store
Il content addressable store (CAS) persiste i file, caricati sulla piattaforma Lokad o generati tramite gli script Envision. Abbiamo rilasciato il codice sorgente del nostro content addressable storage come open source.
Il CAS è destinato a supportare file di grandi dimensioni, tipicamente di diversi MB, con un limite superiore di 100 GB. Il CAS viene utilizzato per archiviare file o frammenti di file, suddivisi seguendo una strategia di archiviazione colonnare. L’archiviazione colonnare è allineata al pattern di accesso del livello di esecuzione.
Il livello di esecuzione
Come suggerisce il nome, il livello di esecuzione garantisce l’esecuzione degli script Envision all’interno della piattaforma Lokad e include una serie di componenti. Per brevità, elencheremo qui solo quelli più notevoli. Il compiler trasforma gli script Envision in istruzioni destinate a una macchina virtuale distribuita. Il scheduler è un servizio di utilità per attivare, pianificare e sequenziare gli script Envision. Thunks è il nome in codice per la macchina virtuale Envision. Infine, Ionic è il nome per la strategia di archiviazione colonnare, prodotta e consumata dalla macchina virtuale Envision.
Compiler
Il compilatore trasforma gli script Envision in bytecode destinato alla macchina virtuale distribuita della piattaforma Lokad, chiamata “Thunks” (vedi sotto). L’architettura di questo compilatore segue le pratiche di progettazione mainstream: una pipeline di compilazione che inizia con il parsing seguito da una serie di trasformazioni da una rappresentazione interna alla successiva, terminando con la produzione di bytecode.
Il backend del server di linguaggio, che guida le interazioni con il codice sorgente Envision (vedi il servizio Code sopra), fa anche parte del compilatore. Il server di linguaggio è stato progettato per fornire feedback significativi e messaggi di errore al programmatore Envision durante la scrittura del codice. Dopo la maggior parte dei tasti premuti, lo script non è ancora uno script Envision valido, ma grazie allo stato del server di linguaggio, vengono comunque forniti feedback significativi.
Scheduler
Lo scheduler è un servizio di utilità per l’esecuzione degli script Envision senza interventi manuali. Lo scheduler attiva, pianifica e sequenzia l’esecuzione degli script Envision. Fornisce anche funzionalità di allerta se le esecuzioni deviano dai tempi previsti. L’integrazione stretta dello scheduler con il resto della piattaforma fornisce una serie di funzionalità desiderabili, come trigger di modifica file (per avviare gli script Envision alla ricezione di file, ad esempio) o la rilevazione anticipata di un possibile errore (se uno degli script Envision all’interno di una sequenza non viene compilato).
Thunks
Thunks è il nome in codice della macchina virtuale distribuita di Lokad. In effetti, gli script Envision beneficiano nativamente di un’esecuzione distribuita. In questo senso, il compilatore Envision non mira a una singola macchina, ma a un cluster di macchine. Questa caratteristica è fondamentale per elaborare grandi set di dati in modo tempestivo. Il linguaggio Envision è stato appositamente progettato per la parallelizzazione automatica (una caratteristica altrimenti molto difficile da ottenere con un linguaggio di programmazione generale). Incidentalmente, il cluster fornisce anche una maggiore affidabilità dell’esecuzione degli script se una macchina diventa non rispondente.
Il cluster di macchine dedicato a Thunks è condiviso, in modalità multi-tenant, tra tutti gli account. Questa caratteristica è essenziale per mantenere i costi di calcolo sotto controllo. Il caso d’uso tipico della supply chain prevede un batch di esecuzione al giorno, di solito della durata inferiore a 60 minuti. La condivisione delle risorse tramite multi-tenancy mitiga in gran parte i costi associati alle risorse di calcolo, che altrimenti verrebbero addebitati in periodi di 24 ore, mentre solo un’ora (o meno) verrebbe utilizzata.
Per una spiegazione approfondita, suggeriamo la serie in 4 parti di Victor Nicollet sul design della macchina virtuale Envision, e per risposte alle domande più comuni su prestazioni legate a Lokad, consigliamo la sezione 8 delle nostre FAQ sulla sicurezza.