Nickolai Walker: [00:00:11] Hello, hello, thank you for joining us here in the studio, I am your host, Nikolai Walker, on the mic and in your ear. We are joined in studio by Jonathan LaCour and I’m going to throw this question over to Etienne and he’s going to say it a lot better than I possibly can. But I, like a great many people, have a question for you, which is what exactly the hell is Kubernetes? If you could help us clear that up, we’d greatly appreciate it. Etienne take it over.
Etienne de Bruin: [00:00:40] I’m a late bloomer when it comes to containerization and finally understanding what it does. You know, sometimes when you learn a new programming language and you’re like, I can do all the hello world examples and I get it, but I need to do something with it. Like when am I going to actually code something with this. And with containerization and Docker, it’s like, OK, I get it, I’ve run a little hello world instance and all that. But now, how am I deploying this? And I found one of the one of the very useful ways of doing it is through lambdas and sort of thinking about life that way. And so I’m a late bloomer to containerization and serverless. I still feel afraid to admit to people that I don’t really, really understand what Kubernetes is. And so I feel a little vulnerable in admitting that to you.
Jonathan LaCour: [00:01:45] But it is OK. I would say a significant percentage of the people who run Kubernetes don’t fully understand what Kubernetes is. But let me break it down for you in pretty simple terms. And I think it might be interesting to start with containers as a concept. So container’s have been around before Docker. But I think Docker is the thing that really caused containers to take off. And why is that the case? In your view, what was the thing that got people excited about Docker?
Etienne de Bruin: [00:02:20] Yeah, I don’t think people knew why they got excited about Docker. I think for me my initial thought was, wow, we don’t have to worry about dev environments anymore. There’s no worrying about different environments.
Jonathan LaCour: [00:02:37] You’re onto it. Right. So the the key innovation of Docker was finding a way to transform the typical engagement between developers and infrastructure and deployment and making it super simple and really designed to delight them. The thing that made Docker successful was it spoke to developers and their workflow. It works on my machine as a package and ship it to production. That’s what got people excited. So that’s containers in a nutshell to me. I can package something up in a way that I know it works and I can ship it around and I’ve got that mobility. Kubernetes is the logical endpoint of that where now I’m going to go through and I want to start breaking my application down into microcircuits. I’m going to break it out to smaller and smaller components then I can containerize those components. And then when you have a large scale system with many of these different micro services that all have to be orchestrated and communicate together, that turns out to be a very large challenge and a very big problem. So we solved one problem. We created a dozen new ones. And Kubernetes is designed to solve all of those problems. But the key thing about that is, like, how many people really have a scale at which they require something like Kubernetes, so Kubernetes brands themselves as a platform for deploying, managing, scaling containerized applications at scale, at massive scale. So it was born at Google. These are people who are not running little rinky dink workloads. And by the way, there’s nothing wrong with a rinky dink workload.
Etienne de Bruin: [00:05:48] So, for instance, if I just look at the single thread, you package up your container and you publish it to EKS, is that right?
Jonathan LaCour: [00:06:10] EKS is the elastic Kubernetes service. Thats AWS’ like we’re running Kubernetes for you at scale and you just push to it.
Etienne de Bruin: [00:06:17] So would Kubernetes then just be, instead of thinking of your app as a single docker instance, it is actually just a ton of them doing different things like in a micro services environment.
Jonathan LaCour: [00:06:31] Yeah. The long and short of it is, and I’ll caveat all this by saying I’m also not a Kubernetes expert. I know enough to be dangerous here and definitely encountered it a lot. But effectively, think about it this way. You’re defining independent services, right? And you’re grouping them together and you’re allowing the services to do things like discover each other. So you basically can create these pods and you create IP addresses for them and you can create DNS names for a series of these things and you could load balance them. It’s doing things like healing and scaling and the topology of your services and really providing you with all of that substrate. But frankly, it’s pretty boring when you really think about what it’s doing under the hood, its orchestration. It isn’t doing anything that is actually solving any problems for your end users. It’s purely designed to solve problems for you. I want to smoothly scale, deploy, heel, roll out a very large scale service that has many, many, many micro services that make it up.
Etienne de Bruin: [00:07:35] So is Kubernetes something that can also then be defined by something like a terraformed script?
Jonathan LaCour: [00:07:43] Oh, yeah. You can definitely use infrastructure as code to provision things and terraform, for example, actually is an infrastructure code provided that has a whole bunch of different capabilities to extend and plug in and add new capabilities. And so people have done a lot with Kubernetes.
Etienne de Bruin: [00:08:16] So that’s that’s helpful, thank you, I appreciate that. I feel this incompetence.
Jonathan LaCour: [00:08:25] Well, first of all, you’re not incompetent. The fact is that frankly, most people don’t need to know how Kubernetes works. The vast majority of people do not need to know, including CTOs. I think it’s a good idea to understand it because it very well could be a good fit for a workload that you encounter. But, you know, you are not in the minority when it comes to that level.
Etienne de Bruin: [00:08:52] So even if I am a small company, is it potentially best practice to start off with Kubernetes as a infrastructure or as a way to think about your deployment so that you are prepared and you’re just sort of growing, you’re not having to shift. Like what is the paradigm, the devops paradigm that is just plain good old best practice to kick anything off, that might feel like overkill in the beginning, but actually will serve you pretty quickly as you grow?
Jonathan LaCour: [00:09:28] Yeah, I think I do not think that it’s necessary to start with Kubernetes as a given at the beginning of a project. It might be the right choice, but in many times it’s not. I would say honestly, a lot of the same old way that we approach problems as technologists when it comes to application architecture are very, very similar now as they were before. It’s just that some of the atomic building blocks are a little bit different and that parts of them can be outsourced as well. So, you know, like we talk about the database layer, you used to have to think a lot more about the database layer than I think you do now, because you can do things like, I’m going to go ahead and I’m just going to plunk in RDS here or maybe I’m going to use Dinamo or whatever. Maybe not the best example, but, I think starting from a position of yes, I’m going to containerize, that’s totally appropriate. And if you’re starting from there, getting to Kubernetes is definitely not like you’re going to start over when you get to the endpoint. Building out an application with sane architecture around microservices with kind of discrete components that are walled off from one another and know what they’re responsible for.
Jonathan LaCour: [00:10:45] You can do that in a way with very simple atomic bits and pieces and building blocks with containers. And then later you can adopt Kubernetes as you start to want to glue them together and scale them and all of that. But you don’t necessarily have to. And you brought up LAMDA earlier. I think that people are often going to have better luck starting off from a position like that. Right. And then using something like LAMDA or using ECS, even a more simple container service that AWS provides. Like Fargate, which is kind of, quote unquote, serverless on that front. And you can get really, really far with that and the cognitive load is significantly lower than it would be if, like, now I have to understand Kubernetes. That’s a lot. Most people don’t need it. Overkill for most people.
Etienne de Bruin: [00:11:36] Yeah, in the end, I like what you said earlier, which was delighting your engineers. I think there are few things as demoralizing as when you’re onboarding someone and you just cannot get the local dev environments to work or solving a problem and then having it work in one environment and not another. So I love how that seeing Docker as that solution to the developer sort of struggle I think is is a great way to look at that.
Nickolai Walker: [00:12:27] Thanks again for joining us here in the CTO studio and thank you to our guest, Jonathan LaCour, who is the CTO at Mission. If you would, please, since you are enjoying these podcast, go and subscribe to them in iTunes. Go and check out Missioncloud.com and check out 7CTOs.com. And we will see you again next time with another interview with Jonathan LaCour.