 Welcome to the Cube's coverage of KubeCon EU 2024, live from Paris, France. Join hosts Savannah Peterson, Dustin Kirkland, and Rob Strzece as they interview some of the brightest minds in cloud-native computing. Coverage of KubeCon cloud-native con is brought to you by Red Hat, CNCF, and its ecosystem partners. The Cube's coverage of KubeCon EU 2024 begins right now. Good afternoon, cloud-native community, and welcome back to KubeCon cloud-native con, CNCF's flagship event here in Europe. We are in beautiful Paris, France. My name is Savannah Peterson, and I'm joined by brilliant analyst, Dustin Kirkland. Dustin, what a week we have had. I'm telling you. The wine, the cheese, the Kubernetes. What more can you ask for? What more can you ask for? Actually, well, we could ask for a really great guest, and thankfully we have one sitting on my right. Jeff, thank you so much for joining us today. Oh my gosh, you're far too kind. What a great opportunity to spend a few minutes with you. Yes, and it's been a really big week for you. You announced you're joining CNCF, correct? Yeah. It's a big moment for the GraphQL community and GraphQL Federation, I think. There's so much cool stuff happening in this world. Often we don't think about API, when we think about APIs in the context of the DevOps world, we might think about how do we secure those APIs, or how do we make sure they're scalable. But I think more and more people are talking about API ops. We're talking about how we can get more value out of our APIs. And we're talking about how we can take a platform engineering mindset to APIs. And it's this whole world of how do we go from the imperative world of the past to kind of the declarative world of the future. And I just think there's such an alignment between the way that folks in the CNCF community are starting to think about the stack of the future and what's been happening in the GraphQL community that's the right moment for us to bring those worlds together. And what's the reception been like since you had made that announcement? Very positive, it's there's, I think for some people it's a new idea to think that there's more that we can do with our APIs than just making sure that they're scalable and secure. But when you look at the way people are, when you look at the demands that come from AI, for example. Yeah. You know, I think about, you know, my take on AI, my hot take, I think a lot of what drives our fascination with AI is really personalization. It's the idea that instead of, I have to use an app that somebody else built for me. Some product manager interviewed a bunch of users and then it took a couple quarters but we were eventually able to build three or four features, maybe a quarter, something like that. What if those features aren't the features I want? What if I want to do something that, you know, is my unique take? If we can have apps or however we use computers, it's really personalized to us that's flexible, that's contextual. That's the experience everybody's trying to do. But you just can't deliver that with the technology. We had in the past, we need new ways to build technology faster, to bring all of our business capabilities like forward to an end user in a way that's a lot more flexible. And that's what's driven the interest in API ops, I think. And there's a lot of similarities with what's going on in DevOps. And I think that's really connecting for a lot of people when they think we can do more with our APIs if we just take some of the same platform engineering mindset that's been so powerful in the Kubernetes community and see how that could be applied more broadly. You're saying we can do better than Clippy, right? Oh, we were talking about AI turning humanity to paperclips. I think we're a long way from that. I think if I think about where I see AI being applied the most, it's people want to figure out how they can use AI to drive developer productivity. How can we make it easy for us? But at the same time, we're not ready to trust the AI. So what are these co-pilot models where we can use this technology to build apps faster but in a way that keeps us safe, lets us get experience with the technology, gets us immediate benefits, but also builds towards something bigger later? Yeah, and you see that plugging into GraphQL and driving better GraphQL code. Yeah, absolutely. I mean, when some people think about GraphQL, they think about using it as a front-end technology. And the reason why front-end developers love GraphQL so much is front-end developers have a big problem, which is we have so many microservices now, so many APIs, so many databases. It's all over the place. A front-end developer, their job is to put all of that on one screen. A user isn't going to click 14 times in order to do what they need to do. And we also can't do 14 round trips from the front-end to the back-end. That's really unacceptable for a latency point of view. We've got to do one round trip. And so the front-end developers have these need for these integration APIs. The front-end developers, if you're a back-end developer, you're constantly getting tickets from the front-end team saying, I want you to tweak my API a little bit or combine these fields in a different way. And that results in a huge amount of code that you have to write, just to, you know, you want to build new APIs, you want to make them scalable and secure. But the front-end developers and the UX designers keep on redesigning the apps and you need to put it together a different way. So the front-end developers want a declarative way. They want a query-based way that they can query the APIs. Yep. The problem is, how do we deliver that? We can't just go make a big Graph server. We need this. The thing that's really made GraphQL take off is this idea of GraphQL federation. The idea that we can take a platform engineering mindset or an API ops mindset to this, where we can take all the APIs in our enterprise and connect them all together in kind of one connected virtual abstract view that we call the SuperGraph, one schema. And now the front-end developers can just query whatever they want and get it without us having to build APIs for them. So the big challenge is GraphQL federation is now proven at scale. It runs some of the most important applications from some of the world's largest enterprises, a lot of the products and services we use every day. The question is now, people are saying, I'm going to get back to AI in a second. You're great. It's like, you put, it's not how do I put, today, it's not how do I put one, two, three APIs on the SuperGraph. It's how do I put 30, 40, 50, 60? How does a platform engineering team get all the APIs in the Graph and empower everybody in the enterprise to do it? But that complexity, that's the thing that a machine is always going to be better than a human at trying to manage all of that interconnectivity and complexity, right? Exactly. The transformation that's happening in APIs now, to me, is similar to what happened in the early 80s with the relational database. Before the relational database, yeah, you had all your data and individual files on your mini computer. Yeah, your little silos. And if you wanted to run a query, you had to call in your COBOL programmer to write a new COBOL program to join that data. And eventually, you're doing so many things with all that data, you need a declarative query language. That's what GraphQL is. It's about saying, let's make our query planner be a piece of software, not a human being. And data made that transition, APIs have to make that transition because we're trying to do so much, if we can put this query planner, this graph router in front of all our APIs, we can make those APIs so much more powerful to the end user, we can also make them more secure, we can make them more performant. And that's why this is becoming an essential element of your infrastructure. And you don't want to just leave this to the people building the APIs, you want to empower those folks, give them this declarative way of letting people query the APIs, it becomes so much more valuable. Absolutely, and you providing that value for some of the biggest companies on the planet, correct? Yeah, everything from Intuit to Wayfair to Netflix to Major League Baseball, the Sony PlayStation, a lot of the products and services we use every day. Casual brand drops. When I was looking at your website, it was one of those moments where I went, ooh, you fancy. Social proof is all over it. Check it out here. I mean, literally brands we use every single day. I've got some really interesting data here. So it's half the Fortune 100, Embrace, GraphQL, and everything else is growing too, looking at these metrics that you all sent in. By 2027, more than 60% of enterprises will use GraphQL. So it's already the big companies, but it's about to be everyone. It's going to be ubiquitous. You know, and today, we think about 30% of enterprises using GraphQL are growing to 60% over the next three years. But a lot of that usage of GraphQL right now is it's in small ways as a point solution. It's just letting the front end developers query a little bit of data for maybe one API. That's kind of the classic way of thinking about GraphQL a lot of people have heard of. I just want to get less data duplication on the wire. I want to write apps a little faster. It makes react app development a lot easier. But the even more interesting stat is of the enterprises using GraphQL, in the next three years, Gardner believes that the percentage using GraphQL federation, which is where you're composing all the APIs into one super graph, is going to grow from 5% to 30% over the next three years. So this reflects the transformation we're seeing in APIs. API, and this is the bigger idea of API ops and platform engineering for APIs. It's going from APIs is just something to connect point A to point B to a way to connect all of our APIs into one unified declarative view. So we can make these declarative queries against the whole super graph. And that's just getting easier and easier and easier, more and more scalable. And that's really the thing that's taking off is you listed some of our, we were talking about some of our customers. Why are people trying to do it? Because they want to deliver better experiences for their end users. Whether they're doing that traditional app development or whether they're doing that with AI, it's all about delivering these really personalized, contextual experiences. So it's not one size fits all. You're getting a great experience to your end user. The only way you can do that is by combining all your APIs to create great experiences. And at some point, the old paradigm where I'm going to write a backend for front end, I'm going to write an experience API or an integration API for every use case. At some point that becomes so much maintenance cost, it becomes so hard to secure. It's an enormous attack surface. You got to move to this approach. And it's going to drive this, kind of like how big data was a new chapter for data. We said, we've got all this data. Now we need to bring it together and get insights out of it. That's what's about to happen with APIs. You couldn't do that with data until you had enough data. The same APIs is what's next because we've got all these APIs. Now it's about how do we get this value out of them? How do we deliver incredible experiences, new types of solutions on top of all the APIs we have? And that's what this enables. And I think you said before we came on that you see platform engineering going mainstream in 2024. Is this what you mean by that? Yeah, I mean it's all about moving from an imperative model to a declarative model. And it's all about understanding larger business processes. Because in the dawn of time, back when we were first writing applications, we're like, I remember being, I started my career as a Linux sys admin, right? And I remember this is before the age of package managers really. I'm dating myself. And you're putting all the files in the right directory so the system works. I can relate. Yeah, and over time we moved from that to package managers, to containers, like it's to Kubernetes. And it's just a process of saying we need to think more and more declaratively instead of imperatively. I need to communicate what's my intention instead of I'm going to execute every step. And whether we're thinking about how we run our code, whether we think about how our development processes work, whether we're thinking about doing our APIs, that platform engineering mindset where we need to think declaratively and then think about the larger processes and then think about how the whole thing ultimately turns into a product. It's not just something we're doing once. It's a platform. It's like an internal product that we're delivering. It's a solution hopefully, in theory, yeah. Yeah, and it's all about empowering others. That's one of our values at Apollo. We want to empower, you need to empower your team to build incredible apps so you can empower your end users. And AI only accelerates that because today the consumers of the platform are teams that are building applications. But for all those same reasons, those same platforms are going to enable to empower the AI systems of the future. And that declarative model becomes even more important because AI is really good at some things and it's really not good at other things. You shouldn't trust your AI to go figure out how to call all your back-end services in the right order. You need a query planner for that. You should use like a high quality reusable piece of machinery. You also can't trust your AI to... You need to vet what it's asking to do. So moving to these declarative models, like GraphQL, it's really cool. We have it working where we have a basic prototype of text-to-query working. So you can say, hey, the user asked for this. It's just natural language. Yeah, yeah, you can ask a natural language. That's beautiful. Where's my package? Order me a pizza. Chat GPT can't do that because it's not connected to your systems. I believe you can't have an AI strategy without an API strategy. You've got to connect the AI to your API somehow, otherwise it's going to answer trivia questions for you. It's going to generate cool images, but it can't do things for you. So, but to do that, you need a way for the AI to explain its intent, not have it write a bunch of code, and that's what GraphQL is so good at. You can say, hey, where's my package? Or show me the shipping status of all of my orders. That's going to touch a couple of different systems. Maybe you have to go to UPS's FedEx system, and also Salesforce, and also my microservices. How are you going to pull out the together? Well, if you can translate that text, if you can take that query, and then you can look at the whole schema, which might be thousands or tens of thousands of types in a real world environment. And you can generate a GraphQL query from that and say, oh, I need to join the order information with the shipping status information, and that's the join you're doing to combine the APIs. Then you can express that in GraphQL. Suddenly a couple of things become possible. That GraphQL query is basically an intent. It's something that AI would like to have happen. You can validate that against a set of declarative security rules and say, is that okay or not? Now you're addressing some of the trust issues in AI, and then you can execute that. You know exactly. You can use a query planner, not rely on the AI to decide which backend services you're going to call. You can rely on a mature, performant, proven at scale query planner to say, this is how I'm going to call those backend services. So if you don't have that, how are you ever going to connect your AI to your APIs? So the theme here is everything we're doing in platform engineering today that helps our app developers is also going to help the systems of the future. Whether that's low code, no code tools, whether that's AI, whether that's the electrode implanted in your brain, all of which is going to let us do more to empower end users. So connect us back to joining the CNCF. What changes for you, for Apollo, for GraphQL in the future? Yeah, well I think it's all about, so we have the GraphQL Foundation, which is where we all work together in the GraphQL community to make sure that the standards are really well established and we're all, we're spreading this message that we have about platform engineering, how GraphQL lets you combine your APIs, the power of GraphQL Federation. We want to connect that community which often historically has its roots in the app developer world or the API developer world because a lot of technology originated from back and for front end. We want to connect that to the broader platform engineering movement and we want to connect this to the broader DevOps movement because when we put all these pieces together, that's when we get the platforms of the future that let us build these incredible applications. So starting that conversation and helping people realize we can do more with our APIs. We can go from thinking APIs, maybe we need to put a gateway in front of it to make sure it's secure, but what's security really? Like if you've got, if you can even, it's hard enough to list all the API endpoints we have, if we can't even, if we can't even, if we don't know what they're doing, we have no way to secure them. So putting those pieces together and seeing how we can, how the platform engineering community can do more with APIs with this technology, you know, that's what I think the opportunity is. That's exciting. I think it's great. What a fantastic week and we're really excited to share this story with us. One last question for you. When we have you back on the show because your energy is killing it, killing it for us day three here. What do you hope you can say in Salt Lake or in London that you can't say yet today? I think we're going to be able to share some really cool stuff around how easy it's becoming to get APIs on the grass. How do you go put not one, two, three APIs, but 50, 60, 70 APIs? Yeah, scale. And how do you connect that with AI? What I hope I can say to you is not only have we been really easy to get all of your APIs on the graph without writing very little or no code. We've made it so easy where a front-end developer, for example, you're building your React application, maybe you don't have to write any of the code, connect the app to the backend. Maybe you can just into your GraphQL co-pilot type, just connect my app to the backend and press enter. It's going to find all those resources. It's going to, and it's going to automatically write the GraphQL query, automatically write the code. Think about how much that helps us compared to all the work we have to do to build the backend for front-ends, to constantly be tweaking these backend APIs, even to navigate the politics of that, even setting aside writing our front-end application. So I think we're going to see, I think we're going to see this GraphQL Federation, which is such this powerful and powering technology. I think we're going to see it get 10x easier and faster to use. And I think that's what's going to drive that 10 to 15x probably increase in usage in the next couple of years based on what analysts are saying. Awesome, well I look forward to being sitting next to you and telling that story in a few months. Jeff, thank you so much for being here. Awesome, thank you so much for having me. Justin, oh, yes, this is easy. Always a pleasure with you. And thank all of you for tuning in to our wonderful coverage here at KubeCon CloudNativeCon in Paris. My name's Savannah Peterson. You're watching theCUBE, the leading source for enterprise tech news.