Le voy a dar utilidad al buscador del blog, ese que decora en la barra lateral. Por ejemplo. Todo esto para decir que de lejos, no soy ningún negado del PHP, y que es más bien algo que se me da bien. O un pro, pero eso sólo sirve para verse el ego aún más grande… y no es plan.

Recientemente sir Atwood escribió un notable artículo. PHP sucks but it doesn’t matter. PHP apesta pero no importa. Vamos.

Código spaghetti, dice que es algo normal en PHP. Falta de orientación a objetos, demasiadas funciones… o en otras palabras, “VB, ASP, eso mola más”.

Mi detector de ironías acaba de reventar. Pero bueno, al grano.

Esto me dio por pensar en algún método para evitar tanta repetición de código. Algo como la innovación de Rails con la sencillez de PHP y con la potencia de la que éste dispone, que en código depurado es simplemente… impresionante.

Principios:

• rake / gem, adaptado a PHP: librerías y otras – gem, rake como gestor de entornos (?) no entraría aquí. subir y trabajar.
• archivo de configuración
• activerecord
• mvc sencillo
• url’s limpias
• posibilidad de ir a su bola, no hay necesidad de usar MVC
• templating sencillo

Esto sería lo más básico… pero estoy cansado. Mañana haré algún tipo de preview sobre el código y estructura hasta tener algo maduro en la próxima semana, si es que puedo. Tengo tantas cosas que hacer que no he podido ni poner un post sobre las tantas cosas que tengo que hacer. Cosas…

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.

De verdad, estoy hasta las narices de la gente que pregunta. Que si me preguntan cosas de las que sé, vale. Que no me pregunten de mil chorradas de las que soy completamente ajenas.

• ¿Cómo se dice moco en chino?
• ¿De qué color es el alce campestre?
• ¿Como es la panza de las ovejas abejas?
• ¿Qué beneficios aporta el cultivo transgénico?

O volviendo a la tierra preguntas sobre si tal o tal hosting tiene tal función activada, que qué programa hay que usar para exportar nosequé tipo de cosa, que qué modelo de negocio usaría esta página…

Vale, sé muchas cosas pero no absolutamente todas. Y no preguntéis por obviedades pero tampoco recurráis a mi como un adivino de horizontes insospechables. No he llegado a tal nivel de sabiduría que incluye conocer absolutamente todo y luego contarte. Busca, coño.

Se lo dedico a todos los preguntan (¡un beso a los que preguntan!) esperando que sea su recurso… mágico. Otra vez será, lo siento.