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. Oh, thank you for inviting me. Yeah, please go ahead and introduce yourself. So 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 s
ince 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 had been 25 years ago this year, but I've been writing code since I've been about 11. And back in those days, and this would have been late 90s or late 80s, I coded out of magazines. So Dr. Stop's journals, white magazine. And then when Lending's Journal came around, I wasn't there too. But I like code because where I grew up, it wasn't bad, but it wasn't great. And my pa
rents always wanted something better for me. So they bought me a computer and they said, you can use it if you understand it. So what I ended up doing was just learning how to code on my Tandy Color Computer 3, which is the same thing as a Radio Shack TRS-80. And then they bought me an Intel PC. It was an 88. I had a turbo button on it. And it was a Tandy 1000 TL. I love that computer. And I put everything on it. And in all these years, I've touched tens of languages, so many operating systems.
And really, I'm just happy that I'm able to do what I like, which is computers. Great, great. It's like an inspiration for a lot of aspiring developers to hear those how the things in a career start long ago. It's something that they have never heard of. Right. And interesting story is, so I learned C just because my dad worked at a military base and they wrote things in C. So he brought home manuals. But I used C when Linux first came out, they had sound card support because we had cards in our
computers to do sound at that time. And it didn't work with this particular sound blaster card that I had. So I cracked it open, and I went through the code. And over a couple of weeks, I was able to get that sound card working by writing a device driver. And at that point, it's when it all clicked for me that with code comes so much power and so much ability. That's pretty hardcore. Yeah, I used to study harder, although I'm not, I'm not working with that. But yeah, and doing that on your own,
that's even yeah, quite impressive. Yeah, I think I was 16. That's the worst I was in high school. And this is interesting. And this is something I like to leave with people. I always just thought that you were supposed to solve problems with code. So you would have a hard problem, you would pick your language, and you would solve the problem. So it's interesting now how this younger generation, this next generation looks at it, where things are hard. And people are, they complain a little bit,
I look at it as well. It's hard. It's a challenge. Let's go fix it. And it's carried me well over the past couple of decades. Yeah, yeah, we don't go into direction how younger generations are spoiled. And they only want high level languages. Okay, great. Hey, everyone. Semaphore has published an open source book called CI/CD with Docker and Kubernetes. It combines just the right amount of best practices and practical advice for shipping cloud native apps. Download your free copy today at semap
horeci.com. One of the tools that you are working on is Octant. It would be great if you can introduce us to that tool and share maybe what was the triggering point for starting it and was a stage right now. Right. So it's actually pretty simple. I worked at a company called Heptio. And for those of you all who do not know what Heptio is, it was founded by Joe Bida and Craig McLucky. And those two gentlemen are two of the three people who founded Kubernetes. And you all can't see me, but I'm air
coding now founded because Kubernetes, it may have been started by those three, but there was a lot of early people at Google who were helping on. I met Joe a few years back. And he said, come work with me. And I said, no way. I'm not working at startup ever again. That's silly. And over a year, we just talked and things happened. And I ended up there working on this project called case on it, which was a way of thinking about rethinking configuration for Kubernetes. And we approached it as a k
ind of a research project and realized that it was a little bit difficult. And it wasn't giving our people, our users, what we think we should have had. So when we were thinking about shuttering that project, we're thinking of something new. And what Joe Bida and I discussed was, well, 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 often started out. So what often is today is it's a Kubernetes dashboard that r
uns in a browser and soon new running your desktop. And what it allows you to do is 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. So a good example would be, and I'm going to make this as simple as possible to make it inclusive as possible is Kubernetes has this idea of workloads, something you're running an application, one or more application, combine it t
ogether, call a workload. And one type of workload is a deployment. And what a deployment allows you to do is scale your workloads. So you can run one instance, you can run 10 instances. And inside of the deployment, there's this thing called a replica set. And replica set basically manages versions. You can do a blue green. So you can move from version one to version two. And inside of replica set are pods. And pods are groups of containers. And the containers actually run your application. So
that's just complex right there. We have deployments, we have replica sets, we have pods. And then if you want someone to actually be able to get to your application, maybe you create something called a service. And then maybe if you want it to be hooked up outside of your cluster, you create an ingress. Now you have an ingress, a service, a pod, a replica set, and deployment. And something doesn't work. What doesn't work? Well, what do you do with Kubernetes? There's a command line tool that's
kubectl, kubectl, depends on how you want to call it. You can use that tool and you can do kubectl get, kubectl describe. Well, what are you getting? What are you describing? Look at some logs. So that's a problem. But with just simple heuristics, we can actually determine. I know if your ingress is invalid because there's no host. I know if your service is invalid because there's no endpoints. I know if your replica set is invalid because there's an available number. And if that available numbe
r is greater than zero, and I don't have that many pods, I have a problem. I know if my deployment is invalid because I can look at how many replica sets I think I should have. And this is actually the best example of computers doing what computers should do, which is the hard stuff and let people think about the abstract stuff. So that's what Octant does. It allows you to see your cluster, see the relationships of objects inside your clusters. And we're growing it into making it a full-fledged
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 can support those. There's 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 to su
mmarize, what Octant is, it's a tool for humans using Kubernetes. I think it's pretty exciting. And it's a good tagline. For our listeners, we are going to share the link to the project that you can find on GitHub. And as far as I understand, they can just run it on their local development box, right? Right. It runs on Linux, Mac, and Windows. And over the summer, we're going to put in a desktop client to make it run on your desktop natively. And then also thinking about running it in cluster, b
ecause people always ask me that, like, why can't I run it in cluster? And I tell them because it's hard. But we're going to get there. Great. Great. One other topic that I wanted to ask you about and be chatted a bit, prep part, is generally the Kubernetes and usability around it. And it's great what you shared about how you started and all the things that you went through from writing a device driver through all the Linux times and all those languages and so on. 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 and doing things? But maybe just three years on a career, I'm entering my job and I need to deploy to Kubernetes. There are a lot of things to understand and figure out. So yeah, I talked enough. Please share what you think. So I think that we've done ourselves a disse
rvice as a community talking about Kubernetes as if it will solve all of our problems. No, no, it won't. I talked about this at KubeCon, San Diego last year at the end of my talk and one of my keynotes, where we need to look at Kubernetes like we looked at Linux. We had Linux for all these years and it battled with Microsoft and then battled to get into the enterprise and for all intents and purposes it won. But we don't think about deploying to Linux these days. We just assumed that it's there
and we use the Linux ABI. So we use the Linux programming interface to be able to do things without having to worry about hardware all the time. Now we can take that same thought and we can abstract that to Kubernetes. Kubernetes will not solve your 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 compu
ter or you can 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's enough copies of it around. So we don't look at Kubernetes as a deployment. We use it as a tool to get us to where we want, which is basically I have all this compute networking and storage and I want to make it available to all
these apps. 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 wouldn'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. They say, oh, the YAML is hard. And guess what? We were talking earlier about Istio. And Istio was a whole bunch of differen
t binaries with its own set of configurations. And now it's like one massive thing, which is probably good for them. But then there's another project out there called Knative, which is serverless, like a serverless backend, and not just serving, but eventing and messaging as well for Kubernetes. And you realize there's all these parts to do serverless with Knative is a lot of YAML. And if you want to configure certs from Let's Encrypt with cert manager, more YAML. And what we need to do is what
we did in every single other case. Hey, I'm going to take a quick break here and tell you that Semaphore has a new book out called CI/CD with Docker and Kubernetes. If you are looking to deploy cloud native apps, it's going to show you the most productive way of doing that. And the best of all, it's free. Download your free copy today at semaphoreci.com. Spoiler alert, 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. And what I talked about in my talk is about the Kubernetes ecosystem can learn from the LLVM project that was for compilers. And really what that comes down to is for years, when GCC first came out, which is the GNU C compiler, you had to say where it was going to spit out. Is it going to spit out a mock binary for running on an Apple? Is it going to spit out a
MIPS binary? Is it going to spit out an Intel 386 or x64? And we had to think about that. And then every single time we put another language, so we could go to C to C++ to languages like R or Lua or any of these other languages, what we realized is that we're duplicating this effort. At a certain point, we should be able to have an abstraction and we should be able to take that abstraction and then apply optimizations to it and then run it on the platform. And that's what LLVM did. It allowed u
s to create these front ends that would spit out this byte code that could then be transferred to your machines. And the example that I gave was now what we need to think about that in the Kubernetes. 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 abstract over things we don't care about. So creating services is one example. When you create a service and the service says it's an internal cluster IP service an
d 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 it's inside. We can generate that. And I can think of that for horizontal pod scaling, auto scaler. I can think about it for things like K-native. I can think about it for basically anything. And what we need to do now is focus on that meddling level.
Let's create these abstractions for humans rather than these abstractions for Kubernetes. And yeah, 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. And I think the spring project, and I do bring them up because they're my coworkers now, but the way that they're thinking about annotating their spring apps and then it generating what it needs to run in a cluster is more i
nteresting than just writing YAML itself. Now, I'll add just one more thing. We were talking about Istio. So as my app, I don't care if I'm using Istio and Istio does its own thing, injects sidecars, makes communication between my workloads work. You know what? I just need to know that it's there or I actually be able to at runtime say, hey, I'm using Istio and it gets injected in and I don't have to think about it as an application developer. It's like all the things that we've thought about in
development land to make our lives easier. So the reason people love Ruby is because Ruby was made for developers. It was pretty much objects everywhere. And it was expressive enough that you could write DSLs that you can use a configuration language. Python is another case. It's expressive enough that people can use it for data scientists to use it. And they don't consider themselves developers. We need that level of abstraction for Kubernetes. Yeah, I couldn't agree more. I have to put myself
in that category of whining about having too many lines of YAML. And you mentioned Linux and how it evolved. And we know the timeline is roughly for Linux, maybe for Ruby to get adopted for Docker also it took a while. Yeah, would you maybe like want to like predict or guess how many years would we need to figure out what are those abstractions on top of Kubernetes that we need those hard level things that we don't have to write assembler, let's say. So this year is a little bit weird because o
f the pandemic and all, but I think this year is actually the beginning where I'm now seeing people are solving this problem well. So a good example would be different ideas from this is company called Upbound.io. And they make this thing called crossplane. And what crossplane allows you to do is create objects in your Kubernetes cluster that then go out and create cloud resources. This is just a neatest concept. So if I'm using AWS, I can create this RDS construct in my cluster. And a few minut
es later, I have RDS spun up on Amazon and then access inside of my cluster. I think this year is going to be pivotal for those kinds of actions. We went down this road, there was this thing called open service broker API, OSB API. And what it allowed us to do was to say that I have computing stuff running over here, and I have my computer stuff, and then I have my services run over here. How do I connect those up? How do I know where it is? How do I know what my authentication is? 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 actually the landscape will look different. And another good example is when people think of installing things on their cluster, they think Helm. And I think that we're moving past that. 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. I
t's a Helm 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 the cluster? And so there's things coming out of VMware this year. I've seen some good things coming out of Red Hat this year. And Microsoft is continuing to do their work with all their Rust stuff on Kubernetes. They're Crustlet, I think that's what they're calling it, which is WASM running inside of Kubernetes
in kind of like a serverless fashion. That's neat stuff. I think we've finally hit the point where the backend of Kubernetes, so 1.16, 1.17, 1.18, where we are now with the 1.19 release coming up later this year, we are finally hitting a point where we are not solving the foundational problems anymore. Yes, there's 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. Yeah, you have a great insight into co
mmunities. Great to hear that. Because yeah, once the foundations are shaky, it's hard to like, get the courage to start building something and things below you are going to change. Correct, correct. Okay, great. And something that I can do, but our listeners will not be able to, I can see your bookshelf behind you. And do I see there are like art of computer programming? You do see the art of computer programming. So I have read most of the first one. So I've known about it for a long time and
I've caught some snippets online. This is one of the best parts about being an adult. Once you get to your career, your career gets to a certain level in tech, you can start affording things. So I bought that and I'm slowly going through it. And it's just neat having those words in a hardbound copy. And then actually what I'm reading right now, and you people can't see it, is this book called The Art of Doing Science and Engineering, Learning to Learn. And it's hardbound. I was not a big hardbou
nd book reader, but now that I'm older, I'm loving all these hardbound books. One of my favorite things. Yeah, great, great. I remember like at the university, I stumbled into that book online. And I asked my, you know, professor, he was like, introduction course, I asked about that book, all the volumes and no, no, no, no, stay away from it for the next like 10 years. No, no, no, it's not light reading. Even I, you know, I've been doing this for a long time. I can't read it from beginning to en
d. I have to read it and then think about it. Yeah, it's a different kind of book. Yeah, it is definitely a different type of something interesting is that we think about computer science and we think about it as like programming. Computer science is not programming. It's just something we happen to do. But this idea of organizing or research around data and algorithms is a big topic. Like we don't think about things like sort, or we just call sort using go, you sort got sort, using Ruby sort, P
ython sort, but we don't think about, well, what algorithm is it using? And we don't think about, well, why is it using that algorithm? I like these books because they talk about the algorithms and why these algorithms are good. And the tradeoffs between other algorithms. So I do like that. Yeah, right. I guess we will also not think about certain things in Kubernetes in the way that we don't think if the sort is, you know, very efficient or it's not efficient. We don't even know how it works. M
ost of us. That's a good point. We don't need to know if the foundation is solid, I don't need to know how the bin packing algorithm for pod organization works in a Kubernetes cluster. I don't need to worry about the consensus protocols required to have the distributed store that backs all the Kubernetes objects. That just works. And I could think about other problems. And that's what we should be doing just in general as your developer. That's your job. Your job is to make something that is dif
ficult, complex, or cumbersome easy for your users. And it depends on where you're going to stack. So I'm an infra engineer. I work on Kubernetes. And then I look at how applications interact with Kubernetes. But other people are writing apps that just want a platform. And you're making it easier for your customers. So it's all just a different level of abstraction. But it's all about supporting the people who use your software. Yeah, couldn't agree more. We continue where someone else talks. So
Brian, thank you so much for sharing all this with us. And yeah, good luck with all the projects. Oh, thank you for having me.
Comments