Hace 26 años, en 1995, tuvo lugar un evento que revolucionó el incipiente sector del desarrollo web: el nacimiento de la pila LAMP; es decir, del uso combinado de sistemas Linux equipados con el servidor Apache, bases de datos MySQL y el intérprete de PHP.
El problema es que exigía un gran uso de memoria y CPU en una época en que ambos recursos se medían aún en megahercios y megabytes. Ben Johnson, creador de Litestream, rememora en su blog esta época y la evolución posterior del sector, y se hace a raíz de eso una pregunta:
"Pero, si la Ley de Moore nos prometió un futuro mejor en el que las computadoras se volvían exponencialmente más rápidas [...], ¿por qué necesitamos más computadoras que nunca?".
La complejidad empieza a crecer
De lo que Johnson habla es del surgimiento de la arquitectura n-tier, que llevó a la separación física de niveles entre cliente, servidor lógico y servidor de datos, en una búsqueda de que la lentitud de procesamiento de PHP o Ruby no repercutiera sobre el rendimiento de las bases de datos SQL.
Esta arquitectura de 'n' niveles suena simple al principio, pero contiene una complejidad oculta:
"En una sola máquina, podríamos a nuestro servidor memoria caché para acelerar las solicitudes, pero ahora los datos se comparten entre varias máquinas, por lo que debemos agregar un servidor memcached o Redis para compartir datos almacenados en caché".
"Los servidores de bases de datos se sobrecargan fácilmente cuando se dan numerosas conexiones simultáneas, por lo que tenemos que agregar servicios intermedios como PgBouncer".
"Si tenemos eventos en nuestro sistema que deben ser comunicados a todos nuestros nodos, entonces necesitamos un clúster de máquinas Kafka".
En definitiva, "nos encontramos con toda una flota de máquinas a administrar".
Y llegan la virtualización y los contenedores
Pero, mientras todo el mundo perdía los nervios por culpa de la amenaza del 'Efecto 2000', se venía fraguando una nueva revolución en la industria de la arquitectura web: la virtualización.
Según relata Lawrence Edmonson, responsable de ingeniería de Squarespace, "la virtualización resolvió muchos de los problemas de escalado de la burbuja de puntocom y dio origen a una unidad de negocio completamente nueva de Amazon (Amazon Web Services) en 2006".
Así, fueron llegando diferentes tecnologías de virtualización (VMWare, Virtualbox) o complementarias a la misma (como Chef y Vagrant). Luego, aparecieron los contenedores, como Docker y Kubernetes.
Todas ellas son herramientas útiles que han hecho avanzar el desarrollo web, pero Johnson señala el aspecto negativo de las mismas:
"Todas estas capas nos ralentizan de nuestro trabajo de escribir sistemas de software que resuelvan problemas reales".
"Lo que comenzó como un simple sistema de software de dos niveles se ha convertido en un gigante con una docena de capas de complejidad".
A eso se añade otro problema, precisamente uno que ha ayudado al auge de Kubernetes... la persecución del tiempo de actividad como un objetivo en sí mismo:
"Soluciones como Kubernetes promocionan las ventajas de las implementaciones sin tiempo de inactividad, pero ignoran que su complejidad inherente causa problemas de disponibilidad".
La complejidad ha generado complejidad
Y lo resume así: "La complejidad engendra complejidad". Un usuario que comentaba el post de Johnson en Hacker News profundiza en esa idea:
"Veo que la complejidad se debe a la replicación de los numerosos servicios del sistema operativo que requieren las aplicaciones. Como resultado, un ecosistema en contenedores sólo reinventar la rueda pero complicándola aún más.
Y esto no hace sino extenderse como un cáncer: las infraestructuras no-Kubernetes son ahora 'abandonware'".
La conclusión es que una serie de decisiones sobre la arquitectura tecnológica tomadas a lo largo del último cuarto de siglo explican que, pese al descomunal aumento de la potencia informática, nuestras aplicaciones requieran de más máquinas detrás que nunca para funcionar.
Ver 23 comentarios