Desarrollar sistemas de software escalables es una estrategia, no una religión. Es crucial revisar sus arquitecturas con una mentalidad abierta.
Las arquitecturas de software no se asemejan a las arquitecturas de puentes y edificios. Una vez que se construye un puente, es difícil, si no imposible, modificar su estructura. Por el contrario, el software presenta una dinámica diferente: al ejecutarlo, se puede adquirir información sobre las cargas de trabajo que no estaban presentes durante el diseño inicial. Si desde un principio se hubiera considerado esta posibilidad y se hubiera optado por una arquitectura evolutiva, sería factible cambiar componentes sin afectar la experiencia del usuario. Mi recomendación general es que con cada incremento significativo en el crecimiento, se debe revisar la arquitectura para asegurar su capacidad de soportar el siguiente nivel de expansión.
Un excelente ejemplo se encuentra en dos entradas de blog escritas por los equipos de ingeniería de Prime Video. El primero describe la infraestructura detrás de la transmisión en vivo de Thursday Night Football , basada en una arquitectura de flujo de trabajo distribuido. El segundo es una publicación reciente que explora la arquitectura de su herramienta de monitoreo de transmisiones y cómo su experiencia y análisis los llevaron a implementarla como una arquitectura monolítica. No existe una solución única para todas las situaciones. Siempre se alienta a nuestros ingenieros a buscar la mejor solución sin imponer un estilo arquitectónico específico. Al contratar a los mejores ingenieros, se debe confiar en su capacidad para tomar decisiones acertadas.
Siempre se insta a los desarrolladores a considerar la evolución de sus sistemas a lo largo del tiempo y garantizar que la base establecida permita realizar cambios y expansiones con el menor número de dependencias posible. Las arquitecturas basadas en eventos (EDA) y los microservicios constituyen una combinación efectiva para lograr este objetivo. Sin embargo, cuando existe un conjunto de servicios que contribuyen constantemente a la respuesta, comparten los mismos requisitos de escala y rendimiento, los mismos aspectos de seguridad y, sobre todo, son administrados por un mismo equipo, resulta beneficioso analizar si fusionarlos simplificaría la arquitectura.
En Amazon, hemos tomado en serio la creación de arquitecturas escalables desde sus inicios. Reevaluamos y rediseñamos nuestros sistemas para cumplir con las crecientes demandas de nuestros clientes. Regresando a 1998, un grupo de ingenieros de alto nivel redactó el Manifiesto de Computación Distribuida, que marcó el comienzo de la transición de Amazon de ser un monolito a adoptar una arquitectura orientada a servicios. En las décadas siguientes, hemos continuado evolucionando, pasando de los microservicios a los microservicios en infraestructura compartida y, como mencioné en re:Invent, también los EDA.
La transición hacia sistemas autónomos desacoplados fue un progreso natural. Los microservicios son más pequeños y fáciles de gestionar, pueden emplear tecnologías adecuadas para satisfacer los requerimientos empresariales, permiten tiempos de implementación más cortos, facilitan el progreso de los desarrolladores, posibilitan la adición de nuevos componentes sin interferir con el sistema completo y, lo más crucial, si un microservicio falla, el resto del sistema sigue funcionando. Cuando el servicio se restaura, reproduce los eventos perdidos y los ejecuta. Esto es lo que conocemos como una arquitectura evolutiva, que puede adaptarse fácilmente con el tiempo. Comienza con algo básico y permite que se desarrolle en complejidad de acuerdo con tu visión.
Amazon S3 es un ejemplo sobresaliente de un servicio que ha evolucionado desde unos pocos microservicios en su lanzamiento en 2006 hasta más de 300 microservicios, con implementaciones adicionales de políticas de almacenamiento y clases de almacenamiento. Esto solo fue factible gracias a la capacidad de evolución de la arquitectura, un aspecto crítico en el diseño de sistemas.
No obstante, es importante señalar que no existe un único patrón arquitectónico universal. La forma en que optes por desarrollar, implementar y administrar servicios siempre estará determinada por el producto en cuestión, las habilidades del equipo involucrado y la experiencia que desees ofrecer a los clientes (además de consideraciones como costos, velocidad y resiliencia). Por ejemplo, una startup con cinco ingenieros podría elegir una arquitectura monolítica por su facilidad de implementación y la ausencia de necesidad de aprender múltiples lenguajes de programación. Sus necesidades difieren fundamentalmente de las de una empresa con múltiples equipos de ingeniería, cada uno gestionando un subservicio individual. Y esto está bien. Se trata de seleccionar las herramientas adecuadas para el trabajo.
Hay pocas decisiones unidireccionales. Evaluar tus sistemas de forma periódica es tan crucial, si no más, que construirlos inicialmente. Ya que tus sistemas estarán en funcionamiento durante mucho más tiempo del que llevó diseñarlos. Así que, los monolitos no están obsoletos (todo lo contrario), pero las arquitecturas evolutivas desempeñan un papel cada vez más relevante en un entorno tecnológico en constante cambio, gracias a las tecnologías en la nube.
¡Ahora, a construir!