#89: 2020 is in the rear view mirror. 2021 is out the front windshield. The items that are going to be the most important are going to be those items that are the most irrelevant. In today’s episode, we try to unwind what that means and why it matters to you.
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 Principal DevOps Architect at Codefresh, 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.
This is a curious thing about buzzwords. I don't think that GitOps is there, but if GitOps becomes a huge buzzword, like continuous integration, continuous delivery, DevOps, then every company is going to rush to put the stamp saying we're doing GitOps and the world will be better, slightly.
This is DevOps Paradox episode number 89. 2021 - the Year of the Irrelevant
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 it 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.
Happy New Year!
Happy Holidays. Honeycut and, uh, I'm inventing words now, right?
Is it really happy new year? We're still sitting at home. We're still wearing masks. Yes, it is a happy new year.
well, usually you're at home for new year. Somebodys home for new year anyway.
I'm always home for new year now. I used to not. Last week, we talked about looking back on 2020. This week, we're looking ahead into 2021 and one of the big things that we think is going to happen is Kubernetes is going to die and is no longer going to make any kind of difference in how we do our day-to-day jobs.
That's it. Thank you very much for listening.
That's partially true. There will still be people that have to deal with the ugly side of Kubernetes, but we're pushing in on, there's going to be a layer on top of Kubernetes that changes the world.
You almost certainly remember how much we were talking about and dealing with hypervisors back in days and how, at that time, if you would say, Hey, nobody is going to care about the hypervisor. Why do I care about hypervisor. You would be called insane probably and today, nobody knows how virtual machines are created anymore. I mean, when I say nobody, there is somebody, but that person is somewhere working in Amazon, Google, Azure, somewhere.
All we care about is did I get the instance I was expecting with the specs I requested? I don't care if it came up under LXC. I don't care if it was provisioned through ESX. I don't care.
Exactly and I believe that the same future is in store for Kubernetes. I don't care whether it's Kubernetes below, which it almost certainly is, but I don't care and what I care even less is, Hey, is it Linkerd or Istio for service mesh? Are they using this storage or that storage? Which ingress controller is being used? I don't care. It just works. Those are such low level implementation details that I don't care or at least majority of people would not care. I might care because that happens to be something I'm very, very focused on and some other people as well, but for majority of people, Hey, it just works.
Let me take it one level deeper. I don't care if it's Docker or containerd or fill in the blank.
No, we definitely don't care about that.
The problem is at least at this point in time, a lot of people may care because they have poorly written their applications.
Yes. We had news maybe few weeks ago about in Friday's stream on YouTube how the default container engine in Azure is now containerd. I dare people to install all their third party tools that they are having in a newly created AKS with the default settings, meaning containerd, and confirm that everything works. There is no way on earth that it will work, but that's fault of those third party tools. Reality is that it will take us a bit more time to get rid of Docker from Kubernetes.
So as that time is moving, and this is the reason why we're going in on this layer on top of Kubernetes. I might be interested in knowing what's happening under the hood, but as long as it's working, I shouldn't care what's happening under the hood. We're going back to true platform as a service. I think that's what's going to happen.
If you say for a second and that might be debatable, that let's say that we all define container images as Dockerfile. Who cares whether it's built with Docker or something else. What's the relevance in what is building it. What is really problematic and I think that the reason why many previous attempts at something like that failed is because we did not really reach the point where we have a common API that I can define my stuff in some format and that just works and we are not there yet but we might be getting there. That's why I'm mentioning Dockerfile. I really care that we have a standard that say it's Dockerfile to define container images and that like over 50% of people adopted it and then it only from that moment, I don't care anymore about the tool below it.
Do you think in 2021, Docker is going to be a going concern?
Throughout 2021, Docker inside of Kubernetes clusters, if that's what you're referring to will be a very big concern because we will see early on in the year, increased switch to alternative container engines inside of Kubernetes clusters and things will start breaking up. Which is a good thing, because that will start forcing companies, software vendors to adapt their software not to rely on Docker anymore. So it will be painful year for container engine, I think in that transition in 2021, but a positively painful one.
What about Docker on the desktop? What about Docker for developers?
Docker for developers. This is not even that much of a prediction. It's more like stating the facts or facts as I see them which are open to interpretation. It is very clear to me that Docker is moving into as a company to something very different, very developer focused, very focused on what it was first year or two and moving away from many of the things that they had before. I think that Docker will survive, but it will not be as huge as it was and it will be very different. If you talk about some of the new features that they're releasing, deployment to ECS and ACI, scanning with Snyk and what so not. I could not have predicted that three years ago because that's so different than the direction Docker was going in the past.
So if we believe that this new layer on top of Kubernetes is coming and we don't really care much about the insides, but what do you think the lifecycle of Istio, Linkerd, the whole service mesh thing. Where is that going in 2021?
If the world is moving towards some forms of Kubernetes platforms, ignoring now the discussion how abstracted that those platforms will be, then the distributors of those platforms will be choosing, at least the default service mesh rather than users. Right now, we as users are choosing, Hey, I'm going to create a cluster in Amazon, Google, whatever. Which service mesh I'm going to choose. Soon, that will become the default choice in those platforms that we are already using today and then the choice will not be ours anymore or at least not the default one. Then the question arises, Hey, which service mesh most of vendors will be using? Last year, if we had that discussion, I would have said almost certainly Istio. Linkerd and alternatives did not manage to get enough traction. Today, I'm taking all that back. Istio is going down the drain mostly because if the future of service meshes is in vendors, not users, adopting it, then vendors are picking something that can be partly controlled by them and hopefully not controlled by any single company so that their investment is not at risk and that means that Istio is not an option anymore since Google is really rejecting to allow its management, let's say, governance to be independent and that leads us to the conclusion it's going to be some form of SMI service machine interface with Linkerd being the lead. I already forgot. What was the question?
Well, no, you, you landed on it is where is service mesh going in 2021 and basically we're thinking it's going to be not Istio and more SMI based.
To be honest, I always felt that I would like it to go the direction of SMI because to me having some form of common interface that can be implemented by one or many different solutions sounds like an awesome idea. Hey, I can have this interface. I write my definitions, YAMLs, what so not, and then whether they're implemented by Linkerd or some other solution, Hey, I don't care anymore and I can switch from one to another. That sounded like awesome idea. Didn't get enough traction last year and it's getting a lot of traction this year. So one prediction from last year down the train. I think that I remember us speaking about it.
Now one thing we did talk a lot about in 2020, I don't know that it was a prediction in 2020, but we talked about chaos a lot. Where do we think chaos is going to go in 2021? Not chaos, a pandemic. We're hoping that's going to ease off, but chaos when it comes to testing.
It's going to continue increasing, but not to the level that it will become the thing, huge thing. I think it's still early. Average companies need to get more comfortable in this new world. Cloud native, Kubernetes, containers, what so not, for them to take seriously something like chaos engineering. I would like it to become a huge thing, but I don't see it yet in 2021 as being the thing mostly because I think that 2021 will be characterized as sorry, 2020 will be described as a company where most of us decided to experiment and maybe make first steps towards having Kubernetes as serious production, not just something in production, but seriously. 2021 is when increased percentage of companies will have Kubernetes production for real and then after that, we might be able to talk about wider adoption of chaos as a way to confirm and to find holes into something that you're already confident with.
What you just said there reminds me of something I read in the past couple of weeks that somebody was concerned about, Hey, I've got my application running or excuse me, I've got my pod running. It's running on this node. I need to make sure that that node never goes down. That pod never moves. I think one of the things that we're going to see in 2021 is some people are going to wake up and figure out the Kubernetes necessarily isn't the right platform for whatever their application is. As much as we like to say that Kubernetes is the answer for everything, it's not.
Of course, it will never be the answer for everything, but it might actually be the answer for majority of things. The real question is whether me managing Kubernetes is the answer to everything. Whether me interacting directly with Kubernetes is the answer for everything and that's going back to the story about serverless, like Google Cloud Run and I'm aware Google Cloud Run is not the solution for everything. It's actually a solution for a small percentage of things, but I will go bold and say that Kubernetes is a solution for the majority of things. It's just that it's too painful for significant percentage of us to use it directly. That's the real problem. Problem is not Kubernetes. Problem is complexity in dealing with Kubernetes directly.
The other thing that you really have ramped up and I've ridden on your coattails is the emergence of the phrasing and I'm going to be careful how I say this, the phrasing of GitOps. It's not that it's a new thing. It's not. Heck we could have had SvnOps back in the nineties. It's the same thing. It's just now it's getting scarily commercialized. Does it continue growing at its crazy pace? Legitimately growing, not blog posts, not videos about GitOps. I'm talking about is there something in 2021 to where there's going to be an inflection point that occurs with GitOps?
I do not yet honestly know. I would say it's 50/50. I think that 2021 will be make it or break it for GitOps in terms like, it will either become a huge, widely acknowledged and accepted thing like CI was back in the day or CD or it will just stay a niche thing. If it stays a niche thing, that's going to be very problematic and I really hope it will not happen because you just mentioned that yes, GitOps we could do since the dawn of time and all those things. That's absolutely true. The real problem always for those principles is that the tooling that we are using, third party tooling, is not really respecting that idea and majority never was. I think that you or me, one of us commented in one of the previous episodes, that my beef, like I'm often really ridiculizing and saying very bad stuff about UIs and that's not because I don't really want to use UIs, but because UIs do not leave trace and by trace in this context, I mean something in Git about what I did, but because they make ad-hoc changes. Majority of them. I'm using that as example, is that will be interesting to see in 2021 whether GitOps will become the thing that everybody will rush to implement in their products. So I would like to see all those third-party applications saying, Hey, yes, I'm going to store things in Git, and the other one, and I'm going to store things in Git as well and then we can collaborate through Git and all that stuff. If that happens, I think that we're going to make huge strides forward and it's going to be relatively easy because those are easy things to do for each individual up and very hard if you're trying to create that process yourself based on many different third party apps that do not really respect it.
Basically what you're talking about there is accounting. Instead of going around and pointing and clicking, even if I point and click, no matter what it is, those changes are captured, therefore that is accounting.
Yes, exactly. Exactly. Whichever operation I do that ends up or want to do to be more precise that ends up being somehow stored in Git. Whether that's Visual Studio Code, that's browser, UI of your favorite application. When I say that I like using terminals, that's mostly because that's the closest one I can get today on a global scale of having everything scripted and documented and ultimately stored in Git. If you see increase in adoption of GitOps, then I hope that everybody will do its part. This is a curious thing about buzzwords. I don't think that GitOps is there, but if GitOps becomes a huge buzzword, like continuous integration, continuous delivery, DevOps, then every company is going to rush to put the stamp saying we're doing GitOps and the world will be better, slightly.
Slightly because there is, I think a big fallacy or a hole inside of the GitOps model is if we're storing everything in Git, just because it's in Git does not mean that it is immutable
and this goes back to what I was talking about with accounting. From an audit perspective, just because things are in Git does not mean that was really what happened at a certain point in time. It may be true, but there's no guarantee of it.
Yes, but except that I would make a small correction. I don't think that that's that much about being immutable. It's more about not having the ability to change the actual state without really applying something stored in Git. I want to see all the, and I'm really exaggerating now, but I want to see all those SSH keys and kubeconfig TLSs revoked. That's what I want.
I'm just taking it one step further. You're focusing on the desired state has to live within Git and that's what's applied. I'm taking it probably five steps further from an audit perspective and I cannot use Git as proof for audit. I can use it as information for audit. I'm putting a small bet on something. It won't happen in 2021, but I'm going to put a small bet out there. At some point, blockchain is going to get tied back to GitOps because with blockchain, when something happens, it's done. I can't change it.
Yeah, actually now when I think about it, you mean in a way immutable everywhere, not only the cluster, but basically of the states defined in Git or whatever else we might. Yes.
So part of the stuff that would end up in blockchain is the commit hash.
Yes. But Git is also giving you that. Now I know that you can delete past commits, but basically those are more exceptions that can be even prevented easily. Git gives you that type of, really record of every single change through commits.
Unless you're the administrator of that repository, which you could still then fake the repository. I'm saying you have to be able to, as I saw one client do, not even Linux administrators had root or sudo privileges.
Somebody always has to. There must be a person locked somewhere in a basement just in case. Except really, really exceptions, nobody should have. I mean not sudo access. I think that, and this is now prediction, probably not for 21, but further, it's simply no access to systems. It's pretty clear that might not be GitOps and it's probably almost certainly not going to be GitOps, but we will be communicating with the machines, which we are doing right now through APIs and telling machines what we want without really having access to internals of those machines.
Which takes us back to the beginning. Kubernetes is dead. Long live the layer that lives on top of Kubernetes, whatever that may be. Is it going to be Knative? That's a real question. Is it going to be Knative? My gut feel is no. Could it be based on Knative? Maybe.
I honestly couldn't really predict mean if I would have to choose among those that I know right now I would have to say Knative because there aren't many, but that will be the thing. Here's my prediction. Those layers on top of Kubernetes that actually abstract, that's where VC money will be pouring in 2021. Guaranteed. That's the next thing.
The obvious example to me would be something like, at least from a commercial perspective, Pivotal Cloud Foundry. Right now, they have been built on whatever their framework is, well now and I have no inside knowledge of how that's working, but that's what I would expect is PCF would now become a layer running on top of Kubernetes.
Yes. I hope it won't be really Cloud Foundry that we've closed that story, but something like that, conceptually. Yes. Something like that. Definitely.
It may not be Knative, but the concepts of Knative are rolled into whatever that platform is.
Yeah. Whatever it is, it has to be irrelevant. The reason why we are interested whether it's Knative or what it is is because we are witnessing the birth of those solutions, but once they become adults, then what's below them will become irrelevant. Nobody's going to know whether it's Knative or something else
And should not care . So just a quick recap here. It's going to be a layer on top of Kubernetes, not Kubernetes itself. That doesn't mean that we do not need great Kubernetes administrators. We do. It doesn't mean that we don't need good plumbing and good tooling inside of the Kubernetes cluster. We really do. If you're still running StatefulSet and I saw a report from, I believe it was Datadog, what they're seeing from their data is Elasticsearch, Redis, all of these StatefulSet type applications. I'm hoping we get better StatefulSet management inside of Kubernetes in 2021.
I don't know if you noticed like huge quantity of news during KubeCon were around storage, actually. That's the next thing. That's happening right now. That will become huge in 2021 and will be forgotten after 2021, because once we get couple of winners with new solutions, then those things are going to become just part of whatever you're using.
I really hope so. I really hope so. Because we had to get compute right first and then that exposed the pain of storage.
Because storage is not much different. I mean, storage is the same as before virtualization actually started. Essentially. I know that there are some improvements. Conceptually, it's exactly the same. It predates virtualization.
Yeah. It's either still spinning discs or SSD. We don't have quantum SSD yet. Boy, that would be cool, wouldn't it?
Yeah. But quantum something that would still be iterative kind of better hardware. I'm hoping that storage is going to become more focused on software than hardware. Which is what happened with networking if you think about it. Networking was perceived as mostly hardware thing, and now it's actually software. Of course, there are some cables somewhere, but that became irrelevant.
The other thing that we talked about today was the impending death of Istio and the true surgence of SMI based service meshes.
Yes. That will be the thing. If I would have to predict which of the things that we were speaking has the biggest chance of being untrue, then it might be this because this is changing so fast so often, but 2021 will be dominated by SMI instead of Istio. For those not aware of it, service mesh interface definition standard.
Yes. Thank you for stating the phrase, because we use acronyms way too much in our jobs and the final two. Chaos may or may not, it'll probably stay flat I'm thinking. It's probably not going to tick up a whole lot. I a little, but not hockey stick and then GitOps. It's still buzzwordy now. The question is, does it become truly commercialized?
I mean, ultimately for something to become widely adopted, what you do need is that something to become focus of one of the giants. No matter what we think about Docker and containers actually, containers truly became adopted truly, truly when Kubernetes emerged and that means when Google, Red Hat, Microsoft started taking notice of those things. That's simply how it works. For some wide adoption, either a small company needs to become huge or huge company needs to take it seriously and buy the small company that started it.
Exactly. So those are our current predictions for 2021. If I write it down and if I remember it, maybe we will revisit maybe mid-year and do some corrections or add some new ones. So when we get here next year, we may actually have, see, we told you so neener, neener, neener, but maybe, maybe not. Is there anything else, any other, anything else that we want to go in on right now?
Nothing comes to my mind. You know that's how it works and then two minutes after we close it, I'm going to be, yeah. Oh, I just forgot.
Okay. So I do have one. The toilet paper supply in the world. They'll get the logistics worked out on that.
You still have problems with toilet paper?
Still have problems with toilet paper.
Oh yeah. So in 2021 the supply chain is going to figure out how to keep toilet paper on the shelves. I'm not going to go all in on that, but I'm going to make a large bet on that.
Can you 3D print toilet papers?
You can 3D print anything, I guess, but I would be spending more money in energy than. Basically it just turns into use washcloths. That's probably too much information right there, but hey.
I was about to say I was about, I just had an analogy and I stopped myself from saying to save you from editing efforts later.
Thank you very much. Okay. 2021. If you've got some that you want to throw in, go join up in the Slack workspace over in the podcast channel. Go add in what you think 2021 is going to be.
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.