Consideraciones de diseño de aplicaciones en la nube

Al diseñar aplicaciones para la nube, independientemente de la plataforma elegida, me ha resultado útil considerar cuatro temas específicos durante mis reflexiones iniciales; escalabilidad, disponibilidad, manejabilidad y viabilidad.

Es importante recordar que los ítems presentados bajo cada tema dentro de este artículo no son una lista exhaustiva y tienen como único objetivo presentar un punto de partida para una serie de conversaciones largas y detalladas con las partes interesadas de su proyecto, siempre la parte más importante del diseño de cualquier aplicación. El objetivo de estas conversaciones debería ser producir un diseño y una arquitectura iniciales de alto nivel. Esto se logra considerando estos cuatro elementos clave de manera integral dentro del dominio de los requisitos del proyecto del cliente, recordando siempre considerar los efectos secundarios y las compensaciones de cualquier decisión de diseño (es decir, lo que ganamos frente a lo que perdemos, o lo que hacemos más difícil).

Escalabilidad

Las conversaciones sobre la escalabilidad deben centrarse en cualquier requerimiento para añadir capacidad adicional a la aplicación y a los servicios relacionados para afrontar el aumento de la carga y la demanda. Es especialmente importante tener en cuenta cada uno de los niveles de la aplicación al diseñar para la escalabilidad, cómo deben escalar individualmente y cómo podemos evitar los problemas de contención y los cuellos de botella. Entre las áreas clave a tener en cuenta rstán:

Capacidad

• ¿Necesitaremos escalar las capas individuales de la aplicación y, si es así, cómo podemos conseguirlo sin que afecte a la disponibilidad?
• ¿Con qué rapidez tendremos que escalar los servicios individuales?
• ¿Cómo podemos añadir capacidad adicional a la aplicación o a alguna de sus partes?
• ¿Necesitamos que la aplicación funcione a escala 24 horas al día, 7 días a la semana, o podemos reducirla fuera del horario laboral o los fines de semana, por ejemplo?

Plataforma / Datos

• ¿Podemos trabajar dentro de las limitaciones de nuestros servicios de persistencia elegidos mientras trabajamos a escala (tamaño de la base de datos, rendimiento de las transacciones, etc.)?
• ¿Cómo podemos dividir nuestros datos para favorecer la escalabilidad dentro de las restricciones de la plataforma de persistencia (por ejemplo, los tamaños máximos de las bases de datos, los límites de solicitudes concurrentes, etc.)?
• ¿Cómo podemos asegurarnos de que estamos haciendo un uso eficiente y eficaz de los recursos de la plataforma? Como regla general, me inclino por un diseño basado en muchas instancias pequeñas, en lugar de pocas instancias grandes.
• ¿Podemos colapsar los niveles para minimizar el tráfico de la red interna y el uso de recursos, al tiempo que mantenemos una escalabilidad eficiente y la mantenibilidad del código en el futuro?

Carga

• ¿Cómo podemos mejorar el diseño para evitar problemas de contención y cuellos de botella? Por ejemplo, ¿podemos utilizar filas o un bus de servicio entre servicios en un patrón de productor cooperante y consumidor competitivo?
• ¿Qué operaciones podrían gestionarse de forma asíncrona para ayudar a equilibrar la carga en las horas punta?
• ¿Cómo podríamos utilizar las funciones de la plataforma para la nivelación de tarifas (por ejemplo, Azure Queues, Service Bus, etc.)?
• ¿Cómo podríamos utilizar las funciones de la plataforma para el equilibrio de carga (por ejemplo, Azure Traffic Manager, Load Balancer, etc.)?


Disponibilidad

Garantías de tiempo de funcionamiento

• ¿Qué acuerdos de nivel de servicio (SLA) deben cumplir los productos?
• ¿Se pueden cumplir estos SLA? ¿Los diferentes servicios en la nube que pensamos utilizar cumplen con los niveles requeridos? Recuerde que los SLA son compuestos.

Replicación y conmutación por error

• ¿Qué partes de la aplicación corren más riesgo de fallar?
• ¿En qué partes del sistema tendría un mayor impacto un fallo?
• ¿Qué partes de la aplicación podrían beneficiarse de las opciones de redundancia y conmutación por error?
• ¿Se necesitarán servicios de replicación de datos?
• ¿Estamos restringidos a zonas geopolíticas concretas? Si es así, ¿están disponibles en esas zonas todos los servicios que pensamos utilizar?
• ¿Cómo evitar que se repliquen datos defectuosos?
• ¿La recuperación de un fallo supondrá una presión excesiva para el sistema? ¿Necesitamos aplicar políticas de reintento y/o un interruptor automático?

Recuperación en caso de catástrofe

• En caso de fallo catastrófico, ¿cómo reconstruimos el sistema?
• ¿Cuántos datos, si es que hay alguno, es aceptable perder en un escenario de recuperación de desastres?
• ¿Cómo gestionamos las copias de seguridad? ¿Necesitamos copias de seguridad además de la replicación de datos?
• ¿Cómo gestionamos los mensajes y las colas "en marcha" en caso de fallo?
• ¿Somos idempotentes? ¿Podemos repetir los mensajes?
• ¿Dónde guardamos las imágenes de nuestra máquina virtual? ¿Tenemos una copia de seguridad?

Rendimiento

• ¿Cuáles son los niveles de rendimiento aceptables? ¿Cómo podemos medirlo? ¿Qué ocurre si bajamos de ese nivel?
• ¿Podemos hacer que alguna parte del sistema sea asíncrona como ayuda al rendimiento?
• ¿Qué partes del sistema son las más concurridas y, por tanto, las más propensas a causar problemas de rendimiento?
• ¿Es probable que se produzcan picos de tráfico que puedan causar problemas de rendimiento? ¿Podemos autoescalar o utilizar un diseño centrado en las colas para cubrirlo?

Seguridad

Está claro que este es un tema muy amplio en sí mismo, pero algunos puntos interesantes para explorarlo, que se relacionan directamente con la computación en la nube, incluyen:

• ¿Cuál es la legislación local y la jurisdicción donde se guardan los datos? No olvides incluir los países en los que se conservan los datos sobre fallos y métricas.
• ¿Existe un requisito de seguridad federada (por ejemplo, ADFS con Azure Active Directory)?
• ¿Se trata de una aplicación de nube híbrida? Cómo estamos asegurando el enlace entre nuestras redes corporativas y de la nube?
• ¿Cómo controlamos el acceso al portal de administración del proveedor de la nube?
• ¿Cómo restringimos el acceso a las bases de datos, etc. desde otros servicios (por ejemplo, listas blancas de direcciones IP, etc.)?
• ¿Cómo gestionamos los cambios regulares de contraseña?
• ¿Cómo afectan a la seguridad la desvinculación de servicios y la tenencia múltiple?
• ¿Cómo nos ocuparemos de los parches y actualizaciones de seguridad del sistema operativo y de los proveedores?

Manejabilidad

Este tema de conversación abarca nuestra capacidad para comprender la salud y el rendimiento del sistema en vivo y gestionar las operaciones del sitio. Algunas consideraciones útiles específicas de la nube incluyen:

Monitorización

• ¿Cómo pensamos supervisar la aplicación?
• ¿Vamos a utilizar servicios de monitorización estándar o a escribir los nuestros?
• ¿Dónde se almacenarán físicamente los datos de seguimiento/medición? ¿Se ajusta a las políticas de protección de datos?
• ¿Cuántos datos producirán nuestros planes de control?
• ¿Cómo accederemos a las métricas y a los registros? ¿Tenemos un plan para hacer que estos datos sean utilizables a medida que aumenten los volúmenes?
• ¿Es necesario auditar y registrar?
• ¿Podemos permitirnos perder algunas métricas/registros/datos de auditoría (es decir, podemos utilizar un diseño asíncrono para "disparar y olvidar" para ayudar al rendimiento)?
• ¿Tendremos que modificar el nivel de supervisión en tiempo de ejecución?
• ¿Necesitamos informes de excepción automatizados?

Implementación

• ¿Cómo automatizamos el despliegue?
• ¿Cómo podemos parchear y/o reimplantar sin interrumpir el sistema en vivo? ¿Podemos seguir cumpliendo los acuerdos de nivel de servicio?
• ¿Cómo se comprueba que un despliegue se ha realizado con éxito?
• ¿Cómo podemos revertir un despliegue fallido?
• ¿Cuántos entornos necesitaremos (por ejemplo, de desarrollo, de prueba, de ensayo, de producción) y cómo se desplegará en cada uno de ellos?
• ¿Necesitará cada entorno un almacenamiento de datos independiente?
• ¿Es necesario que cada entorno esté disponible 24 horas al día, 7 días a la semana?

Viabilidad

Cuando se habla de viabilidad, se tiene en cuenta la capacidad de entregar y mantener el sistema, dentro de las limitaciones de presupuesto y tiempo. Entre los elementos que merece la pena investigar se encuentran:

• ¿Pueden cumplirse los acuerdos de nivel de servicio? Es decir, ¿existe un proveedor de servicios de nube que pueda garantizarnos el tiempo de entrega que nosotros necesitamos para nuestros clientes?
• ¿Disponemos de los conocimientos y la experiencia interna necesarios para diseñar y crear aplicaciones en la nube?
• ¿Podemos construir y diseñar la aplicación dentro de nuestros límites presupuestarios y en un tiempo que tenga sentido para la empresa?
• ¿Cuánto tendremos que gastar en costes operativos (los proveedores de la nube suelen tener estructuras de precios muy complejas)?
• ¿Qué podemos reducir de forma razonable (alcance, acuerdos de nivel de servicio, resiliencia)?
• ¿Qué compensaciones estamos dispuestos a aceptar?

Conclusión

La consideración de estos cuatro temas (disponibilidad, escalabilidad, capacidad de gestión y viabilidad) te ayudará a descubrir las áreas de tu aplicación que requieren una reflexión específica sobre la nube, especialmente en las primeras etapas de un proyecto. Los elementos que se enumeran en cada uno de ellos no son exhaustivos, pero deberían proporcionarte un buen punto de partida para el análisis.