Table of Contents
Una de las decisiones más difíciles a las que puede enfrentarse su equipo de desarrollo de software a medida que escala es decidir entre mantener su código base actual o reconstruir sobre una nueva arquitectura de software. En este artículo veremos qué es la llamada arquitectura de sacrificio y por qué a veces es mejor construir algo desde cero en lugar de intentar continuar y mejorar lo que ya existe.
Repensar, reestructurar y reconstruir
A veces se necesita menos esfuerzo en términos de tiempo y dinero para construir una solución desde cero. La clave está en repensar, reestructurar y reconstruir. Por supuesto que puede traer un poco de frustración que el trabajo anterior «vaya a la basura», pero en realidad este conocimiento que obtuviste, estas lecciones que aprendiste te llevan a desarrollar un producto mucho más potente y escalable, utilizando las últimas y más rápidas tecnologías.
Espera, ¿pero qué es la arquitectura del sacrificio?
Muchas empresas trabajan en la arquitectura de sacrificio de forma estratégica. A menudo, las empresas construyen una arquitectura de sacrificio cuando crean un producto mínimo viable para probar un mercado, anticipando la construcción de una arquitectura más robusta si el mercado lo aprueba. Construir una arquitectura de sacrificio implica que los arquitectos de software no van a tratar de evolucionarla, sino de sustituirla más adelante.
Por lo tanto, la arquitectura de sacrificio significa aceptar ahora que dentro de unos años el equipo tendrá que desechar lo que está construyendo actualmente. En otras palabras, la arquitectura de sacrificio es una solución a corto plazo para las necesidades actuales, que en la mayoría de los casos se utiliza para ir al mercado más rápido y probar el MVP.
Martin Fowler mencionó una cosa curiosa sobre la arquitectura de sacrificio, dice que también se trata de pensar ahora en las cosas que pueden hacer más fácil el reemplazo cuando llegue el momento, pero los arquitectos de software rara vez piensan en cómo construir una arquitectura para apoyar su reemplazo.
Arquitectura de sacrificio: Estudios de caso
Para empresas tecnológicas muy famosas, la decisión de reconstruir sus sistemas de software desde cero fue una decisión valiente y un éxito masivo. Para otras, las arruinó. Se trata de compensaciones, de ver el panorama general y de calcular con precisión todas las opciones, encontrando soluciones óptimas para su situación específica. Veamos algunos estudios de casos en los que la sustitución condujo a un crecimiento exponencial
Arquitectura de sacrificio de eBay
eBay, una de las empresas más exitosas del mundo, comenzó como un conjunto de scripts en perl construidos durante un fin de semana hace 20 años. Después de 2 años de funcionamiento, se desmontó todo y se sustituyó por un sistema escrito en C++ sobre las herramientas de Windows de la época. Y 5 años después la aplicación se reescribió de nuevo en Java.
La primera pregunta que surge es si estas primeras versiones fueron un error porque fueron sustituidas. ¿Qué diría usted? En la mayoría de los casos, los principales arquitectos de software creen que fue la decisión correcta en ese momento. Ahora, Ebay es uno de los grandes éxitos, pero gran parte de ese éxito se construyó sobre el software descartado de los años 90. La arquitectura correcta para soportar el Ebay de 1996 no es la arquitectura correcta para el Ebay de 2006. La de 1996 no puede manejar adecuadamente la carga de 2006, pero la versión de 2006 es demasiado compleja para construir, mantener y evolucionar para las necesidades de 1996.
Cuando eBay empezó, era como cualquier otra empresa emergente: necesitaban encontrar el conjunto de características que hicieran que la gente utilizara el servicio. Atender a una gran base de usuarios concurrentes no era el reto, sino encontrar el ajuste del producto al mercado. Y esto le ocurre a la mayoría de las startups de hoy en día. No se pueden predecir todos los posibles retos y obstáculos de crecimiento, lo primero es demostrar que tu idea está en demanda.
Analicemos la situación de nuevo. Al principio, eBay necesitaba iterar rápidamente, por lo que Perl tenía sentido. Luego, con el paso de los años, el tráfico aumentó rápidamente, mientras que el conjunto de características se hizo más maduro. En esta nueva fase de crecimiento de la empresa, necesitaban un sistema más estable y escalable. Pasar de Perl a Java parecía una decisión acertada porque Perl no era un lenguaje estricto sintáctica y semánticamente, lo que lo hacía adecuado para el desarrollo rápido pero no ideal para la programación a gran escala. Java, en cambio, está diseñado para que los desarrolladores escriban una vez y lo ejecuten en cualquier lugar. Durante los primeros días, sólo tenían unos pocos usuarios, por lo que no había necesidad de una arquitectura compleja para garantizar una alta disponibilidad de tráfico. Cuando encontraron las características que atraían a los usuarios, el rendimiento y la alta disponibilidad se convirtieron en algo esencial para que el negocio creciera.
Arquitectura de sacrificio en Twitter
En 2020, Twitter lanzó su nueva API pública. El lanzamiento no sólo contenía nuevas características. Era un replanteamiento de la arquitectura general.
«El lanzamiento de hoy marca la reconstrucción más importante de nuestra API pública desde 2012. Se ha construido para ofrecer nuevas características, más rápido, y para servir mejor al diverso conjunto de desarrolladores que construyen en Twitter. También se ha construido para incorporar muchas de nuestras experiencias y lecciones aprendidas durante los últimos catorce años de funcionamiento de las API públicas.»
La API pública de Twitter v1.1 se implementó como un conjunto de microservicios HTTP, alejándose de un monolito. Aunque los microservicios permitieron al equipo de Twitter acelerar el proceso de desarrollo, dieron lugar a puntos finales dispersos y heterogéneos, ya que equipos independientes diseñaron y construyeron para sus propios casos de uso específicos. Twitter necesitaba una nueva arquitectura, ya que la antigua no estaba a la altura de las expectativas futuras. La nueva versión de la API v2 de Twitter tenía que ser más escalable para dar servicio a un gran número de nuevos puntos finales previstos que admiten nuevas funcionalidades. También tenía que ofrecer más consistencia a los desarrolladores externos y reforzar la uniformidad.
En estos ejemplos, eBay y Twitter pasaron por reconstrucciones completas de su arquitectura con el fin de tener sistemas estables y de alto rendimiento que pudieran escalar y soportar nuevas características. Sus antiguas arquitecturas no fueron una pérdida de tiempo; fueron cimientos que tuvieron que sacrificar para llegar a donde están hoy. Lo interesante aquí es que los arquitectos de software no siempre desechan el código porque sea terrible, sino porque las necesidades han cambiado.
Arquitectura de sacrificio de Google
En Google, la regla explícita es diseñar un sistema para diez veces sus necesidades actuales, con la implicación de que si las necesidades superan un orden de magnitud, a menudo es mejor tirar y reemplazar desde cero. Es habitual que los subsistemas se rediseñen y desechen cada pocos años.
En Apiumhub vemos muchos proyectos que tienen un patrón común al entrar en una base de código madura denigrando su falta de rendimiento o escalabilidad. Pero aquí es importante entender que en el período inicial de un sistema de software los equipos están menos seguros de lo que realmente necesita hacer, por lo que a veces es importante poner más atención en la flexibilidad para cambiar las características en lugar de rendimiento o disponibilidad.
«La modularidad es la característica más importante de una aplicación mantenible. La modularidad es el grado en que los componentes de un sistema pueden separarse y recombinarse. Una aplicación modular no es un desperdicio: las partes pueden cambiarse, sustituirse o desecharse sin que ello afecte al resto de la aplicación» Justin Meyer.
Es más fácil escribir código que leerlo. Por eso Martin Fowler sugiere que el equipo que ha desarrollado un software es el que, en última instancia, debe decidir si lo sacrifica y cuándo lo hace.
Además, es importante destacar que el código nuevo no siempre es mejor. El código antiguo ha sido utilizado y probado por usuarios reales, con datos precisos y bajo la presión del mundo real. Se han encontrado y corregido muchos errores, y se han aplicado muchas iteraciones y mejoras. Si la decisión de desechar un código se debe a una «condición if», probablemente todo lo que hay que hacer es un par de iteraciones de refactorización. Cuando el código está en línea con los objetivos de negocio actuales y futuros, entonces no es necesario sacrificarlo.
La arquitectura de sacrificio es una mentalidad que te permite aceptar la idea de renunciar a tu propio código. Elegir el momento adecuado depende exclusivamente de ti.
En conclusión, la arquitectura de sacrificio puede ser una gran manera de aprender, sin embargo, no debe ser una excusa para construir software de baja calidad, ya que será sacrificado de todos modos. No tengas miedo de renunciar a parte de tu propio código, pero hazlo con sabiduría, analizando todas las compensaciones que tienes.
