Understanding the roles of Workload Identities, Cluster Service Accounts, IAM Policies, and IAM Roles in managing access controls within AWS environments.
Exploring real-world use cases to illustrate the importance of effective IAM policy management in securing multi-tenant environments and aligning access controls with business requirements.
Comparing manual IAM policy management with streamlined approaches, such as Wayfinder's Package Workload Identities, to highlight the benefits of automation and centralised policy management.
You can’t deny the impact of Kubernetes. It’s allowed thousands of businesses to scale their applications with the power of container orchestration and cloud-native technologies. While it can seem like this revolutionary tech has only just hit the market, the reality is that Kubernetes history started long before the introduction of Kubernetes v1.0.0 in 2015.
This article looks at the events that led up to the introduction of Kubernetes, the major players and how an internal project at a major tech company changed how we approach app deployment and development.
Before Kubernetes became a de facto standard for application deployment and orchestration, it was a project at one of the world’s largest tech giants: Google. Back then, only those with their ear to the ground knew about the revolution happening behind the scenes. Soon, though, the world would see what Kubernetes features had to offer — but not for another ten years.
To start our history of Kubernetes, we need to begin with Google. Back in the early 2000s, Google had a big problem. While they were still dominating most of the digital world, they still were dialling in how they could make revenue off their robust list of free services. This included popular utilities like:
The problem for Google, which was not the profit-making machine we know today, was finding a way to offer these free services without tanking the business. Keep in mind that it costs a ton to keep services like these up and running — especially if they are popular, which they were.
While Google may not have been making the kind of money we see today, it did have another thing going for it. You see, even back in the early part of the new millennium, Google was still attracting the best and brightest to its teams. With this in mind, Google’s main goal shifted. Google asked its team, “How can we get maximum performance from our hardware?”
Managing Google’s massive architecture of commodity hardware was the issue. Reaching its new goal took a brand new perspective. Google had to completely rethink its infrastructure and application architecture. The result was a new application orchestration system that Google lovingly named ‘Borg’.
Now, if you’re unfamiliar with the Borg, you may not be deep into the Star Trek trivia. Basically, the Borg were an alien hive mind with a collective consciousness. The Borg would “assimilate” enemies, incorporating them into the hive mind and taking away their individuality. They weren't the good guys, but it's a great way to think of the technology that would soon become Kubernetes.
Borg created the cluster management system Google needed to keep up with the millions of users of their services. It even predated Linux kernel features, like control groups, that we now see as foundational elements of containerized applications. This meant that the project wasn't very outside party-friendly and was only usable within Google itself.
At the time, Google thought Borg gave them a competitive advantage. Consequently, the project was a closely kept secret. Nevertheless, the project’s contributions to what we now know as Kubernetes can’t be understated.
At this point in Kubernetes’ history, the Borg project was still under wraps. By now, though, another tech startup was creating some truly next-generation approaches to application development. We’re talking, of course, about Docker.
Now, we could spend a whole day talking about the Docker Engine and containerized applications. But today’s story is focused on the impact Docker had on Google’s team — and how it pushed a few Googlers into creating the open-source Kubernetes we use today.
Around 2013, Docker was the company that popularised container management. Seeing the rise of containers as a scalable and efficient way of managing massive workloads, several members of Google’s Borg Project decided to make some waves for good. Joe Beda, Brendan Burns, and Craig McLuckie looked at the popularity of Docker’s containers and saw a path forward for some of Borg’s more useful elements.
At this point, Borg was around a decade old. Over those years, the project had grown quite a bit. Google’s engineers learned a lot from the development and design of Borg and its successor, Omega. Of course, many team members had no idea of the kind of impact their work would have in the future. The few we mentioned earlier, however, did.
Those three Googlers made it their mission to create a project that would combine all the magnificent elements of Borg/Omega and Docker’s containers. The decision to make the entire thing open-source was a difficult one. At the time, Google’s cloud services were in their adolescence. This meant deploying a Google-exclusive container orchestration platform wasn't an option.
Even for Google’s CTO Urs Hölzle, the idea of open-sourcing “one of our most competitive advantages” seemed like an odd move. But even still, Hölzle recognised the importance of developing a usable and scalable containerized orchestration platform.
With the Borg/Omega project, Google cloud was able to do this internally, but to bridge the gap between internal and external needed the help of developers across the globe — and the only way to do this was to make the entire project open-source.
Thus, Kubernetes was born, and the basic components of Kubernetes architecture that we know today became part of the tech world. But don’t think that’s the end of the story. Since the introduction of Kubernetes v1.0.0 in July of 2015, we’ve only seen the Kubernetes cluster grow, and the future for the platform is brighter than ever.
No story is complete without some fun Easter eggs. The history of Kubernetes is certainly no exception. But keep in mind the team that helped guide the Borg into the Kubernetes of 2021 were tech-savvy rebels. As such, the fun elements of Kubernetes tend to lean on the slightly geeky side.
First is the codename of the Kubernetes project before we knew it as Kubernetes. Internally, as the team was mulling over how to approach open-sourcing the platform, the project went by the name Project Seven or Project Seven of Nine. This is an homage to the original name Borg, and by that, we mean it's another Star Trek reference. Seven of Nine was a member of the USS Voyager. The Borg captured her, and she was able to escape their assimilation — very fitting.
While the Star Trek naming convention petered off after around 2016, you can still see seven points on the Kubernetes logo, referencing the original name for the project. When the team finally introduced the world to Kubernetes, it felt that keeping with the nautical theming of Docker was more appropriate. That’s why it's called Kubernetes, which is Greek for helmsman.
While plenty of teams are still writing Kubernetes history, by now, you have an idea of all the hard work and brainpower that went into developing this one-of-a-kind container orchestration environment.
Even now, as thousands of companies are jumping on the Kubernetes bandwagon, implementing a Kubernetes software development database architecture can be difficult. Even with an introductory guide to Kubernetes, it can be a struggle to wrap your head around how to utilise Kubernetes.
We built Appvia’s Wayfinder to make Kubernetes simple for enterprise teams. We take the pain out of Kubernetes with an environment that anyone can use, without the need for high-powered teams of Certified Kubernetes Administrators.
To learn more about Wayfinder and how it can help your business grow, reach out to us today.
