Cloud Native ERP
vs ERP adattato al Cloud

Con questo articolo vogliamo fare chiarezza sulla differenza tra applicazioni ERP Cloud native e applicazioni adattate al Cloud e sui motivi per cui portare le applicazioni non native per il Cloud all’interno del Cloud non conviene affatto.

ERP CLOUD NATIVE E ERP ADATTATO AL CLOUD:
C’È UN’ENORME DIFFERENZA!

Molte applicazioni gestionali sul mercato oggi operano in Cloud, ma c’è una caratteristica cruciale che spesso passa inosservata e costituisce invece l’elemento fondamentale affinché possano essere sfruttati o meno i molti vantaggi che il Cloud offre.
La differenza sta nella modalità di funzionamento del Cloud, ovvero se l’applicazione è stata concepita in modo nativo per il Cloud o se è stata piuttosto adattata, attraverso degli strumenti che riescono a serverizzare e rendere operativa l’applicazione in Cloud, anche se per il Cloud non è concepita.

Iniziamo dicendo che la più parte delle applicazioni ERP esistenti nel mercato che dichiarano di operare in Cloud sono in realtà adattate e non Cloud native.

Ovvero si tratta di applicazioni installate in un Server in Cloud, dove attraverso tecnologie di remotizzazione come le tecnologie di Terminal Services e Remote Desktop Connection l’utente accede a quel Server in Cloud e renderizza in locale sul suo Client l’immagine dell’applicazione che in verità funziona nel Server.

Quindi l’applicazione funziona nel Cloud, si visualizza nel Cloud e dopodichè l’immagine che avviene in ogni millesimo di secondo viene “copiata” nell’immagine che l’utente ha davanti agli occhi nel suo pc. Di fatto tutta l’elaborazione non la fa il suo pc, il suo pc al massimo fa muovere il mouse e comunica i tasti che vengono pigiati nella tastiera, ma la capacità elaborativa del Client è praticamente nulla in questo caso.

Si tratta di tecnologie vecchie e ormai superate, che non possono far altro che renderizzare in locale le applicazioni non native per il Cloud fatte funzionare in un server remoto.

PROBLEMI DELLE APPLICAZIONI ADATTATE AL CLOUD

La remotizzazione delle applicazioni in Cloud presenta alcuni importanti problemi:

1° problema di natura economica

Il Cliente che vuole remotizzare un’applicazione o una serie di applicazioni deve acquistare delle licenze Microsoft, che dispone delle tecnologie di remotizzazione, abbastanza costose.
E ogni volta che cambia la versione del Sistema Operativo sul Server, queste licenze vanno riacquistate. Ovvero, se un’azienda passa da Windows Server 2010 al 2012 al 2016 al 2019, ogni volta che passa di release del Server deve riacquistare le licenze.
Il numero delle licenze è proporzionale al numero dei Client, quindi se l’azienda ha 10 client avrà bisogno di 10 licenze, se ha 100 client serviranno 100 licenze. Diventa quindi davvero oneroso questo tipo di attività.

Spesso, per evitare di pagare, le aziende non passano di versione e tengono una versione più vecchia, ma facendo così rimangono ancorate a una tecnologia vecchia, anche della parte Server. Si tratta un po’ di un auto goal, se teniamo presente che poi dopo un pò le versioni vecchie dei sistemi operativi vengono dismesse, quindi si esce anche dalla manutenzione. Il problema economico in questo caso innesca altri problemi di natura tecnologica, perché non andando ad aggiornare le licenze l’azienda rimane tecnologicamente arretrata.

2° problema di natura tecnica

Nella remotizzazione dell’applicazione, la connessione che devo avere tra la mia parte Client e la parte Server remota in Cloud deve essere una connessione molto affidabile perché nel momento in cui la connessione svanisce, venendo anche per pochi secondi a mancare, vedrò che il mio monitor diventa nero o si frizza. Questo avviene perché il Server non è più in grado di copiare l’immagine del mio programma nel mio renderizzatore locale, perché non c’è più la connessione.

3° problema di natura tecnica

Abbiamo visto quindi che cercare di portare le applicazioni non native per il Cloud all’interno del Cloud attraverso tecniche di remotizzazione è molto costoso per le licenze ed è sconveniente per un problema di natura tecnica.
Esiste un altro grande problema, ovvero le performance che il Server deve avere per poter contemplare questo tipo di tecnologia. Immaginiamo un’azienda con 50 postazioni di lavoro: oggi tutti i nostri pc hanno un processore perlomeno da 2 GHz, che è una potenza abbastanza importante (+ 8 Giga di RAM + un bel hard disk che contiene le nostre informazioni), ora moltiplichiamo per 50 utenti, scopriremo presto che non esiste nessun processore più grande di 4GHz.

Un processore di 4GHz è il massimo della frequenza che un Server può implementare. 

Il dimensionamento del Server che un’azienda dovrebbe avere sulla parte Server per implementare in Cloud quel tipo di soluzione, diventa molto molto molto dispendioso. Utilizzare un Cloud con un Server molto potente oggi costa tantissimo, costa un’enormità. La dimensione della CPU e la quantità di RAM sul lato Server incide molto sul costo della Virtual Machine necessaria sul Cloud per ospitare questa soluzione.

 

La potenza distribuita di tutti i pc locali presenti in un’azienda è molto più grande di un ottimo server presente nel Cloud, quindi conviene sfruttare la potenza distribuita.

Perché dovrei renderla inutilizzata e acquistare un Server super potente in Cloud che mi costa tantissimo? 

Capiamo così che un’applicazione non nativa per il Cloud impone, per essere utilizzata in Cloud, dei costi Cloud molto elevati.

LA – LEGITTIMA – PERPLESSITÀ DELLE AZIENDE VERSO IL CLOUD

A questo punto uno si chiederà: “Ma chi me lo fa fare di andare in Cloud?” Ed è esattamente questo il motivo per cui molte aziende oggi sono reticenti a spostarsi in Cloud, perché scoprono che per poter lavorare come prima dovrebbero spendere molto di più.
Ma perché? Perché considerano una modalità cosiddetta ibrida, che consiste nel mettere l’azienda in Cloud con le applicazioni vecchie.

Sottovalutano il fatto che, se il Cloud è una tecnologia concepita per essere più efficienti, è necessario però avere tutto l’ambiente in linea con questo tipo di tecnologia, comprese le applicazioni che devono essere Cloud native.
La cosiddetta modalità ibrida non è una modalità nativa, è una modalità che si può ottenere ma costa tanto.

Per remotizzare in Private Cloud un’applicazione non concepita per il Cloud dovrò acquistare una Macchina Virtuale con delle caratteristiche e delle capacità elaborative molto elevate, che crescono proporzionalmente con l’aumentare del numero di utenti.

Un Private Cloud fatto in questo modo è molto costoso, è molto più costoso che avere le stesse Macchine Virtuali presso un Server fisico che l’azienda ha al suo interno e che manutiene.

Ecco che un’azienda dotata di un minimo di raziocinio fa 2 conti e scopre che nell’arco di 3 anni può comperarsi la Macchina con il costo del noleggio in Cloud.
Ma perché succede questo? Questo succede perché le applicazioni che si vanno ad installare in quella Virtual Machine non sono adatte al Cloud. Sono adattate al Cloud, attraverso le tecnologie di Terminal Services.

COME OPERANO LE APPLICAZIONI ERP CLOUD NATIVE: UN APPROCCIO MOLTO DIVERSO

Le applicazioni native per il Cloud operano in modo da sfruttare realmente i vantaggi del Cloud, evitando i problemi tecnici ed economici visti finora.

L’applicazione dove l’utente opera non viene installata nel Cloud per poi essere renderizzata nel pc dell’utente, ma direttamente nel pc dell’utente, che è in grado di colloquiare in termini di transizione di dati e di funzionalità con la parte Server, installata nel Cloud. Si sfrutta così la potenza distribuita di tutti i pc locali presenti in un’azienda, che come abbiamo visto è molto più grande di un ottimo server presente nel Cloud.

Nel caso di Fluentis ERP, la componente Server viene installata in una Virtual Machine presente in Cloud, mentre su tutti i pc dell’azienda si installa l’applicazione che comunica con l’ambiente Server attraverso quella che si definisce una modalità SOA (Service Oriented Architecture).

Non più Client Server quindi, ma Service Oriented.

In altre parole l’applicazione Fluentis installata sul PC del Cliente comunica con il Server in Cloud, attraverso una serie di comandi che l’applicazione Client dà alla parte Server, i cui comandi servono per estrapolare i dati, eseguire delle procedure, cancellare delle informazioni, richiedere dei report, insomma tutte le attività che vengono normalmente svolte.

Uno scenario molto diverso dalle applicazioni cosiddette vecchie, in cui tutto deve essere installato nella parte Server, altrimenti non funzionano.
Nel nostro caso installiamo nella parte Server solo il “cuore” di Fluentis, che non ha nessuna interfaccia, ma solo le funzionalità.

Capiamo quindi che il peso di Fluentis sul Server è molto molto ma molto più ridotto rispetto a quello di un’applicazione non concepita per il Cloud. Di conseguenza all’aumentare del numero di utenti non abbiamo un proporzionale aumento delle necessità e delle capacità elaborative.

Un’applicazione concepita per il Cloud distribuisce la capacità elaborativa tra Server e Client, dove il Client è un’applicazione che svolge le sue attività ma comunica con il Server solo quando deve fare delle transazioni di dati e di operazioni.
Mentre le applicazioni vecchie che devono essere continuamente disegnate tra la parte Client e la parte Server richiedono una capacità elaborativa molto più grande e una sofferenza maggiore della rete, questo non succede con un’applicazione nativa per il Cloud.
Ecco quindi che le capacità richieste da un’applicazione Cloud native alla Virtual Machine sul lato Server sono molto meno strutturate rispetto a quelle necessarie per far funzionare applicazioni di vecchia generazione.

Un’applicazione di nuova generazione è un’applicazione che fa un attento utilizzo delle risorse lato Server. È ottimizzata per utilizzare al massimo le applicazioni locali, le risorse locali del pc, rispetto a quelle remote del Server.

Facciamo un esempio: nel nostro smartphone preferiamo utilizzare un’app piuttosto che lo stesso servizio via browser, perché l’app, che è un programma installato sul nostro smartphone, riesce ad utilizzare le risorse del nostro smartphone in un modo molto più efficiente rispetto a doverle ricevere continuamente dalla rete.

Scarichiamo le app perché sfruttiamo così di più l’elaborazione locale del nostro smartphone.
Per il gestionale, nei pc che abbiamo, Fluentis opera esattamente allo stesso modo, sfruttando molto le risorse locali della Macchina che lo sta utilizzando.

CLOUD NATIVE APP E IN BROWSER: FACCIAMO CHIAREZZA

Le applicazioni native per il Cloud possono essere costruite in 2 modalità: o tramite un’app installata localmente o tramite un sito web installato nella parte server.

Fluentis finora ha scelto come strada prioritaria la strada dell’app.

Perché? Perché era l’unica percorribile? No. Ci sono dei gestionali che operano attraverso un browser. Esiste purtroppo però confusione al riguardo: molti confondono l’applicazione nativa per il Cloud con un’applicazione che opera in un browser rispetto a un’applicazione che non opera in un browser.

Fluentis NON opera IN un browser, opera COME un browser.

Operare in un browser significa invocare un’applicazione che è installata in un Server remoto attraverso un protocollo http.

Noi non abbiamo scelto questa strada. Perché?
Perché nello sviluppo dell’attuale versione di Fluentis i 2 principali e inderogabili presupposti erano questi: che fosse un’applicazione CLOUD NATIVE e che potesse essere completamente GESTIBILE DA UN PARTNER.

Il protocollo html caratterizzato da tutte le applicazioni che operano in un browser, è un protocollo statico. Ovvero, quando ho definito una pagina in quel modo, così me la tengo, non posso cambiarla.

Modificare e personalizzare l’applicazione per ogni cliente nel linguaggio html non è impossibile, è possibile, ma manutenere queste modifiche nel tempo è qualcosa di impensabile.
Se avessimo concepito Fluentis come fruibile attraverso browser, uno dei 2 fondamenti su cui non accettiamo compromessi sarebbe venuto meno: il Partner non sarebbe mai stato in grado di cambiare e modificare l’applicazione.

Infatti vediamo che oggi molti dei nostri competitor che hanno scelto invece la strada del browser hanno seri problemi quando fanno gli aggiornamenti, perché l’applicazione non ha un’interfaccia flessibile, ma un’interfaccia statica.

COSA BOLLE IN PENTOLA: NUOVI SVILUPPI

La mancanza di standard nel protocollo del browser e soprattutto la mancanza di flessibilità, ci ha sempre posto nella condizione di attendere che questi standard arrivassero a diventare comuni.

Circa un paio d’anni fa la comunità di sviluppatori si è resa conto che la strada non poteva più andare avanti in questo modo e si è riunita per sviluppare dei protocolli standard che fossero in grado di ospitare nel browser le varie applicazioni e che fossero anche flessibili.
Poter avere delle applicazioni molto flessibili ma anche operanti nel browser.
Finalmente la direzione corretta.

Questa nuova tecnologia, che si chiama Web Assembly, è nata solo 2 anni fa ed è ancora molto immatura.

Fluentis ha realizzato e presentato al Synergy 2019 un’applicazione chiamata Fluentis Live Update, realizzata con lo scopo di testare l’affidabilità della tecnologia Web Assembly. Era il progetto giusto per essere pionieri di una tecnologia appena nata. Abbiamo visto molte mancanze, abbiamo continuato a monitorare gli standard che da allora si sono ulteriormente evoluti e ragionevolmente possiamo dire che questa piattaforma potrà rappresentare la piattaforma di riferimento corretta per le applicazioni di tipo Enterprise (quelle applicazioni che hanno la caratteristica di essere estremamente demanding in termini di transazioni). 

Fluentis fa dell’innovazione tecnologica uno dei suoi punti maggiori di forza, monitoriamo e sperimentiamo continuamente le nuove tecnologie per offrire le soluzioni più performanti.

A presto nuovi sviluppi.

CONTATTACI PER AVERE MAGGIORI INFORMAZIONI

Un nostro consulente prenderà in carico la tua richiesta e ti risponderà al più presto








Ho preso visione della Privacy Policy e acconsento
al trattamento dei miei dati personali ai sensi dell’art. 13 Reg. 679/16