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.
Compila il form per richiedere informazioni
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
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.
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.
Distribuzione della capacità elaborativa
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.
Attento utilizzo delle risorse lato server
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.
ERP Cloud Nativo via APP o Browser?: Meglio entrambe le interfacce
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 ERP è disponibile in entrambe le modalità.
Oggi gli utenti richiedono sempre più la possibilità di accedere in modo dinamico all’applicativo, utilizzando postazioni differenti ed interfacciandosi da diversi dispositivi.
Fluentis ERP permette la massima flessibilità offrendo un’interfaccia centralizzata fruibile poi in diverse modalità.
- Versione Desktop: l’interfaccia tipica, basata su una workstation WPF e installata sui PC-Client come applicativo distribuito Client-Server.
- Versione APP (Android & iOS): per chi desidera accedere ai dati da smart device ovunque e in qualunque momento.
- Versione Web: per chi desidera utilizzare l’applicazione senza installare in locale nessun componente. Adatto anche ad utenti MAC e Linux.
.
Vuoi saperne di più sulle soluzioni in Cloud di Fluentis ERP?
Scopri cosa può fare Fluentis ERP
per la tua azienda
Prova gratuita 15 giorni | Nessun rinnovo automatico | Accesso immediato
Contattaci per maggiori informazioni