Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La aplicación de software como servicio (SaaS) debe ejecutarse en una plataforma de proceso. Al igual que otros componentes de la arquitectura, debe cumplir los requisitos empresariales y diseñarse según el modelo de negocio. La elección de la plataforma de computación es una decisión de diseño importante. La decisión afecta al aislamiento, el rendimiento y la resistencia de los clientes, y la plataforma de proceso influye en cómo toda la solución SaaS puede escalar y crecer.
En este artículo se describen las consideraciones para elegir el modelo de hospedaje, los aspectos operativos de ese modelo y cómo optimizar las opciones de tecnología para ayudarle a cumplir los acuerdos de nivel de servicio (SLA) y los objetivos de nivel de servicio (SLO).
Seleccione una plataforma informática
Elegir la plataforma de proceso adecuada para la carga de trabajo de SaaS es importante, pero la abundancia de opciones disponibles puede hacer que la elección se sienta abrumadora. La mejor plataforma depende de factores como la arquitectura de la aplicación, la escala, las necesidades de rendimiento y el modelo de aislamiento de inquilinos. Es posible que lo que sea óptimo para una aplicación no sea para otra.
Consideraciones de diseño
Modelo de hospedaje. Azure ofrece varios modelos de hospedaje, principalmente infraestructura como servicio (IaaS) y plataforma como servicio (PaaS), cada uno con sus propias ventajas y desventajas. Evalúe los requisitos de la aplicación y elija el modelo más adecuado.
IaaS proporciona máquinas virtuales (VM) y un amplio control sobre ellas, incluidas las redes y el almacenamiento. Sin embargo, requiere gestionarlo y aplicar parches, lo que puede exigir mucho esfuerzo operativo. Algunos ejemplos son los conjuntos de escalado de máquinas virtuales y los clústeres de Azure Kubernetes Service (AKS).
PaaS permite implementar aplicaciones sin administrar la infraestructura subyacente. Incluye características integradas para el escalado automático y el equilibrio de carga. Algunos ejemplos son Azure App Service y Azure Container Apps.
Los servicios paaS ofrecen menos control en comparación con IaaS, lo que puede ser problemático si la aplicación necesita una configuración específica. Por ejemplo, la aplicación podría ejecutarse en un sistema operativo que el servicio PaaS no admite.
Tipo de carga de trabajo. Algunas plataformas están especializadas para cargas de trabajo específicas, mientras que otras son versátiles. Por ejemplo, App Service está diseñado para aplicaciones web, mientras que AKS es más de uso general. Puede hospedar aplicaciones web, cargas de trabajo de IA y tareas de proceso por lotes.
Desarrollar la experiencia del equipo. Los cambios grandes pueden ser difíciles si el equipo no tiene experiencia con la nueva plataforma. Evalúe las aptitudes de su equipo y adíquelas a sus requisitos de plataforma. Comience con una plataforma sencilla y evolucione gradualmente su arquitectura en lugar de saltar directamente a una opción más avanzada.
Por ejemplo, si va a compilar una aplicación en contenedor, comience con Container Apps para facilitar la administración. A medida que sus necesidades crecen más complejas, puede realizar la transición a AKS cuando obtenga una mejor comprensión de la plataforma a lo largo del tiempo.
Sobrecarga de administración. Las plataformas informáticas equilibran la sobrecarga y el control. Cuanta más responsabilidad de gestión se traslade fuera de tu equipo, menos control tendrás sobre la plataforma.
Por ejemplo, IaaS ofrece un alto control sobre las máquinas virtuales, pero conlleva una sobrecarga significativa. Si la aplicación se implementa en el entorno de un cliente, es posible que tenga acceso limitado para las operaciones de administración. Evalúe si estas compensaciones son aceptables y viables.
Requisitos de rendimiento. Comprenda los requisitos de rendimiento de la aplicación mediante el modelado de CPU, memoria, red, incluidos el ancho de banda y la latencia, la GPU y las necesidades de disponibilidad. También debe considerar el crecimiento futuro. Use esta información para elegir los recursos de proceso adecuados, como la serie y el tamaño de las máquinas virtuales. Es posible que también tenga que seleccionar regiones específicas que admitan series de máquinas virtuales concretas para cumplir los requisitos especializados.
Requisitos de confiabilidad. Tenga en cuenta las características de confiabilidad de la plataforma de proceso y asegúrese de que cumplen los objetivos de confiabilidad. Es posible que tenga que usar niveles de servicio específicos para tener varias instancias de la solución o implementar en zonas de disponibilidad para mejorar la confiabilidad.
Consulte RE:04 Recomendaciones para definir objetivos de fiabilidad.
Seguridad y cumplimiento de aplicaciones. Evalúe las características de seguridad y las certificaciones de cumplimiento de cada plataforma de proceso para asegurarse de que satisfacen sus necesidades. Por ejemplo, si necesita supervisar y filtrar el tráfico saliente, es posible que tenga que elegir niveles o servicios de proceso específicos.
Recomendaciones de diseño
| Recomendación | Prestación |
|---|---|
| Evalúe los requisitos de rendimiento de proceso mediante la estimación de las dimensiones de CPU, memoria, red y escala de GPU. Realice pruebas de carga para recopilar datos más precisos para informar al ejercicio de modelado. |
Estas tareas le ayudan a seleccionar el ajuste de tamaño adecuado para la plataforma de proceso y escalar adecuadamente cuando aumenta la carga en el sistema. |
| Evalúe la competencia de su equipo y comience con la plataforma menos compleja que satisfaga sus necesidades o una con la que el equipo ya esté familiarizado. | Garantizas unas operaciones más fluidas y evitas sobrecargar a tu equipo al elegir una plataforma de computación con la que ya está familiarizado. |
| Sea flexible en su diseño. Procura contar con una solución que puedas mejorar de forma iterativa con el tiempo para adaptarte a la evolución de los requisitos empresariales y técnicos. | La flexibilidad le permite adaptarse más fácilmente a los cambios y mejoras a lo largo del tiempo. Puede responder eficazmente a las necesidades empresariales y técnicas en constante evolución. |
| Evalúe el costo total de propiedad (TCO), incluidos los costos de funcionamiento de la solución. | Tiene una comprensión clara de los costos, que es fundamental para planear el modelo de precios y garantizar operaciones rentables. |
| Evalúa si necesitas usar plataformas informáticas específicas en función de tu pila tecnológica. Algunas plataformas de proceso son más adecuadas para determinados lenguajes de programación, herramientas y sistemas operativos. Esfuércese por usar plataformas que admitan de forma nativa sus opciones tecnológicas. | Evite el costo de rediseñar la arquitectura, lo que podría incluir la migración a una nueva plataforma. |
| Evalúe las características de confiabilidad de la plataforma y factorice las garantías del proveedor de servicios en la nube en los SLO. | Puede reducir el riesgo de interrupciones localizadas del centro de datos mediante la planeación de características de confiabilidad y el uso de zonas de disponibilidad si están disponibles. |
Modelo de arrendamiento y aislamiento
El modelo de negocio de SaaS determina si hospeda recursos para los clientes o los administra en el entorno del cliente. La mayoría de los proveedores de SaaS hospedan recursos en nombre de sus clientes, lo que permite flexibilidad en el diseño de la plataforma de proceso. Aísle las cargas de trabajo de los clientes de forma eficaz para optimizar la eficiencia de los costos sin poner en peligro la experiencia o el rendimiento del cliente.
Consideraciones de diseño
Planee el modelo de arrendamiento. Su modelo de arrendamiento determina cómo se comparten los recursos entre los clientes y está influido por sus modelos de negocio y de precios. Los modelos de inquilino único tienen mayores costos por cliente en comparación con los modelos totalmente multiinquilino. Los precios deben reflejar estas diferencias.
Requisitos del cliente. Algunos clientes pueden tener necesidades específicas para la residencia de datos, garantías de rendimiento o cumplimiento de seguridad. Si estos requisitos necesitan niveles de aislamiento más altos de los habituales, considere cómo reflejar el aumento de los costos en el modelo de negocio.
Problema de vecino ruidoso. Tenga en cuenta el problema de vecino ruidoso al compartir recursos entre inquilinos. Los recursos de proceso se ven afectados más. Para obtener más información, consulte antipatrón del vecino ruidoso.
Al elegir un modelo de arrendamiento, equilibre el ahorro de costos del uso compartido de recursos con la necesidad de garantizar el rendimiento del cliente. Los recursos de uso compartido excesivo o permitir un consumo excesivo pueden degradar la experiencia del cliente.
Compensación: rendimiento y costo. Compartir recursos entre los clientes puede ser rentable, pero si algunos clientes usan más recursos de lo esperado, este enfoque puede degradar el rendimiento de otros. Para evitar esto, implemente la gobernanza de recursos adecuada para asegurarse de que el uso del inquilino permanece dentro de los límites esperados.
Recomendaciones de diseño
| Recomendación | Prestación |
|---|---|
| Evalúe las características de aislamiento de la plataforma informática para garantizar que cumple los requisitos de su modelo de tenencia. | Para evitar volver a trabajar la plataforma, compruebe primero la configuración crítica. |
| Imponga su modelo de aislamiento. Tenga cuidado con los recursos compartidos, como las memorias caché de disco local, la memoria del sistema y las memorias caché externas, ya que pueden filtrar accidentalmente datos entre inquilinos si no se administran correctamente. Para requisitos de aislamiento elevados, aplique el aislamiento dentro de la plataforma de proceso y en la aplicación. |
El aislamiento seguro reduce el riesgo de pérdida de datos entre inquilinos, un incidente de seguridad grave. |
| Implemente la gobernanza y la supervisión de recursos, con visibilidad de las métricas de nivel de cliente. Supervise proactivamente el consumo de recursos de cada cliente para detectar y mitigar los problemas ruidosos de los vecinos. |
Evita que los problemas afecten a otros clientes mediante la supervisión del consumo de recursos y la mitigación temprana de los problemas. |
Configuración de la escalabilidad y la rentabilidad
Los clientes pueden usar la aplicación con diferentes perfiles de rendimiento. Esperan que la aplicación controle las crecientes demandas de los usuarios, los datos a gran escala y las cargas de trabajo complejas sin poner en peligro la velocidad y el rendimiento. La arquitectura del sistema debe garantizar la escalabilidad y el rendimiento óptimo, independientemente de si administra cientos o millones de usuarios, a la vez que equilibra las necesidades y los costos de rendimiento.
Para más información sobre la administración de costos, consulte Facturación y administración de costos para cargas de trabajo de SaaS en Azure.
Consideraciones de diseño
Estrategias de escalado horizontal y vertical. Los enfoques de escalado horizontal y vertical son viables para controlar el aumento de la carga. El enfoque que use depende de la capacidad de la aplicación para escalar entre varias instancias.
- El escalado horizontal implica agregar más instancias de nodos de proceso. La arquitectura necesita un equilibrador de carga para distribuir el tráfico entrante entre varios servidores o instancias.
- El escalado vertical implica aumentar los recursos, como la CPU y la memoria, en un solo servidor. Use este enfoque para las aplicaciones con estado que no necesitan almacenes de estado externos, como las memorias caché. El escalado vertical puede provocar interrupciones breves del servicio y tener un límite de recursos en un solo servidor.
Consulte Recomendaciones de PE:05 para el escalado y la creación de particiones.
Escalado automático. Los sistemas necesitan controlar eficazmente distintos niveles de demanda. A medida que aumenta el tráfico de usuario, los recursos de la aplicación deben escalar verticalmente para mantener el rendimiento. Cuando la demanda disminuye, los recursos se reducen verticalmente para controlar los costos sin afectar a la experiencia del usuario. Factores como el uso de cpu, la hora del día o las solicitudes entrantes guían estos ajustes. El escalado automático ayuda a equilibrar el rendimiento y el costo y mitiga el impacto de la alta demanda en otros inquilinos.
Planificación de capacidad y asignación de recursos de cómputo. La incorporación de nuevos clientes a la carga de trabajo de SaaS consume capacidad de recursos. Incluso si se escala vertical o horizontalmente, finalmente alcanza los límites, como las restricciones de red o almacenamiento, en la escalabilidad de la solución.
Nota:
El patrón de sellos de implementación permite implementar varias instancias independientes de su solución. Proporciona otra dimensión de escalado. Es fundamental comprender la capacidad de cada sello para determinar cuándo implementar más. Este concepto también se conoce como empaquetado en contenedores.
Recomendaciones de diseño
| Recomendación | Prestación |
|---|---|
| Elija el escalado horizontal a través del escalado vertical. El escalado horizontal suele ser menos complejo, más confiable y rentable que el escalado vertical. | El escalado horizontal suele ser más sencillo, más confiable y rentable, lo que le permite escalar a un grado mayor que el escalado vertical. |
| Realice pruebas de carga. | La simulación del uso puede ayudarle a identificar cuellos de botella y umbrales de escalado antes de implementar en producción. |
| Defina el umbral de escalado para implementar una nueva marca en lugar de escalar horizontal o verticalmente. Para lograr una escalabilidad rentable sin pérdida de rendimiento, concentre sus inquilinos en la menor cantidad posible de recursos. |
Está mejor preparado para controlar el crecimiento más allá de la infraestructura actual. |
| Implemente el escalado automático, siempre que sea posible. Establezca reglas de escalado automático para reflejar la carga de la aplicación con precisión. | Para optimizar el rendimiento y el costo, aumente y reduzca los recursos según sea necesario. |
| Supervise y evalúe los patrones de uso de los clientes. | Sabe cuándo ajustar la infraestructura para aumentar el rendimiento o optimizar los costos. |
| Implemente mecanismos de almacenamiento en caché, siempre que sea posible. | Se reduce la carga potencial de procesamiento en la capa de proceso. |
| Usa las alertas de costes. | Las advertencias le ayudan a detectar problemas de alto uso y control de costos al principio. |
| Use reservas de Azure para clientes con compromisos a largo plazo y un uso garantizado de capacidad de proceso durante todo ese periodo. | Maximiza la rentabilidad de su capacidad reservada. |
Diseño para lograr resistencia
La resiliencia de su capa de computación desempeña un papel fundamental en su estrategia general de resiliencia. La aplicación debe tolerar y recuperarse de errores comunes de forma automática y sin problemas, sin impacto en el usuario.
Consideraciones de diseño
Requisitos de confiabilidad. Establezca requisitos claros de confiabilidad. Estos requisitos incluyen objetivos internos, o SLOs, y compromisos con los clientes, o SLA, que a menudo especifican objetivos de disponibilidad, como un 99,9 % al mes.
Consulte las recomendaciones RE:04 para definir objetivos de fiabilidad.
Estrategia de implementación. Los recursos en la nube se implementan en regiones geográficas específicas. En Azure, las zonas de disponibilidad son conjuntos de centros de datos aislados dentro de una región. Para lograr resistencia, implemente aplicaciones en varias zonas de disponibilidad. La implementación entre regiones o proveedores de nube mejora la resistencia, pero agrega complejidad operativa y de costos.
Consulte RE:05 Recomendaciones para usar las zonas de disponibilidad y las regiones.
Cargas de trabajo sin estado. Para implementar aplicaciones resistentes, normalmente es necesario ejecutar copias redundantes en diferentes ubicaciones. Esta tarea puede ser complicada para las cargas de trabajo con estado, que necesitan mantener el estado de sesión. Procure crear cargas de trabajo sin estado siempre que sea posible.
Recomendaciones de diseño
| Recomendación | Prestación |
|---|---|
| Controle los errores transitorios en la aplicación. | Aumentas tu disponibilidad al recuperarte rápidamente de problemas menores. |
| Elija aplicaciones sin estado. Si la aplicación debe tener estado, use un mecanismo de almacenamiento de estado externo como una memoria caché para almacenar el estado. | Se evita la pérdida de estado causada por la indisponibilidad de una instancia, como durante un balanceo de carga erróneo o una caída del servicio. |
| Uso de zonas de disponibilidad. | Aumenta su capacidad de recuperación al mitigar las interrupciones localizadas del centro de datos. |
| Diseñe una arquitectura multirregional cuando haya justificación comercial para hacerlo. | Cumples altos requisitos de disponibilidad y das soporte a usuarios en distintas regiones. |
| Realice pruebas de ingeniería del caos. | Comprenda mejor dónde están los puntos de error y puede corregirlos antes de que se produzca una interrupción. |
| Limite el uso de componentes que comparten varios sellos. | Eliminas los puntos únicos de fallo y reduces el posible alcance de una interrupción. |
Recursos adicionales
La multitenencia es una metodología empresarial fundamental para diseñar cargas de trabajo SaaS. Estos artículos proporcionan más información sobre las consideraciones relativas a la plataforma informática:
Paso siguiente
Obtenga información sobre las consideraciones de red para las cargas de trabajo de SaaS.