What Is Cloud Native?
Learn what cloud native applications are and how they scale, self-heal, and update without downtime. Understand Kubernetes' role in orchestrating microservices and managing resilient applications across environments.
In the last lesson, we learned about microservices. Let’s now examine the cloud native and orchestrator parts of the Kubernetes definition.
What is a cloud native application?
A cloud native app must:
Scale on demand
Self-heal
Support rolling updates
Let’s understand these jargons.
Scale on demand
Scaling on demand is the ability of an application and associated infrastructure to grow and shrink automatically to meet requirements. For example, an online retail app might need to scale up infrastructure and application resources during holiday periods. If configured correctly, Kubernetes can automatically scale applications and infrastructure according to demand. Not only does this help businesses react more quickly to unexpected changes, but it also reduces infrastructure costs when scaling down.
Self-heal applications
Kubernetes can also self-heal applications. We tell Kubernetes what an app should look like, such as how many instances of each microservice. Kubernetes records this as the desired state and watches the app to make sure it always matches that particular state. When things change, such as a microservice failing, Kubernetes notices this and spins up a replacement. We call this self-healing or resiliency.
Rolling updates
Rolling updates is the ability to update parts of an application without taking it offline and impacting consumers. It’s a game-changer in today’s always-on world, and we’ll see it in action later.
One final point. Cloud native has almost nothing to do with the public cloud. For example, deploying a monolithic application to the cloud does not make it cloud native. Whereas a microservices application that self-heals, automatically scales, and does rolling updates deployed to your on-premises data center is cloud native. We call applications cloud native because they possess the attributes we associate with public clouds—resilient, elastic, always on.
In summary, cloud native apps are resilient, automatically scale, and can be updated without downtime.
Orchestration
Orchestration can be a difficult concept to understand. The following sports analogy should help.
A football (soccer) team is a group of individual players. Each has a different set of skills and attributes and a different role to play when the game starts.
The following figure shows an unorganized football team without a game plan.
The coach comes along with the game plan and assigns each player a position and job. They also dictate the tempo of the game, such as when to press, how high to press, and how quickly to get the ball into the opposition’s box.
In short, the coach takes the chaos from the above figure and imposes the order in the below figure. They also react to real-time events, such as injuries and tactical changes, depending on the score.
Well… cloud native microservices applications are a lot like sports teams.
Each cloud native app is made of individual microservices that do different things. Some serve web requests; some authenticate, some do logging, some persist data, some generate reports, etc. And, just like a sports team, they need something to organize them into a useful app.
Enter Kubernetes.
Kubernetes organizes a mess of independent microservices into meaningful apps, as shown in the figure below. It also responds to real-time events by self-healing, scaling, and more.
In summary, Kubernetes is an application orchestrator that brings together different microservices and organizes them into a useful application. It also provides and manages cloud native features such as scaling, self-healing, and updates.
Interesting facts on Kubernetes
The name Kubernetes comes from the Greek word meaning helmsman. This is a nautical term for the person who steers a ship. The wheel of a ship is called the helm, which is where the Kubernetes logo comes from.
If you look closely, you’ll see the logo has seven spokes instead of the usual six or eight. This is because the original Kubernetes developers had worked on the Google Borg project and wanted to name Kubernetes “Seven of Nine” after the famous Borg drone rescued by the USS Voyager on stardate 25479. Copyright laws prevented this, so the founders gave the logo seven spokes in a subtle reference to “Seven of Nine.”
You’ll also see Kubernetes shortened to K8s. The 8 replaces the eight letters between the leading “K” and the trailing “s.” It’s usually pronounced “kates”.