Recomendaciones para diseñar por motivos de simplicidad y eficiencia

  • Artículo

Se aplica a esta recomendación de lista de comprobación de confiabilidad de Azure Well-Architected Framework:

RE:01 Diseñe la carga de trabajo para alinearse con los objetivos empresariales y evite una complejidad o sobrecarga innecesarias. Use un enfoque práctico y equilibrado para tomar decisiones de diseño que proporcionen los resultados deseados. Contenga su diseño a las necesidades para reducir las ineficiencias y posibles problemas.

En esta guía se describen las recomendaciones para minimizar la complejidad y la sobrecarga innecesarias para que las cargas de trabajo sean sencillas y eficientes. Elija los mejores componentes para realizar las tareas de carga de trabajo necesarias para optimizar la confiabilidad de la carga de trabajo. Para reducir las cargas de desarrollo y administración, aproveche las eficiencias que ofrecen los servicios proporcionados por la plataforma. Este diseño le ayuda a crear una arquitectura de carga de trabajo resistente, repetible, escalable y administrable.

Definiciones

Término Definición
Carga de trabajo Una funcionalidad discreta o tarea informática que se puede separar lógicamente de otras tareas.

Estrategias de diseño principales

Una red clave de diseño para la confiabilidad es mantener las cosas sencillas y eficientes. Centre el diseño de la carga de trabajo en cumplir los requisitos empresariales para reducir el riesgo de complejidad innecesaria o sobrecarga excesiva. Tenga en cuenta las recomendaciones de este artículo para ayudarle a tomar decisiones sobre el diseño para crear una carga de trabajo ajustada, eficaz y confiable. Unas cargas de trabajo diferentes pueden tener distintos requisitos de disponibilidad, escalabilidad, coherencia de datos y recuperación ante desastres.

Debe justificar cada decisión de diseño con un requisito empresarial. Este principio de diseño puede parecer obvio, pero es fundamental para el diseño de la carga de trabajo. ¿La aplicación admite millones de usuarios o unos 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? Los requisitos empresariales impulsan estas consideraciones de diseño.

Equilibrio: una solución compleja puede ofrecer más características y flexibilidad, pero podría afectar a la confiabilidad de la carga de trabajo porque requiere más coordinación, comunicación y administración de componentes. Como alternativa, una solución más sencilla podría no satisfacer completamente las expectativas del usuario o podría tener un efecto negativo en la escalabilidad y la extensibilidad a medida que evoluciona la carga de trabajo.

Ejercicios de diseño colaborativo

Trabaje con las partes interesadas para:

  • Defina y asigne un nivel de importancia a los flujos de usuario y los flujos del sistema de la carga de trabajo. Céntrese en el diseño de flujos críticos para ayudarle a determinar los componentes necesarios y el mejor enfoque para lograr el nivel de resistencia necesario.

  • Definir los requisitos funcionales y no funcionales. Considere los requisitos funcionales para determinar si una aplicación realiza una tarea. Considere los requisitos no funcionales para determinar el rendimiento de la aplicación en una tarea. Asegúrese de comprender 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.

  • Descompona las cargas de trabajo en componentes. Priorice la simplicidad, la eficiencia y la confiabilidad en el diseño. Determine los componentes que necesita para admitir los flujos. Algunos componentes admiten varios flujos. Identifique qué desafío aborda conceptualmente un componente y considere la posibilidad de quitar un componente de flujos individuales para simplificar el diseño general y, al mismo tiempo, proporcionar una funcionalidad completa. Para obtener más información, consulte Recomendaciones para realizar el análisis del modo de error.

  • Use el análisis del modo de error para identificar puntos únicos de error y posibles riesgos. Tenga en cuenta si necesita tener en cuenta situaciones poco probables, por ejemplo, un área geográfica que experimenta un desastre natural importante que afecta a todas las zonas de disponibilidad de la región. Es costoso e implica importantes inconvenientes para mitigar estos riesgos poco comunes. Comprenda claramente la tolerancia del riesgo de su empresa. Para obtener más información, consulte Recomendaciones para realizar el análisis del modo de error.

  • Defina los destinos de disponibilidad y recuperación de los flujos para informar a la arquitectura de la carga de trabajo. Las métricas empresariales incluyen objetivos de nivel de servicio (SLO), acuerdos de nivel de servicio (SLA), tiempo medio de recuperación (MTTR), tiempo medio entre errores (MTBF), objetivos de tiempo de recuperación (RTO) y objetivos de punto de recuperación (RPO). Defina los valores de destino para estas métricas. Este ejercicio puede requerir compromiso y comprensión mutua entre la tecnología y los equipos empresariales para garantizar que los objetivos de cada equipo cumplan los objetivos empresariales y sean realistas. Para obtener más información, consulte Recomendaciones para definir destinos de confiabilidad.

Recomendaciones de diseño adicionales

Puede realizar las siguientes recomendaciones sin la participación de las partes interesadas:

  • Esfuércese por simplificar y claridad en su diseño. Use el nivel adecuado de abstracción y granularidad para los componentes y servicios. Evite el exceso de ingeniería o la ingeniería inferior de la solución. Por ejemplo, si desglosa el código en varias funciones pequeñas, es difícil comprender, probar y mantener.

  • Conceda que todas las aplicaciones correctas cambien con el tiempo, ya sea para corregir errores, implementar nuevas características o tecnologías, o hacer que los sistemas existentes sean más escalables y resistentes.

  • Use las opciones de plataforma como servicio (PaaS) en lugar de infraestructura como servicio (IaaS) siempre que sea posible. IaaS es como tener una caja de piezas. Puede crear cualquier cosa pero lo debe ensamblar usted mismo. Las opciones de PaaS son más fáciles de configurar y administrar. No es necesario configurar máquinas virtuales (VM) ni redes virtuales. Tampoco es necesario realizar tareas de mantenimiento, como instalar revisiones y actualizaciones.

  • Use la mensajería asincrónica para desacoplar el productor de mensajes del consumidor.

  • Infraestructura abstracta fuera de la lógica del dominio. Asegúrese de que la lógica de dominio no interfiere con la funcionalidad relacionada con la infraestructura, como la mensajería o la persistencia.

  • Descargar cuestiones transversales en un servicio independiente. Minimice la necesidad de duplicar el código entre distintas funciones, prefiere reutilizar los servicios con interfaces bien definidas que pueden consumir fácilmente distintos componentes. Por ejemplo, si varios servicios necesitan autenticar solicitudes, puede mover esta funcionalidad a su propio servicio. Después, puede evolucionar el servicio de autenticación. Por ejemplo, puede agregar un nuevo flujo de autenticación sin tocar ninguno de los servicios que lo usan.

  • Evalúe la idoneidad de patrones y prácticas comunes para sus necesidades. Evite las siguientes tendencias o recomendaciones que podrían no ser mejores para su contexto o requisitos. Por ejemplo, los microservicios no son la mejor opción para cada aplicación porque pueden presentar problemas de complejidad, sobrecarga y dependencia.

Desarrollo de código suficiente

Los principios de simplicidad, eficiencia y confiabilidad también se aplican a las prácticas de desarrollo. En una carga de trabajo con componentes acoplada de forma flexible, determine la funcionalidad que proporciona un componente. Desarrolle los flujos para aprovechar esa funcionalidad. Tenga en cuenta estas recomendaciones para las prácticas de desarrollo:

  • Use funcionalidades de plataforma cuando cumplan los requisitos empresariales. Por ejemplo, para descargar el desarrollo y la administración, use soluciones sin código, sin código o sin servidor que ofrezca el proveedor de nube.

  • Use bibliotecas y marcos.

  • Presentar sesiones de revisión de código dedicadas o programación de pares como práctica de desarrollo.

  • Implemente un enfoque para identificar el código fallido. Sea escéptica del código que las pruebas automatizadas no cubren.

Use el mejor almacén de datos para sus datos

En el pasado, muchas organizaciones almacenaron todos sus datos en bases de datos SQL relacionales de gran tamaño. Las bases de datos relacionales proporcionan garantías atómicas, coherentes, aisladas y duraderas (ACID) para transacciones de datos relacionales. Pero estas bases de datos tienen desventajas:

  • Las consultas pueden requerir combinaciones costosas.

  • Debe normalizar los datos y reestructurarlos para el esquema en escritura.

  • La contención de bloqueos puede afectar al rendimiento.

Alternativas a las bases de datos relacionales

En una solución grande, es probable que una única tecnología de almacén de datos no satisfaga todas sus necesidades. Las alternativas a las bases de datos relacionales son:

  • Almacenes de clave-valor

  • Bases de datos de documentos

  • Bases de datos del motor de búsqueda

  • Bases de datos de series temporales

  • Bases de datos de familia de columnas

  • Bases de datos de grafos

Cada opción tiene ventajas y desventajas. Los distintos tipos de datos son más adecuados para diferentes tipos de almacén de datos. Elija la tecnología de almacenamiento que mejor se adapte a sus datos y a su uso.

Por ejemplo, puede almacenar un catálogo de productos en una base de datos de documentos, como Azure Cosmos DB, que admite un esquema flexible. Cada descripción del producto es un documento independiente. Para las consultas en todo el catálogo, puede indexar el catálogo y almacenar el índice en Azure Cognitive Search. El inventario de productos puede entrar en una base de datos SQL porque esos datos requieren garantías ACID.

Recomendaciones

  • Considere otros almacenes de datos. Las bases de datos relacionales no siempre son adecuadas. Para más información, consulte Descripción de los modelos del almacén de datos.

  • Recuerde que los datos incluyen más que simplemente los datos de aplicación conservados. También contienen registros de aplicación, eventos, mensajes y memorias caché.

  • Adopte la persistencia poliglot o las soluciones que usan una combinación de tecnologías de almacén de datos.

  • Tenga en cuenta el tipo de datos que tiene. Por ejemplo, almacene:

    • Datos transaccionales en una base de datos SQL.

    • Documentos JSON en una base de datos de documentos.

    • Telemetría en una base de datos de serie temporal.

    • Registros de aplicación en Azure Cognitive Search.

    • Blobs en Azure Blob Storage.

  • Priorice la disponibilidad sobre la coherencia. El teorema CAP implica que hay que compensar entre la disponibilidad y la coherencia en un sistema distribuido. No se pueden evitar completamente las particiones de red, que es el otro componente del teorema CAP. Pero puede adoptar un modelo de coherencia final para lograr una mayor disponibilidad.

  • Considere el conjunto de habilidades de su equipo de desarrollo. El uso de Polyglot entraña ventajas, pero es posible acabar abusando de ello. Requiere nuevos conjuntos de aptitudes para adoptar una nueva tecnología de almacenamiento de datos. Para sacar el máximo partido de la tecnología, el equipo de desarrollo debe:

    • Optimice las consultas.

    • Ajuste para el rendimiento.

    • Trabaje con los patrones de uso adecuados.

Tenga en cuenta estos factores al elegir una tecnología de almacenamiento:

  • Use transacciones de compensación. Con la persistencia poliglot, una sola transacción podría escribir datos en varios almacenes. Si se produce un error, use transacciones de compensación para deshacer los pasos que hayan finalizado.

  • Considere los contextos limitados, que es un concepto de diseño controlado por dominio. Un contexto delimitado es un límite explícito alrededor de un modelo de dominio. Un contexto enlazado define a qué partes del dominio se aplica el modelo. Idealmente, un contexto enlazado se asigna a un subdominio del dominio empresarial. Considere la persistencia poliglot para contextos limitados en el sistema. Por ejemplo, los productos pueden aparecer en el subdominio del catálogo de productos y en el subdominio de inventario de productos. Pero lo más probable es que estos dos subdominios tengan requisitos diferentes para almacenar, actualizar y consultar productos.

Facilitación de Azure

Azure ofrece los siguientes servicios:

  • Azure Functions es un servicio de proceso sin servidor que puede usar para compilar la orquestación con código mínimo.

  • Azure Logic Apps es una plataforma de integración de flujos de trabajo sin servidor que puede usar para compilar la orquestación con una GUI o editando un archivo de configuración.

  • Azure Event Grid es un servicio de distribución de mensajes de publicación y suscripción altamente escalable y totalmente administrado que ofrece patrones flexibles de consumo de mensajes que usan los protocolos MQTT y HTTP. Con Event Grid, puede compilar canalizaciones de datos con datos de dispositivo, compilar arquitecturas sin servidor controladas por eventos e integrar aplicaciones.

Para más información, consulte:

Ejemplo

Para obtener una carga de trabajo de ejemplo que determine los componentes y sus características en función de los requisitos, consulte Patrón reliable Web App.

Lista de comprobación de confiabilidad

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de confiabilidad