Serie de arquitecturas evolutivas (parte 4)

“¿Le apetece un café de acompañamiento?”

“Arquitecturas evolutivas” es una serie de blogs de cuatro partes que ilustra 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 la tercera entrada del blog se describe cómo la startup comienza a desarrollar su arquitectura para incluir herramientas como las canalizaciones de CI/CD y la infraestructura como código, así como la implementación de prácticas recomendadas, especialmente en torno a la seguridad y la autenticación. En la parte 4, vemos cómo la startup Ejemplo formaliza su postura en materia de seguridad y copias de seguridad para cumplir diversas normas de conformidad. También establecen una estrategia de datos para la organización y exploran líneas de negocio adicionales para diversificar su cartera de productos.

Uso de la financiación de serie B para contratar, ampliar y escalar

Las cosas van todo lo bien que pueden para la startup Ejemplo. Acaban de cerrar una ronda de financiación de serie B con la que esperan poder realizar algunas contrataciones, expansiones y ampliaciones muy necesarias. Con la financiación y la adopción por parte de los clientes, también ha llegado una competencia cada vez mayor. Los competidores bien establecidos en el sector están empezando a verlos como serios competidores y están intensificando sus esfuerzos en materia de marketing.

La startup Ejemplo empieza a contratar para ampliar las áreas funcionales y crear equipos dedicados a la ingeniería de fiabilidad del sitio (SRE), la plataforma, el análisis y la ciencia de datos. Debido a la competitividad del mercado laboral y a que la startup carece de un departamento de recursos humanos dedicado, vuelven a ponerse en contacto con su account team de AWS para preguntar sobre la búsqueda de talentos técnicos que dominen AWS. Resulta que el account team ya ha ayudado a otros clientes de startups en situaciones similares, sugiriéndoles socios de AWS que pueden ayudarlos con sus necesidades de contratación. Al poco tiempo, la startup tiene en su bandeja de entrada correos electrónicos de numerosos candidatos con experiencia en AWS. Afortunadamente, muchas de las entrevistas se convierten en ofertas de trabajo y la startup puede tachar la contratación de su lista de tareas pendientes.

La avalancha de contrataciones conduce a un problema técnico: los equipos se quejan de que el platform team de la startup Ejemplo tarda demasiado en crear cuentas nuevas para realizar pruebas y esto está frenando la innovación. El platform team explica que no disponen del ancho de banda necesario para crear cuentas individuales cada vez que alguien tiene una nueva idea para una característica. Llegados a este punto de su andadura en AWS, el platform team tiene una reunión quincenal con su account team de AWS y le plantean su dilema. El solutions architect (SA) de AWS recomienda crear una unidad organizativa (OU) dedicada a los entornos aislados dentro de su organización de AWS para proporcionar con rapidez recursos y entornos temporales a otros equipos que deseen poner a prueba servicios y características nuevos de AWS. Además, para mantener los costos bajo control, el SA recomienda utilizar la automatización para interrumpir automáticamente recursos como las instancias de Amazon EC2 fuera del horario laboral normal. El platform team de la startup Ejemplo sigue el consejo del SA. Son capaces de crear rápidamente cuentas para los diferentes equipos de la startup y hacerlo con unos costos controlados.

Tras esto, el SRE team que se ha contratado recientemente comprende que la startup puede estar mejor posicionada desde el punto de vista de la disponibilidad y la recuperación de desastres (DR). Reconocen que la startup está creciendo rápidamente y que, a medida que empiece a dirigirse a clientes más grandes, se enfrentará a requisitos de seguridad más estrictos, como auditorías y revisiones de cumplimiento. Esto implica la necesidad de algún cambio en la infraestructura. Por suerte, gran parte del trabajo pesado de recuperación de desastres se lleva a cabo cuando la startup Ejemplo planifica su infraestructura en Terraform y realiza la transición a una arquitectura multicuenta en la parte 3 de la serie.

Como primer paso, el equipo de la startup Ejemplo se familiariza con AWS Resilience Hub para obtener más información sobre la creación de aplicaciones resilientes en AWS. El equipo aún tiene algunas consultas pendientes, por lo que se pone en contacto con el account team de AWS, que les presenta a un SA con experiencia en resiliencia. El SA trabaja con la startup Ejemplo para especificar sus requisitos de objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO) y hacer un análisis de los costos y beneficios de diferentes casos hipotéticos de recuperación de desastres. Tras unas cuantas llamadas con el SA y mucha deliberación interna, el SRE team decide que sus requisitos de RTO y RPO no exigen una configuración multirregión por el momento. Toman la decisión de trasladar sus datos transaccionales de Amazon RDS para PostgreSQL a Amazon Aurora para PostgreSQL, principalmente por la mayor disponibilidad que ofrece, así como por la funcionalidad de la Base de datos global de Amazon Aurora, que es importante para su base de datos de producción. La startup también utiliza AWS Audit Manager para evaluar su cumplimiento de las normas de conformidad pertinentes para la próxima auditoría. Su funcionalidad automatizada de recopilación de pruebas les ahorra mucho trabajo manual.

Creación de una mejor experiencia del cliente

Tras analizar los comentarios de varios clientes sobre el producto, el chief technology officer (CTO) se da cuenta de que las funciones de panel que se ofrecen a los operadores en la aplicación de comercio de la startup Ejemplo son insuficientes. Los competidores permiten a los usuarios ver fácilmente una representación visual del historial de operaciones y del rendimiento (en comparación con otros operadores) con respecto a cada operación. El CTO considera que se trata de una carencia importante y asigna el proyecto al nuevo analytics team. Además, el CTO quiere que el equipo permita a los operadores generar informes de comercio cuando quieran.

El analytics team tiene experiencia previa con Amazon QuickSight, por lo que el componente del panel será fácil de mejorar, incluida una característica para la detección de anomalías con el fin de ayudar a los operadores a encontrar operaciones específicas que sean atípicas. La solicitud de informes es más compleja, ya que no quieren molestar a los equipos de desarrolladores ejecutando esos informes en la base de datos de producción (tampoco se consideraría una práctica recomendable). Tras consultar el documento técnico Modern Data Architecture on AWS, el analytics team se da cuenta de que la mejor forma de hacerlo es cargar los datos de Amazon RDS para PostgreSQL en Amazon Redshift, un repositorio para el almacenamiento de datos. Al utilizar el gran paralelismo de Amazon Redshift, podrán ejecutar agregaciones complejas contra estos datos transaccionales con mucha menos latencia y con la ventaja agregada de no producir cuellos de botella en la base de datos de producción. El analytics team está encantado de descubrir que, dado que Amazon Redshift se ha creado sobre el motor PostgreSQL, pueden reutilizar la mayoría de sus consultas.

Incorporación de una nueva línea de negocio a la startup

Mientras se producen todos estos cambios, la chief executive officer (CEO) asiste a una reunión con uno de sus excompañeros en una importante empresa de comercio. Se entera de que hay escasez de operadores en activo en el mercado, lo que está afectando negativamente a la contratación de personal y a los proyectos futuros de la empresa. La CEO llama a algunos de sus amigos de empresas de comercio, que le confirman que se trata de una escasez en todo el sector. La CEO empieza a forjarse una idea: la startup Ejemplo tiene muchos operadores que rinden bien. ¿Qué pasaría si la startup Ejemplo proporcionara a sus operadores algún tipo de capacitación en grupo, que luego sirviera como medio de caza de talentos para estas empresas de comercio? Daría a los operadores la oportunidad de entrar en el mercado laboral y las empresas de comercio tendrían profesionales nuevos.

Dado que una parte fundamental de la capacitación consistiría en recomendar las operaciones correctas a los nuevos aprendices, la CEO organiza una llamada con el data science team para saber con qué rapidez pueden crear un modelo de machine learning (ML). Afortunadamente, parte del data science team tiene experiencia previa en la creación, capacitación e implementación de modelos con Amazon SageMaker. Como Amazon Redshift es uno de los orígenes de datos disponibles para SageMaker, el data science team no tendrá que configurar una canalización compleja de extracción, transformación y carga (ETL). Los miembros del data science team que tenían menos experiencia con SageMaker asistieron invitados por su account team de AWS a una jornada de inmersión centrada en SageMaker para actualizar rápidamente sus conocimientos. En poco tiempo, ellos también empezaron a crear trabajos de capacitación, crear modelos precisos e implementar los modelos en los puntos de conexión. Anticipándose a la llamada del finance team de la startup Ejemplo en relación con los costos de computación cada vez mayores, el data science team investigó un poco y descubrió que en realidad podían ejecutar sus trabajos de capacitación (que representan aproximadamente el 80 % de sus costos totales) en instancias de spot. Al hacerlo, pudieron reducir significativamente sus costos.

A medida que la noticia de esta iniciativa de desarrollo profesional como nueva línea de negocio y fuente de ingresos se extiende entre el sector, más empresas de capital riesgo (VC) comienzan a manifestar su interés por la startup Ejemplo, incluso antes de que la startup exprese su intención de iniciar otra ronda de recaudación de fondos.

Unos trimestres más tarde, guiada por las iniciativas de marketing, la labor de marketing conjunta con AWS y algo de boca a boca de los clientes existentes, la iniciativa de desarrollo de personal con talento de la startup Ejemplo había crecido rápidamente. Aunque el crecimiento de la base de clientes es emocionante, más emocionante es el hecho de que la startup está, por primera vez desde su creación, ¡en números verdes! La contratación resulta ser un negocio rentable para la startup y crece día a día. El executive team se da cuenta de que este flujo de rentabilidad constante podría estimular al resto de su negocio. Trabajan con diligencia en nuevos planes de expansión e innovación, entusiasmados por el futuro increíble que les espera.

Resumen

A lo largo de esta serie de cuatro partes, la startup Ejemplo recorre las principales etapas de una startup, desde su nacimiento hasta que se convierte en una empresa consolidada. La mayoría de las startups comienzan con poco más que una idea atrevida y un equipo de fundadores dedicado. Crean el producto mínimo viable (MVP) con una infraestructura sin servidor que les permite probar su idea de una forma que el equipo fundador puede administrar por sí mismo.

A medida que la startup capta clientes que pagan y consigue financiación postsemilla, avanza hacia la fase de “tener algo entre manos”, en la que su arquitectura evoluciona y se empieza a pensar seriamente en la escalabilidad, la seguridad y la agilidad del desarrollo. Esto implica mejoras como el uso de herramientas de compilación y la creación de bases de datos personalizadas y de supervisión.

Una de las lecciones más importantes durante estas etapas es colaborar con el equipo de AWS desde el principio y con frecuencia, incluso antes de iniciar los proyectos, para ayudar a evaluar las opciones y ahorrar tiempo. El acceso a recursos tanto empresariales como técnicos puede acelerar los plazos y ayudar a los equipos de las startups en fase inicial a alcanzar sus objetivos.

Después de la fase de adecuación del producto al mercado, las startups pueden empezar a contratar más y a centrarse principalmente en la ampliación: la fase “de aquí a la luna”. En este punto, empiezan a considerar una estrategia multicuenta, con una arquitectura orientada al servicio, almacenamiento en caché y otros ajustes arquitectónicos para optimizar su aplicación y mejorar la experiencia del cliente desde una perspectiva técnica.

Por último, entran en la fase de hiperescalado, en la que pueden empezar a realizar contrataciones a gran escala y crear líneas de negocio adicionales. Desde una perspectiva técnica, la startup ha invertido mucho tiempo y esfuerzo técnico en mejorar aspectos como la seguridad y los controles y permisos de su entorno. Es probable que tengan una versión codificada de su entorno que puedan utilizar para una expansión internacional rápida y para la recuperación de desastres, entre otros casos de uso. También han creado una estrategia de datos y están en proceso de utilizar el análisis y el machine learning para comprender mejor a sus clientes y su negocio. Esta fase final puede presentar variaciones. Algunas startups se encontrarán en proceso de adquisición, mientras que otras buscarán la rentabilidad y el dominio del mercado.

¿Está listo para emprender el viaje de su startup? Únase a AWS Activate para crear y escalar su startup con los recursos adecuados en el momento oportuno.

Consulte toda la serie de arquitecturas evolutivas:

• Arquitecturas evolutivas (parte 1): “Tengo una gran idea”.
• Arquitecturas evolutivas (parte 2): “Creo que tenemos una buena idea”.
• Arquitecturas evolutivas (parte 3): “De aquí a la luna”.