Kubernetes and Cloud Native Associate (KCNA) Study Guide

Chapter 4. Essential Concepts for Cloud Native Practitioners

In this chapter, we will explore essential concepts related to cloud computing. Having a solid understanding of the basics allows you to build upon them for advanced implementation. Every exam candidate will have different levels of preexisting knowledge; to give you a solid base, we will cover cloud-related topics end to end, from the basics to other advanced concepts that you will leverage later in Chapters 5 and 6 for Kubernetes.

Concretely, we will cover an introduction to general cloud computing, its evolution, infrastructure, commercialization, and the road to cloud native. The goal is to provide a holistic picture of how cloud computing evolved into what we know today. The material in this chapter includes explanations of topics covered in the KCNA exam.

General Cloud Computing

Let’s start from the beginning. What is cloud computing? And why do we use the word “cloud”?

The cloud refers to servers that are remotely accessible over the internet. Software and databases run on these servers. Imagine buildings (often referred to as data centers) full of physical servers. A company that owns these data centers rents out the ability to use the computing powers of these servers to other users or companies. These users then do not have to manage physical servers themselves. Running their applications on these clouds, a computing model that allows remote allocation of computing resources owned by a third-party for external users, is what is generally referred to as cloud computing.

More officially, CNCF defines cloud computing as follows:

A model that offers compute resources like CPU, network, and disk capabilities on-demand over the internet. Cloud computing gives users the ability to access and use computing power in a remote physical location. Cloud service providers (CSPs) like AWS, GCP, Azure, DigitalOcean, and others all offer third parties the ability to rent access to compute resources in multiple geographic locations.

Before the advent of cloud computing, organizations typically had to rely on building and managing their own physical infrastructure to support their computing needs. This is typically called on-premises, or bare-metal infrastructure. This approach involved procuring servers, storage devices, networking equipment, and other hardware components, as well as establishing data centers or server rooms to house and maintain these resources, which are costly and often cumbersome to manage.

Also, you may have heard the term monolithic application. The term refers to a single piece of traditional software that continues to increase in size and complexity as new features and abilities are added onto it. In order for the monolith to function, it must reside and run on a single system that supports it. This hardware system with specific memory, networking, storage, and computational capacity and ability is complex to build, maintain, and expand. Scaling up or down a part of this operation is difficult as it requires another server with a load balancer. To do this, organizations have to assess needs, weigh the benefits against the cost, go through a procurement process, and once obtained, set it up. This process can take months or years, making it difficult for organizations to respond quickly to demand. This is not to mention the work that the engineers have to do in order to keep all server instances up-to-date with upgrades and security or operational patches. The disruptions in service are hard to avoid.

If a monolith is a hard-to-move mammoth, microservices are like a colony of bees. Bees come together to carry out many well-organized functions. The colony’s shape and size is easy to adapt. Bees can adjust and move with agility. That is why organizations move away from monolithic applications and start building microservices instead.

As you can see in Figure 4-1, microservices refer to small, independent processes coming together to form a complex application. These microservices communicate with one another through application programming interfaces (APIs) over a network. You may have heard of external APIs. API specifications dictate the way that each component interacts with another, regardless of them being in the same application.

Figure 4-1. Microservices-enabled development

Now, think of the fact that microservices are small and independent. They can communicate with each other easily. That means there is no need for them to reside together on a single piece of hardware. The hardware can similarly be smaller and separated. Each microservice can find the hardware that best suits its characteristics and needs. This is where cloud computing comes in.

As connectivity, storage, and hardware technologies advanced, cloud computing became an answer to the challenges associated with traditional computing and monoliths. With Amazon’s launch of AWS in 2006, which enabled organizations to rent server space remotely, cloud computing gained mainstream adoption and revolutionized the way organizations approach their computing needs. With cloud computing, organizations can leverage the resources and services of cloud service providers, accessing computing power, storage, and other resources over the internet. They can scale resources up or down on demand, pay for what they use, and benefit from the provider’s expertise in managing and maintaining the underlying infrastructure. More importantly, cloud computing enables organizations to focus more on their core business activities and software development rather than worrying about hardware maintenance, infrastructure planning, and scalability constraints.

This is why microservices and cloud computing are a match made in heaven. Together, with containers (see details in Chapters 5 and 6), they are a trifecta of modern cloud application architecture. Containers fill in the missing piece in making microservices run easily anywhere. They can be considered an add-on package that isolates the microservice from dependencies and the operating system. Containers make microservices self-sufficient so they can run in any environment, any cloud, and any desktop. Technologies like Docker or Podman are used to create and run containers.

To manage, deploy, and scale containerized code in the cloud and take full advantage of it, you need a system. Container orchestration refers to the ability to automatically provision, deploy, and scale containerized applications on the cloud. Systems like Kubernetes and Docker Swarm do just that. They allow users to manage the containers across the clouds.

This application architecture is crucial in the popularization of cloud computing in modern times. The commercialization of the cloud depends on its connectivity and users’ ability to access it from anywhere. In the next section, we will explore the different ways that cloud services are structured and made available in the market.

Commercialization of Cloud Computing

Cloud service providers (CSPs) offer cloud technology with differing degrees of administration, maintenance, and self-service functionalities, so their clients do not need to buy physical machines or develop their own services. Not dissimilar to a rental agreement, CSPs allow their clients to pay to use their infrastructure and services without having to build, own, and maintain them. A consumption-based pricing strategy is typically employed, where customers are charged based on the resources they utilize and the duration of usage. This flexible pricing structure eliminates the need for up-front capital investments and allows organizations to align their costs with actual resource consumption, optimizing their IT budgets. Public and private organizations use this type of service as a financial choice of operational expenditure (OPEX).

The commercialization of cloud computing technologies offers different levels of service, as you can see in Figure 4-2. Basically, there are trade-offs between financial cost and technical control, giving adopters the option to choose the model that suits them better. The “as a service” model has different levels of implementation as described in the following subsections.

Figure 4-2. Managed cloud “as a service” levels

Infrastructure as a Service

In the infrastructure-as-a-service (IaaS) model, CSPs provide users with computing, networking, and storage resources to create and run their applications. Users have a high level of control but also higher maintenance requirements. In this case, the users rent bare-bones server space and storage from the providers. A popular analogy for IaaS is that it is like renting a plot of land. The possibilities are endless. You can build anything you want on it. However, know that you will bear the cost of building material and equipment.

One of the reasons IaaS is appealing to users is to reduce capital expenditures and transform them into operational expenses. Instead of procuring the hardware and building their own cooling server room, users simply engage the CSP to provision and manage the infrastructure, which can be accessed over the internet.

Other benefits of IaaS include scalability efficiency and boosting productivity. For businesses with changing and unpredictable needs, IaaS allows users to respond to needs by quickly increasing or decreasing resources as needed. IT professionals in the organization do not have to worry about maintaining a data center with high availability. The CSPs are in charge of ensuring that the service is available to users at all times, even when there is a problem with equipment. This allows the organization to concentrate on strategic business activities.

Examples of IaaS offerings are Amazon Elastic Cloud Compute (EC2), Microsoft Azure Virtual Machines, and Google Compute Engine.

Platform as a Service

In the case of platform as a service (PaaS), cloud providers equip their users with a platform to run applications, as well as all the IT infrastructure required. In other words, the users rent the equipment and tools to build their own building on the infrastructure. PaaS provides a platform for developers to develop, run, and manage their own application without having to worry about the infrastructure. Infrastructure management, security patches, updates, and other administrative tasks are taken care of by the provider. When using PaaS, organizations can forget about setting up and maintaining application servers and the various environments. They pay only for the resources that they use, which makes this option attractive in scenarios where they want to quickly build, test, and deploy applications.

PaaS requires less maintenance when compared to IaaS, but users also have less control. Some examples of PaaS offerings include Google App Engine, Microsoft Azure App Service, and Heroku.

Software as a Service

With software as a service (SaaS), CSPs offer applications plus the required platform and IT infrastructure over the internet. Cloud providers build, maintain, and offer applications for users on demand. Generally, these ready-to-use products are available for a subscription fee. In this model, the users do not have to build the building themselves. The building is available for them to rent; all they have to do is move in and pay rent. The renter can use the building as if they own it most of the time. However, they know that while the landlords will fix things when they are broken, not all functions can be customized according to their needs.

SaaS makes it easy for organizations to implement new technology with little effort to train their staff. There is no need for an IT staff member to even manage the software as it is all taken care of by the provider.

This model is simple to use with limited maintenance required by users. Popular SaaS offerings that you may be familiar with include Salesforce, Google Workspace, Slack, and Dropbox.

Container as a Service

While you may be more familiar with IaaS, PaaS, and SaaS, container as a service (CaaS) is gaining popularity among IT professionals, particularly microservices developers. CaaS refers to the automated hosting and deployment of containerized software packages. It is usually available for a subscription fee, hence the as-a-service concept. Designed based on industry standards such as OCI and CRI, CaaS makes it easy to move from one to another cloud provider.

Without CaaS, software development and operations teams need to deploy, manage, and monitor the underlying infrastructure that containers run on. This infrastructure is a collection of cloud machines and network routing systems that requires dedicated DevOps resources to oversee and manage. There is no need to install, operate, or maintain the container orchestration control plane. In other words, CaaS solutions remove the complication of actually orchestrating the container orchestration tool.

Some examples of CaaS include Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS). ECS is a container orchestration and management service provided by AWS. It offers a choice of orchestrators including its own native orchestration tool. Similar to ECS, EKS is a fully managed Kubernetes service. Other popular CaaS tools are Azure Container Instances (ACI) and Google Cloud Run.

Function as a Service

In the function-as-a-service (FaaS) model, CSPs enable users to create packages of code as functions without maintaining any infrastructure. This is a very granular cloud usage option, which makes it especially interesting for development activities. To use the same analogy, FaaS allows the renter to pay only for the room in the building that’s being used at the time.

The FaaS model allows developers to write and deploy code in the form of functions that are executed in response to specific events or triggers. Since the code is deployed without provisioning or managing servers or backend infrastructure, it is often referred to as serverless cloud computing. FaaS is suitable for users who wish to run specific functions of the application without managing the servers. The users only have to provide code and pay per duration or number of executions.

Some CaaS tools mentioned in the previous section are integrated within an environment that is serverless, so some CaaS solutions have the characteristics of FaaS. The key here for FaaS is that the underlying infrastructure and platform is all taken care of by the providers. Some examples of FaaS are AWS Lambda and Google Cloud Functions.

Cloud Computing Infrastructure

There are different types of cloud computing. General cloud computing often refers to the “public” cloud, which is a global infrastructure from big providers, physically shared by different clients that are logically isolated within their own work environments. However, let’s dive into a comprehensive list of all the options.

Public Cloud

For the public cloud, physical cloud resources (servers) are organized and distributed by the cloud provider. This means that two or more companies can use the same physical infrastructure. As opposed to public parks or libraries, public clouds actually have a private owner. The owner provides access and usage of the cloud to their clients, who pay them a fee. Examples of public clouds include AWS, GCP, and Azure from Microsoft.

Private Cloud

In a private cloud, the whole “cloud” is for one single organization. It is commonly used in environments requiring a very high level of control. Private clouds allow users to leverage all the advantages that come with cloud computing but with the access control, security, and resource customization of an on-premises infrastructure. Some organizations may opt for a private cloud if they deal with sensitive and confidential information or strict regulations that mandate greater visibility and control on access, software/hardware choices, and governance. What’s interesting here is that because private clouds (often dubbed “on-prem” solutions) are built with the same fundamentals as public clouds, it allows the organization to easily migrate to or share its workload with public clouds, leading to a hybrid cloud solution.

Hybrid Cloud

Hybrid cloud refers to utilizing both public and private clouds for an organization’s cloud computing, storage, or service needs. Sharing the load between private and public cloud options allows the organization to create a versatile setup based on its needs. This approach is one of the most common setups today because of its ability to optimize usage and costs, including risk sharing.

Multicloud

Multicloud refers to a type of hybrid cloud setup (see Figure 4-3 for an example). Some organizations may choose to use cloud technologies from multiple providers. This can make sense in terms of cost optimization (when provider A is cheaper than provider B for some specific services), or to leverage the combined offerings of services (which may be different depending on the combination of providers).

Figure 4-3. Types of cloud infrastructure

Organizations choose their “-aaS” models and type of clouds based on their own business needs and preferences. After they choose their cloud, they have to decide how to deploy their systems, services, and applications. That’s where the concepts of virtualization, containerization, and orchestration come in.

The Virtualization, Containerization, and Orchestration Trifecta

At this point in the process, organizations have to ask themselves how to deploy systems, services, or applications to make them available to everyone within the organization, embracing the benefits of cloud-enabled systems, such as availability or scalability. They will likely utilize already deployed services and deploy others based on techniques such as virtualization, containerization, and others.

Virtualization

Virtualization is a technology that enables the creation of virtual versions or representations of physical resources, such as servers, operating systems, storage devices, or networks. It allows multiple virtual instances to run simultaneously on a single physical machine, each isolated and behaving as if it were running on its dedicated hardware.

In traditional computing, each physical server or computer typically runs a single operating system and hosts specific applications. However, virtualization enables the abstraction and sharing of physical resources among multiple virtual machines (VMs) or virtual environments.

Containerization

Containerization is a technique in software development and deployment that encapsulates application and its dependencies into a self-contained unit called a container. A container provides a lightweight and isolated runtime environment that allows applications to run consistently across different computing environments, such as development machines, testing environments, and production servers.

Containers are created from container images, which are pre-built packages that include the application code, libraries, runtime environment, and any other dependencies needed to run the application. These images are typically created using containerization platforms like Docker.

The key components and concepts in containerization are as follows:

Container image

A container image is a static, read-only file that serves as a blueprint for creating containers. It contains the application code, along with the necessary runtime dependencies, libraries, and configuration files. Container images are portable and can be shared and distributed across different systems.

Container runtime

The container runtime is responsible for running and managing containers. It provides an isolated and secure execution environment for containers, ensuring that they have their own filesystem, processes, and network stack while sharing the host machine’s operating system kernel.

Containerization platforms

Containerization platforms (such as Docker) and container orchestration systems (like Kubernetes) provide tools and services for building, running, and managing containers at scale. They offer features like container orchestration, networking, storage, and monitoring to simplify deployment and management of containers.

Container orchestrators

Container orchestrators, such as Kubernetes, manage the deployment, scaling, and monitoring of containers across multiple hosts or nodes. They automate the scheduling of containers, ensure high availability, and provide advanced features like load balancing and service discovery.

Benefits of containerization include the following:

Portability

Containers can run consistently across different environments, from development to production, enabling easier deployment and migration of applications.

Efficiency

Containers are lightweight and have fast startup times, allowing for efficient resource utilization and rapid scaling.

Isolation

Containers provide isolation between applications and the host system, enhancing security and preventing conflicts between dependencies.

Reproducibility

Containers encapsulate all dependencies and configurations, ensuring consistent application behavior and simplifying collaboration between teams.

DevOps enablement

Containerization aligns well with DevOps practices, enabling faster and more streamlined software development, testing, and deployment workflows.

The main difference between virtualization and containerization is that virtualization creates separate virtual machines with complete operating systems, while containerization encapsulates applications and their dependencies within lightweight containers that share the host OS. Virtualization provides stronger isolation, while containerization offers faster startup times, lower overhead, and more efficient resource utilization, making it well suited for modern application deployment and microservices architectures. As you can see in Figure 4-4, lighter weight is one of the key advantages of containers.

Figure 4-4. Virtualization versus containerization

Orchestration

Orchestration refers to the automated management, coordination, and execution of complex tasks or processes, like a musical conductor in a symphony. It involves controlling and organizing various components, services, and resources to achieve a desired outcome efficiently and reliably.

Orchestration plays a crucial role in the deployment and operation of distributed applications, especially in cloud computing and microservices architectures. It helps automate and streamline processes that involve multiple interconnected components, such as provisioning and scaling resources, managing dependencies, handling deployments, and ensuring high availability.

Kubernetes is a type of container orchestrator. Basically, it manages service-oriented application components that are tightly scoped, strongly encapsulated, loosely coupled, independently deployable, and independently scalable. Each service focuses on a specific business functionality and can be developed, deployed, and scaled independently. In a microservices architecture, an application is decomposed into a set of self-contained services that each handle a specific task or business capability.

Relationship Between Cloud Computing and Cloud Native

Cloud computing and cloud native are related concepts but refer to different aspects of modern computing. As we have discussed, cloud computing refers to the delivery of computing services over the internet, providing on-demand access to a variety of resources, including servers, storage, databases, software, and networking. It involves leveraging remote servers and infrastructure provided by CSPs to store and process data, run applications, and perform computing tasks. Examples of cloud computing service providers include AWS, Microsoft Azure, and GCP.

Cloud computing offers benefits such as cost efficiency, scalability, flexibility, accessibility, and reliability. It eliminates the need for organizations to build and manage their own physical infrastructure, allowing them to focus on core business activities while leveraging the resources and services offered by cloud providers.

Cloud native, on the other hand, is an approach to developing and deploying applications that take full advantage of cloud computing capabilities and leverage cloud native technologies and practices. It is about designing, building, and running applications specifically for the cloud environment, with a focus on scalability, resilience, and agility. Developers make use of microservices and containerization technologies, such as Docker, to package applications and their dependencies into lightweight, portable containers that are often managed and orchestrated using tools like Kubernetes. Along with DevOps (development operations, which we explain later in this chapter) and CI/CD, you have the key building blocks of cloud native, as illustrated in Figure 4-5.

Figure 4-5. Cloud native building blocks

Let’s discuss a couple of cloud native examples. Netflix is a prime case of a cloud native application. It utilizes microservices architecture and runs on the AWS cloud infrastructure. Each component of Netflix’s application, such as user profiles, recommendations, and video streaming, is built as a separate microservice, allowing for scalability, fault tolerance, and continuous deployment. Similarly, Lyft, a ride-sharing platform, is built as a cloud native application. It uses microservices architecture to handle various functions such as ride matching, real-time tracking, and payments. Lyft employs cloud computing platforms like AWS and GCP to ensure scalability, availability, and cost optimization.

In summary, cloud computing is about delivering computing services over the internet, while cloud native refers to an approach to application development and deployment that leverages cloud computing capabilities and adopts cloud native technologies and practices. Cloud native applications are designed and built specifically for the cloud, taking advantage of microservices, containerization, and orchestration to achieve scalability, resilience, and agility.

Building Cloud Native Applications

Cloud computing helps build cloud applications that are efficient to deploy and resilient to maintain. As with anything new, best practices emerge out of experience. It is through this experience that the Twelve-Factor App came about.

Heroku created this methodology in 2012. It outlines building SaaS apps that can be written in any programming language, using any combination of backing services (database, queue, memory cache). The 12 factors are outlined here:

1. Codebase

A Twelve-Factor App should have one codebase tracked in version control, but there can be multiple deployments of this codebase. For example, production, staging, and development environments should all come from the same codebase.

2. Dependencies

Declare and isolate dependencies explicitly. Do not rely on the existence of system-wide packages. This ensures consistent environments and avoids the “works on my machine” problem.

3. Config

Store configuration that varies between deployments (e.g., database credentials, API keys) in the environment. This separates the configuration from the application, ensuring that the application is environment agnostic.

4. Backing services

Treat backing services like databases, caching, messaging systems, and so forth as attached resources. This means that a local MySQL database should be treated the same as a managed Amazon Relational Database Service (RDS) instance, for example.

5. Build, release, run

Strictly separate the build and run stages. The build stage converts code into an executable bundle, the release takes the build and combines it with the environment’s config, and the run stage (runtime) runs the app in the execution environment.

6. Processes

Execute the application as one or more stateless processes. Any data that needs to persist should be stored in a stateful backing service, like a database.

7. Port binding

Export services via port binding. Your application should be self-contained and not rely on a separate web server; it should be able to bind to a port and start accepting requests.

8. Concurrency

Scale out using the process model. This means that performance scaling should be achieved by adding more processes rather than trying to make individual processes bigger and more complex.

9. Disposability

Maximize robustness with fast startup and graceful shutdown. Processes should strive to start quickly and shut down gracefully by releasing their resources and shutting down in response to a SIGTERM signal.

10. Dev/prod parity

Keep development, staging, and production environments as similar as possible. This reduces discrepancies and “works on my machine” issues, leading to more predictable deployments.

11. Logs

Treat logs as event streams. Instead of managing logfiles, apps should produce logs as a continuous stream of events and let the environment handle storage and archiving.

12. Admin processes

Run admin/management tasks as one-off processes. This means that tasks like database migrations should be run as separate processes, ideally in an identical environment to the regular long-running processes of the app.

The Twelve-Factor App methodology is a comprehensive guide, and while not all applications will strictly adhere to every factor, they provide a solid foundation for building scalable and maintainable SaaS applications. From a KCNA point of view, you can consider these factors industry standards when it comes to cloud native development.

Other Relevant Cloud Native Topics

There are several terms related to cloud native that explain methodologies, best practices, technical paradigms, etc. Most of them are described by CNCF in its official glossary of terms. Besides everything we have reviewed up to now, and the next two Kubernetes-first chapters, here are some fundamental terms you need to familiarize yourself with before taking the KCNA exam.

DevOps and CI/CD

According to the CNCF Glossary, DevOps is a methodology in which teams own the entire process from application development to production operations, hence DevOps. It goes beyond implementing a set of technologies and requires a complete shift in culture and processes. DevOps calls for groups of engineers who work on small components (versus an entire feature), decreasing handoffs—a common source of errors.

The reality is that the definition of DevOps is one of the most debated issues in the field. DevOps implementation often entails a practice of moving testing, quality, and performance evaluation early in the development process. This move is sometimes referred to as a “left shift,” as in shifting these steps to the left closer to or even before code is written.

See Figure 4-6 for an illustration of an iterative DevOps cycle, a series of steps for the software development and release process.

Figure 4-6. DevOps lifecycle loop

Let’s discuss each of the eight steps:

1. Plan

In this initial phase, the team plans out the features, improvements, or fixes that they want to implement. Requirements are gathered, and tasks are prioritized.

2. Code

Developers write and commit the source code. This could involve feature development, bug fixing, or code refactoring. Tools like Git are commonly used for version control.

3. Build

The source code is compiled into executable artifacts. Build tools such as Maven, Gradle, or Jenkins automate this process, ensuring that the code can be reliably built into software.

4. Test

Automated tests are run to ensure that the software is reliable, secure, and meets quality standards. This can encompass unit tests, integration tests, system tests, and more.

5. Release

Once the software passes tests, it’s ready for release. Automated deployment tools can push the software into staging or production environments. The release process might involve CI/CD pipelines.

6. Deploy

The software is deployed to production servers. This step is sometimes combined with release, especially in CD environments where code is automatically deployed once it passes all tests.

7. Operate

After deployment, operations teams monitor and maintain the system. This includes ensuring uptime, scaling resources as necessary, and addressing any runtime issues.

8. Monitor

The software’s performance and health are continuously monitored. Monitoring tools can detect and alert teams to anomalies or failures. Feedback from monitoring is used to identify areas of improvement, and the loop begins anew.

These steps plus the previously explored Twelve-Factor App methodology lead to the concept of CI/CD. As noted earlier, this acronym stands for continuous integration and continuous delivery/deployment. The “CD” part often refers to two possible options:

Continuous delivery

An extension of CI. It ensures that code is always in a deployable state after passing CI pipelines. In this case, the release process is still manual.

Continuous deployment

While continuous delivery ensures that code is always deployable, continuous deployment goes a step further. Every change that passes the CI tests is automatically deployed to the production environment without manual intervention.

These are fundamental principles in the DevOps philosophy, emphasizing the automation of the software development and deployment processes. They are designed to increase the velocity, efficiency, and reliability of software releases, based on the eight iterative DevOps steps.

GitOps and Infrastructure as Code

GitOps is a DevOps method using Git repositories as the source of truth for all configuration and code and automating deployments. Using Git principles provides a clear and versioned history of changes, enabling easy rollbacks, auditability, and peer review. Then, once changes are merged into the main branch of the repository, they are automatically applied to the infrastructure. This reduces manual steps and errors and ensures a consistent state of infrastructure.

GitOps allows CI/CD tools to handle the infrastructure as code (IaC), which is the practice of storing the definition of infrastructure as one or more files. This replaces the traditional model, where infrastructure as a service is provisioned manually, usually through shell scripts or other configuration tools. Examples of these tools include Terraform, Ansible, Puppet, and other native approaches from the public cloud providers.

Declarative Versus Imperative

One of the key concepts in cloud native is the notion of declarative or imperative, which focuses on two different programming paradigms, in this case to specify the expected configuration for cloud native systems:

Declarative

The declarative approach requires that you specify what you want to achieve without detailing the step-by-step procedures to get there. For example, picture it like setting a destination in your GPS. You specify where you want to go, but you don’t need to provide the GPS with turn-by-turn directions because it figures out the best route on its own. In software terms, this often involves setting configurations or states that the system should adhere to, and letting the underlying logic determine how to accomplish that.

Imperative

Now, imagine you’re giving someone step-by-step directions to reach a particular destination. This embodies the imperative approach. In an imperative style, you give a series of commands or steps that need to be executed in sequence to achieve the desired result. It’s like writing a detailed recipe where each step is explicitly stated. In programming, this translates to writing out each action and logic operation in detail.

Stateful Versus Stateless

Stateful and stateless are two fundamental concepts in computing and software design that describe how systems or processes retain information over time and across interactions. Concretely:

Stateful

A system or process is considered stateful when it retains or remembers information from one transaction to the next. This “state” information can be used to influence future transactions, meaning that past interactions can affect future ones. For example, consider online banking transactions or a shopping cart at an online grocery store.

Stateless

A system or process is considered stateless when it doesn’t retain any record of previous interactions. Each transaction is processed without any memory of past transactions. Every request is treated as an entirely new operation. For example, think of a REST API in which each transaction is managed independently and there is no data retention from previous transactions.

Egress and Ingress

These two terms are commonly used in telematics/networking and cloud environments to describe the flow of traffic in relation to a particular point of reference, usually a network boundary or a specific system. These terms are applicable to Kubernetes with regard to the direction of the traffic coming to and leaving from the cluster. More specifically:

Ingress

Ingress refers to the incoming traffic that is being routed to a specific network, system, or application. It’s essentially about managing and allowing external users or systems to access your internal resources. In K8s, an Ingress is also a specific object that manages external access to services within a cluster.

Egress

Egress pertains to the outgoing traffic that is being routed out of a specific network, system, or application. It’s about managing and controlling the access of internal resources to external destinations.

In cloud computing, providers usually have controls and tools to manage egress traffic because of both cost and security concerns. For instance, an organization may want to restrict or monitor which external services a cloud-based application can access.

Serverless

Serverless is a cloud native development model that allows developers to build and run applications without having to manage servers. There are still servers in serverless, but they are abstracted away from the developer. A cloud provider handles the routine work of provisioning, maintaining, and scaling the server infrastructure. Developers can simply package their code in containers for deployment. Once deployed, serverless apps respond to demand and automatically scale up and down as needed. Serverless offerings from public cloud providers are usually metered on demand through an event-driven execution model. As a result, when a serverless function is sitting idle, it doesn’t cost anything.

These are just a few terms that you need to know before starting Chapters 5 and 6, which will exclusively focus on Kubernetes and its technical details. But before that, let’s turn to the end-of-chapter expert insights, in this case from someone who knows the KCNA and other Kubernetes certifications very well: Benjamin Muschko, who is a renowned cloud native consultant and the author of the O’Reilly CKA, CKAD, and CKS study guides.

Expert Insights: Benjamin Muschko

Adrián: How are you, Ben? Welcome.

Benjamin: Hi, thank you. Doing pretty good. How about yourself?

Adrián: Doing well. Enjoying the day and having a blast sharing some time with you. We really appreciate that you are joining this series of interviews with different Kubernetes and cloud native experts.

Benjamin: You’re welcome.

Adrián: So just for those who don’t know you, I don’t think there are a lot, but in case they don’t know you, who is Ben and what’s your relationship with the Kubernetes ecosystem?

Benjamin: Yeah, so I work as an independent software engineer and technical trainer, oftentimes actually with O’Reilly. It’s one of my main content providers. And when I do consulting on cloud native migrations, I would say the move toward Kubernetes is oftentimes a big topic. Not only I would say Kubernetes, but also the migration toward microservices, containers, and so on. So I think that’s my background. So ultimately, when I work with clients, Kubernetes comes up in many cases, I would say, because organizations simply want to migrate to the cloud. And that usually means Kubernetes these days.

Adrián: And I assume that you are also within the CNCF and Kubernetes communities.

Benjamin: Yeah, that’s right. I’ve been trying to get into contributing to some of the open source projects. I just got started with the OPA project, Open Policy Agent. I am trying to get into that a bit more. I was actually really just starting to look into the list of issues that they have, and the contributions they’re looking for. That’s what I’m going for right now. I’ve not been contributing too much to the actual Kubernetes project itself. They have this big ecosystem with a lot of contributors there. But it’s great to see what’s around.

Adrián: Yeah. Since you have been working on this area for so many years, do you remember how hard or easy it was to start working with Kubernetes and, in general, with microservices and containers as an initial learner? Because these interviews are oriented to people who are starting to learn about the Kubernetes and cloud native ecosystem.

Benjamin: Yeah, moving toward microservices is somewhat independent of a specific technology. So it’s more a methodology where you have to think about how to cut up your monolithic application into chunks, how you want to expose it, how you want to run it in the cloud, potentially. So I would say that is more a discipline than anything technological.

Oftentimes, people bring in Kubernetes or containers in that context, but it doesn’t necessarily have to mean that you have to run it on the cloud or in a container. But generally speaking, when we talk about containers and Kubernetes, containers are relatively easy to pick up. I think their hype days are somewhat over nowadays since it’s not super new anymore. So I would say that it wasn’t too hard for me to pick it up.

Though the general usage of containers is relatively easy, when it comes down to best practices, it looks slightly different. Especially when it comes down to security aspects, how to build your container image properly, how to integrate it into your CI/CD pipelines, for example. Those are usually concerns that come with the notion of wanting to move toward containers.

In terms of Kubernetes, when I first looked at it, it wasn’t necessarily apparent where to start. I mean, you obviously would start on the level of Pods, at least if you look at it from the perspective of an application developer. So getting something to run in a Pod is relatively easy. But then when it comes down to actually operating applications at scale and exposing it to end users and picking the right product that you want to use as your Kubernetes cluster, I think those aspects are more complicated. And if you look at documentation, there’s simply a lot of it. So it’s hard to find a good starting point where you would say, OK, look at this first, this will give you a rough understanding about Kubernetes, and then you’re good to go. I don’t think it’s like that.

How I usually look at Kubernetes is from the perspective of a specific role. What capacity are you working in? Are you looking at it from the perspective of, say, an administrator who wants to manage a Kubernetes cluster and everything that comes with it? Or are you basically a developer, where you work with an administrator who sets everything up for you and manages nodes and security aspects and things like that and you just want to operate your application? I think those are different perspectives on how to look at Kubernetes, and also how to learn Kubernetes, if you’re somewhat new to it.

My clients are often application developers. They usually have a hard time grasping certain concepts and where to start. Often, the issue is time. So application developers come in and say, OK, I need to deploy something to the cloud. I know how to write my application independent of the language that you’re using. But now I have to learn everything around Kubernetes. Where do I even start? What do I need to understand in terms of fundamentals and the Kubernetes primitives that help me run the actual application inside of a Pod? And not just a Pod, but anything that comes with it. Security, scaling, and so on. From that perspective, it’s hard to know where to start.

Adrián: I think part of the goal of this book and the certification itself is just to give some structure to all these areas of knowledge. The architecture part, the architecture mindset, how to connect the pieces regardless of the technology or the provider we have. It doesn’t matter if it’s a private cloud, a public cloud, but all the security aspects, all the development aspects. How do we gain actual experience in Kubernetes and related technologies?

Benjamin: The certification curriculums are a good start. I think they provide a very good structure for anyone who’s new to Kubernetes and they just want to learn what’s really important to them, to their specific role. They can really go into it, learn it from scratch, independent of a cloud provider or a specific cloud environment. You simply just go ahead and set up minikube if that’s the thing that you want to use. Obviously, it’s not production ready, but once you gain experience, you can easily apply that knowledge to your cloud provider.

But generally speaking, I would say a good starting point is the Kubernetes documentation. I think they put in a lot of improvements over the past couple of years. When I first started to look at it, it was somewhat overwhelming. I think the structure has changed and improved quite a bit. And they try to bring in best practices as well.

I wish there were a bigger focus on tutorial-style documentation as well, or at least as a complement to the reference documentation. If you look at other ecosystems, I think one company that does a pretty good job with that is HashiCorp. They usually have their reference documentation and then they have their tutorial-style documentation as well.

But generally speaking, there’s a lot of information on the web. So if you Google for it, you can spend weeks going through tutorials and best practices. I think some of the prominent companies in the Kubernetes space have their own blog pages as well. And they are pretty useful when it comes down to picking up best practices, I would say.

Adrián: Do you have any favorite resources out there, like from companies, from experts?

Benjamin: There are many for different aspects. The Cilium project sometimes has pretty good blog posts. But there are so many companies now in the space so you can find very specialized aspects as well. For example, using Kubernetes at scale or multi-tenancy, things like that. Those are topics that are usually backed by the companies that have a special interest in that space too.

Adrián: Yes, I totally agree. The cookbooks and the how-tos and the manuals and the architectural views are all very intuitive for people to start learning. At the end of the book, we have a chapter dedicated to additional resources, community resources, because this is a living area of knowledge. It’s easy for people to continue learning and exploring because there is so much.

Benjamin: I think it’s always good to build that bridge from, I wouldn’t say necessarily theoretical, but from the general content as a reference toward how do you actually apply this in a real project too? And what are the challenges you would potentially face? Anything that you know up front, even if you’re a beginner to Kubernetes, will be helpful. Just a simple example of security aspects or resource management in general, that you can assign to Pods or applications that run inside of a container. If you already know about that, you can help yourself quite a bit when it comes down to production-level issues that you may run into in general.

Adrián: Totally. And that applies to Kubernetes, to cloud native, to general cloud computing. One thing is the theory of how you deploy things and then when we have a specific situation, experience is an additional value for these situations.

What do you think about the different Kubernetes-related certifications, exams in general, without going into detail of this one, but what do you think that the most challenging parts are for a Kubernetes exam? Where do you think that people will struggle the most when they are trying to pass these certifications?

Benjamin: I believe the certifications are a good concept, a good credential to have for anyone who tries to either get into the space or wants to show that they have the knowledge in that space already. I know that some folks like to acquire these certifications if they want to potentially transition into a different role. Maybe they already have worked in some sort of DevOps role, but they want to get more deeply into Kubernetes. From that perspective, the certifications clearly lay out a curriculum. They give you the building blocks that you can follow to have the most basic understanding about what this role involves when it comes down to Kubernetes. So I think in that way, they’re super useful.

Independent of finding a new job, I think you can use these certifications to improve your knowledge as a developer, as an administrator, or whatever your role may look like. Don’t view these certifications as something you do quickly just to gain the badge or credential to put on your resume. See it as the starting point for your career to become more proficient with Kubernetes in general.

But I would say generally speaking, if you’ve taken one of these certifications before, one of the challenges is you don’t have any visual dashboard, which you may be already used to. If you’re working with Kubernetes, maybe you already work with AWS or Azure, and you may not be that comfortable with kubectl. So kubectl, learning how to use the tool, knowing what’s important about it is the most important skill for the practical side of certifications. I think that is something people struggle with.

I know in the new versions of these certifications, you get a lot of support. You don’t have to memorize every command anymore, they actually provide you with auto-completion up front, and you have an alias for kube-control that’s already set up for you. You don’t have to struggle with that stuff. But generally speaking, being thrown into certain scenarios where you have to solve a problem is extremely useful because that’s something you would face in your job as well. It’s not an exam where you have to answer multiple-choice questions and memorize things. You actually have to work through a problem on a real Kubernetes cluster. I think from that perspective, I think it’s awesome.

If you’re a beginner to Kubernetes in general, the KCNA would be a good entry point. I can definitely talk about that a bit more. Even though it may just be on a level of multiple choice, you can see it as an entry point for you as a learner. What topics are even important in the cloud environment if you want to transition over? Just to give you a certain perspective. You don’t have to understand everything in detail, but if you want to break into that field, where do you want to go? And you might actually find that you like one of those areas specifically, and you may want to specialize, go toward that goal as well.

But generally speaking, learning how to solve problems hands-on, when it comes down to the practical certifications, is the biggest thing people struggle with. And I think they put you under time pressure for a reason. Even though you might think two hours is a long time for a certification for solving X amount of problems, time goes by fairly quickly. So you’re pretty much under pressure and you have to know what you’re doing up front. And I think that could be another challenging aspect to the certification. That doesn’t mean that at work, you have to work the same way. Obviously, they try to make it harder than it potentially needs to be. But at least that puts you into a mindset of how do I solve that problem as quickly, as efficiently as I can.

Adrián: Totally. I wanted to chime in on the commands you mentioned because it’s the same on the KCNA exam. Obviously, we are not using the visual interface. Just answering a question with multiple options. But there is a lot of focus on the exam for the same reason, because it’s a core capability that we would use for any other certification later. Let’s talk more about your O’Reilly books. I think that there was something new this year, but you have been working with O’Reilly for so long.

Benjamin: Yeah, I’ve been working with O’Reilly for probably four or five years now. It’s one of the big topics for O’Reilly as well. I would say, generally speaking, there are a lot of learners looking for that content. And given that at that point of time, I got more into Kubernetes myself. I proposed the idea, why don’t we run some training sessions on Kubernetes? And I know there were already a couple of training sessions out there on Kubernetes. They ran well, so they knew the content is something people are looking for.

But certifications were somewhat still new. I think they had been around for maybe two years before I started. And at that time, there was relatively little content on the Kubernetes certifications. So we did start with the live training on Kubernetes, specifically for the application developer certification. So we started with that. And then my editor asked me whether I wanted to write a book about it too. And it just so happened that I wrote the book about it then. I think if you compare the two mediums, it’s interesting how they can complement each other. The live training helps a lot of people, if they work through a problem, hands-on live, to ask a lot of questions. But then they still need to go back and get more context about a certain topic, because live trainings are constrained to a certain timeframe. And at some point, it’s simply over.

But then you let the information settle itself a little bit. And you notice you still have more questions, you need more context around certain topics. And I think at that point of time, at least for some learners who like to read up on things, those books could be super helpful. So they provide additional context. They come with additional questions and exercises. And they try to answer the why as well. Why do I even care about this specific Kubernetes primitive? Why is it important? How does it play together with other Kubernetes primitives? So at least from that perspective, it gives you more context, more opportunity to learn. And for some learners, it’s easier to read up on something than to sit in a training. And just now we’re planning to also launch a recorded training. So a video course on the CKAD. So that’s probably going to come up in like two months or so, at least I hope. The recording is done. We’ll see how long it takes to process all the videos. I think we have something for anyone, depending on what kind of learner you are. Obviously, there are many other learning opportunities out there. So O’Reilly is not the only publisher that got into Kubernetes. There are plenty more that even started before O’Reilly that provide help with these certifications. So I think at least from a learning perspective, see what’s out there. See what fits your needs the best. Whether that’s a book, whether it’s a video, live training, or anything practical. And then just pick and choose depending on what provider you like the best.

Adrián: Yeah. I think that’s the best approach. And what I find very interesting is the way the CNCF structures different Kubernetes certifications is role-based. I personally love role-based certifications because they treat the same topics from different perspectives. You have covered the CKA for administration, the CKAD for application development, and the security one now.

Benjamin: Yeah. That’s the latest launch we did with O’Reilly. So that one was an interesting one because the security aspects were less known to me before. And it’s good to get some extra exposure in that field. As you may know, the whole industry is moving toward wanting to put in more security. The more security incidents we have as an industry, the more important that aspect becomes.

Depending on the organization that you work with, there’s still a separation between administration, application development, and then security aspects. But I think they’re moving somewhat all together with DevSecOps. So I think in that context, they blend together. It’s important to have some exposure to each of those aspects, whether you work on this on a day-to-day basis or not. It’s good to have an understanding of what potentially may happen in production.

Especially when it comes down to security, it can become very costly for a company not to consider those aspects up front. If you can educate yourself or your team members or anyone that you’re working with on those aspects as well, I think it will save you a lot of money as a company. Whether that’s going to be your main focus or not is a different question. But it’s important to know about security. And the cool thing about the certification on security is that CNCF tries to bring in open source projects as well. So it’s not constrained to just plain Kubernetes. It’s also about open source projects in that space.

I think that could even make the scope much bigger if they wanted to. But at some point, you just have to make a cut and say, like, we can’t cover more than two hours. The exam will probably evolve in terms of the content over the years. So as tools change, as practices change, I think they’ll probably try to bring it in. And usually we see an update to those certifications, say, every three, four years. That might be the case for the security certification as well. So I think from my perspective, I wanted to get more into security myself. And I think that was a great opportunity to get some exposure specifically in the Kubernetes space and ecosystem.

Adrián: Totally, totally. With the KCNA exam, we see that pattern because it is about Kubernetes, obviously, but also about the cloud native ecosystem and the rest of the projects. Some of the questions on the exam are related to other projects that are not Kubernetes. I think that that’s interesting because, as you mentioned, it’s not only about Kubernetes. It’s highly related to Kubernetes, of course, but it’s important for learners out there to know the whole ecosystem.

You mentioned the fact that the people don’t need to be total experts. And that reminds me of the exam personas for the KCNA. We’re talking about maybe like fresh graduates or people who are working on Kubernetes-enabled environments, but they don’t need to be the experts or the people who will be the experts or will become the experts. Is it important that all these people get at the very least a basic level of knowledge on these technologies to improve security and other topics that you have mentioned before?

Benjamin: Yeah, absolutely. I think that is definitely the case, especially if you look at some position descriptions nowadays. They usually blend multiple technologies or responsibilities together. I’m thinking about the full-stack application developer. It’s not just about you being the frontend or backend developer anymore. You have to know the full stack. You have to interact with the database. And then when it comes down to more cross-cutting functionality or features or technologies like security, I think it becomes more and more important. If you look at job descriptions nowadays, I would say security is oftentimes mentioned also just for application developers or administrators, obviously for good reasons. So I think from that perspective, it is important to get at least some high-level exposure, have some understanding. This doesn’t mean you have to be an expert, because oftentimes organizations have specialized roles for security. But you want to speak the same language with different team members or across different departments within an organization. So I think it’s good to have some additional exposure, but that doesn’t necessarily mean you have to be an expert.

Adrián: Totally. Now that’s amazing. You have shared a few recommendations already of resources and how to upscale or where to focus, but do you have any other general recommendations for the exam candidates and the learners out there, something that they should do in order to, I wouldn’t say only pass the exam, but also to be successful with their Kubernetes-related careers?

Benjamin: Yeah, I would say, generally speaking, if you look at, for example, KubeCon and the wider Kubernetes community, I think there’s a lot of opportunity to learn and to get involved. If you compare this to some other communities, I feel the Kubernetes community is extremely inclusive and welcoming to new members. I think one way to start, if you want to get deeper into the community, is to hop on to the Slack channel. I think there’s a lot of discussion going on there. And maybe based on those discussions, you may recognize certain areas, tools from the ecosystem that you may want to get involved into more deeply.

So apart from your main job, where you may focus on a specific role, let’s say you’re an administrator of a Kubernetes cluster, you may still be interested in something else, like helping people picking up Kubernetes easier. There are some learning opportunities and also roles within the CNCF organization that you can get involved with. I think the scope is really broad. There’s a book club now and there’s a new documentation approach now for beginners of Kubernetes. If you want to improve documentation, that’s a good way to involve yourself more deeply. And with that, learn about the contribution process for the CNCF as well.

And then on the sidelines, you may recognize that you’re interested in learning more about a specific tool in the ecosystem. Of those tools, there are almost hundreds by now. This is a good chance to make good connections and improve your knowledge about a specific tool or part of the Kubernetes ecosystem. And obviously, that comes with a big time involvement, I understand. Not everybody has the time, apart from family, hobbies, and a regular job to contribute. But if you want to, you can. So that is a great opportunity to learn more.

If you want to start your own blog, that is oftentimes a good way to start, not necessarily on the level of an expert about XYZ. You can just talk about your personal experience. That is always a perspective that people value a lot, independent of kind of, hey, I’m trying to teach you something. I’m just going to talk about what I’m struggling with and how I solve that specific problem. I guess, if you want to even take that to KubeCon or some other conference, that would be a great chance to do it. Because that’s what attendees are usually looking for. It can just give a personal perspective on those sides of things. And maybe you evolve or develop a specific best practice even better. But I think from that perspective, open source contributions, blogging about things, getting exposure to those tools yourself, obviously, and maybe trying out new tools, comparing them.

For example, if you look at the different tools in the security space for Kubernetes, there are a lot of them by now. You could compare them, try them out, see what kind of features they bring, which one do you like the best, and then maybe you can make it a blog post and go from there. Generally speaking, there are so many learning opportunities, specifically because the community is so welcoming. Just go to KubeCon or one of the conferences or a local meetup and see what other people are talking about that may spark new ideas and show you the direction you may want to go.

Adrián: Yeah, totally. I love the recommendation because that’s what we see in all the open source communities. Of course, this level of involvement requires time, and everyone is aware of the difficulty of Kubernetes topics. So, we don’t need to be hyper experts. We can adapt the content to our level of knowledge, and people are looking for that, like applied experiences. So, that’s a great recommendation for learners and for people who are trying to get into the KCNA exam, because that’s their level usually.

I really appreciate the time you have spent here with us. I’ll be paying attention to the new online training that you’re releasing and will certainly read your latest book. I think that you are helping a lot of the community with your content and the way you explain things. Thank you very much.

Benjamin: Yeah, thank you. It was a pleasure.

Summary

We have now concluded your full immersion into cloud native and some of the key terms that you will leverage for the KCNA exam and in Chapters 5 and 6. Chapter 4 is especially important if you were missing some general cloud computing knowledge, and if you haven’t been exposed to DevOps and other cloud native topics. The next chapter, along with Chapter 6, will equip you with the Kubernetes knowledge you will need to pass the exam. These chapters can be especially challenging if you haven’t worked with Kubernetes before.