Cuando escribimos una aplicación nos gusta que sobre todo sea rápida y eficiente, esto es un problema cuando se trata de una aplicación compleja. Pensemos a lo grande: “Divide y vencerás”

 Si miramos de cerca al final todo programa que ofrece información se compone de tres partes:

  • Quien piensa (lenguaje de programacíon como C, PHP, Java o Ruby On Rails)
  • Quien almacena datos (una base de datos MySql, SQLite, Oracle, Access o un archivo sencillo)
  • Quien contiene datos estáticos (fotos, documentos pdfs, imágenes dinámicas gif, ...)

 

Además prácticamente siempre se sigue el mismo diagrama de flujo:

  1. Llamada al servidor para darnos información, por ejemplo una web.

  2. Quien piensa entra en acción pidiendo datos

  3. Petición a quien almacena datos

  4. El servidor procesa y resuelve usando a quien piensa y quien almacena datos.

  5. Se ofrece un renderizado parcial sin el contenido estático

  6. Petición a quien contiene los datos estáticos para poder incrustar por ejemplo imágenes

  7. LISTO, petición de información resuelta :)

 

El problema son las tres peticiones, si las tres peticiones se hacen en la misma máquina el tiempo de CPU para solucionar la llamada sería la suma de las tres peticiones. Otro problema importante es que si se rompe este servidor todo deja de funcionar.

Un buen plan sería intentar hacer las tres peticiones lo mas paralelamente posible o al menos que no sea la misma maquina quien las resuelva. Así conseguiremos descargar el servidor de trabajo, poder atender más peticiones al mismo tiempo, estar más rápidos y seguros si se cae una de las partes.

Por ejemplo, pedimos una página web a un servidor:

  • (Quien piensa). La web esta alojada en un servidor, por ejemplo Heroku, AppFog, Ovh, Amazon EC2, etc

  • (Quien almacena datos). La base de datos está alojada en otro servidor, por ejemplo Amazon RDS, caldecott-aws en AppFog, servicio Postgres en Heroku, etc

  • (Quien contiene datos estáticos). El contenido estático se alojada en Amazon S3, Google Drive, Dropbox, etc

 

En este ejemplo ganamos:

  • Tranquilidad: podemos balancear la carga del servidor donde está la aplicación con espejos y balanceo de carga (Squid o Nginx). Así si saturan a un servidor con llamadas, saltara a otro que pueda dar solución porque este más descargado de llamadas. Este servidor solo contiene la aplicación, la parte que piensa.

  • Seguridad: si se cae el servidor de bases de datos, lo podemos cambiar por otro con una copia de seguridad que tengamos (servicio de base de datos en otro lado o reiniciarlo).

  • Rapidez: le pasamos la pelota de la carga extra por datos estáticos a otro servidor. Ahora cuando la web se resuelva y se pida contenido estático como imágenes, el cliente las pedirá a otro servidor. Nuestro servidor ahorrara trafico y peticiones.

y perdemos:

  • Existe un tiempo de espera extra entre el servidor que contiene la aplicación y el de la base de datos

  • Más complicado porque hay que configurar mas servicios en sitios distintos, cada uno con sus peculiaridades e intentar que todos se lleven bien con la aplicación

  • Dinero, el almacenamiento tiene un precio. Las bases datos son gratuitas hasta cierto volumen de datos y el contenido estático lo mismo. Normalmente cuando se contrata un servidor para alojar nuestra aplicación se suele disponer de bastante capacidad para albergar una base de datos y contenido estático.

 

En resumen, todo depende... como dice Jarabe de Palo ;)

Tal vez un buen plan sería albergarlo todo en un servidor y después ir descentralizando servicios a medida que el proyecto vaya creciendo. El problema es que ir cambiando cosas de sitio, también es tiempo y dinero. Tu decides.

 

Saludos a todos

Volver