ABDEL SGHIOUAR: Hi, and welcome to the Kubernetes Podcast from Google. I am your host, Abdel Sghiouar.

KASLIN FIELDS: And I'm Kaslin Fields.

[MUSIC PLAYING]

ABDEL SGHIOUAR: This week, I had the opportunity to speak to our colleague Nick Eberts. Nick is a product manager on GKE in the platform engineering space. We discussed what platform engineering is, how different or similar it is to DevOps, and what is Nick up to these days.

KASLIN FIELDS: But first, let's get to the news.

[MUSIC PLAYING]

Starting July 24, 2023, the official Kubernetes binaries will be distributed using a CDN. The domain dl.k8s.io, which hosts these binaries and serves more than five petabytes of traffic per month, will adopt Fastly as its content delivery network. So if your company uses some IP filtering, you may have trouble with this, and you should look into updating your infrastructure. Keep in mind that July 24 is a cutoff date. Past that date, the IPs will change and there will be no dual running period.

ABDEL SGHIOUAR: Red Hat announced OpenShift Service Mesh version 2.4. The new version is based on Istio 1.16 and Kiali 1.65. This new version introduced a set of new features like cluster-wide topology, search manager integration, and external authorization all becoming generally available. OpenShift Service Mesh is included in all subscription levels of the OpenShift platform.

KASLIN FIELDS: Amazon Web Services introduced AWS Signer, a container image signing service which uses their key management system. The new service uses notation, a CLI of the open source notary project from the CNCF. For verification of image signature and policy management, customers can use Kyverno or bring their own admission controllers.

ABDEL SGHIOUAR: Registration is now open for KubeCon and CloudNativeCon North America for 2023. The event will take place in Chicago, Illinois on November 6 to 9. If you haven't registered, but you plan to attend, we recommend that you do so now, especially since early bird tickets are available only until July 7. Also, make sure to book your hotel as soon as possible. They are selling out fast.

KASLIN FIELDS: The registration is also open for KubeCon, CloudNativeCon, and Open Source Summit in China. The event will take place September 26 to 28 in Shanghai. Early bird tickets are available until August 9.

ABDEL SGHIOUAR: Have you heard of SBOM, or software bill of material? Enter KBOM, or Kubernetes bill of materials. KSOC Labs, the San Francisco-based firm, open-sourced the command line interface and the standard for generating a bill of material for Kubernetes. The JSON specifications gives operators and security teams insights into their clusters, especially workloads, vulnerability and images, third-party customization and CRDs, service mesh, and object versions. It's compatible with Kubernetes 1.19 plus, and works on most major cloud providers.

KASLIN FIELDS: The CNCF has released a new blog by Kubernetes 1.26 release lead and friend of the podcast, Leonard Pahlke, titled "Version after version-- how the open source project Kubernetes releases its software". The article goes into detail on how the Kubernetes community is structured, how Kubernetes enhancement proposals work, and what goes into releasing new versions of the software. It's a great detailed write up for the curious among you or those looking to get involved with the project. And that's the news.

[MUSIC PLAYING]

ABDEL SGHIOUAR: Hello, and welcome to a new episode of the Kubernetes podcast by Google. I'm your host Abdel Sghiouar, and I'm here with--

NICK EBERTS: Nick Eberts.

ABDEL SGHIOUAR: How are you doing, Nick?

NICK EBERTS: Doing great, man. How are you doing?

ABDEL SGHIOUAR: Good. So we are actually recording this in Atlanta.

NICK EBERTS: Yeah, we're in my hometown, Hotlanta.

[LAUGHTER]

That's right. Yeah. Yeah.

ABDEL SGHIOUAR: Yeah, I spent a couple of days here. I'm attending Devnexus, and Nick was so generous to invite me on the weekend. I had a really fantastic weekend last Sunday.

NICK EBERTS: Yeah, it was a good time. We had Abdel up, we showed him some southern hospitality, fed him some foods, gave him some drinks, and sent him on his way.

ABDEL SGHIOUAR: It was amazing.

NICK EBERTS: I also, wait. I actually recall though, I think my daughter was kind of whooping your butt a little bit on some Switch.

ABDEL SGHIOUAR: We were playing on the Switch. We played Mario Kart, and we played some sort of soccer game.

NICK EBERTS: Yeah?

ABDEL SGHIOUAR: And yeah, she was beating me.

NICK EBERTS: Yeah. She was really adamant about talking trash, too.

ABDEL SGHIOUAR: Oh, yeah. The trash talk was real.

NICK EBERTS: Yeah.

ABDEL SGHIOUAR: Yeah, I had so much fun. It was great. Yeah, and we had the chat, actually, over the weekend about the topic that we're going to cover today, which is platform engineering.

NICK EBERTS: That's right.

ABDEL SGHIOUAR: This whole thing started with a tweet. I wrote something around the lines of, is platform engineering just a solution to the complexity of Kubernetes? And then you replied with something, something, something. And then it was like, if we only had a podcast to talk about this.

[LAUGHTER]

And that's how you get yourself invited to this show.

NICK EBERTS: Yeah. Subtle hint.

ABDEL SGHIOUAR: Yeah. Before we get ahead of ourselves, let's get to know you. So who you are. Tell us about yourself.

NICK EBERTS: Yeah, so I am, you know, Nick Eberts. Kind of rolling with two jobs right now. Half product manager on outbound product manager working with the GKE team, and then the other half of my role is focused on being an app ecosystem specialist.

I've been using Kubernetes and working with customers to help them adopt Kubernetes since .7, way back when me and Eddie Vilaboa, shout-out to that dude, another Googler, we were both at Microsoft, probably the first couple of people rolling Kubernetes on top of Azure VMs, which is treacherous.

But anyway, yeah. Yeah, so I've been in the space for a while, working with lots and lots of customers. I feel like I've seen platform engineering being born out of Kubernetes for the past half a decade.

ABDEL SGHIOUAR: And so, as you said, this whole platform engineering as a buzzword, whatever you want to call it, have been around for a while. But I think, I don't know about you, but one of the things that attracted the most my attention in the last maybe six months, is this tweet. Which is like, they pay for it. It's promoted tweet by, I think, the people behind PlatformCon, if I'm not mistaken.

NICK EBERTS: Also, owners of a product that may or may not provide platform-as-a-service.

ABDEL SGHIOUAR: Yes. And so the tweet is basically a graveyard picture and like a bunch of people around it, and it says DevOps is dead. Do you think DevOps is dead?

NICK EBERTS: I mean, there's no such thing as bad press. Right? So we understand why that was done. No. I mean, it just depends on how in your head you define DevOps. And I feel like DevOps, in general, has been defined super loosely over its existence. Right? Lots of people have different takes. Lots of vendors are selling DevOps, which is hilarious.

But DevOps, to me, is more like a philosophy. Right? It's a state of mind. And I think a lot of the philosophy just remains to be applied. You know, automate things, ship things faster. All the parts of DevOps that we know and we talk about don't go away with a platform engineering sort of conversation replacing them. It's just, where those human beings work might change. Right? And I do think it's a spectrum.

So if your org is centralized and you have a lot of users that have different expectations for their compute systems, they're doing a bunch of different distributed [? sys ?] systems, maybe batch, maybe web services, you're probably going to have a more centralized platform. Right?

And so maybe you're not going to have DevOps folks, necessarily, living on each of those teams. But it may be more cost-effective for you to centralize that talent to build a platform. So just depends a lot on-- Conway's law prevails.

ABDEL SGHIOUAR: Pretty much. So you said something interesting, and I think it's one of these things that makes DevOps really hard to define. You said it's a philosophical question. And as far as I know, tech people are really bad with philosophy. Right? We define things, because we're more on the implementation side, really, than the sort of philosophical/research/creation side of things.

Case in point, the company that we acquired, DORA, that was a research company. And their job was trying to bring a scientific methodology into trying to understand how DevOps is used by organizations and companies, and try to provide some guidance.

But to people like you and me, people who are on the ground implementing things, thinking about DevOps from a philosophical point of view, it's kind of hard, because how do you-- as you said, it's a spectrum. So what does it mean, a spectrum? Tech people like implementing stuff.

And that's one of the reasons why, most of the time, when you see a DevOps job it's usually just a set of tools. Do you know Kubernetes? Do you know CI/CD? Do you know this and this and that. Right? So I think it's one of the reasons why it's a highly debated topic, in general, in the industry, because we cannot define what it is. It really depends on which company, what the company wants to do, how is it organized, et cetera. Right?

NICK EBERTS: Yeah, that's fair. I mean DORA's a good example, where if you look at the indicators and the solutions, I guess, that DORA would recommend, they're always these capabilities. Right? They measure these capabilities and the effects that these capabilities have on the speed with which a company can deliver software.

And the capabilities don't really change when you're talking about platform engineering or DevOps, where you've just got-- you have an operations person right next to your developer and implementing that same thing. Right?

So you have a DevOps engineer who's in charge of setting up CI/CD for his small dev team, or you have a massive platform team that sets up patterns of CI/CD for the bespoke business units that consume the product. The bottlenecks are still being addressed, if the bottlenecks are indeed technology, which, often, they're not. But yeah.

ABDEL SGHIOUAR: Yeah, most of the time, they're not. All right. So that's DevOps. Then how would you define what people today refer to as platform engineering? What do you think people think of when they say, oh, we're doing platform engineering?

NICK EBERTS: First off, super early term. I think I first started-- I feel like I've been doing platform engineering for, like I said, five, six, seven years. Maybe even longer if you consider pre-Kubernetes Linux-distributed system work on other cloud providers. But I think that the term is sort of being set right now.

I remember first hearing it being just used prolifically at, I think it was KubeCon Valencia is probably the first time I was like, oh, everyone's talking about platform engineering. And then at KubeCon Detroit, quadruple so. There was 15 talks about platform engineering.

And it's, I think a lot of the sort of hype around it, or the buzz around it, is wrapped into this notion of GitOps, where you're defining all of your configuration centrally and creating infrastructure and clusters and configuration that's sort of immutable, that then pushes out and propagates to your fleets of clusters.

But so platform engineering for me, though, my take on it is it's an acknowledgment that maybe not every end user of your container platform needs to know Kubernetes. Or, I don't know, maybe you're still running Mesos or some other container orchestrator. But not everybody needs to know it, right? But there are some things they do need to know.

And so it's creating an abstraction that sort of removes the cognitive overhead of being a developer who has to maintain knowledge over deployments, and stateful sets, and horizontal pod autoscalers and all of that configuration. And so platform engineering is just this idea that you're going to improve the developer experience of the end users of your platform so that they don't need to understand all of the complexities of the underlying infrastructure.

ABDEL SGHIOUAR: Sure. So there are a bunch of things you said there that I think we need to unpack. First question. Do you think that platform engineering is really specific to Kubernetes? Because you mostly mentioned Kubernetes stuff. Right? Like what if you don't run on Kubernetes? What if you run on VMs?

NICK EBERTS: Yeah, I don't think it's specific to Kubernetes, though it's the place that I see it most often. I'm also biased, because that's where I spend most of my time. But no, I don't think it's-- I definitely don't think it's specific to Kubernetes. I mean, there have been platforms around before we decided to use containers.

ABDEL SGHIOUAR: So that's why I was asking. Like, it was probably born from the complexity of Kubernetes to a large extent, but it's probably not specific to Kubernetes. Although, maybe the people who are out there talking about it are people coming from Cloud Native and Kubernetes space, so you would associate it directly to Kubernetes.

NICK EBERTS: Yeah, I think we have some confirmation bias, because you and I both spend a lot of time in the Kubernetes space. But I do think that a lot of this is born out of that Cloud Native CNCF space. That said, I mean, whether it was called platform engineering six years ago when everyone was just rolling Helm charts.

Right? It's the same thing. They had these-- you built these sort of templates of golden paths. And you could have maybe considered that one of the first layers attempt at a platform on top of Kubernetes back in the day. And still people using it now.

ABDEL SGHIOUAR: Exactly. And then the other thing that you mentioned, which I think is interesting, is the GitOps model. I mean, that have been around for a while. It's not new. Doing things the GitOps way, or the Git way, as some people would refer to it, have been also around for a while. I think it's, like, I don't know, more specific, more important in the platform engineering space. Or is it just like an implementation detail? Because I think about it as an implementation detail.

NICK EBERTS: Yeah, so I don't know if, again, we're getting into jargon, but-- and we live and die by it in the tech industry-- but GitOps, a lot of people will assume that GitOps is always this pull model in which you have a bunch of daemons running across your clusters or orchestrators pulling configuration and then making stuff happen. But it could be a push model, too. I mean, when I think of GitOps, I just think you make a change in Git, and that change is then reflected across a number of computers.

ABDEL SGHIOUAR: Yeah, pretty much. And that's the basic definition.

NICK EBERTS: Right. It is an implementation detail, but I do think that-- I don't know. One way to approach platform building, and this is the approach I've been sort of a fan of for a while, is to-- and this is specific to Kubernetes. I mean, I'm a GKE PM half the time. Is this idea that you're going to create fungible clusters. This idea that the underlying clusters in your quote unquote "fleet of Kubernetes".

I mean, they just don't have a personality. I like to call them clusters without a personality. So their personality is just defined in this config somewhere, and it's centralized. And if you do it right, you don't fall into the trap of care and feeding and maintaining a particular cluster. It's very much that old school--

KASLIN FIELDS: Pets versus cattle?

NICK EBERTS: Yeah. Yeah, you just rip and replace as you need. And it keeps you out of trouble when you're-- there are certain configuration choices in any cloud provider that are immutable for a cluster. And so if you need to put a new cluster in, the fact that you've codified everything, whether it's GitOps, I guess, or just Bash, the idea is that you can just quickly rebuild that cluster with the one change you need to make and then de-provision the old one. And I think that's kind of key to the underlying infrastructure of a platform.

ABDEL SGHIOUAR: I see. OK. Well, that's one component of it, I think. The other component would be the abstraction layer, that platform engineering is supposed to provide the end developers. You talked earlier about the developer experience.

So the way platform engineering is marketed, especially by the companies that want to make money out of this, is OK, we're just going to give your developers this beautiful interface, beautiful GUI, so they don't really have to, as you said earlier, know the implementation detail of Kubernetes. They don't have to know namespaces, whatnot.

They can even go a step further and use Kubernetes to define application dependencies. So use Kubernetes to provision a database. Use Kubernetes to provision a messaging queue or a bucket. Whatever. Stuff like that. Right? So can we talk a little bit about that? Like the abstraction layer.

And that's the chat we had over the weekend where I told you-- I don't want to talk more than you, but--

NICK EBERTS: No, that's OK.

ABDEL SGHIOUAR: --DevOps was supposed to solve the ops versus build model. Right? And then I was saying maybe this platform engineering is just going back to that. Essentially, build a wall, which is the interface, that just shields the implementation detail away from the developers. But you had a different opinion about it.

NICK EBERTS: Yeah, so two things there. To your latter point about the wall, I think as a platform engineer, it's your responsibility to make sure that you're providing your end users more than just a UI for provisioning and for updating apps and provisioning environments. You need to provide them a UI, or an experience, rather. It doesn't have to be a UI. It could be a set of CLI tools.

It just depends on the characteristics of the people that you're working with. Some people don't need everything to be put into a nice, clean UI. They're happy with just a tool chain that works. But the point is that you need to provide them an ability to become aware of how the new thing that they're shipping into their environments, their life cycles, is behaving.

They need that observability coming right back at them. So they can't be disconnected. I was actually listening to a podcast a couple of weeks ago. I can't remember which podcast it was, but Charity Majors was on it. And one of the points that the host and she were making was this idea that the long tail right now in the shipping software quickly is actually merge request time.

ABDEL SGHIOUAR: Oh, yeah.

NICK EBERTS: It's not, yeah, It's not the time to deploy. It's not the time to write the code. It's the time to get two people, or one person, to be like, yeah that's good. Push it into production.

ABDEL SGHIOUAR: Yeah, code reviews, basically.

NICK EBERTS: Right. But so I think part of providing a good experience is a way to create broader visibility of those merge requests and then the subsequent push after that, the telemetry that's coming out of the system as it's being rolled out. That's super important. And that, I think, removes the wall to some degree, because they can't just ship some code and then go home.

And I don't think they want to. Right? Listen. I've been a developer before. If I'm shipping code right now, and I'm waiting, like, 48 hours for a merge request, and then it's getting pushed into production maybe three, four days later and something breaks, I was never more aware of the context of that code that I wrote than the minute that I issued that merge request.

All the time after that is just degradation of my awareness of that particular code set. And I would never be more capable of fixing it quicker than that moment in time when I issued that merge request. So we need to shorten up the time it takes to get from code written, merge requests approved, into production.

ABDEL SGHIOUAR: OK, that's-- I never really thought about it that way. That's interesting to say. What you mentioned is the long tail is the merge request, is the code review part. But while you were talking, I was thinking in my head, the way we do it at Google is we have this thing called readability. So for a certain programming language, you can become readability experts.

Essentially, you become a reviewer. But that means that you, as a software engineer, you have been trained to withhold certain standards. And if everybody is trained on the same standards, then code reviews becomes easier, because you as a trained person, you know what to look at when you are looking at a merge request, or whatever we call it internally. Right? Do you think that that's something that not a lot of companies-- it feels to me like something that it should be implementable by everybody.

NICK EBERTS: Oh, man. It's hard. It's hard because-- I mean, to our credit at Google, we operate as one company, mostly. I mean, we do have our acquisitions and things like that, but we operate as one company. We use one tool chain. I mean, you've been working with enterprise customers long enough to know that that's not typically how they function.

There may as well be, like, 15 different, 20 different, 100 different organizations within one. And so to get that mindshare to establish these frameworks and common understanding is much more difficult with companies that are buying, acquiring other companies and selling them off. It's just-- it's a more difficult problem for them.

ABDEL SGHIOUAR: Yeah, that sounds like a topic we should probably explore in this show. Like, the whole engineering culture and how it impacts productivity. And case in point, how long it takes for code to be reviewed is a major topic that I think is probably not-- maybe overlooked. Maybe other people are covering this topic, but I never really had discussions around this with my customers when I was working with customers.

NICK EBERTS: No, I mean, I think it's worth, when you get in those conversations, just asking some probing questions so we get some better feedback from what's actually happening outside of Google so we can learn a little bit more about the other ways things are getting done.

You're also talking about this idea of creating the abstraction over Kubernetes, or over whatever the computers are and the APIs are that you're abstracting, right? And I mean, you can go all the way back to, I don't know, maybe five years ago. I'm bad with dates, but do you remember Service Broker?

ABDEL SGHIOUAR: Yeah.

NICK EBERTS: Yeah, Service Broker was a pass at trying to create-- it was a pass at trying to create that interface that allowed you to go into this portal, so to say, and pick your wizzywig buttons of an application and have it assembled. And it wasn't successful. It wasn't successful because-- part of the reason I think it wasn't successful is because it actually wrote a little bit in the face of infrastructure-as-code.

And so that, I think, is part of the challenge with, I see as the conflict, with the approach that you need to have a GUI for your platform engineering DevX. You need to be able to turn that configuration into code somewhere. It can't just be like, I come into work and I assemble these clicks and assemble an application and it can't be reproduced.

ABDEL SGHIOUAR: Yeah, what you see is what you get. You have to have the how that thing have been assembled, like the origin story, essentially.

NICK EBERTS: A state store somewhere that tells me what it actually is in production.

ABDEL SGHIOUAR: Yeah. Yeah. Yeah. Definitely. So, I mean, we covered a lot of topics, but I still want to go back to that point of-- to have like a mental model. We have the old school way, which is the ops versus build with the wall in the middle.

We tried to solve it with DevOps. You just get these two functions, roles, whatever, teams, to be one. And effectively, a lot of times, when you talk to people around DevOps, specifically, they say oh, our DevOps team own and operate the entire stack. So they own the VMs. They own the databases. They own everything. Right?

NICK EBERTS: They're effectively a mini platform team at that point.

ABDEL SGHIOUAR: Pretty much. That's actually a very valid point of putting it. So then we're coming to this world of platform engineering. And although the biased person I am around anything that is as jargon, as you said earlier, or passwords or whatever, I see value in the sense of, if your goal is to take these people who are doing repetitive work across multiple organizations, put them together, have them build something that can provide a developer experience to everybody else, That's how I think about platform engineering.

NICK EBERTS: Yeah. No. No, that's a good point. I mean, there's no wrong thing here. The DevOps model isn't wrong. Platform engineering model, if you're being hard and fast about it, isn't wrong. It's more to do with the maturity in the organization that you have, I think.

And so, like a lot of folks that were starting up with Kubernetes or starting up in the cloud, they had these sort of bespoke teams that were all doing their own infrastructure and kind of owning the stack. And out of that, I think, was born DevOps, because they were able to move fast. They were able to get over the hump of traditional on-prem application, I need a VM, and I'm going to put a request in for it, and I might get it next week. Right?

They were able to get past that kind of stuff. But now you have the same organizations that now have what? Some of them 10, 12, 15 different business units doing that. That's not efficient. It's not efficient from a human being like engineering hour perspective. But it's also not efficient from a computer perspective.

One of the things that really gets my ire up is this idea that we're going to treat Kubernetes like some orchestrator for homogeneous workloads. I keep on seeing it. I know that there's reasons. Like, some things are sensitive. There's business reasons why that may be the way that you go. But it was not built or intended to be an orchestrator of homogeneous workloads.

The whole point is to have heterogeneous workloads that have different characteristics so you can get better bin packing and use less computers to serve the same work, have less of an environmental impact to serve the same work. Like, that's the point.

And so when your organizations mature and you start to build out that platform that stretches beyond just different bespoke business units, you start to gain the abilities of more efficiently bin packing and just driving costs down if you do it right, I think.

ABDEL SGHIOUAR: Yeah, I like that perspective, actually. I think that that's something that 99% of the tech writing that people do on the internet are opinions, obviously. And probably 90% of these 99% are people who are somehow mad at everything. Like, we are not doing cloud because X. We are not doing Kubernetes because X. We're not doing Service Mesh because X. And it always seems like it's a black and white type.

NICK EBERTS: We've moved back on prem because of X.

ABDEL SGHIOUAR: Exactly. And I think that when you read these articles you are always-- I cannot prevent myself from thinking, well, you are missing the point. When somebody says we don't use Kubernetes because of X, it's probably what you described. You are trying to make Kubernetes fit your workloads, or you're trying to make your workloads fit Kubernetes, not the other way around.

So it's the homogeneous versus heterogeneous discussion. Right? Or we're not doing cloud because X. Well, you have 10 virtual machines. Going to cloud is not going to be cost-efficient for you. Right? So I think that what I'm trying to get at is a lot of people, they lash out at a tool, or a way of doing things, or a certain platform, or a certain something, but they're missing the point of how that thing is supposed to be used.

NICK EBERTS: No, yeah, I think-- do you know Darren Shepherd?

ABDEL SGHIOUAR: Yeah.

NICK EBERTS: Yeah, so I was talking with him about this about a month ago. And very smart dude. He's built a bunch of really interesting things that a lot of people use today. So good for him, for Rancher, and all the great things that he did over there, and he's continuing to do. But his point with Kubernetes is he always feels like it's too complicated.

ABDEL SGHIOUAR: Sure. I'm not denying that.

NICK EBERTS: Right. And my counter point was to him was that Kubernetes isn't too complicated. The workloads that are in the world today are complicated. Kubernetes API is as complicated as you need it to be. If applications can fit in a nice Pivotal Cloud Foundry PaaS model, and that would have served the needs of 50%, 60%, 70% of the workloads out there, it would be here and be super successful today.

But it didn't. And containers kind of become sort of the next lowest abstraction that can service a decent swath of workloads. There's still a bunch of stuff that shouldn't be in containers. Right? I'm looking at you, Windows. Unless you're, of course, converting it to .NET on Linux, but that's besides the point. But it's complicated as it needs to be.

And I think it's really powerful to have an API that can both serve legacy, stateful Java applications, and then serve cloud-native-- I going to have them do it in quotations-- "cloud-native" applications that are microservices-based that are running asynchronous patterns with RabbitMQ or whatever running in your cluster.

It's great that there's an API out there that does both of those things. And so Kubernetes, I think, ends up becoming the de facto choice for a lot of our customers and a lot of people out there running applications on computers just because of its ability to have a wide net of applications that it can support.

ABDEL SGHIOUAR: Yeah, definitely.

NICK EBERTS: And so yes, it could be easier. But that's greenfield applications. That's a very small percent of what is running the world that we live today.

ABDEL SGHIOUAR: Yes. And as I always like to say, applications doesn't live in a vacuum. Because when Kubernetes came out, and when people started using it, it was mostly, hey, build a container, deploy a container here, create a load balancer. Happy days. "Hello, world" example. Whatever.

But then what is your database? What is your messaging queue? What is your login and monitoring system? Like, all of those stuff had to catch up. And now, we're getting to the point you're describing. It's a pretty flexible API that can do a lot of things, including stateful workloads, including batch workloads, including well, these days, AI and ML workloads, which is a huge one.

So it's getting to a point where Kubernetes, I think, in my opinion, is over the hype period. It's getting to the maturity period now. It is a mature product. And I mean, excuse me for saying this, but if you have a problem with using Kubernetes, you have a problem. It's your problem. It's not the tool.

NICK EBERTS: I don't think it's a problem or no problem. If your applications can run on something else at a higher abstraction, and it fits your cost profile, do it.

ABDEL SGHIOUAR: Yeah, so be it. Yeah.

NICK EBERTS: Right? That's OK. No one says everything has to run on Kubernetes. If you are running one service, you should probably look at something else. Right?

ABDEL SGHIOUAR: Yeah, probably.

NICK EBERTS: You know what I mean?

ABDEL SGHIOUAR: If It's your like personal blog.

NICK EBERTS: Yeah. You probably don't. Or even if it's just something that's making a lot of money for you that's customer facing. But if it's just one service, it's got one characteristic, it's super bursty, and you don't really see a need to start to bring in more things around that service, then it wouldn't make sense to learn Kubernetes. You might want to look at something like Cloud Run or any kind of functions-as-a-service bit to kind of--

ABDEL SGHIOUAR: Yeah, container Cost, basically. A container of service.

NICK EBERTS: Yeah. Anything. Yeah.

ABDEL SGHIOUAR: Yeah, it's probably one of the most fascinating time to be in cloud is now, because it's a lot of moving parts. It's a lot of things that are progressing at some at a steady pace, some are just popping up every week like a JavaScript framework.

Just look at the CNCF landscape. It's growing like crazy every day. Now if you look at the blog, every other week, there is a project which is accepted to the incubating phase. Every other week, there is a project that is graduating. It's getting wild, essentially.

NICK EBERTS: Competition's good, though.

ABDEL SGHIOUAR: That's true.

NICK EBERTS: I like the competition. I like-- I like the-- I mean, I think that's one-- we're getting way off topic and I'm sorry, but one of my favorite parts about Kubernetes is that it sort of, oh, god, this term, it democratized software a little bit. Right? I'm sorry for using that term.

But it made it more accessible for smaller shops to build and ship things. And that's why back in the day, I think Helm, and still today, is successful. You have this common format. You package it up, and then you can ship it around to anybody who's got a Kubernetes API. It doesn't matter what cloud provider they're on most of the time.

ABDEL SGHIOUAR: Yeah. This whole discussion about, is Kubernetes going to give you the multi-cloud the way people want to think it will give you multi-cloud. Right?

NICK EBERTS: Give you like 80% of multi-cloud.

ABDEL SGHIOUAR: Pretty much. But that's a topic for another show. Well, we covered a lot of things. And I want to just bring the discussion back to platform engineering a little bit and try to wrap up. So most of the time, when I ask this question, people hate me. Where do you see this thing going? What's the future? Platform engineering.

NICK EBERTS: I mean, I think it's going to blow up. It's going to be strong. It's going to be strong, because I think that the maturity of customers using Kubernetes the number or the percentage of mature customers using Kubernetes is increasing. And these orgs have complex org charts, all filled with applications that have different requirements.

And you're either going to build kind of a platform abstraction on top of your cloud providers or on prem that's unique for each of those things and doesn't share the compute layer on the bottom, which is fine, but there's obviously inefficiencies there.

Or you're going to look for a way to have kind of a cohesive infrastructure layer underneath so that you can get better bin packing and scaling and drive cost down, better negotiation power with cloud providers. So I think it's only going to become more prolific over time.

ABDEL SGHIOUAR: Yeah, there is actually a point. I think I want to touch on this point we haven't discussed. We talked about complex org charts and how that drives inefficiencies in general. And what you just described, platform engineering could essentially fix that, or could help you fix that.

One of the issues that will remain is chargeback, because in complex organizations, every business unit has its own budget. And one of the challenges that a platform engineering team inside a big, complex organization would have to push for platform engineering and push for their platform to be used is, well, how do you do chargeback? How do you charge me for what I consume out of this platform?

And that kind of created a whole genre of FinOps. Right? Financial operations. So I think that that also has to get to a mature point at some point. Like, how do you do-- I mean, doing chargeback in Kubernetes is extremely difficult.

NICK EBERTS: It's getting easier. Well, it's getting easier in certain places.

ABDEL SGHIOUAR: We're not going to say what those places are.

NICK EBERTS: No. No. That's exactly right. And I think it's why so many folks end up with that single business unit tenancy model in which everybody, every business unit, every unit that they want to charge back gets its own cluster. So I think it's up to the ecosystem and the providers out there to help make that problem more easily solved so that it doesn't need to be a single-tenant cluster and that you can just break those walls down.

Get the chargeback you need, again, by treating the clusters like this fungible fleet of workers. You don't really want to get to know them. You shouldn't care which cluster you're on. It should just be about whether or not your work is running and how much it costs.

ABDEL SGHIOUAR: Yeah. Yeah. So we'll see how it develops in that sense. And I think we're going to see what the trends are in two weeks. We're going to KubeCon. This episode is going to air after KubeCon. But we're going to be in KubeCon, and you know every year KubeCon has one trendy thing. Valencia was EBPF and platform engineering. You know, Detroit was all about software supply chain security. So we're going to see what this edition is going to bring.

NICK EBERTS: It's going to be AI, though, isn't it?

ABDEL SGHIOUAR: It has to be. That's what's going on.

NICK EBERTS: So I'm getting old. I'm 42 years old, and I'm starting to forget things. So much so that there was a group email that went around in the past week and someone discovered-- so we have this internal way at Google you can create bots. So someone discovered a bot called NickGPT. And I couldn't remember if I made it or not.

[LAUGHING]

ABDEL SGHIOUAR: OK.

NICK EBERTS: That's where my brain's at right now, man. I was like, did I make that? And I was just waiting for someone to claim it. And I don't think anyone's claimed it yet. So it might have been me, but I'm not quite sure.

ABDEL SGHIOUAR: So what does it do?

NICK EBERTS: It's a shim on top of Bard.

ABDEL SGHIOUAR: Oh, OK.

[LAUGHTER]

Sure. With a personality, I guess?

NICK EBERTS: Yeah. It's a little bit pessimistic, I guess. I don't know.

ABDEL SGHIOUAR: I've seen on Twitter, last week, this kubectl-ai. Somebody wrote like a kubectl wrapper, which uses, I think, uses ChatGPT to get like, hey, kubectl, create a deployment with three replicas, and then it just prompts you the YAML file, and then it tries to apply it to the cluster. I haven't tried it yet.

NICK EBERTS: Yeah, someone posted a screenshot this morning. And of course, me, being the smart aleck that I am, I was like, awesome. Way to take it back to the 2016 Kubernetes demo.

[LAUGHING]

But yeah, so you know ChatGPT, just capable of making the right decisions to create a three-replica deployment of nginx with an ingress in front, just from one command.

ABDEL SGHIOUAR: Sure. You could just create a deployment with kubectl and then describe it with the dash YAML. What's the difference?

NICK EBERTS: Right. I think they still have generators, too. Right? They didn't completely get rid of those. You could just generate that config.

ABDEL SGHIOUAR: Yeah, you could. Yeah.

NICK EBERTS: That's how I passed all my CCA-V exams back in the day.

ABDEL SGHIOUAR: Yeah, tips if you are doing the exam-- the generator command is very useful.

NICK EBERTS: Yeah. Yeah. Yeah.

ABDEL SGHIOUAR: All right, man. This was fantastic. I really had a good time having a conversation. I always enjoy talking to you.

NICK EBERTS: Yeah, same here. I mean, I'm honored to be on here. I probably could have done better, but I'll take it.

ABDEL SGHIOUAR: Oh, this was-- I mean, we tried to make the show as light as possible. The whole point is to bring perspectives of people into a topic. Right? And we're not trying to push for a specific agenda or anything. We're just having a friendly chat. This basically would be the same thing with a beer over a fireside.

NICK EBERTS: If we do it again, I think that we need to do it at my house.

ABDEL SGHIOUAR: Yeah. Then we have to have a camera and everything and maybe we should shoot it.

NICK EBERTS: Are we going to do a fireside chat?

ABDEL SGHIOUAR: Yeah, but your house, I mean, it's beautiful. We have to take pictures. We cannot just be audio because it's not going to be immersive enough.

NICK EBERTS: Oh, yeah. You hear that, Sundar? I'm going to be doing the fireside chats next year, sir.

ABDEL SGHIOUAR: All right. Fireside chat in next place in Atlanta, Georgia.

NICK EBERTS: All right.

ABDEL SGHIOUAR: All right. Well, thank you very much. Any last words?

NICK EBERTS: No.

ABDEL SGHIOUAR: I mean, I think-- I'll try to get some resources from you to add them to the show notes if people want to expand their knowledge of this topic.

NICK EBERTS: Yeah. I would tell you to come join me at KubeCon in a couple of weeks, but you're not going to hear this until after KubeCon.

ABDEL SGHIOUAR: We're going to take a picture and post it to Twitter.

NICK EBERTS: OK. Sweet.

ABDEL SGHIOUAR: All right. Thank you very much.

NICK EBERTS: Thank you, sir.

[MUSIC PLAYING]

KASLIN FIELDS: Thank you very much for that conversation, Abdel. It was very much a conversation. I feel like you all had a really good time talking to each other. You covered so much.

ABDEL SGHIOUAR: I was in Atlanta when we had that interview. And you know, we have two offices in Atlanta, and there is like the new one and there is the old one, which is not closed yet, but it's pretty much not used. So I was sitting there because it was quiet. And I just, like, we booked like a room, and we sit there and we were-- because I was in his place on the weekend. So this was, like, a continuous of conversation we had over the weekend, really.

KASLIN FIELDS: And like I said, you covered so many different topics. You started out with DevOps. And that is an area that is near and dear to my heart, so let's start with that. I loved how Nick talked about DevOps as being a philosophy. Kind of my way of thinking about DevOps versus platform engineering is similar to what you all were saying.

That DevOps is all about philosophy, and it's really about the culture, whereas platform engineering, I think Nick said in the interview that platform engineering is about improving user experience. It's about specific tasks and work that you do that you could apply DevOps concepts to, but all in the name of user experience. And that's kind of how I see it.

ABDEL SGHIOUAR: Or precisely, developer experience. Right? Because that's essentially what platform engineer is trying to--

KASLIN FIELDS: Yeah, developer experience. Yeah. Because a lot of the folks that I talk to, folks that care about Kubernetes, traditionally, have been folks who are serving developers. So I feel like that's kind of where this comes from.

ABDEL SGHIOUAR: Yeah. Yeah. I mean, it's interesting that Nick's has this very clear way of distinguishing-- the reason I mentioned DevOps in the first place is because we all have seen on Twitter this very famous ad, promoted ad, which--

KASLIN FIELDS: Yeah, you mentioned it. Yep.

ABDEL SGHIOUAR: And then, so I was trying to pull him toward talking about that specifically, because in my head, every single time I read anything about platform engineering, it always tries to compare it to DevOps, which, in my opinion, there is no way to compare those two things. They are, like, distinct things trying to solve distinct specific set of problems.

KASLIN FIELDS: Apples and oranges.

ABDEL SGHIOUAR: Exactly.

KASLIN FIELDS: Both fruit.

ABDEL SGHIOUAR: So they can be complementary. You can use them together, but you don't have to. I mean, in a way, if you really think about it, if I am a developer, and I am using a cloud platform, could we argue that the cloud platform is doing platform engineering for me because they provide me with self-service and managed services? Yes.

KASLIN FIELDS: I think so, yeah.

ABDEL SGHIOUAR: So I use an interface on API to provision stuff, and I don't have to worry too much about where my database is. So yes, that's platform engineering.

KASLIN FIELDS: Yeah. That's a very interesting, I think, kind of way to frame it, this conversation between platform engineering and DevOps. Because sometimes, folks come up to me with this kind of trying to compare the two, like you were talking about.

It's like, our DevOps thing is going to be replaced by platform engineer things. And I think some of them might be because those DevOps things were trying to get at what platform engineering is trying to get at to begin with. But DevOps, I think, will still continue as its own kind of area, as well.

ABDEL SGHIOUAR: Yeah. And also, another thing, because DevOps also has a business component to it. Because in the methodology, or specifically in the DORA methodology, which is kind of one of the ways to assess your DevOps implementation or your DevOps impact on the business, it has those business metrics that you can track.

Platform engineering is just, I mean, you could technically measure developer experience, but I feel like DevOps and DORA give you a framework to do that, while platform engineering tells you, yeah, you should have a platform which is self-service. And then the question becomes, with platform engineering, well, how do I measure developer velocity?

How do I measure the developer experience in general? The X is the random topic that is not very-- it's very difficult to measure if you don't have metrics for it. So as you said, I think DevOps will stick around, and platform engineering is just one implementation, or one set of implementation, one way of looking at it. Maybe down the line, something else will pop up.

KASLIN FIELDS: It's one piece of that pie. If you look at a DORA report, there's definitely stuff in there that applies to platform engineering, but there's more beyond that, as well.

ABDEL SGHIOUAR: Exactly.

KASLIN FIELDS: One thing that you talked about quite a bit was how we improve developer processes, because this is all about improving developer experience. So it's about improving the day-to-day lives of developers. And one thing that really stood out to me was when you talked about trying to standardize processes of how people do code reviews and get software made.

I found that really interesting because we come from a Kubernetes world. So CI/CD is certainly an important part of the world of Kubernetes, though it's kind of outside of Kubernetes itself, but these kind of developer workflows. Kubernetes only touches a small part of it, so it goes beyond that.

ABDEL SGHIOUAR: Yeah. While we were talking, it reminded me of a conversation I remember having a few years back with a friend who used to work at Google as a software engineer and then quit. And I think within a month, we had a conversation. And this person was so shocked with the Wild West of how people do stuff outside.

Obviously, Google has its own way of doing things, and it's all about developer experience, and it's all about you as a developer. You come in and you're productive from day one. Right? You know how code reviews work. You know how CI/CD work, but you don't care how it works. It just works for you. You know how code versioning works.

And then they quit the company, and they went somewhere to work with like GitOps and CI/CD and stuff like that. And they were like, oh, do I have to actually figure out everything myself? I don't even know how it works. So it's definitely, like, the developer experience with the developer workflow is really at the core of what platform engineering is all about. Is, how do you provide people with standardized tooling, but also standardized processes, standardized way of doing things like code reviews. I mean, you'd be surprised how many companies doesn't do code reviews still.

KASLIN FIELDS: Yeah. And it relates to the number one question that I get from customers, which is, how does everybody else do this? That's what everybody always wants to know, because there are so many different ways to do things. And when you're starting up, you do whatever works.

And then as you get larger and larger, there's so many different groups within the company that are doing that all the time, where they're creating their own processes and ways of doing things. And some companies do more to streamline that into a single process than others. So you end up with a huge variety of ways that things could be done. Thus, the answer is always, it depends.

ABDEL SGHIOUAR: It depends, yeah. So today, I was on the flight to Amsterdam. I was reading an article that was shared by Richard on Twitter. And we can share it in the show notes. But the article, I don't remember the exact title, but it's something around the lines of, you should focus more on the platform part of engineering when you're talking about platform engineering. Focus more on the platform side rather than the engineering side.

And there was a breakdown of how this could be implemented. So the person who wrote this article works for a company that had to go through this transformation. And one of the things that I like there is, when you are trying to implement, or you're trying to answer the question of how others are doing it, well, involve your developers. Have them be a stakeholder that can tell you and give you feedback. And try to incorporate their feedback into the platform you're building, rather than deciding on their behalf, essentially.

KASLIN FIELDS: And there's a DevOpsy thing there of trying to bring different skill sets together to make something better for everyone.

ABDEL SGHIOUAR: Yeah. I mean, the article even went further to say, have a PM. Hire a product manager to build the internal platform. Hire somebody who would be tasked with designing and deciding and getting the shareholders together to-- I mean, it comes natural to us, as people working for cloud providers. I think this is not only Google.

All the companies have some sort of PM role, but I don't think a lot of people really think about it. I think people think about product owners, or, like, scrum masters, which are totally different. A PM is its own thing. It's, like, somebody who owns the end to end life cycle of whatever that platform we're trying to build, and able to pull everybody in and get the feedback of everybody.

KASLIN FIELDS: I feel like it keeps coming back to that tools versus culture element of DevOps.

ABDEL SGHIOUAR: Definitely.

KASLIN FIELDS: And also kind of applies to platform engineering here too, of course, of what are the platforms that you're going to use? Nick mentioned in the interview that a lot of the times when you see a DevOps job, it's lifting a whole bunch of tools that you'll need to know. But then the concept is all about culture, bringing people together, and making things work better together. So it's kind of this intersection of those two over and over again.

ABDEL SGHIOUAR: Yeah. I have my own beef with the term "DevOps engineers."

KASLIN FIELDS: Yeah, don't we all.

ABDEL SGHIOUAR: I have tried to understand it over and over. I cannot for the sake of me know, what does it mean when you say DevOps engineer? Because most of the roles are just like, you need to know Jenkins and Terraform and stuff like that.

KASLIN FIELDS: However, when you say "platform engineer," that means something specific to me. You're creating a platform to serve developers.

ABDEL SGHIOUAR: I guess the term "platform engineer" makes more sense for me.

KASLIN FIELDS: Yeah. It does for me at least. Because if you say a DevOps engineer, I'm like, OK, are they your chief culture officer? Are they going around to different teams to figure out what's wrong?

ABDEL SGHIOUAR: Yeah, are they doing full stack? Which, there are probably seven engineers in the world that have that know how to do full stack. Yeah, but I mean, full stack is not only a front and back end. It's also your run environment and your CI/CD and everything. Like, they own everything.

KASLIN FIELDS: Yeah, it's kind of a catch-all term, so it could mean, really, anything.

ABDEL SGHIOUAR: And there are actually companies that does this, by the way. There are companies that intentionally will keep teams separate from each other and have everybody reinvent the wheel and build their own infrastructure and their own security and their own everything. And I mean, there are arguments to be made.

KASLIN FIELDS: DevSecOps.

ABDEL SGHIOUAR: Oh, yeah. Don't even get me started on that one because like, it sounds like whenever we don't know what to do with something we just add security to it because, suddenly, it would make sense.

KASLIN FIELDS: Yeah. I do find the term platform engineer very helpful. Like if I'm talking to a user, a company, and they say oh, you're talking to our platform engineering team, I'm like, that sounds like the right people. I know kind of-- I have some idea of what you're working on, so I find it useful in that respect.

ABDEL SGHIOUAR: It makes more sense, yes.

KASLIN FIELDS: Yeah. So I think it's a good term. I think platform engineering will continue to grow, and I'm excited about it. And I'm also still excited about DevOps, and I hope that there will be fewer job titles with DevOps in the name.

ABDEL SGHIOUAR: I hope so, as well. I hope we stop-- we stop inventing new titles, because that's what that seems like what we're doing.

KASLIN FIELDS: Unless you want to invent your own fun title. You're welcome to do that. But companies, maybe, maybe tone it down.

ABDEL SGHIOUAR: Yeah, just calm down a little bit. You know, I would be-- here is my hot take. I would be OK with going back to system administrator. I don't know what's wrong with system administrator.

KASLIN FIELDS: I do love system administrator. I love that title.

ABDEL SGHIOUAR: I was a system administrator myself. I am OK with that term. Let's just call them sysadmins. That's fine.

KASLIN FIELDS: You know, I did a survey of folks at one point when I was talking to a lot of different companies. And no one ever wanted to call themselves an infras person, an ops person. They didn't want to say that. They wanted to say platform engineering, or they wanted to say developer. They didn't want to use the terms of ops or infrastructure, which I found very interesting.

ABDEL SGHIOUAR: Because it sounds reductive in a way?

KASLIN FIELDS: I don't know. I don't know. It was just the result of that one poll that I did, which I mean, maybe not statistically significant. I'd have to do some analysis on that. It did have a good number of respondents, but still.

[LAUGHTER]

ABDEL SGHIOUAR: That's very interesting one.

KASLIN FIELDS: Yeah. I think there's something to explore there.

ABDEL SGHIOUAR: Yeah, probably.

KASLIN FIELDS: So thank you so much, Abdel. That was a great conversation. And we'll see you all next time.

ABDEL SGHIOUAR: Thank you very much.

[MUSIC PLAYING]

That brings us to the end of another episode. If you enjoyed this show, please help us spread the word and tell a friend. If you have any feedback for us, you can find us on Twitter @kubernetespod or reach us by email at <kubernetespodcast@google.com>.

You can also check out the website at kubernetespodcast.com, where you will find transcripts and show notes and links to subscribe. Please consider rating us in your podcast player so we can help more people find and enjoy the show. Thanks for listening. We'll see you next time.

[MUSIC PLAYING]