subscripción
Pensamientos ágiles
Sobre la arquitectura de eBay
Agosto 31st, 2007 - [Enlace local]
En InfoQ (me encanta este sitio) publicaron hace unos días una entrevista a Dan Pritchett sobre la arquitectura de eBay. Se trata de una entrevista muy intersante, mucho más desde que el año pasado se desvelera que eBay evita las transacciones en dos fases siempre que sea posible tratando de mantener el acceso a datos muy simple y rápido aún a riesgo de perder datos (no importantes). Martin Fowler también escribió en su momento sobre esto.
Recojo aquí las notas que me parecen más importantes sobre la entrevista:
- No todos los datos tienen la misma importancia. Llegado al punto en el que escalar se hace extraordinariamente caro y complejo hay que buscar soluciones que se apartan de los patrones tradicionales. A veces estas soluciones implica asumir riesgos de perder datos y evitar las transacciones distribuidas. No pasa nada mientras estos datos no sean críticos para el negocio.
- Uno puede sentirse incómodo con el punto anterior, pero a medida que investigas en como lo hace otra gente que ha afrontado el mismo problema descubres que todo el mundo llega por diferentes caminos a la misma conclusión.
- Uno llega a plantearse la necesidad de una base de datos en algunos casos. Hoy por hoy se utilizan para todo, pero ¿por qué no usar un sistema de ficheros? Hay muchos datos no críticos que pueden almacenarse en otros lugares que permitan un acceso más simple y rápido.
- La escalabilidad no tan sencilla como aparece en los libros: horizontal y vertical. Hay otros factores. Hay que ser capaz de escalar procesos; de sobrevivir al aumento de branches, de desarrolladores o de builds. Hay que ser capaz de escalar los data centers; de conseguir maximizar el número de transacciones por watio consumido.
- Los patrones y principios son necesarios, pero a veces hay que saltárselos. Los patrones que funcionan para sitios normales no tienen porque funcionar necesariamente para sitios que reciben billones de visitas.
- 30 arquitectos para 1500 desarrolladores (in-house). No todos los problemas reciben la atención de un arquitecto. Se delega mucha responsabilidad sobre los desarrolladores. Sólo se asignan arquitectos a tareas que lo requieran.
- Para gestionar todo el desarrollo existen catálogos bien definidos de principios y patrones a aplicar, junto con un repositorio de reglas que se deben seguir para cada servicio. Los desarrolladores deben ser capaces de aplicar el catálogo de patrones correctamente y de solucionar problemas complejos utilizándolos. En caso de tener que romper algún patrón o regla, un comité decide si es apropiado y da el visto bueno.
- Arquitectos que se manchan las manos. Arquitectos que escriben código y que contribuyen al esfuerzo del grupo. Arquitectos que se ganan la credibilidad del resto de desarrolladores a base de código y hechos; no sólo palabras.
- Involucrar a todo el mundo en las reuniones técnicas. Desarrolladores, arquitectos, operaciones, analistas de negocio. Todo el mundo aporta su punto de vista, y todos estos puntos de vista son necesarios a la hora de afrontar un problema de manera efectiva.
Para mi, la mejor entrevista sobre arquitectura que he leido en lo que va de año.
» Leer más, comentarios, etc...