github: Un nuevo hogar para el código fuente de Voota

8 marzo 2010

Siguiendo la política de transpariencia de Voota, esta semana hemos dado otro pasito. Nos hemos quitado de encima todo el código y le hemos buscado un sitio donde, pensamos, estará más cómodo.

Voota en github

Voota en github

Hasta ahora lo teníamos alojado en un servidor propio gestionado con subversion. Hoy Voota está en github, un servicio especializado en alojar software libre, donde cualquiera podrá acceder, comentar, reportar errores y muchos otro servicios. Además, pasamos de subversion a git que nos trae algunas funcionalidades nuevas.

¿Por qué este cambio?

Pensamos que es el lugar natural para un proyecto de estas características:

  • Porque el código fuente de Voota será más accesible, más fácilmente localizable para cualquiera que lo busque o lo quiera ver.
  • Porque estará más cerca de la comunidad de desarrolladores, gente que puede estar interesada y/o que puede aportar conocimiento.
  • Porque estará gestionado por expertos en el tema.
  • … y, además, quitará parte del trabajo de gestión a éste que suscribe. Eso siempre es bueno ;)

… y con el paso a git (vs. subversion):

  • Ganamos un entorno distribuido en el que no hace falta estar conectado con un servidor para utilizar el control de versiones.
  • Mejora sustancial de la gestión de ramas (branching).
  • Flexibilidad y eficiencia. Poco se puede decir de git que no esté dicho ya. Sólo puedo añadir que uno no es consciente de su potencia hasta que comienza a utilizarlo.

Dicho esto, estáis todos invitados a ver, descargar, comentar y cotillear por el código de Voota. Estará encantado de recibiros en su nueva casa ;)

Traducción web rápida y fácil con Symfony y Pootle

8 febrero 2010

El tema de las traducciones es, muchas veces un verdadero dolor de cabeza. La creación del código multi-idioma, la extracción de etiquetas y el envío y recepción de los textos al traductor son tareas que se pueden simplificar notablemente utilizando las herramientas apropiadas. Ahí va nuestra propuesta:

  • Codificación de las vistas (páginas) con etiquetas traducibles. El ejemplo a continuación es un extracto de una vista de Symfony :

    [...]

    <li><h2><?php echo __(‘Comparte opiniones sobre políticos de España.’) ?></h2></li>

    [...]

    Codificar las vistas de esta forma permite ver el html casi como será generado en el idioma original pero dando la posibilidad de traducir todos los literales que se encuentren entre ‘__(‘ y ‘)’.

  • Extracción de etiquetas. Un simple comando permite extraer todas las etiquetas a un fichero XLIFF:
    php symfony i18n:extract –auto-save frontend ca

    Este comando generará un fichero para almacenar las traducciones al catalán (‘ca’) de cada etiqueta encontrada en todas y cada una de las vistas de la aplicación (‘frontend’). Algo así como ‘…/ca/messages.xml’.
    Lo ideal es almacenar este fichero en un repositorio de software junto con el resto del código del proyecto. En nuestro caso utilizamos un servidor svn.

  • La magia de Pootle. La aplicación de Pootle deberá estar instalada en un servidor con acceso al repositorio svn. Habrá que configurar permisos y accesos para cada traductor. Una vez esté listo, Pootle permite conectarse con svn para obtener el fichero de etiquetas generado por Symfony. El traductor podrá conectarse vía web a la aplicación para ver y traducir todas aquellas que pertenezcan a sus proyectos y lenguajes asignados.
    Interfaz de traducciones - Pootle

    Interfaz de traducciones - Pootle

    Desde el propio interfaz de Pootle, siempre con los permisos apropiados, se puede enviar de nuevo el fichero con las traducciones realizadas de nuevo al repositorio de software. Sobra decir que, además, Pootle ofrece un montón de utilidades más sobre las traducciones, como estadísticas, traducciones dudosas o poco claras, perfiles para sugerir y otros para confirmar, etc..
    Te invitamos a que eches un vistazo al Pootle de Voota: http://pootle.voota.org/

Nunca fue tan fácil tener sitios en varios idiomas. Ahora solo necesitamos los traductores que, por el momento, seguirán siendo humanos ;)

SfReviewPlugin 1.0: Nueva versión del plugin de opiniones para Symfony

18 enero 2010

Hoy ya hemos puesto a disposición de todos la versión 1.0 de SfReviewPlugin. Se trata del plugin de symfony que desarrollamos y utilizamos en Voota para la gestión de opiniones sobre políticos (y muy pronto sobre partidos).

Aunque sigue siendo una versión beta, hemos decidido etiquetarla 1.0 para seguir con la numeración de los milestones de voota.

Descarga

Puedes obtener la versión instalable directamente del sitio de symfony:

http://www.symfony-project.org/plugins/sfReviewPlugin

Para obtener los últimos cambios día a día, puedes bajarte los fuentes del repositorio svn de Voota:

http://trac.voota.org/browser/trunk/www/plugins/sfReviewPlugin

Novedades

  • La novedad principal, sin duda, es la posibilidad de opinar/votar sobre otras opiniones.

    Opinando sobre un comentario

    Opinando sobre un comentario

  • Opiniones “culturizadas”. Hemos introducido el idioma del usuario a la opinión para, de esta forma, poder distinguir el idioma en la página donde aparecen los comentarios.
  • Paginación “tipo twitter”. Para mejorar la experiencia de usuario hemos introducido un botoncito que dice “más” cuando no caben todos los comentarios. Al pulsarlo aparecerá otra página de comentarios “inline” por ajax (sin necesidad de recargar la página). Ej.: Página de Zapatero en Voota
  • Mejoras en el sistema de moderación: Más filtros, más facilidad para encontrar comentarios y mejor interfaz para visualizar el comentario con enlace a la “entidad comentada”.

    Moderación de comentarios

    Moderación de comentarios

  • Y, como siempre, un montón de pequeñas mejoras y correcciones que hacen la vida un poco más fácil ;)

En definitiva, seguimos trabajando en el sistema de opiniones como uno de los módulos principales de Voota. Ójala te sea útil a tí también y compartas con nosotros tus impresiones.

nginx + fast-cgi: Nueva arquitectura para Voota

31 diciembre 2009

Tras tener varios problemas de servidores en Voota, nos tocó investigar como mejorar los sistemas. Como siempre, lo primero es preguntar a los expertos. Nuestros amigos de amplicate.com y masquemedicos.com lo tenían claro. Junto con muchas otras recomendaciones, nos convencieron para cambiar el servidor web a una arquitectura más moderna.

Adiós Apache y gracias por todo

Apache ha sido durante mucho tiempo (y sigue siendo) el servidor web más utilizado y popular para servir tanto páginas estáticas (html) como aplicaciones desarrolladas en php, perl o python. Pero como pasa con todo, poco a poco ha ido quedándose atrás en favor de otras arquitecturas más modernas.

Nginx

Arquitectura nginx con fast-cgi

Nginx es un servidor mucho más ligero que apache y que, por lo tanto, realiza menos funciones. La idea de es utilizar Nginx en la primera línea de fuego para servir todo el contenido estático del sitio web: Pagínas html, imágenes, javascript, hojas de estilo, etc. El resto de las tareas se delegarán a un servidor específico.

fast-cgi

Es la evolución de CGI (Common Gateway Interface), aquél protocolo concebido allá por 1993 para responder a la demanda de páginas dinámicas. Hoy fast-cgi permite conectar (por tcp) un servidor web estilo Nginx con otro servidor independiente que ejecuta las aplicaciones. En el caso de Voota, estás aplicaciones están desarrolladas en php y el servidor de aplicación es php-fpm.

En resumen, nada radicalmente nuevo. Mismos programas, mismo lenguaje, pero con una arquitectura mucho más moderna, flexible, rápida y escalable.

Mejorando el rendimiento de Symfony a base de caché

17 diciembre 2009

Symfony no es lento

Se dice que utilizar un framework en general y Symfony en particular penaliza el rendimiento de una aplicación web. Es cierto, al menos a priori. Por mucho trabajo de optimización que se haga, las propias clases del framework consumirán tiempo y recursos y tampoco serán las óptimas las queries de acceso a base de datos generadas. Siempre será más eficiente un código personalizado para la ocasión que un código genérico.

Dicho así podría parecer que es preferible invertir tiempo en hacer código a medida que utilizar herramientas como Symfony. Nada más lejos de la realidad. Una de las cosas que proporciona Symfony, y que compensa con creces “su lentitud”, es un sistema de caché que con muy poco esfuerzo permitirá a una aplicación desarrollada en Symfony “correr” mucho más rápido que una aplicación hecha “a mano”. ¡Ojo! Esto no quita la responsabilidad de hacer un código eficiente.

Activando la caché de página

Efectivamente, hay muchas formas de optimizar el rendimiento de una aplicación, pero sin duda, la caché de página es la que marca la diferencia. Para activarla en Symfony solo hay que crear el fichero cache.yml en el directorio config del módulo (ej. apps/frontend/modules/politico/config/) activando la cache para cada acción en la que se quiera poner en caché:

ranking:
 enabled: on
 with_layout: false
 lifetime: 60

show:
 enabled: on
 with_layout: false
 lifetime: 360

“ranking” y “show” son dos de las acciones del módulo. “with_layou: false” indica que sólo ha de guardarse el código específico de esta vista, no el de layout.php. “lifetime” es el tiempo en segundos que tardará en limpiarse la caché automáticamente.

Limpiando la caché manualmente

Symfony proporciona información del estado de la caché si se necesita

Una de las opciones para limpiar la caché de una página es esperar a que pase el tiempo indicado en “lifetime” en el fichero de configuración. Como esto muchas veces no es una opción, Symfony proporciona un mecanismo para limpiarla por código. El siguiente snipplet (pedacito de código) muestra como, en Voota, se limpia la caché de la página de un político cada vez que alguien deja un comentario:

$cacheManager = $this->getContext()->getViewCacheManager();
if ($cacheManager != null) {
$cacheManager->remove(“politico/show?id=”.$politico->getVanity().”&sf_culture=es”);
$cacheManager->remove(“politico/show?id=”.$politico->getVanity().”&sf_culture=ca”);
}

La clase sfViewCacheManager permite interactuar con el sistema de caché de Symfony. El método “remove” limpia la página que se quiera.

Más rápido incluso

Otra de las funcionalidades que ofrece Symfony es delegar la gestión de la caché a un sistema externo. Unos de los sistemas más conocidos y utilizados dentro y fuera de Symfony es memcached. Una buena idea será dejarle la gestión a él. Esto se configura en el fichero de factorías de la aplicación (apps/frontend/config/factories.yml):

dev:
 view_cache:
  class: sfMemcacheCache
   param:
    lifetime:                  86400 #24h
    prefix:                    vo
    servers:
     server_01:
      host: localhost
      post: 11211

El resto exactamente igual. No será necesario tocar ni una línea de código para esto.

sfReviewPlugin: Plugin symfony para dejar opiniones sobre “cualquier cosa”

30 noviembre 2009

Como parte del desarrollo de Voota estamos creando un plugin genérico para dejar opiniones: sfReviewPlugin. En su primera versión, Voota permite opinar sobre políticos, pero pronto permitirá opinar sobre partidos políticos y, más adelante, sobre otras “entidades”.

Como se puede ver en el decálogo  de Voota, parte de nuestro compromiso es con el software libre y, por lo tanto, pretendemos ir a aportando cualquier pieza de software que vayamos produciendo. Hoy tenemos ya publicada la primera versión del sistema de opiniones:

¿Qué es sfReviewPlugin?

Editando una opinión con sfReviewPlugin

Es un plugin genérico para valorar y opinar sobre cualquier elemento de un sitio web desarrollado con Symfony. Está basado en sfGuardPlugin como gestor de usuarios y en JQuery (sfJqueryReloadedPlugin) como api javascript/ajax.

Donde bajarlo y cómo instalarlo

El plugin está alojado en el propio sitio de symfony:

http://www.symfony-project.org/plugins/sfReviewPlugin

En la pestaña “Readme” se pueden encontrar las instrucciones para descargarlo, instalarlo y realizar una configuración básica.

Los fuentes están disponibles en el repositorio de software de Voota:

http://trac.voota.org/browser/trunk/www/plugins/sfReviewPlugin

Cualquier duda / problema / sugerencia será muy bien recibida en este blog, en mi twitter o en la dirección de email de temas técnicos de Voota: tech [arr0ba] voota.es

Suma y sigue

Como todas las primeras versiones esto no es más que una beta del plugin. Para el siguiente milestone de Voota ya estamos trabajando en las opiniones sobre opiniones (para permitir el debate entre usuarios) y, muy pronto, este mismo plugin permitirá cargar imágenes y vídeos con el comentario.

http://trac.voota.org/browser/trunk/www/plugins/sfReviewPlugin

Como implementar Sphinx con symfony

23 noviembre 2009

Como primera aproximación a un buscador simple en la primera versión de Voota, se nos ocurrió utilizar “Google custom search“. Mala idea. Hoy, 5 días después de la puesta online, Google solo ha indexado 267 páginas y teniendo en cuenta que empezábamos con 1.549 políticos con sus 1.549 correspondientes fichas, los resultados no eran muy apropiados. Por ejemplo, buscando “Zapatero” aparecían varios resultados del blog, alguna ficha de otros políticos y varios enlaces al ranking, pero no la ficha del sr. presidente.

Necesitábamos un buscador, sencillo, potente y que escalase bien con los futuros desarrollos que vienen. La solución fue mucho más fácil de lo esperado. Decidimos implementar nuestro propio motor de búsqueda con Sphinx. Así es como lo hicimos:

  1. Lo primero es instalar el motor de búsqueda, que básicamente consta de dos partes: El indexador, que obtiene las palabras clave de la base de datos (Postgresql o mysql) y el demonio o servicio de búsqueda que atiende a las peticiones del servidor web.
    La instalación no tiene más misterio que seguir los pasos que explican en su web: Manual de referencia de Sphinx.
  2. Después viene la fase de configuración. Aquí es donde se le dice a Sphinx que datos tiene que indexar para que puedan ser encontrados en el buscador del sitio web. En nuestro caso, de momento, sólo queríamos indexar los políticos:
    source src1
    {
    type                                    = mysql
    sql_host                                = localhost
    sql_user                                = usuario
    sql_pass                                =
    sql_db                                  = voota
    sql_port                                = 3306  # optional, default is 3306
    sql_query_pre   = SET NAMES utf8
    sql_query                               = \
    SELECT id, vanity, alias, nombre, apellidos, bio, presentacion, residencia, formacion \
    FROM politico
    sql_ranged_throttle     = 0
    sql_query_info          = SELECT * FROM politico WHERE id=$id
    }
    source src1throttled : src1
    {
    sql_ranged_throttle                     = 100
    }
    index politico
    {
    source                  = src1
    path                    = /var/data/voota
    docinfo                 = extern
    mlock                   = 0
    morphology              = none
    min_word_len            = 1
    charset_type            = utf-8
    charset_table   = 0..9, A..Z->a..z, a..z, \
    U+C0->a, U+C1->a, U+C2->a, U+C3->a, \
    U+C4->a, U+C5->a, U+C6->a, \
    U+C7->c,U+E7->c, U+C8->e, U+C9->e, \
    U+CA->e, U+CB->e, U+CC->i, \
    U+CD->i, U+CE->i, U+CF->i, U+D0->d, \
    U+D1->n, U+D2->o, U+D3->o, \
    U+D4->o, U+D5->o, U+D6->o, U+D8->o, \
    U+D9->u, U+DA->u, U+DB->u, \
    U+DC->u, U+DD->y, U+DE->t, U+DF->s, \
    U+E0->a, U+E1->a, U+E2->a, U+E3->a, \
    U+E4->a, U+E5->a, U+E6->a, \
    U+E7->c,U+E7->c, U+E8->e, \
    U+E9->e, U+EA->e, U+EB->e, U+EC->i, \
    U+ED->i, U+EE->i, U+EF->i, \
    U+F0->d, U+F1->n, U+F2->o, U+F3->o, \
    U+F4->o, U+F5->o, U+F6->o, \
    U+F8->o, U+F9->u, U+FA->u, U+FB->u, \
    U+FC->u, U+FD->y, U+FE->t, U+FF->s,
    html_strip                              = 0
    }

    Extracto del fichero de configuración de Sphinx

  3. A continuación se arranca el servicio de búsqueda:
    sudo searchd –config /usr/local/etc/sphinx.conf
    y se da la orden para que Sphinx realice la indexación (Esto será necesario hacerlo periódicamente):
    sudo /usr/local/bin/indexer politico –rotate
    Muy bien, Sphinx configurado y escuchando.
  4. Sólo falta escribir el código Symfony para interrogar al motor de búsqueda:
    $this->q = $request->getParameter(“q”);$cl = new SphinxClient ();
    $cl->SetServer ( ‘localhost’, 3312 );
    $this->limit = 1000;
    $cl->SetLimits ( 0, $this->limit, $this->limit );
    $cl->SetArrayResult ( true );
    $this->res = $cl->Query ( SfVoUtil::stripAccents( $this->q ), ‘politico’ );
    if ( $this->res!==false ) {
    if ( isset($this->res["matches"]) && is_array($this->res["matches"]) ) {
    $c = new Criteria();
    $list = array();
    foreach ($this->res["matches"] as $idx => $match) {
    $list[] = $match['id'];
    }
    $c->add(PoliticoPeer::ID, $list, Criteria::IN);
    $c->addDescendingOrderByColumn(PoliticoPeer::SUMU);
    $this->politicosPager = new sfPropelPager(‘Politico’, 10);
    $this->politicosPager->setCriteria($c);
    $this->politicosPager->setPage($this->getRequestParameter(‘page’, 1));
    $this->politicosPager->init();if ($this->politicosPager->getNbResults() == 1){
    $res = $this->politicosPager->getResults();
    $this->redirect( “@politico_”.$this->getUser()->getCulture( ‘es’ ).”?id=”.$res[0]->getVanity() );
    }
    }
    }

    Código Symfony que realiza la búsqueda

Listo, hoy puedes buscar Zapatero, José Luis Rodriguez o ZP en Voota, que seguro que encuentras lo que buscas, a no ser que quieras comprarte unos zapatos nuevos, claro ;)

Voota goes live !

18 noviembre 2009

Después de 3 meses de trabajo y un sencillo paso de puesta en producción, ya se puede opinar y votar sobre nuestros políticos. Voota sale con una versión beta que aporta lo esencial:

  • Opiniones de usuarios sobre políticos
  • Ranking de los políticos más y menos valorados

Por supuesto, esto es solo el principio, pero espero que dejes muchas opiniones/votos y, si quieres, me digas que te parece. Y si te apetece ver qué viene después, puedes echar un vistazo al roadmap de nuestro Trac.

Ale, ¡a Vootar!

Posts relacionados:

La puesta en producción

16 noviembre 2009

Se acerca el día “D”. Voota empieza su andadura esta semana y, como no puede ser de otra manera, estamos llenos de emoción. Y cuando digo emoción, me refiero a lo contentos que estamos y a las ganas que tenemos de verlo funcionando, no a que tenemos los pelos como escarpias por el miedo a la puesta en producción. Veamos algunos consejillos para que esto no ocurra.

Ante todo, ¡orden!

Para que la subida (o puesta en producción) sea un éxito, es fundamental hacer una buena planificación, preparar el proceso unos días antes. Una buena idea es tener un checklist de cosas a preparar/revisar antes de ponerse manos a la obra. Podría ser algo tan simple como:

  • Asegurar que los servidores están correctamente actualizados.
  • Comprobar los datos. Todos están correctamente cargados con la información adecuada.
  • Backups. Asegurarse de que todos los subsistemas se están copiado adecuadamente según la política de backup.
  • Todas las aplicaciones están listas (este punto debería llevar implícito toda una fase de pruebas funcionales)

Otra cosa importante es planificar el día y la hora correctamente. Si se planifica la subida a última hora del día, ante cualquier imprevisto, se condena uno a una de dos: dejar el trabajo a medias, o a hacer horas extras. Lo mejor es hacerlo a media mañana con tranquilidad y sin estrés. Lo mismo pasa con el día. Si se realiza la subida un viernes, se está exponiendo el sitio a que se pasé 3 días offline.

Sube pronto, sube a menudo

Hoja de ruta (roadmap) de Voota

Hoja de ruta (roadmap) de Voota

Una de las máximas del desarrollo ágil es que los “sprints” deben de ser cortos. Esta semana Voota sale con lo esencial, es decir, un sistema de opiniones sobre políticos con un ranking para ver los más votados. Hemos querido reducir tanto que ya tenemos programado otro “sprint” de 7 días para subir la semana que viene. En su Trac se puede ver la hoja de ruta de Voota.

Sólo errores, ¡por favor!

No se puede concebir un desarrollo de software que no tenga incidencias, bugs o errores (depende quien los nombre). Son fallos en el desarrollo que se producen a todos los niveles (datos, aplicación, sistemas, …). Es por esto que es imprescindible una fase de pruebas de software, durante la cual se van identificando y corrigiendo estos fallos. Hasta aquí todo bien, el problema es que, inevitablemente, al revisar las aplicaciones siempre aparecen funcionalidades nuevas con las que se podría dotar al sitio. La tentación de informar como incidencia una nueva funcionalidad que se le ocurre al encargado de hacer la revisión es muy grande.
Es importante no caer en esta tentación a menos que se detecte una funcionalidad importante no detectada en la fase de definición. En este caso debería incluirse en la definición con su correspondiente estimación y retrasar la subida todo lo que sea necesario. Nunca “colarla” como un error. Lo único que se conseguiría con esto es degradar la calidad del software.

Ya está, ¿y ahora qué?

Ramificaciones para gestionar subidas en Voota

Ramificaciones para gestionar subidas en Voota

Un problema clásico de las puestas en producción es el siguiente. Se sube una versión a producción, por ejemplo, “milestone0.5″. Inmediatamente se comienza con el desarrollo del “milestone0.6″, pero dos días después se descubre un error importante en la versión en producción (“mileston0.5″). Si no se ha tenido la precaución de guardar el estado de todos los programas en el momento de hacer la subida, el problema no se podrá solucionar hasta que el “milestone0.6″ esté listo. Es por esto importante hacer una “foto” con el estado del proyecto en el momento de la subida. Cualquier gestor de fuentes del mercado (subversion en el caso de Voota) permite crear ramas (branching).
Una rama en el gestor de fuentes es como tomar una foto del estado del proyecto, con la ventaja que se puede cambiar de una rama a otra cuando se necesite.

¡ Vamos, pues, a por el siguiente punto kilométrico !

Así utilizamos Amazon Web Services

2 noviembre 2009

En Voota creemos que cada uno debe dedicarse a lo que mejor sabe hacer. Por eso, desde el primer momento, no quisimos encargarnos de comprar, instalar y configurar servidores. Amazon Web Services (AWS) ofrece un sistema de virtualización que nos abstrae de gran parte de este trabajo de sistemas. De momento empezaremos utilizando 2 de sus servicios:

Así utilizamos EC2

Este es, sin duda, el núcleo de los servicios de virtualización. Permite crear servidores web, servidores de bases de datos y … servidores en general. El concepto es simple: Permite crear todos los servidores que necesite el proyecto desde una interfaz web. Por supuesto son servidores virtuales, pero a todos los efectos es igual que tener un servidor en el despacho de abajo, con la ventaja de que puedes incrementar el número de servidores con un clic de ratón.

Instancias EC2

Lista de instancias en Amazon EC2

Las instancias en EC2 son servidores en ejecución. Se paga por el uso de instancias, lo cual permite tener más o menos servidores sirviendo páginas en función del tráfico del sitio en cada momento.

Otro concepto muy interesante es del AMI (Amazon Machine Image) que no es otra cosa que un servidor “congelado” o, más técnicamente, una imagen de servidor. Cuando se necesita arrancar una nueva instancia, se abre la “nevera” y se le dice a Amazon: “Arráncame uno de estos” y se crea una instancia nueva.

Elegir un AMI

Cualquiera en la comunidad puede crear sus propias imágenes al igual que cualquier distribuidor de software. En el caso de Voota, utilizamos Ubuntu server. Canonical nos lo pone fácil y pone a disposición de cualquier usuario de EC2 su “servidor congelado”. Ya está disponible en Karmic Koala (la nueva versión de ubuntu).

Pero esto es sólo para la primera vez. En Voota, una vez que tuvimos el servidor instalado con el software necesario y listo para servir páginas, le hicimos una foto. Es decir, lo congelamos a un AMI. De esta forma, la próxima vez que sea necesario arrancar una nueva instancia, lo haremos desde nuestro propio AMI, que ya está listo para funcionar.

AMI del servidor web de Voota

AMI del servidor web de Voota

Así utilizamos S3

S3 es un servicio de almacenamiento. Permite almacenar cualquier tipo de información mediante ficheros (imágenes, vídeos, AMIs, backups, etc.). Para nosotros es muy útil a la hora de almacenar las imágenes y los vídeos. Un error muy común en el desarrollo web es almacenar estos ficheros multimedia en un disco del servidor. Todo funciona bien hasta que se necesitan más servidores y por tanto compartir estos ficheros de imágenes. Hay varias soluciones para este problema:

  • Sincronizar continuamente los ficheros entre todos los servidores. Bastante poco práctico sobre todo a medida que va creciendo la estructura.
  • Utilizar una unidad compartida de modo que todos los servidores lean y escriban en el mismo disco. Más cómodo pero se corre el peligro de saturar el disco con lo  cual el balanceo de los servidores no servirá para nada.
  • Crear un servidor de ficheros al que todos los servidores web envíen los ficheros cuando hay que “escribir”. Y que sea este servidor de ficheros el encargado de servirlas directamente al navegador del usuario del sitio web.

Esto último es lo que nos ofrece S3. Cuando algún usuario de Voota carga una fotografía, ésta se envía directamente a S3, quien la almacena. Cuando esta fotografía ha de aparecer en alguna página web, será S3 el encargado de servirla.

Foto de Zapatero almacenada en S3

Esta foto está almacenada en http://imagesvoota.s3.amazonaws.com/politicos/bw_p_238.jpg

Otra utilidad de S3 es el almacenaje de los AMIs o “servidores congelados” que mencionaba antes. Para poder utilizar un AMI en EC2 es obligatorio tenerlo almacenado en S3.


Seguir

Get every new post delivered to your Inbox.