In Jitterbit la nostra missione è semplificare anche le sfide di connettività più complesse e consentire a chiunque di connettersi nel mondo digitale di oggi. Mentre sottolineiamo che non è necessario essere uno sviluppatore per utilizzare i prodotti di Jitterbit, dietro ogni grande soluzione software c'è un team di fantastici sviluppatori. Nel Jitterbit Tech Talk blog serie, i membri del team di sviluppo di Jitterbit ci forniscono informazioni sulla creazione di una piattaforma cloud di livello aziendale e sulle sfide che hanno dovuto risolvere in merito a multi-tenancy, scalabilità e sicurezza.
Questa settimana, Pankaj Arora, il nostro Sr. Director of Technology, esamina come progettare e progettare una piattaforma cloud di classe enterprise altamente scalabile.
Il Cloud offre alle aziende un modo potente per offrire i propri prodotti e servizi facilmente accessibili da qualsiasi luogo e su qualsiasi dispositivo. Fornisce inoltre enormi vantaggi al fornitore, tra cui la visibilità su come viene utilizzata la propria offerta, sviluppo e implementazione rapidi e riduzioni complessive dei costi IT e di manutenzione. Di conseguenza, quasi tutti company oggi sta cercando di rendere le proprie soluzioni disponibili nel Cloud.
Ma c'è molto di più per diventare un vero cloud company piuttosto che installare software su un server ospitato e inserire la parola "Cloud" nei tuoi materiali di marketing.
Di recente ho parlato con uno stratega della tecnologia e hanno notato che circa il 75% delle aziende vorrebbe migrare le proprie offerte aziendali legacy nel cloud. Sorprendentemente, il 90% di loro elabora un piano iniziale che verrebbe costruito su un'architettura in cui le loro applicazioni legacy verrebbero semplicemente distribuite su un server cloud accessibile al pubblico. Questo approccio annulla tutti i vantaggi che il cloud ha da offrire.
La creazione di una vera piattaforma cloud multi-tenant richiede la risoluzione di una serie di diversi tipi di sfide come sicurezza, affidabilità, scalabilità, disponibilità elevata, tolleranza ai guasti, registrazione, monitoraggio, sistema di notifica, capacità di distribuzione continua e altro ancora.
Nel post di oggi, daremo uno sguardo più approfondito a come abbiamo gestito la sfida della "scalabilità" durante lo sviluppo della nostra piattaforma di integrazione cloud multi-tenant.
Il grado di scalabilità di un'applicazione è legato alla sua capacità di scalare verticalmente e orizzontalmente. In un ambiente Cloud, ciò significa progettare servizi che soddisfino richieste esterne scalabili in modo da poter sfruttare sistemi di back-end interni come database, cache, livelli mediatori, processi batch (motore analitico, motore di raccomandazione) ecc. per gestire richieste praticamente infinite in un tempo ragionevolmente breve lasso di tempo. Non è sempre possibile prevedere il numero di utenti che accedono alla tua piattaforma. La progettazione di un'architettura che tenga conto di ciò nel modello multi-tenancy aiuta a trasformare questa incertezza in un problema generico di scalabilità.
Ridimensionamento verticale
La scalabilità verticale comporta l'aggiunta di risorse come CPU aggiuntive o memoria a un singolo nodo in un sistema e questa dovrebbe essere la prima cosa a cui pensare quando si ridimensionano i servizi. È molto importante progettare le applicazioni in modo che utilizzino in modo ottimale queste risorse. Prendiamo il caso d'uso comune per la nostra piattaforma cloud di integrazione ibrida, in cui le operazioni di integrazione sono servite da un nodo di server on-premise o cloud. Qui i servizi dovrebbero prendere una richiesta per eseguire integrazioni, passare la richiesta ai nodi del server e continuare a servire più richieste. Il livello dei servizi non dovrebbe dipendere o essere bloccato dai processi che si verificano ai vari livelli del sistema. Pertanto, è molto importante disporre di un'architettura asincrona guidata dagli eventi.
Un modo semplice per comprendere l'architettura asincrona è pensare alla tua architettura come a un ristorante. Un cameriere prende le ordinazioni da un tavolo e le passa allo chef. Mentre lo chef, il food runner e il fattorino si occupano di attività come cucinare, servire e pulire, il cameriere continua a servire i nuovi clienti ed esegue i controlli alla fine del servizio.
Mantenere l'asincronia mentre il sistema funziona con tutti i componenti come database, cache e livello mediatore è molto importante. Il passaggio del carico ai nodi server in cluster ad alta disponibilità che eseguono le integrazioni libera le risorse affinché il livello di servizio accetti più richieste e risponda quando i processi sono completati.
Ridimensionamento orizzontale
La successiva considerazione chiave dovrebbe essere che i servizi sono scritti in modo tale che non dovrebbe importare quante istanze di tali servizi sono in esecuzione e quale sistema condiviso sta eseguendo transazioni in un dato momento. Ciò offre alla nostra piattaforma cloud la flessibilità necessaria per ridimensionare automaticamente il livello dei servizi. Ogni parte del back-end è altamente disponibile e scalabile automaticamente per tenere il passo con la domanda di contenitori di servizi in crescita.
Tuttavia, non possiamo avere contenitori infiniti che eseguono livelli di servizio che utilizzano componenti condivisi. Questo non è il design ottimale. Torniamo al nostro esempio di ristorante. Con il ridimensionamento verticale un singolo ristorante potrebbe diventare altamente scalabile aggiungendo più personale, ma a un certo punto il numero di risorse (cuochi, corridori, ragazzi dell'autobus) raggiungerà un punto di saturazione. Per scalare ulteriormente, questa attività dovrebbe aprire ulteriori sedi che aiuterebbero a distribuire i clienti e bilanciare il carico.
È meglio dividere l'intera piattaforma in più zone, con ciascuna zona che si comporta come una replica della zona iniziale. Questo ci consente di utilizzare più zone per bilanciare il carico delle esigenze future.
Questo modello ha molteplici vantaggi:
1. Possibile ridimensionamento orizzontale infinito, poiché possiamo inserire qualsiasi numero di zone
2. Tolleranza ai guasti, nel caso in cui l'intera zona fallisca a causa di un disastro naturale
3. Separazione dei dati, nel caso di una piattaforma SaaS che richiede anche la segregazione dei metadati basata sulla posizione come per le zone USA, EMEA, ecc.
Il risultato desiderato qui è che l'esperienza di un utente dovrebbe essere la stessa, indipendentemente da dove si trovino e in quale zona colpiscano. Nessun intervento manuale dovrebbe essere richiesto da un utente per portare a termine il lavoro.
Nei nostri cloud di integrazione ibrida blog, abbiamo discusso di come ci siamo imbattuti nella sfida di utilizzare un livello mediatore in modo da supportare una scala verticale limitata. Scrivendo il nostro livello di connessione non bloccante personalizzato basato sul trasporto HTTPS sicuro, siamo stati in grado di estendere l'architettura per avere una scala verticale di 50 volte. Naturalmente, è anche scalabile orizzontalmente. Questa combinazione di ridimensionamento verticale e orizzontale ci ha fornito uno strato meno costoso e facilmente estendibile per soddisfare le nostre crescenti esigenze.
Ottimizzazione dell'uso dei componenti condivisi:
I componenti condivisi dovrebbero essere essi stessi scalabili e altamente disponibili per supportare la piattaforma cloud. Ma i componenti condivisi sono condivisi e, di conseguenza, non sono così scalabili come il livello dei servizi. È molto importante prendersi cura di alcuni componenti che possono essere sensibili a un carico elevato, ad esempio i database. Un modello può essere quello di dare la priorità e mettere in coda l'utilizzo di componenti condivisi in cui più carichi simultanei di volume elevato possono causare problemi. La definizione delle priorità può ridurre il carico e mitigare l'errore su qualsiasi richiesta mission-critical. Nel nostro ristorante la cucina è una componente condivisa e mentre il cameriere può prendere l'ordine di un commensale per antipasto, antipasto e dessert, la cucina darà la priorità alla cottura di questi elementi e ne bilancerà il carico.
Un altro modo per affrontare il carico può essere la memorizzazione nella cache dei dati che vengono modificati raramente per impedire un utilizzo elevato di tali componenti. Se le patatine fritte sono un elemento popolare nel menu, il ristorante potrebbe decidere di "nascondere" un lotto continuo piuttosto che friggerle su ordinazione.
Monitoraggio dei componenti:
Infine, è molto importante monitorare ogni componente e conoscerne i limiti. Il sistema dovrebbe essere in grado di aumentare la larghezza di banda automaticamente e al momento giusto per mantenere i sistemi attivi e funzionanti in base alle esigenze della piattaforma cloud. Il monitoraggio può essere esterno o avviato dall'applicazione, ma in entrambi i casi l'obiettivo finale è consentire al sistema di ridimensionarsi automaticamente in base al carico.
Nel prossimo blog post, parleremo di monitoraggio, logging e altri elementi dell'architettura.
