Microservices, Docker, and Kubernetes
A monolithic arch basically means you have a single large program with all the features and things packed into one. The UI layer triggers the functions in the business logic later and the data is transmitted to and from the single data access layer and the DB.
In an MS architecture, the single UI can trigger logic based on several MSs which can have their own DB or all can have a shared DB.
Pros of an MS Arch:
Language independence:
Each MS communicates with the other through HTTP. As long as they all agree upon a single standard, we’re good to go, no matter what the language of the code you wrote.
Dedicated small teams:
Each MS can have a small team dedicated to that microservice instead of one figuring out all features.
Fault isolation:
If one MS has a bug the whole app doesn't fail
Pricing and Scalability:
Your app which is divided into MSs can also now be containerised easily and each container can be put on the cloud. In all this allows your app to scale dynamically at runtime. SAVE MONEY FOR YOUR COMPANY!!
Docker
Docker is a platform to run distributed applications on VMs, systems, Data Centers, Cloud. It solves the issue of “It runs on yours why doesn't it run on mine”.
How you can containerize your app into an image that can be shared with someone and they can run it if they also have docker.
A container is not a VM.
- Let’s say you’ve got an app with multiple containers that need the same libraries and dependencies the BIG pro is all of them can share among them the common libs and deps. So suppose you have 3 containers running a Go application, you don’t need to install 3 instances of it on each of the containers they can all share it.
- Another big one is Docker runs on the host OS whereas for a VM you need to have a guest OS. SO fewer resource consumption.
A dockerfile is the definition of your image and how it builds is specified in the dockerfile with all the sequential commands.
Orchestration
Tools like Kubernetes run your containers.
- A node is a computer running Kubernetes
- A Kubelet is an app that communicates with the master node
- A pod is what contains the container/s
- A service handles requests from inside (one node to another) or outside of a Kubernetes cluster (a public request to hit a MS). It is responsible for how the request is routed and addressed in the cluster.
- The deployment is taken care of using a YAML file
After successful deployment, you can see a minikube dashboard in the browser
In our deployment YAML file we had given the desired state (5 replicas). Let’s say one pod is down somehow or deleted or a node goes offline. Now Kubernetes is automatically trying to keep the state so it will recreate the pod to go from 4 pods to 5 again.
Load balancing in Kubernetes is a method of managing network traffic and allocating resources. It involves distributing network traffic across multiple backend services to increase scalability and availability. A load balancer in Kubernetes assigns pods, containers, and other cluster resources based on their availability when it detects an incoming request
Scaling
Containerizationing …yeah… the app
- We first write a Dockerfile (/nodeApp/Dockerfile)
- Any changes that are done to the Docker image are tracked using hashing
- Now similar to .gitignore file we can create a .dockerignore file to leanify our image. Anything not required for the production can be put into it.
- After specifying the dockerfile, we need to build the image of our app locally.
sudo docker build -t myimage:latest .- After successfully building it let’s run it locally
We map our 8088 port to port 8080 inside of the container running our app.
sudo docker run -p 8088:8080 velvetjedi/nodeapp:v1.0.0
- After everything let’s push our image to the docker hub (which allows users to share and build on existing images)
sudo docker push velvetjedi/nodeapp:v1.0.0Find the created image:
Find here the GitHub Repo of my version of hands-on:
For practical: Thanks James Quigley
