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

Desarrollando la serie de artículos sobre el diseño de aplicaciones CloudReady , continuamos  con esta segunda entrada.

Si no leíste la anterior o no lo recuerdas es buen momento para leerla de nuevo antes de continuar.

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

El reto de la Elasticidad:

Uno de los mayores atractivos que ofrece el Cloud es la posibilidad de ser elástico, crecer cuando lo necesitamos y “adelgazar” cuando no lo necesitamos para reducir costes.

Si hemos hecho los deberes y nuestra aplicación es stateless, podremos soportar sin ningún problema (siempre que nuestro proveedor lo haga) crecer y decrecer, por lo que ya habremos dado el primer paso.

Nuestro segundo paso será usar un elemento que nos permite realizar ese crecimiento/decrecimiento de manera elástica y que típicamente será un balanceador de carga.

En la siguiente imagen ilustro una aplicación que cumple los requisitos de ser stateless y dispone los recursos de arquitectura (balanceador) necesarios para escalar y decrecer y que esta experimentando un momento de sobrecarga:

OCI Overload

la solución a este problema pasa por definir reglas de escalado, que creen recursos de computo para procesar esas peticiones cuando sea necesario:

OCI No Overload

The containers meet the Cloud, el reto de la portabilidad y simplificación:

Muy pocos entornos son diseñados con el webscale en mente y en pocos sitios podemos conseguir esto de una manera tan sencilla como en el Cloud.

En general cuando empezamos a hablar de arquitecturas escalables, etc, etc. y si estamos al día del estado del arte, empezaremos a tener en cuenta el concepto de contenedor o container.

¿Qué es un contenedor?, explicado de una manera sencilla es un paso intermedio entre la virtualización (donde creamos un servidor virtual completo, con su software y hardware virtual) y el servidor físico tradicional. La siguiente imagen con Docker (la solución de contenedores más utilizada) ilustra perfectamente la diferencia existente.

Docker

la idea subyacente es que si somo capaces de “empaquetar”, nuestras aplicaciones en contenedores, podremos desplegar estos de una manera muy sencilla en la nube.

Si optamos por usar contenedores, podemos optar por desplegar nosotros mismos el engine de Docker en modo IaaS o usarlo como servicios PaaS si nuestro proveedor Cloud lo ofrece.

Si queréis saber más sobre el Servicio Cloud Container Native de Oracle, podéis hacerlo en el siguiente enlace.

El reto de gestionar los contenedores:

Cuando empezamos a sentirnos cómodos con el uso de contenedores, es habitual que veamos posibilidades de desplegarlos por todos lados y que suframos un episodio similar al ocurrido con la adopción masiva de la virtualización, esto es…. empiezan a salirnos contenedores como setas y comienza a complicarse su gestión.

Contenedores en Puerto

Para gestionar la complejidad de un entorno masivo de contenedores, es recomendable apoyarnos en herramientas de gestión. Existen varias:

la más usada a día de hoy es Kubernetes.

Al igual que con Dockers tenemos la posibilidad de desplegar nuestro propio cluster de Kubernetes en modo IaaS o si nuestro cloud provider lo permite usar este servicio como PaaS.

En el caso de OCI se usa Kubernetes y podéis consultar información adicional aquí.

Cuidado con el vendor locking:

Si potamos por una solución de contenedores ya sea ofrecida por nuestro proveedor de cloud o instalada por nosotros en modelo IaaS es importante que tengamos claro si estamos implementando las opciones OPEN de Docker y Kubernetes o algún tipo de fork de ellas.

El riesgo de usar un Fork es caer en algún tipo de vendor locking. Usar forks propietarios no tiene porque ser malo (quizás en nuestro caso este justificado), pero es importante hacerlo de manera consciente.

En el caso de OCI NO se usan fork propietarios, por lo que el usuario es libre de entrar/salir de la cloud con total facilidad, pero existen otros providers que si usan forks propietarios de los proyectos originales.

 

El reto del Serverless:

Con nuestra aplicación corriendo en la nube, contenerizada, escalable, estateless…etc,etc, llega el momento de hacerla 100% Cloud nativa y esto lo conseguiremos haciendo uso de serverless.

El serverless es posiblemente la última frontera de la adopción Cloud.

El concepto es muy sencillo, a mi me interesa ejecutar una carga de trabajo determinada, cuando la necesito, no tener un servidor activo esperando ejecutar esa carga.

Para ello nuestro proveedor de Cloud nos ofrecerá un pool de recursos, capaz de “comerse” esas cargas de trabajo y devolvernos un resultado y nos generará gasto unicamente por el tiempo de proceso de esa carga de trabajo.

Existen múltiples proveedores de Cloud que ofrecen servicios Serverless, nuevamente lo más importante es no caer (al menos no de manera inconsciente) en un vendor locking.

Un ejemplo de serverless propietario son las Lambda de AWS, si desarrollamos basándonos en Lambda, debemos ser conscientes de que esas cargas de trabajo solo podrán ejecutarse en AWS y que si algún día queremos sacar esas cargas a otros Clouds, tendremos que reescribirlas.

Actualmente el proyecto libre más usado es FN project y es el que usa por ejemplo OCI.

Logo FN Project

 

con esto terminamos esta segunda entrega de diseño de aplicaciones Cloud Ready. Espero os haya resultado de utilidad e interés.

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

Diseño de aplicaciones Cloud Ready, un caso real (3 de 3)

 

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

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