Recomendaciones para diseñar para simplificar y mejorar la eficacia
Se aplica a esta recomendación de lista de comprobación de confiabilidad del marco de trabajo bien diseñado de Azure:
| RE:01 | Diseñe la carga de trabajo para alinearse con los objetivos empresariales y evite la 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 para las necesidades para reducir las ineficacias y los posibles problemas. |
|---|
En esta guía se describen las recomendaciones para minimizar la complejidad innecesaria y la sobrecarga para mantener las cargas de trabajo 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 ventajas de 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 manejable.
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 tenet clave del 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 complejidades innecesarias o sobrecargas excesivas. Tenga en cuenta las recomendaciones de este artículo para ayudarle a tomar decisiones sobre el diseño para crear una carga de trabajo magra, 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 cargas de trabajo. ¿La aplicación admite millones de usuarios o unos pocos 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.
Compensación: 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.
Colaboración con las partes interesadas en ejercicios de diseño
Trabaje con las partes interesadas para:
Defina y asigne un nivel de importancia crítica a los flujos de usuario y los flujos del sistema de la carga de trabajo. Centre el diseño en 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.
Descompone 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, a la vez que proporciona una funcionalidad completa. Para 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. Considere 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 a riesgos de su empresa. Para 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 para recuperar (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 podría requerir compromiso y comprensión mutua entre tecnología y equipos empresariales para asegurarse de que los objetivos de cada equipo cumplen los objetivos empresariales y son realistas. Para obtener más información, consulte Recomendaciones para definir objetivos de confiabilidad.
Favor de opciones de diseño más sencillas
Puede realizar las siguientes recomendaciones sin participación de las partes interesadas:
Se esfuerza por simplificar y claridad en su diseño. Use el nivel adecuado de abstracción y granularidad para los componentes y servicios. Evite la sobreengineering o la ingeniería inferior de la solución. Por ejemplo, si desglosa el código en varias funciones pequeñas, es difícil entender, 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 tiene que 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 en diferentes 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. A continuación, 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 introducir problemas de complejidad, sobrecarga y dependencia.
Desarrollo de código suficiente
Los principios de simplicidad, eficiencia y confiabilidad también se aplican a sus 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 sus 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.
Introducir sesiones de revisión de código dedicadas o programación de pares como práctica de desarrollo.
Implemente un enfoque para identificar código fallido. Sea escéptica del código que las pruebas automatizadas no cubren.
Selección del almacén de datos correcto
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 las transacciones de datos relacionales. Pero estas bases de datos presentan 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 los 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 aplicaciones en Azure Cognitive Search.
Blobs en Azure Blob Storage.
Priorice la disponibilidad sobre la coherencia. El teorema CAP implica que tiene que hacer equilibrios entre disponibilidad y coherencia en un sistema distribuido. No puede 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 a 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 políglota, 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 enlazados, 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 flujo de trabajo sin servidor que puede usar para compilar orquestaciones con una GUI o editando un archivo de configuración.
Azure Event Grid es un servicio de distribución de mensajes de publicación totalmente administrado y altamente escalable que ofrece patrones de consumo de mensajes flexibles que usan los protocolos MQTT y HTTP. Con Event Grid, puede crear canalizaciones de datos con datos de dispositivo, crear arquitecturas sin servidor controladas por eventos e integrar aplicaciones.
Para más información, vea:
- Elección de un servicio de proceso de Azure
- Elección de una opción de proceso para microservicios
- Revisión de las opciones de datos
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 de aplicación web confiable.
Vínculos relacionados
Lista de comprobación de confiabilidad
Consulte el conjunto completo de recomendaciones.