The engine, then the Pilot
Tags: devops, docker, kubernetes, microservices
Published: 2022-07-07 22:59:24

In a monolithic architecture, all the layers of our applications are built into one single artifact. In this case, each service offered by the application is essentially a function call away from another service. This facilitates the networking and communications between the layers of the applications. However, things can get rocky when it comes scaling a part of the application, it is essentially the same cost as scaling the whole application. It becomes difficult to upgrade a layer of the application without causing failure in another unrelated layer.
Micro-service gives us the ability to re-architect our applications into different services such that they can be built, deployed and scaled independently. The services can communicate using an Application Programming Interface, API. 

To achieve a micro-service architecture, we can use container images as our artifact.
Container images are convenient artifacts for software development. We specify the  all the dependencies needed to execute code inside a container in a YAML file called Docker file, we can build this file to create our Docker image. The Docker image is a largely static file that can be deployed on any host without any changes.
Container images readily serve as the engine driving each services and they accelerate our ability to build applications. 

Finally, we need a way to deploy, scale and update these containers. This is where kubernetes comes in.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tspvls9enc76dobsqm9l.jpeg)
 
Kubernetes is an orchestration system for containers. We can create a kubernetes cluster to run our containers, deploy an existing app to the cluster, expose application ports, scale applications and update applications. 
Kubernetes helps us get our applications in front of our customers with maximum up-time using declarative configuration and automation. All we need to do is describe the desired state of the system using objects like pods and services in a YAML file. A kubernetes controller observe the current state of the cluster and brings the system to the specified state. We can do all this from the terminal using kubectl, kubernetes command line tool.
Kubernetes is like a pilot for our workload, while we set the destination.

Now that we are convinced about containers and container orchestration, the next step is to have fun building docker images and managing container orchestration with services like Amazon Elastic Container Service (Amazon ECS) and Amazon Elastic Kubernetes Service (EKS). We can also venture into extending kubectl binary with plugins for authentication. Finally we can establish fine-grained access on our clusters by using self-manged options like Kops and Kubeadm.
If all of these excites you, you should read this googles' article om different generations of containers [here](https://queue.acm.org/detail.cfm?id=2898444). You might want to check [this](https://dev.to/speedygamer12/i-explained-googles-lesson-on-their-container-management-systems-so-you-can-have-fun-reading-43lj) out, I tried to explain some technical terms from the google article. 

In our micro-service architecture, the container image can serve as our engine, whilst kubernetes is the Pilot. Happy learning!