Once you've written your first container-based application and have it running in Docker or Podman, you're ready to move to the next level. That means multiple applications—microservices—running within a managed environment. Kubernetes, an open source container orchestration platform, is just such an environment, and by far the most popular one at that. Let's consider it from a developer's perspective.
Run multiple containers on Kubernetes
Running a container with Docker or Podman is great, but it's only a start. To implement an entire system, you need several services (or microservices, if you will). Kubernetes can orchestrate the entire system in a namespace, giving you both isolation from other namespaces and a shared environment within a namespace. You can just plop your applications into your Kubernetes cluster and let it run. Well ... it might not be that simple, but that's not a bad generalization.
Kubernetes port management
Imagine you're running multiple services in Kubernetes, and those services use network ports for communications—a Web API or a database, for example. Kubernetes will automatically allow you to use the same port number for multiple services. This is fantastic for developers. You don't need to remember that "this API uses port 8080, this other one uses 8082" and so on. Instead, you simply assign a port and let Kubernetes worry about it. Eight applications that all use port 443? No problem.
Kubernetes names
Once you have those services running, Kubernetes helps make life easier for you by allowing you to reference any other service by the name you assign to it. You don't need to know IP addresses or some long, convoluted name. You named the service getcustomer? Well, then ... you reference it as getcustomer, no matter where it's running within Kubernetes. Even after that service scales up to several running instances, you don't need to concern yourself with that. Just call the service by its name; Kubernetes will do the load balancing.
Kubernetes Secrets
When dealing with sensitive information like passwords and connect strings in your code, Kubernetes once again makes life easy for the developer. When you establish a Secret in Kubernetes, you can assign an environment variable name to it. Then, in your code, you simply use the value of that environment variable as the value of the Secret.
So easy. So nice.
Kubernetes rolling updates
Kubernetes, out of the box, supports what's known as a rolling update. This means that you can start a new version of your application while the older version is running. Once the new version is ready, Kubernetes will automagically transfer traffic over to your new version.
As a developer, you might think this is more of a big deal for the operations side of things, but here's the thing: Rolling updates are great when you're developing code and desk testing. While you're working at your local PC and want to try the new version of your application, you simply move it to Kubernetes and let the rolling update handle it. No need to stop this, start that, change routing, etc., etc. As a developer, this makes life much easier. It seems like a trivial thing, but you'll get spoiled very quickly.
Kubernetes and dependencies
We're all too familiar with the old "It works on my PC" problem: You carefully craft an artisanal service that works perfectly on your workstation, and after you have gently deployed it to a server, it crashes, because one of the dependencies on the server is the wrong version. But you can't change that or another application might break. Cue frustration and complexity.
Or, you could build a container that holds all the dependencies you need and deploy it to Kubernetes. Done. No conflict, no frustration, reduced complexity. For a developer, this is wonderful.
Kubernetes YAML files
Yes, yes, we developers are all about source code. But what about using source code to deploy our applications? Is that a thing?
With Kubernetes, it is. Alongside your Java (or C# or Node.js or Python or...) code, you'll be creating one or more YAML files to define the objects and environment your application needs in Kubernetes.
But why should a developer care? Isn't this the realm of operations?
Well, it's good for a developer because it makes your development and desk testing completely repeatable and consistent. And when you're finished, you have code to turn over to the operations folks, who can tweak it, improve it, and get it ready for production. That same code is then available to you for any future work. It's a cycle, and it's helpful for everyone, and it has a name: DevOps.
Want more?
Reading is fine, but you can actually use Kubernetes for free by taking advantage of our free offering, the Developer Sandbox for Red Hat OpenShift. (Red Hat Openshift is a Kubernetes distribution focused on developer experience and application security that's platform agnostic.) We even have an activity that you can do to get started with Kubernetes.