Why Kubernetes and cloud deployment happened and the history behind it.

In this article we’ll talk about Kubernetes and Cloud deployment. We’ll have a short history of what was deploying an application before Docker, Cloud, Virtualization and Kubernetes.
Also cloud infrastructure via K8S can be applied in the context of video as encoders, which reduce the complexity size and optimize for getting the best quality can be deployed on Kubernetes clusters. In order to speed up the Coding a video and also to enable the transcoding and encoding of very high quality video, Like full HD or 4K, by splitting the load on different nodes and pods. And we will see why this all works together in conjunction with a bit of History. So let’s start from there. So initially we had a situation were Cloud wasn’t there, right? We had virtual machines or servers living in the internet and people just connect them and it’s our first case: App -> Deployment on VM -> User. So we have an application on a virtual machine and the user can reach it. Then we evolved from that, we got into versioning: App -> GitRepo/Versioning -> Continuous deployment/Continuous integration -> VM/Server -> User. So we version each file that gets added to a repository. And this versioning means that if something changes we can track it and we can act upon it and this is where this type comes in. So, a CI CD, which is continuous integration and continuous deployment. Basically, we react via hooks to changes in the code which then get pushed in a repo. Then whole process kicks off is the CI/CD process where, for example, unit tests can run at this step or integration tests. And the build can happen if the application requires a build step, like a Typescript app that needs transpiling to Javascript. All of these happens in the CI/CD phase. Then that gets deployed to a VM and the user accesses the code on the VM and the application there. Then we evolved again from that. We went from that environment to something called virtualization and Docker, App code -> GitRepo/Versioning -> CI/CD -> VM/Server -> Docker container -> User. Okay, so We basically add a way to define and explicitly specify what the server here, which was just running on a server somewhere would need to function. We create a sort of a manifest of the computer, specified in a Dockerfile, which defines which resources (for example installing FFMPEG of a specific version to get a specific filter like black detect or freeze detection) and how these must be installed and what is needed to run the application. Or for example if we need a specific version of Python. This was now not defined at the Vienna level or at the server level but it was defined in a configuration file. This configuration file, which is called a Docker file, has steps that are needed to kind of bring that application to life. So from this step. We basically added in. A virtualization file which allowed to then? Deploy a container which basically was a self-contained unit running on VMware, server with the file specification, which we gave before. So we have now a container, which is extensible, can be deploying different parts easily running on a virtual machine or server or really whatever you want after being deployed by a CI CD step. Then you have the user connecting to that container which exposes a port. So what situation are we are now?

The history behind deployment on Kubernetes


Now we develop locally with already in mind a cloud structure and infrastructure as code. We have a configuration which mimics a cloud environment and you can use something like tilt.dev and we basically replicate the Kubernetes cluster environment locally. Once we have that we feed the K8S objects that we want to run through tilt. So what does the process look like right? App code -> GitRepo/Versioning -> CICD of the app -> infracode k8s repo where version of code repo is increased -> CICD -> K8s deployment -> Node -> Namespace -> Pod -> Container -> User. And this is infrastructure as code, resources and deploy paths are declaratively specified and mirror an intent. We basically developed locally with tilt, then we actually make changes to the app repo. We push the repo to, to the remote. We then have a CI CD step, which for example runs the unit test runs the build, then when this step ends, CI/CD deploys, or increments a version in an infrastructure git repo. So this is your code does law. It’s a declarative repository, specifying resources and steps to deploy an app in a Kubernetes environment. And in this infra code repo, we specify which environment this deploy must go too for example in Production, the latest version which was created in the CI/CD step earlier is tagged and deployed in the k8s cluster. The application is hosted on a node. Inside a pod and then run in the container which we used specify in the Docker manifest file and then a user can access it. And this way, it’s a much much better and replicable development method because you know what everything changes and you can control exactly what goes in which environment and with which resources, if you need to scale, and also if you need to overwrite some files, so it’s a great way to actually do software development these days building for accountability, resiliency, and scalability.