Compilación para las necesidades empresariales

  • Artículo

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 cargas de trabajo. La carga de trabajo en este contexto significa una funcionalidad o tarea de computación discreta, que se puede separar de forma lógica de otras tareas. Unas cargas de trabajo diferentes pueden tener distintos requisitos de disponibilidad, escalabilidad, coherencia de datos y recuperación ante desastres.

  • 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.

  • 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.

Pasos siguientes