A2A
Lo más importante es su comprensión de lo que está construyendo (propósito, forma, escala …). La arquitectura de un producto que cambiará mucho durante su desarrollo debe ser muy diferente de una arquitectura adaptada a especificaciones bien definidas. La segunda cosa más importante es el equipo que lo construirá. Trataré de ilustrar con dos ejemplos.
Caso 1 : usted es el cofundador técnico de una empresa joven. No conoce muy bien su mercado y, francamente, no está seguro de qué características quieren o no quieren sus clientes, pero debe comenzar a trabajar en un producto. Necesita algo que pueda mostrar a los primeros inversores y prospectos, y utilizar para validar las suposiciones sobre su negocio.
- ¿Por qué no podemos usar un lenguaje de compilación en una aplicación web directamente?
- ¿Qué sitios web o aplicaciones web utilizas constantemente, pero no te encanta usar? ¿De qué servicios cambiaría rápidamente si se presentara una alternativa mejor?
- Para aplicaciones web como Disqus, ¿quién tiene derechos de autor de los comentarios?
- ¿Cómo convertirse en un comerciante de día? ¿Cuánto capital necesita y qué sitios web, aplicaciones web o software se utilizan?
- Cómo construir una aplicación
En esas circunstancias, lo que debe optimizar es la velocidad de iteración a corto plazo. Si desea cambiar algo o agregar una función, debería poder hacerlo rápidamente.
Debería buscar una solución en la que no tenga que preocuparse demasiado por el alojamiento o la administración, algo que simplemente pueda poner en Heroku o ese VPS suyo en unos minutos, y que le permita implementarlo fácilmente varias veces al día. Debería optar por una arquitectura monolítica (aunque todavía esté bien modularizada), y cualquier idioma que conozca mejor, siempre que sea adecuado para un desarrollo web rápido (tiene suficientes bibliotecas de código abierto, etc.). Puede elegir SQL si tiene una experiencia significativa con él o una base de datos NoSQL para la flexibilidad (PostgreSQL es un buen término medio).
Caso 2 : el producto del caso 1 ha sido exitoso, ahora tiene un millón de usuarios. El equipo técnico ha crecido hasta 40 personas. Tienes problemas:
- Hay problemas de rendimiento y parece que su arquitectura se desmoronará en el siguiente orden de magnitud de crecimiento.
- Se ha mudado de su PaaS por razones de costo. Ahora tiene varios servidores y un “equipo de operaciones”; se quejan de lo difícil que es su trabajo.
- Todos sus desarrolladores trabajan en la misma base de código y les resulta problemático. Nadie es claramente responsable de nada. Hay partes de la base de código que nadie conoce.
- Ese esquema de base de datos se está convirtiendo en un monstruo que ya nadie entiende completamente.
Decides conseguir una reescritura. Este es un caso en el que diría que SOA tiene mucho sentido: divida el monolito en bloques separados con interfaces bien definidas. Deben ser verificables de forma independiente, y usted debe organizar su equipo en equipos alrededor de esos servicios.
Los servicios pueden estar en diferentes lenguajes de programación si tienen diferentes requisitos. Puede haber varias bases de datos más simples en lugar de una grande. La velocidad de iteración sigue siendo un objetivo (casi siempre lo es) pero ya no es el único.
Debes apuntar a:
- partes escalables independientemente;
- operaciones y depuración más fáciles en la producción;
- estabilidad, redundancia, copias de seguridad confiables …
Finalmente, me gustaría agregar tres cosas:
- Como dijo Lon Hosford, siempre tenga en cuenta dicha seguridad (y auditabilidad cuando alcance una cierta escala).
- No abogo necesariamente por pasar del paso 1 al paso 2 mediante una reescritura. Puede (y debe) intentar evolucionar gradualmente del caso 1 al caso 2. Pero a veces las personas no hacen eso, dejan que el sistema del caso 1 crezca demasiado hasta que sea demasiado tarde, y luego es mejor comenzar desde una hoja limpia.
- Si aún no ha visto este video, debe verlo:
