Arquitectura de pila de startup principal
Muchas lecciones que aprende en empresas más grandes no se aplican directamente a la primera pila de un inicio. En la fase de exploración inicial de un producto, debe optimizar la implementación para la velocidad, el costo y la opcionalidad. 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 de productos podría usar una arquitectura orientada a servicios o microservicios. Este tipo de arquitectura de implementación rara vez es adecuado para un inicio que aún no ha encontrado tracción comercial o producto.
Para una pila de inicio principal, es mejor un diseño monolítico sencillo. Este diseño limita el tiempo dedicado a administrar la infraestructura, a la vez que proporciona una amplia capacidad de escalado a medida que el inicio gana más clientes.
Casos de uso potenciales
En este artículo se presenta un ejemplo de una pila de inicio principal sencilla y se describen sus componentes.
Arquitectura
Un inicio, Contoso, ha creado un prototipo de aplicación con un back-end ruby on Rails y un front-end react escrito en TypeScript. El equipo de Contoso ha estado ejecutando demostraciones en sus portátiles. Ahora quieren implementar su aplicación para sus primeras reuniones de ventas de clientes.
Nota:
Las opciones de tecnología aquí de Ruby, React y TypeScript son ilustrativas. Esta arquitectura de inicio se aplica igualmente a muchos otros lenguajes y marcos de trabajo.
Aunque la aplicación es ambiciosa, aún no necesita una arquitectura compleja controlada por microservicios. Contoso optó por un diseño monolítico sencillo que incluye los componentes recomendados de la pila de inicio.
Descargue un archivo de Visio de esta arquitectura.
Flujo de datos
En esta arquitectura de pila de inicio principal:
Azure App Service proporciona un servidor de aplicaciones sencillo para implementar aplicaciones escalables sin configurar servidores, equilibradores de carga u otra infraestructura. App Service admite implementaciones de contenedores como en el ejemplo siguiente y también admite implementaciones sin contenedor para ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP o Python.
Azure Database for PostgreSQL es un servicio de base de datos de Azure para un sistema de administración de bases de datos relacionales de código abierto líder (RDBMS). Puede concentrarse en desarrollar la aplicación en lugar de administrar servidores de bases de datos.
Azure también tiene servicios de base de datos administrados para SQL, MySQL, MongoDB, Apache Cassandra, Gremlin y Redis.
Además de las ofertas administradas, Azure Marketplace también incluye bases de datos usadas en arquitecturas de inicio, como CockroachDB, Neon Serverless Postgres y SQLite.
Azure Virtual Network segmenta el tráfico de red y mantiene protegidos los servicios internos frente a amenazas de Internet. Los servidores de aplicaciones usan la integración de red virtual para comunicarse con la base de datos sin exposición a Internet.
Acciones de GitHub compila la integración continua y la implementación continua (CI/CD) en la administración del código fuente. Acciones de GitHub tiene una amplia compatibilidad con diferentes lenguajes e integración sólida con los servicios de Azure.
Azure Blob Storage almacena recursos estáticos y mueve la carga fuera de los servidores de aplicaciones.
Azure Front Door con WAF acelera y protege la entrega de contenido a los usuarios a través de una red de entrega de contenido global (CDN) y un firewall de aplicaciones web.
Azure Monitor supervisa y analiza lo que sucede en la infraestructura de la aplicación.
Componentes principales de la pila de inicio
Una pila compleja puede generar errores que requieren atención constante. Una arquitectura sofisticada podría desatraer 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, pero desperdician sus recursos si aún no ha encontrado ajuste al producto o al mercado. La primera pila de inicio debe ser sencilla y salir de su camino, por lo que puede concentrarse en el desarrollo de productos.
En el siguiente diagrama sencillo se muestra la pila de inicio principal recomendada. Estos componentes son suficientes para sacar el producto del suelo y en manos de sus 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 aprendizaje automático, Internet de las cosas (IoT) o entornos altamente regulados pueden requerir más componentes.
CDN
Con pocos clientes al principio, una red CDN podría parecer prematura. Sin embargo, agregar una red CDN a un producto ya en producción puede tener efectos secundarios inesperados. Es mejor implementar una red CDN por adelantado. Una red CDN almacena en caché el 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 debe ejecutarse en algún lugar. Idealmente, esta plataforma debe facilitar las implementaciones, al tiempo que requiere la menor entrada operativa posible. El servidor de aplicaciones debe escalar horizontalmente, pero algunas intervenciones de escalado manual están bien mientras todavía se encuentra en la fase de exploración.
Al igual que la mayoría de esta pila, el servidor de aplicaciones debe ejecutarse básicamente. 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 de plataforma como servicio (PaaS), como App Service anteriormente y contenedores para quitar la sobrecarga operativa.
Contenido estático
El servicio de contenido estático del servidor de aplicaciones desperdicia recursos. Una vez configurada 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 merece la pena empezar por alinearse con este procedimiento recomendado.
Base de datos
Una vez que la aplicación se esté ejecutando, debe almacenar los datos en una base de datos. En la mayoría de los casos, una base de datos relacional es la mejor solución. Una base de datos relacional tiene varios métodos de acceso y la velocidad de una solución probada con tiempo. Las bases de datos relacionales incluyen Azure SQL Database y Azure Database for PostgreSQL. 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 algo va mal con la aplicación, quieres dedicar el menor tiempo posible al diagnóstico del problema. Al agregar registros y usar el seguimiento de aplicaciones desde el principio, ayudará a su equipo a centrarse en los propios problemas. No tiene que acceder a un archivo en el servidor de aplicaciones y pore sobre los registros para obtener datos de supervisión.
CI/CD
La falta de implementaciones repetibles y rápidas es uno de los peores obstáculos a la velocidad al iterar 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 los resultados del trabajo se ven rápidamente. La integración frecuente evita las bases de código divergentes que conducen a conflictos de combinación. Los conceptos y técnicas son los mismos para la mayoría de los proyectos que se compilan mediante un Dockerfile.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- Andrew Harvey | Director de tecnología y promotor de inicio
Otros colaboradores:
- Nick Ward | Arquitecto de soluciones en la nube