ERP Cloud Native
vs ERP Adaptat la Cloud

Cu acest articol, dorim să clarificăm diferența dintre aplicațiile ERP Cloud Native și aplicațiile adaptate la cloud și motivele pentru care portarea aplicațiilor non-native Cloud în Cloud nu este convenabilă.

ERP CLOUD NATIV ȘI ERP ADAPTAT LA CLOUD:
EXISTĂ O DIFERENȚĂ URIAȘĂ!

Multe aplicații ERP de pe piață funcționează astăzi în Cloud, dar există o caracteristică crucială care deseori trece neobservată și care reprezintăelementul cheie în utilizarea sau nu a numeroaselor avantaje pe care le oferă Cloud-ul.
Diferența constă în modul în care funcționează Cloud-ul, mai exact dacă aplicația a fost concepută nativ pentru Cloud sau dacă a fost adaptată, prin instrumente care gestionează serverul și fac aplicația operațională în Cloud.

Începem prin a spune că majoritatea aplicațiilor ERP existente pe piață, care pretind că funcționează în cloud, sunt de fapt adaptate și nu native în cloud.

Acestea sunt aplicații instalate pe un Server in Cloud, unde prin intermediul tehnologiilor remote , cum ar fi tehnologiile Terminal Services și Remote Desktop Connection, utilizatorul accesează acel Server in Cloud pentru a reda local, pe Clientul propiu, imaginea aplicației care funcționează de fapt pe Server.

Deci aplicația funcționează în Cloud, este afișată în Cloud și apoi imaginea care apare la fiecare miime de secundă este „copiată” în imaginea pe care utilizatorul o are în fața ochilor pe computerul său, cu care cel mult mută mouse-ul și comunică tastele care sunt apăsate de la tastatură, dar capacitatea de procesare a Clientului este practic nulă în acest caz.

Acestea sunt tehnologii depășite, care pot doar să redea local aplicațiile non-native pentru Cloud care funcționează pe un server remote.

PROBLEMELE APLICAȚIILOR ADAPTATE LA CLOUD

Controlul de la distanţă al aplicațiilor in Cloud prezintă câteva probleme importante:

1° problemă de natură economică

Clientul care dorește să controleze de la distanță o aplicație sau o serie de aplicații trebuie să achiziționeze licențe Microsoft, care deține tehnologii de control de la distanţă destul de costisitoare.
Și de fiecare dată când se modifică versiunea sistemului de operare de pe server, aceste licențe trebuie cumpărate din nou. Adică, dacă o companie trece de la Windows Server 2010 la 2012 la 2016 la 2019, de fiecare dată când trece la un release nou al sistemului de server, trebuie să cumpere din nou licențele.
Numărul de licențe este proporțional cu numărul de Client. În cazul în care compania are 10 Client va avea nevoie de 10 licențe, dacă are 100 de Client va avea nevoie de 100 de licențe. Prin urmare, acest tip de activitate devine foarte costisitoare.

Deseori, pentru a evita plata, companiile nu schimbă versiunea și o păstrează pe cea veche, însă, procedând în acest fel, rămân ancorate la o tehnologie veche, chiar și pe partea Server. Acesta este ca un autogol, dacă ținem cont de faptul că, după o vreme, vechile versiuni ale sistemelor de operare sunt scoase din uz, încheind astfel și întreținerea lor. Problema economică în acest caz declanșează alte probleme de natură tehnologică, deoarece prin neactualizarea licențelor, compania rămâne în urmă din punct de vedere tehnologic.

2° problemă de natură tehnică

În controlul de la distanță al aplicației, conexiunea pe care trebuie să o avem între partea Client și partea Server remote in Cloud trebuie să fie o conexiune foarte fiabilă deoarece atunci când conexiunea dispare, chiar și pentru câteva secunde, vom vedea că monitorul se înnegrește sau se blochează. Acest lucru se întâmplă deoarece Serverul nu mai este capabil să copieze imaginea programului în rendering-ul local, deoarece nu mai există conexiunea.

3° problemă de natură tehnică

Prin urmare, am văzut că încercarea de a aduce aplicații non-native Cloud in Cloud prin tehnici remote este foarte costisitoare pentru licențe și este neconvenabilă din cauza unei probleme tehnice.
Există o altă mare problemă, și anume performanțele pe care Serverul trebuie să le dețină pentru a accepta acest tip de tehnologie. Să ne imaginăm o companie cu 50 de stații de lucru: astăzi toate computerele noastre au cel puțin un procesor de 2 GHz, ceea ce reprezintă o putere destul de importantă (+ 8 Giga RAM + un hard disk bun care conține informațiile noastre); acum înmulțim cu 50 de utilizatori și descoperim imediat că nu există un procesor mai mare de 4 GHz.

Un procesor de 4 GHz este frecvența maximă pe care o poate implementa un server. 

Dimensiunea serverului pe care o companie ar trebui să o aibă pe partea Server pentru a implementa acel tip de soluție in Cloud devine foarte costisitoare. Folosirea unui Cloud cu un Server foarte puternic astăzi costă foarte mult. Dimensiunea procesorului și cantitatea de memorie RAM pe partea Server afectează foarte mult costul mașinii virtuale necesare in Cloud pentru a găzdui această soluție.

 

Puterea distribuită a tuturor computerelor locale dintr-o companie este mult mai mare decât a unui server excelent in Cloud, deci este mai bine să exploatați puterea distribuită.

De ce să nu o utilizez și să cumpăr un server in Cloud super puternic care mă costă foarte mult? 

Ajungem astfel la concluzia că o aplicație non-nativă pentru Cloud impune, pentru a fi utilizată în Cloud, costuri Cloud foarte mari.

PERPLEXITATEA - LEGITIMĂ - A COMPANIILOR ÎN CE PRIVEȘTE CLOUD-UL

Cineva se poate întreba: „Dar ce mă determină să aleg in Cloud?” Exact acesta este motivul pentru care multe companii sunt astăzi reticente să se mute in Cloud, deoarece consideră că, pentru a lucra ca înainte, ar trebui să cheltuiască mult mai mult.
Dar de ce? Deoarece consideră așa-numitul mod hibrid, care consistă în a pune compania în Cloud cu aplicațiile vechi.

Subestimează faptul că, dacă Cloud-ul este o tehnologie concepută pentru a fi mai eficienți, este totuși necesar să existe întregul mediu în concordanță cu acest tip de tehnologie, inclusiv aplicațiile care trebuie să fie Cloud Native.
Așa-numitul mod hibrid nu este un mod nativ, este un mod care poate fi obținut, dar costă foarte mult.

Pentru a controla de la distanță in Private Cloud o Mașina Virtuală cu caracteristici și capacități de procesare foarte ridicate, care cresc proporțional cu creșterea numărului de utilizatori.

Un Private Cloud realizat în acest mod este foarte scump, este mult mai scump decât să ai aceleași mașini virtuale pe un server fizic pe care compania îl deține intern și îl întreține.

Deci, o companie face câteva calcule și descoperă că în termen de 3 ani poate cumpăra mașina cu costul închirierii in Cloud.
Dar de ce se întâmplă acest lucru? Acest lucru se întâmplă deoarece aplicațiile care sunt instalate pe acea mașina virtuală nu sunt potrivite pentru Cloud. Acestea sunt adaptate la Cloud, prin tehnologiile Terminal Services.

CUM FUNCȚIONEAZĂ APLICAȚIILE ERP CLOUD NATIVE: O ABORDARE FOARTE DIFERITĂ

Aplicațiile native pentru Cloud funcționează astfel încât să exploateze cu adevărat avantajele Cloud-ului, evitând problemele tehnice și economice analizate până acum.

Aplicația în care operează utilizatorul nu este instalată în Cloud și apoi redată pe computerul utilizatorului, ci direct pe computerul utilizatorului, care poate să comunice, în ceea ce privește tranzacțiile de date și de operații, cu partea Server, instalată în Cloud. În acest fel, se exploatează puterea distribuită a tuturor computerelor locale prezente într-o companie, care, așa cum am văzut, este mult mai mare decât un server excelent în Cloud.

În cazul Fluentis ERP, componenta Server este instalată pe o mașină virtuală în Cloud, în timp ce pe toate computerele companiei este instalată aplicația care comunică cu mediul Server prin intermediul modalității SOA (Service Oriented Architecture).

Deci nu Client Server, ci Service Oriented.

Cu alte cuvinte, aplicația Fluentis instalată pe computerul Clientului comunică cu Server-ul in Cloud, printr-o serie de comenzi pe care aplicația Client le dă Serverului, comenzi care sunt folosite pentru a extrapola datele, a efectua proceduri, a șterge informații, a cere rapoarte, pe scurt, toate activitățile care se desfășoară în mod normal.

Un scenariu foarte diferit de așa-numitele aplicații vechi, în care totul trebuie instalat pe partea Server, altfel nu funcționează.
În cazul nostru, instalăm pe partea Server doar partea esențială a Fluentis, care nu are interfața, ci doar funcțiile.

Înțelegem deci că 'greutatea' lui Fluentis pe server este mult mai mică decât cea a unei aplicații care nu este concepută pentru Cloud.În consecință, pe măsură ce crește numărul de utilizatori, nu avem o creștere proporțională a necesităților și a capacităților de procesare.

O aplicație concepută pentru Cloud distribuie capacitatea de procesare între Server și Client, caz în care clientul este o aplicație care desfășoară activitățile sale, dar comunică cu serverul numai atunci când trebuie să efectueze tranzacții de date și de operații.
În timp ce aplicațiile vechi, care trebuie proiectate continuu între părțile client și server, necesită o capacitate de procesare mult mai mare și o mai mare solicitare a rețelei, acest lucru nu se întâmplă cu o aplicație nativă pentru cloud.
Prin urmare, capacitățile cerute de o aplicație Cloud Native către Virtual Machine pe partea Server sunt mult mai puțin structurate decât cele necesare pentru a rula aplicații de generație veche.

O aplicație de nouă generație este o aplicație care utilizează cu atenție resursele pe partea Server. Este optimizată pentru a utiliza la maxim aplicațiile locale, resursele locale ale computerului, comparativ cu cele remote ale serverului.

Să facem un exemplu: pe smartphone-ul nostru preferăm să folosim un app mai degrabă decât același serviciu prin browser, deoarece app-ul, care este un program instalat pe smartphone-ul nostru, este capabil să utilizeze resursele smartphone-ului nostru într-un mod mult mai eficient decât receptarea lor continuă din rețea.

Descărcăm app-urile deoarece folosim astfel mai mult procesarea locală a smartphone-ului nostru.
Pentru ERP, pe computerele pe care le avem, Fluentis funcționează exact în același mod, exploatând mult resursele locale ale mașinii care îl utilizează.

CLOUD NATIVE APP ȘI IN BROWSER: SĂ CLARIFICĂM

Aplicațiile native pentru cloud pot fi construite în 2 moduri: fie printr-un app instalat local, fie printr-un site web instalat pe partea server.

Fluentis a ales până acum ca stradă principală pe cea a App.

De ce? Pentru că era singura viabilă? Nu. Există software ERP care funcționează printr-un browser. Din păcate, există o confuzie în acest sens: mulți confundă aplicația nativă pentru Cloud cu o aplicație care funcționează într-un browser.

Fluentis NU funcționează ÎN browser, funcționează CA un browser.

Operarea în browser înseamnă invocarea unei aplicații care este instalată pe un server remote printr-un protocol http.

Nu am ales această stradă. De ce?
Deoarece în dezvoltarea versiunii actuale a Fluentis cele două ipoteze principale și obligatorii au fost următoarele: să fie o aplicație CLOUD NATIVE și să poată fi complet GESTIONATĂ DE UN PARTENER.

Protocolul html, ale aplicațiilor care funcționează în browser, este un protocol static. Adică, atunci când am definit o pagină în acel mod, așa o păstrez, nu o pot schimba.

Schimbarea și personalizarea aplicației pentru fiecare client în limbajul html nu este imposibilă, însă menținerea acestor modificări în timp este ceva de neimaginat.
Dacă am fi conceput Fluentis pentru a fi utilizat în browser, una dintre cele 2 condiții fundamentale pe care ne bazăm nu ar fi fost îndeplinită: partenerul nu ar fi putut niciodată să modifice aplicația.

Vedem că astăzi mulți dintre concurenții noștri care au ales în schimb strada browserului au probleme serioase atunci când fac actualizări, deoarece aplicația nu are o interfață flexibilă, ci statică.

CE PREGĂTIM: NOI DEZVOLTĂRI

Lipsa standardelor în protocolul browserului și, mai ales, lipsa flexibilității, ne-a făcut să așteptăm ca aceste standarde să devină comune.

Acum câțiva ani, comunitatea dezvoltatorilor a realizat că nu se mai putea continua în acest fel și s-a reunit pentru a dezvolta protocoale standard care puteau găzdui diferitele aplicații în browser și care erau, de asemenea, flexibile.
Posibilitatea de a avea aplicații foarte flexibile, dar care să funcționeze în browser.
În sfârșit direcția corectă.

Această nouă tehnologie, care se numește Web Assembly, a fost creată acum 2 ani și este încă foarte imatură.

Fluentis a creat și a prezentat, în cadrul evenimentului Synergy 2019, o aplicație numită Fluentis Live Update, creată cu scopul de a testa fiabilitatea tehnologiei Web Assembly. Era proiectul potrivit pentru a fi pionierii unei tehnologii nou-născute. Am văzut multe lacune, am continuat să monitorizăm standardele care au evoluat ulterior și putem spune că această platformă va reprezenta platforma de referință corectă pentru aplicațiile Enterprise (acele aplicații care au caracteristica de a fi extrem de solicitante pentru tranzacții). 

Inovația tehnologică continuă să fie unul dintre punctele forte ale Fluentis. Monitorizăm continuu și experimentăm noi tehnologii pentru a oferi cele mai bune soluții.

Noi dezvoltări în curând.

Contactează-ne pentru mai multe informații

Unul dintre consultanții noștri se va ocupa de cererea ta și îți va răspunde cât mai curând posibil