Architettura della piattaforma Lokad
La piattaforma Lokad è una soluzione SaaS multi-tenant ospitata su cloud. Questa pagina presenta l’architettura ad alto livello della piattaforma. Anche se la pagina è destinata a un pubblico IT, un praticante della supply chain esperto di tecnologia 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 operare app di ottimizzazione predittiva destinate ai problemi della supply chain. Al suo nucleo si trova un linguaggio specifico del dominio (DSL) chiamato Envision, progettato da Lokad. Envision è accessibile agli utenti finali e la maggior parte delle funzionalità viene fornita attraverso di esso. Anche se Envision implica programmazione, Lokad è destinato a specialisti della supply chain, non a specialisti IT o ingegneri del 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 frequentemente aggiornati insieme.
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 (approssimativamente un ordine di grandezza inferiore alla norma).
Questa architettura si discosta ampiamente dalle architetture “usuali” trovate tra le app enterprise - e per buone ragioni. L’app enterprise comune dipende da pesanti e ampie dipendenze; 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: Invece, utilizziamo un event store insieme a uno store indirizzabile per contenuto.
- Sistema di caching: Invece, collocalizziamo calcolo e storage transitorio.
- Gestore di pipeline: Invece, abbiamo il nostro scheduler (dettagliato di seguito)
- Motore di analisi: Invece, il nostro DSL chiamato Envision fornisce capacità di analisi.
- Toolkit di machine learning: Invece, il DSL fornisce anche capacità di ML.
- Toolkit di visualizzazione dei dati: Invece, abbiamo sviluppato il nostro, con stretta integrazione del DSL.
Va notato che, sebbene internalizziamo ampiamente lo sviluppo della nostra piattaforma, ci affidiamo intenzionalmente ed esclusivamente a componenti di terze parti per tutti i nostri componenti di sicurezza, come algoritmi crittografici.
Il front-end
Il front-end si riferisce agli elementi accessibili agli utenti finali, inclusi 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 a singola pagina (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 massima priorità per questo servizio; indipendentemente da quale servizio viene accesso tramite il web, il servizio go.lokad.com deve essere disponibile.
Dashboard
Il servizio dashboard, come suggerisce il nome, si occupa del rendering dei 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 dell’insieme 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 minimizzare il ritardo di latenza. Il confezionamento binario e la compressione minimizzano il consumo di larghezza di banda.
Lato server, i dati associati a un determinato dashboard vengono confezionati dallo store dei contenuti. Anche in questo caso, il confezionamento è 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 attraverso un browser. Passare da una vista all’altra richiede al massimo una singola richiesta lato client (e pochissime lato server).
Lokad vs mainstream
Il design di tempo di rendering costante di Lokad differisce dalle principali soluzioni di business intelligence (BI) e da altri strumenti analitici. I dashboard che si trovano in tali strumenti sono inevitabilmente composti da una lista di riquadri, a volte chiamati blocchi o widget. Il modo standard per gestire questi riquadri prevede 1 richiesta lato client per riquadro, seguita da un numero non specificato/non garantito di richieste lato server. Purtroppo, questo design porta a dashboard lenti 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 confezionamento dei dati utilizzati per renderizzare il dashboard, garantendo così sia richieste a cifra singola 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 (a volte 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 minimizza le risorse lato server necessarie - su richiesta dell’utente finale - per servire un dashboard, lasciando lo store dei contenuti 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 dashboard con una degradazione minima 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’applicazione 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 lo store eventi 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. Tuttavia, sotto il cofano, viene utilizzato il modello CQRS+ES come alternativa a quello CRUD (create, read, update, delete) utilizzato per la maggior parte del software enterprise. Questo modello sostituisce il database relazionale con uno store eventi (discusso di seguito).
L’approccio CQRS+ES offre molti vantaggi rispetto al modello CRUD. Ad esempio, offre una semantica superiore, una maggiore auditabilità e, nel caso di Lokad, una maggiore performance in quanto ci consente di personalizzare ampiamente la strategia di persistenza utilizzata per memorizzare 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 presenta 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 (es: rinominazione delle variabili), reso possibile 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 battuta di tastiera. In particolare, una delle sfide tecniche principali 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 memorizzare file. Il servizio file presenta un sistema di file distribuito versionato che viene utilizzato per gestire i suoi file. Questo sistema di file può essere accesso tramite un’interfaccia web e 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 completa la presentazione di una sequenza di “commit”, riflettendo l’evoluzione del sistema di file stesso. La persistenza dei contenuti dei file è garantita attraverso uno store indirizzabile per contenuto (discusso di seguito).
Versionando sia il codice (script Envision) che i dati, Lokad offre una riproducibilità completa dei comportamenti passati per le app della supply chain implementate sulla sua piattaforma. Da una prospettiva della supply chain, questa capacità è importante per assicurarsi che ogni risultato anomalo generato dall’app della supply chain possa essere risolto.
Lokad vs mainstream
Il servizio file è strettamente integrato con il linguaggio Envision (fornendo benefici di correttezza), l’IDE Envision (fornendo benefici di produttività) e il runtime Envision (fornendo benefici di performance). Questi benefici sarebbero difficili da ottenere con un sistema di file generico, un pezzo di software che è prima di tutto un compagno del kernel.
Inoltre, molti dei benefici del servizio file sono ottenuti facendo meno rispetto a un sistema di file generico. Ad esempio, il servizio file non permette a un file di essere aggiornato contemporaneamente da diversi processi. Tali funzionalità, nel contesto specifico delle app della supply chain, espongono solo i professionisti della supply chain a questioni e complessità legate all’IT senza fornire un valore in cambio.
Account
La Gestione dell’Identità e degli Accessi (IAM) del servizio account è una delle parti più mainstream di Lokad. Gestisce gli account Lokad, gli utenti Lokad, l’autenticazione (idealmente, autenticazione delegata) e la ACL (Access Control List) che controlla cosa gli utenti possono o non possono fare con un account Lokad.
Questo servizio sfrutta anche il modello 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 dell’IAM. Utilizzando la sorgente degli eventi come registro di audit si eliminano intere classi di problemi di sicurezza, come il compromesso del registro di audit per non aver registrato eventi selezionati al suo interno.
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 distinte varianti: in primo luogo, i file - caricati dai clienti su Lokad o generati tramite script Envision; in secondo lu sede, gli eventi derivanti dalle operazioni degli utenti (inclusi agenti automatizzati, come uno script di caricamento file). Lokad persiste entrambe le varianti di dati attraverso Azure Blob Storage che funge da store 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 uno store distribuito chiave-valore sottostante (Azure Blob Storage). Ci si aspetta che gli eventi siano di dimensioni ridotte - limitati a 512kB, ma tipicamente inferiori a 1kB.
Non ci sono funzionalità “intelligenti”, come analisi in streaming o gestione delle proiezioni. Ancora una volta, facendo meno, Lokad elimina intere classi di problemi, come gli attacchi di injection SQL, che sorgono a causa delle capacità del livello di persistenza.
Store indirizzabile per contenuto
Lo store indirizzabile per contenuto (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 massimo di 100GB. Il CAS viene utilizzato per memorizzare file o frammenti di file, sharded seguendo una strategia di storage columnar. Lo storage columnar è allineato con il modello 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 i più notevoli. Il compilatore trasforma gli script Envision in istruzioni destinate a una macchina virtuale distribuita. Lo scheduler è un servizio di utilità per attivare, pianificare e sequenziare gli script Envision. Thunks è il nome in codice della macchina virtuale Envision. Infine, Ionic è il nome della strategia di storage columnar, prodotta e consumata dalla macchina virtuale Envision.
Compilatore
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 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 parte anche del compilatore. Il server di linguaggio è stateful per fornire feedback significativo e messaggi di errore al programmatore Envision mentre si codifica. Dopo la maggior parte delle battiture, 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 eseguire gli script Envision senza interventi manuali. Lo scheduler attiva, pianifica e sequenzia l’esecuzione degli script Envision. Fornisce anche capacità 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 dei file, ad esempio), o la rilevazione precoce di un’eventuale fallimento imminente (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. Di fatto, 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 esse. Questa caratteristica è fondamentale per elaborare grandi set di dati in modo tempestivo. Il linguaggio Envision è stato appositamente progettato per la parallelizzazione automatica (una funzionalità altrimenti molto difficile da ottenere con un linguaggio di programmazione generale). Incidentemente, il cluster fornisce anche una maggiore affidabilità dell’esecuzione degli script se una macchina diventa non reattiva.
Il cluster di macchine dedicato a Thunks è raggruppato, in modo multi-tenant, tra tutti gli account. Questa caratteristica è essenziale per mantenere sotto controllo i costi di calcolo. Il tipico caso d’uso della supply chain prevede un batch di esecuzione al giorno, che di solito dura meno di 60 minuti. Il raggruppamento delle risorse attraverso il multi-tenancy mitiga in gran parte i costi associati alle risorse di calcolo - un costo che altrimenti verrebbe addebitato in periodi di 24 ore, mentre verrebbe utilizzato solo un’ora (forse meno).
Per una spiegazione dettagliata, suggeriamo la serie in 4 parti di Victor Nicollet sul design della Macchina Virtuale Envision, e per risposte alle domande più comuni su prestazioni di Lokad, raccomandiamo la sezione 8 delle nostre FAQ sulla sicurezza.