The Swagger Revolution: How API Specs Became a Testing Superpower with Tony Tam

Welcome to the Cloud Native Testing podcast. I'm Ole Lensmar, your host, and I've spent years building testing tools like SoapUI and Swagger, and now I'm the CTO of Testkube where we're redefining testing for the cloud native landscape. In this podcast we invite people in the space to discuss with us the challenges solutions and best practices for testing in Kubernetes and beyond, covering automation CI/CD, GitOps, and more.

This podcast is proudly sponsored by Testkube. If you're interested about how to test cloud native applications and infrastructure, subscribe and stay tuned.

Now let's dive into the episode. Thank you for joining.

---

Ole Lensmar:
Welcome again. I'm super happy to be joined by Tony Tam today, someone I’ve known for 10 or 15 years now. We ran into each other in 2011 or 2012, maybe even earlier. Do you recall?

Tony Tam:
I do, but I try not to give away any hints of age.

Ole Lensmar:
Okay, so maybe kindergarten, 2010. Before we jump into cloud-native testing, for those who don't know, Tony is the creator of Swagger—a technology that has had an enormous impact on how we build APIs today.

Tony Tam:
Exactly.

Ole Lensmar:
It’d be great to hear more about the background and where Swagger is today—though it goes by another name now.

Tony Tam:
Thanks for having me on. It's great to see you again. I had experience with WSDL and SOAP and always appreciated the ability to auto-generate clients. Later on, when REST started gaining traction, people liked browsing payloads and URLs, but client generation was still very manual—these beautiful, artisanal REST clients were hard to maintain under tight deadlines.

So, we took some of the good ideas from WSDL and came up with a way of describing APIs in JSON. After a few iterations, that became known as Swagger. I didn’t come up with the name—thanks to Zeke for that—but it caught on organically. We were lucky with the timing as REST APIs were taking off. That got the attention of folks like you, Ole, and helped spark a broader movement around standardizing REST APIs.

Eventually, Swagger was moved into the Linux Foundation and rebranded to the more neutral OpenAPI. I led version two and was on the technical board for version three. I hear version four is even more advanced.

Swagger started with a goal to auto-generate clients, but people found it was also great for documentation and even server generation. One of the biggest impacts, though, was in testing. OpenAPI specs explain what the API expects—so testing teams could validate coverage and also send in unexpected inputs, like characters instead of numbers, or negative values where only positives were expected.

Now, I see testing teams often begin by asking if there's an OpenAPI spec for a service. That becomes the starting point for their work.

Ole Lensmar:
That’s a great answer. What's interesting is that Swagger means different things to different people—some see it as a doc tool, others a code gen tool, and others as a testing tool. You really built something with broad value. I also think you did an amazing job building a strong open-source community around it.

Tony Tam:
The community side was just plain diligence and hard work. When I got frustrated with my day job, I worked on Swagger because I believed in it and enjoyed it. Early on, someone joined our IRC chat room and casually mentioned they had deployed Swagger across 300 servers and ran $2 billion in financial transactions through it the previous year. They didn’t even say what company it was—it could’ve been anything—but it was nice to see people using it in meaningful ways.

Ole Lensmar:
And people were sharing it and contributing—it really evolved organically. That helped make it so widely adopted. Obviously there’s GraphQL and other API approaches now, but REST still seems to dominate. What’s your take?

Tony Tam:
REST will be around for decades. Asynchronous APIs are useful, and there’s excitement around GraphQL, but in my experience it’s not always great. Socket-based, full-duplex transport is more interesting to me. People sometimes stretch OpenAPI to describe those, though there are probably better ways.

Ole Lensmar:
Thanks. So what are you working on nowadays?

Tony Tam:
I lead developer tools for part of a large company—still building tools to help people write great software. I still deal with lots of REST APIs, and sometimes I can’t believe I’m still doing this 15 years later. But even now, I meet developers who are just discovering OpenAPI. Part of me wants to ask, “What cave have you been living in?” But the truth is, not everyone needs to deal with API connectivity—until they do. And when they find OpenAPI, they’re usually happy... until they hit the code generators. A lot of them are garbage. I take some blame for that.

Ole Lensmar:
Even OpenAI and others use REST APIs described with OpenAPI. Connecting systems with REST is still a straightforward and efficient approach.

Tony Tam:
Yeah. And think of Star Wars—R2D2 just plugs into any system and communicates. He’s not packet-sniffing. He’s probably running OpenAPI v12. Watch Star Wars.

Ole Lensmar:
Segueing into cloud-native testing—the theme of this episode—how much emphasis is there on testing in your work building internal developer tools? Is it a top-down mandate or more bottom-up from developers?

Tony Tam:
Just to be clear—I lead tools for a part of a large company, not all of it.

Testing and the broader lifecycle are fascinating. I believe good engineers like writing good software. No one feels bad when they write lots of tests and confidently deploy. Many projects start with good testing practices—TDD, spec-driven development. But at big companies, projects grow, people leave, and others join without knowing the original testing strategy. Deadlines, new dependencies, and shifting priorities can unravel things quickly. Suddenly, you're disabling tests because they don’t run with the latest framework, and the once-great test suite falls apart.

Without containerization or good mocking strategies, you're stuck. Testing falls behind, everything slows down, and before you know it, you're moving like a slow, bloated company. That’s why infrastructure and tools are critical—not just mandates. You need easy, reliable systems, and alarms when tests are disabled. Every company, especially large ones, needs infrastructure to keep testing on track.

Ole Lensmar:
Platform engineering is a big topic now—especially in Kubernetes. It seems like those teams are responsible for enabling quality guardrails and making testing easy. Are you seeing that too?

Tony Tam:
Yes. If you set up platform testing infrastructure early, it's often easier than cobbling together your own CI and test suite. But if you bolt it on later, it can be a nightmare. It requires constant maintenance. New tools, languages, and protocols keep evolving. But if you do it right, you gain velocity and avoid running into walls.

Ole Lensmar:
Totally agree. It's about culture and communication, and starting early. You need someone to champion testing and quality. Now that we’re in a cloud-native world, has Kubernetes and containers made testing easier or harder?

Tony Tam:
Containerization is incredible—you don’t have to set up an OS or dependencies. Isolated services with clear boundaries are easier to test. But new challenges come with it—network rules, namespace isolation, and recreating production environments can be tough, especially for big companies with multiple regions or compliance requirements.

Cloud-native testing infrastructure is essential, but also not simple. You need real expertise. The "full-stack engineer" doesn't cover cloud-native testing infrastructure.

Ole Lensmar:
Something we’ve seen is the rise of infrastructure testing—validating that environments are provisioned correctly, especially with dynamic infrastructure. Is that something you encounter?

Tony Tam:
Absolutely. Think about GPUs—different models, configurations, versions. Virtualization doesn’t protect you from hardware mismatches or physical network issues. We’ve seen all kinds of weird hardware problems. Disks fail constantly, routers have flaky ports. You might just experience flakiness in your app and not realize it's a hardware issue underneath. You need tests that validate the environment, not just the app.

Ole Lensmar:
Do you think that also means applications need to be more resilient—or that chaos testing is more important to simulate failure conditions?

Tony Tam:
Definitely. Service dependency issues are tough—especially when calling external services. You don’t control their reliability or changes. An error code might change one day because someone thought it should be improved.

Once you depend on external services, you’ve lost your version control. It's like back in the day, when we downloaded random jar files. It's unpredictable. You can implement caching and retries, but it depends on the use case. For a credit card transaction—no. For a dictionary API—sure.

Ole Lensmar:
So designing fault-tolerant APIs and clients becomes essential.

Tony Tam:
Exactly. Good service architects understand when a call is critical versus non-essential. Cloud-native tools help monitor traffic and production behavior. Our SRE teams handle a lot of that, but it's essential work—especially now that everyone depends on external services like ChatGPT. You're not building your own GPT—you’re relying on others.

Ole Lensmar:
That might be the key difference between cloud-native and "OG" testing—factoring in resilience and infrastructure reliability from the start.

Tony Tam:
Definitely. You've seen that too, right?

Ole Lensmar:
Yep. Building great software is hard. Cloud-native adds complexity, but also powerful possibilities. Testers and QA teams just need to stay informed and adapt.

Tony Tam:
Absolutely.

Ole Lensmar:
Thanks so much, Tony. Great to catch up, and really appreciate having you on the show. Good luck with everything—testing or not, APIs or not.

Tony Tam:
Thanks a lot.

Ole Lensmar:
Take care.

‍