A volte l'accelerazione delle applicazioni per le wide-area network (WAN) inizia sulla workstation del programmatore.
I tecnici di rete possono infatti prevenire la latenza delle applicazioni WAN grazie alla collaborazione con i team di sviluppo software.
"Il gruppo delle network operation dovrebbe avere un team che assiste gli sviluppatori sul versante delle prestazioni e che gli fornisca, per esempio, dei tool di emulazione dei ritardi sulle WAN, in modo che possano vedere cosa accadrà - ha affermato Eric Siegel, analista senior di Burton Group -. Prima di essere usato nei sistemi di produzione, un nuovo programma dovrebbe superare la fase di testing in laboratorio con una latenza realistica e anche su alcune path reali attraverso la rete aziendale".
Finché i gruppi che si occupano dello sviluppo di applicazioni e delle reti operano con una mentalità separata e monolitica, una rete WAN rischia di continuare a mostrare una certa latenza nelle applicazioni.
"Chi ha il compito di gestire la rete non riesce a capire quanto siano distanti i programmatori dall'hardware e dalla rete stessa - ha detto Siegel -. E quindi, dal punto di vista del programmatore, è il team di rete che commette gli errori. Per contro, chi si occupa del network ritiene che le responsabilità di malfunzionamenti siano tutte dei programmatori".
All'interno di un ambiente di sviluppo, anche le applicazioni "più inclini al dialogo" funzioneranno senza problemi su una rete locale (LAN) e ciò potrebbe dare ai programmatori l'impressione che tali applicazioni siano in grado di girare allo stesso modo su tutta la WAN. Gli amministratori di rete devono spingere i team di programmazione a effettuare controlli reali, ha detto Siegel, che ha scritto a proposito il testo Designing Applications for the WAN.
Ciò significa portare le applicazioni fuori dal laboratorio di prova e metterle in alcune tipiche macchine utente - come per esempio un piccolo branch office, un notebook remoto su Internet o una filiale di grandi dimensioni - per vedere come si comportano le applicazioni quando passano attraverso firewall, cache, ottimizzatori e VPN.
Affinché questo tipo di collaborazione abbia luogo è necessario un approccio "top-down" che coinvolge il CIO, ha dichiarato Jim Metzler, vice presidente di Ashton, Metzler & Associates.
"Dobbiamo cambiare quell'atteggiamento che obbliga a investire parte del tempo a proteggere il mio gruppo dalle frecce scagliate dagli altri gruppi - ha sostenuto -. Un cambiamento culturale può essere attuato solo se a volerlo sono prima di tutto i vertici. L'amministratore di rete dovrebbe essere più affabile nei confronti dell'amministratore di sistema".
Bloccare la latenza delle applicazioni prima che si verifichi
Quando progettano le applicazioni, i programmatori usano il middleware, che "nasconde la complessità e i dettagli dell'ambiente informatico", e questo permette loro di "non aver niente a che fare con i bit", ha detto Siegel. Questo, però, comporta una serie di inconvenienti, come per esempio il fatto che spesso comprednono appieno che le loro chiamate SQL sono strettamente connesse o che un'applicazione effettua un eccessivo numero di chiamate.
"Si potrebbero rendere necessari duecento tragitti di andata e ritorno per eseguire una transazione. Se questo avvenisse su una LAN e si avesse un ritardo di uno o due millesimi di secondo, nessuno lo noterebbe - ha sottolineato Metzler -. Ma prendete un'applicazione ed fatela girare su una WAN: avrete un ritardo che va dai 10 ai 20 secondi. E questo non è accettabile".
Gli amministratori di rete dovrebbero sollecitare i gruppi di programmatori a usare tool per il dye-tracing per verificare che le applicazioni siano ottimizzate per la WAN. "E questo durante lo sviluppo non dopo l'esecuzione sui sistemi di produzione", ha detto Siegel.
"La diagnosi dei problemi durante la produzione spesso richiede il monitoraggio dello stato di una singola transazione che passa attraverso molti processori differenti e interagisce con i server remoti - ha scritto Siegel nel suo testo -. Per fare ciò, molte organizzazioni chiedono al gruppo di rete di scaricare i dati grezzi e di aiutare i programmatori a interpretare il flusso dei messaggi".
Poiché i programmatori e il personale in rete parlano linguaggi tecnici differenti, il processo è spesso infruttuoso, ha precisato Siegel. In passato, vendor come Quest Software e AmberPoint hanno realizzato tool per la tracciabilità delle transazioni da usare sui mainframe. Tali tool sono oggi disponibili anche per i sistemi di computer distribuiti, ha aggiunto Siegel.
"Associano una singola transazione con tutte le chiamate che essa fa al sistema operativo e al database e possono contrassegnare ogni singola transazione, come questa si sposta da un server all'altro - ha scritto Siegel. I tool possono tracciare un sottoinsieme delle transazioni oppure tutte le transazioni che entrano nel sistema".
Le prestazioni delle applicazioni su una rete WAN possono talvolta anche essere stabilite durante lo sviluppo se i programmatori conoscono i giusti parametri da inserire nei rispettivi middleware, "un ambito in cui gli amministratori di rete possono anche svolgere un ruolo fondamentale", ha evidenziato Siegel. Per diagnosticare problemi alle applicazioni può essere utilizzato anche lo sniffing di rete.
"I programmatori non hanno questi tool nei loro sistemi di produzione, perché chi si occupa delle operation non li vuole eseguire tutte le volte - ha sostenuto Siegel. "Eppure, questo è esattamente ciò che ci servirebbe".
Anche se non tutte le applicazioni sono destinate a fallire in una rete WAN, è molto probabile che alcune abbiano dei problemi, ha detto Siegel. "Soprattutto quelle connessi alla limitata ampiezza di banda, all'alta latenza o ai collegamenti ad alto errore - ha detto -. Lo streaming video è un chiaro esempio, così come una qualsiasi grafica con continui aggiornamenti ".
Nel caso delle applicazioni commerciali che ottengono scarsi risultati sulla WAN, l'unica soluzione è un dispositivo di ottimizzazione delle WAN stessa, dicono gli analisti. Le grandi imprese con più possibilità di spesa possono decidere di investire utilizzando un MPLS per attenuare la latenza di Internet attraverso la rete WAN, mentre le organizzazioni più piccole che non possono permettersi un MPLS potrebbero acquistare un servizio di application delivery.
Ma per nella maggior parte dei casi, gli amministratori di rete devono assicurarsi che i programmatori in-house comprendano le loro preoccupazioni mentre stanno sviluppando nuove applicazioni "friendly" WAN.
