Aplicaciones en Cloud con PaaS y CaaS

Aprende cómo estos modelos optimizan el desarrollo y despliegue de aplicaciones.

Modelos de despliegue en CaixaBank Tech: PaaS y CaaS con Kubernetes

En CaixaBank Tech trabajamos con una plataforma Cloud basada en la tecnología de Kubernetes. Es una tecnología que ofrece más agilidad y versatilidad. Sin embargo, con el cambio de la plataforma, hemos tenido que cambiar la forma de trabajar y, por consiguiente, hemos dejado atrás la idea de acceder a un servidor para subir la nueva versión del binario aplicativo y reiniciar el servidor web para que se actualice la versión para pasar a un modelo en el que distribuimos el código fuente y las herramientas son las encargadas de generar el contenedor Docker y de desplegarlo en Kubernetes.

En CaixaBank Tech disponemos de dos modelos diferentes de despliegue de las aplicaciones en Cloud: Platform as a Service (PaaS) o Container as a Service (CaaS). En ambos casos se basan en el mismo stack tecnológico:

• GitLab
• Herramienta propia para el CI/CD (basada en Jenkins)
• Docker
• Kubernetes

A continuación, explicaremos los dos modelos de despliegue comentados.

PaaS (Platform as a Service)

Para la solución cloud de Platform as a Service (PaaS), proporcionamos la plataforma con la que se construirá y desplegará la aplicación, entendiendo plataforma no solo como la infraestructura, sino también como las imágenes base Docker, los Charts, etc. El listado de recursos que proporcionamos es:

• Imagen Docker Base: Disponemos de un catálogo de tecnologías base como Java, Python, PHP… Estas imágenes se utilizan en las imágenes Docker multistage.
• Imagen Docker Multistage: Esta imagen se utiliza para hacer la construcción del binario aplicativo en el primer stage y el segundo stage se trata del propio runtime A partir de esta imagen, se genera la imagen Docker aplicativa que se despliega. En este punto también se revisa la calidad del código, vulnerabilidades…
• Chart Helm: Los charts se utilizan para el despliegue de las imágenes aplicativas mediante la creación de los objetos de Kubernetes a partir de templates

Con el conjunto de recursos que proporcionamos como solución de la plataforma conseguimos que el equipo se abstraiga de la solución de Kubernetes y se centre únicamente en el código aplicativo a la hora de desarrollar.

El flujo de trabajo de los equipos de desarrollo representado en el diagrama es el siguiente:

1. El equipo aplicativo sube el código de su aplicación a GitLab.
2. Cuando han subido el código, usan la herramienta de CI/CD para construir y distribuir la imagen Docker aplicativa en nuestro Docker Registry.
3. Antes de desplegar la aplicación, desde la herramienta, configuran el entorno donde se despliega la aplicación: secretos, ficheros de configuración, urls públicas…
4. Finalmente, con el entorno configurado, utilizan la herramienta de CI/CD para desplegar la versión de la aplicación.

CaaS (Container as a Service)

Las soluciones cloud con CaaS están pensadas para casos excepcionales en que los PaaS no se adaptan a las necesidades o cuando se han de desplegar productos con su propia imagen base. En comparación con la solución PaaS, los equipos aplicativos no solo son responsables del código de la aplicación, sino también de preparar todos los objetos de despliegue de Kubernetes.

De soluciones CaaS nos encontramos con dos tipos diferentes:

• Basadas en imágenes Docker de producto.
• Basadas en imágenes Docker base del catálogo interno.

Para cada caso el flujo de trabajo de los equipos es un poco diferente por lo que vale la pena explicar ambos modelos.

El flujo de trabajo de los equipos de desarrollo si la imagen Docker es de producto es el siguiente:

1. El equipo aplicativo prepara los objetos de Kubernetes para su despliegue: Deployment/StatefulSet, Service… y los sube a GitLab.
2. Cuando han subido el código, usan la herramienta de CI/CD para construir y distribuir la imagen Docker aplicativa en nuestro Docker Registry.
3. Antes de desplegar la aplicación, desde la herramienta, configuran el entorno donde se despliega la aplicación: Secretos, ficheros de configuración, urls públicas…
4. Finalmente, con el entorno configurado, utilizan la herramienta de CI/CD para desplegar la versión de la aplicación.

El flujo de trabajo de los equipos de desarrollo si la solución se basa en una imagen del catálogo interno es el siguiente:

1. El equipo aplicativo sube el código de su aplicación a GitLab.
2. Preparan un Dockerfile que hará la construcción del binario aplicativo, además de preparar el runtime del contenedor.
3. Construyen la imagen Docker aplicativa usando las herramientas de distribución.
4. Preparan los objetos de Kubernetes: Deployment/StatefulSet, Service… y los suben a GitLab.
5. Antes de desplegar la aplicación, desde la herramienta, configuran el entorno donde se despliega la aplicación: Secretos, ficheros de configuración, urls públicas…
6. Finalmente, con el entorno configurado, utilizan la herramienta de CI/CD para desplegar la versión de la aplicación.

La diferencia entre una solución y la otra reside en que si se trata de una imagen de producto no es necesario codificar un DockerFile que prepare el runtime aplicativo, ya que lo ofrecen como solución de producto.

Comparación entre CaaS y PaaS en despliegue y gestión de vulnerabilidades

Después de ver qué implicaciones tiene el uso de cada uno de los modelos de despliegue, el CaaS puede resultar el más atractivo porque da la oportunidad de tener un mayor control sobre el despliegue de la aplicación en Kubernetes al tener que codificarlo. La parte negativa es que el equipo aplicativo también es responsable de la imagen Docker, por lo que cualquier vulnerabilidad que se detecte por Seguridad la deberán arreglar o gestionar con el proveedor de la solución Docker de producto.

En cuanto al PaaS, el beneficio que tiene es que el equipo aplicativo no necesita tener conocimientos en profundidad de Kubernetes para que su aplicación se despliegue, pudiendo centrarse por completo en su código. Además, el parcheado y resolución de vulnerabilidades con respecto a la imagen es responsabilidad del equipo que proporciona la solución PaaS.