DOP 39: One API To Rule Them All

Transcript

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

Viktor Farcic 0:06
and I am Viktor.

Darin Pope 0:08
And today's episode we're going to talk about one API to rule them all. And that would be...

Viktor Farcic 0:18
Kube API. I mean, that's that's a silly question. We all know it.

Darin Pope 0:23
So how does it rule everything? What's the right thing? We've talked about it a little bit, but we want to talk about a little bit more.

Viktor Farcic 0:31
I guess I should start with my theory that really Kubernetes the main benefit of Kubernetes is not that it schedules containers. That's not really what distinguishes it from from competitors, which are more or less dead, but it's the API. I'm biased. So I've worked with Kubernetes mostly with Kubernetes for a while now. So I love its API and I love how it's extensible. And if I could do everything through that API, then my life and I'm talking about my life only would be so much easier. Because if you know if wouldn't it be great if I if if we could avoid learning, AWS and GCP, and Azure, and load balancers and all those things, which are all different different API's different ways how to do stuff, if we can say, okay, Kubernetes API solves all my needs to instruct the system to do one thing or another. At least I think that would be kind of really, really awesome.

Darin Pope 1:45
Yeah, I mean, think about the first time you installed an Ingress in fill in the blank thing. You didn't know that a load balancer was being spun up under the hood.

Viktor Farcic 2:00
Exactly. And once you learned that, then then you start thinking the other way around. I'm not thinking, Oh, I need a load balancer, and therefore I need to create an ingress.

Darin Pope 2:11
Yeah. And when you when you start thinking that way everything becomes software, whether it's hardware or not. And that's key. That's key that's going to, that's going to be if you listen to our episode, last episode about how important people are to a company. We're pretty harsh about it right? If everything's being outsourced if you're if you're using a managed service provider to do all your things. But now, if the Kube API can actually do everything, if you can extend it to do the things that you need for your company. I'll use a phrase that I'm used to using if you if you write a DSL around the Kube API to do your company specific things. How great is that?

Viktor Farcic 2:59
That's probably the key aspect of Kubernetes designed from day one API and it being extensible. And I remember I haven't tried. So I don't know how well or doesn't we does have doesn't work. But I've seen that VMware is now using Kube API or planning to use Kube API to manage their vSphere VMs. Awesome. I've seen announcements of was it MacStadium, or one of those that, oh, we're, we're using Kubernetes to schedule our Mac VM server, whatever they're using behind the hood. It's not really containers anymore. So in both of those examples, it's not about scheduling containers. It's about using adopting that API to do stuff so that we don't deal with so many different complexities.

Darin Pope 4:00
I mean, you go back and think about the Ingress example, again real quick. In in a non Kubernetes world, you'd say, hey, I need an endpoint added to my F5. So then you have to interact with the DNS team, you'd have to interact with the infrastructure team, you'd have to interact with a networking team. All of that goes away. Now, those three may still have to come together and come up with Okay, here's how we need it done within the company to meet compliance requirements. That's okay. But then it's done.

Viktor Farcic 4:35
That's the key aspect is let's see, I'm just I'm just going to roll with your example right? And let's say that we are not using any of the standard for whatever reason it's we are not in AWS or whatever. So if you're a team that provides that service, load balancing and certificates, then you create your own extend Ingress in Kubernetes, and create your own service and call it "MyCompanyIngress", I don't really care. And actually most people don't care because for most people is still I'm creating Ingress, which happens to be your implementation of Ingress that you defined excellent, but I don't really care. I creating the s and expect x, y and Zed to happen. And you define what that is. That's kind of that separation of concerns that we are missing and we have badly interpreted is, I'm supposed to be able to do everything I need to do instead of opening Jira tickets and assigning them to you. And you're supposed to create the mechanism in a way that is that can be used in a way that is understandable by everybody. And the only way to be understandable by everybody is by not every department, every group, every team coming up with a new way to do the same thing over and over again, different API UIs whatever you're using.

Darin Pope 5:58
It doesn't make sense to do that. This is I think one of the fallacies of I've heard some people say this is like, we want to give everybody the ability to do whatever they want. That's dumb. That's really dumb. Because you need to be able to my opinion is, there needs to be one way to do something within a company. Now, at some point that one way may get turned into two because there's enough of a variation that it becomes two. That's okay. But to say that anybody can do anything they want, how the heck do you manage that? It just doesn't make any sense to me.

Viktor Farcic 6:44
And it's the same thing like, you know, if you're designing application, we all agree that we're going to use REST/HTTP based API, or maybe GraphQL or some, I mean, there are two variations, three variations and everything else is is considered obsolete part of the history and all those things and there is nothing wrong with that. And that does not really hinder innovation. So you can still define your HTTP REST API with all the fields you need. It just we all agree that we're going to use that, right? So it's more about agreeing on a base way how to do things not really agreeing on all the details, because that will definitely vary and change over time. Actually, from my part to the fascination of all this when I was fascinated with external usages of Kube API for a while now, but what really got me thinking is and this will sound is a commercial but it's not because I'm going I will talk about open source now come fully, is it that discovered the product called Crossplane. I don't know if you've heard about that, and it's awesome it's very early beta, alpha I don't know what what version it is. So don't use it in production, yet. But https://www.crossplane.io/, I think the idea is to be able to create Kubernetes resources that will do things like what we spoke about before, like load balancers or database as a service, basically anything in any cloud provider, even on prem, using Kube API, without even mentioning containers in any formal way. So I played around with that project, and it's really, really cool. I really like it. I don't think it's ready. I don't think is there the world will not adopt it today. But it's one of those ideas that I rarely see these days. Would you say, oh, man, man, I, I would be there.

Darin Pope 8:50
Yeah, I've looked at Crossplane a little bit. They sort of re leverage the term stacks. So if you think About, even though we've talked about full stack developers, there is no such thing. There is such a thing as a stack. So if you know you're building an app, and you're going to use node for your front end, you're going to use some Java stuff for middle tier and you're using Mongo or rethink for the DB. That's a stack. Right? And that's, that's my application stack. They've taken that and modified it to, or extended that to the point to where the stack is not just the app, but everything else around the app that supports it. And it's it's a very interesting strategy. And it's nothing new. They're just building on top of what's now available. could this have been done a couple of years ago? No. It's this is just now becoming viable

Viktor Farcic 9:48
Exactly because a big part of the work that they would normally need to do is already done for them. And that's Kube API. That's the complex thing. They're just building boxes that they're putting inside of them. That's what allows them to be fast and which few people I would guess, and and for me as a user, just another Kubernetes CRD.

Darin Pope 10:12
So what would be the coolest thing that you think you could do with the Kube API?

Viktor Farcic 10:19
Personally, the first thing I would like to see is to replace my Terraform scripts with Kubernetes YAML files. That's what I would like to see. So create the cluster, create the cluster, create the ready service script, I mean, whatever you're doing today with Terraform. I would like I would like to do that with Kubernetes API.

Darin Pope 10:47
So the only thing you couldn't do with that would be the actual creation of the control plane. The only thing you would need we'll call classic Terraform for will be creating the control plane, and then everything else go through the control plane.

Viktor Farcic 11:00
Exactly. So I would need the control plane, but that control plane can be running on my laptop for all I know. But yes.

Darin Pope 11:10
That's a scary thought I didn't think about that.

Viktor Farcic 11:13
Now, it's not really a big deal, you know? It's already there. You have a full blown Kubernetes in Minikube, and all I'm asking you actually is to reduce tiny to less for Terraform example,

Darin Pope 11:26
right, because Minikube has a worker node baked as well. So you don't need that part of it.

Viktor Farcic 11:33
Exactly.

Darin Pope 11:34
I don't know what my favorite thing would be maybe place a fast food order.

Viktor Farcic 11:40
In my case, that would be that already exists in Kubernetes that would be a Kubernetes cron job, because I need it every day. a specific time. Could be a cron job

Darin Pope 11:53
be a cron job that makes a call to to a pizza order right into Pizza Hut call you have a Pizza Hut CRD

Viktor Farcic 12:01
No. It would need to be like kind of a five, six of them and then randomly chosing one with predefined order.

Darin Pope 12:07
So you're you're just surprised.

Viktor Farcic 12:10
Exactly.

Darin Pope 12:11
Wonder if someone's gonna listen to this. It's like, Oh, I could write that. But again, that has nothing to do with Kubernetes as we know it today.

Viktor Farcic 12:22
I mean Kubernetes is API that is highly extensible and through custom resource definitions can be extended to create any type of resources. That's Kubernetes API that we know. What is kind of more confusing or less used today is all those things being used in ways completely unrelated with containers because most of Real Usage of Kubernetes ends up being slave to a container one way or another. You know, if if I need to use Terraform going back to the previous example to create a Kubernetes cluster and from there on everything will be done through kubectl then I can just do just as well remove that first step.

Darin Pope 13:07
You would just need one and then you can have it generate everything else.

Viktor Farcic 13:11
Yeah

Darin Pope 13:13
sounds like Skynet, though to me, it's like make the request and stuff happens.

Viktor Farcic 13:20
It's It's It's more about the process itself and the way we define things, but you know, what's that YAML definition is can be anything still, it just needs to follow the formatting rules of Kubernetes. But it would not really hinder innovation in any form or way I think. Which is my main concern always when we say everything is to be if I say everything needs to be Terraform, then we are much more limited, for example, in what it can do, but Kube API can do almost anything. It's it's just pub sub machine.

Darin Pope 13:58
It's it's really smart in how it interprets what to do. But in actuality its really dumb.

Viktor Farcic 14:04
Hey, just send the request that we receive acknowledgement that request goes in a queue and is processed by one or more resources that somebody defined. And they're listening to those types of requests. And what those listeners are, can be anything really literally anything. Any process you can imagine, and like, lately, what I've been tinkering with, is doing chaos engineering, and a quickly fall into doing it from Kubernetes simply because it's more comfortable for me, even though most of those experiments I'm working on right now are completely unrelated with Kubernetes just shutting down data center in AWS. So no, it's not directly related to Kubernetes. And yet, for me, it's more comfortable to do it using Kube API.

Darin Pope 14:57
Chaos is a lot of fun.

Viktor Farcic 15:00
You just heard Actually, I was not supposed to. You just heard the topic for the next course. For the first time, including you Darin.

Darin Pope 15:09
Yeah, I know. Joy, more chaos to my life. But that's okay. Chaos is chaos. But Kube API as as that one API to rule them all. That just sounds like too far of a stretch. But in reality, it's not. If what you've heard that VMware is doing that already. If that is true, that makes complete sense. I mean, you think about what ESX is, its containers but not containers. You have guests running on hosts. That sounds like pods running on worker nodes. It's it's the same model, just a different implementation. So why not use the same control plane

Viktor Farcic 15:55
99% of the stuff is going to continue being the same with vSphere right? Just different mechanism to accept your input as, as a human or a machine what you want to do. So API is the only change really in that announcement.

Darin Pope 16:11
Yeah, because I can't tell you the number of times going back to the previous episode where I've got open a JIRA ticket to get a VM spun up so I can do work. Well, now, even if even if the, even if that ESX team had self serviced that right through some PowerShell commands, which is the way you can interact with ESX it's still not super clean. But now all that goes away.

Viktor Farcic 16:40
Now, here's the real issue and tell me how how, how often you experience the same thing. But at least when I visit companies, you need certificates and then they say they somebody goes to a wiki page, oh, these are the instructions how to create certificates in the system called A and then oh, we need this as well. And then some other thing created something completely different, I mean, different way to interact with, not what is in the background is different in any case, right. And then companies have like, hundreds of different APIs or interfaces, it can be UI, right? To interact and create different things. And managing all that and remembering that that's why everybody has so many Wiki pages, because every single detail you need to do is is done differently. And just let me clarify. This is important. When I say different other mean, what's done behind the scenes behind the scene can be as different as you want, but the way how to interact with that. That can be unified.

Darin Pope 17:44
Yeah, a common API is hugely important for making good progress. Let's say there is a common API. In fact there already is just using Kubernetes. As it stands today, if you're Doing nothing more than Ingress. And just a couple of simple things. If you were to leave your company and go to another company, the way you install an Ingress is the same at Company B as it was Company A. There's no, there's no difference, right? So that's already just sort of naturally baked into the process. That's assuming you're actually doing the companies are doing the right things, which that's pretty rare and far in between. I think Crossplane is hitting on it from the right concept. It's an API wrapper around Kube API to do all the things. Well, it's a CRDs and stuff, but it's, that's what it is, right?

Viktor Farcic 18:44
Yeah. But it goes a bit more than that. So you can say for example, for every infrastructure related thing, I can have Terraform is my API or CLI or whatever it is. And I think that that's better for me than using CloudFormation for AWS. And then whatever is Azure, and then whatever is Google, so on, so forth. So Terraform to rule them all, I like it. But I still get annoyed, because I want a load balancer. And the only thing that I'm reusing in Terraform to create load balancers in different places, is that the syntax is same Ruby like syntax. But it's completely different. And I really don't care, I want the bloody load balancer, just create me a load balancer. And you should know how to interact with Amazon instead of Google. So that type of unification I would like to see, I know that it will never be exactly the same arguments, parameters and stuff like that. But the differences between playbooks in Terraform for different providers are just too huge. I need to learn each of them by heart even though. Actually, most of like, take Kubernetes as an example managed Kubernetes most of the things I'm specifying are essentially the same, how many nodes I have, autoscaling, what is the size of VMs and stuff like that. And yet the syntax is completely different for all of them.

Darin Pope 20:07
And here's where Terraform does fall down. Again, nothing against Terraform. But new feature comes out from fill in the blank provider. It takes time to get that in there. And if I'm wanting to do that day one, day two, I can't get it that fast, typically. So then then I'm stuck having to use console, native CLI, whatever to do the things I need to do right then you would still have the same problem with Kube API that point too, because you'd have to have a CRD to do that thing.

Viktor Farcic 20:43
Delays are almost inevitable, because a provider will do thing native with their way first, and then it takes a while to get there, but at least we can somehow simplify and simplify. Now, as I think aloud, maybe actually most people don't have that problem. Maybe I'm just having that problem Because I work with many different providers and stuff like that, maybe most people are stuck with one provider or whatever it is, and they don't really care about those things. That could be the case.

Darin Pope 21:10
Now that opens up another can of worms that we'll save for another day. But if you're running everything on a single provider is that the best thing for business continuity for you?

Viktor Farcic 21:20
Almost certainly is not. But on the other hand, I can actually the answer is no, very clear answer. But that could also say, is it worthwhile investment?

Darin Pope 21:33
And the answer is probably going to be no,

Viktor Farcic 21:35
because you cannot, you know, if you're stuck with on prem, you're going cloud and going from nothing straight into a couple of different providers. That's not going to result in anything good. You're going to have enough trouble getting into one of them. And it takes years for an average enterprise to get to AWS, Azure, Google, whatever they're using. Going from nothing to do all of them. Haha.

Darin Pope 22:05
That's probably a good place to wrap for today. Kube API one API to rule them all.

Viktor Farcic 22:14
Yes. I mean, I wouldn't be surprised if, like, five years from now, the main thing about Kubernetes is not containers. But Kube API stays.

Darin Pope 22:27
Oh, you already sort of seeing that in a weird way with OpenShift. OpenShift 4 doesn't ship with Docker. Now, it still can run containers, but still containers.

Viktor Farcic 22:41
But let's say that tomorrow, we And I'm not saying that will happen, but we move into some lightweight VMs that turn out to be better than containers. It's not going to be containers forever. But API so and also Kube API will not last forever. Nothing lasts forever. But here is my prediction. Kube API is going to outlast Kubernetes scheduling engine for containers.

Darin Pope 23:05
It's a pretty bold prediction. We'll see. I don't know. I'm a coin flip on that one because they're they're tightly bound enough, but they're also loosely coupled enough. Looks like it'll be the next big thing. Well, we've talked about it before. serverless is going to be the next big thing. On Kubernetes. Right, so then Kubernetes still nothing. So then does it matter? Today, serverless on Kubernetes although good, I can see it being much better.

Viktor Farcic 23:39
Oh, yeah, it's it's only the beginning. I'm not the 100% sure that containers in the current way are the best place for serverless but we'll get there. And that's another subject.

Darin Pope 23:54
If you like to make some comments about this episode, you can reach out to us our contact information. is in the show notes below. It's at https://www.devopsparadox.com/contact. Leave us a Voxer message. didn't mention it last time. But if you're interested in learning about Canary deployments go out to Udemy and you can search for Canary deployments. Look for Viktor's name to there'll be a link, I'll include the link to it as well. One API to rule them all. If you were to task people with one thing this year, would it be to learn how to interact with the Kube API? Know how kubectl works. Is that a good thing or a bad thing?

Viktor Farcic 24:33
I'm not sure yet.

Darin Pope 24:34
Okay. It's still January, so that's fine. Okay, let me rephrase the question. Should you be should you be learning Kubernetes this year?

Viktor Farcic 24:45
Yes, yes. Yes, there is no doubt. It affects absolutely everybody. Now, the only question is whether, depending on what your interests are, what is the level of learning You should do. That is the thing. If you're a Node JS developer, maybe like couple of days is enough.

Darin Pope 25:02
If you're an operations person?

Viktor Farcic 25:12
five years.

Darin Pope 25:13
Five years. I can, I can already see the the recruiters coming out, hey, we need somebody with 10 years of Kubernetes experience and, you know, 25 years of Java And oh, by the way, we're only going to pay $20,000 a year for that. That's another conversation for another day. Okay, well, that pretty much wraps this episode. Thanks for listening to episode number 39 of DevOps Paradox.

DOP 39: One API to Rule Them All

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