#62: We welcome back Ádám Sándor to continue our discussion about Kubernetes, Serverless and developer productivity.
If you like our podcast, please consider rating and reviewing our show! Click here, scroll to the bottom, tap to rate with five stars, and select “Write a Review.” Then be sure to let us know what you liked most about the episode!
Also, if you haven’t done so already, subscribe to the podcast. We're adding a bunch of bonus episodes to the feed and, if you’re not subscribed, there’s a good chance you’ll miss out. Subscribe now!
Viktor Farcic is a member of the Google Developer Experts and Docker Captains groups, and published author.
His big passions are DevOps, Containers, Kubernetes, Microservices, Continuous Integration, Delivery and Deployment (CI/CD) and Test-Driven Development (TDD).
He often speaks at community gatherings and conferences (latest can be found here).
His random thoughts and tutorials can be found in his blog TechnologyConversations.com.
Ádám Sándor 0:00
Cloud native transformation is not about installing Kubernetes. It's all the processes, the company culture, everything needs to be impacted by it. But there is no avoiding like mentioning Kubernetes in these discussions. It's always like the base technology layer for that transformation.
Darin Pope 0:19
This is DevOps Paradox Episode Number 62. Kubernetes is dead. Long live Serverless
Darin Pope 0:29
Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darin and Viktor, pretend we know what we're talking about. Most of the time, we mask our ignorance by putting the word DevOps everywhere we can, and mix it with random buzzwords like Kubernetes, Serverless, CI/CD, team productivity, islands of happiness, and other fancy expressions that make us sound like we know what we're doing. Occasionally, we invite guests who do know something, but we do not do that often since they might make us look incompetent. The truth is out there and there is no way we are going to find it. PS... it's Darin reading this text and feeling embarrassed that Viktor made me do it. Here are your hosts, Darin Pope and Viktor Farcic.
Darin Pope 1:22
Hey, Viktor, how's it going today?
Viktor Farcic 1:24
Darin Pope 1:25
Viktor Farcic 1:26
beautiful morning or noon. I don't know what it is.
Darin Pope 1:30
At the point that we're recording right now it is 6:30am where I am. It's 12:30 where Viktor is. And I've been up for about 20 minutes. And he said he's been up for 15.
Viktor Farcic 1:46
Darin Pope 1:49
He's living in rock star life.
Viktor Farcic 1:51
We are synchronized. We wake up and go to sleep at more or less the same time even though we are in kind of seven hours apart.
Darin Pope 1:59
Viktor Farcic 1:59
Darin Pope 2:01
It's six, seven, at this point in, in the timeline of the world, it's about the same. We have our first repeat guest, I believe. I didn't actually do the math. Some I'm officially gonna say this is our first repeat guest. And well maybe he's back to beat us up this time. Ádám, welcome back.
Ádám Sándor 2:25
Well, thank you guys. I'm honored to be the first repeat guest.
Darin Pope 2:30
I think people get confused when they say they're honored.
Viktor Farcic 2:32
Exactly, exactly. You're honored when a queen makes you a knight. Right. That's when your honored.
Ádám Sándor 2:39
Isn't this kind of the same?
Viktor Farcic 2:42
Darin Pope 2:43
no. No that yet yeah. The answer's no. So and, by the way, Ádám, I didn't tell you this. This ought to be fun. So this is part two of a three parter. So we are building a trilogy around Ádám. This this is the good trilogy, like Star Wars four, five and six, not one, two and three. There will be no Jar Jar Binks here. So what's going to happen? See, I should have talked to you about this. So, today if you're listening today's one day episodes being released. Today is July July 1. Adam is going to be on with us on July 3 on the live stream, aren't you Ádám?
Ádám Sándor 3:30
Darin Pope 3:32
Okay, good. We'll talk details later. And if he's not, please don't please don't hold it against Adam.
Viktor Farcic 3:38
No, hold it against them. You need to have a leverage against him.
Darin Pope 3:42
I'm sorry. We should. We should have talked about this. I had it all planned out and I forgot to talk to anybody about it. That's my that's my fault.
Viktor Farcic 3:50
If it's any consolation didn't did tell me but I forgot almost immediately afterwards.
Darin Pope 3:55
Did I tell you? Yes. Oh my gosh. This is the problem when I don't go to bed. by nine o'clock at night, I don't remember anything. The topic that y'all were talking about. And this is how we're going to title it today. Kubernetes is dead.
Viktor Farcic 4:15
Go explained why do you think so Ádám.
Ádám Sándor 4:21
Why do I think so?
Viktor Farcic 4:23
Darin Pope 4:24
I have opinions on this too. I have opinions
Ádám Sándor 4:26
Really? Come on go, go ahead Darin.
Darin Pope 4:28
Do you want me to go first?
Ádám Sándor 4:29
Darin Pope 4:30
All right. So my opinion is Kubernetes is dead. Because the people, many people that are running Kubernetes. And let's say let's finish it. finish the sentence. Kubernetes is dead on arrival. Because people are taking it. It's like, Oh, this is yet just another application I need to run. And they don't understand what they have and how much work it's going to take to actually run and operate a Kubernetes cluster.
Viktor Farcic 5:05
I would, I would rephrase it a bit and say that what I would really like to say is that I believe that Kubernetes will become irrelevant, not part of discussions, just like hypervisor is today, right? Kind of, I think that we are slowly going towards place where actually there is there is Kubernetes somewhere, right, but you're not really even using it directly anymore. Similar, like either, like, if you go to Lambda. And I'm not suggesting that anybody should use Lambda, that's a separate subject, but there is some kind of orchestrator behind it. Right? But you don't care about that anymore. And I think that that's the future, kind of that it becomes an irrelevant implementation detail that most people don't care about.
Ádám Sándor 5:55
Okay, so that's two very different statements to for me to disagree with.
Viktor Farcic 6:02
I wanted to get you out of your comfort zone.
Ádám Sándor 6:06
Yeah. Would you say Darin that basically people just underestimate the complexity of Kubernetes. I'm pretty sure that's the case in in many cases, but I don't think that makes it dead in any sense of the word. So for me, the strongest indicator that Kubernetes is like, is [unintellgible]. But when people realize that Kubernetes is is maybe too difficult and whatever, that's by the time they already bet their company on it, so it's there. It's definitely not dead. It's just more difficult than anticipated. And what Viktor says, I kinda agree with it, but just not in the like present tense. So Kubernetes will be dead someday become commodity, but we are far away from that.
Viktor Farcic 7:01
What is far in your case?
Ádám Sándor 7:03
Let's say five years? Well, there is several things like one is we still don't have any kind of platform to wrap Kubernetes into, right that we talked about last time, there is nothing really that we that would be a widely used platform where it just hides away Kubernetes and people just like to use that thing and don't care about Kubernetes underneath. That's one thing. And the other is when I'm talking to clients, companies still Kubernetes is mentioned in every discussion. Like anything like cloud native transformation, and we at Container Solutions are really all about like, okay, cloud native transformation is not about installing Kubernetes it's, it's all the processes, the company culture, everything needs to be impacted by it. But there is no avoiding like mentioning Kubernetes in these discussions. It's always like the base technology layer for that transformation.
Viktor Farcic 8:01
Yeah, I agree. I think what you just said makes a lot of sense in five years since sounds like a reasonable kind of timeframe.
Ádám Sándor 8:10
It's a wild guess. So like, of course,
Viktor Farcic 8:13
everybody's guessing in this industry, but yeah, I mean, I did. And I'm almost kind of embarrassed that I didn't dive into those things earlier. But now that I've spent some considerable time with, with what's the name, Cloud Run and Azure Containers, I think or something like that. It's, it's amazing, kind of, I love it. It's so easy to use. It's so beautiful. Unusable for for larger companies, without a doubt, but kind of that's direction. I became a believer in those things now.
Ádám Sándor 8:54
You mean the thingy that just runs containers without being Kubernetes. Basically, we just like you give it a container and it starts it up.
Viktor Farcic 9:02
Yes. Basically, like, the one I like the most is Cloud Run from Google. Because it is Knative, you know what it is? It's even open source, right? It's just that you either tell it, this is my image, or you tell it this is my yaml, which is kind of Knative yaml is like 20 lines altogether. Choose your level of complexity, both levels of complexity are fairly not complex, right?
Ádám Sándor 9:28
Viktor Farcic 9:28
And just kind of Here you go. Here you go. Kind of. Don't bother me, please. And if let's say on prem as well. OpenShift will almost certainly offer something like that, or whomever is the player right in on prem or cloud. It's similar to what we were talking last time about, you know, I think that I was mentioning Flagger how it simplifies some things for the end user, not for the administrator not for the sysadmin but for the end user. Similar thing.
Ádám Sándor 10:01
Yeah, Knative is definitely a interesting abstraction on top of Kubernetes. The most interesting thing for me about Knative is it will be completely I love that, that something like Cloud Run actually uses open source under the hood and you can understand how the whole thing works and like take it apart into components. That is great. But I read on Twitter some time ago, really good, like rebuke to call these Knative and these tools from somebody from AWS, of course. But he made a good point that it is very, very expensive to run these tools, not at scale, basically. So the problem is when you're when this tool is tied into Kubernetes Kubernetes is already not great to like to for massive scale. All big companies ended up with 10s or sometimes hundreds of Kubernetes clusters. Now Knative can't bridge those clusters. So in the end it it doesn't really can't really employ like scale efficiencies in the way how Lambda can.
Viktor Farcic 11:11
Yeah. But efficiency in terms of resources that you need to use?
Ádám Sándor 11:18
Yep. So like you actually have to manage like multiple control planes to be able to run in the end mode that many functions on the same cluster.
Viktor Farcic 11:26
Yes, but this is where where I kind of disagree with the mostly because it comes from AWS, because in to run AWS Fargate containers, right, which is equivalent of Knative, let's say in Google, similar, right. You need to create a cluster. You literally need to create a cluster. So and if you create a cluster for something that you will not run at scale, its just silly.
Ádám Sándor 11:57
Yeah, absolutely. Like Fargate is weird.
Viktor Farcic 12:00
Exactly. So you need a cluster even if you're gonna run equivalent of one function, but this time is it's a container
Ádám Sándor 12:07
Why would you compare Fargate to Knative? Wouldn't Knative compare better to Lambda? Fargate is running your long running process. Knative isn't.
Viktor Farcic 12:19
Knative is yes, so it scales down if there are no requests, but it's not like Lambda one one instance is one request, right? So one instance will handle, let's say, hundred requests, concurrent requests. And as long as the requests do not fall to zero, for for some period of time, it will always be running. Right. So it's not really like Lambda. And I like to compare it because both of them input in both cases is a container. Right? In case of Lambda. I think that Lambda is closer to I think they call it Google function or something like that. Right? Yeah, give me code. This is giving me a container. Oh, container image.
Ádám Sándor 13:01
Yeah, it's true that the model how you supply your logic is different. But on the other hand, the more in Fargate you still care about your process running. You know it's going to be one or you know, it's going to be two. In Knative and Lambda you don't care about how many instances are really running. Knative might implement it differently than Lambda. But you as the user don't care about it. So it's still more the Function as a Service model even though you Yes, you define your function as a Docker image.
Viktor Farcic 13:36
Yes, its a mixture of both and none of them actually now that I think about
Ádám Sándor 13:41
yeah kinda but so the important thing is that like that, if you want to, let's say you would want to use like Function as a Service are like really the next thing
Viktor Farcic 13:51
Absolutely not. I hate Function as a Service. Because function is in my in my context, my world function is too small of something to be used on a considerable level.
Ádám Sándor 14:07
I would like let's say maybe if we how about we redefine functions not to like something a, which is a small function like really like the math style and whatever. But more like the operational model where your code where you don't manage whether your code is running, not running whatever, it can run 100 instances so that the management platform is not like Kubernetes, where you still care about how many instances of something is running. But the platform manages all your instances or scales down to zero and does whatever the hell it wants to do with it. In that sense, I think maybe actually the the FaaS model is, could be the thing that like hides away the Kubernetes because it is really something which you don't really want to care about this, how many instances you're running.
Viktor Farcic 14:57
I mean, you care about it, but you don't wanna do it yourself.
Ádám Sándor 15:01
And that's where the argument from this AWS person comes in to a FaaS would be the future, then you really need those economies of scale because you don't want to run like 100 Knative control planes in your company, as opposed to, like, you know, like, because if you would really run, let's say something like Knative and OpenShift on an on premise platform, you'd have to manage all those Knative and even if you run it in Google, and Google does it for you. Still, there are many, many control planes. So there is a problem with efficiency here.
Viktor Farcic 15:38
But wait. That would assume that you would assign a control plane for each shall we call it function for each Knative instance?
Ádám Sándor 15:49
Yeah, let's say Knative per cluster, right? And you and you always end up with many clusters in Kubernetes land, so that would mean many Knatives.
Viktor Farcic 15:58
That would be that's true. But cannot even. Let's say you sit in a company, let's say it's my Kubernetes cluster, right? One, one or thousand clusters. Why would I not run? Let's say that they have 100 applications defined as Knative, maybe I have thousand apps, but we ignoring them, right? Why wouldn't I run those hundred Knative applications in a single cluster? Why? Why would I have 100 clusters?
Ádám Sándor 16:24
There are many reasons why people really one there is reality where people do end up with many clusters. The good reasons are you can't run Kubernetes over different regions. So just different data centers. If you have like two data, if it's on premise, you have two data centers or just two regions in a cloud provider if you already have to split then there is the prod/non-prod. So Kubernetes is not really trustable enough to like not some that some test workload couldn't take down your cluster. So this this already starts like the clusters start proliferating basically.
Viktor Farcic 17:03
I agree with all that. But let me then better define example. You have two cases, hundred applications. I'm throwing an arbitrary number. 100 applications, normal application, I don't know, Deployment, StatefulSet. It's in Kubernetes. Right? running in a single cluster. There are other clusters, other applications. But imagine this scenario, right?
Ádám Sándor 17:25
Viktor Farcic 17:25
And now, 100 of those same applications when applicable running as Knative? Would you have that scenario as Knative in multiple clusters, when a single cluster would fit your scenario for normal applications? So kind of, if you will transform whatever you have in one cluster from deployment statefulsets into Knatives, would you use still the same cluster or or 100 clusters?
Ádám Sándor 17:56
I don't think it is. I don't think the fact that I will be running things as Knative would really change how many clusters do I need.
Viktor Farcic 18:04
Exactly. And you do gain something. So it's not that that now becomes more expensive.
Ádám Sándor 18:10
Oh, yeah. Okay, it does, because now I'm running many, many Knative control planes that I have to maintain and make sure they work.
Viktor Farcic 18:20
It's one in that scenario, right? I mean, there is one there is one Knative CRD, let's say or multiple CRDs. It's still one Kubernetes. It's still one Kubernetes control plane. It's still the same cluster. You just changed the definitions from StatefulSet to deploy a deployment
Ádám Sándor 18:40
as in a single cluster scenario. It's It's fine. Yeah.
Viktor Farcic 18:46
Or let's say that you had five clusters and they've converted applications in those five clusters to be Knative. Still, it still stays continues being five clusters. You will not increase the number of clusters.
Ádám Sándor 18:58
No, no, but now you have five Knative control planes.
Viktor Farcic 19:02
Yes. And you still have five, but you get some different scaling. Let's say I'm not even gonna, I'm not gonna say better scaling because you can do the same scaling as Knative yourself, you just not done by you. So I don't buy that argument right?
Ádám Sándor 19:18
I'm not buying it. I just don't know enough to know whether this is really a problem or not. Maybe actually, nobody knows enough right now, because maybe nobody has tested Knative in such like, seriously large deployments where you will try to really mimic Lambda with it. But But I can see it as a potential serious problem because of the fact how Kubernetes works, because this is already defined by the fact that how Kubernetes works, you end up with many Kubernetes clusters. So any kind of technology that is tied into a Kubernetes cluster, will be multiplicated basically or in a large enterprise environment to many, many clusters.
Viktor Farcic 19:55
I love what you just said because I think that that brings us to the beginning of of the conversation. I'm creating, I'm deploying some function as a container images as Lambda something as doesn't matter, right? I'm telling somebody, this my application, run it. That's more or less the idea of, and we know that all those are using some form of containers. I'm certain it's not public knowledge, but I'm certain that there is some form of containers for Lambda. I know that there are containers for ECS. It's always containers right. Now, I don't care anymore. Kind of. I'm not saying that this is today. But some future. I don't care. Maybe maybe Knative tomorrow will not run in Kubernetes but it will run in I don't know, something Pepito. Maybe it will not be Knative, right kind of it becomes irrelevant in the distant future.
Ádám Sándor 20:53
Yes, yeah, absolutely. Yeah, that would be also I could imagine also a Knative implemented that can actually run the functions over multiple Kubernetes clusters, that like one Knative control plane mapping to multiple clusters, actually. Why not? So, so it is it is doable. So but these are, these could be hurdles, but it is doable and it's and, and the FaaS could be the thing to be able to replace the current operational model. But also there is the like, all the efficiencies of like, let's say running an application and keeping everything in memory, which is also not that easy to just lose. Even now, like a lot of things that are implemented as functions will not work as efficiently and actually and you and you can end up with a much larger AWS bill also by running something on Lambda instead of running just a single container which keeps memory state actually. So these are, we will see how long these things will be holding back this model there.
Viktor Farcic 21:57
It ultimately probably it will we'll end up like always with a combination of I don't know 15% on average, is using that, just like 30% will be using Kubernetes directly. And then 70% will continue being mainframe, stuff like that.
Ádám Sándor 22:15
But it is like interesting. The important thing is to realize what is the goal really. And actually, there are multiple goals. There is simplifying operations, but there is also improving developer productivity. And the two don't necessarily always go hand in hand, like what one needs or what the other needs. Because I think for developer productivity, building large monolithic applications is probably the best. As long as those developers don't end up. Well, your compiler just ***** tells you what's wrong in your application. So it's a it's it's much more fast than deploying 50 functions and then realizing in runtime that they just like don't work together. Well.
Viktor Farcic 22:59
Yes. But on the other hand, the, to me from developer perspective working in a team that is bigger than five, six people, maybe seven, eight. is horrible. So kind of you know my argue I actually don't like to speak about to use that much terms, microservices, monoliths and stuff like that. I don't think it's about that. It's about when, if the codebase is so big that you need 20 people or 50 people to work on it, that's unacceptable. Doesn't matter what's the size. It can be like, only 10,000 lines of code and still you need 20 people kind of it's a microservice. You cannot manage it like that.
Ádám Sándor 23:41
Yeah, absolutely. Yeah. So like, it's It is true that the monolith has like this limit where simply you just want different groups of people, different teams to be deploying independently, without having to compile the one big monolith. That is that is true. You can't escape, escape that
Viktor Farcic 23:57
It's okay. If you have a monolith. Let's say you huge monolith, but you can manage it with a small team, there is nothing wrong with it. I mean, there are some other things that we might discuss. But from a people perspective, if you can manage it with six people, the size is irrelevant from that perspective.
Ádám Sándor 24:17
Yeah, so does developer productivity and like operational simplicity go hand in hand? That's a good question.
Darin Pope 24:28
That is what we're going to talk about on the live stream. Developer productivity, hey, at least we at least we have a plan this time.
Viktor Farcic 24:39
You know what happens without plans, they last for around 30 seconds.
Darin Pope 24:45
What? No, I get it. So, I'm gonna stop us right there. Because in two days, if you're listening to this in real time come watch the livestream. What time is it going to happen? I don't know yet. I think I have the day off. So it doesn't matter. It can happen anytime. So you have to go subscribe to our Twitter feed, Twitter handle Twitter, whatever https://twitter.com/devopsparadox. Go subscribe there. That's where you'll get the notification. And we sort of know what we're talking about. Of course, I'll have to go back and listen to this as I'm editing to figure out what we're going to talk about and then I'll make notes.
Viktor Farcic 25:27
And we don't know yet whether Ádám we didn't check his agenda can come or no, so if he cannot I will practice imitating his voice
Ádám Sándor 25:36
sounds good. I'll send my answers in writing and you can then pretend I'm saying them.
Viktor Farcic 25:44
Yeah, no, make an open letter. Right.
Darin Pope 25:47
You can pre record all the answers and we'll just play them back. But that would that would work. Alright, great conversation today. We're going to pause it here. Join us on Friday, July 3. If you're listening to this after July 3, go over to YouTube, you'll find it. And watch part three of Ádám. Ádám versus Viktor and Darin. Actually, it's more Ádám versus Viktor.
Viktor Farcic 26:16
The next one we'll start with now that Kubernetes is dead, Serverless is dead as well. We're progressing in each conversation.
Ádám Sándor 26:26
I think it's time we invented what comes after Serverless. It's probably unikernels, it's always unikernels.
Darin Pope 26:35
Then we're just back to where it all started. So, Ádám, thanks for hanging out today.
Ádám Sándor 26:41
Thanks for having me, guys.
Darin Pope 26:44
We hope this episode was helpful to you. If you want to discuss it or ask a question, please reach out to us. Our contact information and the link to the Slack workspace are at https://www.devopsparadox.com/contact. If you subscribe through Apple Podcasts, be sure to leave us a review there. That helps other people discover this podcast. Go sign up right now at https://www.devopsparadox.com/ to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox.