Evolution of cloud native builds and deployment techniques

Its been bit long I posted anything out here as I was in a transition phase . Today's post is very special to me as this would be the last post while I complete my workplace transition and move to a new workplace. I would like to leverage this opportunity and pen down one my my recent and joint learning(with Himanshu Gupta from Infosys).

We have seen traditional monolith architecture and how they are being broken down into microservice architecture. The evolution from legacy monolith the microservice is not just true for any functional architecture, but also for cloud native build/deploy tools.

Docker started in the era of microservices evolution, however it had been by itself a monolith process that runs in the background performing image build/deploy and further management. We have seen developers writing lengthy and complex dockerfile and it bomes difficult to maintain. Additionally there are few more challenges in the dockerfile or docker build techniques that makes it difficult to maintain. 

1. Docker file gets created by individual developers and we do see lack of standards being followed in writing docker files.
2. Security has always been an issue with dockerfile as we see docker sockets being mounted and user needs admin privileges' to run docker builds. One can ingest any malware code in dockerfile and execute it as it runs with elevated privileges'
3. Every time the image is being built, all the steps gets re-executed and that makes the build process less efficient affecting the performance.

So, what is in store for us ?

Soon Kubernetes/Openshift will, if not already, remove the support for Docker. We are also seeing lightweight edge kubernetes-based cluster where running a separate docker daemon process becomes a liability as well as impediment to Edge deployments. 

There are other builds which we have seen in the past especially from Red hat in the form of S2I(source to image). However very few people know that S2I internally uses dockerfile-based build as well to create the builder image. It also needs Docker daemon to run. 

So how are organizations going towards more cloud native build and deployment techniques?

1. Getting away of monolith docker background processes and implementing daemon-less tools.
2. Use separation of concern as well in build and deployment tools. Use multiple tools intended to do different work.
3. Enable even developers do builds from anywhere without the need for admin privileges'. 

This is what one of the toolchain that Red Hat has come up with in order to address the above issues. 

What we see above is that we have now different tools to do different jobs without the need of any heavy daemon process to run. All of these tools can be orchestrated in a devops lifecycle and BINGO !!! The developer doesn't have to write a docker file at all. Not just that we get an OCI compliant image that can run anywhere and not just in Kubernetes. It can even run in Cloudfoundry/Hereku using buildpacks. 

We can use the same S2I concept , without using docker and create OCI compliant images. The folowing value and benefits can be achieved using this process. 

S2I is used to build containerized applications by simply providing source code as an input.

• Flexibility – You can customize a service to fit your needs by providing a configuration file that rewrites the values used in a container by default.
• Any platform – You can use S2I for building standalone containers on several Linux platforms that provide the s2i RPM package, including Red Hat Enterprise Linux, CentOS, and Fedora or take advantage of the s2i binary.
• Separated images and service configuration – Although having a clear distinction between images and service configuration allows you to perform adjustments that are more complex, the build reproducibility remains preserved at the same time

Buildah is a tool that facilitates building OCI container images capable of running on docker or any OCI compliant engine.

• It allows for finer control of creating image layers. Committing many changes to a single layer is desirable.
• Buildah can build images from scratch, that is, images with nothing in them at all.

Skopeo is a tool to inspect, push and tag images to image registry. 

Podman provides enhanced security. For starters, containers under the control of Podman can either be run by root or by a non-privileged user, maintaining almost all functionality. This is a great advantage since you can run your containers with different users who have different privileges.

• Podman directly interacts with Image registry, containers and image storage. As we know Docker is built on top of runC runtime container and uses daemon, Instead of using daemon in Podman, it is directly using runC runtime container.
• Podman is capable of using UID separation using namespaces, which provides an extra isolation layer when running containers making it a safer tool.

The below diagram provides a pictorial view on how we build images now vs how the future looks like. 

Where we do see the use case of these tools and techniques ?

While I discussed earlier, we will see growing use cases in Edge computing area . In edge computing memory and cpu are of maximum importance and Buildah/Podman will help in addressing the same concern

How do we migrate existing workloads ?

Both Buildah and Podman can use the same dockerfile and build an OCI compliant images. So we dont need to run a docker daemon and neither any parts of docker need to be installed. 

I hope I was able to provide a view on some of the upcoming container build/deployment techniques .