En la era en donde nos estamos enfocando a Web 2.0 (palabra que muchos hablan y no tantos comprenden), está cambiando radicalmente la forma en la que se crean sistemas. Actualmente, estamos viendo que los equipos tienden a entregar software como servicios, no como productos. Esta realidad lleva a cambios fundamentales en los modelos de negocio de las organizaciones.
Las operaciones deben convertirse en una competencia fundamental
El conocimiento clave de Google o Yahoo en el desarrollo de productos tiene que ser igualado por su experiencia en las operaciones diarias. El cambio es tan fundametal (de software como objeto a software como servicio) que el software dejará de funcionar a menos que sea mantenido de forma diaria. Google está indexando la web y actualizando su índice en todo momento, continuamente filtrando links de spam y otros intentos de influenciar los resultados, dinámicamente respondiendo a los cientos de millones de consultas de usuarios, y a la vez agregando anuncios relacionadas con el contexto.
No es entonces coincidencia que los sistemas de administración, redes y las técnicas de balanceo de carga de Google son el secreto mejor guardado de esta empresa, incluso más que su algoritmo de búsqueda. El éxito de Google en automatizar estos procesos es una parte clave en su ventaja de costos sobre la competencia.
Tampoco es coincidencia que los lenguages de scripting como Perl, Python, PHP y Ruby jueguen un papel tan importante en las empresas web 2.0. Perl es conocido como "la cinta adhesiva de Internet". Los lenguajes dinámicos son la herramienta preferida para los administradores de redes y de sistemas, y para los desarrolladores de aplicaciones que necesitan construir sistemas dinámicos con cambios constantes.
Se debe tratar a los usuarios como co-desarrolladores
Este concepto refleja prácticas del desarrollo de software de código abierrto (incluso aunque el software en desarrollo no sea liberado con una licencia de este tipo). La premisa del código abierto "entregar rápido y entregar seguido" fue mutando a una posición aún más radical: "La beta perpetua". En este enfoque, el producto se desarrolla "al abierto", agregando nuevas características de forma mensual, semanal o incluso diaria. Así tenemos servicios como Gmail, Google Maps, Flickr, del.icio.us que usan el logo de "beta" por varios años.
De esta manera, se convierte en una habilidad fundamental el poder monitorear el comportamiento de los usuarios para ver cómo usan las nuevas características y qué tan seguido las acceden. Una estrategia posible es agregar dos o tres características en alguna parte del sitio todos los días, y si los usuarios no las adoptan se quitan directamente; si a los usuarios les gusta, se aplican al sitio completo.
Carl Henderson, desarrollador líder de Flickr, explicó que realizan despliegues cada media hora. ¡Queda en evidencia que este es un modelo de desarrollo completamente distinto! Aunque no todas las aplicaciones web se desarrollan con un estilo tan extremo como Flickr, casi todas estas aplicaciones tienen un ciclo de desarrollo que es muy diferente al de la era de aplicaciones cliente-servidor.
Es analizando todo esto que una editorial de ZDnet concluyó que Microsoft no va a poder ganarle a Google: "El modelo de negocio de Microsoft depende en que todos actualicen su entorno operativo (sistema operativo y aplicaciones) cada dos o tres años. Google depende en que todos exploren lo que hay nuevo en su entorno operativo todos los días".
Aunque Microsoft ha demostrado que tiene una gran habilidad para aprender y eventualmente ganarle a su competencia, no hay dudas que esta vez la competencia va a obligar a Microsoft (y a otras empresas que desarrollan software) a convertirse en una organización profundamente distinta. Las empresas web 2.0 "nativas" tienen una ventaja natural, ya que no tienen vicios antiguos (y los correspondientes modelos de negocio y fuentes de ganancias) por superar.
El caso de Flickr
El equipo de Flickr realmente despliega sus aplicaciones en producción hasta cada media hora. Surgen dos preguntas: ¿por qué lo hacen? y ¿cómo lo hacen?
¿Por qué despliegan cada media hora?
Simplemente porque pueden. Porque, al menos para ellos, "entregar temprano, entregar seguido" es siempre efectivo, sin importar qué tan seguido se haga. Mientras más pequeñas y rápidas son las entregas, menos problemas de regresión, más rápido los usuarios tienen características, y más rápido se consigue feedback para el equipo. Básicamente, se publica cada característica nueva y arreglo de bug ni bien esté completo - no se preocupan por "agrupar" releases.
¿Cómo lo hacen?
Primero, tienen un sistema de construir-y-deplegar con un único click. Primero despliegan a un entorno de pre-producción, y si todo sale bien se pasa a producción directamente. Se ve algo como esto:
Como la lógica está escrita en PHP, implementar la mayoría de los cambios es tan simple como hacer un rsync desde el CVS HEAD hacia el cluster de servidores. A veces se necesita hacer un apachectl graceful, o limpiar el caché de squid/memcached, pero son acciones que no provocan pérdida de disponibilidad en la aplicación.
También se implementa un rollback con un único click que vuelve todo a la versión anterior si algo sale mal. Por otro lado, existe una buena separación de capas en la aplicación, para minimizar el daño colateral de un cambio.
Los equipos de desarrollo son pequeños y conocen todo sobre el código que actualizan (generalmente, 2 programadores Java, 2 PHP, un diseñador y alguien para la presentación).
Por último, la aplicación está basada en componentes con interfaces claras. La mayoría de la lógica de la aplicación se codifica en PHP, con sistema de caché a través de Squid y memcached, y procesos de ejecución larga que se ejecutan como daemons en Java. Los componentes individuales puede redesplegarse con bajo riesgo para el resto de los componentes, siempre y cuando se mantengan las interfaces.
El equipo tiene suites de pruebas para los componentes clave y algunas pruebas funcionales, pero la mayoría de las pruebas se confian a los mismos desarrolladores que prueban en un servidor de pre-producción.