Compilación para las necesidades empresariales
Cada decisión de diseño debe estar justificada por un requisito empresarial. Este principio de diseño puede parecer obvio pero es fundamental tenerlo en cuenta al diseñar aplicaciones de Azure.
¿La aplicación debe admitir millones de usuarios o algunos miles? ¿Hay grandes ráfagas de tráfico o, por el contrario, una carga de trabajo estable? ¿Qué nivel de interrupción de la aplicación es aceptable? En última instancia, los requisitos empresariales impulsan estas consideraciones de diseño.
Las siguientes recomendaciones le ayudan a diseñar y crear soluciones para cumplir los requisitos empresariales:
Definir objetivos de negocio, como el objetivo de tiempo de recuperación (RTO), el objetivo de punto de recuperación (RPO) y la interrupción tolerable máxima (MTO). Estos números deben dar información para ayudar a tomar decisiones acerca de la arquitectura.
Por ejemplo, supongamos que su empresa requiere un RTO muy bajo y un RPO muy bajo. Puede optar por usar una arquitectura con redundancia de zona para cumplir estos requisitos. Si su empresa puede tolerar un RTO y un RPO más altos, agregar redundancia podría agregar costos adicionales para ninguna ventaja empresarial.
Tenga en cuenta los riesgos de error que debe mitigar. Siga la Guía de diseño para recuperación automática para diseñar la solución para que sea resistente a muchos tipos de modos de error comunes. Tenga en cuenta si necesita tener en cuenta situaciones menos probables, como un área geográfica que experimenta un desastre natural importante que podría afectar a todas las zonas de disponibilidad de la región. La mitigación de estos riesgos poco comunes suele ser más costosa e implica importantes inconvenientes, por lo que tiene una clara comprensión de la tolerancia del negocio al riesgo.
Documentar Acuerdos de Nivel de Servicio (SLA) y Objetivos de Nivel de Servicio (SLO), incluidas las métricas de rendimiento y la disponibilidad. Por ejemplo, una solución propuesta podría ofrecer una disponibilidad del 99,95 %. Si ese SLO cumple el Acuerdo de Nivel de Servicio, se trata de una decisión empresarial.
Modelar aplicaciones para el dominio empresarial. Analice los requisitos empresariales y úselos para modelar la solución. Considere la posibilidad de usar un enfoque de diseño basado en el dominio (DDD) para crear modelos de dominio que reflejen los procesos empresariales y los casos de uso.
Definir los requisitos funcionales y no funcionales. Los requisitos funcionales determinan si una aplicación realiza su tarea. Los requisitos no funcionales determinan si la aplicación tiene un buen rendimiento. Asegúrese de conocer los requisitos no funcionales, como la escalabilidad, la disponibilidad y la latencia. Estos requisitos influirán en las decisiones de diseño y la elección de la tecnología.
Descomponer las cargas de trabajo en funcionalidades discretas. Una carga de trabajo es una colección de recursos de aplicaciones, datos e infraestructura de apoyo que funcionan juntos para lograr resultados empresariales definidos. Una carga de trabajo consta de componentes y también de procedimientos operativos y de desarrollo. Las cargas de trabajo a menudo pueden descomponerse en una funcionalidad discreta que se alinea con los flujos de usuarios, datos o sistemas, y a esos flujos se les puede atribuir valor y tienen requisitos no funcionales.
Los distintos flujos de usuarios, datos o sistemas suelen tener diferentes requisitos de disponibilidad, escalabilidad, coherencia de datos y recuperación en caso de desastre. Los sistemas bien diseñados permiten optimizar el diseño por flujo. Para lograrlo, debe desglosar las cargas de trabajo en componentes ajustables. Una estrategia típica consiste en categorizar los componentes en función de su valor. Por ejemplo, los componentes de nivel 1 son cruciales y deben optimizarse sin tener en cuenta el gasto. Los componentes de nivel 2 son importantes, pero pueden reducirse temporalmente con consecuencias mínimas. Los componentes de nivel 3 son opcionales; manténgalos rentables y fácilmente gestionables. Establecer un entendimiento compartido del valor de los flujos ayuda a todos los que diseñan y evolucionan una carga de trabajo a mantener un equilibrio entre el coste y otros requisitos no funcionales.
Planear el crecimiento. Una solución podría satisfacer las necesidades actuales para el número de usuarios, el volumen de transacciones y el almacenamiento de datos, pero también debe controlar el crecimiento sin cambios importantes en la arquitectura. Tenga también en cuenta que el modelo empresarial y los requisitos empresariales pueden cambiar con el tiempo. Es difícil que una solución evolucione para nuevos casos de uso y escenarios si el modelo de servicio y lo modelos de datos de la aplicación son demasiado rígidos.
Alinear el modelo de negocio y el coste. La longevidad de un sistema depende de la eficacia con que sus costes se ajusten al modelo de negocio. Como arquitecto, debe tener en cuenta los impulsores de valor y utilizar esa información para orientar sus decisiones. Debe identificar la dimensión en la que su solución aportará valor (como la rentabilidad) y, a continuación, asegurarse de que la arquitectura sigue la transmisión de valor. De este modo, su arquitectura puede maximizar el valor de la inversión, generando un retorno de la inversión (ROI) acorde con las expectativas empresariales.
Administrar los costos. En una aplicación local tradicional, paga por adelantado por el hardware como un gasto de capital. En una aplicación en la nube, paga por los recursos que consume. Asegúrese de que conoce el modelo de precios de los servicios. Los costos totales pueden incluir el consumo de ancho de banda de red, el almacenamiento, las direcciones IP y el consumo del servicio.
Tenga también en cuenta los costos de las operaciones. En la nube, no tiene que administrar el hardware ni la infraestructura, pero sí debe administrar las tareas de DevOps de la aplicación, la respuesta a incidentes y la recuperación ante desastres.