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-2000’s, 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 migrating 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 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 quick, 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 focusses on handling on 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 tool set and is not agile enough for the fast paced developing ICT world we are currently working in. Kubernetes really focusses on handling on what it knows to do well; which is orchestration.
So Kubernetes focusses 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 compute (for less money).
So what does OpenStack bring to the table?
So Docker focusses on containerization and Kubernetes focusses 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 is not being taking 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 focusses 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.