Sergei Egorov:
We cannot simply let it disappear. I mean now we have no way back, for us as open source maintainers. The community would not appreciate if TestContainers will be no longer, it becomes a critical component of modern software development.

Eric Anderson:
This is contributor a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson.
This is a conversation with Sergei and Eli, leaders of AtomicJar. The company behind the open source project testcontainers. Testcontainers is an exciting project that has become basically the API for integration tests and not the integration test you're used to in the sense that these run locally on your machine, they act like unit tests. TestContainers is a library inside your code and the test can run on your local machine. The project is wildly popular originally on Java with six and a half thousand GitHub stars, but now drawing even faster on .NET and other communities.
I'm excited to have Eli and Sergei here of the TestContainers team. TestContainers, as you may already know, is a wildly popular open source project, six and a half thousand in climbing GitHub stars that help people test their software quicker, more efficiently, easier. Let's start there, actually. Sergei and Eli. What are TestContainers? Exactly? Hey,

Sergei Egorov:
Eric. Oh, first of all, thanks for having us. Always happy to talk about TestContainers, open source, especially given the current context of what we usually talk about. So TestContainers is as you say, as the concept of this call is open source library, and we always make it in phases on library because when it comes to testing, we are usually exposed to products or solutions and ephemeral environments or something like that. While I think what made the whole difference with TestContainers is the fact that it's a library, it's something that developer can add as any other library and they could get going without learning a new parting, without migrating, without whatever. But maybe before I talk about what made it popular, I can describe what TestContainers is. And TestContainers solves one of the biggest or one of the hardest actually challenges in development confidence, how to gain confidence that the code, your writing is correct.
There are various ways of how to gain more confidence. You can use statically compile language, so at least knows that the thing you wrote will compile, will run, but obviously that's not enough. You can run some unit tests and you can verify say two plus two equals four. That's good enough. But at the same time, modern applications, they talk to external databases and some of them are actually very small. They are basically some things that reads from database, transforms it and sends it to other IO source like resting point or other database or Kafka topic, whatever. So how do I test it? Obviously not with unit tests because then if I mock my databases, I'm almost not testing anything.
I actually need to test that my queries that I'm writing that they run correctly and TestContainers solves exactly that. It gives the developers a set of libraries available in various languages like Java, Golang .NET, and others that they can plug into their project, into their test suit and start those external dependencies, Kafka, Postgres, Oracle, [inaudible 00:03:43], or literally anything else that can run a docker container and powers their task, runs their task with those external dependencies without learning, well, Yamo or Kubernetes or anything else, or even Docker, in fact, because now it becomes a single line of code that any developer can write, including an entry loud developer, "New Kafka container," boom, you have Kafka container running.
And that's what I believe because I wasn't the original author. The beauty of TestContainers and what really clicked with developers, the simplicity and the friendliness towards entry level developers, which is I think is one of the most important things in the modern world of software, how to bring more developers into all these best practices that we adopted.

Eli Aleyner:
Maybe just to build on what Sergei just said, in some ways, the way I think about this, it makes writing integration tests as simple as writing unit tests. That's how I summarize the value of TestContainers in my mind at least.

Eric Anderson:
Got it. Well, okay, so in a world of microservices or even just services, we're generally building our service against other services. And in order to test our service, we need to test the connection to these other services. And doing so is a lot of work unless you've got a library that abstracts containers and other ways of connecting, is that maybe part of it?

Sergei Egorov:
Precisely that there is a simple need that requires a simple solution and a lot of other solutions aren't feeding into the definition of simple, hence TestContainers adoption.

Eric Anderson:
Totally. And let's get to how this came about. Sergei, you already hinted that you're not one of the original authors of TestContainers. Where did this come from, and how did the two of you get involved?

Sergei Egorov:
So TestContainers started... It is open source project that started almost eight years ago. We celebrate eight years in April and was started by Richard Norris who was back then at Deloitte Digital and he was building it for himself. It wasn't the idea, "I'll build this open source project for it to be successful, because there are some projects that are being built to be successful." No, he created it to solve his own pain and he had exactly the pain we just talked about, "How do I power my task so that I can run them on my machine as part of my software development lifecycle?" And back then they weren't that many solutions.
And eight years ago wasn't really something that was on everyone's machine and everyone's production containers were just getting their wide adoption. And I'm not saying the Docker created containers. No, what Docker did, they created great tuning around containers just like how to make it easy to build images, to publish images, to consume images. And while writing dock in production eight years ago wasn't something that would spark joy in everyone's mind, yet.
On desktop, it was getting more and more adoption. People realize that "Hey, actually this obstruction, Docker obstruction gives a lot of tools to solve the problem of testing." And while other solutions were focused on the idea of externalizing it, let's say FIG now known as Docker, compos was one of such tools, you would just write the Yama file, you'll describe your containers in the Yama file, start them with a single command, and that's already good start. Then you can run your test with those containers.
But the problem is that the developers had to learn, first of all what Docker compose is, then what Docker is. It wasn't that every second person is very experienced with Docker. Back then it was just like a tiny fraction of the developer's community who were on the bleeding edge of learning new tools, including Docker. So it required the developers to inherit not the complexity per se, because Docker obstructed away a lot of complexity, but still the specifics of Docker and related tooling.
And another thing is that I'm a big fan of clone and run. When I clone the project and I run it where I don't need to read me where I don't need to run some scripts where I don't need to do anything. I just clone any project from GitHub or any other source control system and I can run it. And most importantly, when I prove changes, I don't need to read me again because someone changed how we start our test environment or maybe I'm using an outdated version of the database and now we migrated to a newer version, something like that. I just want to run my test and expect them to be self-contained as in my test should be starting everything that is needed for them to run.
And that's what triggered the idea for Richard. It was just like, "Hey, Docker is an HTP API, how Docker Compost works, it talks to Docker over HTP, so why can't we do the same from Java code, from Go Code, from Python code?" There is a HTP client in every language out there. And he came up with this idea of building task containers as a solution to make tasks self-contained to store their external dependencies in place of Mocks, where previously they had to use Mocks and Mocks certain interfaces or use in memory databases that weren't gaining them the confidence because they were using Oracle in production.
And he shared with me the story where he had to run with CD with Oracle installation and installed on every developers machine just to guarantees that they have the same installation of Oracle needed for their testing. But with TestContainers, they were able to get rid of it basically to make external dependencies shareable as a code available to any developer at the company, that was the original idea of TestContainers.
And by the way, as Richard said about it, I thought it's going to take a few months and then I can call it done. Just like it's simple enough project to spend a couple of months on it. And then once we have the concept, I don't need to do anything about it anymore. It was eight years ago. And TestContainers right now remains one of the fastest growing Java projects, one of the most popular testing libraries out there. And we have so many more ideas how to evolve it.
But maybe I could quickly explain what the hell I'm doing here because as I said, Richard was the original creator, but shortly after he created TestContainers. Around that time I was working on ZeroTurnaround, a small defunct company from Estonia. And we basically had our own TestContainers internally. We had the very same concept of talking to Docker directly from TAS, very same pain, very same everything but our project was inner source. It wasn't open source, but as a patch software foundation member and a number of other open source communities I was involved into including Spring, for me, it was a no-brainer that Richard's open source solution is better.
And the way I discovered it is another fun story because I really believe that one of the best things in GitHub is a networking effect. And the way they achieve it is cross-linking from issues. When you read comments, you read comments on some issues that you Googled and you see other projects talking about the same issue. And I was literally trying to solve one of the problems I had with our library. I was looking at the Docker client for Java and I noticed a link from task containers and it was just like, I'm looking at Docker, I'm working on a test library with containers and I see a reference to task containers, so obviously I need to check it.
And one day later I already convinced my manager and his managers that we should teach our internal implementation, backport all the features that we are missing in TestContainers and start using the opensource library. And I guess I was so noisy with my contributions that Richard just gave up and invited me as a container of TestContainers. And ever since then we were working together on TestContainers with Richard and later Kevin Wittek joined us as cert maintainer.

Eric Anderson:
Got it. Yeah, I know, I see here on the GitHub that you know number two in terms of contributions, you're right up there with Richard. Very good. Eli, how did you get involved in the project? So

Eli Aleyner:
I got involved a lot later. Sergei got involved in the beginning and drove a lot of the success. I started seeing TestContainers much later and what excited me is actually the implications of the projects on companies and teams that are adopting TestContainers. The specific item that I think Sergei has mentioned here, this idea of self-contained tests is extremely powerful because what this allows users to do, it allows them to write tests that can execute independently of everything else and provide confidence to them to ship software to production.
I always remember it as experience that I've had when I was early at Amazon, right? The idea of hey, we were building S3 and we had an integration environment and the integration environment had integration tests, fun story. It also had, we had monitors all over our working environment and on the monitors we had a bunny. And when 80% of the tests were passing, the bunny would be super happy when less than 80% of the tests were passing the bunny would be a little upset. And as we continued our journey in building integration tests and shipping software, that environment became less and less useful because tests were failing more often because the environment provided less and less confidence and over time it became less used.
And this idea of being able to get confidence as you develop software before you go to integration environment, yes, you might still use an integration environment, but getting confidence before you go there, getting this confidence quickly, getting this confidence on your developer machine is extremely powerful because it allows developers to be more productive as they develop code. And that allows organizations to ship software faster. And I've structured my career over the years to really gravitate towards organizations that can do that.
And that to me was a no-brainer when I saw Sergei and Richard building TestContainers and the opportunity arose to be able to join the project and the company, I jumped on it because I felt such a strong connection to the mission of what we are trying to build.

Eric Anderson:
Awesome. So self-contained tests, I guess I think I didn't fully grasp the implication that these all run on your local machine and presumably they're less flaky if they've asked the right word, than your typical integration test that's subject to network availability or different contexts around the services. Maybe there's new data in the database that kind of messes up your tests. So if I'm a traditional developer, I've got a bunch of unit tests, a handful of integration tests, and I adopt TestContainers, I'm going to take half those integration tests and I'm going to pull them into my local suite, right?

Sergei Egorov:
I think it's a good question. What are the implications of using TestContainers? Because they do change the way you treat your task, the way you're reasonable your task. And as Eli said, what actually the approach that we are advertising, we are enabling the TestContainers experience is much closer to unit task than to traditional integration task or integrated task. And Spotify had a really good article on virus testing stages, how they do that. They also do it with desk containers that you can grasp from the article, but they talk about what is an integration test? Is it an environment or is it just the idea of testing your code with external dependencies?
And Martin Fowler also talks about the definition of integration task that is right now is a bit... I mean, there is a lot of ambiguity whether we talk about environments or not. And in TestContainers, we're try to avoid even mentioning word environment because that's not something in our vocabulary, that's not an obstruction in TestContainers' experience while individual external components are, you're not starting an environment with Kafka, Postgres and Redis. You're starting Kafka, Postgres and Redis similar to how you instantiate variety of objects in your code.
Indeed, it's a local experience, it's part of your software development lifecycle, it's your inner cycle development loop and you code, you run your task and you get feedback that is also much faster than just compiling something, deploying it to some environment or know someone else deployed to that environment. Something else as per Eli's story at AWS three, he was always humble and he was also referring, "Oh, yeah," but Eli was on the original team of AWS S3 and you've seen it at that scale. So I never worked at the scale of something like AWS S3, but I can easily understand the pain he's referring to because those staging environments including integration environment. So code is a snowflake.
If I may refer to this, pets versus cattle DevOps parting, it's the same thing. Staging environments are pets, you take care of them, you are really sad when they go away and so on and so forth. While what we advertise ephemeral components for tasks that you start-stop always with the fresh state. You never inherit outstate from the old run unless you choose to so that you can iterate faster. But then you explicitly acknowledge that, "Okay, the state will remain between the runs," and it makes the feedback cycle from tasks much faster than any other testing approach, including staging environments, end-to-end testing, browser testing and so on and so forth.
And it's something familiar to developers, they know how to instantiate objects and they know how to send, let's say, request to their REST service. Their REST service might not even have UI so they cannot use something like Cyprus or a Selenium or something like that to test them. But they can do it with the APIs, but they need to power their services for them to start. And that's how they do it with TestContainers.

Eli Aleyner:
They don't have much to add to what Sergei said, because he made such a complete answer, maybe just very, very high level at a three. If a test fails in integration, you never know if it's a data issue. If some other dependency you have somebody else deployed something else, no clue. You start getting to a situation where, I don't know, 20% of the test fail. Why is it happening? Is it my code? Is it an environmental issue? Is what's happening? And then the more time passes, the more fundamentally it becomes like "Okay, are we going to invest the time to get the tests passing now? Or is this just normal?" Is it becomes a background thing. So as the system becomes bigger is you build more components, the value of that becomes less and less because you have to invest more and more to continue maintaining it. And that's completely the opposite of what you want happening when you're building software.
This is why the idea of TestContainers resonated so much. And this is why I believe we are seeing such adoption curve for that technology and such adoption curve, not only on individual language, it's not language specific because the paradigm is the same paradigm whether you're writing in Java, in .NET and go any language because that it's so powerful and up until this scheme about people thought about containers and people thought about those technologies as primarily the past production, but it adds so much value in the inner development loop. And then once you adopt it, of course you can run the same test in your CI test as in your CI, they add more value. But by you being able to do this on your developer machine and being able to get feedback earlier, you're able to discover bags earlier, you're able to fix bug issues earlier, you're able to develop faster.

Eric Anderson:
Eli, I think I'm with Sergei being on the original AWS S3 team is a big deal. S3 was the first product. So you're on the original AWS team, right? I mean that's full stop.

Eli Aleyner:
I joined AWS when AWS less than 50, before that I was an intern, it used to be called web services in the original email that I got.

Eric Anderson:
I want to go back a bit to the history here. So Richard started this project, he thought I was a few months, now he's a couple years in or something, Sergei's on board, but this is still an open source project. No one's decided, "We're going to build a business here yet." Eli's not quite involved yet and the project's growing, but it seems to me it's growing organically.
A lot of the people I interview on this show, we go look at Hacker News and we can see distinct times that they went viral and everybody got excited about them. TestContainers shows up on Hacker News a lot, but it never quite explodes on Hacker News and yet the project's just on a tear. How do you think about the adoption path for TestContainers? Maybe you could describe for how that has come to be.

Sergei Egorov:
So when I joined TestContainers project existed for three or four months I think. So I joined quite early. And what I start doing, because it was my passion, I start talking, I mean I almost passionate about sharing something that I learned with others just especially if it made me happy. I'm just like, "Hey, this is cool thing, have you tried this restaurant? Because it's the best food I ever had." So I'm also passionate about that and I start doing conference talks on TestContainers, I start talking to others about it.
And actually what happened is that as developer, I mean, I wasn't developer advocate, but I was doing developer advocacy. But as a developer, advocates, especially from early days, folks from Elastic for example, they started talking about TestContainers. Two because it solved their pain. They didn't want to maintain embedded elastic search. They were having lot of issues. They were limited in what Java runtime versions they can use because of those customers who were using embedded elastic search that were required to use exactly the same version.
And here they have TestContainers, something they could delegate this experience to because they're infrastructure companies, they're not actually developer tools company, they're not selling to developers, they're selling to infrastructure people. So they would ideally delegate it to someone else. And TestContainers, was that someone else for them. So their developer advocates start talking about TestContainers.
Eventually they duplicated them by the elastic surge and they were recommending TestContainers as a solution and others were doing it too, from big companies. And indeed, we never had this moment when someone famous would say something about TestContainers and boom, I know plus thousand stars on GitHub. Our growth was very organic coming from conference talks. For me, just sometimes going to other open source projects and offering them help with TestContainers.
And it was a question of discoverability, just like whether the right people discover it or not. And of course there is this viral effect where someone discovered it, water cooler conversation team talking to another team, someone doing internal tech talk about TestContainers. And we are seeing it almost every day. When I joined TestContainers project, one of the things I started doing, I started monitoring GitHub code currencies for TestContainers mention.
Funny story, there is some tool by Microsoft and one of the properties in their XO file is TestContainers. It has nothing to do with TestContainers, open source library. But it really messed up my search. So I really had to... And I couldn't ignore XML files because Maven POM files are also XML. So I was spending a lot of time just like, "Nope, not TestContainers. Not TestContainers, not contain... Ooh, TestContainers."
And one of the early adopters of TestContainers was, well, Apache Software Foundation,º really when project was probably less than year old, start with a couple of Apache projects, but then it really exploded. And Eric, I know that you were involved into Apache Beam and probably are still involved, and Apache Beam is one of the examples of TestContainers adopters, but the fact that it's a library made it easier for them to adopt. And in fact for something like Apache Beam, well, you don't even have production, you didn't even have staging environment. How do you test other than while you develop, right?

Eric Anderson:
Yeah. TestContainers started as a Java library if I recall. And a lot of the Apache projects are Java and they all work together. So I can see that as a great breeding ground where if you get into Kafka and then people are using Apache Beam with Kafka, they see the dependency and then maybe you're also doing something with Spark or you name it.
All these projects work together. So that makes a lot of sense. And then the developer relations developer advocate channel is clever, as well. I can imagine demos being a lot easier when you can quickly show people how to stand up tests.
So I want to move us forward a bit to at some point Sergei, you decide there might be a business here and I'm curious, is that something that Richard ever considered pursuing? Is that something, how did the kind of formation of the business come about?

Sergei Egorov:
So since I was exposed to those developers who are using those other companies who are using it well, Richard was a bit more on the development side of things. I always had these feelings that there is something about it, there is an opportunity and as always was open source. Actually commercializing open source is a huge challenge and it requires a lot of product work. Actually before you start the company, you got to be a product manager for your open source project before you understand how to commercialize it, not as the way around. We're like, "Hey, we have an open source project, we should just raise around and we don't know how to commercialize it, but we'll sure figure out, there must be something because our stars are growing." Well, that's not how it works.
But over those seven years or six years before we started the company, we accumulated a lot of feedback on TestContainers and overall it was very positive feedback. People were happy with it and there were some major pains that we unfortunately couldn't solve, but they were related not to TestContainers, but let's say Docker is... I mean Docker is what makes this whole thing work. But at the same time, not everyone can get Docker running on their machines. Or maybe their security teams aren't unhappy with having Docker and their CI pipelines where many other reasons, just like Docker is a great technology, but adoption is weird. It's overly adopted in some areas and adopted in others, but it was one of the major pains.
And when projects started and even a few years into project existence technology weren't there yet to do anything about it, I would say we're barely, there's anything we can do and we didn't want to sell TestContainers Pro. First of all, we don't know how to do it, but also we don't want to do it. It's a very dangerous pass where you always have to make this trade off of what features go into pro version, what features stay in open source or we do companies with more than hundred developers need to buy pro. That's not the conversation I want to have with our open source community because we value them a lot, they like us a lot. And I don't want to break this relationship because of our commercial reasons.
But a bit more than two years ago we've been thinking about what can we do about Docker? Postman isn't really an option because it's, first of all, it was early days of Postman but also doesn't solve it fully. It's 20% improvement to the problem. It's not a hundred percent improvement than Kubernetes. Well, it's actually even bigger problems than Docker because at least Docker, everyone knows how to install. Kubernetes, there are five different ways of installing Kubernetes on desktop alone and not to mention a variety of options of running Kubernetes in let's say CI pipelines.
So we needed a solution and we realized that, "Okay, if we cannot solve it locally, we could solve it remotely." And this idea of remocal dev tools where it feels like local but it's actually remote, really clicked with us. Back then it didn't exist this word remocal. And what we realized is that we can actually move those containers off the machine that runs the test but not too far somewhere on the edge because the technologies allow us. And then the very same TestContainers based test can run on the very same machine, but the containers will be running somewhere else. So that now TestContainers based test can run on low powered machines or low performed machines.
But also Apple silicon start gain popularity. And more and more of our users starting telling us, "Hey, how do I run my TestContainers based test and Apple M1 because it's armed and Kafka won't start, Oracle won't start many other containers that I used to run and I need to run them today." Just like "I just got this new shiny Apple M1 laptop. I was so excited because everyone is talking about them. But then I realized that I no longer can run my test." And this is where it really clicked with idea of TestContainers, cloud and moving containers to the cloud while keeping the test on developer machines, NCI environments with the original machines and environments.

Eric Anderson:
Oh, it does seem like Kubernetes and M1 are a perfect storm to help you out.

Eli Aleyner:
To me, this approach that Sergei and Richard were taking around building a commercial product that actually helps the community and doesn't necessarily limit features or the commercial product makes the open source better appealed very much, I would say. Previously to joining Sergei, I tried to do something somewhat similar by taking, working inside of VMware and Pivotal, taking the Spring framework and building a managed service around it. At the time I did it with Microsoft, this is called Azure Spring Apps.
But this idea of taking open source and providing a better run time, providing value, providing things that developers would choose to use, not because we are limiting something, but because they choose it, makes it better appealed. And this is again why the conversation with Sergei, why I'm so excited about what we are building over here because it actually helps the community.

Eric Anderson:
That's awesome. And I think you're thoughtful about going through this process in the early stages of the company. Because I think a lot of folks don't have that clarity of how we're going to monetize and how that will compliment the community until much later. Good for you.

Sergei Egorov:
It was something really important for us by the way, to pick the right strategy from day one because both Richard and I, and also Kevin, certain maintainer who is our employee, number one, we deeply care about TestContainers community. We actually have personal responsibility for this communities that we have built. And I mean at the end of the day, TestContainers' something that's currently being used at the biggest companies out there. I could just start first ones in my head. I know Spotify, Uber, Netflix, VMware, Google, and a bunch of Capital One and 1/6. I can continue counting those big, big companies, startups, companies of virus stages.
But what it means is that we cannot simply let it disappear. I mean now we have no way back. For us as open source maintainers, the community would not appreciate if TestContainers will be no longer, it becomes a critical component of modern software development, especially in Java. We also received this contribution from GitHub where the distributed fund to open source projects they're relying on and that's how we learned that TestContainers is also used at GitHub. But the point I'm trying to make is that we couldn't really risk for us, it must have been a low risk strategy. We needed a solid commercial idea because what could happen, should we have an issue with our commercialization strategy is that we will either be forced. And back then we didn't know how VCs works, so we always assumed the worst.
But back then, especially our thinking was that, "Should we fail with our TestContainers cloud product, then we'll be forced to go and commercialize TestContainers itself." Like start setting TestContainers, start removing features from open source and adding it to commercial version, and that was anti-go. So for us, it was one of the most critical thing, and this is why it took us so long to actually make a decision to just commit to, "Okay, we are starting, we doing, we know exactly what we are doing." And we also did a lot of interviews with our open source users before starting the commercial company just to know that what we are building will be later purchased by them because that solves their pain. So for us, it was critical.

Eric Anderson:
Great. As we wind down here, Sergei and Eli, anything you wanted to cover that we didn't cover yet? I imagine some folks might want to hear about the future of TestContainers, what gets you excited, but I want to just float the idea if you have anything you want to cover, let's do so now.
One thing I'll mention, we talked about this being a Java library at first, but you've already mentioned that you cover Go Python, several others. That's certainly one dimension of excitement around TestContainers. What else do folks have to look forward to?

Eli Aleyner:
Absolutely. The multilingual part of this is super, super thrilling for us. In fact, internally we look at the adoption curve at least as measured in stars on GitHub. And we are seeing .NET actually overtake Java in terms of the rate of increase of stars on GitHub. So that makes us super, super excited. We're excited about the fact that other companies are also starting to support this idea of TestContainers. So Elastic has TestContainers in their documentation. We have other folks who are now.
It becomes somewhat of a standard, other members of the community starting to build on top of it. And that gets us super, super excited. Of course, we're excited when we talk to our prospects and customers seeing how what's the implication of adopting TestContainers on those large companies And we learn a ton from having those conversations. Sergei, anything to add?

Sergei Egorov:
Just maybe on the multilanguages story, because it took us quite a bit of time to convince the world that TestContainers isn't just about Java. Yes, that's how it started in Java. But then shortly after Python was the second version, Golang was assert and then it just exploded because it's really not about the implementation but about the experience, the approach, the idea that we are promoting and I mean, reimagining is like it's a buzzword, but we just took a different path to how testing can be done and it really clicked with developers.
And it doesn't matter if I develop in Java, in rust, in .NET or any other language. The idea is the same. And the good news is that there is TestContainers library. So I need to build it myself first of all. But also I don't need to choose. If I change from one project to another, I'll see the same obstructions or more or less the same obstructions. So make it language native so that you'll not be like, "Oh it's very Javish code and Golang." No, it'll be Golang native code.
But indeed this adoption leads to a question of, is TestContainers becoming the API for integration testing on site platforms? And that's what we see right now. It's already... Especially in the Java world, all major Java frameworks integrate with TestContainers; Spring, Quarkus, MicroNaut, all of them have first class support for TestContainers. Some took it even further. For example, Quarkus, they implemented local development mode where I'm not writing automated tests, but I want to start my application and clicks through UI or maybe send some queries with Postman or [inaudible 00:37:40] as a tool or Corel, for that I need the same thing.
I need to start dependencies then to start databases. I need to start brokers and TestContainers can be used for that. And red Hot integrated into Quarkus. So they have TestContainers powered local development mode. MicroNaut did the same and we are working with the Spring team on doing the same. And I heard that in other languages specifically in Golang. They're also exploring this option because I see starting applications locally as just yet another type of testing, manual testing. So even we don't even need to rename the library. It's the same TestContainers that powers automated testing and manual testing.
And given that our API seems to be good enough, stable enough, and appreciated enough by other framework authors, it gives us the opportunity to just become the defacto API, making it possible to enable developers do the development and gain the confidence they need to ship their code even before they committed to repository.
And as the vendors who support us only help us in that journey, it's a long journey. It's going to take quite some effort to get there, but at least we are committed to build this API and have it so that the developers out there will be enjoying the TestContainers experience, same experience that led us believe that we should invest eight years of our life maintaining it on our spare time on evenings before we start the [inaudible 00:39:15] chart because we truly believed into this approach and we still support by the community too.

Eric Anderson:
Yeah, I don't think outsiders fully appreciate just how different open source or development communities are by language, their subcultures. And so the fact that you took off within Java and then have been able to replicate that success in different ways in each community, presumably because there's different kind of cultures and ways of doing things in each one is exciting and does suggest that you're headed in the direction as you point out of being the API for better testing.
Sergei, Eli, thank you so much for coming and sharing this with us. We look forward to seeing what the new year holds for the project. I know you've got some big enhancements coming. Appreciate you spending the time.

Eli Aleyner:
Thank you.

Sergei Egorov:
Thank you, Eric. It was a pleasure to chat about it, and thanks for keeping focus on open source. That makes me happy.

Eric Anderson:
You can subscribe to the podcast and check out our community Slack and newsletter at contributor.fyi. If you like the show, please leave a rating and review on Apple Podcasts, Spotify, or wherever you get your podcasts. Until next time, I'm Eric Anderson and this has been Contributor.