DOP 59: Why It Is Silly Not To Use Kubernetes If You’re Moving To The Cloud Today

Transcript

Darin Pope 0:00
This is episode number 59 of DevOps Paradox with Darin Pope and Viktor Farcic. I am Darin.

Viktor Farcic 0:06
And I'm Viktor.

Darin Pope 0:09
And Viktor contacted me today, sort of out of our normal recording schedule. He was like, hey, hey, hey, I've got an idea. I've got an idea. And who am I to say no to Viktor. So why don't you go ahead and set up the premise and then we'll talk about it.

Viktor Farcic 0:31
So the short version of the story is that I've been hearing in, in a few occasion, companies moving to cloud, AWS, Azure, this and that, and then their architects deciding that they should be cloud native and by cloud native, that means using cloud specific services but since Kubernetes is not cloud specific really service, they shouldn't go to Kubernetes. And that I don't know how it happened that I heard that couple of times in the last couple of weeks and I thought it's very strange. Now I understand perfectly well, that Kubernetes is not for everybody and not everybody can move everything to Kubernetes. But if we are now moving to cloud right now, today, would it make sense not to use Kubernetes? And I'm excluding those edge cases, you know, when millisecond in transactions is important, right? So excluding edge cases, would it make sense to move to cloud today and use let's see, EC2 instances or whatever else cloud providers software instead of using Kubernetes.

Darin Pope 2:00
I think it depends.

Viktor Farcic 2:02
Okay, on what?

Darin Pope 2:04
It depends on what you're running. So tell me what you're going to tell me the workload that you're running.

Viktor Farcic 2:10
let's say, application simple application,

Darin Pope 2:12
you're so you're not saying a database.

Viktor Farcic 2:16
I'm not saying a database,

Darin Pope 2:17
you're not saying something like Elasticsearch,

Viktor Farcic 2:21
not Elasticsearch. So, those for those actually, I think it's great to, if you ask me, I would give that use that as a service from some vendor. Doesn't matter whether it's AWS, or Elastic or whatever and forget about it, and not really care whether they're running it in Kubernetes or running it in bare metal or what they do.

Darin Pope 2:41
Okay, so what we're saying is for packaged type things, let that be a service.

Viktor Farcic 2:49
Yes, exactly. So if it's a third party,

Darin Pope 2:53
yeah, so if a third party Okay, so now what we're saying is this applies to I'm writing Spring Boot. I'm writing Go microservices, I'm writing fill in the blank.

Viktor Farcic 3:04
Yes,

Darin Pope 3:05
I'm writing my business logic type stuff.

Viktor Farcic 3:07
Yes. Now, by the nature of my work. That is also another example is very often CI/CD processes. So you can put in that bag, let's say also. So let's put it this way, things that you run, that can be long running processes. And then that could be our application or ephemeral processes that just do something and disappear. And remember, we're starting, we're talking about some building something new. Doesn't matter whether it's a process, whether it's application, it's new.

Darin Pope 3:40
The downside of one of the downsides of not going Kubernetes is if you had to change cloud providers, at least today, if I, if I'm in Kubernetes, I can go to pretty much any cloud provider that I want, roughly, right. Is that a fair statement?

Viktor Farcic 3:58
Yes, yes. Now you might need an hour or a month of work right? but less than

Darin Pope 4:04
doable, I wouldn't have to I wouldn't have to re architect my application in order to move.

Viktor Farcic 4:09
Yes.

Darin Pope 4:10
In general, I cannot think of a good reason why I would not run in Kubernetes today.

Viktor Farcic 4:18
That's why I was kind of surprised by by those conversations, I cannot reveal the sources but with those conversations, because I understand that we are all having different, you know, applications in different stages of evolution, and then that can be complex, but starting something new making decisions right now. And, you know, if that if that same question popped up, let's say three years ago, then I could defend it with saying, Oh, we don't know whether Kubernetes is here to stay We don't know whether it's going to be Kubernetes or this or that. But I don't think that there is a doubt whether it will stay. It will for a while and I don't really think there is a doubt of the level of innovation happening on it. And this is actually something I wanted to ask you or other people. I have impression that most of the innovation is happening on top of Kubernetes today. But what I don't really know whether that's because I'm so focused on it, and I don't see the rest of the world going on. Or that's really true. But if it is true, that means that you're missing not only on the future platform, which most of us are going to use it use and all the other benefits but you also you're missing on the lots of good things happening.

Darin Pope 5:45
For as much time as you spend in Kubernetes and on Kubernetes, I spend just as much time not on Kubernetes. Right now I'm working with a client that is completely on bare metal. There's no containerization at all. They don't even know what Docker means. So there are still those other side of things. They're still fully on premise. It's a whole different conversation. But looking at it from the perspective of what we've done through the courses and through the books, is there is a huge ecosystem if every major cloud provider, every minor cloud provider, is providing Kubernetes as a service, that's a very telling sign. If it's one thing to say, hey, AWS, Google and Azure, they've all got Kubernetes. But we've got DigitalOcean. We've got Linode. We've got Alibaba which is AWS level, right, you've got everybody has a managed Kubernetes. I'm using managed in a very loose term here for a moment, but they're providing Kubernetes roughly as a service that you can use. Now that the level of managed varies from provider to provider.

Viktor Farcic 7:02
Exactly. I mean, the other day we spoke I don't know whether the other day means that it will be released before or after this episode, but we spoke about news that Linode is offering now Kubernetes service, right? That's that's a player that not many companies follow. But that means that actually that is propagating absolutely everywhere, not only within the big three. And then there is another thing that I'm of, I believe I'm observing is that not only everybody is offering now Kubernetes as a service, and that speaks volumes about its adoption, and the direction but also that most software providers are building their next gen to be Kubernetes something right? That includes not only our company, but also almost everybody else is trying to jump on the train.

Darin Pope 7:54
To me, it's if you're creating, here's the thing. In fact, I was listening to an episode. I'll go and give him some props. I was listening to an episode that Tim Berglund does. He works for Confluent. He's a devrel for Confluent. And he was interviewing Kelsey Hightower. Kelsey, if you're listening to this, you need to come visit us.

Viktor Farcic 8:16
Oh, yeah.

Darin Pope 8:18
But they were talking about this concept of look, every function that lives within Kubernetes, there is a mapped function back to a human in some shape or form. A Kubernetes operator, that's why it's named an operator, is fault tolerance. Okay, well, if you don't have now, fault tolerance is just core. Each of the features that are built into Kubernetes or can be plugged into Kubernetes quite easily, cluster autoscaler for one, is just available. Otherwise you have to build it yourself.

Viktor Farcic 8:59
Exactly.

Darin Pope 9:00
It doesn't make sense to do that, when Kubernetes gives it to you for almost literally free.

Viktor Farcic 9:09
Exactly. But I'm still kind of more interested in to me kind of even bigger argument is the upcoming innovation. And so you always want to invest into something that will be usable tomorrow if possible. So like the other day I was in, in a panel about GitOps with few other people. And at one moment, I said, Hey, everybody, you need to stop, GitOps is not Kubernetes because everybody was talking about in the context of Kubernetes. And conceptually, GitOps is not really about. It's not even that neither directly or indirectly related with Kubernetes. It's just a concept of using Git to store as a source of truth and triggering some action saying converging desired into actual desired state. But even though the conceptual is not Kubernetes related, everything happening in that sphere is Kubernetes. I don't know a single tool like I mean Jenkins X because I work on it but then there is Argo, there is Flux, there is many, not a single one that is trying to implement implement this, let's say buzzword or a new concept outside of Kubernetes and that is the curious thing to me. That is a big thing that you would be missing if you could jump on a train but you don't.

Darin Pope 10:46
Everything that I see and other people I talk with, everything is based on Kubernetes. Everything because because of the basic things of availability. It's a declarative way to define how your application is going to run. I don't have to go out and figure out okay, I need to go write these 30 different Terraform scripts, these handful of Ansible playbooks. I need to get together a 50 page Word runbook to handle disaster recovery scenarios. No. Kubernetes does that for me out of the box. If I if I'm trying to basically, I might step on some toes here. If I'm basically just trying to keep my job, then maybe I would ignore Kubernetes. But if I'm thinking what's best for the company, right now Kubernetes is the answer. Because otherwise I'm getting potential vendor lock in that would make it to the point. Let's say now, AWS has not followed this pattern from a pricing perspective ever. They usually go price down except in one case. Wait, they did price down even for that. It was GKE that priced up. Alright, so we'll use Google, this is actually a good example of course it's bad that I'm saying it with Google, because it was specifically around the Kubernetes product. Their control plane used to be for free now your pay 75 bucks a month per control plane, or whatever the money is. To have a dependency on a service that's written in a very specific way and all of a sudden, my CTO changes out and we were a Google shop and now we have to become an AWS shop and I wasn't using Kubernetes, it's not just a weeks or months change. It could be potentially a years change.

Viktor Farcic 12:38
Oh, yeah, it would be the same situation as currently with mainframe I think. It's so big of an investment that actually, you're going to stay no matter what. And that that pricing for GKE is actually a good example, because I could have gone maybe to AKS because AKS still offers free control plane. I'm not now going to enter into comparison, you know whether it's better or worse solution, but I can do that. So kind of common understanding of an API, reusable everywhere. innovation happening on top of it, mostly. And every single vendor implements that something. Man, how can you not jump into it if you start from scratch? It's It's my head hurts by even trying to think about it.

Darin Pope 13:34
There's no good answer. I can't think of a good I mean, remember, I'm the old one of the two of us. And even I would say, of course I want to use Kubernetes. Why not? Because I, if for no other reason, I've got built in fault tolerance. Right? That's, to me, that's always the huge one. I don't have to figure out how I'm going to deal with failovers or failure scenarios.

Viktor Farcic 13:59
I have a bad answer, but an answer that I think it might be common. What I believe is happening is that companies are rushing to move into cloud, especially now with what is happening with the virus and everything right that I think that that is even more accelerating. So what is the natural thing to do when you're rushing from on prem to cloud? To find an expert. And if you already made the decision in advance which cloud it's going to be, you're likely to find an expert in that cloud, right? AWS, Azure, Google, whatever you choose. And being an expert in cloud means that actually you know all its services inside out. But that's not Kubernetes. right, you know, if you see AWS you know, inside out then NLB, ELB, auto-scaling groups, all that stuff. So that might be the reason hidden reason why there is a certain rejection of Kubernetes or try to stick with vendor specific services no matter what.

Darin Pope 15:21
But when you step back and look at the Kubernetes side of things, you still get all those pieces. They're just set up in a very specific way.

Viktor Farcic 15:29
Oh, yeah, yeah. But, you know, it's, it might be even similar to, you know, I often joke saying, Oh, yeah, that's because he's a DB2 expert. That's why you don't have NoSQL. Maybe actually, a new equivalent of DB2 experts are cloud specific experts.

Darin Pope 15:51
To me, it's, it's very simple. We talked at the beginning about having databases or data stores. Let those be services. Don't care who it is. But for my applications, and for the for the known money and the known visibility that Kubernetes is getting across all the major and minor cloud providers now, and you decided you want to go off and do something specific one little niche thing that was great six years ago with AWS because there was I'll say it Elastic Beanstalk. Right? Elastic Beanstalk is a fine product. Right? Five years ago. Even I'll even go this far, even 24 months ago. Because until recently, EKS recently, meaning in the past 12 months, EKS was, although workable, not completely friendly. Now, you'll argue with me that it's still not friendly. I've worked with it enough to where it's become friendly.

Viktor Farcic 16:53
Yes, I exaggerated. I agree.

Darin Pope 16:56
But it's it's still doable. You there's a lot more knobs and switches you've got to deal with in order to get EKS setup right. But once it's setup, from my perspective, it's no different than GKE.

Viktor Farcic 17:09
Yes.

Darin Pope 17:09
Once it's set up, right, and that's, that's the key is making sure that you get it set up. Is there work in getting that done? Yeah, probably a little bit more. How much more? An hour, two hours maybe compared to GKE. This is what I was saying, I cannot think of a logical reason why I would write in a business application today or business usage application today, and not deploy it to Kubernetes. It just seems it seems a complete waste of time and a complete waste of resources. Because again, it goes it goes back to my basic premise at the very top, somewhere along the way of if my C level changes, my CTO, CIO, I don't like AWS. Everything I've ever worked on is Azure, so we're going to Azure. So we have to migrate everything to Azure. What kind of...I need a beep button right now. What kind of mess are you going to be in when you actually have to make that change, and how much loss of revenue is that company going to be impacted on

Viktor Farcic 18:16
It's not even necessarily a change. It can be addition. Like what Carlos was speaking the other day. He run autoscale, he wants certain guarantees. It's a very reasonable assumption that tomorrow you might be running in two providers, whichever two you choose, not only one.

Darin Pope 18:35
and you have to. You have to in order to mitigate your risk, now you are forced to run in two, alright, let's play it out for just a second. Let's, let's use Azure and AWS, because I know these two probably better than GKE or better than GCP. In order to mitigate our risk for availability, I have to run in both AWS and Azure. That means I either (A) have to write stuff that runs on bare metal across the board just like I did in on prem or I write a Kubernetes application that runs exactly runs, maybe not gets set up the same way but runs exactly the same way in both providers.

Viktor Farcic 19:16
Exactly. It's a no brainer.

Darin Pope 19:18
it's a no brainer from a business decision. No brainer.

Viktor Farcic 19:23
I mean, what what is a huge I think other extreme is when people start thinking about multi provider setup on other fronts. So you invest a huge amount of money millions into being able to run in two providers even though actually the second one is not needed today. So what I'm trying to say investing huge amount of money to be ready to run somewhere else is also not a good option because the same ways it's not good option to start a startup thinking that your Google sized, right? But if it comes with almost no cost, then, hey,

Darin Pope 20:06
it's worth a gamble at that point.

Viktor Farcic 20:08
Exactly.

Darin Pope 20:09
It's like, Okay, let's try it for a month. See how it works. It works? Great. Maybe you decide, okay, let's keep it running that way. Maybe you go to, you know, warm, cold or hot, cold or hot, hot, who cares? But from an application developer standpoint, I don't have to think about where it is landing. I just know that it's landing in Kubernetes and be completely agnostic to how it got there. Why are we even having this conversation?

Viktor Farcic 20:38
It was more like validation. You know, sometimes I need to speak with somebody and that happens to be you very often is, is a validation that I'm not going insane when I hear somethings. So somethings are debatable, like for example, serverless that's a debatable subject. I might be against it I might be for but it's I can understand different reasoning behind pros and cons of let's say serverless. But we're starting from scratch. We don't like Kubernetes and there is no good reason, like latency or whatever. I literally thought that I'm going insane. So the fact that we just that you confirmed that it's good, I can go back to my work thinking that yeah, part of my sanity is still there. It's not me.

Darin Pope 21:26
Okay, well, I'm glad I was able to help out. Now, I do want to go back. And I'll say it for a third time. If you need a service for a database, data store, don't try to run that yourself. Let that be a service. That makes complete sense.

Viktor Farcic 21:43
Oh, yeah.

Darin Pope 21:44
That I mean, there's absolutely there's zero business value in running your own database cluster within Kubernetes.

Viktor Farcic 21:50
There is a paranoia part. I mean, yes, there is zero business value. Now. You know, some people would argue and I would say that they're wrong that oohh there's sensitive data and I don't trust and all that stuff. I think it's exaggerated. But hey, I can hear that and not go insane at the same time. But services yeah definitely. I mean, I would even predict that. I think we're still we did not reach a peak in cloud adoption. I think that many companies are still in initial stages. But once cloud really lands kind of like fully in its full glory, services are the next thing. Then the companies start by shifting what they have there let's say databases or CI/CD services or this or that. But once they get the taste of cloud, then they will want more and that more is going to be services.

Darin Pope 22:51
Let's go to the other side of the curve. And then we'll finish up. I've been in cloud. I've been in Kubernetes in the cloud. But now I have to go back on prem because my cloud spend is too much and I can offset it back into the data centers that I already have. If you had written your application to take advantage of native application based services, Elastic Beanstalk for the example. And now I have to bring that back on prem. Because of spend, you could do that. But then you're going to be baking in all these other crazy things, the availability problems that you have to solve, versus I was already running in Kubernetes. And now instead of running in Kubernetes in the cloud, I'm now picking Rancher, OpenShift, whatever on prem. It's a matter of moving the workload on prem. Now, again, it's not a magic Thanos snap. But it's a heck of a lot easier than trying to say okay, how do I re architect all my applications that were running in Elastic Beanstalk, and have them running back on premise, and still get all the availability features that Elastic Beanstalk gave me for free. Kubernetes does that for me.

Viktor Farcic 24:14
You could never do that. I mean, not without exaggerated effort and cost.

Darin Pope 24:20
You'd have to get a lot of new coffee mugs and T shirts printed to support that project level.

Viktor Farcic 24:27
And then once you do it now, let me follow your example. Once you do it, and then a year later, you will realize, okay, so on prem is not that bad for me, whatever the reason is, but actually, it's I cannot really have infinite capacity on prem, so maybe I should have normal capacity or minimum capacity and go for excess capacity when it happens to cloud because why would I buy servers for excess capacity if it happens only around Christmas, right? Let's say Christmas, right? And then again, for the third time, it doesn't work because you just shifted from something that was cloud specific to something that is on prem specific and now you need both. It wouldn't be possible.

Darin Pope 25:16
To validate your point, if you're doing completely greenfield application development today, business, let's call it business application development today, you're making this decision or you're trying to make the decision, should I go with whatever the native services are for my specific cloud provider or should I use Kubernetes? That shouldn't even be a decision that has to be made. It's Kubernetes.

Viktor Farcic 25:40
And you're still leverage, you're still leveraging this Kubernetes as a service from whichever provider you chose to have it and they will run your control plane and they will scale your nodes and they will do all those things.

Darin Pope 25:42
that you can set limits on so you don't get runaway costs or, hey, the one thing you just mentioned it there. We didn't talk about it here. All the cloud providers are running the control plane for you. If you think you need to throw the knobs and the switches in the control plane, you need to go work for one of the three cloud providers and not for your company. Because talk about something that nobody needs to mess with. It's that. Okay, so we went way off the rails there. Did we answer the question to your satisfaction or answer answer the question in your head? Am I am I missing something?

Viktor Farcic 26:29
Yeah, you valiated my sanity.

Darin Pope 26:35
I don't know if that's a true statement or not that your sanity was validated. The question the question in your head is validated.

Viktor Farcic 26:44
Yeah. So you did not confirm that I'm insane so it's still for the up to the up for debate. It's a possibility, but it's not certain.

Darin Pope 26:53
But on this one point, we have validated that if you're writing new business applications, and you're not using Kubernetes, you need to get a new job. If you're still listening, thank you. But if you're listening via Apple podcast, please subscribe and go ahead and leave a rating and review. All of our contact information including Twitter and LinkedIn can be found at https://www.devopsparadox.com/contact. And if you'd like to be notified by email when a new episode is released, you can sign up at https://www.devopsparadox.com.com. The signup form is at the top of every page. There are also Slack, slacks links, we'll call them slacks. There are also links to the Slack workspace, the Voxer account, and how to leave a review in the description of this episode. I don't know that there is anything else to say.

Viktor Farcic 27:42
That's it.

Darin Pope 27:43
That's it. Okay. We usually have something else smart to say, but there's nothing else to say about here. If you're writing if you're writing business apps for your company today and you're not and your primary deploy target is not Kubernetes. Let me rephrase that if you're writing greenfield applications, greenfield business applications for your company and your deploy target is not Kubernetes you're providing not a service to your company, but you are providing a disservice to your company.

Viktor Farcic 28:11
Well said.

Darin Pope 28:12
Wow, really? I got I the Viktor thumbs up on that.

Viktor Farcic 28:15
Oh, yeah.

Darin Pope 28:16
Okay. Thanks again for listening to episode number 59 of DevOps Paradox.

DOP 59: Why It Is Silly Not to Use Kubernetes if You’re Moving to the Cloud Today

Show Notes

Hosts

Darin Pope

Viktor Farcic

Links

Rate, Review, & Subscribe on Apple Podcasts

Signup to receive an email when new content is released

Transcript