Where Software Moves Fast,
Infra Needs to Move Smart
Your Title Goes Here
Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.
Notes
As API sprawl and microservices boom, IT teams struggle with integration chaos, slowing dev velocity and risking security lapses. In this episode of The Hitchhiker’s Guide to IT, host Michelle Dawn Mooney interviews Matt DeBergolis, co-founder and CEO of Apollo GraphQL—a leader in federated APIs—on streamlining APIs for faster, reliable software delivery.
Rooted in ’80s open-source roots, Matt’s career fuses tech innovation with social impact, advocating tools that connect fragmented systems into seamless, user-centric experiences amid cloud-native shifts.
Key topics include:
– Microservices evolution: From monoliths to hundreds of distributed components; GraphQL orchestrates them for secure, performant user flows like real-time retail shipping estimates\
– Declarative GraphQL benefits: Intent-based queries cut custom code, enable omnichannel reuse (mobile/web/voice), and boost efficiency in budget-tight environments\
– Federation for team scaling: Decouples services for autonomous squads, slashing coordination overhead while handling testing and varied dev paces\
– APIs fueling AI agents: Secure bridges to systems for personalized actions—like adaptive banking—taming non-determinism in chat-to-action workflows\
– Taming API sprawl: View APIs as products with usability focus, adoption metrics, and discovery to shift IT toward customer-driven innovation
For dev leads or CIOs battling silos, this episode packs frameworks, case studies (e.g., NYT personalization, Sysco expansions), and AI-forward tips to turn API hurdles into agile advantages.
Transcript
Welcome to the Hitchhiker’s Guide to IT brought to you by Device42. On this show we explore the ins and outs of modern IT management and the infinite expanse of its universe. So buckle up and get ready to explore the ever changing landscape of modern IT management.
Hello everyone and welcome to The Hitchhiker’s Guide to IT. I’m your host, Michelle Dawn Mooney. And today we’re exploring how modern API strategies can really simplify development, improve observability, and keep infrastructure teams in sync as complexity grows. Joining me is Matt Dibergolas, co founder and CEO of Apollo GraphQL. Matt is helping enterprise teams move faster and build smarter with a federated approach to APIs without losing control of security, performance, or infrastructure reliability. So Matt, thank you so much for joining me today. Welcome.
Oh, my pleasure. Thanks for having me.
Looking forward to the conversation. Before we kind of dive in, can I ask you to give us a brief bio if you can, please?
Sure. I’ve been building software really, my whole life, and for me, a big part of what’s behind that is software has such a cool impact on the world, and I I wanna see a world where, as people, we have more and more ways to communicate with each other and more and more great software, whether it’s on our phone or a desktop or some kind of an AI software.
There’s so much important work, so much social that comes with this. It’s it’s not just a a technical endeavor for us.
I got my start in the open source world, which is software that has a free license that you can just download and and modify, and that really changed the whole industry back in the eighties and nineties when I got my start, and what I learned was the open source movement at its heart is a social movement. It’s a it’s a vision for the kind of world we can have and a vision for how we can empower people to make things, make great things for each other. That’s what’s really been behind all of this for me, and it’s, it’s true to this day here at Apollo.
Yeah. And it’s exciting. It’s exciting field to be in at this day and time. So how has software complexity changed in the last decade, and what are the implications for both dev and In for Teams?
Well, it hasn’t gotten simpler, that’s for sure, and it’s really when you start looking at how software gets built today and how enterprises in particular do it, it’s amazing we can get anything done.
You know, the old days, everything was in one box. You had one big computer and you had one big piece of software and that was it, but now there’s been so many technical developments and trends.
You’ve got the cloud, for example, has completely changed the nature of software because with cloud, it becomes possible to build software in smaller and smaller pieces. We call these microservices sometimes, and if in the old days, writing software was a single large thing that you could all do in, you know, one room with one team, let’s say, today, a piece of software on your phone, if you’re looking for your flight schedule or if you’re on a social application, under the hood, there might be twenty or fifty or hundreds of these individual components that have been built, by a separate team, each with a different kind of technology.
You might be using a piece of software that combines the work of multiple companies. A lot of companies have an M and A strategy, and that often is a strategy that’s about taking two products and combining them into one. You might be using a piece of software that partners with another company. And so the thing that’s gotten really hard, really, really hard over the last ten or twenty years is how you connect all that stuff back up together.
How do you assemble the components or the LEGO bricks into a really high quality, coherent experience that feels great, that’s a AAA, you know, product that you can use, and a big part of what we solved at Apollo is that question, because if you if you look at the time it takes and the number of engineers it takes to assemble all those parts, that’s that’s part of the challenge, but you touched on the other half, which is there’s so much room for error there, and if you think about how hard it is to do all that work and be secure, how hard it is to do that work and have good performance, all the other things that are so important, not just for the quality of the software, but really for a company and its brand and its reputation, What we’re attacking at Apollo is the problem of assembling all of those pieces together into one.
And you talked about earlier, it certainly hasn’t gotten easier. Everything that we’re talking about here today, right? A lot of complexity. So what is one way GraphQL helps enterprise teams reduce friction between development speed and infrastructure reliability?
GraphQL’s the core technology inside of Apollo. It’s a language that we use to describe the different parts that we need from those systems I was talking about and bring them together onto a screen. I’ll give you an example. If you think about a retail experience, you’re looking at a product on your mobile app that you might want to buy.
One of the things you probably wanna know is how quickly that product would show up on your doorstep if you click the buy button. Is it is it gonna show up in time for my my kid’s soccer game this weekend? Right? And if you think about how hard it is just to say, arrives on Friday, you’ve gotta figure out what warehouses have the product in stock. What’s my real time inventory? You’ve gotta figure out what shipping partners are available to me to get that product from that warehouse to the zip code of the customer.
You’ve got to decide, you know, do I wanna ship quickly and eat into my margins? I’m a retailer, margins are pretty important, or do I wanna maybe ship more slowly and cheaply and potentially harm the customer’s experience. So there’s a business decision in there and you have to bring all that together just for four words that show up on the screen. But the thing of it is, if you don’t, your customer’s going to walk. They’re going to go to a different retailer that tells them, and you may have half heartedly gone through a checkout flow before just to see when the thing’s going to show up, but people have less and less patience for that.
So GraphQL emerged as a technology to address that question, because if solving a problem like I just described means you have to assign a team of engineers to build new systems, new code that we’re gonna then have to audit and secure and run through a performance assessment, and then we’re gonna have to maintain for the next five years, it becomes a really hard choice, especially if you’re in a budget constrained environment, especially if you’re having more to do than you have people on your team to be able to do, and GraphQL replaces that code and that time with, we call it a declarative approach in in the idea that you explain what you want instead of telling the computer system how to do it.
That’s what code is, and it’s not just a lot simpler and shorter. It means that now we can use pre built infrastructure, in our case, it comes from Apollo, to figure out what to do. So in GraphQL, you would say, I need a list of the warehouses and the current shipping time for that piece of app, then I want the best three of them.
And under the hood, there’s there’s machinery that says, okay, to do that, first, I have to go talk to the warehouse systems and figure out where their stuff, then I have to go talk to the relevant shipping partners given the user information I have about where the ZIP code is. There’s all of this, we call it orchestration, that happens behind the scenes to make that possible, and it’s it’s something you get basically out of the box instead of having to build a bespoke version yourself.
The other big thing GraphQL does is that nobody has just a mobile app anymore, right? You’ve got a mobile app, maybe two or three. You’ve got a web experience. You might have an Alexa or a voice application.
We have a lot of hospitality customers. They’ve got a kiosk in the hotel where you can check-in instead of going up to the front desk. So you’ve got to do the thing I just described in many different settings, and it has to be a coherent and, you know, omnichannel experience that doesn’t leave the customer confused or disjointed. That’s the other big place where the benefit comes in because you’re able to leverage that work repeatedly instead of having to rewrite new software for each kind of platform that you want to reach your customers on.
And you know, it’s funny you brought up the example of the retailer because just last night around ten something, if I put in an order in an hour and a number of minutes, I could see if it was going to get to my house tomorrow versus the next day. Instantaneously, I need to know. And you’re right. If you can’t get that, you’re gonna walk. So Apollo’s Federation model enables teams to decouple services. Can you explain what that means in practice and why it matters?
The whole prize, when you think about building software, is how do you scale your practice?
How do I have lots and lots and lots of engineering teams working together where each of them adds more value, where you can ship more? And there’s been a lot of work on engineering practices and architectures that make this possible.
If everybody is in one big room working on the same piece of software, there’s a lot of coordination costs. There’s just an enormous amount of time lost to, well, if I change this thing, I got to go talk to these other folks that are over here, and that might cascade into them having to talk to a third set of folks, and you discover eighty percent of your engineers are spending eighty percent of their time in meetings instead of actually getting work done. And so the solution is to, as you said, decouple it, is to create smaller and smaller boundaries around a small team, maybe four or five, six engineers that can work essentially independently, that don’t have this tight coordination cost between them.
That’s the prize to being able to sip more and more with the team you’ve got and to be able to leverage more and more engineers on the project, and so the challenge simply becomes, okay, if I’m gonna commit to that style of engineering, which is the modern practice that we have found works best, I have to address all of the other questions. Now I’ve got, you know, the question of orchestrating across them that Apollo addresses. You’ve got all kinds of interesting questions around how you test all that stuff together, how you manage different paces of development. Maybe some of those teams are shipping new functionality every week, maybe some of them are working on projects that are going to take the better part of a year.
And so a lot of this ends up being the structural and social in how you run a modern engineering organization and how you empower those engineers with tools that are really about collaboration and coordination and that that start from the point of view of what can we do to minimize the the the overhead or the burden of that coordination so that the bulk of the time is actually going toward delivering value to the customer, to the user of our product.
Yeah. And, Matt, as AI and agentic apps become more prominent, what role would you say modern APIs play in powering those experiences?
The whole idea of an agent is that it can do stuff.
Right? So so we we all had the experience of a chatbot. It’s incredible. You can talk to it.
You can ask it questions, but you’re limited to what the chatbot was trained on. So there’s there’s all of this English text on the Internet, and so you can talk to the chatbot about the history of of, you know, the world. You can talk to it about a recipe you might wanna to make, but an agent is different. An agent is is something that that can go out and and and do something for you.
You can imagine an agent that’s gonna help you book airline travel or an agent that I don’t want to just make a recipe. I probably wanna put some stuff in my shopping cart that I don’t have yet. Maybe all that stuff will come to me over the weekend so that I can, you know, plan for dinner that week. I might want an agent inside my organization so that I can ask questions about my customers or my business.
The way you do that is to call what we call an API. An API is the front door to a business system or capability or piece of software.
So we built these APIs in the past as part of this architecture we’ve been talking about. It’s what makes it possible to write a mobile application on top of all these different systems. It’s what makes it possible for a credit card company to have a digital partnership with a travel company so that you can spend your points. Those are APIs.
With agents, we need all that, but we also need them in a somewhat different way because you don’t trust the AI inside of an agent the way that you might trust a piece of software that your own engineers built.
We all have seen, you know, these models can do wacky things.
And so the big exciting thing that everybody at Apollo’s working on in one way or another is how do we apply everything we’ve learned about orchestrating these APIs and building systems on top of them to a really exciting world of agentic software, software that’s going to get more and more capable as it has this bridge to more and more of your systems.
And agents aren’t some far out idea. I’m not suggesting that you’re just gonna wake up one day and say, I wanna go to New York tomorrow, just find me some tickets and a play that I can watch and it’s all done. But imagine like a banking experience, for example.
Banks have a tricky thing to do with their software because you’ve got to appeal to such a wide variety of users.
Your app has to serve somebody who’s retired and thinks of their bank as the place where they’ve kept all their money, and you have to somehow have that same app serve the needs of someone younger who’s excited about modern crypto or stock trading and sees their bank very differently than someone who’s from an earlier generation. How are you supposed to serve both of those with one piece of software? It’s really tough.
With an agent, we can talk about software that gets really personalized to you and to what you want.
So it learns from you, it allows you to change what’s on the screen and adapt to what you wanna do and how you wanna do it. And again, to do that the right way, you have to have this bridge to all of the capabilities in your business, and you have to have that bridge be secure and appropriate for the, you know, kind of, we call it non determinism, the agent’s gonna do one thing one day and another thing another day, so you want that to all sit on top of something solid and understandable.
I wanna dive a little deeper with APIs. What do IT and security leaders often misunderstand about API sprawl, and then how can a declarative approach help there?
Well, think the big shift in IT in a lot of ways is who they serve and what this is all for. The old days, IT was the provider of technology, right? And so the user of that technology had to accommodate to that. Today, everything has to come from the customer and the customer experience, and whatever business you’re in, the customer is gonna care a lot about the experience they have as they interact with you digitally, and if they don’t like that experience, they’re probably gonna walk. They’re probably gonna change banks or airlines or what newspaper they choose to read or take your pick, whatever the industry is.
So IT has to serve the customer. That’s the big change. It has to be a servant leadership model.
We’re used to thinking about APIs as these sort of deep technical things, and there’s certain technical requirements, right? They have to have a security story. They’ve got a scale. They have to be reliable.
Those things are all still true, but you have to look at it through the lens of like, how does this help our customer? Are the APIs easy to use?
Is a question that should be at the forefront instead of at the end of the list of things you care about, because if you’ve got an API, it doesn’t matter how secure it is.
If nobody wants to use it, if the developers can’t figure out the right way to connect to it, if they don’t know it exists, turns out discovering all the APIs in your company is a bigger problem than you might think, then what’s the point? It’s not valuable. You can’t push this stuff on people. You have to create something great. I guess a good summary is you have to treat your API as a product.
You have to treat it as something that your own engineers have a choice about using and the teams that really see it that way and look at their API sprawl, the growing number of these things as an asset and something that they want to make flourish, and they think about questions like, what’s my adoption?
Are the people who are adopting my APIs happy? Can I do a customer satisfaction, you know, measure against that? That’s the modern way that IT thinks about this stuff and, that’s the way modern companies build great software on top of it.
So I wanna ask you this because we’re hearing about some great things that we can accomplish, maybe some pain points that can be taken care of, solutions here, But can you share a real world use case where GraphQL helped an enterprise improve scalability or developer velocity? Because I always like to hear, you know, kind of the proof is in the pudding. Like, us give us some of the good stuff there.
GraphQL is inside of a lot of the household brands that that you interact with every day. I’ll give you an example. The New York Times is one of the companies that really saw this early, and they’ve been a a a great partner for us and and a leader in the GraphQL community for for a long time.
If if you go to the front page of the New York Times, the the the information you’re seeing, whether it’s on the computer screen or in your mobile application, that’s all coming through everything we’ve been talking about, a GraphQL system that brings together a whole bunch of different parts.
And think about the evolution of that particular company.
You might think of a newspaper, you might have a mental model of, well, there’s a bunch of stories and, you know, sometime back in the 90s, they made a website, so you could read those stories on the screen instead of on the sheet of newsprint.
That’s not New York Times or any modern media company of today.
There is, you know, a recipe business. There’s a gaming business. There’s the athletic, sports, you know, call it media, but a a different business line there. Their business model has evolved, more and more towards subscriptions, and and they’ve written a lot about that and spoken a lot about the importance of navigating this big shift that’s happening in media.
There’s a personalization element. If you go to the New York Times, you’re not just seeing a list of stories, they’re stories that were picked for you, and there’s comments and other users and other forms of engagement because their goal is to bring you more and more of relevance to what you want to learn about and what you want to seek. Think about how hard it is to take a bunch of systems that were built in a very different time for a very different business model and adapt that to, it’s still the paper of record, I think they call it, but it’s also the website everybody wants to go to on election day to see second by second, minute by minute results of what’s happening around the country.
And GraphQL has allowed them to do that. It’s allowed them to transform that business into something where they can ship very quickly, they can experiment with new ideas, They can quickly bring different products together into a coherent experience. We see this a lot in media because of the forces that are transforming that industry. We see it a lot.
I mentioned hospitality, a lot of the the major, you know, hotel chains. We see it a lot in in sports. As a matter of fact, Major League Baseball is a is a big user of GraphQL because it lets them bring a really data rich stand experience to their viewers, but we also see it in industries you may not think about as much when you think about software. Cisco is an example, the food distributor.
Cisco is a multinational organization. Every time they want to expand their footprint, they have to build new software to, again, combine these different systems into a country or a region specific interface for their buyers and their customers. Cisco used GraphQL to expand into the Canadian market. Same idea. We’ve got a bunch of these internal systems, and in many of these companies, they go back decades and decades, and now they’re available, in this modern form to meet the needs of a modern customer, that has a choice in who they’re gonna do business with and what they expect from their providers digitally.
It really is amazing to think when you talked about the New York Times and a website, because a website was a huge to do, and I’m dating myself, but you know, the companies that had websites, but we’re so far past that. You talk about baseball or, you know, for my husband, it’s golf, like literally refreshing the page and instantaneously seeing who’s ahead. It’s just amazing, the technology and places that you said too, that we don’t even think about some of this technology is being used. I want to ask you this. Looking ahead, what trends in infrastructure, dev tooling, or AI are you watching closely?
Well, I’ll I’ll just pick up where I left off. The the thing about the the examples I gave is think about the prize for being at the forefront, for being one of the two or three most digital, most customer friendly companies that meets customers where they want to be met, the way they want to be met, that’s most innovative, that can experiment the most quickly. We can talk about how GraphQL saves teams. I mean, I think the average figure is maybe twenty, thirty percent of the engineering time is reduced when you adopt this architecture, so from a dollars and cents point of view, it’s a no brainer, But I think the the bigger prize is is think about the the the win for being one of the two or three top in the vertical that you’re in. Think about the risk of being one of the laggards.
And I think across all these industries, we’re just seeing such consolidation, and the Internet really does create, you know, winners and losers.
And I say all that because as I think about the trends that are coming, we’ve got in AI in particular, the largest, most seismic change in the technology landscape, certainly in my career, and it’s going to create winners and losers.
We read about that every day. It’s gonna for companies that embrace it the right way, it’s gonna transform their business. It’s gonna let them reach more people. It’s gonna let them reach those people in a in a much more human friendly, hyper personalized way.
It’s really urgent, really urgent, I think, for every company to find their footing there and to figure out how do I adapt the systems I have to an AI world? How do I adapt the engineering culture I’ve built to an AI world? How do I use AI internally to be more productive, more insightful? How do I empower my team more effectively with that?
And I think over the next two or three years, we’re going to see just such transformative change to not just the technical elements of IT and how the software is assembled and provided, but deeper changes to how teams are formed and what the nature of that work is and what kinds of tools and and systems allow them to go furthest and and fastest. It’s it’s an exciting time to to be doing this stuff.
And as you said, there is so much excitement about what we’re talking about. So I wanna end here. For teams feeling overwhelmed by legacy systems or siloed APIs, what is the best way to start modernizing with GraphQL?
Well, we try to make that exact thing easy at Apollo. So point your developers at Apollo. Dev, and they can very quickly see what we’re talking about. GraphQL is just a a wonderful we call it developer experience. It’s it’s fun to use. It’s rewarding. It’s it’s got certain affordances that that really, I think delight the modern software developer, and and on our website, there’s lots and lots of stories and examples of how companies have changed their business by approaching their API strategy this way, and I think there’s a lot to draw from there as inspiration for how you can, get started at yours.
Wanna thank you so much for being here, Matt, because, a lot of exciting things to look forward to, and it’s kind of crazy to see how fast things are going. So appreciate your time today. Thank you for being here.
It’s my pleasure. What a time to be alive.
And another big thank you to Matt DeBergolis for joining us today on unpacking how modern API architecture can help teams move faster, integrate smarter, and scale responsibly. And that is going to do it for this episode of The Hitchhiker’s Guide to IT. Of course, want to thank you for tuning in. If you like what you heard, we would invite you to subscribe to the podcast. I’m your host, Michelle Dahl Mooney. Thanks again for joining us. We hope to connect with you on another podcast soon.