Awesome World of Cloud, Containers, and Kubernetes

Do you know AWS made up a large portion of Amazon’s operating income, making it the key to the company’s overall profitability?
All thanks to the rise of the cloud and the flexibility it provides to large organizations in orchestrating their infrastructure.

Working with some of the major US clients I have seen firsthand how these organizations are able to quickly deploy and scrap environments on the cloud with help of automation tools like terraform, TeamCity, etc (which itself is a talk of another day).

It helps them in saving millions of dollars annually, Let’s take an example when we talk about large organizations, they are in the market for decades and have many libraries and small applications interacting with each other, when they deploy them with the help of cloud-based API and automation tools they have a freedom of taking them down and redeploying them whenever needed for different purposes, they can automate up and downtime based on need, e.g on the testing environment which is being used by day time only have no use of being online 24 hours they can be only up when testing is being done and scrapped after working hours, this processing power can be used somewhere else or if not It will save some money to the organization. And based on the complexity of applications and the number of services these applications use it can be a big amount If we look into the big picture.

Now we know that cloud is good and it saves millions to organizations in long run, next question is how much we can optimize these savings and how robust we can make these applications, decreasing our downtime to almost 0% or how close we can go to this benchmark, this is where containerization of application infrastructure comes in picture.

Let’s make it clear here that docker or Kubernetes can’t be learned by reading one article, what my aim here is to introduce you to these tools and give you a big picture and raise your interest, and since most of the technologies are large organization backed you can find tons of tools online and slowly grow your knowledge. Don’t get frustrated and be in hurry, learning docker or Kubernetes is a slow path and takes time.

The first question which every student should ask is why?
Although we have gained some basics information about the cloud let’s know why we need Kubernetes and containers when we have cloud instances on AWS or Google Cloud.

And the answer to this is flexibility, uptime, robustness, cost-saving, and utilization of resources.

Imagine that you have an application that you want to deploy on the cloud, so what do you need, In its simplest form, you need a Linux instance to host your server, you need some storage to save files and you need a database server to store the application data.

so
Instance: 4 GB RAM, Storage 16 GB, and a Different instance to run your Database server

You can always argue that why this or why not that but hey My job here is to give you a usability advantage and I will pick an example that suits my narrative. So If you have a different configuration in mind then good luck with that make your own example. e.g we can say why not run the database engine on the same instance and my answer to that is to say goodbye to scalability.

so let’s see how can we make a configuration which can contribute to zero downtime deployment means how to make sure my application stack is always UP? Let’s put a load balancer over this combination and scale this combination by 3. Yeyyy… we reached zero downtime, but wait… are we getting the best deal to our buck?

so let's see how can we make a configuration which can contribute to zero downtime deployment means how to make sure my application stack is always UP? Let's put a load balancer over this combination and scale this combination by 3. Yeyy we reached zero downtime, but wait are we getting the best deal to our buck?

I mean by 3 we are paying for 12 GB of RAM, 48 GB of storage, and 1 DB instance of whatever size we choose,
dang it… Let's do autoscaling so based on a certain amount of CPU and Memory usage we will decide how many instances to run which can not be applied to the database since it needs data consistency but let's leave that for a minute and say we can save in terms of ram and memory. You see we started hitting limitations even in our imaginary scenario.

But still is our 4 GB RAM and 16 GB storage server 24 hours at full throttle and its reserved capacity is in use always, almost always the answer is no, In day time usage might go at the higher side but at night even this server configuration is losing money, but we can’t take it down fully, who knows which of your customer will find it down for 1 second and go on to Twitter and cry about it. we are a large organization and can’t afford such negative publicity.

Look I am committed here to not pay a penny to Bezos more than he is providing me service of so let's think about something, how can we achieve such a level of flexibility. let's break it into smaller instances.

But how?
This is where docker comes into the picture.
what is it?
By official definition: Docker is a set of platforms as service products that use OS-level virtualization to deliver software in packages called containers.

Ok, so what is a container?

well, it's the smallest possible Linux kernel (mostly using alpine distro of Linux) with a size as small as 13 MB nothing else, rest you can install as needed.

so how can it help in our scenario?

Have you seen a beehive? If you deploy your application using Docker and Kubernetes that is what your application infrastructure is.

Let's talk technical and try to understand our components and wrap our heads around them.

In short, the smallest part of our infrastructure is containers but Kubernetes doesn’t count it as a single unit,

well then what is the smallest unit?
a collection of these containers which we will call pods. you see it's all a sci-fi movie here.

A pod is the smallest unit in Kubernetes term made up of multiple containers local to each other.

In the theoretical level above pods are nodes, now what is a node?
To understand that we will have to go one more level up which is called a cluster,
so what is a cluster?
A cluster is your entire collection of machines which can be like 5 machines with 3 GB Ram totaling 15 GB, and each of these machines is your node.
which pod will run on which node is decided by Kubernetes.

so now if we look again at our hierarchy, we have pods above which is a node, and above which is a cluster.

There are two more things that complete our theoretical discussion,

1. Interaction with Kubernetes
2. Services to do different works like load balancing, networking, etc

Let's talk about how to interact with Kubernetes?
For interaction we use kubectl, you see rather than providing any specific tools to manage your infrastructure with Kubernetes it gives you an API, now this API can be utilized by many tools, e.g in CLI(command-line interface) we have kubectl and in GUI we have Kubernetes dashboard and different companies can have different tools thanks to the API based communication approach. (An API is a request-response-based architecture used widely for web-based communication by applications mainly of two types REST and SOAP. Kubernetes uses REST, almost all your mobile applications are using API)

Now let's talk about services, to provide some other different tasks Kubernetes provide services, for example, we have LoadBalancer service which exposes your service and maps itself to cluster IP controlling your web traffic based on pod health and availability.

now with all these, we can decide the size of our application as small as 13mb+your code base and also decide what amount of RAM and processor you want to allocate to your containers based on your application requirements, and then just tell Kubernetes how many of pods you want to run.

now you have more control since these are the smallest possible units, let me help you in counting the flexibility

1. we can decide how many machines cluster should run based on your current pod health and CPU or memory utilization which will save cost If not a lot of user then just run 1 node in the cluster and as the usage rise and pod number increases increase my cluster, you can set max and min in node count or pod count.
2. we can decide how to distribute your new changes, it provides you many ways of pushing your changes on your cluster by default it is a rolling update, and if the deployment fails your application won’t go down just one pod in many so no worries.
3. Till your pod is in a healthy state Kubernetes won’t send traffic to it, so no unhappy customer.
4. we can share storage between pods so cost saving here, if you run one Linux machine in AWS you have to allocate 16 GB of storage to it most of the time but here all your pods can share the same storage so more saving here
5. we have zero downtime since if any pod fail Kubernetes will delete it slowly and spinup new pod and you have to do nothing, your users are not gonna notice a thing.
6. And most important we are always using the maximum amount of server capacity that we paid for.

There are many more advantages, a lot can be talked about Kubernetes and docker and there are numbers of books you can read to sharpen your knowledge, I would recommend you to go to the official documentation site provided by Google (https://kubernetes.io/docs/tutorials/) and do hands-on practice which is the best approach of learning it.
If you have any question you can reach out to me at
http://kumarravi.me
from here you can get my Twitter, Linkedin, and Github contact