3 elementos para una Arquitectura más Ágil

Esta semana me pidieron en un cliente si podía compartir algunas definiciones o lineamientos sobre agilidad en Arquitectura de Software, para trabajar en una reunión interna.

Como otras veces, después de pensar la respuesta y escribir un poco, les pedí permiso para compartir las ideas en este blog, y aquí van los tres elementos a los que llegué, a través de algunas preguntas de ellos:

Arquitectura incremental

Igual que con el diseño funcional, desconfiamos del "gran diseño preliminar", y tratamos de empezar con la arquitectura mínima necesaria para la funcionalidad que estamos encarando. Podemos hacer este ejercicio, idealmente, Sprint a Sprint, decidiendo sobre la arquitectura en cada planning.

IMPORTANTE: esto no implica que no iniciemos con algunos elementos mínimos de referencia, que nos son comunes (un lenguaje, un framework, una base de datos, etc). Es común que dentro de una organización tengamos algunos lineamientos (idealmente definidos de manera colaborativa). Lo que nos dejamos abierto es la posibilidad de cambiar algo más adelante, si nos damos cuenta que nos conviene.

Validación continua

Más allá de una visión general de guía, igual que con la funcionalidad, tratamos de dejar una prueba automatizada que nos ayuda a validar que logramos el efecto que queríamos al implementar cada pieza de arquitectura: por ejemplo, pruebas de performances, de extensibilidad, validaciones de nivel de acoplamiento o complejidad, etc. Esas pruebas se ejecutan de manera continua, al igual que las pruebas unitarias o de aceptación.

Esa validación permanente en el entorno de desarrollo/QA se extiende también a mediciones en el proceso automatizado de deployment, y al monitoreo de la solución en el ambiente productivo (monitoreo de servidor, clientes, dispositivos, plataforma, etc). Todo ese seguimiento es lo que nos permite entender si nuestra arquitectura realmente está soportando lo que necesitamos en este momento, y también comprobar si cualquier cambio tiene el efecto deseado o no. Ese nivel de feedback es lo que nos permite encarar cambios en la arquitectura sin entrar en pánico.

Demasiado importante para dejárselo a los Arquitectos

Como no diseñamos la arquitectura por completo en el inicio, tampoco se define desde un rol centralizado o mediante especialista en un silo. Aunque haya personas en el equipo con el título de Arquitecto, el tema se discute con todo el equipo y con los involucrados del negocio, y las decisiones se realizan de manera colaborativa, teniendo en cuenta todos los puntos de vista.

Las decisiones tampoco suelen ser finales, sino que se diseñan experimentos, con métricas asociadas y un objetivo a alcanzar, que se validado o no en la implementación.

Nuevamente, este no quita que exista un equipo de Arquitectura Corporativa o algo similar. La diferencia es que esos grupos se ocupan más de entender las restricciones generales necesarias para el negocio, la plataforma común, el ecosistema de diferentes aplicaciones (propias y de terceros), y actúa como un participante frecuente en las reuniones de planificación de los equipos, no para imponer definiciones, sino para tener feedback y colaborar en las definiciones de cada aplicación.

Finalmente, como para otras actividades, interese o tecnologías (testing, diseño, JS, bases de datos, temas de negocios) el intercambio y alineamiento de temas de arquitectura entre diferentes equipos se puede realizar mediante espacios de Comunidades de Práctica.

 

Continuando la discusión

Obviamente estas ideas están resumidas y tienen mucho más detrás. Si te interesa continuar este tema, algunas de las cosas en las que he trabajado a lo largo de los años son:

• El paper “Software Architecture in the Agile Life Cycle” que publicamos en 2010 con mi amigo y colega de la vida Diego Fontdevila.
  (Original en inglés, en el Architecture Journal; ó versión en español, actualizada en 2013)
• Mi libro en progreso, Agile Software Architecture.
• Mi Agile Architecture Workshop, que doy varias veces al año en distintas ciudades de América Latina
  (cuando hay fechas programadas aparecen a la derecha)
• Otros libros relacionados de colegas varios: 
• Building Evolutionary Architectures, de Rebecca Parsons, Neil Ford y Patrick Kua
• Lean Architecture, de James Coplien y Gertrud Bjørnvig

 

Katas de Arquitectura

Un año atrás mi amiga Rox (¡que viva México!) me hizo una consulta por mail que acordamos compartir. Me demoré un poco, pero aquí va.

Primero copio su consulta:

Mañana tengo una sesión de kata de arquitectura con un equipo.  El objetivo principal no es la arquitectura en sí, sino un problema que tienen en partir en historias de usuario porque la mayoría de sus requerimientos son no-funcionales y dicen que no se puede.

Así que pensé en hacer un experimento: mezclar la kata de arquitectura con una kata de User Story Splitting.

Así que estoy en el sitio, pero veo que faltan los requerimientos no-funcionales que se agregan y recuerdo que tenías unas cartas.

¿Son los "normales" (escalabilidad, performance, mantenibilidad, etc)? o ¿cuáles son?

Y ahora mi respuesta (ampliada con algún material extra que no incluí en el mensaje original, que pongo entre [corchetes]):

---

¡Hola, Rox! 

Te paso el material:

• Las Katas de Arquitectura en español    [y aquí el sitio original en inglés]
  
  
• Y mi Tarot de Arquitectura
  
  
• [agrego también la guía ágil de patrones de slicing - que a su vez tiene el link a las tarjetas con los patrones]

 

Pero... me suena raro que quieran hacer historias de usuario sobre requisitos no funcionales, que es algo que no recomiendo, salvo que esté originado en un problema de negocio concreto (por ejemplo, la App se pone demasiado lenta cuando hay más de N usuarios).

Las cartas de Tarot están pensadas para discutir esos temas con la gente de negocio *en el contexto* de una historia funcional. 

Trataría de que para los atributos que quieren mejorar definan y anoten explícitamente:

Contexto

¿Por qué es importante este tema? Entender la operación detrás de este tema en un proceso concreto. No pensar que la aplicación tiene que escalar a tantos usuarios, sino lo como 'la transacción de pago de una orden' debe poder soportar tantas sesiones concurrentes.

Métrica 

¿Cómo vamos a medir que estamos en el nivel que queremos? Siguiendo el ejemplo anterior, puede ser cuánto tiempo demora para 1, 5, 10 o 30 transacciones concurrentes, y ponerle tiempos JUNTO con la gente de negocio.

Esto luego, idealmente se escribe en pruebas automatizadas que corren al menos en el build nocturno. 

Decisión 

¿Cómo hacemos para lograr esa métrica?

Acá es donde nos concentramos en 'lo técnico'. ¿Hacemos un componente que escale en threads? ¿Usamos una queue? ¿Cuál? Esto se va a convertir en una o más tareas, de una o más historias.

El Kyū-Dan de la Integración Continua

En algún momento del 2014, tuve una consulta de mi amigo Sebis Henzenn, que generó (estaba lejos y tenía un rato)  un mail con una explicación bastante larga de lo que se me ocurrió en ese momento como una metáfora aproximada de los pasos de aprendizaje respecto a prácticas relacionadas con Integración Continua y sus derivaciones.

El mensaje quedó guardado unos años, pero lo recordé recién hablando con otro amigo, Edson Chávez, de Kleer Perú, donde estoy en este momento.

Así que aquí va mi elucubración de esa vez, que no sufrió mucho cambios en el ínterin. Sólo aclararía que no es una categorización exhaustiva, sino un recorrido posible, que espero que le sirva a alguien para formular sus planes al respecto.

Aquí el texto original:

Mi recomendación es empezar por el build server, e ir evolucionando. Por ejemplo:

Cinturón blanco:
- instalás Team City (o Jenkins, o el que te guste -salvo TFS que yo no recomendaría).
- empezás haciendo que cada equipo aprenda a configurar su proyecto (es importante que sepan hacerlo ellos)
- lo básico es que en cada commit el proyecto compile, por lo menos
- que se acostumbren a no tener el proyecto en rojo NUNCA. Si queda en rojo, arreglarlo antes de seguir con nada.

Cinturón amarillo:
- pueden empezar a hacer tests (si no los hacen) y correrlos en el build en cada commit.
- de nuevo: nunca dejarlo en rojo, y aprovechar los arreglos para entender más lo que los demás están haciendo y nivelar la calidad de las pruebas.

Cinturón naranja:
- empezar a hacer TDD y ATDD, y elevar el número de pruebas
- seleccionar alguna manera de medir code coverage y hacer que el build falle si ni se alcanza el 1% (pruebas mínimas)
- cada tanto medir el coverage promedio de la solución e ir subiendo el límite casi hasta ahí (incrementalmente)
- cada vez que se reporta un incidente o bug (en testing o producción), no puede arreglarse si no se escribe la prueba primero que demuestra el problema, y se da por resuelto una vez que se corrige la aplicación para que pase ese test

Cinturón verde:
- empezar a ejecutar analizadores estáticos, y que el build server muestre el informe.
- concentrarse en los problemas más importantes; cuando ya no existen en la solución, hacer que rompan el build
- seguir con el problema más importante, y así sucesivamente; alcanza con eliminar un tema o dos por sprint

Cinturón azul:
- empezar a versionar junto al código migraciones de bases de datos, configuraciones y scripts de instalación de componentes o librerías
- hacer que si el build server compiló con éxito y ejecutó todas las pruebas y validaciones, genere desde cero un entorno nuevo de testing

Cinturón marrón:
- trabajar en conjunto con el equipo responsable de despliegue para que valide y adopte los scripts y métodos de generación de ambientes
- lograr que el build server genere en cada commit un ambiente de prueba desde cero, y otro incremental
- lograr que si se detecta un problema en el ambiente incremental, se pueda volver a la versión anterior de la aplicación con el script de reversión

Cinturón negro:
- cada vez que un desarrollador hace un commit que pasa todo el pipeline de pruebas y validaciones en csda uno de los ambientes de prueba, potencialmente puede llegar a producción de manera automática, aunque se opte por decidir manualmente el momento de despliegue
- trabajar en el diseño de la solución para que soporte el desplliegue sin interrupciones de servicio (hot deploy)

Cinturón rojo:
- cada vez que un desarrollador hace un commit, llega a producción sin interrupción de servicio

 

Cada uno de esos saltos puede llevar de 1 a 9 meses, dependiendo del equipo, el proyecto, y de dónde arrancar en cada parte, pero creo que te das una idea. :)

[Autobombo] Webinar de Arquitectura Ágil + Yoseki Coding Dojo semana que viene en RubyConf

Como avisé antes, el tag [autobombo] hace explícito que un post de este blog está referido a actividades en las que estoy directamente involucrado.

En este caso, quiero compartir el video (de ~50 minutos) del Webinar sobre Arquitectura Ágil que di anoche. 

 

Para los interesados en el tema, dejo links a la presentación original (muy similar a la del video) y al paper de hace unos años con el amigazo Diego Fontdevila en el Architecture Journal.

Para ver algunos de los comentarios durante el webinar, o posteriores, pueden mirar lo que quedó en Twitter bajo el hashtag #KleerArqAgil.

 

 

Por otro lado, si están interesados en la RubyConf Argentina, no se olviden que el próximo martes 26 de noviembre es el Ruby Fun Day, el evento anterior a la conferencia compuesto por talleres prácticos sobre diversos temas. Atención que este día es en la UP, no en Ciudad Cultural Konex como la conferencia.

En ese día de 15:30 a 17:30 voy a estar facilitando nuestro tradicional Yoseki Coding Dojo, edición Ruby. Si andan por ahí, pasen a saludar y avisen que leen este blog. :)

 

Libros gratuitos sobre Arquitectura de Aplicaciones Open Source

La arquitectura de software es un terreno interesantísimo que más allá de que uno pretenda o no ser Arquitecto como perfil profesional, es importante para todo desarrollador, porque tiene que ver con la estructura de lo que construimos y con cómo tomamos las decisiones respecto a ella. Como en el caso del diseño de un producto, no es algo que se pueda evitar, cuando uno no dedica tiempo a la arquitectura, el producto final tendrá muy probablemente una estructura deficiente o endeble, pero no dejará de tenerla.

De todas maneras, este es un terreno que siempre pareció de cierta sofisticación, y que por lo tanto no ha generado mucho material libre y gratuito, salvo últimamente, de la mano de sitios web como InfoQ ó High Scalability, que publican informes detallados o algunos libros breves.

En este caso se trata de un esfuerzo conjunto, coordinado por Amy Brown y Greg Wilson como editores, y una larga lista de colaboradores, que compila, en dos volúmenes, reseñas de la arquitectura de aplicaciones de código abierto, explicadas por expertos en el tema, a veces coautores o parte del equipo del proyecto. En algunos casos se cubren familias o ecosistemas de aplicaciones, en lugar de productos individuales.

Todo el material está disponible de manera gratuita en el sitio web, bajo licencia Creative Commons Attribution 3.0 Unported, pero para quienes prefieran leerlo en Kindle u otro dispositivo electrónico, está disponible una versión paga cuyos derechos se donan íntegramente a Anmesty International.

Los dos tomos están en inglés, y cubren unas 25 aplicaciones populares cada uno.

Algunos ejemplos del Volumen I son: Asterisk (la plataforma de telefonía), Audacity (el editor de audio), Eclipse, el file system distribuido de Hadoop, mecanismos de integración continua, el ecosistema LLVM, Mercurial, Python Packaging, Selenium WebDriver y otros.

Algunos ejemplos del Volumen II son: Arquitectura Web Escalable y Sistemas Distribuidos, Ingeniería de Actualizaciones de Firefox, el compilador Glasgow Haskell, Git, el Dynamic Language Runtime y la familia de lenguajes Iron (IronPython, IronRuby, etc), MediaWiki, Moodle, nginx, PyPy, Twisted, ZeroMQ y otros.

La cantidad de material es impresionante y los temas están muy bien cubiertos, a gran nivel de detalle técnico.

Video: BDD, por Jorge Gamba, desde el Campus Party Colombia

Campus Party es un enorme evento de tecnología que se realiza en diversas partes del mundo, cubriendo muchas facetas de la vida digital, incluyendo desarrollo de software.

La semana pasada se realizó la quinta edición de este evento en Colombia, en la ciudad de Bogotá, y nuestro amigo Jorge Gamba, incansable organizador de las actividades de Alt.NET Hispano, estuvo allí haciendo una presentación excelente sobre Behavior Driven Development, uno de sus temas predilectos.

Dejo para ustedes el video debajo (~56 minutos, en español) para que lo disfruten, y pueden leer muchos más detalles en su propio post sobre la sesión. Debajo del video dejo también sus slides para quienes quieran verlos en más detalle (en el video se aprecian bastante bien, de todas maneras).

Slides:

Video: Migrando el modelo de negocio de SaaS a PaaS, por Andrés Vettori

Esta es la última de las sesiones de la reciente Jornada de Arquitectura de Software organizada por el MUG en UADE, a cargo de Andrés Vettori, CTO de VMBC y reconocido miembro de la comunidad de desarrollo en Argentina.

De hecho, Andrés es casi un prócer para mucha gente, desde hace muchos años, estando al frente de un equipo de desarrollo dentro de una multinacional metalúrgica de capital argentino, donde tuvo la oportunidad de liderar muchos proyectos de software de base por donde pasaron muchos de los desarrolladores más conocidos y respetados en el mercado local actualmente, que aprendieron con él mucho sobre la manera de encarar los problemas, lidiar con tecnología cambiante y balancear las presiones del negocio con una visión de largo plazo.

Andrés es también autor de Retina, uno de los primeros ORM para .NET, y un blogger técnico muy afilado.

En la charla, Andrés cuenta cómo la sofisticación del tipo de aplicaciones que desarrolla su equipo para los clientes de su compañía exigían cada vez más flexibilidad y menores tiempos de desarrollo y puesta en marcha, por lo que lentamente fueron virando su modelo y la arquitectura subyacente de Software como Servicio (SaaS) a una Plataforma como Servicio (PaaS) que brinda mejor soporte a su equipo, permitiendo separar los esfuerzos de aplicaciones propiamente dichas del desarrollo de la plataforma subyacente. La presentación está disponible en su Skydrive.

Video: ¿Dónde quedó SOA?, por Roberto Schatz

Llegando casi al final de las sesiones de la reciente Jornada de Arquitectura de Software organizada por el MUG en UADE (nos queda una más), le toca el turno a Roberto Schatz, figura emblemática de las Arquitecturas Orientadas a Servicios.

Roberto fue uno de los responsables de la estrategia de Servicios de Banco Galicia en Argentina, construyendo un ecosistema SOA basado en mainframe, y adelantando en mucho el área de Arquitectura internamente, cuando esta disciplina todavía no era demasiado reconocida. Conozco grandes profesionales surgidos de ese grupo, hoy distribuidos por el mundo y con una importante carrera iniciada junto a Roberto.

Años después Roberto se convirtió en el líder de Arquitectura de Software dentro de Microsoft, iniciando actividades junto a la comunidad como los Desayunos de Arquitectos, que aún continúan después de varias generaciones de anfitriones en Microsoft Argentina. Por esa época tuve la oportunidad de colaborar con Roberto en varios proyectos, sobre todo en el sector público, realizando entrenamientos y ayudando a organizaciones a construir aplicaciones.

Más recientemente Roberto estuvo a cargo del área de Arquitectura de ANSES, la Administración Nacional de la Seguridad Social en Argentina, uno de los organismos más grandes y complejos en el país, con aplicaciones que soportan millones de operaciones diarias de toda la ciudadanía.

En esta sesión Roberto recorre un poco el escenario histórico de SOA y algunos de los problemas principales que este estilo encontró en el camino, desde la exageración de los proveedores hasta la paradójica inconsistencia de los estándares. Sin embargo, él sigue rescatando los pilares conceptuales de SOA, y explica por qué sigue siendo relevante, aunque en lugar de basarnos en SOAP utilicemos otros protocolos.

Dejo debajo los cuatro segmentos de unos 15 minutos cada uno.

Video: Arquitecturas y Organizaciones, por Diego Fontdevila (+ invitación)

Comparto con ustedes otros de los vídeos de la reciente Jornada de Arquitectura de Software organizada por el MUG en UADE. Esta vez le toca el turno a Diego Fontdevila y su sesión sobre las similitudes y ecos entre las arquitecturas de software y las organizaciones que las construyen o mantienen.

Diego es uno de los socios fundadores de Grupo Esfera, una empresa dedicada a consultoría, desarrollo y capacitación con fuerte foco en la plataforma Java y otras tecnologías de software libre. Diego también es docente en la UBA, UNTREF y UNLAM, y está estudiando en el programa de Software Engineering Management de Carnegie Mellon y el SEI.

Nos conocimos durante Agiles 2008, la primer edición de las jornadas latinoamericanas, y nos hicimos amigos a través de los años y las actividades conjuntas en torno a esta comunidad. Tuvimos la oportunidad de colaborar en algunos proyectos e incluso publicamos juntos un paper sobre arquitectura y métodos ágiles que también presentamos varias veces, siempre agregando detalles.

En esta sesión Diego habla sobre la relación entre las formas de las organizaciones y las estructuras tecnológicas que engendran, y cómo es altamente improbable poder quitarles la impronta que una impone a la otra, aportando visiones de diferentes disciplinas e ideas de varios autores y vertientes. La sesión da para un intenso debate o mas participación, y para eso Diego va a repetirla la semana próxima en la próxima reunión de Agiles @ Buenos Aires. Como siempre, este evento es abierto y gratuito, pero requiere registro previo.

Les dejo el video, en 4 partes de 15 minutos aproximadamente.

Video: Arquitectura Orientada a la Web, por Diego Gonzalez

Siguiendo con las sesiones de la reciente Jornada de Arquitectura de Software organizada por el MUG en UADE, esta vez publico el video de la sesión de Diego Gonzalez acerca de arquitecturas centradas en la web.

Diego es uno de los fundadores de Lagash, una consultora argentina que se ha expandido a algunos otros puntos de América Latina, y que es reconocida en el mercado por la capacidad de su gente y por un espíritu innovador y creativo a la hora de resolver problemas, del que Diego es parcialmente responsable con sus socios. Desde hace muchos años tengo el placer de trabajar de tanto en tanto con Diego y su equipo, e incluso hemos llegado a compartir una cátedra de Arquitectura de Software.

En su sesión, Diego realiza algunas consideraciones generales en cuanto a arquitectura, y después indaga en las características que la web ayudó a establecer, y a una serie de tendencias que le parecen las más importantes a tener en cuenta en aplicaciones modernas.

Dejo a continuación las cuatro partes del video, de unos 15 minutos cada una.

Video: Lenguajes dinámicos meta-circulares, por Hernán Wilkinson

En la reciente Jornada de Arquitectura de Software organizada por el MUG en UADE, Hernán Wilkinson presentó esta sesión sobre lenguajes dinámicos en el contexto de entornos meta-circulares, un valor agregado a las características básicas de los tipos dinámicos.

Hernán es uno de los principales especialistas locales en programación y diseño orientado a objetos, uno de los miembros fundadores de FAST (la Fundación Argentina de Smalltalk) y organizador de la conferencia anual internacional Smalltalks que se realiza en Argentina en diversas localidades, en forma rotativa (la edición 2011 está corriendo hoy mismo en Quilmes).

Actualmente Hernán es uno de los socios de 10pines, una consultora de entrenamiento y desarrollo de software especializada en metodologías ágiles y buenas prácticas de ingeniería.

En la sesión (de una hora aproximadamente) podrán verlo explicar conceptos generales sobre lenguajes dinámicos, puntualizando la diferencia entre tiempos de evaluación y chequeo de tipos, y profundizando luego en la diferencia de flujo de trabajo al efectuar TDD en entornos meta-circulares como una imagen de Smalltak.

No tengo disponibles los slides de la sesión, pero una buena parte de la presentación incluye ejemplos sencillos en Java y en Smalltalk, con lo que el video es más importante. Van a continuación las cuatro partes de aproximadamente 15 minutos cada una.

Jornada de Arquitectura de Software en Buenos Aires (gratuita)

El próximo viernes 28 de octubre, en la UADE (Lima 717, puerta M, Ciudad de Buenos Aires) el Grupo de Usuarios Microsoft de Argentina organiza una jornada dedicada a Arquitectura de Software.

La arquitectura de software es un área sumamente interesante para todos los que llevamos un tiempo en la industria, aunque también está plagada de planteos grandilocuentes y excesos.

En esta jornada que he tenido el placer de coordinar, y en la que voy a realizar una breve apertura, he tenido especial cuidado en convocar a personalidades que conjugan un amplio marco teórico con una extensa carrera práctica y un estilo pragmático y realista a la hora de encarar la labor de arquitectura, lejos de las torres de marfil y muy cerca de los problemas reales de los clientes, y trabajando codo a codo con los equipos de desarrollo, de los que son un miembro más.

La jornada es gratuita pero requiere inscripción previa.

El programa comprende:

11:30 Acreditación y café 
12:00 Apertura: De vuelta a la sencillez - Martin Salias
12:30 Lenguajes dinámicos y su impacto en ambientes meta-circulares - Hernán Wilkinson
13:30 Web Oriented Architecture - Diego Gonzalez
14:30 Coffee break
15:00 Ecosistemas sociotécnicos: Idilios y desencuentros entre arquitecturas y organizaciones - Diego Fontdevila
16:00 ¿Dónde quedó SOA? Nuevos modelos corporativos - Roberto Schatz
17:00 Virando el modelo de negocio de SaaS a PaaS - Andrés Vettori
18:00 Cierre

Creo que va a ser un evento muy interesante y disparador de muchísimas ideas. Si alguno de los asistentes lee este blog, me encantaría conocerlos. ¡Nos vemos!

Videos desde el pasado: arquitectura

Toda empresa toma decisiones dolorosas, debatibles o erróneas, pero finalmente tenemos que aceptarlas aunque no nos gusten si están dentro de los términos que aceptamos en su momento.

En estos días, Google anunció que va a eliminar el contenido subido a Google Video (que ahora es solamente un índice), lo que significa que varios millones de videos van a perderse en el tiempo. El 29 de abril (en 10 días más) todo este material se va a ir, pero al menos dejaron la posibilidad de que uno descargue los videos que había subido y los mueva a otro lado.

Lamentablemente lo que se puede descargar no es el video original, sino la versión en formato FLV procesada por Google en su momento (estimo que el original no deben haberlo guardado), así que los que pude recuperar no están en el mejor de los formatos, pero me pareció interesante la oportunidad de compartirlos.

En esta primera tanda comparto tres sesiones mías del año 2007, presentadas dentro de una serie sobre arquitectura de software en el MUG, que di a lo largo de varios meses entre Buenos Aires y Rosario. No todas quedaron registradas, pero estas tres si, y aunque el tiempo se nota, las republico porque en su momento tuvieron buena recepción.

La primer sesión es una introducción al modelo arquitectónico REST (Representational State Transfer), que hoy está sumamente difundido, pero en aquel momento todavía era algo novedoso. Sobre el final menciono un libro de Rails que en esa época todavía no era RESTful por omisión.

Los dos siguientes son parte de una serie de Casos de Arquitectura, que eran charlas en las que analizaba la manera en que estaban construidas algunas aplicaciones fuera de lo común, en particular en cuanto a escalabilidad, que era un tema menos frecuente en ese entonces (antes de la explosión de las redes sociales, por ejemplo). Además de las sesiones sobre Joost y Google Search que publico aquí abajo, recuerdo haber hablado sobre Second Life, YouTube (a meses de haber sido adquirido por Google), EBay y Amazon, entre otros.

El primero de los dos casos, Joost, aún existe pero se convirtió en un sitio web de nicho que perdió la gracia del proyecto original que utilizaba una red peer-to-peer para transmitir video en muy buena calidad con un consumo limitado de ancho de banda.

El segundo caso lo dediqué a Google Search, que a pesar de haber crecido muchísimo, sigue trabajando sobre premisas similares. Muchas de las tecnologías que explico en la sesión, como Bigtable, el Google File System o MapReduce están ahora disponibles como proyectos de código abierto o como parte de Google App Engine.