Serie de arquitecturas evolutivas (parte 3)

“De aquí a la luna 🚀”

“Arquitecturas evolutivas” es una serie de blogs de cuatro partes que muestra cómo los diseños de soluciones y las decisiones evolucionan a medida que las empresas atraviesan las distintas etapas del ciclo de vida de las startups. En esta serie, seguimos la bien llamada startup “Ejemplo”, cuya idea es crear una aplicación de “bolsa de valores de fantasía”, similar a las ligas deportivas de fantasía. Prevén celebrar cuatro “torneos” en el transcurso de un año.

En el segundo blog se describió cómo la startup comenzó a desarrollar sus soluciones técnicas mientras los fundadores se preparaban para recaudar fondos. En la tercera parte, veremos cómo la startup Ejemplo sigue avanzando en la maduración de su oferta tecnológica y en posicionarse bien para crecer.

Escalado eficiente mediante la transición a una arquitectura de microservicios

El fantástico stock trading team está creciendo y se están creando nuevos componentes y soluciones. A medida que la cartera técnica se amplía, comienzan a aparecer ciertas fisuras que requieren la atención del equipo.

“Los viejos hábitos son difíciles de eliminar”, y el equipo comienza a darse cuenta de que esto puede causar problemas para el crecimiento de su startup: los plazos agresivos y el entusiasmo por hacer más con menos están provocando un aumento de la deuda técnica. Un aspecto de esta deuda técnica es la proliferación gradual de monolitos, a diferencia de la arquitectura de microservicios que el equipo había decidido inicialmente. Los problemas relacionados con los sistemas monolíticos, como la escalabilidad y los cuellos de botella en el rendimiento, comienzan a manifestarse durante las pruebas y la introducción de nuevas características. Afortunadamente, el equipo reconoce rápidamente los desafíos que plantea este enfoque monolítico para el escalado óptimo de las cargas de trabajo. Deciden dar un paso atrás y reevaluar sus prácticas de desarrollo. Uno de los desarrolladores recuerda que el solutions architect (SA) de AWS había previsto algunos de estos problemas en una conversación anterior. El equipo de la startup Ejemplo programa una llamada con AWS para obtener ayuda.

Romper los monolitos y hacer la transición a un paradigma basado en microservicios es un tema amplio, por lo que el SA de AWS recomienda un día de inmersión en la modernización de aplicaciones para el equipo de la startup Ejemplo. El día de inmersión utiliza un taller relacionado como telón de fondo, centrado en las cargas de trabajo relevantes para las startups. Al evento asisten casi todos los desarrolladores de la empresa y acaba por cambiar las reglas del juego. En el transcurso de un solo día, el equipo puede aprender a definir, diseñar e implementar correctamente los microservicios. También aprenden a trazar una ruta de migración gradual de una aplicación monolítica a un conjunto de microservicios sin tener que rehacer todo de una vez. El equipo está encantado de detectar sus errores desde el principio y aprender algunas de las prácticas recomendadas que los ayudarán a seguir adelante. El solutions architect también comparte un documento técnico de AWS centrado en las estrategias de modernización que pueden cubrir cualquier falta de conocimiento del equipo de la startup Ejemplo.

La experiencia con la modernización de aplicaciones aporta tanto valor a la startup Ejemplo que el equipo decide aplicar el mismo enfoque de utilizar las prácticas recomendadas existentes para las diferentes áreas funcionales en el futuro. Los ingenieros y product manager programan una llamada para compartir con AWS su hoja de ruta para lo que queda del año, a fin de evitar la duplicación de tareas. La startup Ejemplo ya firmó un acuerdo de confidencialidad mutua (MNDA) con AWS y, durante la conversación, hubo un flujo de ideas productivo y libre entre ambas partes, además de una buena noticia: resulta que una característica que la startup Ejemplo estaba considerando desarrollar por sí misma ya figura en la hoja de ruta de AWS para el próximo trimestre, lo que libera al equipo una parte del tiempo de ingeniería.

El siguiente tema de la lista de áreas que se deben mejorar de la startup Ejemplo hace referencia a la infraestructura como código (IaC), la integración y la entrega continuas (CI/CD) y las pruebas automatizadas. Dos developer operations (DevOps) recién contratados no están satisfechos con muchos de los mecanismos operativos actuales de la startup, especialmente con aspectos como la creación y la prueba de entornos, así como con la administración de los artefactos del código. El crecimiento del equipo de la startup Ejemplo significa que más personas tienen acceso a estos procesos delicados, lo que supone un riesgo innecesario. Los dos nuevos miembros del equipo ya tienen cierta experiencia con Terraform como enfoque de IaC. Están encantados de saber que Terraform tiene una gran compatibilidad con AWS y de descubrir otras herramientas, como AWS CloudFormation y AWS CDK, en caso de que necesiten una alternativa. Sin embargo, aún necesitan ayuda con la configuración de su CI/CD. Hasta ahora, sus intentos carecen de cohesión y resulta difícil hacer que su herramienta de creación funcione bien con su herramienta de implementación. Además, siguen buscando un enfoque adecuado para administrar las imágenes de sus contenedores. El equipo de AWS recomienda probar AWS CodePipeline porque satisface sus necesidades de integrar sin problemas una herramienta de creación y una de implementación y también incluye pruebas automatizadas, todo ello junto con la compatibilidad con varios entornos. El uso de CodePipeline permite la integración con soluciones que no necesariamente se crearon de forma nativa en AWS, así como una sólida compatibilidad con otras herramientas, como AWS CodeBuild, AWS CodeDeploy y herramientas de terceros. La implementación de CodePipeline permite a la startup Ejemplo solucionar otro elemento importante de su lista.

Con el equipo bien encaminado hacia una implementación adecuada de los microservicios, se sienten capacitados para trabajar en algunos de los otros desafíos complejos que siguen pendientes. Por un lado, la presencia de varios servicios que funcionan de forma independiente plantea naturalmente la cuestión de la comunicación entre estos servicios. Hay un gran interrogante en torno a si cada llamada entre servicios debe ser síncrona o asíncrona en la comunicación, además de cómo el equipo puede empezar a adoptar patrones de prácticas recomendadas, como la mensajería de publicación o suscripción (PubSub). El equipo entiende en general que adoptar una arquitectura basada en eventos sería beneficioso, especialmente si se quieren dejar de lado los monolitos, pero está un poco abrumado por la infinita variedad de servicios de AWS relacionados con esa arquitectura, como, por ejemplo, Amazon EventBridge, Amazon Simple Queue Service (Amazon SQS), Amazon Simple Notification Service (Amazon SNS) y Amazon Managed Streaming para Apache Kafka (Amazon MSK). Esta vez, el equipo puede encontrar que algunos recursos son un excelente punto de partida, como algunos talleres y blogs muy útiles sobre el tema. El paradigma “basado en eventos” se está convirtiendo poco a poco en otra herramienta de la caja de herramientas del equipo.

Desarrollo de una estrategia de seguridad más sólida

La seguridad siguió siendo una prioridad para nuestra startup y herramientas como AWS Startup Security Baseline (AWS SSB) los ayudan a empezar. Lamentablemente, nunca se puede tener demasiada seguridad. La implementación inicial de AWS WAF fue un buen comienzo, pero el equipo debe empezar a pensar de manera más proactiva en la prevención, la detección y la corrección. Empiezan a adquirir habilidades en los numerosos servicios de AWS centrados en la seguridad que pueden ayudarlos a implementar una estrategia de seguridad sólida.

El equipo en crecimiento y la participación de los socios hacen que el control de acceso, los permisos y la gobernanza sean otros temas que requieren cada vez más atención. El equipo está intentando implementar las prácticas recomendadas, como el principio del mínimo privilegio a la hora de aplicar los permisos. Como mínimo, quieren trasladar las cargas de trabajo de producción a sus propias cuentas independientes. A medida que el equipo adopta estas prácticas recomendadas, ven cómo aumenta la complejidad operativa debido a los niveles adicionales de administración y permisos a los que ahora tienen que hacer frente. Rápidamente se hace evidente que necesitan un enfoque mecanizado de la estructura de cuentas. Alguien menciona AWS Organizations, lo que parece un paso acertado, así que se ponen en contacto con su SA de confianza de AWS para hablar. El SA comparte algunos consejos relevantes, como considerar AWS Control Tower como una forma más sencilla de administrar varias cuentas y organizaciones de AWS. Dado que este es el primero de muchos pasos para lograr una estrategia sólida de varias cuentas, el SA de AWS también compartió con el equipo la guía prescriptiva sobre la transición a varias cuentas de AWS. Esta guía incluye las prácticas recomendadas sobre la migración de cuentas, la administración de usuarios, las redes, la seguridad y la arquitectura cuando se pasa a una configuración de varias cuentas.

Optimización de las cargas de trabajo para mejorar el rendimiento

El equipo está abordando algunas piezas fundamentales para que la startup esté bien preparada para crecer al ritmo adecuado. Algunos elementos importantes están tachados de la lista y otros tienen planes de acción establecidos. Los desarrolladores hacen todo lo posible para optimizar el rendimiento de sus cargas de trabajo, pero han identificado algunas oportunidades de mejora que van más allá del código, como el almacenamiento en caché en la periferia con Amazon CloudFront, el almacenamiento en caché en el nivel de la aplicación con Amazon ElastiCache y el almacenamiento en caché de bases de datos. El equipo depende cada vez más de los servicios administrados de AWS para proporcionarles la funcionalidad que necesitan y, al mismo tiempo, reducir al mínimo la complejidad operativa asociada. Otro servicio administrado que algunos de los desarrolladores descubren y encuentran sorprendentemente fácil de usar es AWS Batch. El enfoque inicial de procesamiento de fuentes con AWS Lambda está empezando a alcanzar sus límites debido al aumento exponencial del volumen de datos que deben procesarse. Tras experimentar un poco, los desarrolladores pueden trazar una ruta para usar AWS Batch que les permita seguir creciendo con un aumento relativamente bajo de la carga operativa y manteniendo los costos bajos.

Demostración de la propuesta de valor de su startup

Todo este buen trabajo de la startup Ejemplo no pasa desapercibido. Crear de una manera ágil y sostenible sin depender de soluciones alternativas a corto plazo demuestra que la empresa piensa en el largo plazo, demuestra madurez y tiene la capacidad de ofrecer resultados. Estas características, junto con una solución innovadora y una buena adaptación al mercado de productos, son la base de la propuesta de valor de la empresa. Los fundadores transmiten con éxito el valor de su empresa a dos firmas de capital riesgo diferentes y cierran su primera ronda de financiación de serie A. La startup Ejemplo está de camino a la luna.

Consulte el primer y el segundo blog de la serie de arquitecturas evolutivas.