Introduction

• Monolithic applications are difficult when scaling individual portions of the application. If one service is memory-intensive and another is CPU-intensive, then the server must be provisioned with enough memory and CPU to handle the baseline load for each service. This can get expensive if each server needs a high amount of CPU and RAM, and is exacerbated if load balancing is used to scale the application horizontally. Finally, and more subtlety, the engineering team structure will often start to mirror the application architecture over time.

  image comes here

• In my project I'll use Docker container images and Kubernetes to help my Django webapp which will use any number of micro-services to function and tries to achieve architectural goals mentioned above.The architecture of containers is the major benefit.Breaking applications up this way offers the ability to place them on different physical and virtual machines, in the cloud or not. This flexibility offers more advantages around workload management and provides the ability to easily make fault-tolerant systems.

• A container image is a lightweight, stand-alone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, settings. Available for both Linux and Windows based apps, containerized software will always run the same, regardless of the environment. Containers isolate software from its surroundings, for example differences between development and staging environments and help reduce conflicts between teams running different software on the same infrastructure.

  image comes here

- Container or VM? Container or VM?

As of today, there is a significant trend in the industry to move towards containers from VMs for deploying software applications. The main reasons for this are the flexibility and low cost that containers provide compared to VMs.

image comes here (in parallel see here ) image 1 image 2

• Kubernetes Kubernetes is an open source system for managing clusters and deploying “containerised” applications. Kubernetes abstracts the underlying hardware (of your cloud provider or on-premises cluster), and presents a simple API that allows you to easily control it. You send this API some declarative state, e.g. “I’d like three copies of my Django app container running behind a load balancer, please,” and it ensures that the appropriate containers are scheduled on the nodes of your cluster.

Furthermore, it monitors the situation and ensures that this state is maintained, allowing it to be robust to arbitrary changes in the system. This means, for example, that if a container is shut down prematurely because a node runs out of memory, Kubernetes will notice this and ensure another copy is restarted elsewhere.

Kubernetes works by having agents that sit on each node of your cluster. These allow for things like running Docker containers (the docker daemon), making sure the desired state is maintained (the kubelet), and that the containers can talk to each other (kube-proxy). These agents listen to and synchronise with a centralised API server to ensure that the system is in the desired state.

image comes here