We're kicking off the new year with Paul Czarkowski talking all about kubernetes and…soup.
VMware finalizes Pivotal acquisition, on Dec 30th, 2019.
Speaking of, this is a good overview of Project Pacific.
Forrester's Pivotal Cloud Foundry Total Economic Impact report is out, a new edition since last time: "Based on customer interviews, Forrester calculated the ROI of Pivotal Platform to be 142%"
First, we discuss Paul's take on drinking broth, especially bone broth. After hearing Richard's Fork Rule of Thumb for Stew Detection, we jump right into the middle of a conversation about containers and kubernetes. The primary benefits of containers are the ease of building and sharing software, Paul says. And once you stick with putting containers in VMs, you can get the security and performance benefits of VMs without having to re-invent them. We discuss previous methods of packaging up code comparing them to how much easier containers are to build. While "bin packing" is a fun riddle to solve, Paul explains that it's maybe not as big of a deal in container stuff as it may seem.
I then try to give a big picture idea of what kubernetes does, namely, coordinating the install and running of large-scale, container-based software. To try and flesh it out more, we discuss what kubernetes doesn't do. Here, we end up getting to an interesting rule of thumb: if you want to change the behavior of your app, that's not kubernetes, it's something on-top of it.
We then get into a discussion about architecting applications for running in kubernetes, like dividing up components into pods, thinking through the network routing and load balancing, and so on. Paul gives a good overview of what kubernetes takes care of when it comes to running your applications. As Richard summarizes, there's two main concerns: container placement and handling network connectivity.
Richard then asks: are developers supposed to use kubernetes directly? You'll probably have some operations people to handle that, Paul says, especially at larger, existing organizations. This prompts Coté to ask one of his recurring questions on kubernetes: what's the concept of "kubernetes is a platform for platforms" mean? The goal is to get as much self-service into your appdev platform as possible, for example, for developers requesting resources, deploying code, and even managing it in production. You want them, as always, being productive as possible so they can focus on writing the application instead of doing all the configuration and release management around it. DevOps dreams!
Then we sway over to the programming side, where Coté asks what "cloud native programming" is. While "12 factor" apps were a start do making cloud native apps, we've come a long way from there with kubernetes that allows for more intimate relationships with storage and ports.
Paul then goes over areas that kubernetes will be focus on in the near future: multi-cluster management, paying more attention to building and storing images.
As you'd expect, it's utensil-full episode!
"You're either building a platform, or you are the platform": a platform made out of meat, or a platform made out of kubernetes. -Paul
"If you're modifying how your application works, it probably should not be in the kubernetes layer" - Coté
"The 12 factors, they're always good practice, but they're not as important on kubernetes as they are on a PaaS-like system. And that gives you the benefit of: if you really want to, you can run any old garbage pretty successfully on kubernetes " -Paul
"Let the one that everyone wants to use win" -Coté
About the AuthorMore Content by Michael Coté