Muchas de las lecciones que aprende en empresas más grandes no se pueden aplicar directamente a la primera pila de una startup. En la fase de exploración inicial de un producto, debe optimizar la implementación para mejorar la velocidad, el costo y la opcionalidad. La opcionalidad hace referencia a la rapidez con la que puede cambiar las direcciones dentro de una arquitectura determinada.
Una empresa en las fases de expansión o extracción del desarrollo del producto puede utilizar una arquitectura orientada al servicio o de microservicios. Este tipo de arquitectura de implementación pocas veces es adecuado para una startup que aún no ha encontrado la tracción comercial o el ajuste de producto o mercado adecuado.
Para una pila de inicio principal, resulta mejor un diseño monolítico sencillo. Este diseño limita el tiempo dedicado a administrar la infraestructura, a la vez que proporciona una capacidad amplia de escalado a medida que la startup gana más clientes.
Posibles casos de uso
En este artículo se presenta un ejemplo de una pila de startup principal sencilla y se analizan sus componentes.
Architecture
Contoso, una startup, ha creado un prototipo de aplicación con un back-end Ruby on Rails y un front-end React escritos en TypeScript. El equipo de Contoso ha ejecutado demostraciones en equipos portátiles. Ahora, los miembros del equipo quieren implementar la aplicación para su primera reunión de ventas con un cliente.
Si bien la aplicación es exigente, todavía no necesita una arquitectura compleja controlada por microservicios. Contoso optó por un diseño monolítico sencillo que incluye los componentes recomendados de pila de startup.
Descargue un archivo Visio de esta arquitectura.
Flujo de datos
En esta arquitectura de pila de startup principal:
- Azure App Service proporciona un servidor de aplicaciones sencillo para implementar aplicaciones escalables sin tener que configurar servidores, equilibradores de carga u otro tipo de infraestructura.
- Azure Database for PostgreSQL es un servicio de base de datos de Azure para un sistema de administración de bases de datos relacionales (RDBMS) de código abierto líder. Puede concentrarse en desarrollar la aplicación en lugar de administrar servidores de base de datos.
- Azure Virtual Network segmenta el tráfico y protege los servicios internos frente a amenazas de Internet. Los servidores de aplicación utilizan la integración de red virtual para comunicarse con la base de datos sin exposición a Internet.
- Acciones de GitHub traslada la integración continua e implementación continua (CI/CD) a la administración del código fuente. Acciones de GitHub tiene una compatibilidad amplia con varios lenguajes y una integración sólida con los servicios de Azure.
- Azure Blob Storage almacena recursos estáticos y aleja la carga de los servidores de aplicación.
- Azure Content Delivery Network (CDN) acelera la entrega de contenido a los usuarios a través de una red global.
- Azure Monitor supervisa y analiza lo que sucede en toda la infraestructura de la aplicación.
Componentes de la pila de startup principal
Una pila compleja puede generar errores que requieren atención constante. Una arquitectura sofisticada podría dificultar la creación del producto. Los errores no se deben a la complejidad, pero una pila compleja facilita el envío de errores. No todas las arquitecturas sofisticadas son un desperdicio de energía, sino que desperdician los recursos si todavía no encuentra el producto o mercado adecuado. La primera pila de startup debe ser sencilla y no ser una molestia, de manera que pueda concentrarse en desarrollar el producto.
En el diagrama sencillo siguiente se muestra la pila de startup principal recomendada. Estos componentes son suficientes para que el producto exista y llegue a manos de los clientes. Para el 80 % de las startups, esta pila es todo lo que necesita para probar las hipótesis básicas integradas en el producto. Las startups que trabajan en el aprendizaje automático, en la Internet de las cosas (IoT) o en entornos muy regulados pueden requerir más componentes.
CDN
Con pocos clientes al principio, una red CDN puede parecer prematura. Sin embargo, agregarla a un producto que ya está en producción puede tener efectos secundarios inesperados. Es mejor implementar una red CDN por adelantado. Una red CDN almacena en caché contenido estático más cerca de los clientes y proporciona una fachada detrás de la cual puede iterar en las API y la arquitectura.
Servidor de aplicaciones
El código se debe ejecutar en algún lugar. Idealmente, esta plataforma debe facilitar las implementaciones, a la vez que requiere la menor entrada operativa posible. El servidor de aplicaciones se debe escalar horizontalmente, pero se permite cierta intervención de escalado manual mientras sigue en la fase de exploración.
Al igual que ocurre con la mayoría de esta pila, el servidor de aplicaciones debe ejecutarse a sí mismo. Tradicionalmente, el servidor de aplicaciones era una máquina virtual o una instancia de servidor web que se ejecutaba en un servidor sin sistema operativo. Ahora, puede buscar opciones y contenedores de plataforma como servicio (PaaS) para quitar la sobrecarga operativa.
Contenido estático
Distribuir el contenido estático desde el servidor de aplicaciones es un desperdicio de recursos. Una vez que configura una canalización de CI/CD, el trabajo para compilar e implementar recursos estáticos con cada versión es trivial. La mayoría de los marcos web de producción implementan recursos estáticos con CI/CD, por lo que resulta buena idea alinearse con este procedimiento recomendado.
Base de datos
Una vez que se ejecuta la aplicación, debe almacenar los datos en una base de datos. En la mayoría de los casos, la mejor solución es una base de datos relacional. Una base de datos relacional tiene varios métodos de acceso y la velocidad de una solución probada en el tiempo. Entre las bases de datos relacionales se incluyen Azure SQL Database, Azure Database for PostgreSQL y Azure Database for MariaDB. Algunos casos de uso necesitan una base de datos de documentos o una base de datos NoSQL como MongoDB o Azure Cosmos DB.
Agregación de registros
Si hay algún problema con la aplicación debe dedicar el menor tiempo posible a diagnosticar el problema. Al agregar registros y usar el seguimiento de la aplicación desde el principio, permite que su equipo se centre en los problemas mismos. No es necesario que acceda a un archivo en el servidor de aplicaciones y analice los registros para obtener los datos de supervisión.
CI/CD
La falta de implementaciones repetibles y rápidas es uno de los peores impedimentos para acelerar la iteración en un producto. Una canalización de CI/CD bien configurada simplifica el proceso de implementación de código en el servidor de aplicaciones. Las implementaciones rápidas y sencillas significan que puede ver los resultados de su trabajo rápidamente. La integración frecuente evita bases de código divergentes que generan conflictos de fusión mediante combinación.
Implementación de este escenario
Los conceptos y las técnicas son iguales para la mayoría de los proyectos que compila mediante un archivo Dockerfile.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- Andrew Harvey | Director de tecnología y promotor de startup