To many developers, deploying an application to Kubernetes may feel like riding a wild horse. That experience will soon change as more high-level abstractions appear. Bryan Liles, Senior Staff Engineer at VMware, was kind to share with us his views on how to think about Kubernetes, where the next innovations will appear, and his latest project.
Bryan is an expert in software architecture with nearly 25 years of experience.
Key takeaways:
- Octant – a Kubernetes dashboard to better understand your clusters.
- Kubernetes is a platform for building platforms, not the endgame of app deployment experience.
- YAML is the new machine code.
- Where to expect new innovations and how the landscape will look in two years.
Listen to our entire conversation above, and check out my favorite parts in the episode highlights!
You can also get Semaphore Uncut on Apple Podcasts, Spotify, Google Podcasts, Stitcher, and more.
Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.
Highlights from this episode
Darko (00:02): Hello, and welcome to Semaphore Uncut, a podcast for developers about building great products. Today, I’m excited to welcome Bryan Liles. Bryan, thank you so much for joining us. Please go ahead and introduce yourself.
Bryan: I’m Bryan Liles. I am an engineer at VMware and I work in a group called Modern Applications where we basically just think about Kubernetes and cloud native applications and distributed systems all day long. I’ve been writing code for money since 1995, so I guess that puts me at 25 years this month, because I got my first job my freshman year out of college. So, it’d been 25 years ago this year. But I’ve been writing code since I’ve been wow, 11. And back in those days, and this would have been late nineties or late eighties, I coded out of magazines.
Octant – a human view into Kubernetes
Darko (04:01): One of the tools that you are working on is Octant. It would be great if you can introduce us to that too, and share what was the trigger point for starting it and what’s the stage right now?
Bryan: I worked at a company called Heptio founded by Joe Beda and Craig McLuckie, where I started working on this project called Ksonnet, which was a way of thinking about rethinking configuration for Kubernetes. And we approached it as a kind of a research project and realized that it’s a little bit difficult and it wasn’t giving our people, our users, what we think we should have had. So, what we were thinking about shuttering that project, or thinking of something new and what Joe B and I discussed was, “I have a Kubernetes cluster, what’s it doing?” Actually, even better: “What’s broken? Why is my workload not working?” And this is where Octant started out.
Octant is a Kubernetes dashboard. It runs in a browser and similarly you can run it on your desktop. And it allows you to dive into your one or more Kubernetes clusters, look in the namespaces, see how workloads work, but also what it can do is it can infer relationships between objects in your cluster.
While using Octant you’ll be able to see your cluster, the relationships of objects inside of your clusters. We’re growing it into making it a full fleshed environment where not only can you see what Kubernetes provides you, but there’s this concept of custom resource definitions, which are API extensions for Kubernetes, which means you can make the Kubernetes API do things that we didn’t think about. We could support those. This other concept of plugins, where we’re providing a view for deployment. And what if you wanted to provide another context specific view, or maybe a graph that you had from your data. We allow you to do that as well. So, Octant is a tool for humans using Kubernetes. I think it’s pretty exciting.
Darko (08:26): For our listeners we are going to share the link to the project that they can find on GitHub, and as far as I understood, they can just try it on their local development box. Right?
Bryan: Right, it runs on Linux, Mac, and Windows. And over the summer, we’re going to put in like a desktop client to make it run on your desktop natively. And then also thinking about running it in cluster. Cause people always ask me that. “Why can’t I run it in cluster?” And I tell them because it’s hard, but we’re going to get there.
Will Kubernetes become more accessible?
Darko (08:57): So, you have seen a better part of the history when it comes to programming and computer science in general. And with Kubernetes, what do you see as a next step in terms of making it more usable, more approachable for people who don’t have decades in programming experience?
Bryan: I think that we’ve done ourselves a disservice as a community, talking about Kubernetes as if it will solve all of our problems.
Kubernetes is a platform for building platforms. So, what Kubernetes will make it easy to do is to provide this abstraction over a set of computers, real or virtual, where now you can actually have applications that are bigger than one computer. Or you could have multiple applications bigger than one computer. And the neat part about that is that if you run multiple instances of these applications, you can now have some fault tolerance because if a node goes away, Kubernetes scheduler will ensure that there’re enough copies of it around.
We don’t look at Kubernetes as a deployment. We use it as a tool to get us to where we want. And if we look at Kubernetes that way, then it becomes a much more tenable, easy to understand solution, but what do we need to do?
There’s one big problem that we have right now. And actually, I won’t even say it’s a problem. It’s a challenge, it’s a roadblock. When people make fun of Kubernetes or they make light of Kubernetes, they always talk about YAML.
All of the software you write is not interpreted by your computer in the language you write it in. It’s machine code. So, if you’re on a Mac it’s x86, and then there’s an operating system on top of that. And what we’ve done is we’ve built up levels of abstraction. Think about YAML as the machine code. Now we should be able to have all these translation layers that run in the middle that actually extract over things we don’t care about.
Printing services is one example. When you create a service, and the service says it’s an internal cluster IP service, and it points to a selector. That’s all sorts of YAML there. We can actually infer that from our app. “Hey app, look at my deployment pod spec template. Pull a service out of there.” We know what the ports are. We know what the selector is, and we know what’s inside. We can generate that. And I can think of that for like horizontal pod scaling, auto scaler, things like Knative. I can think about it for basically anything. And what we need to do now is focus on that middling level.
Let’s create these abstractions for humans, rather than these abstractions for Kubernetes and, on the back end, we’re still talking deployments and we’re still talking services and whatever else, but on the front end, let’s talk about things that are closer to our app.
The future of Kubernetes looks bright
Darko (16:18): Would you maybe want to predict or guess how many years would we need to figure out what are those abstractions on top of Kubernetes?
Bryan: I think that we’re finally hitting the place this year, where multiple companies at the same time are actually really figuring this out for Kubernetes. So, this year, by the end of 2021, I think the landscape will look different.
A good example is when people think of installing things on their cluster, they think Helm. And I think that we’re moving past that and not saying that Helm is not a great product. I actually think it’s not a bad solution, but it’s not a Kubernetes centric solution.
And I think that now people are actually thinking, how do I not only get stuff on my clusters, but how do I get my team on the cluster? How do I get my enterprise on a cluster? And so, there’re things coming out of VMware this year. I think we’ve finally hit the point releases: .16, .17, .18, .19 coming up later this year, where we are not solving the foundational problems anymore.
There are more foundational problems to solve, but now we have just enough base where we can start building some really cool things on top of Kubernetes.
Darko (22:34): Brian, thank you so much for sharing all this with us and good luck with all your projects.
Bryan: Thank you for having me.
