Artwork

Player FM - Internet Radio Done Right
Checked 19d ago
Added seven weeks ago
Content provided by Sagar Batchu. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Sagar Batchu or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.
Player FM - Podcast App
Go offline with the Player FM app!
icon Daily Deals

Separating deployment from release, API-first development, and the future of developer experience | John Kodumal (co-founder & fmr CTO LaunchDarkly)

26:04
 
Share
 

Manage episode 471036348 series 3652402
Content provided by Sagar Batchu. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Sagar Batchu or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.

On the first episode of Request // Response, I speak with John Kodumal, co-founder and former CTO of LaunchDarkly.

We discussed how LaunchDarkly used feature flags to separate deployment from release, offering fine-grained control for safer rollouts and experimentation.

LaunchDarkly was an early adopter of server-sent events, and was a pioneer of the technology even before LLMs.

Tune in to hear our thoughts on the changing demands and expectations for APIs and developer experience in light of agentic era of APIs.

Listen on

Apple Podcasts | Spotify

Where to find John Kodumal

Show Notes:

[00:00:00] Introduction

  • Sagar welcomes John Kodumal to the podcast.
  • John’s background as co-founder and former CTO of LaunchDarkly.

[00:00:28] What is LaunchDarkly?

  • LaunchDarkly's role in separating deployment from release.
  • The impact of fine-grained feature flag controls.
  • Benefits: safer rollouts, experimentation, controlled beta releases.

[00:02:18] Pre-LaunchDarkly Era

  • How companies previously handled feature releases.
  • Homegrown tools and their limitations.
  • Inspiration from early DevOps talks, including Flickr’s feature flagging.

[00:05:26] LaunchDarkly’s API and SDK Focus

  • The importance of embedding into the software development lifecycle.
  • Learning from Atlassian’s approach to API-driven development.
  • Early investment in API design and OpenAPI specifications.

[00:10:37] Technical Deep Dive: SSE and Feature Flags

  • Use of Server-Sent Events (SSE) for real-time feature flagging.
  • Challenges with existing SSE open-source libraries.
  • Ensuring consistency across distributed systems.

[00:14:23] The Evolution of API Expectations

  • Increased demand for standardized, high-quality APIs.
  • Importance of pagination, rate limiting, and caching.
  • Growing role of OpenAPI specifications in modern API development.

[00:19:26] Traversability and Developer Experience

  • APIs as traversable maps for both humans and machines.
  • Comparison to REST principles and the Fielding Thesis.
  • How great APIs lower integration barriers for developers and AI agents.

[00:22:40] What Defines Great Developer Experience?

  • Macro and micro-scale perspectives on DevEx.
  • Anticipating user needs and providing escape hatches.
  • Importance of small but impactful UX details.

[00:26:23] Closing Thoughts

  • The significance of developer experience in building tools.
  • How LaunchDarkly has influenced modern software development.

Subscribe to Request // Response

If you enjoyed this podcast, you can be the first to hear about new episodes by signing up at
https://speakeasy.com/post/request-response-john-kodumal

More John Kodumal Quotes From The Discussion

  1. Feature Flags Are Powerful

    “A lot of people look at just that idea of feature flags, and they think that it's small, and they're shocked that there's a multi billion dollar company that does feature flags. But it's not about feature flags. It's about all the changes to the software development lifecycle that feature flags enable”

  2. Traversability Over Endpoints

    “Nothing should be an endpoint. Everything should be traversable. If you have an endpoint, it's broken.”

  3. Working With The Complexity of Developer Needs

    “In order to fit into someone's SDLC you have to respect the differences that make their software development practices unique—you have to work with them, not force a one-size-fits-all solution.”

Referenced

Production by Shapeshift | https://shapeshift.so

For inquiries about guesting on Request // Response, email samantha.wen@speakeasy.com.

  continue reading

3 episodes

Artwork
iconShare
 
Manage episode 471036348 series 3652402
Content provided by Sagar Batchu. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Sagar Batchu or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.

On the first episode of Request // Response, I speak with John Kodumal, co-founder and former CTO of LaunchDarkly.

We discussed how LaunchDarkly used feature flags to separate deployment from release, offering fine-grained control for safer rollouts and experimentation.

LaunchDarkly was an early adopter of server-sent events, and was a pioneer of the technology even before LLMs.

Tune in to hear our thoughts on the changing demands and expectations for APIs and developer experience in light of agentic era of APIs.

Listen on

Apple Podcasts | Spotify

Where to find John Kodumal

Show Notes:

[00:00:00] Introduction

  • Sagar welcomes John Kodumal to the podcast.
  • John’s background as co-founder and former CTO of LaunchDarkly.

[00:00:28] What is LaunchDarkly?

  • LaunchDarkly's role in separating deployment from release.
  • The impact of fine-grained feature flag controls.
  • Benefits: safer rollouts, experimentation, controlled beta releases.

[00:02:18] Pre-LaunchDarkly Era

  • How companies previously handled feature releases.
  • Homegrown tools and their limitations.
  • Inspiration from early DevOps talks, including Flickr’s feature flagging.

[00:05:26] LaunchDarkly’s API and SDK Focus

  • The importance of embedding into the software development lifecycle.
  • Learning from Atlassian’s approach to API-driven development.
  • Early investment in API design and OpenAPI specifications.

[00:10:37] Technical Deep Dive: SSE and Feature Flags

  • Use of Server-Sent Events (SSE) for real-time feature flagging.
  • Challenges with existing SSE open-source libraries.
  • Ensuring consistency across distributed systems.

[00:14:23] The Evolution of API Expectations

  • Increased demand for standardized, high-quality APIs.
  • Importance of pagination, rate limiting, and caching.
  • Growing role of OpenAPI specifications in modern API development.

[00:19:26] Traversability and Developer Experience

  • APIs as traversable maps for both humans and machines.
  • Comparison to REST principles and the Fielding Thesis.
  • How great APIs lower integration barriers for developers and AI agents.

[00:22:40] What Defines Great Developer Experience?

  • Macro and micro-scale perspectives on DevEx.
  • Anticipating user needs and providing escape hatches.
  • Importance of small but impactful UX details.

[00:26:23] Closing Thoughts

  • The significance of developer experience in building tools.
  • How LaunchDarkly has influenced modern software development.

Subscribe to Request // Response

If you enjoyed this podcast, you can be the first to hear about new episodes by signing up at
https://speakeasy.com/post/request-response-john-kodumal

More John Kodumal Quotes From The Discussion

  1. Feature Flags Are Powerful

    “A lot of people look at just that idea of feature flags, and they think that it's small, and they're shocked that there's a multi billion dollar company that does feature flags. But it's not about feature flags. It's about all the changes to the software development lifecycle that feature flags enable”

  2. Traversability Over Endpoints

    “Nothing should be an endpoint. Everything should be traversable. If you have an endpoint, it's broken.”

  3. Working With The Complexity of Developer Needs

    “In order to fit into someone's SDLC you have to respect the differences that make their software development practices unique—you have to work with them, not force a one-size-fits-all solution.”

Referenced

Production by Shapeshift | https://shapeshift.so

For inquiries about guesting on Request // Response, email samantha.wen@speakeasy.com.

  continue reading

3 episodes

All episodes

×
 
Ken Rose is the CTO and co-founder of OpsLevel. Ken shares the founding journey of OpsLevel and lessons from his time at PagerDuty and Shopify. We debate GraphQL vs REST, API metrics that matter, and how LLMs and agentic workflows could reshape developer productivity. Listen On Apple Podcasts | Spotify Subscribe to Request // Response If you enjoyed this podcast, you can be the first to hear about new episodes by signing up at https://speakeasy.com/post/request-response-ken-rose Show Notes [00:01:08] What OpsLevel does and why internal developer portals matter [00:01:51] Ken’s journey from PagerDuty to Shopify and to starting OpsLevel [00:04:03] Developer empathy, platform engineering, and founding OpsLevel [00:05:02] OpsLevel’s API-first approach and extensibility focus [00:06:26] Using GraphQL at scale—Shopify's journey and lessons [00:08:30] Managing GraphQL performance and versioning [00:10:12] GraphQL vs REST – developer expectations and real-world tradeoffs [00:11:27] Key metrics to track in API platforms [00:12:50] Why not every feature should have an API—and how to decide [00:13:48] Advice for API teams launching today [00:14:44] API consistency and avoiding Conway’s Law [00:15:50] Agentic APIs, LLMs, and the challenge of semantic understanding [00:18:48] Why LLM-driven API interaction isn’t quite magic—yet [00:20:00] Internal APIs as the next frontier for LLM productivity [00:21:43] 5x–10x improvements in DX via LLMs + internal API visibility [00:23:00] API consolidation, discoverability, and LLM-powered developer tools [00:23:54] What great developer experience (DevEx) actually looks like More Quotes From The Discussion Challenges of Running GraphQL "I can tell you as OpsLevel, running a GraphQL API, you know, all the usual things, making sure that like you don't have n+1 queries, ensuring, you don't get per resource rate limiting like you do with REST... You have to kind of be more intentional about things like query complexity. Those are challenges you end up having to solve. Versioning is another big one. We are far enough along in our journey. We haven't done a major version bump yet. I know a few years ago, after I left Shopify, they switched their GraphQL schema to be versioned and now they have much more kind of program management around like every six months they have a new major version bump. They require clients to migrate to the latest version, but that's effort and that's calories that you have to spend in that kind of API program management." DevEx of REST vs GraphQL "We have a customer that has been with us for years, but our champion there hates GraphQL. Like he really hates it. And the first time he told me that I actually thought he was like, you know, joking or being sarcastic. No. He was legitimate and serious because from his perspective, he has a certain workflow he's trying to accomplish, like a "Guys, I just need a list of services. Why can't I just like REST, even make a REST call and fetch last services and that's it. Why do I have to do all this stuff and build up a query and pass in this particular print?" And I get that frustration for developers that, you know, REST is sort of easier to start. It's easier just to create a curl request and be done with it, right? It's easier to pipe, the output of a REST call, which is generally just a nice JSON up into whatever you want versus "No, you've actually have to define the schema and things change." I think GraphQL solves a certain set of problems, again, around over fetching and if you have a variety of different clients. But there is this attractive part of REST, which is "I just made a single API call the single endpoint to get the one thing I needed, and that was it." And if your use case is that, then the complexity of GraphQL can really be overwhelming." API Consistency and Conway's Law "I do think consistency is an important thing, especially when you're dealing with a large company that has disparate parts working on different aspects of the API. You don't want Conway's Law to appear in your API—you know, where you can see the organizational structure reflected in how the API is shipped. So making sure that an API platform team or someone is providing guidance on how your organization thinks about the shape of APIs is crucial. Here's how you should structure requests. Here's how you should name parameters. Here's what response formats should look like. Here's consistent context for returns and responses. Here's how to implement pagination. It's all about ensuring consistency because the most frustrating thing as an API client is when you hit one endpoint and it works a certain way, then you hit another endpoint and wonder, 'Why is this structured differently? Why does this feel different?' That can be tremendously difficult. So having some guardrails or mechanisms to ensure consistency across an API surface area is really valuable." Referenced - OpsLevel (https://opslevel.com/) - Shopify Storefront API (https://shopify.dev/docs/api/storefront) - GraphQL (https://graphql.org/) - REST (https://restfulapi.net/) - Conway's Law (https://en.wikipedia.org/wiki/Conway%27s_law) RED Metrics (https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services/) - Anthropic MCP (https://www.anthropic.com/news/model-context-protocol) - Agents.js (https://huggingface.co/blog/agents-js) Production by Shapeshift | https://shapeshift.so For inquiries about guesting on Request // Response, email samantha.wen@speakeasy.com.…
 
Robert Ross ( @BobbyTables ) is the CEO of FireHydrant. We discuss the journey of building FireHydrant, the evolution of API design, and the impact of gRPC and REST on developer experience. We also talked about the role of LLMs in API design, the shift towards data consumption trends in enterprises, and how great developer experience is measured by a simple litmus test. Listen On Apple Podcasts | Spotify Subscribe to Request // Response If you enjoyed this podcast, you can be the first to hear about new episodes by signing up at https://speakeasy.com/post/request-response-robert-ross Show Notes [00:00:00] Introduction - Overview of discussion topics: building FireHydrant, gRPC, API design trends, and LLMs in APIs. [00:00:42] The Story Behind FireHydrant - Robert’s background in on-call engineering and why he built FireHydrant. - The problem of incidents and automation gaps in on-call engineering. [00:02:16] APIs at FireHydrant - FireHydrant’s API-first architecture from day one. - Moving away from Rails controllers to a JavaScript frontend with API calls. - Today, over 350 public API endpoints power FireHydrant’s frontend and customer integrations. [00:03:50] Why gRPC? - Initial adoption of gRPC for contract-based APIs. - Evolution to a REST-based JSON API but with lessons from protocol buffers. - Would Robert choose gRPC today? His thoughts on API design best practices. [00:06:40] Design-First API Development - The advantages of Protocol Buffers over OpenAPI for API design. - How API-first development improves collaboration and review. - Challenges with OpenAPI’s verbosity vs. Protobuf’s simplicity. [00:08:23] Enterprise API Consumption Trends - Shift from data-push models to API-first data pulls. - Companies scraping API every 5 minutes vs. traditional data lake ingestion. - FireHydrant’s most popular API endpoint: Get Incidents API. [00:10:11] Evolving Data Exposure in APIs - Considering webhooks and real-time data streams for API consumers. - Internal FireHydrant Pub/Sub architecture. - Future vision: "Firehose for FireHydrant" (real-time streaming API). [00:12:02] Measuring API Success (KPIs & Metrics) - Time to first byte (TTFB) as a key metric. - API reliability: retry rates, latency tracking, and avoiding thundering herd issues. - The challenge of maintaining six years of stable API structure. [00:17:12] API Ergonomics & Developer Experience - Why Jira’s API is one of the worst to integrate with. - The importance of API usability for long-term adoption. - Companies with great API design (e.g., Linear). [00:18:14] LLMs and API Design - How LLMs help in API design validation. - Are LLMs changing API consumption patterns? - Rethinking API naming conventions for AI agents. [00:22:02] Future of API Ergonomics for AI & Agents - Will there be separate APIs for humans vs. AI agents? - How agentic systems influence API structures. - The need for context-rich naming conventions in APIs. [00:24:02] What Defines Great Developer Experience? - The true test of developer experience: Can you be productive on an airplane? - Importance of great error messages and intuitive API design. - The shift towards zero-docs, self-explanatory APIs. More Quotes From The Discussion Enterprise Data Teams are Now More Receptive to APIs "I think more and more people are willing to pull data from your API. There used to be kind of a requirement many years ago of like, you need to push data to me, into my data lake. And the problem with that is, sure, we can push data all day long, but it may not be in the format you want. It may not be frequent enough. Like, you might have stale data if we're doing, a nightly push to our customers' data lakes. So, a lot of our customers are scraping our API every five minutes in some cases to get their incident data. And what our customers tell us is that they have data analyst teams. They have data analytics engineers that their job is to write scripts that pull the data into their internal data lake from all of their vendors. And I think that's, I don't know if it's a new trend or the new normal, I'm not quite sure, but it's definitely something I've noticed is that enterprises are spending more time building the teams to get the data in the exact format, the exact time that they want it, as opposed to having the requirement of push the data to me." On LLMs and API Design “I don't think that LLMs are going to fundamentally change how we interact with APIs. At least not in the short term. I think that they'll help us build better clients and I think they'll help us build better APIs, but the moment we start using them, I mean, that's just going to be code calling code. I just don't think that LLMs are going to get too integrated at that point.” Referenced - FireHydrant the end-to-end incident management platform ( https://firehydrant.com ) - Linear API docs ( https://linear.app/docs/api ) - Offset's Materialize RBAC system ( https://materialize.com/docs/manage/access-control/rbac ) - Speakeasy's Terraform generator ( https://docs.speakeasyapi.dev/docs/using-speakeasy/client-sdks-generation/terraform ) Production by Shapeshift | https://shapeshift.so For inquiries about guesting on Request // Response, email samantha.wen@speakeasy.com.…
 
On the first episode of Request // Response , I speak with John Kodumal, co-founder and former CTO of LaunchDarkly. We discussed how LaunchDarkly used feature flags to separate deployment from release, offering fine-grained control for safer rollouts and experimentation. LaunchDarkly was an early adopter of server-sent events, and was a pioneer of the technology even before LLMs. Tune in to hear our thoughts on the changing demands and expectations for APIs and developer experience in light of agentic era of APIs. Listen on Apple Podcasts | Spotify Where to find John Kodumal LaunchDarkly.com LinkedIn: https://www.linkedin.com/in/jkodumal/ Show Notes: [00:00:00] Introduction Sagar welcomes John Kodumal to the podcast. John’s background as co-founder and former CTO of LaunchDarkly. [00:00:28] What is LaunchDarkly? LaunchDarkly's role in separating deployment from release. The impact of fine-grained feature flag controls. Benefits: safer rollouts, experimentation, controlled beta releases. [00:02:18] Pre-LaunchDarkly Era How companies previously handled feature releases. Homegrown tools and their limitations. Inspiration from early DevOps talks, including Flickr’s feature flagging. [00:05:26] LaunchDarkly’s API and SDK Focus The importance of embedding into the software development lifecycle. Learning from Atlassian’s approach to API-driven development. Early investment in API design and OpenAPI specifications. [00:10:37] Technical Deep Dive: SSE and Feature Flags Use of Server-Sent Events (SSE) for real-time feature flagging. Challenges with existing SSE open-source libraries. Ensuring consistency across distributed systems. [00:14:23] The Evolution of API Expectations Increased demand for standardized, high-quality APIs. Importance of pagination, rate limiting, and caching. Growing role of OpenAPI specifications in modern API development. [00:19:26] Traversability and Developer Experience APIs as traversable maps for both humans and machines. Comparison to REST principles and the Fielding Thesis. How great APIs lower integration barriers for developers and AI agents. [00:22:40] What Defines Great Developer Experience? Macro and micro-scale perspectives on DevEx. Anticipating user needs and providing escape hatches. Importance of small but impactful UX details. [00:26:23] Closing Thoughts The significance of developer experience in building tools. How LaunchDarkly has influenced modern software development. Subscribe to Request // Response If you enjoyed this podcast, you can be the first to hear about new episodes by signing up at https://speakeasy.com/post/request-response-john-kodumal More John Kodumal Quotes From The Discussion Feature Flags Are Powerful “A lot of people look at just that idea of feature flags, and they think that it's small, and they're shocked that there's a multi billion dollar company that does feature flags. But it's not about feature flags. It's about all the changes to the software development lifecycle that feature flags enable” Traversability Over Endpoints “Nothing should be an endpoint. Everything should be traversable. If you have an endpoint, it's broken.” Working With The Complexity of Developer Needs “In order to fit into someone's SDLC you have to respect the differences that make their software development practices unique—you have to work with them, not force a one-size-fits-all solution.” Referenced Flickr DevOps Talk on Feature Flagging (2009) https://www.youtube.com/watch?v=LdOe18KhtT4 OpenAPI Spec https://spec.openapis.org/#specifications Production by Shapeshift | https://shapeshift.so For inquiries about guesting on Request // Response, email samantha.wen@speakeasy.com .…
 
Loading …

Welcome to Player FM!

Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.

 

icon Daily Deals
icon Daily Deals
icon Daily Deals

Quick Reference Guide

Listen to this show while you explore
Play