Comprensión de la carga de trabajo

Para aplicar el marco, comience por comprender la carga de trabajo que desea analizar. Un diagrama de la arquitectura del sistema proporciona un punto de partida para documentar los detalles más relevantes del sistema. Sin embargo, tratar de analizar una carga de trabajo completa puede resultar complejo, ya que muchos sistemas tienen numerosos componentes e interacciones. En su lugar, le recomendamos que se centre enhistorias de usuarios, que sonexplicaciones informales y generales de las características del software escritas desde la perspectiva del usuario final. Su propósito es articular cómo una función de software proporciona valor al cliente. A continuación, puede modelar estas historias de usuario con diagramas de arquitectura y diagramas de flujo de datos para facilitar la evaluación de los componentes técnicos que proporcionan la funcionalidad empresarial descrita. Por ejemplo, una solución de compra de juegos móviles integrada en una aplicación puede tener dos historias de usuario: «comprar créditos integrados en la aplicación» y «obtener reembolsos integrados en la aplicación», tal y como se muestra en el siguiente diagrama. (Este ejemplo de arquitectura destaca cómo se puede descomponer un sistema en historias de usuario; no pretende representar una aplicación muy resistente).

Cada historia de usuario consta de cuatro componentes comunes: código y configuración, infraestructura, almacenes de datos y dependencias externas. Los diagramas deben incluir todos estos componentes y reflejar las interacciones entre los componentes. Por ejemplo, si hay una carga excesiva en su punto de enlace de Amazon API Gateway, considere cómo esa carga se transfiere en cascada a otros componentes del sistema, como suAWS Lambdafunciones o tablas de Amazon DynamoDB. El seguimiento de estas interacciones le ayuda a comprender cómo el modo de fallo puede afectar a la historia del usuario. Puede capturar este flujo de forma visual con un diagrama de flujo de datos o utilizando flechas de flujo sencillas en un diagrama de arquitectura, como en la ilustración anterior. Para cada componente, considere la posibilidad de capturar detalles como el tipo de información que se transmite, la información que se recibe, si la comunicación es sincrónica o asíncrona y qué límites de falla se están cruzando. En el ejemplo, las tablas de DynamoDB se comparten en ambas historias de usuario, como se puede ver en las flechas que indican que el componente Lambda del historial de reembolsos integrado en la aplicación accede a las tablas de DynamoDB del historial de compras integradas en la aplicación. Esto significa que un error provocado por la historia de un usuario que realiza compras dentro de la aplicación podría repercutir en cascada en la historia del usuario que realiza devoluciones integradas en la aplicación, como consecuencia de una suerte compartida.

Además, es importante entender la configuración básica de cada componente. La configuración básica identifica restricciones como el número medio y máximo de transacciones por segundo, el tamaño máximo de una carga útil, el tiempo de espera del cliente y las cuotas de servicio predeterminadas o actuales del recurso. Si va a modelar un diseño nuevo, le recomendamos que documente los requisitos funcionales del diseño y tenga en cuenta los límites. Esto le ayuda a comprender cómo se pueden manifestar los modos de fallo en el componente.

Por último, debe priorizar las historias de los usuarios en función del valor empresarial que proporcionan. Esta priorización le ayuda a centrarse primero en las funciones más importantes de su carga de trabajo. A continuación, puede centrar su análisis en los componentes de la carga de trabajo que forman parte de la ruta crítica para lograr esa funcionalidad y aprovechar el valor al utilizar el marco con mayor rapidez. A medida que avance en el proceso, podrá examinar otras historias de usuarios con diferentes prioridades.