Descripció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 toda una carga de trabajo puede ser complejo, ya que muchos sistemas tienen numerosos componentes e interacciones. En su lugar, le recomendamos que se centre en las historias de usuario, que son explicaciones informales y generales de las características del software escritas desde el punto de vista del usuario final. Sirven para explicar cómo una característica de software aporta 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 aportan la funcionalidad empresarial que se ha descrito. Por ejemplo, una solución de compra de juegos para móviles integrada en una aplicación puede tener dos historias de usuario: “comprar créditos en la aplicación” y “obtener reembolsos en la aplicación”, tal y como se muestra en el siguiente diagrama. (En este ejemplo de arquitectura se destaca cómo se puede descomponer un sistema en historias de usuario; no pretende representar una aplicación muy resiliente).

Todas las historias de usuario constan de cuatro componentes comunes: código y configuración, infraestructura, almacenes de datos y dependencias externas. En los diagramas se deben incluir todos estos componentes y reflejar las interacciones entre los componentes. Por ejemplo, si hay una carga excesiva en el punto de conexión de Amazon API Gateway, considere cómo esa carga se extiende en cascada a otros componentes del sistema, como las funciones de AWS Lambda o las tablas de Amazon DynamoDB. El seguimiento de estas interacciones lo ayuda a comprender cómo el modo de error puede afectar a la historia de 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. En 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 error se cruzan. En el ejemplo, las tablas de DynamoDB se comparten en ambas historias de usuario, como puede ver en las flechas que indican que el componente de Lambda del historial de reembolsos en la aplicación accede a las tablas de DynamoDB del historial de compras en la aplicación. Esto significa que un error provocado por la historia de usuario de compras en la aplicación podría repercutir en cascada en la historia de usuario de devoluciones en la aplicación, como consecuencia de un destino compartido.

Además, es importante conocer la configuración de referencia de cada componente. La configuración de referencia 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 que tenga en cuenta los límites. Esto lo ayudará a comprender cómo se pueden manifestar los modos de error en el componente.

Por último, debe priorizar las historias de usuario en función del valor empresarial que proporcionan. Esta priorización lo ayuda a centrarse primero en las funciones más importantes de la carga de trabajo. A continuación, puede centrar el 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 usar el marco con mayor rapidez. A medida que avance en el proceso, podrá examinar otras historias de usuario con distintas prioridades.