Cando eu aprendín a programar, as empresas pequenas e algúns particulares tiñamos “o ordenador” no que funcionaba “o programa”. As empresas grandes tamén tiñan “o ordenador”, malia o chamaren “a computadora” para que soara máis importante, que era un mainframe xigante cunha morea de terminais conectados para que todas as sucursais o puideran usar.
Uns anos despois, a cousa mudou un pouco: as empresas tiñan “a rede” con “o servidor” e “os ordenadores”. “O programa” funcionaba nos ordenadores, pero o servidor termaba dos datos. Entre tanto, as empresas grandes tiñan “os servidores”, que estaban todos xuntos nun CPD a carón de “a computadora” (o comercial de IBM aínda tiña cartos para pagar as merendas).
Pasou máis tempo, e algunhas empresas xa non tiñan “o ordenador” ou “o servidor” ou incluso “os servidores”, senón que tiñan “a nube”: varias moreas de servidores repartidos polo mundo adiante. O programa xa non era “o programa”, senón que era “unha aplicación” que estaba distribuída entre varios servidores que podían pertencer a distintas moreas.
Pouco tempo despois, todos os demais (a xente, as empresas pequenas e as empresas grandes) comezamos a usar “a nube”, a facer e usar aplicacións altamente espalladas, e a nos desfacer de “os servidores” (“a computadora” segue aí, que o comercial de IBM xa non paga as merendas pero en 2008 quixemos reescribir o seu software en Java e non houbo maneira).
E, con todos eses cambios, “a aplicación” non nos dá a impresión de ir máis rápido que “o programa” que usabamos hai trinta anos. A ben seguro: os ordenadores son máis rápidos e máis potentes, os gráficos son mellores, a base de datos ten máis capacidade e é máis barata de contratar e manter. Pero non vai máis rápida.
Un dos motivos polos que temos esta impresión é a velocidade da luz.
Cando tiñamos o ordenador co programa, todo cabía nunha caixa que tiñamos no escritorio. A RAM estaba a menos de quince centímetros da CPU e o disco duro estaba conectado cun cable de trinta centímetros. Cando o programa necesitaba acceder a un dato que estaba na RAM, o acceso á memoria levaba un microsegundo. Se precisaba de acceder ao disco duro, podía tardar uns 20 milisegundos.
Coa nube, o noso ordenador que está en Boqueixón conéctase a un servidor web en Londres (20 milisegundos de latencia), que fala cun servidor de aplicacións en Houston (55 ms), que se conecta a un servidor de datos que está noutro edificio (1 ms), que recolle os datos dun servidor que está en Os Ánxeles (non en Brión senón en California; 20 ms) e que pertence a outra empresa. Cando a aplicación precisa de acceder a un dato na nube, a petición vai de servidor en servidor e a resposta fai o mesmo camiño pero de volta, tardando 192 milisegundos en total.
Con esa diferenza de latencia (20 ms contra 192) non é de estrañar que a nova aplicación nos pareza máis lenta, especialmente porque hai moita xente que programa eses sistemas altamente espallados como se todo estivera metido nunha caixa enriba do noso escritorio.
Non vos vou dicir que volvades todos a facer programas como nos anos 90 pero si que, cando se escriben aplicacións distribuídas, hai que ter en conta a distancia e a latencia, que a velocidade da luz é constante e moito menor do que un pensa.
As comunicacións máis rápidas ocorren entre dous compoñentes que residen no mesmo proceso. Se non podedes, tentade que estean na mesma máquina virtual; se non, por orde de preferencia, no mesmo ordenador, na mesma rede, no mesmo CPD, na mesma cidade, no mesmo país ou no mesmo continente.
E se non podedes evitar as comunicacións de longa distancia, mirade de poñer unha caché ou unha réplica local, que presta moito.
A ilustración desta Folla é unha composición de varias láminas de “Le Larousse pour tous”.
1 comentario