Originally published at https://devopscube.com on April 29, 2023.

Learning Kubernetes can seem overwhelming. It’s a complex container orchestration system, that has a steep learning curve. But with the right roadmap and understanding of the foundational concepts, it’s something that any developer or ops person can learn.

In this Kubernetes learning roadmap, I have added prerequisites and complete Kubernetes learning path covering basic to advanced Kubernetes concepts.

Note: I have published a CKA certification learning course .You can join the course here Complete CKA Course . Use code DCUBE30 to get 30% discount on the course.

Kubernetes Certification Discount: If you are preparing for Kubernetes Certification, get discount at https://kube.promo/devops (code: DCUBE30)

CKA + CKS Bundle ($210 savings): https://kube.promo/bundle (code: DCUBE30)

Prerequisites To Learn Kubernetes

Before jumping into learning kubernetes, you need to have a fair amount of knowledge of some of the underlying technologies and concepts.

1. Distributed system: Learn about distributed system basics & their use cases in modern IT infrastructure. CAP theorem is good to have knowledge.
2. Authentication & Authorization: A very basic concept in IT. However, engineers starting their careers tend to get confused. So please get a good understanding of learning from analogies. You will quite often see these terms in Kubernetes.
3. Key Value Store: It is a type of NoSQL Database. Understand just enough basics and their use cases.
4. API: Kubernetes is an API-driven system. So you need to have an understanding of RESTFUL APIs. Also, try to understand gRPC API. It’s good to have knowledge.
5. YAML: YAML stands for YAML Ain’t Markup Language. It is a data serialization language that can be used for data storage and configuration files. It’s very easy to learn and from a Kubernetes standpoint, we will use it for configuration files. So understanding YAML syntax is very important.
6. Container: Container is the basic building block of kubernetes.The primary work of Kubernetes is to orchestrate containers. You need to learn all the container basics and have hands-on experience working on container tools like Docker or Podman. I would also suggest reading about Open container initiative and Container Runtime Interface (CRI)
7. Service Discovery: It is one of the key areas of Kubernetes. You need to have basic knowledge of client-side and server-side service discovery. To put it simply, in client-side service discovery, the request goes to a service registry to get the endpoints available for backend services. In server-side service discovery, the request goes to a load balancer and the load balancer uses the service registry to get the ending of backend services.
8. Networking Basis

• CIDR Notation & Type of IP Addresses
• L3, L4 & L7 Layers (OSI Layers)
• SSL/TLS: One way & Mutual TLS
• Proxy
• DNS/IP
• IP Tables
• IPVS
• Software Defined Networking (SDN)
• Virtual Interfaces
• Overlay networking
• eBPF

1. Learn Kubernetes Architecture

Understanding Kubernetes architecture is not an easy task. The system has many moving parts that need to be understood in order for you to get a grip on what’s happening beneath the surface. While learning architecture, you will come across the concepts we discuss in the prerequisites.

As Kubernetes is a complex system, trying to understand the core architecture could be a little overwhelming for DevOps Engineers. As you get more hands-on experience, you will be able to understand the core architecture better.

Here is my suggestion. Learn the high-level architecture and key components involved in Kubernetes. If you are not able to grasp the concept, either you can spend time and do more research on a specific topic or you can learn the concept while doing hands-on. It’s your choice.

Check out the Kubernetes Architecture guide to learn about all the Kubernetes components in detail.

Overall you need to learn the following.

1. Control plane components: Understand the role of each component like API server, etcd, Scheduler, and Controller manager.
2. Worker node components: Learn about Kube Proxy, Kubelet, Container Runtime
3. Addon Components: CoreDNS, Network plugins (Calico, weave, etc.), Metric Server
4. Cluster high availability: Most organizations use managed Kubernetes services (GKE, EKS, AKS, etc.). So the cloud provider takes care of the cluster’s control plane’s high availability. However, it is very important to learn the high availability concepts in scaling the cluster in multiple zones and regions. It will help you in real-time projects and devops interviews.
5. Network Design: While it is easy to set up a cluster in an open network without restrictions, it is not that easy in a corporate network. As a DevOps engineer, you should understand the Kubernetes network design and requirements so that you can collaborate with the network team better. For example, When I was working with kubernetes setup on Google Cloud, we used a CIDR pod range that was not routable in the corporate network. As a workaround, we had to deploy IP masquerading for the pod network.

2. Use $1000+ Free Cloud Credits to Deploy Clusters

Deploying big clusters on the cloud could be expensive. So make use of the following cloud credits and learn to launch clusters as if you would on a real-time project. All platforms offer managed k8s services.

1. GKE (Google Cloud — $300 free credits)
2. EKS (AWS — $300 free POC credits)
3. DO Kubernetes (Digital Ocean — $200 free credits)
4. Linode Kubernetes Engine (Linode Cloud — $100 Free credits)
5. Vultr Kubernetes Engine (Vultr Cloud — $250 Free Credits)

Use one account at a time. Once the credits have expired. move to the next account. You need to keep a watch on your credits as well as expiry. Or else you could get charged. Also, check the terms and instance usage limits if any.

Also, setting up servers on this platform is very easy and every cloud provider has extensive documentation to get started.

3. Learn to Setup Kubernetes Cluster

As DevOps engineers, it is very important to learn every component and cluster configuration. While there are many options to deploy a Kubernetes cluster, It is always better to learn to deploy multi-node clusters from scratch.

With multi-node clusters, you can learn about all the concepts like Cluster security, High Availability, Scaling, Networking, etc.

It gives you the feeling of working on a real-world project. It will also help you in interviews and you can be confident about production-level cluster configurations.

Following are my cluster setup suggestions.

1. Kubernetes the Hard Way: I would suggest you start with Kubernetes the hard way set up. It helps you understand all the configurations involved in bootstrapping a kubernetes cluster. If you want to work on production clusters, this lab will help you a lot. The setup is based on google cloud. You can use the $300 free credits to complete the lab.
2. Kubeadm Cluster Setup: Learning kubeadm cluster setup helps you in Kubernetes certification preparation. Also, it helps you automate Kubernetes cluster setup with best practices.
3. Minikube: If you want to have a minimal development cluster setup, minikube is the best option.
4. Kind: Kind is another local development Kubernetes cluster setup.
5. Vagrant Automated Kubernetes: If you prefer to have a multi-VM-based local Kubernetes cluster setup, you can try the automated vagrant setup that uses Kubeadm to bootstrap the cluster.

4. Learn About Cluster Configurations

Once you have a working cluster, you should learn about the key cluster configurations. This knowledge will be particularly helpful when working in a self-hosted Kubernetes setup.

Even if you use a managed Kubernetes cluster for your project, there may be certain cluster configurations that you need to modify.

For example, if you set up a cluster in a hybrid network, you may need to configure it with an on-premises private DNS server for private DNS resolution. This can be done via CoreDNS configuration.

Refer to the Kubernetes Cluster configurations guide for more details.

Also, having a solid understanding of cluster configurations will help you with Kubernetes certifications (CKA & CKS) where you need to troubleshoot cluster misconfiguration and issues.

5. Understand Kubeconfig File

Kubeconfig file is a YAML file that contains all the cluster information and credentials to connect to the cluster.

As a Devops Engineer, You should learn to connect to kubernetes clusters in different ways using the Kubeconfig file. Because you will be responsible for setting up cluster authentication for CI/CD systems, providing cluster access to developers, etc.

So spend some time, understanding the Kubeconfig file structure and associated parameters.

Check out the complete Kubeconfig file guide to learn everything about the Kubeconfig file.

6. Understand Kubernetes Objects And Resources

You will quite often come across the names “ Kubernetes Object” and “ Kubernetes Resource “

First, you need to Understand the difference between an object and a resource in kubernetes.

To put it simply, anything a user creates and persists in Kubernetes is an object. For example, a namespace, pod, Deployment configmap, Secret, etc.

Before creating an object, you represent it in a YAML or JSON format. It is called an Object Specification (Spec). You declare the desired state of the object on the Object Spec. Once the object is created, you can retrieve its details from the Kubernetes API using Kubectl or client libraries.

As we discussed earlier in the prerequisite section, everything in Kubernetes is an API. To create different object types, there are API endpoints provided by the Kubernetes API server. Those object-specific api-endpoints are called resources. For example, an endpoint to create a pod is called a pod resource.

So when you try to create a Kubernetes Object using Kubectl, it converts the YAML spec to JSON format and sends it to the Pod resource (Pod API endpoint).

You can refer to the Kubernetes objects vs resource guide for more details.

7. Learn About Pod & Associated Resources

Once you have an understanding of Kubernetes Objects and resources, you can start with a native Kubernetes object called Pod. A pod is a basic building block of Kubernetes.

You should learn all the Pod concepts and their associated objects like Service, Ingress, Persistent Volume, Configmap, and Secret. Once you know everything about a pod, it is very easy to learn other pod-dependent objects like deployments, Daemonset, etc.

First, learn about the Pod Resource Definition (YAML). A typical Pod YAML contains the following high-level constructs.

Once you have a basic understanding of the above, move on to hands-on learning. These concepts will make more sense when you do hands-on.

Following are the hands-on tasks to learn about Pod and its associated objects.

1. Deploy a pod
2. Deploy pod on the specific worker node
3. Add service to pod
4. Expose the pod Service using Nodeport
5. Expose the Pod Service using Ingress
6. Setup Pod resources & limits
7. Setup Pod with startup, liveness, and readiness probes.
8. Add Persistent Volume to the pod.
9. Attach configmap to pod
10. Add Secret to pod
11. multi-container pods (sidecar container pattern)
12. Init containers
13. Ephemeral containers
14. Static Pods
15. Learn to troubleshoot Pods

Few advanced pod scheduling concepts.

1. Pod Preemption & Priority
2. Pod Disruption Budget
3. Pod Placement Using a Node Selector
4. Pod Affinity and Anti-affinity

8. Learn Pod Dependent Objects

Now that you have a better understanding of Pod and independent kubernetes resources, you can start learning about objects that are dependent on the pod object. While learning this, you will come across concepts like HPA (Horizontal Pod Autoscaling) and VPA (Verification Pod Autoscaling)

9. Learn Ingress & Ingress Controllers

To expose applications to the outside world or end users, kubernetes has a native object called ingress.

Many engineers get confused with Ingress due to less knowledge of Ingress controllers. Ensure you go through the concept of Ingress and Ingress controllers and understand it correctly. Because it is the base of exposing applications to the outside world.

You can start with the following comprehensive guides.

1. Kubernetes Ingress Explained
2. Setting up Nginx Ingress Controller

Also, learn about the Kubernetes Gateway API. it provides advanced features over Ingress.

10. Learn End to End Microservices Application Deployment on Kubernetes

Once you understand the basics of these objects, you can try deploying an end-to-end microservices application on Kubernetes. Start with simple use cases and gradually increase complexity.

I would suggest you get a domain name and try setting up a microservice application from scratch and host it on your domain.

You don’t need to develop an application for this. Choose any open-source microservice-based application and deploy it. My suggestion is to choose the open-source pet clinic microservice application based on spring boot.

Following are the high-level tasks.

1. Build Docker images for all the services. Ensure you optimize the Dockerfile to reduce the Docker Image size.
2. Create manifests for all the services. (Deployment, Statefulset, Services, Configmaps, Secrets, etc)
3. Expose the front end with service type ClusterIp
4. Deploy Nginx Ingress controller and expose it with service type Loadbalancer
5. Map the loadbalancer IP to the domain name.
6. Create an ingress object with a DNS name with the backend as a front-end service name.
7. Validate the application.

11. Learn About Securing Kubernetes Cluster

Security is a key aspect of Kubernetes. There are many ways to implement security best practices in Kubernetes starting from building a secure container image.

Following the native ways of implementing security in kubernetes.

1. Service account
2. Pod Security Context
3. Seccomp & AppArmor
4. Role Based Access Control (RBAC)
5. Attribute-based access control (ABAC)
6. Network Policies

The following are the open-source tools you need to look at.

12. Learn About Kubernetes Configuration Management Tools

Now that you have a good understanding of all Kubernetes objects and deploying applications on Kubernetes, you can start learning about Kubernetes configuration management tools.

When you start working on a real-time project in an organization, you will see the usage of configuration management tools to deploy applications on Kubernetes.

Because in organizations, there are different environments like dev, stage, pre-prod, and production. You cannot create individual YAML files for each environment and manage them manually. So you need a system to manage Kubernetes YAML configurations effectively.

Following are the popular and widely adopted Kubernetes tools to manage YAML.

13. Learn About Kubernetes Operator Pattern

Kubernetes Operators is an advanced concept.

To understand operators, first, you need to learn the following Kubernetes concepts.

1. Custom resource definitions
2. Admission controllers
3. Validating & Mutating Webhooks

To get started with operators, you can try setting the following operators on Kubernetes.

1. Prometheus Operator
2. MySQL Operator

If you are a Go developer or you want to learn to extend/customize kubernetes, I would suggest you create your own operator using Golang.

14. Learn Kubernetes Best Practices

Following are the resources that might help and add value to the Kubernetes learning process in terms of best practices.

1. 12 Factor Apps: It is a methodology that talks about how to code, deploy and maintain modern microservices-based applications. Since Kubernetes is a cloud-native microservices platform, it is a must-know concept for DevOps engineers. So when you work on a real-time kubernetes project, you can implement these 12-factor principles.
2. Kubernetes Failure Stories: Kubernetes failure stories is a website that has a list of articles that talk about failures in Kubernetes implementation. If you read those stories, you can avoid those mistakes in your kubernetes implementation.
3. Case Studies From Organizations: Spend time on use cases published by organizations on Kubernetes usage and scaling. You can learn a lot from them. Following are some of the case studies that are worth reading.
4. Scheduling 300,000 Kubernetes Pods in Production Daily
5. Scaling Kubernetes to 7,500 Nodes

15. The Best Resources to Learn Kubernetes Online

Following are the list of the best online resource to learn Kubernetes practically.

1. The official Kubernetes Basics Tutorial

The official Kubernetes website has browser-based hands-on kubernetes basic tutorials powered by Katacoda scenarios. It covers the following.

1. Kubernetes basics
2. Kubernetes configurations
3. Stateless Application deployment
4. Stateful application deployment
5. Kubernetes services
6. Kubernetes Security

You can also look at official Kubernetes tasks to learn to implement Kubernetes concepts practically. It will also help you prepare for Kubernetes certifications.

2. DevOpsCube Kubernetes Tutorials

DevOpsCube has 35+ comprehensive Kubernetes hands-on tutorials for beginners to advanced users. You will learn everything from Kubernetes architecture, Cluster setup, Deployments, best practices, package management, secret management, monitoring, logging, etc.

3. KillerCoda Interactive Tutorials

If you want to learn Kubernetes from the comfort of your browser, Killercoda is a great option. It offers scenario-based learning playgrounds on the browser.

Kubernetes Learning GitHub Repository

The full Kubernetes learning guide is added to the Kubernetes learning path GitHub repo with links to all the free useful resources.

This repo is maintained and contributed by community members and it has the following.

What is the Best Way to Learn Kubernetes?

Let’s have a look at some of the best ways to learn Kubernetes.

You could fall under any of the following categories.

1. Self Learning: If you are a self-learner, you could start with the roadmap and for each topic do further research and learn from blogs, official documentation, free youtube tutorials, and Kubecon Videos.
2. Guided Learning (Text): If you like reading guided materials, the best place to learn kubernetes is to start with a beginner’s kubernetes book. My suggestion would be “Kubernetes Up and Running” followed by Kubernetes in Action. You could also try educative Kubernetes Course.
3. Guided Learning (Videos): If you want to learn Kubernetes by watching guided Video courses, you could start with Udemy, Pluralsight, or KodeKloud Kubernetes courses.
4. Signup For Certification: Another way to learn Kubernetes is to prepare for Kubernetes certification. This way, you not only learn Kubernetes but also have a certification to boost your career. If you choose this path, it’s important not to use exam dumps. Instead, learn all the concepts properly and take the exam. You could save money on certification using the Kubernetes Certification coupon.

Real-World Kubernetes Case Studies

When I spoke to the DevOps community, I found that a common issue was the lack of real-world experience with Kubernetes. If you don’t have an active Kubernetes project in your organization, you can refer to case studies and learning materials published by organizations that use Kubernetes. This will also help you in Kubernetes interviews.

Here are some good real-world Kubernetes case studies that can enhance your Kubernetes knowledge:

1. List of Kubernetes User Case StudiesOfficial Case Studies
2. How OpenAI Scaled Kubernetes to 7,500 NodesBlog
3. Testing 500 Pods Per NodeBlog
4. Dynamic Kubernetes Cluster Scaling at AirbnbBlog
5. Scaling 100 to 10,000 pods on Amazon EKSBlog

Conclusion

In this learning path to learn Kubernetes, I have covered all the important concepts you need to learn to master Kubernetes. I will keep adding new features when the new Kubernetes versions get released.

Also, learning a new technical skill takes hours of practice. You’ll certainly gain a good understanding of Kubernetes in the learning process, but the truth is that you never stop learning.

I started my Kubernetes journey in 2014 and I learn new concepts and functionalities all the time.

How To Learn Kubernetes (Complete Roadmap & Resources) was originally published in DevOpsCube on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kubernetes is growing in popularity day by day. A survey conducted by Cloud Native Computing Foundation (CNCF) reported that 96% of the respondents are either using or evaluating Kubernetes.

Engineers getting certified on Kubernetes are also growing at a rapid pace. A report by Kube careers shows that Kubernetes Certifications stand in second place in the list of popular certifications.

Now you know why getting certified in Kubernetes is very important. I will be running through each certification, plus an explanation on what purpose each certification is best suited to — everything you need to choose the best Kubernetes certification for your needs.

Also, CNCF certifications under The Linux Foundation are widely accepted and considered by organizations. However, sometimes, certification is about learning and gaining experience. As long as learning is your objective, you can choose to prepare for certifications that add value to your career. So I will also cover certifications that are not part of CNCF but will help you enhance your skill related to Kubernetes.

Table of Contents show

🚀 Important Note: You can save 35% on Kubernetes certifications and upto $237 on CKA + CKS Bundle. Check Linux Foundation Coupon for latest offers.

What are the Best Kubernetes Certifications?

1. Certified Kubernetes Administrator (CKA)

CKA is my #1 choice for Kubernetes certification.

CKA certification is a sought-after certification when it comes to DevOps Engineer Jobs. Whether you are an experienced IT professional or a fresh college graduate, CKA certification will add value to your resume. It is mainly due to the nature of the exam. Also, it is one of the best devops certifications today.

Unlike other certifications where exams have multiple-choice questions, CKA is a hands-on certification exam where you need to solve Kubernetes tasks and solve cluster issues from the command line. This certification is aimed at sysadmins and DevOps engineers who are involved with day-to-day Kubernetes operations.

The Certified Kubernetes Administrator (CKA) program provides assurance that CKAs have the skills, knowledge, and competency to perform the responsibilities of Kubernetes administrators.

training.linuxfoundation.org

The CKA exam focuses on the following domain and competencies.

1. Storage
2. Troubleshooting
3. Workloads & Scheduling
4. Cluster Architecture, Installation & Configuration
5. Services & Networking

Check out the CKA Study Guide where I have given the detailed CKA exam resources and links to Kubernetes official documentation.

2. Certified Kubernetes Application Developer (CKAD)

I recommend CKAD certification for all developers & engineers who focus more on cloud-native microservices application development & deployment.

CKAD certification focuses more on the application aspects of Kubernetes. If you are a developer or a Devops engineer who wants to showcase your ability to deploy applications on Kubernetes with cloud-native best practices, CKAD certification is for you.

The Certified Kubernetes Application Developer (CKAD) exam certifies that candidates can design, build and deploy cloud-native applications for Kubernetes.

training.linuxfoundation.org

It is also a performance-based hands-on exam where you need to solve Kubernetes tasks related to cloud-native application deployment on Kubernetes. CKAD covers the following Domains & Competencies

1. Application Design and Build
2. Application Deployment
3. Application Observability and Maintenance
4. Application Environment, Configuration, and Security
5. Services and Networking

Check out the comprehensive CKAD Study Guide where I have given the detailed CKAD exam resources and links to Kubernetes official documentation.

3. Certified Kubernetes Security Specialist (CKS)

CKS exam is recommended for engineers involved in cloud-native security.

CKS certification focuses more on Kubernetes security. When it comes to containerized environments, security plays a key role. From building a container image to deploying it on kubernetes, security best practices have to be applied to reduce the attack surface. This certification covers the security aspects from building images to deployment. You have to learn container security best practices and associate cncf security tooling such as Falco and Trivy to prepare for this exam.

The Certified Kubernetes Security Specialist (CKS) program provides assurance that a CKS has the skills, knowledge, and competence on a broad range of best practices for securing container-based applications and Kubernetes platforms during build, deployment and runtime. CKA certification is required to sit for this exam.

training.linuxfoundation.org

To appear for the CKS exam, you need to pass the CKA certification first. CKS exam covers the following domains and competencies.

1. Cluster Setup
2. Cluster Hardening
3. System Hardening
4. Minimize Microservice Vulnerabilities
5. Supply Chain Security
6. Monitoring, Logging, and Runtime Security

Check out the comprehensive CKS Study Guide where I have given the detailed CKS exam resources, links to Kubernetes official documentation, and links to associate cncf security tools mentioned in the CKS curriculum

4. Kubernetes and Cloud Native Associate (KCNA)

KCNA is recommended for students, IT managers, and engineers who need foundational knowledge of the cloud-native ecosystem.

KCNA exam focuses on Kubernetes and related tools in the cloud-native landscape. This exam is easy compared to CKA, CKAD, and CKS. It is a multiple-choice exam with 60 questions and a 90 minutes exam time.

The Kubernetes and Cloud Native Associate (KCNA) exam demonstrates a user’s foundational knowledge and skills in Kubernetes and the wider cloud native ecosystem.

training.linuxfoundation.org

The topics covered on the KCNA exam include:

1. Introduction to Kubernetes (10 questions)
2. Kubernetes Architecture and Components (20 questions)
3. Kubernetes Networking (15 questions)
4. Kubernetes Storage (15 questions)
5. Kubernetes Security (10 questions)
6. Kubernetes Monitoring and Logging (10 questions)
7. Cloud-Native Application Development (10 questions)
8. Container Orchestration with Kubernetes (5 questions)

The passing score for the KCNA exam is 65%.

Tips for preparing for and taking the KCNA exam:

1. Make sure you are familiar with the topics covered on the exam. You can find a list of topics in the Exam Topics section below.
2. Read through the Exam Guide and familiarize yourself with the structure of the exam.
3. Use practice exams to test your knowledge and identify areas where you need to focus your studies.
4. When taking the exam, take your time and read each question carefully before selecting your answer.
5. If you are unsure about an answer, eliminate the obviously incorrect answers and make your best guess.

How to Register for Kubernetes Certification?

You can register for the certification exam on the Linux Foundation training Portal.

Step 1: Head over to the Cloud & Containers Category

Step 2: Choose a certification of your choice and click the “Enroll Today” Button. If you want to choose a bundle, select the “Buy Bundle” option as highlighted in the image below. With bundles, you can save an extra $100.

Step 3: On the checkout page, you will get an option to apply a coupon code. Use code DCUBEOFFER to save 15%.

To get the latest Kubernetes promotion updates, check out the Kubernetes certification coupon page. You could save up to 50% during exclusive Linux Foundation sales.

Which is the Popular Kubernetes Certification?

The popular Kubernetes certification is CKA as it covers the administrative aspects of Kubernetes clusters.

An interesting Kubernetes job trend shows that CKA represented 54% of the mentioned certifications. And in terms of popularity, the ranking goes like CKA > CKAD > CKS.

As a CKA certified engineer myself, I can say that you should opt for CKA if you are planning to work on Kubernetes cluster administration and deployment. However, if you are just focused on deploying apps on Kubernetes, CKAD is preferable.

CKS certification is popular in the security domain. If you are someone involved in DevSecOps or someone interested in cloud-native security, CKS is definitely worth going for.

Kubernetes Certified Engineers Salary Stats

Let’s look at some of the salary stats for candidates with Kubernetes skills.

According to Payscale, the average salary for candidates with Kubernetes skills is $117k/ year.

Talent.com data shows a $150000/year average salary based on 728 salaries. In that highest salary is $180000/year.

As per kube.careers Kubernetes job trends report data, the salary range is between $123,126 & $166,505. And the highest salary reported is between $200,000–240,000.

Linkedin search returned 124,565 results for Kubernetes jobs in the USA. In that for salaries more than $10000, it’s returned 28000 results. And for salaries above $200000, it returned 302 results.

Glassdoor shows the highest reported salary $69,655 per year.

Kubernetes Certification FAQs

Is the CKA certification worth it?

Yes. The Linux Foundation CKA is a sought-after Kubernetes certification. CKA is a widely accepted certification that showcases a candidate’s Kubernetes administration and management skills. You will also gain a competitive advantage over peers without the certification as recruiters and organizations are looking for certified professionals.

What is the Certified Kubernetes Administrator Salary?

As of 2022, data from popular job sites like indeed and talent.com shows that the average salary for CKA certified engineers ranges anywhere between $130,000 and $180,000/year.

What are the latest Kubernetes Certification Voucher codes?

The latest Kubernetes certification voucher codes are DEVOPS35 where you get a flat 35% discount on CKA, CKAD, CKS, and KCNA certification & bundles.

Which Kubernetes Certification is good for entry-level engineers?

If you are an entry-level DevOps engineer, a Certified Kubernetes Administrator (CKA) is the best option as it covers mostly administrative aspects of Kubernetes. It helps you gain core Kubernetes skills that are required for a DevOps engineer Job.

Which Kubernetes Certification is good for developers?

For developers, the recommended Kubernetes certification is Certified Kubernetes Application Developer (CKAD) as it covers concepts related to cloud-native Kubernetes development.

Which Kubernetes certification is best for Devops engineers?

CKA is the best certification for DevOps engineers as it focuses more on Kubernetes administrative aspects.

Conclusion

In this blog, I have covered the best Kubernetes certifications to showcase your Kubernetes skills. However, you will need to look at your current skill set and choose a certification that aligns with your career goals and aspiration.

For example, if you are more interested in the DevSecOps path, CKA+CKS is the best choice. If you are in the DevOps engineer path, CKA is the best option. If you are getting started with cloud-native tools, KCNA is the best entry-level certification.

Also, if you are learning Kubernetes, check out the list of comprehensive kubernetes tutorials with practical examples.

Best Kubernetes Certifications was originally published in DevOpsCube on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blue-Green Deployment

Blue Green is a deployment pattern that reduces downtime by running two identical production environment called blue and green. Only one environment lives at a time.

We need to ensure about the changes. Changes must be forward and backward compatible. We need to setup a parallel infrastructure i.e. same number of servers and services used in the actual infrastructure. Post the setup deploy the new version to the new infrastructure, do the sanity and validate everything. Then switch all the traffic to the green infrastructure. After everything is validated, remove or stop the old infrastructure (blue).

Pros of Blue-Green Deployment

• Rollbacks are superfast and simple, rollbacks to the previous change are just a route change.
• Downtime during deployments is minimized, with no period where no request could be served.
• Deployments are quick, just a flip of a switch.
• Disaster recovery plan is super simple.
• Deployments can happen in regular hours.
• We can debug why a release failed.

Challenges in Blue-Green Deployment

• During deployments, the infra cost would be double.
• Stateful applications would face problems. The information stored on instances like cached files, and artifacts will be lost when we switch from blue to green, everything would need to be rebuilt.
• Database migrations are tough.
• Frontend and Backend compatibility for APIs.
• Blue Green Setup takes effort and time.

Canary Deployment

Canary deployment is a pattern that allows us to roll out code, features, and changes to an initial subset of users/servers. Basically, the change is deployed to a small subset of servers, then tested and rolled out to the rest of the servers. If everything is good then only roll out to all the servers otherwise rollback it. So canary deployment act as an early warning indicator so that we could avoid a massive outage.

We create a small parallel Infra. We need to deploy the new version to one server and then monitor the vitals, cpu ram, error rates, and all. Test all the changes. If everything is working as expected then deploy this to the remaining servers as well.

In canary deployment, the selection criteria of new version traffic can be different i.e geographical-based, random users, beta users, internal employees, etc. Canary deployment is very helpful when you re-wrote your service.

Pros of Canary Deployment

• It allows us to test the changes in prod with actual users.
• Rollbacks are much faster because we deployed on few servers.
• If the newly deployed version of code has bugs it would affect a very limited set of requests.
• Zero downtime deployments.
• We could deploy even when we are unsure about the new release.

Challenges in Canary Deployment

• Engineers will be habituated to test in prod directly which is not a recommendable practice.
• Architecting a canary deployment is complex.
• Parallel monitoring setup observability is super important in canary setup side-by-side comparison of vitals, cpu ram, response times, error rates, exceptions, etc.

That’s all about Blue-Green and Canary Deployments. Read more in-depth and choose which type of deployment you can use according to your project’s requirements.

Blue-Green vs Canary Deployment was originally published in DevOpsCube on Medium, where people are continuing the conversation by highlighting and responding to this story.

Scaling is reactive and manual in a traditional data center. In the reactive scaling method, we manually brought up and down the servers as per the changes in application workload or traffic. We increase and decrease the servers according to the workload. Suppose the traffic is increasing, hence we will need to add 2–3 more servers to handle the traffic and address the user requests. But this is a time taking process and not sustainable as this is dependent on different factors for example availability of the servers, cost approval, and availability of admins. Also if the traffic goes down we have to remove the extra added servers, otherwise, it will run idle and increase the cost.
Cloud Computing solves all these problems as it’s very easy to add and remove extra resources based on the traffic. We use autoscaling for the same.

What is autoscaling?

Autoscaling is a feature of cloud computing that automatically increases and decreases the compute resources, memory and networking resources as per actual uses and demand. Autoscaling provides flexibility and elasticity to compute demand. It also enables consistent application performance at a low cost.

Let’s talk about autoscaling in AWS.

AWS Autoscaling

AWS Autoscaling is a service that monitors your application and automatically adjusts the capacity to maintain steady, predictable application performance at the lowest cost. It uses cloudwatch to monitor the application demand and raise alarms to scale up and down the resources.

Benefits of AWS Autoscaling

Below are the benefits of AWS AutoScaling:

• Better Fault Tolerance
• High Availability of the resources
• Flexibility and Elasticity
• Only pay for what you use, better cost management
• High Reliability of the resources
• Automatically maintain performance

Types of Scaling Plan

There are different types of plans we can look for:

Manual Scaling -> It helps in managing the task of building or terminating the instances on its own.

Schedule Based -> Based on traffic, we can schedule the time for executing the AWS Autoscaling.

Demand Based -> Based on client demand, we can define required scaling.

Current Instance-Level Based -> We can configure an Autoscaling group for managing running instances.

Let’s see what the Autoscaling group is.

AWS EC2 Autoscaling Group

The Autoscaling group is a collection of Amazon EC2 instances grouped logically for automatic scaling and management. The Autoscaling group also enables us to use EC2 Autoscaling features such as health check replacements and scaling policies.

There are 3 major parameters:

Minimum Size, Desired Capacity, Maximum Size

Minimum Size -> It ensures that we always have a fixed number of instances running. The minimum number of instances should be enough to meet the base application load, but not have too much unused capacity.

Desired Capacity -> This is the number that notates how many instances we want to run ideally. Autoscaling group try to maintain this capacity

Maximum Size -> It notates the max number of instances running in the autoscaling group. Autoscaling group never creates the instances more than the maximum size.

These parameter values will determine the cost of running the cluster.

This was all about Autoscaling. We can scale EC2 instances, ECS, RDS, DynamoDB etc. Read more in-depth about it and how to create and configure an autoscaling group.

Reference: “Cloud Computing With AWS” by Pravin Mishra on Udemy

Auto Scaling in AWS was originally published in DevOpsCube on Medium, where people are continuing the conversation by highlighting and responding to this story.

At my work it manifests itself that our future lies with docker containers. As a matter of fact even more confusing terms are being used. They talk about ‘CRC’ aka ‘Code Ready Containers’, Kubernetes clusters and other things that make my head spin so violently that I have to hold onto my chair, else I would topple over.

In case it is not clear already, I am not in the slightest familiar with these technologies. But this is no reason to fret! It is my believe that the IT sector means constant learning and so I welcome this step towards ‘modern’ tools. (In an industry that is evolving as quickly as it does one should always be careful when using the word modern.)
Especially, since my company has a tendency to lack behind — significantly — when it comes to technology.

So I started to look into Docker containers and first tried to answer the question:

“What are they and why should I care”.

Let’s have a look at the bigger picture by looking at where we are coming from.

The simple beginnings

In the past things were much simpler. Every server had exactly one operating system installed. Let it be a version of Windows (Server) or a flavor of Linux. Everything would be controlled by one OS.

This simplicity would come with a lack of flexibility. What if you have Linux installed but need Windows for an application or vice versa? What if you need more computational power or less? Would you want to invest in new hardware and have to maintain it in that case?

The issues do not stop there. On application level there are further issues when you have just one big server. What if you have conflicting dependencies between the software you use? Maybe your WordPress and your data base cannot come to terms about drivers they need.

Divide and conquer

And with that, the stage opens for virtual machines. They use something called a hypervisor to divide a computers resource for multiple guest operating systems. They come in two different flavors. Either they function as a lightweight operating system and run directly on the hardware or they run on a host operating system.

All of a sudden, you are able to quickly react to changing needs. You can create a new virtual machine on your existing hardware that runs Windows Server or Linux. If one machine needs more power, you can simply assign more resources (if available), no need to get new hardware.

In a sense, Virtual Machines are virtualizing hardware.

One step back and a giant leap forward

Docker now goes one step further … or maybe back. You no longer need a hypervisor.
Instead a single operating system on your hardware suffices. Because what docker is doing is to virtualize the operating system instead of the hardware.

The docker engine runs on the host operating system and hosts itself so called docker “containers”. Which could be described as isolated micro computers. They can have their own CPU, OS, Memory and Network.

Why care?

Their strongest selling point is that they are lightweight. Once you have the Docker engine installed you for example pull the docker image for Ubuntu — which is currently only 77mb in size — and you have it running within seconds.

Installing Ubuntu on a virtual machine takes magnitudes longer.

But how is that even possible?

The secret is that Linux based docker containers share their Kernel with the host operating system. This brings one big drawback with it and that is that a Linux OS can only host Linux docker container whereas a Windows host can only run Windows docker container. (Not taking into account that you could use Windows Subsystems for Linux).

The biggest advantage is yet to come. Technically I have already mentioned it, but I want to emphasize it …strongly! They are isolated and therefore highly portable.

A scene like the following happens every day around the globe and is with a high probability also familiar to you:

Developer: Finally I am done with this feature. All tests are green. Time to give it up for review.

other Developer / Tester tries to run the code and it fails

Developer: Don’t know the problem. IT RUNS ON MY MACHINE.

Who knows how much money / time is lost because of differing runtime environments. May it be the environment variable that you have changed months ago or this one dependency that you forgot to document. Maybe you run a different version of insert about anything or who knows what might be the reason.

This will be a thing of the past. Because everything you need for a script to run must be part of a docker image. When it runs on your machine, it will run on every other machine. Because all dependencies and all those little tweaks must be part of the docker image.

Quick break to explain terminology: an image is the abstract definition of the environment and
every instance of this image is called a docker container. Cool? Cool!

You wanna know what else is neat? It’s this thing about isolation. You can have different parts of your server run in their own docker container and have those containers communicate with one another. Each having their needed dependencies in the version they need.

One component needs an update either for itself or a dependency? No problem. Your other components will not be affected. They might not even notice anything being different.

Conclusion

It’s time to wrap this up. This article was only intended to be a brief introduction into the topic of docker and as such can only be seen as a starting point.

Most information stem from this NetworkChuck video.

Check it out if you want to see some Docker containers in action.

In case you jumped right to the end in order to find out why you should care. Here are the 3 main reasons I see:

Docker containers are

• lightweight
• isolated
• highly portable

What is docker and why should you care? was originally published in DevOpsCube on Medium, where people are continuing the conversation by highlighting and responding to this story.

Docker networking is primarily used to establish communication between Docker containers and the outside world. Docker supports different types of networks. In this article, I’ll talk about docker network containers and drivers.

When we install Docker, it created three networks automatically.

Bridge
None
Host

If we will run below command it will give us the list of all networks.

docker network ls

We can also get the details of each network by running below command:

docker network inspect <network-name>

Let’s talk about these one by one.

Bridge:

Bridge is the default network a container gets attached to. It is a private internal network created by Docker on the host. Eah container connecting to this network get their own internal private network address. Generally IPs get assigned in the range of 172.17.x.x to the containers. The containers can access each other using the internal IP. If we want to access any of these containers from the outside world, then we need to map the ports of these containers to ports on the Docker host. The another name of Bridge network is docker0 as it’s the default one.

None:

With a none network the docker container is not attached to any other network. The container can not reach to the outside world and no one from the outside world can access the container. We can use it when we want to disable the networking on a container.

Host:

If we want to access the containers externally, then we can attach the container to Host network. There is no network isolation between the host and the container. That means like bridge network we don’t need to any additional port mapping. For example, If we deploy a web app which is listening on port 80 , then it will be accessible on port 80 on the host. But we will now not be able to run multiple web containers on the same host and the same port. If we try to run another instance of our web app that listens on the same port, it won’t work as they share the host networking and two processes can’t listen on the same port at the same time.

Attaching Container:

Now what if we want to attach the container with any other network, not the default on. We can use below command to attach any different network. (host in our case for example)

docker run ubuntu --network=host

User Defined Custom Network:

We can also create our own internal network, where we can give the docker drivers and subnet for the custom network.

docker network create --driver <driver-name> --subnet <subnet> <network-name>

Common Networking Commands:

Let’s see some useful commands related with docker networks.

If we want to see the network setting and the IP address assigned to an existing container, we can use below command. (can use container name as well instead of id)

docker inspect <container-id>

What if we want to attach any container to our custom network. We can use connect and disconnect command for the same.

docker network connect <custom-network-name> <container-name>

To disconnect the container:

docker network disconnect <custom-network-name> <container-name>

If we want to delete any network, we can use below command:

docker network rm <custom-network-name>

If we want to delete all unused networks, we can use below command:

docker network prune

Other Network Drivers:

We have used a parameter — driver while creating the custom networks. Docker allows us to create three different types of network drivers bridge, host, and none. However, they may not fit in every use case. There are some other drivers as well which we can use to create the custom networks according to requirements.

Some other drivers are overlay, macvlan and ipvlan.

Let’s talk about these one by one.

Overlay:

When we need the communication between containers running on different docker hosts or when multiple apps work together using swarm services, we can use overlay networks. Basically it used for multi-host network communication.

Macvlan:

Macvlan networks allow you to assign a MAC address to a container, making it appear as a physical device on your network. Macvlan networks are best for applications that need to be modernized by containerizing them and running them on the cloud. It used to connect docker containers directly to the host network interfaces through layer 2 segmentation.

IPvlan:

IPvlan networks give users total control over both IPv4 and IPv6 addressing.

Read more about each network types and how they work in details.

https://docs.docker.com/network/

This is all about network in Docker. I’ve talked about the basic details and the idea behind that, that should provide you a an overview of Docker Networks. Explore more about the networking in Docker.

Docker Networks was originally published in DevOpsCube on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you are responsible for managing Red Hat OpenShift clusters, then there is a nifty opensource project (aptly named openshift-checks) that could be a good addition to your toolkit.

The openshift-checks project is a collection of health-check scripts for an OpenShift cluster.

Take a look at the project description and related details from the following link:

GitHub - RHsyseng/openshift-checks: A collection of scripts to check the health of an OpenShift cluster

Running health checks

The easiest way is to run it as a container.

Remember to provide the path to the kubeconfig file. In the example below, the kubeconfig file is located at “$HOME/kubeconfig”

$ alias openshift-checks="podman run -it --rm -v $HOME/kubeconfig:/kubeconfig:Z -e KUBECONFIG=/kubeconfig quay.io/rhsysdeseng/openshift-checks:latest"

Take a look at available checks.

$ openshift-checks -l
Available scripts:
[..snip...]
checks/nodes
checks/notrunningpods
checks/operators
checks/ovn-pods-memory-usage
checks/pdb
checks/port-thrasing
checks/restarts
[...snip...]

Executing the command without any options will run all the checks. It’s also possible to execute specific checks.

The following example runs single info (command) check to display the cluster version.

$ openshift-checks -s info/00-clusterversion

Using system:admin context
Cluster version:
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.10.0–0.nightly-2022–03–11–203311 True False 12m Cluster version is 4.10.0–0.nightly-2022–03–11–203311
No issues found

You can also extend it by adding your own specific health checks.

Adding new health checks

Adding a new health check consists of two primary steps:

1. Clone the source tree
2. Add script to a specific folder (info, checks, etc)
3. Build a new container image (Optional)

Let’s see this in action by way of an example. We’ll be adding a simple info (command) check for Red Hat OpenShift sandboxed containers operator.

Clone the source tree.

$ git clone https://github.com/RHsyseng/openshift-checks.git
$ cd openshift-checks

Add health check script.

$ cat > info/06-sandboxed-containers <EOF

#!/usr/bin/env bash

[ -z ${UTILSFILE} ] && source $(echo “$(dirname ${0})/../utils”)

if oc auth can-i get pods -n openshift-sandboxed-containers-operator >/dev/null 2>&1; then
 msg “Sandboxed containers operator:\n$(oc get pods -n openshift-sandboxed-containers-operator)”
 exit ${OCINFO}
else
 msg “Couldn’t get sandboxed containers operator details, check permissions”
 exit ${OCSKIP}
fi
exit ${OCUNKOWN}
EOF

Build a new container image.

$ podman build -t bpradipt/openshift-checks .

Verify

$ alias openshift-checks="podman run -it --rm -v $HOME/kubeconfig:/kubeconfig:Z -e KUBECONFIG=/kubeconfig bpradipt/openshift-checks:latest"

$ openshift-checks -l
[...snip...]
info/04-machineset
info/06-sandboxed-containers
[...snip...]

$ openshift-checks -s info/06-sandboxed-containers

Using system:admin context
Sandboxed containers operator:
NAME                                  READY   STATUS    RESTARTS         AGE
controller-manager-676fccfcff-j2trz   2/2     Running   0   14d
No issues found

There are numerous possibilities. You can use this to run a specific set of checks post-deployment to ensure the cluster is set up as per your requirements and ready to handle workloads, or you can run some periodic checks as needed.

Health Checkups for your OpenShift Cluster was originally published in DevOpsCube on Medium, where people are continuing the conversation by highlighting and responding to this story.

Docker is an open platform for developing, shipping, and running applications. Docker helps us package our software to ‘build once and run anywhere. In this blog, I’ll talk about the architecture of the Docker Engine.

Docker engine consists of three components Docker daemon, the REST API, and the Docker CLI.

The Docker daemon (dockerd) is the actual server or process that is responsible for creating and managing objects such as the images, containers, volumes, and networks on a host. It communicates with other daemons also to manage Docker services.

The REST API provides an interface to manage objects in Docker. In simple words, it instructs the Docker daemon what to do.

The Docker CLI is the command-line interface that we use to run commands to manage objects in Docker, basically the Docker Commands.

What is an Image?

An image is a read-only template with instructions for creating a Docker container. It consists of a collection of files that pack together all the necessities.

What is a Container?

Container is a runnable instance of an image. Simply, Containers are executable units of software in which application code is packaged, along with its libraries and dependencies.

When we execute a command using the Docker CLI to create a container the docker client converts the command into a RESTful API which is passed to the Docker daemon. Then Docker daemon downloads the image from Docker Registry (by default docker hub), it further makes a call to containerd. Will talk about containerd later in this article.

Docker has its own execution environment which is called libcontainer. Before that docker used Linux containers to manage containers on Linux. With libcontainer, docker talks with the Linux kernel feature eg: namespaces, and cgroups. For details about namespace and cgroup, and how they work, read the below article.

https://www.nginx.com/blog/what-are-namespaces-cgroups-how-do-they-work/

The another important components are runC, containerd and containerd-shim. runC runs the containers, actually we can run containers by installing runC without installing docker. containerd manages runC, eventually manages containers. containerd is responsible for converting the image into OCI (open container initiative) compliance bundle. It passes the bundle to containerd-shim.

What is OCI?

The Open Container Initiative(OCI) is a Linux Foundation project, started in June 2015 by Docker, to design open standards for operating-system-level virtualization (software containers), most importantly Linux containers.

Read more about it: https://opencontainers.org/

containerd-shim monitors the state of the container. Even if the Docker daemon shuts down or get restarted, the containers run in the background and is attached back when the daemon comes back up. containerd-shim calls the runC to start the container. runC then interacts with namespaces and cgroups in libcontainer to create a container. In this way a container gets created. So the exact flow will be:

What is Docker Registry?

A Docker registry stores Docker images. It can be a public docker registry or a private docker registry. Docker Hub is the default place of docker images, its stores public registry that anyone can use. We can also create and run our own private registry.

This was the high level architecture of Docker Engine. We can further read about every single keywords to get more details.

The Architecture of Docker Engine was originally published in DevOpsCube on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this blog, you will learn about important Kubernetes pod scheduling concepts such as Pod priority, Preemption, and Pod PriorityClass

What is Pod priority in Kubernetes?

Pod priority is a Kubernetes scheduling feature that allows Kubernetes to make scheduling decisions comparing other pods based on priority number. Let’s look at the following two main concepts in pod priority.

1. Pod Preemption
2. Pod Priority Class

Pod Preemption

Pod preemption feature allows Kubernetes to preempt (evict) lower priority pods from nodes when higher priority pods are in the scheduling queue and no node resources are available.

Kubernetes Pod Priority Class

To assign a pod certain priority, you need a priority class.

You can set a priority for a Pod using the PriorityClass object (non-namespaced) with a Value.

The value determines the priority. It can be 1,000,000,000 (one billion) or lower. Larger the number, the higher the priority.

The name of the priorityclass (priorityClassName) will be used in the pod specification to set the priority.

If you don’t want the priority class to preempt the pods, you can set PreemptionPolicy: Never. By default, Priorityclasss use PreemptLowerPriority policy.

Pod PriorityClass Example

The following example has a PriorityClass object and a pod that uses the PriorityClass.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority-apps
value: 1000000
preemptionPolicy: PreemptLowerPriority
globalDefault: false
description: "Mission Critical apps."
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: dev
spec:
  containers:
  - name: web
    image: nginx:latest
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority-apps

Kubernetes System High PriorityClass

How do you safeguard system-critical pods from preemption?

Well, there are two default high-priority classes set by Kubernetes

1. system-node-critical: This class has a value of 2000001000. Pods like etcd, kube-apiserver, and Controller manager use this priority class.
2. system-cluster-critical: This class has a value of 2000000000. Addon Pods like coredns, calico controller, metrics server, etc use this Priority class.

How does Kubernetes Pod Priority & Preemption work?

1. If a pod is deployed with PriorityClassName, the priority admission controller gets the priority value using the PriorityClassName value.
2. If there are many pods in the scheduling queue, the scheduler arranges the scheduling order based on priority. Meaning, the scheduler places the high priority pod ahead of low priority pods
3. Now, if there are no nodes available with resources to accommodate a higher priority pod, the preemption logic kicks in.
4. The scheduler preempts (evicts) low priority pod from a node where it can schedule the higher priority pod. The evicted pod gets a graceful default termination time of 30 seconds. If pods have terminationGracePeriodSeconds set for preStop container Lifecycle Hooks, it overrides the default 30 seconds.
5. However, if for some reason, the scheduling requirements are not met, the scheduler goes ahead with scheduling the lower priority pods.

Now we know how kubernetes pod scheduling priority work with Priorityclass and preemption.

Pod Priority FAQs

What is Kubernetes DaemonSet Priority?

Daemonset has priority like any other pods. Therefore, if you want your Daemonsets to be stable and not evicted during node resource crunch, you need to set a higher pod PriorityClass to the Daemonset.

How is Pod QoS related to Pod priority & Preemption?

Kubelet first considers the QoS class and then pod priority value to evict pods. This happens only when there is a resource shortage on the nodes.

However, preemption logic kicks in only when high-priority pods are on the scheduling queue. The scheduler ignores the pod QoS during pod preemption. Whereas a QoS-based eviction happens without a scheduling queue due to a resource crunch.

What is the significance of Pod Priority?

When you deploy apps to Kubernetes in production, there are certain apps you don’t want to get killed. For example, a metrics collector Daemonset, logging agents, payment service, etc.

To ensure the availability of mission-critical pods, you can create a hierarchy of pod tiers with priorities; when there is a resource crunch in the clusters, kubelet tries to kill the low priority pods to accommodate pods with higher PriorityClass.

Note: If you are preparing for Kubernetes certification, check out the latest CKA Coupon to get discounts.

Kubernetes Pod Priority, PriorityClass, and Preemption Explained was originally published in DevOpsCube on Medium, where people are continuing the conversation by highlighting and responding to this story.

Foreword:

After I got unique recognition and excellent personal connections developed through my 2021 DosaOps story, that elucidated the power of DevOps, often I have been motivated by different individuals to come up with another story on a popular topic.

Although few topics were on mind, I wanted to give it a time to marinate very well. Finally, after hiatus, I am here again with a personal story!!.

The Motivation:

Thanks to the ongoing Cloud disruption, and the “As a service” has become ubiquitous phrase which all of us comes across very frequently. That basically alludes to “providing a scoped product/solution as a service, to reduce the extreme management/operational burden involved in procuring, configuring and maintaining that service”.

Despite we being familiar on various Cloud service models, that are usually suffixed with “as a service”, confusion still lurks around due to the broad verity of services, the subtleties involved with each service model and wide range of considerations/choices involved in choosing a certain model.

Numerous others models came up post main service models, IaaS, SaaS & PaaS. To complement this, in my own terms, the overall Cloud can simply be attributed as “Data center as a Service”.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ready… Get set go……….the Plot Begins:

Starring:

The Great Fan(analogous to Cloud Customer):

I am very fond of Tea(Indian Chai, also known as Chai/Tea Latte internationally) as many of you might do. Tea never ceases to lure its fans due to the wide variety of flavors that can be made.

It used to be so easy for me during the days in Hyderabad, to step out to canteen/street side “chaiwala” to quickly grab a cup of tea.

Now, there is no other way except I randomly get my wife busy by requesting: “One more tea please”. Sometimes verbally, and sometimes with just looks and expressions (which she could figure), when I can’t ask out of hesitation to burden her.

😀😀😀

And, I never miss to take advantage of busy work as an excuse, that can easily fly and get me another cup!

The Genius Cook(analogous to Cloud Service Provider-CSP):

However, as excessive Tea is unhealthy, my wife initially put quota per the day. That didn’t work out well, due to variety of reasons I find to ask for an exception!!.

Needless to say that she is a passionate cook, and she has very keen attention to details in the art of cooking. Ideally she prefers to make most of the pre-requisites(for any recipe) from scratch regardless of the type/complexity. Of course it takes time, but she has that passion to make everything in an organic/healthy manner, to the extent possible.

Notedly, Tea is special and it can be made as easy and quick as boiling water and add readymade ingredients/honey, or as complex as possible as described below in Chapter1, based on the interest, time and energy.

To our surprise, she didn’t spare Tea too from her detailing & customization.😀😀

To suffice my thirst for Tea, she gave a very good thought and came up lot of formulas of Tea, that are healthy as well as tasty!!.

Chapter1:

Make Your Own

I love to start the day with Tea, it gives an energetic kick that surfaces any lethargy after my warm up activities.

Each morning and each instance, she would ask me the type & strength of Tea flavor needed.

She then patiently grinds green tea flakes & roots ,spices (ginger, cloves, cardamom, cinnamon, star anise, fennel seeds , lemon grass/leaves, black pepper…) in the stone mill , adds some additional herbs(basil etc), milk, honey /jaggery etc, boils in simmer mode to extract a signature taste.

Same steps repeats for each ask and each instance!!.

Although it is very time consuming and effort staking, it gives her full control on how it should taste and can customize (flavors, intensity of flavors, hotness/sweetness, heat level etc) based on the need.

However, I prefer to enjoy the tea during the little breaks I get but the complexity of this whole process and her busy time with kids & other home operations hesitates me in asking whenever I wanted, with all painstaking and time consuming steps involved.

Now, take a Masala Tea break please, to add a Technology flavor to it:

IaaS- Infrastructure as a Service:

IaaS solutions offer complete control to the customers. Users could do whatever configurations they wanted on the infrastructure, and could install desired software and binaries that are required by the applications.

Just like we were able to prepare our own Chai, with all needed ingredients and customizations as desired, IaaS offers complete control on what we wanted to do with our infrastructure.

However, it brings in lot of responsibility and management burden on us and also we need to spend lot of time& efforts in getting infrastructure configured/customized to suit our needs.

Chapter2:

A little Compromise- Make it as easy and quick as possible

Meanwhile she had to undergo a medical procedure and she needed rest for some period. Hence, I tried to put an end for Tea habit by rarely going for it.

However, she noticed my waning interest, and came up with an innovative idea that achieves same goal in an efficient manner with least efforts possible, while ensuring health factor.

To save time and effort with complex process, as we’d seen earlier in Chapter1, she’d ground all needed ingredients before hand and stored them in air tight containers. She did the same for different flavors.

By doing this, there is no need to prepare all ingredients from scratch, which are time taking. It’s just that she asks me the flavor needed for that instance, boils the milk and adds flavored ingredient from the respective container. Its lot quick and easier than earlier.

However, this doesn't take away rest of the effort each time. Also the level of customization is limited with reduced control on ingredients(with prepackaged flavors) and the freshness/quality of taste diminished comparatively. We got to trade off control/customization, taste & freshness with optimization of time & effort. And,  I got to go with limited flavors available, that didn't ran out.

Now, take one more break please with Cinnamon Tea, to blend this with a service model:

PaaS- Platform as a Service :

PaaS solutions offer moderate amount of control on personal preferences and we can’t access/control base infrastructure settings. However, we could choose specific type of platform (.Net, Python, PHP…) and select amount of resources needed to run our applications.

The biggest advantage is infrastructure management burden will be reduced significantly, and we don’t need to deal with all OS level configurations/software installations, we can spin up PaaS services whenever we want by uploading our code and within short intervals. This gives greater times to market when compared with IaaS solutions.

With pre-configured platform, we could run applications with less effort/burden . (like tea made quickly out of readily available customized tea flavors). However, it will be hard/impossible to inject any custom configurations/libraries that may be required by our applications and have to just use available platforms(like using only the tea flavors that are available, which didn’t ran out).

Chapter3: The Vacation- and the new Idea!!

Ultimately, my family had to go on vacation and I was all alone. Although I am alright at cooking(at-least with Tea) she knew it will not be easy for me with busy schedules and hence she prepared different flavors of Tea in bulk quantities and neatly packed.

To beat my busy schedules & to further optimize time & effort in meeting OnDemand needs, I started to choose a flavor needed, prepare the needed quantity for the day(3–4 cups) early in the morning , put it in a heat holding flask and place at my desk.

With this, there is hardly anytime to spend in making tea for each instance, full contrast to whats described in Chapter1 and significant change with timed efforts required still in Chapter2.

Its super fast and quick and I can fill the cup OnDemand- right at the moment I needed!!

However, it is only one type of flavor I will get for the whole day and there’s no way to customize it, beyond prepackaged/available/prepared flavor for that day. The saved effort/time, convenience and quickness negated the dynamic preferences/control/customizations, and also it begs little compromise with taste/quality/heat.

Now, One last break with Ginger Tea, to see it through the Technology lens:

SaaS- Software as a Service :

SaaS solutions are software products that are readily available, that may fit our business models/requirements. CSPs offer variety of products , together with their partners. We could launch any available software on-demand.

The biggest advantage with it is rapid times to market and lowest development/management burden when compared with IaaS/PaaS. Like, I could fill my cup whenever I wanted from the flask.

However, this has key tradeoffs. We could not make low-level/custom configurations per our desires, and cannot make choices on hardware/OS and access control on platform level. We can quickly consume whatever SaaS product that is offered by the vendor. Just like the only flavor I get per day but quickly OnDemand, at the expense of quality/taste/customization/control.

As an exception, worth noting this, some SaaS products may offer a bit of customizations. It totally depends on SaaS Product/Vendor.

Chapter4: A special Guest

Once I ran out of flavors that she made, and to take out all the manual efforts for her once she returns, I bought a coffee maker.

The good part about it is we get variety of pods, with different flavors. We could simply put the pod/flavor we wanted, and fill the cup. Damn easy!!

But its all pre-made, we have to go with whatever the pods pre-packaged by the producer. Least customizability, broad varieties and extreme convenience.

Family returned meanwhile and she gave me a surprise!!.

I had to return that coffeemaker before even unpacking, as I bought it silently without my home department’s approval, before its denied as unhealthy option. Just quoting this to help the context. 😀

We got to an agreement finally; with simplistic, healthy and optimal plan as in Chapter2.

The Final Break please, with special Matcha Green Tea Latte

CaaS- Container as a Service:

Containers are prepackaged IT infrastructure environment that is required to run an application. All the Libraries, Configuration files and OS Dependencies are packaged as container images (like Pods of coffee maker) and can be deployed as containers, within moments. Containers offer broader level of technologies/platforms that may not be possible with PaaS.

Just like putting the Coffee pod we want, hit start button and get the coffee, we can deploy respective container and see the running applications!!.

One of the best advantages of it is abstraction of all OS level/binary/library level nuances, technology/platform varieties and rapid scale of deployment with high amount of scalability and agility. However, container orchestration and management are the things that need special consideration.

Closing Comments:

One of the key factors that need to be considered is Shared Responsibility Model (Google brought up Shared Fate Model) , where the responsibilities are shared between Customer and CSP.

Thorough knowledge is required on all key aspects around model, as it determines customer’s scope of work/responsibilities and can tighten policies/controls accordingly.

For IaaS, PaaS, SaaS: to get an idea on amount of control/responsibilities between provider/customer, refer below picture.

Thanks a lot for making until here!!.

Kiran’s Chai(Tea Latte) as a Service- Cloud Service Models Exemplified with a personal story… was originally published in DevOpsCube on Medium, where people are continuing the conversation by highlighting and responding to this story.