Let’s get nerdy with it.
On this week’s episode of Dev Interrupted, Dan gets technical with Sergei Egorov, co-founder and CEO of AtomicJar.
With the mission to make integrated testing simpler and easier, AtomicJar created the Testcontainers Cloud which allows developers to test their code against real dependencies, not mocks. Today, Testcontainers powers over a million builds per month, helping developers build and release their software with confidence.
Dan and Sergei also talk about the difficulty of finding time to code once you become a CEO, the challenges of building a product for developers, and the culture differences between Russian devs and U.S. devs.
If you’re a developer or enjoy learning about dev tools, this is the episode for you!
Episode Highlights Include:
- How Sergei became a Java champion
- What it's like to grow up in Siberia
- Cultural differences between U.S. and Russian devs
- Letting go of writing code when you become CEO
- Why it's hard to build a product for developers
Our Interact conference featured content from the best engineering leaders in the world. Watch it on demand on YouTube now.
Transcription:
Dan Lines: Host
Sergei Egorov: Co-founder and CEO of AtomicJar
---
[Music playing]
Sergei: [0:00] A few weeks ago, I realized that my last commit was from the very beginning of September. And it's so weird because I mean, I'm a developer, like I want to write code, I'm enjoying writing code. But I realized that okay, I'm also enjoying running the company now. It's a big surprise, I would never think that I would spend a week without writing code. And here I am just months without spending enough time implementing features.
Producer: [0:26] This episode is sponsored by Linear B. Accelerate your development pipeline with data-driven engineering metrics, continuous improvement automation, and project visibility while cutting your software development cycle time in half. Sign up for your free demo at linearb.io and mention the Dev Interrupted podcast discount for one month free when you sign up for an annual pro membership.
Dan: [0:46] Hey, everyone, welcome to Dev Interrupted. I'm your host, Dan Lines. And today I'm joined by Sergei Egorov, the co-founder and CEO of AtomicJar. Sergei, thanks so much for joining us, and congrats on the four-million-dollar seed round funding earlier this year.
Sergei: [1:04] Thank you, Dan. It's a-indeed a great opportunity for us to turn what we've been doing as developers into something bigger. And yeah, I'm excited about this opportunity also to talk to folks like you. So, thanks for inviting me.
Dan: [1:17] Yeah, absolutely. You know, I want to start by giving our audience the opportunity to get to know you a little bit better before we dig into AtomicJar. I see from your background, your LinkedIn profile, that you're a Java champion, at what age did you start learning Java? And then like, how did you be-come to be a Java champion?
Sergei: [1:38] So I've been doing Java development for I think, around ten years. And it wasn't my first language, definitely not to start with PHP, bit of Pascal, and stuff like that. I was also into game development for seven years and was like, my first geeks were actually a game development project. And it was fun. You always have this yesterday deadline, but at least it's fun. And then it turned into Java developer. And eventually, since I was doing conferences, some community efforts, developer advocacy for best containers project and other projects got the condition as a Java champion, which is a title you receive, rather for what you did versus for what you're currently doing. But on the other hand, it's a nice thing to have this recognition of your efforts, because most of these efforts were on your own capacity and not like you're paid for it or something like that.
Dan: [2:33] Do you have to get nominated or how does it work to get to be a Java champion? What's the process?
Sergei: [2:40] Java championship is elimination only program you have to be nominated by another Java champion, and then they would-and then, it’s as simple as receiving two minus ones to get denominated. But luckily, I guess, I don't have enemies. Or anything like that. Yeah, I got past elimination.
Dan: [3:01] That's really cool. You mentioned you-I think some of your first gigs, you said you were a game developer. That's the type of job that I remember when I was doing development. Like everyone wanted to be a game developer, video game developer, like what type of games were you working on?
Sergei: [3:16] Mostly social network games, were online games, some, but, like, some casual ones, something simple. And I've been doing a lot of Adobe Flash development with ActionScript and flex and everything. And I don't know, like, I still miss Adobe Flash, to be honest.
Dan: [3:32] Yeah, that's funny. Like my second job out of college university. I was doing ActionScript and Flex. I remember I was messing around with-I think it was called PaperVision back then, which is like a 3D-and I was working at a startup company, Aprigo which, that was the name of the company, it became Cloudlock. We then changed the name, and it became very successful, but there was probably only like, ten of us at the company at the time, maybe less. I was a junior developer, and our CEO, Gil, like I was doing the front-end developer development and I brought in PaperVision, and we were making a da-we were doing security software, and I was building the dashboard for a security officer to look at. And I did it with PaperVision, so like the panels would fly in and it was in 3D. And I remember show-showing it to him and he was like, “Oh, this is awesome. Like, how the hell did you do this?” I'm like, “I don't know. I just found this thing, PaperVision. It's really cool.” Now, something else that's interesting about you, you've spent part of your career working in Russia, and I believe Estonia what was that experience like for you? I mean, you're-you're in the US now. Is there like a difference in culture with coding practices, or what do that mean for you with these working all over the world?
Sergei: [4:52] Maybe not half of my career. I think I moved pretty early to Europe, but I definitely started my career in Russia and I grew up in Russia. I grew up in Siberia, in fact, and like minus 53 Celsius is what I usually refer to the explain where I used to live, because I obviously went out when it was minus 53, but shortly after, or like right after I got my diploma, I-I moved to Estonia to work at one of the game development companies called Creative Mobile. And it was an interesting shift. Like, I definitely noticed that when you move from Russia to Europe, you definitely notice that things are being done differently. And it is different in so many ways, starting with something-like in Russia, I know most of the half of the team will be smoking. In Europe-and that's just funny fact.
Dan: [5:36] Yeah, yeah.
Sergei: [5:37] In Europe like they have just couple folks going out and having these breaks. And I'm not smoking cigarettes or anything. And I was just using this just to talk about something because, you know, it's cooler conversations or water dispenser conversations, they're usually the best. And yeah, I notice that I'm not having as many of them as they used to have when I was in Russia, but that’s engineering culture because Russia's are many companies that are outsourcing as our workforces, and in fact, before moving to Europe, I spent a good amount of time working at one of such outsourcing companies. We were doing projects for stuff, like I don’t-, EA, Zynga and some other big-really big titles and companies. But we were a small outsourcing company. While in Europe, there is a lot more product ownership, companies that creates their own products. and for me, it’s much better experience to be honest, because you are in control of what you're doing. And you also see the impact because then if you're successful, then you also feel-you can celebrate. It's not like you're-
Dan: [6:37] You’re a part of it more. Yeah.
Sergei: [6:38] Yes! Yeah, because when you outsource, you just okay. Someone else is successful. And they're like, Okay, you're being sided to the next project now. Oh, well,
Dan: [6:46] I have experience with outsourcing development to Ukraine. There's great development talent there. I love the guys and girls there. But I always just felt like what could we do to make them feel really a part of this project? This is yours, because that must be tough. Like, like you're saying, where you're kind of a gun for hire. Okay, I'm working on this project. But I could be assigned to something different really fast. So yeah, that's interesting. I never thought about that in perspective.
Sergei: [7:14] So I just wanted to say, one of the things that-what-some things that you won't notice, unless you are from inside is that usually, that person who's being one hundred percent allocated to you, is also working for five other customers with a hundred percent allocation. And then you think that okay, like this developer’s been working with us for, I don’t know, for a year, full-time and everything, and then he or she should feel, and I know, like the feeling of celebration, but then when you look at it, apparently, there was someone who was kind of five weeks and been working with four other customers. And this is crazy, because this, I don't really understand how people survive at such companies for, I don’t know, more than a year because it's exhausting.
Dan: [7:54] Yeah, that's tough. Have you noticed any differences in coding behavior or practices, like, I'll just give one example that that I've seen, sometimes I felt like, in the U.S. a while back, we were really into the agile movement, and how we work together, and you know, all these ceremonies, and I've been working with engineers in Israel, these are like brilliant people, super smart people, and they were a little bit more, I think, pragmatic, like, I just want to get the work done. Like, who cares about all this, like agile stuff? Did you notice any cultural-with like, quality or anything like that?
Sergei: [8:34] Oh, yeah, as there is a major difference. It starts with soft skills, because in Russia, I mean, Russia in that regard, more, more like China, where soft skills are-I’m not saying that it is the case for China but it's what I heard about China, that soft skills are kind of under prioritized. And then the priorities go to hard skills, commitment to work and everything. And it is indeed the case in Russia. And when you look at let's say a pull request, like how people review pull requests in Russia versus Europe or Western cultures, United States as well, is there's a lot of passive aggression and negative emotions or just roll feedback, okay, you're doing it wrong, just change it to this. And even for me, it was very hard to adopt. Like, the culture where soft skills are one of the most important skills and when people asked me about the recommendations, like okay, like, if you're a beginner, if you're starting your developer career, like what you do focus on learning this language or wording that, I'm saying, okay, focus on two things, soft skills and learning English because these are two most important skills for modern developer and these two are also something you would sometimes not find in awesome develops-like amazing developers from Russia.
Dan: [9:51] Yeah.
Sergei: [9:52] Like the perfect person's [crosstalk] [9:53] so-.
Dan: [9:53] Smart.
Sergei: [9:54] Yes. So smart. But then when you think about integrating them into the team, and I can say that I'm from Russia, and, you know, I have this opportunity to talk about it openly. But also, even me, I feel awkward talking about it, because it's a cultural thing that started, I don’t know, not even tens of years ago, but maybe, I don’t know, a hundred years ago was this transition to Soviet Union's and our Soviet Union was like, what they were advocating, it was a machine, and then people were gears in this machine. Gears aren't talking gears are moving. And that can affect the whole generation of developers coming from Russia.
Dan: [10:32] I think-I'm really happy that you shared that, you know, we are such a global world, now. You can work from anywhere and hiring all over the place and different cultures. Yeah, I think it's good for our audience listening, Hey, make sure you really understand the culture of the person that you're working with. And you brought up the PR area, which at least in the US, it's such a social kind of review process. And it's always good to know the background, so really appreciate that. I do want to move us on to our next topic, which is AtomicJar. And thank you so much for that insight and sharing a little bit about your background. Can you tell our listeners about AtomicJar? What's up with it? What problem are you trying to solve? How did this come to be?
Sergei: [11:17] Mm-hmm, okay, I had a perfect transition to this topic, actually, because when you asked about the culture difference, the second difference, I wanted to mention that-what I noticed when I was living in Germany is that people in Germany are really dedicated to testing, they really do a lot of testing-software testing, as opposed to other countries. And this is exactly what we are doing here at AtomicJar, we are the testing company for developers basically, or we want to be-we want to be the one because, when-six years-six years ago, my co-founder, Richard, he created Testcontainers, a project that had a very simple idea. It's so simple, that one would think that “Okay, what's the point? Why don't I do the same? And why do I need this library after all?” but the idea is extremely simple. He was struggling when he was at Deloitte, and he's from the UK, but he was living in Japan back then working for Deloitte Japan, and he had an issue, integration testing and how to perform integration testing. But he shared that they-sometimes, they had to bring the CD with stuff like Oracle database to make sure that the environment is consistent across the-across the computers-across the machines, and I can definitely feel the pain because back then, six years ago, Docker was something that was just getting started, it wasn't the de facto solution that everyone is using. It's not, like, doing that today, I mean we cannot say that Docker is what everyone is using. But luckily, most of the developers at least know about Docker. But six years ago, it wasn't the case. Docker was in something like point nine or point eight release, and he figured that, okay, this problem can actually be solved by using Docker. And there are multiple options how you can do it, you can do bash scripting, you can do Fig, which is now known as Docker Compose. But he had a great idea since he’s a developer and he knows how to write tests, how to write code, why don't we talk directly to Docker? Because Docker exposes API, REST API, or HTTP API, rather. And why don't we start-stop containers, configure them and do everything from the test as code. So, it becomes continuous as code was the focus on integration testing. And this solution was so simple, yet powerful that it started getting a lot of traction. And five years ago, I was working at ZeroTurnaround, dev tools company, with an office in Boston by the way, before they got acquired, but like most of the company was actually in Estonia. And this is where like, one of my brightest memories about Estonia are coming from, and I was at ZeroTurnaround and had our own Testcontainers, internally. We had this-libraries that could talk to Docker, and same idea. But unlike Richard's project, ours was inner source project. And when I discovered Testcontainers by looking at one of the issues on GitHub, and there is this feature where you see cross references from other repos, really nice feature one of the best repos to discover other projects actually. I know it's Testcontainers, I said “Okay, I definitely should check it because the main of testing was Docker and I'm looking at something Docker and see Testcontainers.” Realize that the library does basically the same thing as we were doing. And I was so happy because it was open-source libraries, so like, Mr. Managers, we should start contributing. That's what we did. And eventually, Richard invited me as a co-maintainer. And ever since then, we've been working on Testcontainers. It grew so fast and gaining so much traction because it was simple, but so generic, like, it doesn't really matter whether you're working on a banking application, if you're working some fancy startup, or you're developing an application or like backend for a pet grooming mobile app, you will be using Testcontainers because you always need this database to start so that you can run your tests and if-ten years ago, unit testing was kind of the solution for testing when it comes to developers. There is of course, browser testing and team testing that's being done by key and QA teams, and manual testing as well. With Docker, with tooling, with DevOps processes like shifted to the left, or shifted testing to the left to the developers we gave-gave developers access to this tooling, so that they can write the test and for the right moment for Testcontainers, because it is single library to adopt. And then you can test anything that can run in Docker container, which is great, because that's the majority of the technologists currently being available.
Dan: [15:37] That’s really interesting. Is it open-source today? Or is it closed with AtomicJar? What is the business proposition?
Sergei: [15:45] So Testcontainers as a project remains and will always be an open-source project. It's a community. It's not just something that Richard and I and later Kevin, who joined us, created, but rather it’s a community. And we received a lot of contributions also being used by a lot of other projects, such as Spring or Quakus and others, and it helps, I don’t know, at this state I think we can say like hundreds of thousands of developers around the world, and it makes no sense to not keep it open-source, because our product Testcontainers Cloud that we are developing here at AtomicJar focuses on the idea of being complimentary to Testcontainers by removing this complexity of running Docker, because Docker is a great obstruction. But with great power, comes great responsibility. And it is the case with Docker, because there was always this conversation, especially with your security folks, “Okay. Yes, this is super helpful for developers. So, the balance shifted to developers.” Like, it's very helpful to developers, but then security folks are unhappy that there is Docker in their CI CD pipelines or what not, and with Testcontainers Cloud we basically remove this is problem or this complexity of having Docker because Testcontainers Cloud comes serverless platform-management platform for running Testcontainers based tests. And instead of starting databases, the brokers and what's not everything can be started with Testcontainers locally, you'll be starting it in the Manjit environments provided by Testcontainers, which is a great addition to both local development and CI CD pipelines.
Dan: [17:20] So you have your first round of funding right, for your seed round? How did you actually get that seed round the funding? What did that look like for you?
Sergei: [17:29] Okay, so it all started with me going on about-about me quitting VMware without any other destination, a year ago. So, I just announced it and I did like first ever open call in my life, like previously, I was always changing job when I already had my new contract, sign it. But since I was at Pivotal and then, Pivotal got acquired by VMware, just VMware is a much bigger corporations compared to Pivotal. And I was like, “Okay, I really want to find something smaller than just large corporation.” And I did the open call and thought that, okay, I'll find some new job, maybe, I don’t know, Microsoft, Red Hat or something like that. And then I got contacted by one of our users-Testcontainers users who is a business owner and he said that he just migrated all his tabs to Testcontainers, he sees the value and works very well for him. And he asked me whether I considered starting a business for Testcontainers because like, why would I join some other company? Why don't I start my own? And he asked if we had some ideas, and we did have some ideas, just we never had a chance to execute them before, because we lost a lot of traction and Testcontainers became the standard for integration testing when it comes to developers. But it was never commercialized, it was always an open-source project. So, we started talking, I explained some of the ideas, and we were at the stage where he was ready to write off an angel check. But then we realized that “Okay, actually, why don't we go big? Why don't we reach out to VCs? Why don't we do a proper seed round?” And then we jumped from a single angel check to a multimillion round. And it was very interesting experience because we are developers like both Richard and I, we are developers and we don't have this business style of thinking, we had to learn it very fast. But it was so cool to see that our engineering ideas were appreciated by businesspeople as great business ideas for the future. And this is how we ended up doing our oversubscribed round with one of the best, really, investors out there for a seed stage startups we looked at about it.
Dan: [19:34] Yeah, who are you with for your seed stage?
Sergei: [19:36] Our seed round was led by boldstart, which is kind of if you ask me is the best company for seed stage. I would say boldstart, they are amazing. Also, we had 5Capital, we're leading Series B of Docker Inc, just a year ago or so. And yeah, many other amazing folks, which is great because we are here to learn. We're learning as we grow and the best way to learn is to hear from others experience and we have a decent amount of folks to ask about their experiences.
Dan: [20:07] What has it been like for you to go from essentially a kind of a hardcore software developer to now being a CEO and founder, what has that transition been like for you?
Sergei: [20:18] It was fun. [chuckles] I'm not gonna lie, on one hand-and what's especially, not like hard, but you always think about is that, obviously, you want to be a good CEO. And to be a good CEO, you have to understand what it means to be a good CEO. So first, you start thinking, who was your best CEO in your own employment history? And then you start thinking, what made them a great CEO? Then you also realize that, okay, there isn't a single rule, how to be a good CEO, it just-you just learn through the process. And I guess what works well is that you don't think about yourself as a CEO, you’re just part of the team really. And this title, especially in small startups, they almost mean nothing. Like, I mean, I'm-I was the original creator of the prototype, Testcontainers prototype, and I developed kind of half of it, and Richard joined me slightly later, in our process of funding the company or starting the company, there was a bit of delay, this is why the prototype was started by me and Richard is CTO, by the way, but yeah, eventually you start realizing, okay, like, you have to take the responsibility for certain things in the company and-taking ownership and becoming the CEO.
Dan: [21:31] Yeah, absolutely. Is there any pitfalls or challenges that you've run into that you're able to share?
Sergei: [21:38] There was definitely one, if you're starting a dev tools company, your very first assignment as C-as CEO is to figure out how to not be the CTO, because dev tools means that you're working on something technical, like your product becomes almost code. And then it's really hard to draw those lines, really hard to let your CTO be a CTO. And obviously, I sincerely want to let Richard to be the one. So, we had to spend time just drawing the line and understanding, okay, where is the product, and where's engineering. And it's extremely hard when it comes to dev tools, because it's almost unnoticeable, because you can talk about, I know how our product is doing virtualization or isolation of the workloads. And one second later, you're really talking about implementation details, like “Should we use Firecracker or something else?” and then okay, you're no longer talking about the product requirement, you're talking about technical requirements. So, it's extremely hard.
Dan: [22:40] You mentioned what it means to be a CEO. And one of the things you know, that I've learned from co-founding LinearB is you just have to have an awareness of what your role is, your role as a founder or CEO will change when you're really small, versus when you get bigger, and you get, then, twenty employees, forty employees, and that's a different job than when you have a hundred and fifty employees. And, you know, I guess one piece of advice that I've learned is, just keeping that awareness of what your role really is in the stage of the company that you're at. And then being flexible, the learner along the way, it's like, how rapidly can you learn because your job as CEO today may look very different than your job as CEO six months from now. And so that that fluidity has been really important, for me at least.
Sergei: [23:32] I think that's great advice. And I can definitely relate because a few weeks ago, I realized that my last commit was from the very beginning of September. And it's so weird, because I mean, I'm a developer, like I want to write code, I'm enjoying writing code. But I realized that okay, I'm also enjoying running the company now. And I'm not feeling like-okay, I'm not getting to getting the opportunity to write some code. I'm fine with it. But it's a big surprise. I would never think that I would spend a week without writing code. And here I am just months without spending enough time implementing features. But yeah, it’s-it’s fun.
Dan: [24:11] You're building a product for developers, as you mentioned, and you know, us at LinearB, we also have a product for developers, we call it WorkerB. And what I found from that experience is it almost gets personal. If you've become-if you were a developer and now you're building a product for developers, you have all of these experiences that you went through when you're impacting the product. “Aw, this is what it was like for me” and my co-founder Ori, he was also a developer and anything that has to do with our worker bee functionality for developers almost gets personal. Have you felt anything like that? Or what is it like for you to build a product for other developers?
Sergei: [24:54] It is indeed personal and puts a lot of pressure because if you're just starting with some great idea, like I don’t know, a pet grooming app and it becomes extremely popular. And then I don't know, Facebook comes and says, “Hey, I want to buy your application because we see a lot of Facebook users who want to groom their pets.” And okay, yeah, just buy it. It's only question of money. But when it comes to building product for developers by developers, it is indeed personal, like you feel that it is your child, like, it isn't something you would sell to someone. And I'm not even talking about the business aspect of the exit strategy and everything because you still have the thing about the business. But rather, you have a lot of responsibility for this product because you know that if you fail, then you won’t make someone happy. Because that's what we want to do here at AtomicJar, we want to make developers happy and with our project Testcontainers, with our product Testcontainers Cloud, it's all focused on solving someone's problem and making someone a happy developer because there are so many ways how we can make developers a bit happier because we are currently, I don't know, it's always plus, minus, and the more happiness you add to the plus of software development, the better. But yeah, it is indeed personal. I just don't know how to stop thinking about what we do here is something personal, it's our child now, and we are growing our child. And our job here is to let the child grow and eventually lead-lead him to, you know, like, be free, like I don’t know, go to college and everything, it's, I guess, a similar feeling, which I think in a way is unique to dev tools, because dev tools are usually being created for developers, by developers, and then it creates this mutual feeling of what you create is what you would use yourself.
Dan: [26:44] So if I'm a developer, and I'm using AtomicJar, how does my day-to-day development life change? What does it do for me? How does my life change as a developer using it?
Sergei: [26:55] What Testcontainers, specifically changes in your development workflow is that before integration testing, [you] would never have the confidence that what you just wrote, let's say you-you just wrote an ideal SQL query that would solve all your issues, would eliminate a lot of N plus one issues and just you made a big refactoring. And the tests are passing, because you have some, I know Unit has- or maybe you're only using a memory database, like H2, something like that. Then you deploy to production where it is staging. And then you realize, okay, there is a problem, because there is syntax difference in what the Oracle thinks about how queries should be written. And it's a huge challenge, actually. And then you have to change it, maybe you run it on your local instance of Oracle, you can attempt to fix it, but then a week later, you may make a small change. And once again, you have issues in production. So, lacking this confidence, how your application will actually behave with real instance of the database. While with Testcontainers, you actually start a new, fresh instance of the database that you're using, or a broker, something like Kafka, in your tests during the development. So that right after you write this query, for example, or change your application, you can get the confidence that this change will run fine in production, and because-there's nothing to worry about. And you get this feedback so early, that you can experiment you can test and own experience, like game changing experience was Testcontainers. One was when we were migrating Lastik search from I think, 2.5 to 5.0. There were some major change, the queries didn't change-the structure of the queries, but the logic inside Elasticsearch changed a lot. And without Testcontainers, we would spend, I don’t know, months or maybe a couple of months, just testing these by deploying to somewhere realizing it's no longer working, we need to redeploy and everything. But in our case, we fixed our incompatibility issues between different versions of Elasticsearch because we had the support both, locally at our machines. And then even before we submit the pull request, we already knew that this is going to work with our production environment. And this is a major change when it comes to software development, when you start doing integration testing.
Dan: [29:14] That's really cool. One of the things that we're pretty big into at LinearB when we think about the tools we're creating for developers, is how are we going to save developers time? Developers have so much work on their plates? And they have deadlines, and it's this constant grind to get their code out to production. Do you feel like AtomicJar will save developers time?
Sergei: [29:39] Absolutely. Because then this time spent waiting for deployments, for rollbacks, for dealing with production outages, can go into product development, and this is amazing contribution to the performance of the team. I guess that's one of the biggest reasons why Testcontainers is one of the technologies that are really loved by developer productivity teams, because that's exactly that. They just cut stages, like big stages from the delivery pipeline, because you no longer need to wait for staging deployment. And you don't even need to figure out. Okay, how do we create ephemeral staging environments so that developers can test it, so you no longer need to because they have a local environments where they can test everything they want, without asking someone from, let's say, Sys Admins to help them deploying this thing, where not even understanding their production environments.
Dan: [30:31] Obviously, you have this really interesting tool for developers that helps them test their code and then environment that is either similar or exactly like production, I can flush out my issues earlier on. Where do you see the industry going in testing? Are you noticing any patterns? Or what do you think is coming next?
Sergei: [30:53] I think in the testing space, CI goes local. Because if previously CI was something hostile, like you submit jobs to CI, nowadays, CI becomes part of your local workflow. And there are various options like TeamCity was capable of submitting jobs to CI from the ID ten years ago or so. I remember this feature, this remote build and it was amazing, you could just take your local changes submit it to your build system that's already configured by your build system team. And you would run your view on the remote system. And as sometimes happens with great ideas that they should happen is the right time at the right moment. I guess ten years ago, it wasn't as appreciated as it would be now because the more people like more and more people realize that, “Okay, we should actually use clouds, not only for our production deployments, but for our development workflows for what we do as developers.” There are cloud IDs, which is another great idea, where you could just run everything on cloud, and then you don't need a lot of resources on your laptop, the only thing you need is a decent internet connection. And this is what we should focus the most right now like how to make sure that every developer has internet connection. And it's great to see that the industry is very well aligned with that as well, like this 5g, Starlink and everything. It's great to see is that, okay, there is a focus on making sure that internet becomes a given and not a feature of your environment. But yeah, I think the biggest trend is shifting CI to the local environment. And I see a lot of opportunities in this space, because then it will also come with some ideas, something that Redis, for example, are doing how we could avoid rewriting the same task if you already run it locally. And they have Redis caching, where it could just cache the result of the test run. But I believe there is there is much more.
Dan: [32:45] Yeah, really interesting points there. And it sounds to me like some of the concepts that you're doing with AtomicJar is to bring that production type environment shifting that left, again I'm testing my code, and then in a container that is more so replicating production, there is another school of thought of, hey, you know, we need to get our code out to production as fast as possible, small chunks. And we're almost like testing in production, not in a negative way. But in a controlled way. How do you think about balancing like speed getting out to prod with testing, maybe versus doing more testing earlier on in the software development process?
Sergei: [33:29] Actually, it's fun to imagine testing in production, because that's something that I've been thinking about. And I was actually struggling to find good examples of who does that other than Facebook, if I remember correctly, but that's an interesting concept. In the future, we'll see some major changes in that space. Okay, how do we control-ow do we reduce the impact of what we run in production? Can we run experiments in production? Can we ship to production with more confidence? But I also don't feel that we are there yet, while making sure that what you devote would work in production is a really great step, but it is an interesting space. It is an idea that sounds like a theorem-theorems that would be proven one day, but currently you only have it as a theory. And for some took hundreds of years to prove some theories in physics or mathematics. And I hope that for our industry, for the IT industry, it will be matter of at least tens of years and not hundreds, but that's how we move. If you think about it ten years ago, software development was nothing like it is right now. With cloud IDs, with clouds, with serverless, with edge computing, with all these new protocols. Yeah, it's no longer boring. It's no longer a single choice of database. It's at least three options per use case. If you need Kafka. You also have Pulsar, ProVega, Redpanda and others. If you need to database then you have Postgres, Oracle, Massive-scale and others, and this is crazy!
Dan: [35:04] Sergei, thanks so much for taking the time to sit down and talk with us about your background and founding AtomicJar and how you think about testing and kind of the future of work. It's been a really good conversation.
Sergei: [35:18] Thanks. I really enjoyed the conversation, some really nice topics, some unique topics we discussed here, speaking of my background, because usually I have a slightly different background, and some of you who know me may know that already. But currently, I'm at Reinvent, so apologize for the quality of my video, but at least I can give you some nice view. [In video leans away from camera to show glass windows overlooking a city]
Dan: [35:38] Absolutely, I hope you're having a great time at Reinvent. I always like to give, you know, our guests an opportunity to close out the podcast with something they're interested in, some type of pitch. And I know you're working hard on AtomicJar. If I'm a developer, and I want to either get involved with AtomicJar or use AtomicJar, where can I go?
Sergei: [35:57] So we just announced our product. And that's a big relief, because it was really hard to keep it in secret. And now everyone can sign up for private beta. And it's really for everyone's those who never tried Testcontainers, but maybe they couldn't run it because of Docker or something and with Testcontainers clouds they finally can, or maybe they are already existing users of Testcontainers and just want to improve their experience. And yeah, they can go to our website, atomicjar.com and see the announcement and see what value it brings to some of our private beta users, that also includes our cooperation with Red Hat. We are currently delegating Testcontainers for local development of Quarkus applications, which is something fun, you'd never think that a testing library would also be very helpful for local development. But it is what it is. And it's great to see it's being used for that. So, if you're interested for what we just discussed, and to see how it will evolve, you can sign up and eventually we'll also be transitioning to public beta soon, looking forward to letting more users into our system and hearing their feedback because we want to make developers happy, and we are building products for that.
Dan: [37:06] So everyone, please check out atomicjar.com. And a quick reminder for our listeners. If you haven't already rated and reviewed the show on your podcasting app of choice, particularly Apple podcasts, please do so. Reviews are crucial for our show to get discovered. Also, be sure to check out the Dev Interrupted Discord community. That's where we keep this type of conversation going all week long. I also want to say thank you to the more than two thousand of you who are now subscribed to our weekly Interruption newsletter. We bring you articles from the community, inside information on weekly pods, and the first look at Interact 2.0 on April 7th, 2022. [Music plays] We have all the links of the information of what we talked about below. See you all next week. And uh, Sergei, thank you again for coming on the pod. It's been a pleasure.
Sergei: [37:54] Thank you, Dan. Thanks for having me.
[Music fades out]