Pillole di architettura software – 2017

Dal 1998 continuo a ripetere che “il web applicativo è stato un errore di percorso” nella storia dell’informatica. Affermazione direi pesante e drastica, in particolare quando la fai a developer web convinti.

Su questa affermazione si scatenano lunghe discussioni che spesso non portano ad un punto di vista comune.

In questo post provo a spiegare la mia affermazione, partendo da un disegno:

Capture.JPG

Il senso di questo disegno è che da decenni si tenta di spostare le componenti fondamentali di una architettura software per ottenere il massimo vantaggio possibile.

Le prime architetture software diffuse in ambito enterprise sono ovviamente quelle dei mainframe di IBM…sistemi che esistono ancora oggi e che permettono il funzionamento affidabile di moltissime aziende di grandi dimensioni…queste architetture hanno una elaborazione tutta svolta su un server centrale e un dato umero di  terminali stupidi in grado di recepire la pressione dei tasti ed inviarla al server ricevendo in cambio una nuova schermata composta da un numero limitatissimo di byte.

Capture

Riassumendo quindi…pochi byte a video…premo tasti vari e compilo la schermata…invio la schermata al server che la elabora accedendo ai dati e  costruendo una nuova informazione da reinviare al terminale.

Vantaggi:

  • poca banda necessaria per la comunicazione tra server e terminale.
  • molti utenti gestibili.
  • sicurezza garantita al massimo.
  • un solo linguaggo di sviluppo semplice e lineare.

Svantaggi:

  • legati commercialmente alle decisioni di IBM.
  • elevato costo in caso di acquisto hardware.
  • i terminali stupidi hanno dei notevoli limiti in termini grafici e di interazione con periferiche esterne spesso necessarie per svolgere le attività richieste.
  • per formare developer occorreva lavorare per una grande azienda o per IBM.

passano gli anni e arriviamo al 1980 circa con la diffusione dei Personal Computer…qui il server di prima si sposta e si unisce con un terminale a colori meno stupido…

Capture

iniziano a nascere nuove generazioni di sviluppatori e insieme inizia anche la guerra di tool e linguaggi di programmazione. Le aziende potevano finalmente sganciarsi dal monopolio di IBM e giocare sulla competizione tra i vari fornitori per ridurre il costo della gestione IT.

Questa architettura pero’ ha mostrato da subito il limite piu’ grande nell’utilizzo enterprise: la condivisione delle informazioni !!

Rapidamente si decise che occorreva avere i dati in condivisione ed ecco arrivare l’ architettura a due livelli…qui prima oracle e poi microsoft fecero parecchi soldini con i loro database aziendali:

Capture.JPG

I vantaggi di avere un PC, una grafica evoluta, potevo scegliere tra vari linguaggi di programmazione, e avevo risolto il problema del merge delle informazioni che nella precedente architettura faceva venire parecchi mal di testa. Eppure qualcosa non andava…ci si rese conto che al crescere delle postazioni il server che permetteva la condivisione delle informazioni rallentava sempre di piu’.

In aggiunta il traffico di rete aumentava in modo esagerato. Molti scrivevano codice non usando le stored procedure ma richiamando direttamente dalla GUI le istruzioni SQL scatenando ulteriore traffico inutile.

Si provò a tamponare con svariate tecniche lato dbms, ma di fatto il problema era irrisolvibile. Per risolvere il problema occorreva inserire una batteria di server che permettesse di far operare i client non in modalità sempre connessa ma a richiesta, effettuando solo quando serviva le chiamate al dbms.

Siamo entrati nella prima metà degli anni 90…e si inizia a diffondere l’architettura a tre livelli.

Capture

Qui ci si pone il problema di come chiamare il server dalla GUI…si comincia a ragionare su standard di interoperabilità…in questo modo i grandi player oltre a vendere il database potevano produrre un application server che permettesse di ridurre la complessità di sviluppo di un sistema.

Nasce in questo periodo la base di quello che poi diventerà una cosa utilizzata comunemente: i web services.

Realizzare un sistema a 3 livelli con le tecnologie di allora era un inferno, ricordo corba, ricordo tuxedo…a ripensarci ora mi viene da ridere. Per creare un progetto bisognava studiare bene almeno 13 manuali di IBM da 1000 pagine ciascuno. Ci volevano mesi di apprendimento e una memoria particolarissima. Ho visto colleghi impazzire letteralmente !!

Iniziamo a installare i primi modem a 14,4kbps in casa…si naviga tra le informazioni testuali…poi arrivano immagini…una bella mattina mi sveglio e scopro che potevo mettere una combobox reperendo i dati tramite una chiamata ad un pezzo di codice che stava dietro ad un web server.
Osservo attonito e dico…beh semplice…  probabilmente cambierà tutto da oggi…poi faccio refresh della pagina e vedo che rilegge i dati…apro la pagina generata e dentro tutti i valori del database in chiaro…studio il linguaggio html che mi viene definito come standard e scopro che la parola standard ha un significato diverso da quello che avevo sempre immaginato io…ognuno si crea una standard definendolo STANDARD !!

Iniziano ad uscire sul mercato vari browser ognuno che offriva un comportamento diverso a fronte dello stesso pezzo di codice…dopo anni di C++ e di Object Oriented mi ritrovo con una sintassi assurda e preistorica…non era un ritorno ad un passato…era il caos…la masima espressione del “famo come ce pare”.
Inizia la adunanza degli sciamani del web applicativo…ogni mese nuovi nomi, nuovi framework, in un orgia di strumentini e librerie open source mal funzionanti e non documentate prodotte dal vegano di turno.

Capture

Inizia un epoca di devastazione…tutte le grandi aziende decidono che questo è il futuro della loro informatica…si prende una architettura nata per navigare e cercare informazioni  testuali, il tutto in un contenitore blindatissimo che non permetteva a nessuno di accedere alla tua macchina…e si comincia ad usarla per fare una cosa contronatura.

Impossibile spiegare che il pc aveva il mouse, il microfono, la stampante, lo scanner, la smartcard, etc … e che accedervi dal browser non era previsto. Impossibile  spiegare che occorreva disegnare le form in un certo modo altrimenti si sarebbe scaricato mezzo database inutilmente. Tutto inutile…i clienti volevano quello che si faceva con le normali applicazioni desktop negli anni 80…ma volevano farlo con la tecnologia errata….

e così fù !!

Passano altri anni e si comincia a tentare di risolvere il problema di una architettura snaturata mettendo ogni toppa possibile…a cominciare da strani listener che permettevano un colloquio con i server a canale sempre aperto…esattamente il contrario del web…fino a voler accedere all’hardware della macchina saltando ogni controllo del browser…e qui flash, activex, silverlight….il caos applicativo regna sovrano…si continuava a fare cose contronatura…e ormai ci stiamo avvicinando alla nostra epoca corrente…qualcuno inizia a pensare che forse possiamo risolvere il problema con un nuovo linguaggio html in grado di scimmiottare una app desktop collegata ad un application server. Ecco arrivare in pompa magna HTML5 abbinato al suo database locale e ad un insieme selvaggio di framework che  si mettono a chiamare application server prodotti con le piu’ svariate tecnologie…purtroppo tutto questo non ha risolto il problema del browser blindato e della difficoltà di accedere alle periferiche.

Capture

Periferiche che aumentano dal 2005…arrivano smartphone e tablet…si comincia a ragionare con gps, bluetooth, nfc, beacons, wifi, giroscopio, etc.

Tutte cose che un browser ignora beatamente e per design !!

Si comincia anche a capire che su linee dati non sempre velocissime e comunque a pagamento non era salutare far viaggiare tonnellate di byte inutili come nelle architetture da web applicativo.

Si comincia a capire che non si risolveva il problema aprendo dei socket e lasciandoli aperti verso il server.

Ecco finalmente il mondo delle APP

un exe blindato e controllato che si collega al mondo esterno chiamando servizi web solo quando servono e ricevendo solo il necessario. Accedere alle periferiche non è piu’ un problema, scaricare software non garantito non è piu’ un problema, massimizzare le performance non è piu’ un problema…e le app iniziano a diffondersi…android, ios , windows mobile…tre sistemi diversi…tre linguaggi di programmazione differenti… costi triplicati da aggiungere spesso anche ad un sito web per alcune funzioni da consegnare ai dipendenti che operano da pc in ufficio.

A questo aggiungerei anche un enorme platea di developer da web applicativo che devono essere usati nella migrazione alle app. Di nuovo sciamani che tentano di convincersi che tutto è possibile con un sito web responsive e qualche framework in grado di bypassare la sicurezza del browser. Poi si rendono conto che non funziona, come in fin dei conti non funziona e non ha mai funzionato sui pc.

Entriamo quindi nell’era delle app alle quali occorre necessariamente ragionare abbinando un cloud, l’unico in grado di garantire un funzionamento al crescere degli utenti senza dover investire da subito una montagna di soldi.

Capture

Ora siamo nella fase di evoluzione di questo paradigma…sicuramente risolve molto dei problemi del web applicativo. Ora i passi da effettuare sono:

  • Uniformare e standardizzare i vari cloud ( azure, amazon, google ). In parte i servizi REST stanno aiutando, ma occorre permettere un passaggio della app da un cloud all’altro senza dover riscrivere nulla.
  • Un solo linguaggio nativo per tutti i sistemi ( ricordate i tempi del COBOL ? )
  • Integrare il web con le app e le app con il web ( ci stanno lavorando )
  • Permettere l’esecuzione cross platform delle app ( compilazione in real time lato server ? )

I vantaggi di questa architettura sono moltissimi ma occorre scegliere la giusta tecnologia che al  momento non è ancora stradefinita.

Per chiudere esiste una tendenza futura che potrebbe riportarci ai tempi del mainframe.

Si tratta di eseguire le app in remoto sul cloud, fornendo ai vari dispositivi la giusta interfaccia in termini di risoluzione e dimensione e leggendo le info delle periferiche da remoto.

Capture

Nell’attesa di vedere finalmente una soluzione al problema del web applicativo…

 

Annunci

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...