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

KASLIN FIELDS: And I'm Kaslin Fields.

[MUSIC PLAYING]

ABDEL SGHIOUAR: In this episode, we spoke to Mauricio Salatino. Mauricio is a software engineer at Diagrid, working on the Dapr project. We talked about Dapr, Crossplane, Vcluster, and a bunch of more things.

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

[MUSIC PLAYING]

ArgoCD announced that ArgoRollouts now supports version 1.0 of the Kubernetes Gateway API. With this feature, users can perform a Canary deployment using almost any ingress, gateway, or any service mesh using a single configuration. ArgoRollouts are a way for developers to perform progressive delivery on applications. A full list of supported providers is available in the show notes.

ABDEL SGHIOUAR: Google has released Gemma 2, the latest version of its Gemma family of open models. Available in both 9 billion and 27 billion parameter sizes, Gemma 2 is high-performing and more efficient at inference than the first generation, with significant safety advancements built in. In fact, at 27-billion parameters, it offers competitive alternatives to models more than twice its size, delivering the kind of performance that was only possible with proprietary models as recently as December.

KASLIN FIELDS: And that's the news.

[MUSIC PLAYING]

ABDEL SGHIOUAR: Today, we're talking to Mauricio Salatino. Mauricio is a software engineer at Diagrid, working on the Dapr project, but also serves as a chair for the newly formed App Development Working Group under the tag app delivery for the CNCF. He also serves as a member of the steering committee for the Knative and Keptn projects. Mauricio authored a book about platform engineering for Manning and co-authored some books on JBoss. He also worked for Red Hat and VMware in the past. Welcome to the show, Mauricio.

MAURICIO SALATINO: Hi, Abdel. Thank you very much for having me. It's a pleasure to be here.

ABDEL SGHIOUAR: Thank you. How am I with pronouncing your name? Am I doing--

MAURICIO SALATINO: That's pretty good. Yeah. I know that it's a very difficult name in English at least. And that's why most people know me by my nickname, which is Salaboy, which is a nickname that I used when I was a younger person playing online.

ABDEL SGHIOUAR: Yes. Does that mean something?

MAURICIO SALATINO: It doesn't mean anything. It's just my last name, and just boy, like the guy who is playing in a game.

ABDEL SGHIOUAR: Sure. So we were talking a few weeks ago when we met in Barcelona for Spring I/O. You are from Argentina, right?

MAURICIO SALATINO: I'm originally from Argentina, yes.

ABDEL SGHIOUAR: And you live in the UK.

MAURICIO SALATINO: I live in London nowadays, yes.

ABDEL SGHIOUAR: Nice.

MAURICIO SALATINO: And I've been here for like 12, 13 years already. So I feel that the UK is my home right now.

ABDEL SGHIOUAR: Nice. So the story for how this episode came to be is we were hanging out during the speaker activities after Spring I/O. And you were wearing a T-shirt that said Dapr.

MAURICIO SALATINO: Exactly.

ABDEL SGHIOUAR: And for me, whenever I see Dapr, I just associate it with Microsoft. So I came to you, and I was like, do you work at Microsoft? And you said, no. And I was like--

MAURICIO SALATINO: OK.

ABDEL SGHIOUAR: And then I was like, I've always wanted to learn about Dapr. It turns out, actually, there was another thing that's kind of interesting is that we know each other through another person.

KASLIN FIELDS: Exactly, yeah. For me, that's always fascinating, just to meet friends of friends. And in this case, it's a very old friend that I met in Chile, Alejandro Montenegro, who I know that you work with, because he's working in Google. And now he lives in Denmark.

ABDEL SGHIOUAR: Yes.

MAURICIO SALATINO: So people from South America are moving closer to Europe, and then just meeting other people, and getting to know each other. I just always find it fascinating that we have friends in common, that we share this common passion of learning stuff.

ABDEL SGHIOUAR: Yeah.

MAURICIO SALATINO: I met Alejandro in Chile, like for a Java Enterprise Edition course that he was teaching. And since then, we have been collaborating on stuff, contributing to open source projects. And I think that that's maybe one of the reasons why I'm here today.

ABDEL SGHIOUAR: Nice. I met Alejandro, I think, for the first time in KubeCon Copenhagen.

MAURICIO SALATINO: Nice.

ABDEL SGHIOUAR: It might be 2018 or something, or 2017. And yeah, then we ran into each other. We work together in the sense that he does a lot of community stuff. So sometimes I go to Copenhagen for talks or meetups or something like that. And we were literally having a call today, actually. The day of recording this episode, we had a call in the morning.

MAURICIO SALATINO: You see? I love this.

ABDEL SGHIOUAR: But today, we're here to talk about you.

MAURICIO SALATINO: Yeah, let's do it.

ABDEL SGHIOUAR: Let's get started. Because you have a very fascinating background. You started with JBoss, right?

MAURICIO SALATINO: Yeah, that's correct. So after finishing university in Argentina, I started getting into more like Java and stuff like that. I had the luck of having a professor in my university who was a Linux kernel contributor. And he set us up into this kind of open source journey. I quickly decided that I wanted to get involved into open source, but I noticed that the kernel was too low level for me. I really liked creating applications and stuff like that, like a little bit more high level.

And I get into system integrations, kind of a lot by looking into the Java specifications and all that stuff. And I started trying to contribute to open source. And in that place, we met with Alejandro, and we just tried to pick a random project. We started contributing with the security frameworks around JBoss, the JBoss application server back in the day. And since then, my main job and my goal in life in general is working for companies that are related to open source and contributing back to these communities that I find fascinating. But at the same time, as a developer, it's the place where I keep learning about new stuff.

ABDEL SGHIOUAR: Nice. So then you are the right person to answer this question, because I have heard people saying one thing a lot. I heard a lot of people comparing Kubernetes to JBoss.

MAURICIO SALATINO: Yes.

ABDEL SGHIOUAR: Is Kubernetes similar to JBoss?

MAURICIO SALATINO: Back in the day, like back in 2018, there were a lot of blog posts comparing these two things, coming from the Java perspective, coming from the Java application server space to something like Kubernetes. And the similarities are around running things, running applications for people. You have some sort of underlying layer that will run your applications for you. In that sense, you can compare Kubernetes with an application server.

But I think that communities have matured a lot. And taking some of that stuff from Java, taking some other things from other communities, what we have today with Kubernetes is a common application runtime, where you can just run containers, no matter in which languages they are written. And that's a big difference compared to the Java application servers, where you can only run Java applications.

ABDEL SGHIOUAR: I don't know much about JBoss, but does JBoss have this orchestrator kind of logic like Kubernetes? Would it restart applications if they fail? Can they distribute them across multiple servers and stuff like that?

MAURICIO SALATINO: The distribution part, yes. You could have clusters of application servers, and then you basically upload an application. And it will be replicated across this cluster. But conceptually, things will not be restarted. There needs to be some kind of-- on the operation side of things, restarting the application server.

Remember that each instance of the application server will run in a single JVM, in a single Java Virtual Machine. So if that crashes, the entire thing crashes in that node, and then all the applications that were running in that node will fail.

ABDEL SGHIOUAR: Got it.

MAURICIO SALATINO: But compared to Kubernetes, application servers used to provide other things to developers, like a programming model around how do you create applications for these things. So all applications in an application server will be able to use different mechanisms to understand which other services are available for service discovery, for example, and access to infrastructure, for example, using standards like JNDI, which basically gives you the address of where a database is.

So the developer creating an application doesn't actually need to know all the details about where that database is running. They have a string. And they will use that string to connect to infrastructure that's available.

ABDEL SGHIOUAR: Got it. So for those of you who doesn't know, JNDI stands for the Java Naming and Directory Interface, which sounds like a combination of an API and a service discovery mesh together kind of, right?

MAURICIO SALATINO: Yeah, yeah, exactly. And in Java EE 5, they introduce all this programming model about having beans that can be running across different nodes. So applications can instantiate a bean that will run in node B, but application A will be able to connect to that bean remotely using HTTP or using other protocols that we have in the Java communities.

Those programming models never popped up in the containers space, mostly because in Kubernetes, our interface on how we run workloads is the container interface. You know that we can run containers, but what happens inside the containers is not much of a concern for the runtime, in this case, Kubernetes.

ABDEL SGHIOUAR: That's actually an interesting explanation. It's good to see how much we progress, but we kind just reiterate over the same concepts, really.

MAURICIO SALATINO: Yeah.

ABDEL SGHIOUAR: Right?

MAURICIO SALATINO: But I think that the nice thing about Kubernetes is that it has democratized kind of all this orchestration layer across languages, which is something that I keep talking about in the Java communities. In the Java communities, they are great at creating interfaces and creating some sort of standard ways of doing things, but those things don't translate to other communities.

And in the case of Kubernetes, it's the other way around. We have a shared runtime. Now I think that-- I feel that after 10 years, we're going layers on top, just to provide this more concrete programming languages that can span across programming languages.

ABDEL SGHIOUAR: Got it. Got it. Nice. So then that's a really good segue toward the actual main topic of the podcast with this episode at least, which is Dapr.

MAURICIO SALATINO: Exactly.

ABDEL SGHIOUAR: What is Dapr?

MAURICIO SALATINO: I think that this is where-- like I wrote a blog post for Spring I/O about this exactly, Kubernetes and the comparison with the Java space, and then how Dapr comes to complement containers with these standard interfaces to access infrastructure and to solve common distributed application challenges that developers will face, no matter the language that they are writing their applications.

So Dapr stands for Distributed Application Runtime, and it provides these building blocks that will allow applications to interact with their environment in a way that is API-driven. You don't need to know what a database is or how to connect to a database. You can use the Dapr APIs to access that infrastructure.

And how it works is the normal Kubernetes extension model. You install the Dapr control plane into a cluster. And then Dapr will read workload annotations. So you can deploy your applications, add a label, and Dapr will basically say, OK, this application is interested in consuming the Dapr APIs. And it will inject a sidecar into the application pod so the application can access those APIs just from localhost.

ABDEL SGHIOUAR: Got it. You talked on the developer side. As a developer, you write the application, you use the Dapr building blocks to access, for example, database, right?

MAURICIO SALATINO: Yeah.

ABDEL SGHIOUAR: But on the up side, how would you deploy that? So how would you manage all of this?

MAURICIO SALATINO: From the application point of view, you now think about APIs. So you build your application logic, consuming Dapr APIs. And that could be just talking to a key value store, a database, or sending messages to a message broker, or consuming messages for a message broker.

From the operations side of things, it's like you have a cluster. Then you deploy the Dapr control plane into it. So Dapr is running. Some Dapr components are running in there in the cluster. And then you have the component model. Basically, we have a set of components that basically describe which APIs are available for these components to use for the building blocks.

So imagine that you want to provide-- give access to developers to a message broker. Then you create something that we call the Pub/Sub component that basically is a YAML file. Of course, it's like a Kubernetes resource that has the description of the type. For example, you can use the RabbitMQ implementation, or the Kafka implementation, or the Google Pub/Sub implementation for that component. And then you configure how Dapr will connect to the instance of Kafka, RabbitMQ, or Google Pub/Sub. That it's going to be used for your application.

From the developer point of view, they only see APIs. So this application will work the same if you deploy it locally in your local Kubernetes cluster with Kafka, or if you move the same application and configure it to run against Google Cloud, the APIs are the same.

ABDEL SGHIOUAR: Got it. OK. So those components, they have to be custom for each of those pieces of infrastructure, right?

MAURICIO SALATINO: This is kind of a very important question. So the components, like the APIs that we expose to developers, they are the same across all the implementations.

ABDEL SGHIOUAR: Those are standard. That's clear.

MAURICIO SALATINO: Exactly.

ABDEL SGHIOUAR: OK.

MAURICIO SALATINO: And then the components, you will specify the type. So you know how to connect to that specific resource that is running somewhere. If you want to connect to RabbitMQ, of course, that Dapr will need to have some kind of RabbitMQ client to be able to connect to the RabbitMQ instance.

ABDEL SGHIOUAR: Got it. So then the next question, is it the Dapr project that builds those integrations, or is it up to the cloud providers?

MAURICIO SALATINO: No. So the Dapr project already has implementations for the major cloud providers, and also includes Alibaba Cloud, but also includes standalone things that you might run on your own, like a Kafka cluster, or RabbitMQ, or things that people will just run inside their clusters. But if you take a look at the Dapr website, you will see all the implementations, also the supported implementations, and how up to standards they are, like how many features inside their APIs are supported.

ABDEL SGHIOUAR: Got it. Actually, I was looking-- while you were talking, I opened the Dapr components page, and I was looking-- because one of the questions I was going to ask, but then I looked it up, is, does it have access to secret stores? And it sounds like it does, right?

MAURICIO SALATINO: It does.

ABDEL SGHIOUAR: That would be very cool, because I published an article a few months ago about all the ways you can access secrets in GKE, which is our product. But then, of course, I mean, the best way to access secrets, generally speaking, in Kubernetes, is to never store them either environment variables or in the file system. It's to programmatically load the secret when the pod starts. And if Dapr can provide with that standard interface, that it doesn't matter which secret store you have behind, that's a very interesting thing, actually.

MAURICIO SALATINO: Yeah, that's it. And the beautiful thing that basically attracts me to Dapr, because you have these interfaces. When you talk about interfaces or APIs, you know that when you have the same API across multiple providers, then you start losing some of the features that each of the providers will provide.

With Dapr, what we focused on is to just to make sure that we can get 80% of the most common use cases with these APIs. And then we are in no way saying that you need to use these APIs for everything. If you have more specific use cases where you need to bypass these Dapr APIs and connect directly to the provider, you can do so. And you can do so via something that we call Dapr bindings that allows you to call the Dapr APIs, and then execute some custom logic on the Dapr side so you can do more custom operations.

But yeah, it's like IC, secrets, configurations, key value stores, pop-ups, and all these APIs-- that's like the basic layer of APIs that application developers will want to use. But if you look into what we are trying to solve nowadays, it's that we are just solving more common cloud native distributed challenges. For example, we added now durable executions or workflows. Now that you can store state and you can emit events, why not orchestrating these across different services, and just enable developers with higher level programming semantics via APIs?

We have the same for distributed logs. Imagine that if you're trying to create distributed logs across different languages, then you need to make sure that you use the same libraries across languages, and that gets complicated. So we are trying to provide all this functionality out of the box.

ABDEL SGHIOUAR: Got it. So my next question was going to be-- and since-- because I'm a network geek, do you have support for DNS registration in Dapr?

MAURICIO SALATINO: That's a very good question. I will check it out. I don't know if I have the answer for that. I think that we have some support, but I'm not entirely sure to which extent.

ABDEL SGHIOUAR: We could probably look it up later. It would be interesting if that's-- like, if you could annotate.

MAURICIO SALATINO: What would be the case?

ABDEL SGHIOUAR: No, not DNS inside Kubernetes. I'm talking about DNS outside Kubernetes. So a lot of-- the most common thing that people do is you deploy an ingress, and you need the IP address of that ingress to be mapped to a DNS somewhere domain. And a lot of times, the most common projects people use on Kubernetes is this thing called external DNS, which basically integrates all the objects inside Kubernetes with a lot of DNS providers outside. So it supports GoDaddy, and Google, and Amazon, and all of them. But it would be interesting if you could just use one tool--

MAURICIO SALATINO: Just to interact.

ABDEL SGHIOUAR: --to interact. One of the common problems, of course, is that the ecosystem of Kubernetes is so huge that people end up using a lot of tools that do one specific thing. And you have this fragmented problem where every tool is different, and the support for this is different. The community is different.

MAURICIO SALATINO: Basically, that's the topic of the book that I wrote on platforms, like combining multiple projects together. Basically, that's where people spend most of the time, choosing the right one. And then when you choose the ones that you want to use, then combine them together.

And I think that that's why in the book, I just lead the conversation to projects like Dapr that try to standardize across multiple providers. So you can make an easy decision to say, OK, I focus on APIs, then I will just configure with different implementations, depending where I'm running. I'm always closer to developers in the sense that I consider a developer myself, and I want to help other developers to have the right tools to be more efficient.

And for me, something like Dapr will give you that transparency across environments. You can run locally with Dapr locally running in a cluster, or even running outside the Kubernetes cluster. And then move that same application into a cloud provider, connecting to managed services. And the application shouldn't change. It should keep working in the same way.

ABDEL SGHIOUAR: Just work the same way.

MAURICIO SALATINO: With the different configuration, right.

ABDEL SGHIOUAR: Interesting. So it sounds like-- I mean, this is probably a silly comparison. It sounds like it's a cloud native JBoss, essentially.

MAURICIO SALATINO: It's a comparison that I guessed that at some point it will arrive. It's funny, because it wasn't created by the Java community. It was created in Go by Microsoft in 2019, and then donated to CNCF in 2021. And since it was donated, I'm amazed with the amount of people coming from different communities contributing. Between cloud providers and people coming from the Java community, people coming from the Rust community, and even people coming from Wasm. For me, that's a very interesting thing.

ABDEL SGHIOUAR: Oh, yeah?

MAURICIO SALATINO: When you run Wasm modules, because they are so restricted, imagine implementing database drivers from there. If they can interact with APIs, we will make their life of that ecosystem much easier, because they will not need to re-implement drivers or clients for connecting to common infrastructure that we use every day.

ABDEL SGHIOUAR: Got it. That's super interesting. Yeah, that's a very good use case, especially for WebAssembly workloads, right?

MAURICIO SALATINO: Exactly.

ABDEL SGHIOUAR: All right. But before that, you worked on a bunch of other things. And I'm interested in your time spent on Knative. What's the status of Knative right now?

MAURICIO SALATINO: So Knative is very mature. You know that the Knative project-- because you work at Google, I'm assuming that you know some of that-- they have different modules, different things. We have Knative serving. We have Knative eventing. And the newest blog there is Knative functions.

ABDEL SGHIOUAR: Tekton.

MAURICIO SALATINO: Yeah, we have--

ABDEL SGHIOUAR: We have Tekton, which is CI/CD.

MAURICIO SALATINO: Yeah. We used to have Tekton as a Knative build, then it was moved away. Knative serving on its own, it's extremely mature. It has been tested and battle tested for a long time now. I'm always proud to say that the Cloud Run, which is a project that I love, kind of like exposes the same APIs. And for me, that basically means that they got it right in a sense of, if we want to go from a container to a URL-- like, I give you a container; you give me a URL back that I can connect my application to-- that's the perfect example of something that is working, and it's working really, really well.

Then on the eventing side, there has been a lot of projects using that as well, and a lot of progress on that space with different providers, and enabling people to build this event mesh that are pretty complex. And then functions-- at the end, I was working with functions quite a lot with someone from Red Hat LUKS, who is leading that space. And that basically is trying to create that function experience on top of Kubernetes without pushing people to learn about containers, or Kubernetes itself, or YAML. The idea of Knative functions is giving you that quickly scaffolding of functions that you can quickly deploy into a cluster or run locally.

So that's usually the space that I'm always involved with projects on the developer side, making sure that they can work with Kubernetes easily. And sometimes by hiding that Kubernetes is there and simplifying the local development experience.

ABDEL SGHIOUAR: Nice. While you're talking, I just remembered something. I think-- I don't know if it's technically possible, but at least, theoretically, it would be possible to-- because Cloud Run started supporting sidecars very recently. So it would probably be possible if you have the Dapr control plan running somewhere to inject a sidecar into a Cloud Run.

MAURICIO SALATINO: That's something that I will be very interested in, because Azure container apps, they are already running Dapr in production in that way.

ABDEL SGHIOUAR: And that's the first time I heard about Dapr, because I was in a meetup, and there were two people from Microsoft presenting Azure Container Services, ACS. And they showed an app, like a microservice app. And they just injected Dapr to do cross application service discovery, and you know maybe a database. I don't remember what was the demo about, but that was the first time I heard about Dapr, actually.

MAURICIO SALATINO: Now I think that I have a demo to build with Cloud Run. I'm on this kind of mission. So I have two missions nowadays with the Dapr project. One is to get closer to the Java community. Again, as we mentioned before, Java, they already have all these interfaces and common ways of accessing infrastructure.

So when I was showing Dapr and mostly like the Java SDK for Dapr, people didn't feel that comfortable in looking into that, because it didn't fit into the Spring Boot programming model, for example.

ABDEL SGHIOUAR: Yes.

MAURICIO SALATINO: So what I'm trying to do now is I'm getting closer to the Spring Boot programming model to make sure that people can access to Dapr without even thinking about Dapr. They are thinking about, I want to send a message, or I want to store this state. I will just use the Spring way of doing things, just to get that on.

ABDEL SGHIOUAR: Yeah.

MAURICIO SALATINO: And the second thing that I want to build is basically bring the Dapr APIs to all the runtimes. As we were mentioning before, like, for Wasm, that would be kind of a great use case. For container services, that's the next thing. Cloud providers, they allow you to run containers. How do we provide the APIs at that level?

And the third one is Docker itself. I'm working with some Docker engineers to create a proof of concept where you are using, for example, Docker for Mac or whatever. You start a container, and you have a way to say, this container will need access to the Dapr APIs. So let's provide that outside of the Kubernetes cluster, because there is no technical limitations to do so.

ABDEL SGHIOUAR: Can you run the control plane of Dapr outside of Kubernetes?

MAURICIO SALATINO: Yeah, you can.

ABDEL SGHIOUAR: How would you run it, with KCP or something?

MAURICIO SALATINO: No, no, no. Just run a bunch of containers, and wire them together.

ABDEL SGHIOUAR: Oh, OK. So you can just Docker compose, maybe, something like that?

MAURICIO SALATINO: Yep, yep.

ABDEL SGHIOUAR: OK.

MAURICIO SALATINO: Exactly.

ABDEL SGHIOUAR: Interesting. So it doesn't really even need Kubernetes. That's cool.

MAURICIO SALATINO: It doesn't need Kubernetes. You will not have sidecar injection if you don't have sidecars in Docker. But if you wire things correctly, you can actually make that transparent for the user. So the user-- I like the idea of the user not needing to learn about Dapr if you are a developer. You just learn about the APIs, and you use the APIs in different runtimes. But you don't learn about all the underlying details, and injection, and all that stuff.

ABDEL SGHIOUAR: Yeah. That's technically, or theoretically, should be the platform engineering problem, not the developer problem, right?

MAURICIO SALATINO: 100%.

ABDEL SGHIOUAR: Yeah. Nice! You mentioned something that was very interesting. And I think only people who have done Java development in the past understand that. And I've done some Java stuff before. Spring is a super powerful framework in the sense that people who do Spring-- I think it's probably one of the few frameworks where people call themselves, I am a Spring developer.

MAURICIO SALATINO: Exactly.

ABDEL SGHIOUAR: Because it has its own way of doing things. And as a developer, you can just live within the Spring realm. And you don't really have to care about anything else.

MAURICIO SALATINO: Yeah, exactly. And those are the difficult communities, but the communities that I love the most, because they are very opinionated in the way that they work. And there is no reason for projects like Dapr, or even other CNCF projects, to get closer to those communities.

And I think that's a perfect segue to mention the Application Development Working Group that we are working on right now in the CNCF with a bunch of folks, which is, basically, we have that mission. We want to bring more and more developers to the CNCF space, get them closer to the projects, and start bringing all the knowledge that these other communities have into the CNCF space. And the perfect example in this case is that all these people coming from the Java background, creating interfaces, and creating different mechanisms to interact with infrastructure, we can take all that experience to validate the Dapr APIs, for example, and make those APIs super powerful.

ABDEL SGHIOUAR: Yeah. So that's a sub working group of the tag app delivery, right?

MAURICIO SALATINO: That's correct. It's newly formed. I'm working there with Daniel O. from Red Hat and Thomas Vitale, who is working for a Danish company as well. I know that you know Thomas, I think.

ABDEL SGHIOUAR: I know Daniel. I don't know about Thomas-- maybe.

MAURICIO SALATINO: Yeah. These guys are amazing, because they have access to a lot of developers in this space. I would welcome you, Abdel, if you want to join at some point, because what we need is we need people that is in constant communication with developers that understand their needs, and the gap between some of the projects that we have in the CNCF, and people who is actually building applications every day, their development cycles, and the tools that they are currently using. And what's missing there? How do we make their life easier?

ABDEL SGHIOUAR: Just a follow-up question on this. I don't know if you are thinking about it, but do you see this AI and ML having any direct impact on how Dapr progressing as project?

MAURICIO SALATINO: Nowadays, there are a bunch of communities. The Java community is super strong in creating now all the AI integrations with LLMs and common interfaces. I think that the Dapr project will go in that direction at some point. I think it's inevitable to think about, how do we abstract this away in a way that it's not language-- like LLM dependent. And we provide a set of features that are standard across different LLMs.

That's a possibility. I know that there were some proposals already in the community, but I'm really looking forward to see what comes in the second half of the year, and just try to collaborate with some of that stuff, too. I'm just keeping an eye on the entire CNCF community, because I know that that topic will pop up somewhere, right?

ABDEL SGHIOUAR: Yeah. And the reason I ask this is because other frameworks are going in that direction. Spring has now Spring AI.

MAURICIO SALATINO: Exactly.

ABDEL SGHIOUAR: There is that very popular LangChain and LangChain4j, which are also very popular, trying to kind of solve the same problem, making accessing LLMs standards across all LLM providers, the big ones.

One other use case I was thinking about-- and this is just food for thought. I'm not asking you to implement this-- is there is quite a lot of open LLMs that you can deploy on Kubernetes, like Gemma, or Llama 2, or Llama 3. You can just self-host them. So Dapr would be probably an option where you can just-- a component would be an LLM that you can just deploy, and then you have this standard interface, as you say, through an API.

MAURICIO SALATINO: Yeah. Remember that when we were discussing about Dapr and how it works, we didn't spend much time kind of taking into consideration the architectural benefits of doing that model, where we expose the APIs, but we also removed dependencies from the application. And I think that, again, in that case, in Spring AI, you just keep adding dependencies to the application to interact with an LLM.

In the case of Dapr, we will just keep reusing that model where you interact with APIs. You don't add dependencies to your application. And you let Dapr to manage those connections for different environments and different providers.

ABDEL SGHIOUAR: But you still technically have Dapr itself as a dependency, right?

MAURICIO SALATINO: So you can have it if you are willing to have it. So in the case of Spring Boot or Go, you can add the Go SDK or the Java SDK, but Dapr exposes gRPC and HTTP APIs. So in the case of Watson, in the case of Watson, you don't need an SDK. As soon as you can send HTTP requests, then you can access the APIs.

ABDEL SGHIOUAR: Oh, that's interesting. I never thought about-- I didn't think about that. OK. It almost feels like it's trying to do what service mesh does, but for infrastructure dependencies.

MAURICIO SALATINO: Yeah. That's a common thing. You will hear people comparing Dapr with Istio in some cases, because we have sidecars. We can do some networking as well. We provide mTLS, for example. The only difference is that we provide these higher level APIs for developers, where service meshes are all about networking, right.

ABDEL SGHIOUAR: Yes. That's more low level. Yes, yes, yes. OK, cool, cool, interesting.

MAURICIO SALATINO: And important to mention that Dapr and Istio can work together in the same cluster. And they will just work. You can disable all the mTLS stuff on Dapr, and run that with Istio. There is no problem with that whatsoever. Sometimes people think that it's one or the other, but, actually, they complement each other.

ABDEL SGHIOUAR: Nice, nice. I was reviewing one CFP for one of the conferences. I'm not to mention which one. And I saw somebody actually submitting specifically a proposal about Istio and Dapr.

MAURICIO SALATINO: Yeah.

ABDEL SGHIOUAR: And how they-- it took me a little bit of time, because I was reading through it. And I was like, what's the relationship between these two tools? And then I ended up on the documentation, and that's how I figured out what would you use Dapr and Istio for.

But just before we move on, you worked on a bunch of other stuff, like Crossplane, Vcluster, Open Feature, which we had an episode on on the podcast.

MAURICIO SALATINO: Yeah, yeah. So I love this project. I usually engage with this project, even because this is kind of also important in my career. I've been most of the time focused on a single project. When I worked at Red Hat, I worked with JBoss and some Java frameworks. When I worked at VMware, I worked full on Knative.

But I started realizing that I like connecting projects together. So I'm doing all these inter-project collaborations. And sometimes I want to integrate Dapr with Open Feature. So I go to Open Feature, and see the gaps, and see how can we work together. And then I just go and create some integrations there.

I started very early on with Crossplane. Maybe like six months after they announced the project, I was just there, because I realized that now using Dapr, it makes way much more sense. You can simplify using Crossplane compositions-- the idea of aggregate different resources together. In this case, we are aggregating the provisioning of cloud resources to the consumption of those cloud resources from APIs.

So I wrote a blog post there in the Crossplane blog about that, like, how do you create compositions that will give the developer maybe like that, like a string, on when they need to connect to a store state or send messages? You will provision something on Google Cloud. And then at the end of the day, instead of even getting a URL on how to connect to that, you just basically get a Dapr component that will be dealing with that. And it will be automatically wired for you to consume.

ABDEL SGHIOUAR: Interesting, OK.

MAURICIO SALATINO: It's all in that space of, how do you bring stuff together? How do you combine these tools without spending two months being an expert on both of the tools at the same time?

ABDEL SGHIOUAR: Got it. Got it. That's super interesting. Dapr sounds like-- it's a very interesting project from what you explained, because it sounds like it's trying to hide away the complexity of, basically, cloud infrastructure, generally speaking, from developers, right?

MAURICIO SALATINO: I'm phrasing it lately, because, again, the more I use it, the more I realize how people see this project. And for me now, what Dapr gives me is that cross-environment compatibility. It doesn't matter what I'm running.

From an application perspective, I know these APIs. And I can just move the application around different environments that can be in different cloud providers. As soon as the operation people configure the components for me, my application should work.

ABDEL SGHIOUAR: Yeah, yeah. And so can you briefly describe to our audience what Vcluster is?

MAURICIO SALATINO: Oh, yes. That's another project that I'm fascinated with. So Vcluster basically allows you to run clusters inside clusters, which is like cluster inception.

ABDEL SGHIOUAR: Inception, yes.

MAURICIO SALATINO: Yeah. Which is like mad at the beginning, but it kind of makes a lot of sense. I'm pretty sure that you have heard this discussion about namespace isolation, or multiple clusters.

ABDEL SGHIOUAR: For multi-tenancy-- yeah, yeah.

MAURICIO SALATINO: Exactly. And Vcluster sits right there in the middle. If you look into their website, you will see this table that basically says, with namespace, you have these isolation levels. If you have different clusters, you have these isolation levels. If you have a lot of clusters, you will pay a lot of money by running all the cluster control planes.

ABDEL SGHIOUAR: Yes.

MAURICIO SALATINO: And if you run namespaces, well, you will not have enough isolation. So what Vcluster does, it basically allows you to deploy inside a big cluster tons of different builds or clusters that you can give other users access to.

And how it works, basically, they deploy a new Kubernetes API server that provides that isolation. So when customers, or users, or different teams connect to these virtual clusters, they are interacting with their own Kubernetes API server. But the scheduler and everything else on the Kubernetes cluster is being used by the parent cluster.

ABDEL SGHIOUAR: Got it.

MAURICIO SALATINO: So it's kind of like-- again, it's an abstraction that allows you to give more isolation, like API isolation level at this point. My contribution to that project was around that, about how do you-- for example, even if you have a V-- because the problem that you will have is that Kubernetes clusters on their own, they don't do much, right? They just run workloads.

ABDEL SGHIOUAR: Yes.

MAURICIO SALATINO: If you need to install Knative into it, or Dapr, or Crossplane, well, then you're installing Crossplane tons of times, as many virtual clusters as you have. But what you can do with Vcluster is you can reshare an installation of these components on the host cluster. So in the parent cluster, you can install Knative, Dapr, and all that stuff. And then give access to virtual clusters to all these functionality.

ABDEL SGHIOUAR: Got it.

MAURICIO SALATINO: And that's pretty amazing.

ABDEL SGHIOUAR: Would Vcluster do isolation by having dedicated node pools for each virtual cluster?

MAURICIO SALATINO: No, they don't. They just isolate on API level.

ABDEL SGHIOUAR: So it feels like it's virtualizing the control plane, really.

MAURICIO SALATINO: Yes.

ABDEL SGHIOUAR: The data plane is still from the host cluster, right?

MAURICIO SALATINO: Exactly.

ABDEL SGHIOUAR: Interesting.

MAURICIO SALATINO: And the scheduler, too.

ABDEL SGHIOUAR: OK.

MAURICIO SALATINO: Which is-- of course, it has its own limitations, but at the same time, it gives some clear advantages if you are looking into that multi-tenant scenario where you are building a SaaS, and then you want to give a cluster to each of your customers. Then you need this kind of stuff, unless you want to create separate clusters for everyone.

ABDEL SGHIOUAR: Yeah, I see the value. I understand the value. I was just curious about how does it ensure isolation. It sounds like Vcluster is a topic we should bring somebody to talk about on the podcast, because--

MAURICIO SALATINO: You should.

ABDEL SGHIOUAR: --all the other topics we have covered before.

MAURICIO SALATINO: Yeah, I think that having someone-- Fabian, like the CTO of Loft, it's great. He's an amazing engineer, and he can go really deep into the different isolation levels. I know that they have different modes on how you can run Vclusters. So yeah, he will be perfect for that.

ABDEL SGHIOUAR: Yeah, we should probably do that. Yes. Cool! So I don't want to waste more of your time. I just want to ask you one final departing question.

MAURICIO SALATINO: Let's do it.

ABDEL SGHIOUAR: What excites you for the next decade of Kubernetes, generally speaking, on cloud native?

MAURICIO SALATINO: Wow. So this is super interesting. I spent two years writing the "Platform Engineering on Kubernetes" book. And I rewrote it three times in two years, from zero, from scratch, because projects kept changing. When I started, I started with a couple of projects that they were not existent by when I finished.

So it was kind of interesting for me. I always try to look into the next year, maybe just for me to know where to work and how to do stuff. But as I mentioned in the beginning, I strongly believe that we are bringing more developers closer. And developers are now way much more interested, because they have been learning about Kubernetes.

When you go to Spring I/O, or different conferences in different languages, now people know about Kubernetes, which makes me think that we can start building these higher layers that will simplify how people interact with all this complex infrastructure. And I feel super excited about that, because after 10 years, it feels like this is the right moment to simplify what we have, and again, just to bring new communities closer, and just try to bring new people closer to these projects that are amazing and are open source so they can contribute.

ABDEL SGHIOUAR: Yeah. It's actually-- the thing I say to my colleagues a lot is some of my favorite conferences are the conferences that are not necessarily about Kubernetes, because then you get to meet people who have been doing things in whatever framework they use for a very long time. But now Kubernetes is around, and they have to learn it. And it gives two people coming from two different sides, but kind of have to learn how to talk to each other, right?

MAURICIO SALATINO: Exactly.

ABDEL SGHIOUAR: So before going to Spring I/O, I had to learn a little bit about Spring to understand what it does.

MAURICIO SALATINO: But it's funny, because you go there, and then you actually start understanding this other community's mindset. In the Spring case, they even kind of like include buildpacks now to create containers, from Spring itself. So you can actually run a command to create a container from your Spring Boot application.

But they stop there. It's like, OK, you can create a container, and then somebody will run it somewhere. It doesn't really matter where, but building that next layer, I think that it's extremely important. That's why APIs, I believe that that's one way. And then common development practices that might be coming from different communities, it's, for me, the next stuff.

ABDEL SGHIOUAR: Nice.

MAURICIO SALATINO: I went to-- I did a lot of Java, then I moved to Go for all the Kubernetes building controllers, and all that stuff. I used, for example, Google code for creating containers. And every time that I go back to the Spring community, I tell them, look at Go. This is so amazing. It does so many things for you. If you are deploying containers into clusters, this is kind of the experience that I want.

But again, they have strong opinions on how they want to shape the development experience. And they have their own tools to do that. So for me, learning from different communities, trying to share that knowledge, and just help developers in general, it's my day to day job.

ABDEL SGHIOUAR: Nice. Is there any integration? Or do you see any possibility for integration between Dapr and Testcontainers?

MAURICIO SALATINO: My friend, you are making my life easy. That's already done. So I worked with the Testcontainer folks. It was kind of like a great experience. I started collaborating with them before they were acquired by Docker. And now I feel like I'm a very important person, because I'm working with some Testcontainer folks inside Docker.

But no, seriously, like we created the Spring Boot and Testcontainers integration. We presented that with Thomas in Spring I/O, which basically allows us to run Dapr outside of Kubernetes, right?

ABDEL SGHIOUAR: Yes.

MAURICIO SALATINO: You start your application, your Spring Boot application locally, and it will automatically start Dapr for you, so you can use the Dapr APIs.

ABDEL SGHIOUAR: Nice, nice. Yeah, Testcontainers is one of my favorite projects, actually. It's really cool. I really like it.

MAURICIO SALATINO: It's really cool. Now they have the Go integration. They have the .NET integration, too. And in that space, maybe-- I don't know if you had someone from Dagger in the past. I did some collaborations with them, too, because they are coming from a different angle, which I also find fascinating. I always try to not compare between these two tools, because you can do something similar coming from different backgrounds and with different objectives. But if you haven't had anyone from Dagger, I strongly recommend you to check that out, too.

ABDEL SGHIOUAR: I don't want to spoil it up, but we might or might not be working on that, actually.

[LAUGHTER]

MAURICIO SALATINO: Awesome.

ABDEL SGHIOUAR: Yeah. We are-- specifically, the person at Dagger.

MAURICIO SALATINO: Perfect. That's great.

ABDEL SGHIOUAR: Yeah. So there will be an episode at some point talking to somebody that, frankly, should have been on this podcast since it started, but he was never here for some reason. And I just reached out to the person on Twitter. And he was like, yeah, sure, just let me know. Here is my email.

MAURICIO SALATINO: Perfect.

ABDEL SGHIOUAR: Nice.

MAURICIO SALATINO: I'm really happy to hear that, because, yeah, that project is coming strong.

ABDEL SGHIOUAR: Yeah, yeah. It's making a lot of noise, right?

MAURICIO SALATINO: Making a lot of noise. And again, it just touching developers in an interesting way. So I'm all in for that.

ABDEL SGHIOUAR: Yeah. I think I agree with you in the sense that I think that one of the potential futures of Kubernetes and cloud native is being closer to developers, because Kubernetes was never actually built to be a developer friendly tool. It is, arguably, the least developer friendly tool around.

MAURICIO SALATINO: Exactly. But I think that communities are doing a great job around that, and it's coming up together. And now with the massive adoption, we just need to do it, right?

ABDEL SGHIOUAR: Nice, nice. All right, so we'll link all your socials. We'll link the talks and the blogs you talked about. Go check out Dapr. I think it's pretty cool. And thank you for being on the show, Mauricio.

MAURICIO SALATINO: You know, if you at any time want to contribute to open source and if you're interested in that, feel free to reach out as well, because I love helping people to get into open source. I'm happy to mentor anyone there, and just try to assist in any way I can.

ABDEL SGHIOUAR: Awesome. Thank you very much for being on the show.

MAURICIO SALATINO: Abdel, thank you very much.

[MUSIC PLAYING]

KASLIN FIELDS: Thank you, Abdel for that interview. Dapr is definitely one of those projects and scenes that I don't know much about. And judging by your conversation, I can kind of see why. It feels like it's in an area that I don't delve into very often. So I don't know that I fully understand it yet, but we're going to work that out.

So according to the CNCF page on it, Dapr is a portable, event-driven runtime for building distributed applications across Cloud and Edge. And I like that you talked a lot about Java and language communities. So it feels like a very developer tool in the infrastructure world. What do you think, Abdel?

[LAUGHTER]

ABDEL SGHIOUAR: It's pretty much-- yes, it is that. Yeah, it's an intelligent layer for building distributed applications. And it solves a bunch of traditional distributed application problems, like service discovery and a bunch of other ones. But I think the key thing that you mentioned is that it's language agnostic, or it's agnostic in a way. You can use it with any programming language you want, which is, I think, what makes it cool.

To be honest with you, I didn't really know much about Dapr up until when I talked to Mauricio. The only time I saw a demo was in a meetup where some people from Microsoft did a demo about it. They have something called Azure Container Services, I think, ACS if I remember correctly, which is sort of like Cloud Run.

But with ACS, you can actually deploy multiple containers as a single unit, because in Cloud Run, you can do like one service is one container. But in ACS, you can build multiple applications running on multiple containers, and you can deploy them together. And they support Dapr out of the box for making these containers talk to each other.

And you can think of it as kind of like Docker Compose, but it's ended up deploying on Azure. And I saw Dapr. And I was like, oh, that's pretty interesting. And then in my head, it stick that Dapr means Microsoft for some reason, right?

KASLIN FIELDS: Yeah.

[LAUGHTER]

I looked it up, and it did start there.

ABDEL SGHIOUAR: It started there.

KASLIN FIELDS: I think there's a reason for that.

ABDEL SGHIOUAR: Yeah. So the story of how this podcast came to be is I was at Spring I/O, so the conference in Barcelona. And it was during the speaker activity, which is at the end of the conference, hanging out. And Mauricio was wearing a Dapr T-shirt. So I walked to him, and I was like, do you work for Microsoft? He said, no. I was like, let's have you on the podcast. That's it.

KASLIN FIELDS: Yeah. You mentioned that in the interview.

ABDEL SGHIOUAR: Yes. That's basically how it happened. Yeah, it was very interesting.

KASLIN FIELDS: So we're learning about something new today. So there are so many technologies that you mentioned there that I'm familiar with, but I'm trying to parse together in my head how they all relate to come together into this concept of Dapr. So you mentioned Docker Compose in the interview. You also mentioned JBoss, which I was not familiar with at all. I started out in Java when I was doing my computer science degree, but it's been a long time since I've worked in Java.

[LAUGHTER]

And so that was not something I was very familiar with. And then applications talking to each other brought me back real quick to the early days of Docker. And trying to figure out how to get Docker containers to talk to each other was such a pain in the early days. And then there's gRPC is one way that people figured out for applications to talk to each other.

Our microservices demo from Google Cloud is one that we use a lot. We also call it online boutique. And it's really great, because I like using it as like-- microservices are you take the application you want to build, and imagine creating an architecture diagram of the pieces of that application. And basically, those different pieces become different services on the microservice architecture.

But that demo uses gRPC for the different components to talk to each other, which, honestly, has always blown my mind, because I think of gRPC kind of in a hardware world, of you have small little devices that maybe you're playing around with, and you need those different devices to talk to each other. I think that's a very common use case of gRPC.

ABDEL SGHIOUAR: Yes.

KASLIN FIELDS: But in the fully software defined world of applications, getting the pieces to talk to each other, one, we know can be very difficult. And so you have things like gRPC to do that. But then Docker Compose was a way, like you were saying, of creating multiple containers, and deploying them all at the same time, kind of together, and kind of defining--

ABDEL SGHIOUAR: As a single unit.

KASLIN FIELDS: Yeah. How they work together. So at first when you said that, I was like, so they have pods? But it sounds like no.

ABDEL SGHIOUAR: No, no. In ACS world, they're just containers. It's just, like, yeah. Think about it as Cloud Run, but you can run multiple containers inside the same service.

KASLIN FIELDS: OK.

ABDEL SGHIOUAR: Because in Cloud Run, it's one service, one container. But with this ACS thing, it's just like they have their concept of service. They call it service. It's just the terminology they use. And then inside the service, you can have 1, 2, 3, 4, 5, 10 containers. It doesn't matter.

And I think they call it applications, if I remember correctly. And I am quite sure they use Kubernetes behind the scene, but they don't expose the Kubernetes API to people. So they expose a custom API that allows you to interact with the service without-- basically the same way we expose the Knative API for Cloud Run, essentially.

But you mentioned the points very good. So the microservices demo, that's a very good example of where Dapr can fit in. So if I remember correctly, the microservices demo was mainly built not only for this reason, but it was mainly built to demonstrate service mesh, because the whole point of the microservices demo is that it's multiple microservices written in multiple languages, and then you can hook them together using Istio. So you can think of Dapr as Istio++.

KASLIN FIELDS: Interesting.

ABDEL SGHIOUAR: Except that it's not at the infrastructure level. It's at the application level. So a service mesh tries to disconnect network intelligence from the application and bring it down to the infrastructure level. That's most what service mesh does.

Dapr is an application level thing. So it's a library that you import into your app, and you do it-- you use it inside your app. So to be honest, it's Istio+, Docker Compose++++, OpenTelemetry [INAUDIBLE]. It's a whole thing.

KASLIN FIELDS: Interesting. So I think clarifying the difference between pods and this might be important. So in Kubernetes pods, one thing that I like to explain to people because I think it's an easy gotcha for folks is you usually think about pods as a single container, but it's not. It's multiple containers that are treated as a single unit by Kubernetes.

ABDEL SGHIOUAR: Correct.

KASLIN FIELDS: Which means that all of those containers share the same IP address. They share the same storage space. They share the same networking resources. All of the things that can be shared, those containers share. And so that's, I think, why a pod would be kind of a lower level than what Dapr is here. It sounds more like the pathways between these containers are more strictly defined than just you have everything. It has maybe more nuance to it than that in the ways that you define how the applications are connected to each other.

ABDEL SGHIOUAR: Yes. This is a very good example that you're mentioning. So let's say you are deploying an application on Kubernetes. On Kubernetes, you have the Kubernetes services, which is the API in Kubernetes. And that acts as both a way to do load balancing, but also as a way to do service discovery, because when you create a service, there is an associated DNS entry that was created for that service.

So let's say your service is called backend. And it lives in the default namespace. So then to call the pods behind the service called backend, the call becomes backend.default.svc.cluster.local. So that's the default FQDN in Kubernetes. So that's the service discovery mechanism. That's making one application find another through DNS.

But that's only Kubernetes-specific. What if you run this application somewhere else? What if you run it on Cloud Run? And what if you run it on, I don't know, Azure? Or you run it on VMs?

So Dapr, one of the things it tries to solve is this portable service discovery across platforms. So you don't have to rewrite your app logic for-- I mean, this is a very tiny component, of course, but just to make it kind of more easy to understand for people. It's just one of the things that Dapr does, but it does a bunch of other things.

KASLIN FIELDS: I find this really funny. And now I'm thinking that we've got the pods component of you've got multiple containers, and how do they connect to each other, entirely within the Kubernetes world. And then you've got the services component, how we define how you find services, and how you connect to them. Interesting. But Kubernetes is kind of at a lower level there.

ABDEL SGHIOUAR: Yeah. So it's really for developers. And I played with it a little bit after I talked to Mauricio, but then, of course, I had so many things going on between when we did that interview and now, so I mostly forgot all of it. It's pretty cool. I think you have to be in that mindset of developer trying to achieve something that is agnostic or agnostic, both in terms of cloud and technology, to really understand what the added value of Dapr-- what does Dapr give you.

KASLIN FIELDS: Interesting.

ABDEL SGHIOUAR: But what I find fascinating is the fact that Mauricio was in a Java conference. And that goes to the point where we're talking about JBoss, because I don't remember if we talked about this in the interview, but I've been going enough to Java events that I am-- this is a fact. We're not making things up, and we're not saying something bad about the Java community.

Java as an ecosystem has this very interesting set of frameworks that allows people to just live within that framework. They don't really have to learn anything else. So Spring, for example, you learn Spring. You use Spring. That's it. That's all you need. Spring gives you everything. It gives you object-relationship mapping. It gives you service discovery. It gives you security. It gives you everything.

So I find it interesting that they are inviting somebody who is not from the Java world, like Mauricio and myself, of course, coming to say, oh, yes, people, there are things outside of Java. And I find that's quite fascinating. I find it interesting that the Java community that lives in this world where the ecosystem is enough for what they're trying to achieve are actually willing to listen to other things.

KASLIN FIELDS: Interesting. I want to say, well, you kind of have to, right? At some point, Java is built on top of other things. And it interacts with other things. So you've got to get out of that bubble at some point. But it is a fair point that Java has done a lot to enable it to create a bubble.

ABDEL SGHIOUAR: Yes.

KASLIN FIELDS: The JVM even.

[LAUGHTER]

ABDEL SGHIOUAR: Yeah. So actually, a funny story that I think I told you this before. I was invited to a conference in the Netherlands called J-Spring last year. It's a Java conference that happens in spring, so hence why they call it J-Spring. There is another one that happens in fall.

KASLIN FIELDS: And there's the whole Spring Boot thing.

ABDEL SGHIOUAR: No, no, not spring the boot. Spring the-- like the time of the year, right? Java spring.

[LAUGHTER]

Or is it? No, but I know it's the case, because they have another one in November called J-Fall.

KASLIN FIELDS: There you go.

[LAUGHTER]

ABDEL SGHIOUAR: Anyway, so I was invited by the organizer, and he was like, come talk about Kubernetes. I'm like, what am I going to talk about Kubernetes to Java developers? And he was like, figure it out. I was like, OK.

So I decided what I'm going to do is I'm going to basically show people what my developer set up for Kubernetes looks like. So the tooling I use when I'm writing Kubernetes apps. Just basically my developer setup. That's it-- very, very simple.

And the thing with my setup is that it's pretty much language agnostic. I'm not using anything specific to a programming language. I'm using Skaffold, which is whatever language you want to use it with. I'm using a bunch of-- so I showed up. I have 45 minutes, and mostly demos.

So I showed up to the room. And I was like, all right, so we're going to do this, and blah, blah, blah. And I'm going to kubectl command line. And by the way, if you want to switch context, kubectl allows you to do that, but it's very complex. So I use this thing called kubectx, which is just a CLI for switching context.

And then I looked at the room, and no one was like-- I didn't get any motion. And I'm like, does anybody here know what kubectx is? And they were all like-- raise your hand if anybody used kubectx. No one raised their hand.

And I'm like, I'm going to show you this and stop, because my work is done here. If you learn one thing from today's talk, it's kubectx. The rest is optional. The rest is not very important. So it was just very funny for me that I was like-- what to me sounds obvious is not to a lot of people, right?

KASLIN FIELDS: A very good example of when you're giving a talk, be prepared to ask the audience if you're at an OK level for them, if they're able to follow along, and if not, be prepared to bring them along with you.

ABDEL SGHIOUAR: Yes, yes. It was just super interesting. I mean, I think it was-- I mean, we deviated a little bit from that in the interview, but I think it's really cool to be able to hang out with people outside of your comfort zone, because you also learn stuff.

KASLIN FIELDS: It sounded like Mauricio also has background in the Java community, so still relevant.

ABDEL SGHIOUAR: Yes, yes, of course.

KASLIN FIELDS: And shout out to Java communities. I also went to a Java user group meetup once upon a time long, long ago-- helped to do some stuff with that meetup, and it was such a wonderful welcoming group. So shout out to Java communities.

ABDEL SGHIOUAR: Yes. I think a lot of people misinterpret Java, and say that Java is lame. It's not. It's a really cool programming language, in my opinion.

KASLIN FIELDS: Yeah.

ABDEL SGHIOUAR: But then I'm getting old, so that's probably why.

KASLIN FIELDS: Yeah. Every programming language has its-- I don't know-- idiosyncrasies.

[LAUGHTER]

ABDEL SGHIOUAR: Of course, of course.

KASLIN FIELDS: Its unique aspects that make it difficult for folks outside of the community to understand it. But once you get into that, if you come willing to understand it, I think you can find folks who want to get you involved.

ABDEL SGHIOUAR: Yes, yes. Yeah, that's pretty cool.

KASLIN FIELDS: Wonderful. And I look forward to chatting with the Dapr folks at our next CNCF event.

ABDEL SGHIOUAR: Hopefully, well, if you listened up to this point of the interview, and you are at KubeCon North America, come chat with us. If you are a Dapr user, please come explain to us what you use Dapr for. Because we did an interview. We still don't know what's going on.

KASLIN FIELDS: We've got a baseline, and that's a start.

ABDEL SGHIOUAR: We got a baseline, yes. I mean, we're developer advocates. We can pretend to know what we're talking about. Confidence is 50% of-- I don't know. I'm not going to project my things on you. 50% of my personality is confidence, right?

KASLIN FIELDS: I mean, in a podcast, all you want is to get a baseline. And from there, we can figure out cool things to do with it. So I hope you enjoyed the journey today, folks.

[LAUGHTER]

ABDEL SGHIOUAR: Yes. And yeah, there will be more cool interviews coming in the pipeline.

KASLIN FIELDS: You mentioned that.

ABDEL SGHIOUAR: Yes.

KASLIN FIELDS: Giving away some hints, aren't we, Abdel?

[LAUGHTER]

ABDEL SGHIOUAR: No, I'm not going to spoil it. I'm just going to keep it for myself. The person hasn't responded to me yet, so we'll see.

KASLIN FIELDS: All right. Thank you, everyone.

ABDEL SGHIOUAR: Thank you.

[MUSIC PLAYING]

KASLIN FIELDS: That brings us to the end of another episode. If you enjoyed the show, please help us spread the word and tell a friend. If you have any feedback for us, you can find us on social media, @kubernetespod, or reach us by email at <kubernetespodcast@google.com>. You can also check out the website at kubernetespodcast.com, where you'll 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. And we'll see you next time.

[MUSIC PLAYING]