The shift to the cloud

Before diving into Kubernetes, there’s an important question to ask: Why use Kubernetes? The reality is that organizations have been deploying applications without Kubernetes for years. There wasn’t Kubernetes in the 1980s when engineers were writing software to floppy disks. So, why now?

The answer to this question is a complicated one and the best place to start is by thinking about what the cloud does for us – not necessarily what the cloud is, but instead what the cloud helps us think about when deploying software and systems from an architect, engineering, and management perspective. In this section, you’re going to learn about the following aspects of the cloud:

• Why organizations care about the cloud
• What the cloud did for engineers
• How abstraction can help us learn from our mistakes
• How the cloud doesn’t exactly do what people think it does

Let’s take a closer look.

Why organizations care about the cloud

Leadership teams in organizations, whether it’s the CIO, CTO, or someone in a technical leadership position, tend to tie Kubernetes to the cloud. However, this couldn’t be any further from the truth. The reason why could be anything from incredibly good technical marketing to not having enough experience from a hands-on perspective to truly understand what’s happening underneath the hood in a cloud environment. However, let’s digress from that and think about why everyone cares about the cloud. The best way to do this is with a visual, so let’s take a look at the following diagram:

Figure 1.1 – Data center web app architecture

The preceding diagram is of a data center architecture. There are a lot of pieces, some marked and some not, including the following:

• Servers
• Network equipment
• Connections between servers
• Ethernet cables and power cables

With all of that hardware not only comes costs of actually buying it, but also costs around hiring engineers to manage it, maintain it, and keep the lights on in the data center. Not to mention it takes about 4 to 6 months for a full data center to be up and running. With the time that it takes the data center to get up and running, on top of all of the costs and management of hardware, having cloud-based systems starts to make a lot of sense to senior leadership teams for any organization ranging from start-ups to the Fortune 500.

Now, let’s take a look at the architecture in Figure 1.2. This diagram shows a few things, including the following:

• RDS (Amazon’s database service)
• Load balancers
• CDNs
• S3 buckets (cloud storage in AWS)
• Route 53 (AWS DNS)

The architecture diagram in Figure 1.2 is similar to Figure 1.1, in that they are both data centers, but only Figure 1.2 is virtualized as exactly what you would see in a data center. You have network components, storage, databases, servers, and everything in between. The biggest difference is what you’re seeing here is virtualized. It’s a virtual data center with virtual services. Because there are engineers that work at AWS managing the hardware, networking, and other peripherals for you, you no longer have to do it. You only have to worry about the services themselves and making sure they’re working as expected.

No more buying hardware. No more replacing hard drives. No more waiting 4 to 8 months for hardware to arrive at your data center so you can finally build it. Instead, an entire data center is only a few button clicks or a few lines of automation code away:

Figure 1.2 – Cloud web app architecture

Going off of the preceding diagram, here’s where Kubernetes comes into play. Regardless of what option you go with, on-premises or in the cloud, there’s still a ton of stuff to manage. Even though the cloud makes infrastructure easier, there are still major staffing needs and a big cost behind creating all of the cloud infrastructures.

The following are a few pieces of the puzzle to manage:

• Load balancers
• Virtual machines (or bare-metal servers)
• Network equipment (virtual or physical)
• Subnets, private IPs, public IPs, and gateways
• Security for multiple pieces of virtualized hardware and services

And that’s just to name the general categories. Within each category, there are multiple components (physical and/or virtual) to manage. With Kubernetes, it’s all abstracted away from you. There aren’t any firewalls or gateways because that’s managed via kube-proxy. There are no virtual machines that you have to deploy other than the Kubernetes nodes because the apps are running in Kubernetes Pods.

If you run Kubernetes in a Kubernetes service such as Azure Kubernetes Service (AKS) or GKE, the management of the Control Plane, sometimes referred to as the API server or the master nodes (a now deprecated way to describe Control Planes), is completely abstracted away from you.

What AKS, GKE, or another one of the cloud Kubernetes services does underneath the hood is the same thing that you would do if you ran a raw Kubernetes cluster in a bunch of virtual machines. The underlying technology, how it works, and how it’s used don’t change. The only thing that changes is the abstraction.

That’s why the cloud is important for Kubernetes and that’s why CIOs, CTOs, and engineers should care.

What the cloud did for engineers

“The cloud is just someone else’s computer,” as some may say in passing or on funny stickers. As we all know, in every joke is a little truth. The truth is, it’s correct. When you’re interacting with the cloud, it’s not that you’re interacting with some magical service that is just there. Instead, you’re interacting with services that are managed by other engineers.

For example, let’s say you’re working with Azure virtual machines or EC2 instances in AWS. From your perspective, you log into one of the portals or write some Infrastructure as Code (IaC) and in a few minutes, your new virtual server/cloud server is deployed. On the backend, there’s way more that goes into it. There are a ton of different parts, some of which include the following:

• Autoscaling the servers
• Doing multiple checks to ensure that there’s enough hard disk, CPU, and RAM space on the physical/bare-metal server that’s being used
• Networking setup
• Lots of automation

Remember, because the cloud servers that you’re deploying are running on bare-metal servers, people have to be there to manage those servers and maintain them. The cloud is an abstraction layer that you don’t see. With that being said, the cloud has done a lot for engineers.

Let’s take a start-up company for example. Years ago, if a start-up company wanted to do anything in the tech space, they needed servers to host applications and websites. For a small company that’s working out of a tiny office or even from someone’s house, it’s not possible to have a layer of high availability, redundancy, and scalability. They simply cannot afford the hardware, the space, and the employees to do it.

With the cloud, they no longer have to worry about having to do all of that. Instead, the start-up can focus on building applications and deploying them to the cloud. Deploying applications to the cloud is not easy and it certainly has its own complexity, but the idea behind it is to abstract away physical needs (servers, infrastructure, and so on) that your company may not want to/have to worry about.