CPQ Cloud

"Stateless, stateful, multi-tenant, single-tenant, virtualizzazione, micro-servizi, orchestratori, virtualizzazione..."

Questi, e molti altri termini simili, fanno parte del mio vocabolario come architetto KBMax. Saresti sorpreso che al giorno d'oggi facciano parte di la vita di tutti, anche se non è ovvio. Nel mondo di oggi tutti utilizzano un sistema cloud in qualche forma, ma possono essere consapevoli o meno delle implicazioni del servizio utilizzato quotidianamente, come costi, sicurezza, disponibilità e privacy.

"Cos'è l'architettura cloud e perché dovrebbe interessarmi?"

If you are selecting CPQ software (or any software) for your company, you may be interested in preventing wasted resources on future hidden costs, by simply investing in (or buying) future-proof software. I’ve seen many companies who were convinced they were getting a cloud application, but later realized that they had purchased ‘virtualized software’ and paid a very high price to end up getting stuck with the same version of the software forever, racking up hidden costs.

Dato che programmavo da 40 anni, volevo raccontarvi la storia dell'architettura cloud dal mio punto di vista. Puoi Google ciascuno dei termini sopra, ma penso che tu possa capire meglio il "perché" dietro alcune delle scelte architettoniche dopo aver appreso la storia dietro di loro. Come in ogni altro campo, le 'scoperte' sono la risposta ai problemi e alle esigenze attuali.

Una breve storia dell'informatica distribuita

Mainframe

Eviterò il mainframe perché è troppo profondo nella storia antica dell'informatica.

Server e desktop connessi

Cominciamo invece con l'inizio di questo secolo, dove i computer desktop erano comuni e i server erano in circolazione, ma solo per alcune attività come la condivisione di file, la stampa, l'autenticazione degli utenti e i database. I dati erano fisicamente "di proprietà" e il software e l'hardware venivano venduti insieme. Durante questo periodo per gli utenti, il software era principalmente un'applicazione locale con istanze installate su un computer desktop. La sicurezza non era un vero problema, anche se tutti erano "amministratori" e alcuni utenti avevano persino un "post it" con la password apposta sul monitor. Il problema principale era il versionamento del software, la manutenzione dell'hardware, il backup e il sottoutilizzo dei server. 

Ricordo che il "server" era la parte più costosa dell'"affare" e la più sottoutilizzata: non era raro accedere a un server e vedere che l'applicazione CPU più impegnativa era il testo 3D rotante dello schermo di Windows risparmiatore (non ho mai capito perché fosse il più comune). L'aggiornamento di un'applicazione è stato un vero problema e ha richiesto diversi tecnici per affrontare i diversi problemi che sono emersi. Quindi, naturalmente, la manutenzione è avvenuta solo quando era necessaria o inevitabile. 

Informatica basata sul Web

Quindi il web ha iniziato a entrare in modo significativo nel business, poiché avere un sito web è diventato rapidamente obbligatorio. Quel server sottoutilizzato iniziò ad essere utilizzato dalle aziende più lungimiranti e coraggiose. Le organizzazioni no sapere che erano "coraggiosi", ma lo erano davvero, considerando gli enormi problemi di sicurezza che hanno iniziato a incontrare. I reparti IT iniziano a crescere: server, connessioni internet dedicate, periferiche di rete, rack, cavi, UPS, ecc…

Virtualizzazione del server

Era giunto il momento per un nuovo arrivato: la virtualizzazione. "Invece di avere molti server sottoutilizzati, cosa succederebbe se creassimo una copia virtuale di ogni server e poi li mettessimo tutti in un server fisico?" L'idea era fantastica e, onestamente, è ancora una grande idea oggi.

Ma dal punto di vista del software desktop, tutto era esattamente lo stesso fino a quando non abbiamo iniziato a vedere le applicazioni web entrare in un effettivo utilizzo aziendale. Un'applicazione web è tipicamente divisa in 2 parti: l'interfaccia utente (interfaccia utente) costruita in HTML, CSS e Javascript che esegue la logica nel client e la parte restante che viene eseguita sul lato server.

Qui vediamo l'emergere di un nuovo termine architettonico: stateful. Stateful significa che il server è pienamente consapevole del client e del contesto di ogni transazione. Ogni transazione viene eseguita nel contesto delle transazioni precedenti e la transazione corrente potrebbe essere influenzata da quanto accaduto durante le transazioni precedenti. Per questi motivi, le app stateful utilizzano gli stessi server ogni volta che elaborano una richiesta di un utente. Ecco il problema principale: poiché ogni server ha un numero limitato di client che può servire, il ridimensionamento non è facile. Non puoi semplicemente aggiungere un nuovo server. Invece, è necessario creare una logica come "I clienti con un nome che inizia da A a G vanno al server 1, da G a O vanno al server 2..." e così via. 

Ma "stateful" significa anche che il contesto è memorizzato nel server. A volte il server contiene anche il database, oppure ospita diversi server virtuali sullo stesso hardware.

Come puoi immaginare, se il server cade per qualsiasi motivo... tutto è perduto!

La soluzione a questa sfida presenta il termine opposto: apolidi. Un server senza stato non memorizza il contesto del client, ma esegue solo la richiesta. Il client salta tra i server e un "bilanciamento del carico" che assegna dinamicamente i client a ciascun server, distribuendo il carico. Se un server non funziona, nessun problema! Il "bilanciamento del carico" si interrompe per instradare il traffico al server offline. Se il carico aumenta oltre la capacità del server, è solo questione di aggiungere ulteriori server stateless. Ovviamente è vero anche il contrario: se il numero di client diminuisce, i server possono essere facilmente disattivati. Questo è anche chiamato un 'piscina elastica'.

Dal punto di vista di uno sviluppatore, questo momento storico ha rappresentato un enorme cambiamento. Abbiamo dovuto allontanarci dal desktop, dove tutto era un'unica applicazione in cui tutte le risorse ei componenti del software erano compressi. Tutte le abilità ei problemi erano in una 'singolarità'. Ciò ha introdotto una nuova serie di problemi: server, connessioni, logica di frontend, logica di backend, nuovi linguaggi e astrazione dei dati. Molti hanno cercato di adattare le proprie conoscenze a questo nuovo paradigma, invece di partire da zero e specializzarsi in determinati settori (la gente è ancora oggi bloccata nella singolarità dell'applicazione desktop). Ti imbatti ancora regolarmente in software che puoi chiaramente riconoscere come un "port" di un'applicazione desktop su un'infrastruttura cloud, specialmente quando sei costretto a gestire "installazioni", "file" e "versioni". 

Applicazioni cloud

Siamo nel 2011: Occupy Wall Street è in pieno svolgimento e le "applicazioni cloud" sono finalmente in fase di sviluppo per un "sistema operativo cloud". È importante notare che l'esecuzione del software avveniva ancora nelle macchine virtuali. L'architettura del software era "monolitica", il che significa che ogni server virtuale senza stato aveva una copia del software. L'ottimizzazione massima aveva un componente web e componenti "lavoratori". Il "lavoratore" era il pezzo di "esecuzione" come la creazione di documenti, la compressione di file, gli algoritmi di calcolo e le attività di lunga durata.

Questa architettura non era molto efficiente dal punto di vista dell'utilizzo della CPU e portava a server sovraccarichi o sottoutilizzati. Inoltre, non era efficiente per gli sviluppatori occuparsi di questa architettura monolitica, perché per aggiornare una piccola parte del software era necessario rilasciare l'applicazione su tutti i server, con conseguenti tempi di inattività. L'architettura monolitica è più facile da sviluppare, testare e distribuire... ma difficile da scalare.

Anche in questo caso ci viene presentata un'altra sfida che ha spinto il cloud in avanti: "Come possiamo suddividere un'applicazione monolitica in pezzi più piccoli?"

Microservizi, orchestrator e container, oh mio!

La risposta alle applicazioni cloud monolitiche è "l'orchestrazione con i microservizi". Immaginiamo di suddividere un'applicazione in parti autonome di funzionalità aziendali, seguendo la 'filosofia UNIX: “Fai una cosa e falla bene”. Una volta che la tua applicazione è stata suddivisa in questi pezzi, puoi chiamarli "microservizi". Immagina tutti questi microservizi come pezzi di un gioco Tetris, che uniscono tutti i server virtuali in modo da utilizzare al meglio la CPU, la memoria, la rete e le risorse di archiviazione.

Il 'orchestratore' è davvero quello che 'gioca a Tetris' e le VM si chiamano 'nodi' (o i livelli/tabelloni nel nostro gioco Tetris). Se un nodo si interrompe, l'agente di orchestrazione può creare nuovi nodi o spostare i servizi su uno o più nodi. Se aggiorni un microservizio, l'orchestrator può mantenere attiva la versione precedente, distribuire la nuova versione e quindi interrompere la versione precedente. 

Come puoi immaginare, l'orchestrator con i microservizi è un'architettura molto flessibile e robusta, ma ha un problema... qualcuno deve gestire e mantenere l'orchestrator!

Questo ci ha spinto a reimmaginare la "macchina virtuale". Una macchina virtuale è un server logico che contiene l'intero stack software: driver, sistema operativo e applicazione. Una macchina fisica può ospitare più VM, anche per clienti diversi perché completamente isolate l'una dall'altra. Questo approccio è molto potente, ma non è molto efficiente perché il sistema operativo utilizza molte risorse solo per "esistere" e ogni VM richiede manutenzione come aggiornamenti, patch di sicurezza e configurazioni.

UN Contenitore isola l'applicazione e condivide il sistema operativo tra tutti gli altri contenitori. Invece di virtualizzare l'hardware, come una VM in un container, il sistema operativo viene virtualizzato.

Ok, torniamo all'architettura. Potresti aver già intuito che il miglior candidato per sedersi all'interno di un contenitore è un microservizio. Avendo i microservizi completamente separati, puoi ospitare "microservizi contenuti" di istanze diverse all'interno dello stesso orchestrator.

Senza server

Siamo alla fase finale della nostra lezione di storia, quindi diamo un'occhiata all'ultimo termine: Senza server. Se l'agente di orchestrazione è gestito da qualcun altro, come un provider cloud, lo sviluppo di un'applicazione come KBMax è solo una questione di sviluppo e distribuzione di microservizi containerizzati. I microservizi possono essere ridimensionati, spostati, riavviati e aggiornati automaticamente, senza sprecare risorse aziendali. Ma come viene servita l'applicazione a ciascun cliente?

La prima opzione, Monolocazione, è la più ovvia per un'opzione "on premise" poiché coinvolge un'applicazione dedicata e un archivio e un database dedicati. È un'applicazione cloud con un'istanza di tutto dedicata a ciascun cliente. Questo approccio ha vantaggi e svantaggi: ogni cliente può avere un percorso di aggiornamento, backup e controllo diversi. Tuttavia, diventa rapidamente una perdita di risorse poiché al cliente viene data la falsa impressione di poter controllare il rilascio e la sicurezza.

Viene chiamata l'opzione opposta Multi-locazione: C'è solo un'applicazione e un archivio/database. Tutti i clienti utilizzano la stessa applicazione e i loro dati vengono mantenuti fianco a fianco sullo stesso storage/DB. Questa opzione è molto efficiente e i rilasci del software sono generalmente più frequenti e meno invadenti. Ma c'è un problema. Se sei un'azienda particolarmente attenta alla sicurezza, probabilmente non vorrai che i tuoi dati vengano archiviati insieme a quelli di altre aziende. KBMax risolve questo problema con Locazione ibrida: Un'applicazione, ma uno storage/DB dedicato per ogni cliente.

Choosing a Real CPQ Cloud

Speriamo che questa immersione profonda nella storia del cloud computing ti aiuti a capire un po' di più sui dettagli dell'architettura cloud. Ci piace condividere questa conoscenza con altre aziende, in modo che possano imparare a individuare le applicazioni che non seguono le tendenze più recenti per ottimizzare velocità, sicurezza e accesso.

KBMax is built using the latest cloud architectures following development best practices, ensuring top performance and security for our CPQ cloud customers. We often come across customers who were sold a ‘fake cloud’ by another CPQ vendor, only to realize the grift once it was too late. Look for a future article, where we’ll discuss the differences between types of cloud infrastructures (SaaS, IaaS, PaaS, etc.) and how they can fundamentally change the customer experience and total cost of ownership. Because, yeah, not all ‘clouds’ are the same.