Como arquitecto de la nube, una de mis principales responsabilidades es diseñar la arquitectura de los servicios SaaS. Esta responsabilidad ha resultado ser un desafío, incluso complicado, especialmente cuando se trata de arquitecturas sin servidor.
He tenido numerosos casos en los que pude pensar en varias soluciones candidatas a un problema y tuve que elegir entre ellas.
¿Debería utilizar el patrón SNS-> SQS? ¿o EventBridge?
¿Debería utilizar DynamoDB o Aurora RDS Serverless?
¿Debería utilizar Elasticache o DynamoDB con DAX?
Verá, a veces no está claro qué solución candidata es mejor.
Todos los candidatos a la solución cumplen los requisitos, pero cada candidato tiene sus pros y sus contras.
En estos casos de uso, necesitaba pautas claras que me ayudaran a diferenciar las soluciones y tomar una decisión. Mi gerente me sugirió que escribiera una plantilla de diseño para ayudarme a tomar decisiones.
Así fue como esta plantilla llegó a manifestarse.
Entonces, en esta publicación de blog, encontrará mi plantilla de diseño de alto nivel recomendada que lo ayudará a definir e inspeccionar sus soluciones y, finalmente, elegir la que mejor se adapte a sus requisitos.
La documentación es clave
Sí, no es divertido escribir documentación y puede llevar mucho tiempo, PERO tiene muchos beneficios.
Para empezar, documentar su proceso de pensamiento y sus elecciones de diseño puede ayudarlo a elegir entre soluciones y ofrecer una visión clara y sin obstáculos de sus opciones.
En segundo lugar, sirve como justificación para cualquier futura parte interesada en cuanto a las consideraciones y opciones existentes en el momento de redactar el documento.
En tercer lugar, los requisitos del producto pueden cambiar en el futuro y afectar a la solución y la arquitectura. Siempre es bueno especificar los requisitos que tenía en ese momento, ya que afectan a la solución elegida.
Por último, la nube cambia constantemente. Se lanzan nuevas arquitecturas, servicios y capacidades de servicio durante todo el año. Una documentación concreta y clara puede ayudarle a refactorizar la arquitectura en el futuro, ya que señala las limitaciones, los trucos o las soluciones alternativas que consideró e implementó.
Estructura de la plantilla
A continuación se presenta mi recomendación para una estructura de plantilla de diseño de alto nivel.
Siéntete libre de cambiarlo como creas conveniente.
Estado
Valores posibles: [Borrador, En revisión, Aprobado, Implementado, Retirado]
Es fundamental mantener un registro del diseño. Es fácil perderse en diseños antiguos que ya no son relevantes.
Asegúrese de comenzar el diseño con el estado "Borrador".
Una vez realizado, cambia al estado “En revisión” y, una vez aprobado, al estado “Aprobado”. Una vez finalizada la implementación, el estado cambia al estado “Implementado”.
Sin embargo, el estado más crucial, en mi opinión, es el de “Jubilado”.
Cuando crea un nuevo diseño que reemplaza al actual “Implementado” y lo hace redundante, establezca el estado en “Retirado” y agregue un enlace a la página de diseño actualizada.
Terminología
En esta sección, debe explicar las expresiones, definiciones y descripciones de las partes interesadas comunes relacionadas con su servicio.
Imagine que su documentación de diseño es leída por desarrolladores y arquitectos que no están familiarizados con su servicio o dominio del problema y desean revisarlo.
Contexto
En esta sección debes describir el problema que deseas resolver de forma orientada al cliente.
Suposiciones
Describe todos los supuestos que se consideran durante el proceso de diseño.
El equipo de producto debe aceptar estas suposiciones, ya que probablemente afecten la experiencia general del usuario.
Requisitos funcionales
Aquí es donde la cosa se pone interesante.
En esta sección debes definir qué debe hacer el servicio y sus características y funciones.
"En general, los requisitos funcionales describen el comportamiento del sistema en condiciones específicas". - altexsoft.com
Sería útil vincular aquí la documentación de requisitos de cualquier equipo de producto como referencia.
No dude en desafiar al equipo de producto y exigir un conjunto claro y sencillo de requisitos funcionales, ya que son fundamentales para diferenciar entre posibles soluciones.
Por ejemplo:
Manejar X sesiones de usuarios concurrentes por segundo.
Admite las siguientes consultas de filtro en tu llamada API: filter1, filter2, filter3...
Implementar el servicio en regiones específicas: región1, región2.
Cuanto más precisos sean los requisitos, mejor será su investigación y comparación de soluciones.
Requisitos no funcionales
En esta sección, debe describir las propiedades generales de la arquitectura, también conocidas como atributos de calidad.
Debes tener en cuenta los siguientes parámetros:
Costo: estimación de costos por mes, considerando la arquitectura y los requisitos concretos del producto (sesiones de usuario por segundo, etc.). Para AWS, utilice la calculadora de precios de AWS.
Pruebas de rendimiento: definen un conjunto de pruebas/consultas/valores numéricos que pueden ayudar a estimar el rendimiento/los cuellos de botella en el mundo real.
Resiliencia
¿Tiene un mecanismo de copia de seguridad automática? ¿Es necesario construirlo uno mismo?
¿AWS lo gestiona por completo? ¿Tiene alta disponibilidad? ¿En cuántos nueves?
¿Es compatible con múltiples regiones?
Multiinquilino (si corresponde): defina el enfoque recomendado para multiinquilino en la solución (silo, pool, puente). Lea más aquí .
Cumplimiento: defina el mínimo requerido, FedRamp High, SOC2, etc. ¿Su solución lo admite o lo requiere?
Cuotas: especifica los límites de la arquitectura y las cuotas esenciales.
¿Requiere una nueva dependencia del SDK?
¿Es sencillo de integrar y utilizar en su código de servicio?
Facilidad de implementación: AWS CDK/Serverless/Terraform:
¿Tiene una construcción AWS CDK de alto nivel?
¿Requiere una VPC?
¿La implementación demora mucho tiempo?
¿Se requiere más tiempo para investigar las mejores prácticas (investigación de esquemas de bases de datos, políticas de seguridad)?
Opciones consideradas
Para cada solución candidata, proporcione una breve descripción con enlaces a subpáginas donde proporcione:
Diagramas completos de arquitectura/flujo de la solución candidata.
Describe cómo responde a los requisitos funcionales.
Describa en detalle todas las especificaciones de requisitos no funcionales, desde los resultados de pruebas de costo y rendimiento hasta cada uso e implementación.
Incluya cualquier imagen relevante de la consola de AWS.
Proporcione resultados detallados de pruebas de rendimiento. ¿La solución candidata es viable en términos de rendimiento?
Análisis de riesgos: ¿está utilizando un SDK alfa? ¿El servicio de AWS es nuevo? ¿La documentación o la experiencia del usuario son deficientes? Enumere cualquier posible inconveniente que se le ocurra.
Matriz de decisión ponderada
La matriz de decisión ponderada convierte las conjeturas y las intuiciones en una conclusión científica respaldada por números.
Dado que todas las soluciones candidatas deben satisfacer los requisitos funcionales, el foco de esta matriz debe estar en los requisitos no funcionales.
Los pesos son el multiplicador de valores de cada criterio y representan la importancia del criterio a nuestros ojos.
Cada uno de los requisitos no funcionales (del uno al ocho) recibe un peso.
Para nuestro ejemplo, utilizaremos pesos de 1 a 5.
Es esencial discutir esto internamente con su equipo y obtener la aprobación de todos, ya que estos pesos afectan la puntuación final de la solución.
Cada solución recibe una puntuación según cada criterio. La puntuación puede ser de uno a tres.
Por ejemplo, 1-3 marcas significan:
Uno representa la satisfacción del requisito mínimo.
Dos representa una satisfacción razonable.
Tres representa lo mejor de la clase.
Una vez que se establece un criterio de calificación, se puede calcular la puntuación del criterio multiplicando el peso por la calificación.
Examinemos la tabla siguiente:
Queremos distinguir entre dos soluciones: A y B.
Nuestros requisitos no funcionales, en este caso, son "resiliencia", "facilidad de uso" y "costo".
Cada requisito recibe un peso:
La resiliencia obtiene un peso de 3 sobre 5
Facilidad de uso 1 (menos importante para el equipo en este caso)
El costo obtiene 5 de 5, lo que lo convierte en el requisito más importante para el equipo.
La solución A recibió las siguientes calificaciones: 3 de un máximo de 3 por su resistencia, 3 de un máximo de 3 por su facilidad de uso y 3 de 3 por su costo. ¡Qué gran triunfador!
La solución B, por otro lado, recibió 2 de un máximo de 3 por resiliencia, 3 de un máximo de 3 por facilidad de uso y 2 de 3 por costo.
La solución con mayor puntuación será la solución que usted declarará como la solución elegida.
En este caso, la solución A es la solución preferida con 27 puntos.
Resumen de la decisión
En esta sección explica por qué elegiste la solución seleccionada.
Debería ser la solución que recibió más puntos en la tabla de comparación ponderada.
Describa brevemente los pros y contras de la solución.
Eso es todo; el documento de diseño está completo.
¿Me he olvidado de algo? Si tienes alguna sugerencia o comentario, escríbelo en la sección de comentarios que aparece a continuación.
Gracias, Meitar Karas, por sugerirme que cree esta plantilla y por presentarme el concepto de matriz ponderada en la toma de decisiones.
Comments