Today’s DevOps teams develop and run their applications in containers. And for obvious reasons; containers are fast, easy to roll out, and very scalable. The use of containers has been growing enormously these last couple of years. Containers have been around though for quite some time. In fact, it was Google that started using containers almost 15 years ago.
That’s right: Google was one of the first that really made use of the power and capacity of container development at scale. And still does. Every search you enter into Google runs in a container. Why is that? Because a container consists of an entire runtime environment: an application, all its dependencies, libraries, and other binaries and configuration files needed to run it. This causes the application (in this case your search) to almost immediately start and run, no matter where it is hosted. That’s the reason why you can get millions of results returned within milliseconds.
Why Google developed Kubernetes
In the early mid-2000s, Google foresaw the explosive growth the Internet would make. That meant that they needed to be able to push these new applications as well as migrate data between different datacentres extremely fast. At that time, they couldn’t find a system that could help them with that. Being the developers they are, Google created Kubernetes to automate the deployment, scaling, and management of their applications in containers. So Google was able to move applications easily across clusters of hosts, independent of the cloud platform, bare metal solutions, or container technology that was already available and in use by Google, including Docker.
In other words: to deploy applications really quickly, orchestrated containers are the way to go. Especially to deploy related application parts in a sequence and spin a working application up much faster than with separated virtual machines. And as said, you can use them on any system, multi-cloud or bare metal, because the container includes its own operating system. If you run multiple containers together, they share the operating system kernel with each other. It makes them much lighter in size (tens of megabytes instead of gigabytes, which is not unusual with virtual machines).
Kubernetes is the tool that orchestrates all this. It is the only way a major company can be fast enough to keep up with the demand. Containers are also very useful if you have to scale up or down fast.
Docker really focuses on handling what it knows to do well; which is containerization.
Can I just use Docker and call it a day? Yes, sure. Docker is great as a container runtime and it gives you a great API service. But the limitation though is that Docker contains no orchestration toolset and is not agile enough for the fast-paced developing ICT world we are currently working in. Kubernetes really focuses on handling on what it knows to do well; which is orchestration.
So Kubernetes focuses on orchestrating applications, not individual containers;
- It enables faster development by simplifying steps in the CI/CD process;
- It enables increased reliability by ensuring all parts of an application chain;
- It delivers more computing (for less money).
So what does OpenStack bring to the table?
So Docker focuses on containerization and Kubernetes focuses on orchestration; so what does OpenStack bring to the table? As Kubernetes and Docker focus on what they know to do well, a lot of tasks in infrastructure management are not being taken care of in the combination. Everything crossed out in the picture below cannot be done (or is difficult) by Kubernetes alone.
On top of your Kubernetes environment, your CI/CD applications will use the orchestration of Kubernetes. But Kubernetes in its turn uses a provider service to provide infrastructure resources to the containers and application on top. Kubernetes provides you with what they call a cloud provider directory with a set of recourses that Kubernetes requires. But not the actual provider services such as Google Cloud Platform, AWS, Azure VMware, and OpenStack.
Kubernetes uses those providers for what they do well: deliver the infrastructure recourses such as virtual machines, load balancers, networks, and so on. All those things that are outside of what Kubernetes focuses on and is good at: this is the realm of the cloud providers.
So while Kubernetes empowers your application DevOps teams to easily orchestrate large and complex clouds of containers, you will still need a solution to provide those containers with a stable infrastructure. If you want to know more about containers, deployment, docker, Kubernetes, and OpenStack, please let us know or read more of our blogs.
