Applications in the cloud with PaaS and CaaS

Learn how these models optimize application development and deployment.

Deployment models in CaixaBank Tech: PaaS and CaaS with Kubernetes

At CaixaBank Tech, we work with a cloud platform that relies on Kubernetes technology. This is a technology that offers more agility and versatility. However, with the change in platforms, we had to change how we work, so we have given up on the idea of accessing a server to upload the new version of the application binary and restarting the web server to update the version, to instead use a model in which we distribute the source code and the tools are tasked with generating the Docker container and deploying it in Kubernetes.

At CaixaBank Tech, we have two different models for deploying applications from the Cloud: Platform as a Service (PaaS) and Container as a Service (CaaS). In both cases, they are based on the same technology stack:

• GitLab
• Internal tool for CI/CD (based on Jenkins)
• Docker
• Kubernetes

The two deployment models mentioned are explained below.

PaaS (Platform as a Service)

For the Platform as a Service (PaaS) cloud solution, we provide the platform that will be used to build and deploy the application. This platform is not just the infrastructure, but also the Docker images, Charts, etc. The list of resources we provide is:

• Base Docker Image: We have a catalogue of base technologies, such as Java, Python, PHP… These images are used in the multistage Docker images.
• Multistage Docker image: This image is used to build the application binary in the first stage, and the second stage is the application runtime. This image is used to generate the Docker application image that is deployed. At this point, the code is also checked for quality, vulnerabilities, etc.
• Chart Helm: Charts are used to deploy application images by creating Kubernetes objects from the parameterised templates.

The set of resources we provide enable the team to detach itself from the Kubernetes solution and focus solely on the application code during the development.

The workflow of the development teams represented in the diagram is as follows:

1. The application team uploads the code of their application to GitLab.
2. Once the code is uploaded, they use the CI/CD tool to build and distribute the Docker application image in our Docker Registry.
3. Before deploying the application, from the tool, they configure the environment where the application is deployed: secrets, configuration files, public URLs, etc.
4. Finally, with the environment configured, they use the CI/CD tool to deploy the version of the application.

CaaS (Container as a Service)

Cloud solutions with CaaS are intended for exceptional cases in which PaaS does not meet the needs, or when products have to be deployed with their own base image. In contrast with the PaaS solution, application teams are not only responsible for the code of the application, but also for preparing all the Kubernetes deployment objects.

There are two different types of CaaS solutions:

• Based on Docker product images.
• Based on base Docker images of the internal catalogue.

In each case, the workflow of the teams is a little different, so an explanation of the two models is warranted.

The workflow of the development teams in the case of a Docker product image is as follows:

1. The application team prepares the Kubernetes objects for deployment: Deployment/StatefulSet, Service… and uploads them to GitLab.
2. Once the code is uploaded, they use the CI/CD tool to build and distribute the Docker application image in our Docker Registry.
3. Before deploying the application, from the tool, they configure the environment where the application is deployed: secrets, configuration files, public URLs, etc.
4. Finally, with the environment configured, they use the CI/CD tool to deploy the version of the application.

The workflow of the development teams if the solution is based on an image of the internal catalogue is as follows:

1. The application team uploads the code of their application to GitLab.
2. They prepare a Dockerfile to build the application binary, as well as prepare the container runtime.
3. They build the application Docker image using the distribution tools.
4. They prepare the Kubernetes objects: Deployment/StatefulSet, Service… and upload them to GitLab.
5. Before deploying the application, from the tool, they configure the environment where the application is deployed: secrets, configuration files, public URLs, etc.
6. Finally, with the environment configured, they use the CI/CD tool to deploy the version of the application.

The difference between the two solutions is that in the case of a product image, a Dockerfile does not have to be coded to prepare the application runtime, since it is offered as a product solution.

Comparison between CaaS and PaaS in deployment and management of Vulnerabilities

Having seen the implications of using each of the deployment models, CaaS may seem more appealing since, by having to code it, it provides the option to have more control over the deployment of the application in Kubernetes. The downside is that the application team is also responsible for the Docker image, meaning it will have to fix any vulnerability detected by Security, or it will have to coordinate it with the vendor of the Docker product solution.

As for PaaS, the advantage it has is that the application team does not need to have detailed knowledge of Kubernetes to deploy its application, and can focus entirely on the code. In addition, the patching and fixing of vulnerabilities involving the image is the responsibility of the team that provides the PaaS solution.