Diseño de aplicaciones Cloud Ready (1 de 3)

Una de las cosas que más me gusta de “evangelizar” sobre el Cloud es la posibilidad de charlar con personas de diferente posición con respecto a la IT dentro de una organización. Por ejemplo, las dudas, cuestiones e inquietudes varían terriblemente si estamos hablando con un:

  • Desarrollador de aplicaciones (en sus distintos grados de “seniority” y al margen de la tecnología en que desarrolle)
  • Administradores de sistemas y en general personal vinculado con la operación de los sistemas
  • CxO
  • Directivos, mandos intermedios y en general lo que podíamos denominar consumidores finales de la tecnología, sin ser ellos en muchos casos participes de su desarrollo

evidentemente con un grupo tan dispar, los intereses, motivaciones y consideraciones de cada uno de estos grupos lo será también y saldrá a la luz por ejemplo a la hora de desarrollar o adaptar una aplicación para la Cloud.

 

Dejando al margen consideraciones relativas a usabilidad (asumiremos que seremos capaces de desarrollar una aplicación usable y que funcione) e incluso de tecnología (nos abstraeremos de decisiones vinculadas a la tecnología tales como la elección del lenguaje de programación), ¿qué deberíamos tener en cuenta a la hora de tener una aplicación CloudReady?

Nota: las ilustraciones las he basado en la Cloud de Oracle aunque serían extrapolables a cualquier proveedor que ofreciese las mismas funcionalidades.

Principios básicos del Cloud:

El cloud cobra sentido en el momento en que nos damos cuenta de que podemos tener acceso a un completo stack tecnológico, pagando solo por aquellas características que usamos y liberándonos del coste asociado a poseer la infraestructura necesaria para disfrutar de esos servicios, por ejemplo:

  • Dispondremos del múltiples regiones distribuidas por el mundo (ideal para recuperación de desastre o para dar servicio a clientes en distintas zonas geográficas)
  • Algunos proveedores operan múltiples datacenter en una misma región (aún más tolerancia a fallos)
  • Flexibilidad (podemos crecer y decrecer conforme lo necesitemos, pagando solo por lo que usemos y sin lastrarnos con costes de propiedad)
  • Escalabilidad (podemos crecer hasta el “infinito” si lo necesitamos
  • Facilidad ( el operador de Cloud ya ha desarrollado numerosas funcionalidades que pueden hacernos la vida más fácil, serverless, PaaS, etc.)
  • y un largo etc.

entonces, ¿qué deberíamos tener en cuenta a la hora de tener una aplicación CloudReady?

Principios de una aplicación Cloud Ready:

Una aplicación Cloud Ready de “libro” es aquella que nos va a permitir sacar el máximo rendimiento a todo el stack tecnológico que tenemos a nuestra disposición.

Escalabilidad el reto del Stateless:

Bien, como ya todos sabéis las escalabilidad puede ser vertical (incrementando los recursos asociados a un servidor) u horizontal (incrementando el número de recursos asociados a un pool de trabajo), desde el punto de vista de escalado vertical debemos tener en cuenta que la tecnología que usemos no establezca limites demasiado bajos que por ejemplo condicionen el nº máximo de vCPUs o de memoria asignadas las máquinas.

¿Qué pasa con el escalado horizontal?, la respuesta rápida es que es muy sencillo de hacer en el cloud, replicamos máquinas virtuales y colocamos un balanceador por delante que además detecte si un servidor a caído o no. Ya está, ¿fácil verdad?,

OCI Load Balanacing

pero… y que ocurre con las sesiones, ¿da igual que nos atienda un servidor un otro?. Si la respuesta es no, significa que nuestra aplicación no es stateless.

La solución rápida pasa nuevamente por hacer que una conexión vaya siempre al mismo servidor, lo que puede originar problemas como el siguiente:

Sticky Load Balancing

la solución elegante y Cloud Ready sería hacer que nuestra aplicación fuera stateless (o que el estado de la sesión no residiese en la propia conexión), de esta manera cualquier servidor podría atender cualquier petición. (Los colores indican peticiones de un mismo usuario, para ilustrar que las puede atender cualquier servidor)

OCI StateLess Load Balancing

 

Ahora mucho mejor, ¿verdad?

 

Tolerancia a fallos el reto de la persistencia del dato:

Aunque el uso de balanceadores ya aporta cierta tolerancia al fallo, la realidad es que este tipo de dispositivos están pensados para situarse delante de servidores web y de aplicación, pero existen otros muchos tipos de servicio que no podrían beneficiarse (al menos en primera instancia de esta funcionalidad).

Conseguir la persistencia del dato a nivel de fichero puede ser tan sencillo como hacer uso de funcionalidades como el ObjectStorage o similar, que de manera nativa van a realizar replicación del dato entre distintas Zonas de disponibilidad, garantizando así su supervivencia.

OCI Stateless + ObjectStorage

genial tenemos nuestros datos a salvo en un almacenamiento distribuido y de alto rendimiento, pero ¿Qué pasa por ejemplo con las bases de datos?

Bien, las bases de datos son probablemente el caso más complejo de las aplicaciones que a priori ni pueden beneficiarse del uso del balanceadores “clásicos”. La aproximación es este caso pasa por diseñar/desplegar una arquitectura Activo/Pasivo (para tener tolerancia a fallo) o Activo/Activo (para tener además de la tolerancia a fallo balanceo de carga.

La opción más fácil de implementar es un Activo / Pasivo, en los gráficos lo voy a ilustrar con una BBDD Oracle, pero es extrapolable a cualquier otra BBDD que soporte funcionalidades similares.

OCI Dataguard

 

 

si quisiéramos un Activo / Activo en el caso de Oracle estaríamos hablando de un RAC, que podríamos incluso complementar con un Dataguard:

OCI RAC

 

Es importante que tengáis en cuenta aquellas limitaciones propias de la tecnología de BBDD que uséis y del proveedor que elijáis, por ejemplo:

  • Si queréis un modelo Activo / Pasivo, ¿necesitáis garantizar la replicación síncrona?
  • Si necesitáis replicación síncrona, ¿garantiza vuestro proveedor las latencias mínimas necesarias para no tener problemas?
  • ¿Esta certificado vuestro proveedor de cloud para la funcionalidad que queréis usar?, en el caso de Oracle (a día de hoy 08/05/2018) por ejemplo si queréis usar un Active Dataguard o un RAC solo están soportados en la cloud de Oracle

en próximas entradas profundizaremos un poco más en las características que debe reunir nuestra aplicación  para ser Cloud Ready.

Espero os haya resultado de interés y utilidad y nos leemos en próximas entradas.

Deja un comentario

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies