Esencialmente, la filosofía shared nothing se trata de el acoplamiento débil aplicado a todo el conjunto de software utilizado. Esta arquitectura se presentó como respuesta directa a la que en su momento prevalecía: una aplicación de servidor web monolítica que encapsulaba el lenguaje, la base de datos y el servidor web — e incluso partes del sistema operativo — un único proceso (por ejemplo, Java).
Cuando llega el momento de escalar, esto puede ser un problema serio; es casi imposible separar el trabajo de un proceso monolítico entre muchas maquinas físicas diferentes, por lo que las aplicaciones monolíticas requieren servidores enormemente potentes. Estos servidores, por supuesto, cuestan decenas o a veces centenas de miles de dolares, dejando a los sitios web de gran escala lejos del alcance de individuos o pequeñas compañías con buenas ideas pero sin efectivo.
No obstante, lo que la comunidad LAMP descubrió fue que si se separa cada pieza de esa pila de software Web en componentes individuales, se podría fácilmente comenzar con un servidor barato y simplemente ir agregando más servidores baratos a medida que se crece. Si un servidor de base de datos de 3.000 dólares ya no puede manejar la carga, sencillamente se compraría un segundo (o un tercero, o un cuarto) hasta que pueda. Si se necesita más capacidad de almacenamiento, se agregaría un servidor NFS.
Aunque para que esto funcione, las aplicaciones Web deben dejar de asumir que el mismo servidor es el que maneja cada petición — o incluso las distintas partes de una petición. En una implementación LAMP (y Django) de gran escala, ¡más de media docena de servidores pueden estar involucrados en servir una sola petición! Las repercusiones a esta situación son numerosas, pero pueden reducirse a estos puntos:
- El estado no puede ser guardado localmente. En otras palabras, cualquier dato que deba estar disponible entre múltiples solicitudes, debe almacenarse en algún tipo de almacenamiento permanente como la base de datos o una caché centralizada.
- El software no puede asumir que los recursos son locales. Por ejemplo, la plataforma web no puede asumir que la base de datos corre en el mismo servidor; por lo que debe ser capaz de conectarse a servidor de base de datos remoto.
- Cada pieza del conjunto debe ser fácilmente trasladable o reemplazable. Si Apache por alguna razón no funciona para la implementación dada, deberías ser posible cambiarlo por otro servidor con mínimas complicaciones. O a nivel hardware, si un servidor web falla, debería ser posible reemplazarlo por otra maquina con ínfimos tiempos de caída. Recuerda, esta filosofía sobre implementación se basa enteramente en hardware barato. Fallas en maquinas individuales deben estar contempladas.
Como probablemente esperabas, Django maneja todo esto más o menos de forma transparente — ninguna parte de Django viola estos principios — pero conocer la filosofía ayuda cuando es tiempo de escalar.