En la parte 2 de esta serie , aplicamos los conceptos presentados por primera vez en la parte 1 y diseñamos un inicio ficticio de software de citas en línea llamado eTumble. Producimos “documentos vivos” para nuestra estrategia, diseño y arquitectura. El propósito de esta publicación es reunir todo y planificar la infraestructura necesaria para hacer realidad nuestra idea y adaptarse a nuestras futuras necesidades de escala.

Requisitos previos para seguir adelante

• Has leído la parte 1 de la serie .
• Está familiarizado con los marcos / metodologías que exploramos a continuación al menos viendo los enlaces de video compartidos en la parte 1
• Has leído la parte 2 de la serie .

Sin escribir una sola línea de código ni gastar dinero , nuestros ejercicios de "documentos vivos" producidos en la parte 2 revelaron los requisitos del sistema que informan nuestras futuras necesidades de infraestructura de alojamiento:

No es necesario que satisfagamos todas las necesidades "más allá" de inmediato, pero tenerlas en cuenta al diseñar y construir nuestro MVP puede ayudar a minimizar la repetición del trabajo. ¡Exploremos cómo!

Alcance inicial de MVP basado en story map y OGSM

eTumble se está preparando para convertirse en la próxima gran novedad en las citas en línea. Nuestro equipo sabiamente se tomó el tiempo para realizar un análisis FODA, documentó nuestro plan estratégico de 3 a 5 años utilizando el Marco OGSM, visualizó y priorizó nuestro MVP utilizando Story Mapping, y diseñó y documentó nuestra arquitectura utilizando partes de la metodología del Modelo C4.

Nuestro plan OGSM identificó una meta inicial de 25 000 usuarios en el año 1 y tácticas para alcanzar nuestra meta, como un programa de recomendaciones y demostraciones en campus universitarios. Después de múltiples iteraciones de mapeo de historias, nos decidimos por nuestro alcance de MVP y lo escribimos .

Si nos saltamos la planificación estratégica para identificar la importancia de las promociones, es posible que no hayamos iterado lo suficiente en el mapa de la historia para establecer el MVP, lo que ayuda a priorizar lo que construimos primero. Aún más aterrador, es posible que lo hayamos llamado "Mike's Match Maker" (arriba) en lugar de nuestro nombre más genial, eTumble. ;-)

Poner nuestro MVP en manos de los usuarios previstos rápidamente nos dará una mejor comprensión del dominio del problema y, en consecuencia, afectará las decisiones a nivel estratégico y de ideación. Es por eso que nuestros planes se denominan "documentos vivos" y deben repetirse con el tiempo a medida que aprendemos.

Selección de nuestra plataforma de alojamiento en la nube

La selección de un proveedor de alojamiento en la nube puede convertirse en un ejercicio político o religioso dentro de cualquier organización o equipo. Prefiero utilizar un enfoque basado en datos para estas decisiones y describí cómo lo hicimos en una empresa anterior en esta entrevista de BrightTALK en 2020.

En partes anteriores de esta serie, eludí el hecho de que usaremos Google Cloud Platform (GCP), por lo que explicaré brevemente mi enfoque típico.

Orquesté este proceso en organizaciones anteriores, y una tenía una línea de productos con una estrategia móvil primero, por lo que mis razones para seleccionar GCP se derivan de mi experiencia previa y de brindar soporte a miles de empresas en DoiT. AWS Amplify es una solución de la competencia, pero se queda corta en comparación con GCP Firebase utilizando muchos de los criterios anteriores, especialmente la facilidad de uso.

Este artículo entra en más detalles comparando los dos marcos móviles populares, GCP Firebase vs. AWS Amplify , pero está detrás del muro de pago de Medium. El consenso fue que Firebase era más completo, más fácil de usar y podría ser más rentable.

Independientemente de la plataforma que elija, hemos identificado los requisitos de nuestro sistema tanto a corto como a largo plazo. Supongamos que pasamos por el proceso de evaluación anterior, seleccionamos GCP por varias razones y ahora tenemos que diseñar nuestra infraestructura de alojamiento en la nube.

Automatización de nuestras implementaciones de código fuente

Además de su gente, el núcleo de cada empresa emergente de software es su código fuente: el texto estructurado que se convierte en instrucciones que una computadora puede entender y procesar. Para que nuestros programas lleguen a nuestra audiencia prevista (suponiendo que no haya un "MVP de cortina de humo" en esta etapa), deben implementarse en los entornos de alojamiento elegidos.

Una de nuestras estrategias para eTumble es innovar más rápido que otros. Aunque esto puede describir muchos aspectos de un inicio de software, nos centraremos en la velocidad del desarrollador y la velocidad a la que los usuarios finales pueden realizar nuevas funciones (historias de usuarios). Ha habido estudios que prueban que esto es una ventaja competitiva, pero no entraremos en todos los detalles de DevOps y DevSecOps y canalizaciones de CI/CD en este artículo.

Cómo ocurre esto puede ser una preferencia personal del equipo de desarrollo. Muchos proveedores de alojamiento de código fuente (p. ej., Github.com, Gitlab.com o Bitbucket.com) ahora tienen sus propias herramientas. Muchos también ofrecen webhooks cuando ocurren eventos que desencadenan soluciones de terceros. Cada proveedor de alojamiento en la nube también tiene sus propios servicios, como Azure Dev Ops de Microsoft o Cloud Build y Cloud Deploy de GCP.

Normalmente, mi recomendación para la mayoría de las organizaciones es considerar la solución del proveedor de la nube, como mínimo para la fase de "implementación" de sus canalizaciones de compilación, porque elimina la necesidad de compartir claves de cuenta de servicio de larga duración (que pueden verse comprometidas) con un tercero. sistema. GCP ofrece Workload Identity Federation que le permite asignar roles de IAM a una solución de terceros sin compartir claves, que también es una opción.

Consideraciones para escalar en la nube

Monolito o no

Afrontémoslo, la mayoría de las empresas emergentes de software de éxito mundial en la actualidad comenzaron como una aplicación monolítica de 3 niveles. No hay nada malo con los monolitos en la etapa inicial. El acoplamiento minimiza muchas complejidades técnicas y, como implican las "topologías de equipo", estas decisiones a menudo tienen que ver con la carga cognitiva de su equipo . Con una meta de 25 000 usuarios en nuestro primer año y un enfoque en el campus universitario, este es un diseño completamente aceptable para lo que se contempla en nuestro MVP.

El problema a menudo ocurre cuando comienzas a escalar. Sin embargo, no temas, porque podemos diseñar nuestra solución "rápida y sucia" para tener en cuenta fácilmente nuestra futura arquitectura de microservicios.

En nuestros diagramas de arquitectura del Modelo C4, identificamos "Controladores" en la vista de componentes, para la aplicación "Backend API". Las filas que indican la publicación de mensajes en Pub/Sub, por ejemplo, podrían incluir inicialmente la lógica del microservicio dentro de la aplicación API en la capa "Modelo" de la arquitectura Model-View-Controller (MVC). Las rutas API siguen siendo las mismas.

Al tener en cuenta los microservicios, podemos mover la funcionalidad "Modelo" fuera de la aplicación API a servicios separados y comunicarnos a través de HTTP/RPC o mensajería asincrónica. Si planifica con anticipación, puede diseñar una capa contenedora para las llamadas a funciones o métodos que interactúan inicialmente con una capa de datos y la transición a llamadas remotas en el futuro con cambios mínimos en el código.

Sin embargo, si ha diseñado suficientes sistemas distribuidos, puede optar por una arquitectura basada en eventos, como se ilustra en nuestro diagrama de contenedores.

Ir "sin servidor" o usar contenedores

Al comienzo de esta serie de 3 partes, afirmé que las nuevas empresas de software de hoy tienen una ventaja sobre las de hace cinco o diez años, en parte debido a los proveedores de nube de hiperescala. Los productos sin servidor como AWS Lambda, Google Cloud Functions o incluso Azure Functions son un gran ejemplo. Los desarrolladores pueden enviar su código a estos "tiempos de ejecución" y beneficiarse de la ausencia de mantenimiento de la infraestructura y del escalado automático.

Si bien este parece ser el enfoque obvio para lanzar su MVP, tenga en cuenta el campo minado de deuda técnica que planta en el camino. Algunos de estos servicios ofrecen un emulador para que pueda compilar y probar localmente, lo que ayuda a reducir la dependencia y el costo de otro entorno.

Prefiero aprovechar las soluciones sin servidor para pequeños trabajos asincrónicos de un solo propósito que se desencadenan por eventos en su sistema como "archivo cargado o modificado" o "mensaje publicado".

Para crear una API que enrutará las solicitudes a varias piezas de back-end, una aplicación en contenedores puede ser una opción más inteligente. Dado que todas las dependencias están empaquetadas en la imagen, los contenedores simplifican el desarrollo y las pruebas locales. La mayoría de los proveedores de alojamiento en la nube ofrecen una solución de contenedor "sin servidor" como ECS en AWS y Cloud Run o App Engine Flexible en GCP.

Prefiero la portabilidad de los contenedores para aplicaciones más complejas y, si sigue los principios de la metodología de aplicación de 12 factores , también reducen el riesgo de que la configuración se desvíe hacia diferentes entornos en su canalización de CI/CD.

Priyanka Vergadia en Google proporciona una colección de "notas de bocetos" y esto a continuación que ilustra " Dónde debo ejecutar mis cosas " es una guía útil.

Aprovechar los grupos de correo electrónico para escalar de uno a muchos equipos

Supongamos que comenzamos con unas pocas personas, pero nuestro plan eventualmente requiere brindar soporte a decenas de millones de usuarios en muchos países. Sin duda, escalaremos nuestra organización para incluir muchos equipos y especialistas (el eje Y y el eje Z del cubo de escala de AKF también se aplican a nuestra organización).

La mejor práctica al configurar la gestión de acceso e identidad (IAM) con plataformas en la nube es asignar roles a grupos en lugar de usuarios individuales. En un artículo que escribí hace un par de años sobre la estructuración de empresas en la nube , explico los grupos iniciales recomendados y mucho más.

los grupos que establecemos en una etapa temprana pueden escalar con la organización (solo los miembros cambian con el tiempo)

Aunque nuestra startup empiece con tres personas, nada nos impide definir grupos y añadir personas a varios de ellos para empezar . A medida que contratemos a más personas, podemos ir dejando los grupos a los especialistas.

A escala empresarial, eventualmente podría separar más a los equipos según las necesidades y las demandas de carga cognitiva. No importa por dónde empiece, la mejor práctica es otorgar roles de IAM en la nube a grupos, en lugar de a usuarios individuales, para que sea más fácil mantenerlos y minimizar la repetición del trabajo . Observe el patrón aquí.

Diseño de su jerarquía de recursos en la nube para múltiples inquilinos

Esta lista de verificación de referencia segura de GCP que escribí hace un par de años incluye un ejemplo ilustrativo del diseño de mejores prácticas recomendadas. A medida que diseñamos nuestra arquitectura de nube para nuestro MVP, puede haber algo de trabajo "desechable" durante la etapa inicial, pero aun así recomendé una estructura similar al configurar cualquier jerarquía de recursos de nube.

A medida que la organización escala, avanzando hacia versiones posteriores del producto ilustrado en nuestro mapa de historias de usuario, podemos cambiar a una administración de red centralizada, administración de clústeres de Kubernetes y estructura de equipo de múltiples inquilinos. Esto a menudo hace tropezar a las nuevas empresas de software cuando alcanzan los puntos de inflexión descritos en la parte 1 de esta serie.

puede haber algo de trabajo "desechable" durante la etapa inicial

GCP tiene una excelente referencia que describe cómo establecer la multiempresa empresarial con más detalles. A continuación se muestra una ilustración de cómo se verá la infraestructura de la nube de eTumble en el futuro cuando logremos nuestros objetivos de Y2 y Y3 (ignorando la vista de recursos por brevedad del artículo).

El punto clave aquí es notar que los proyectos iniciales de carpetas de servicios compartidos nunca cambian, y los grupos que establecimos en una etapa temprana pueden escalar con la organización (solo los miembros cambian con el tiempo). Cada inquilino (equipo) mantiene sus recursos específicos, como bases de datos y secretos, en sus respectivos proyectos, y se hace referencia a ellos desde las aplicaciones en contenedores implementadas en clústeres en sus respectivos espacios de nombres.

Sistemas externos (autenticación, pagos, correo electrónico, etc.)

Nuestro plan y diseños ilustraron la necesidad de sistemas externos como correo electrónico transaccional, pagos en línea y posiblemente identidad y autenticación. Al seleccionar proveedores de soluciones externas, tenga en cuenta lo siguiente:

• múltiples entornos para pruebas y producción con autenticación separada
• mantenimiento y rotación de credenciales en un almacén secreto cifrado
• incentivos comerciales disponibles para ser comprados a través del mercado

¡Felicitaciones por llegar tan lejos! Esta serie de 3 partes lo lleva en un viaje desde metodologías y marcos útiles, hasta el diseño de un inicio de software desde cero y, finalmente, el uso de "documentos vivos" para planificar la infraestructura de la nube para la etapa inicial y posterior.

• Parte 1: antecedentes e introducción a la metodología
• Parte 2: implementación de metodologías con startup ficticia
• Parte 3: diseñar y escalar la infraestructura de la nube

Espero que tome estos principios y termine donde lo dejamos para ayudar a resolver la soledad a escala planetaria . ;-)

Si cree que esta serie será útil para otros, no la mantenga en secreto. Dele a cada parte un poco de “amor” y aplausos, y comparta con los demás. ¡Gracias por leer!