Bueno, hace tiempo que no escribo un post. Asi que bien podía hablar de UNIX con todo lo que ya he hablado o dedicarme a hacer amigos, pero he preferido lo primero por eso de que me ahorro el tocho de argumentación.

A lo que venía a hablar aquí y hoy es sobre escalabilidad LAMP. Donde LAMP es obviamente Linux-Apache-MySQL-PHP (no, no voy a hablar de como escalar lampáras… aunque suena bien, sin duda).

Normalmente, cuando uno planifica un pequeño proyecto (wrrong, los pequeños proyectos carecen de planificación) no tiene vistas de futuro… Aunque si ahora alguien dice morir de éxito no sería nuevo (eso sí, sonaría irónico).

La planificación suele ser la misma, un servidor guarro que actua de servidor MySQL, Apache, etc. y la mayoría de las veces en un shared. Cuanto eso no cabe ahí, se mueve a un dedicado. Pero cuando el dedicado más caro se queda pequeño o no termina de ser rentables hay que buscar salida.

Como todo depende:

• Si tiene una gran cantidad de ficheros, tocaría externalizar bien el alojamiento (S3) o bien utilizar servidores de gama baja para alojar ficheros. Esto puede salir más caro que S3 debido a los costes de ubicación geográfica y a los costes de mantenimiento.
• Si tiene un gran consumo de CPU (ciclos), lo más probable es que se trate de una aplicación web (leerse como Meebo, por dar un ejemplo que no me vienen a la mente). Entonces se puede usar E3, aún con el riesgo de volverse demasiado caro.
• Si en los casos anteriores se decide uno por la opción de own-way, lo más económico es comprar servidores a precio de coste (por ejemplo, DELL en forma de blade) con configuraciones óptimas para cada parte de la web (las configuraciones entre filer, servidor web y backend sql varían, obviamente: en el filer y en el servidor SQL hay que evitar cuellos de botella I/O por lo que se necesitan discos rápidos y con buen rendimiento. Leerse como RAID 0 y su gran riesgo, con discos con RPM altos (o SSD, quién sabe, pero ya no RAID) o mejor aún, RAID 0+1, todo seguro y con gran rendimiento.
• Cuando la aplicación/proyecto/otros crece mucho (ver demasiado) se puede pensar en hacer load-balancing entre filers según enrutado de paquetes, con cosas del tipo RTM (real-time-monitoring) para saber que disco está más descargado. Recuerda: viva NFS y el coder que le parió.
• Los servidores Apache pueden “tirar” del filer: siempre y cuando no contengan archivos de grandes tamaños, suele ser la solución ideal. Para archivos grandes, externalizarlos en servidores de bajo coste con unidades de disco amplias, y con servidores http ligeros (ie: lighttpd).
• Se hace load-balancing mediante Squid que a su vez cachea peticiones, en este caso es recomendable redundancia, prescindir de este punto si no es posible usar n+1. No olvidarse del load-balancing (preferiblemente por hardware).
• En el backend SQL tocará bien usar la filosofía master-slave cuando se usa más de un servidor o usar replicación. De la primera manera en uno se escribirá y en otro se leerá, de la otra todos los cambios se propagarán. Para esto, MySQL Proxy puede servir (aunque todavía no lo he probado personalmente).

Eso si, nunca viene mal reescribir la aplicación como comenté en otro post muy similar a este pero con un enfoque menos brutal.

Ya ha hablado un montón de gente sobre este servicio, aún así es algo digno de comentar en este blog (chau, dignidad).

Para quien no esté informado -aún-, Google App Engine es la competencia a los WebServices de Amazon, especialmente al EC2 (elastic computing cloud)

He empezado a probarlo, he desarrollado cuatro chorradas en Python (es decir, lo único que sé hacer) y he probado ejemplos. Muy didáctico.

Aunque lo mejor, pienso, es el respaldo de Google y la posibilidad de usar su plataforma a nivel de desarrollador. Por ejemplo, se pueden desarrollar aplicaciones sin necesidad de escalar en el caso de que crezca, aunque siempre a cambio de depender de Google (y de lo que conlleva, como tener los servidores en USA o ser dependiente de tu cuenta Google, que es un peligro).

Por mi parte la única barrera es la falta de lenguajes adicionales a parte de Python, que si bien Google usa mayoritariamente Python hay otros lenguajes como PHP que sirven para la tarea: Python primero fue lenguaje y luego módulo CGI, PHP fue primero módulo CGI y luego lenguaje.

Y en términos más técnicos lo único malo es en mi caso -también- la falta módulos para buscar en una DB -como search engine- o un acceso root / ssh a la máquina, por lo que en estos aspectos Google App Engine difiere mucho de EC2, donde este último provee maquinas -servidores- elásticos.

El tiempo dirá.