On-demand environments for Automation Testing with Tommy McClung

Welcome to the Test Guild Automation Podcast where we all get together to learn more about automation and software testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Automation Podcast. Today we'll be talking with Tommy all about environments as a service, as well as some features of how this can help you as a tester, like using it to automate preview environments and a whole bunch of other cool features. With whether you're a tester or a developer, I think this is going to be some valuable information for you to help really speed up your software development. If you don't know, Tommy is the co founder and CEO of Release. His team has been building scalable infrastructure for over 20 years. An entrepreneur, so I think he's co founded other companies like Karwal, I bet that was acquired by TrueCar. And he also is the founder of I Am Safer and so he has a lot of experience in this space. Really excited to dive into why he chose this particular new venture to really get into some cool technology. I think you're really going to benefit from. You don't want to miss this episode. Check it out.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Source Labs, the cloud based test platform that helps ensure you can develop with confidence at every step from code to deployment for Every framework, browser, OS, mobile device and API. Get a free trial. Visit testguild.comSourceLabs and click on the exclusive sponsor section to try it for free today. Check it out.

Hey Tommy, welcome to the Guild.

Hey, nice to meet you Joe. Thank you for having me on.

Great to have you. Really excited to talk to you about environments today and automation of environments, which I think is clearly lacking from my experience in software development. Before we get into it, is there anything I missed in your bio that you want the Guild to know more about?

No, I'm just, I'm a software developer at heart. Been building companies for the last 20 years and, and in every company that I've worked at, environments are always a scarce resource and with this company kind of came back to what was in my DNA and that's helping developers and test teams be more productive. And you know, I think it's kind of like as a software, once a software engineer, always a software engineer and it's, it's fun to be back working in this space.

Nice. So, you know, obviously before you start up a venture like this, you probably do some sort of research. Why, why did you think this was the next thing to get into that you think was a void that you can help folks with.

Well, prior to this, I was the chief technology officer at TrueCar and environments were an incredibly difficult, you know, missing resource within the organization. So I felt the need directly. We had a large QA team, a lot of test automation that was running and you know, basically only one or two environments where those tests could run. And the developers always ended up bottlenecking, waiting for that resource to get their work done. So, you know, I felt it directly at the kind of management level, you know, seeing how it can impact productivity, having a, you know, a less than ideal number of environments for your large. We had about 2 to 300 engineers in that team over time. And so when you only have a few environments for those teams to get their work done, it's a, it's a really, really big bottleneck. And even in prior companies in startups, you know, when you think about that from the ground up, when you start building a CICD platform, you think about test automation from the beginning. I've seen a. You have ample environments and good automation and it was interesting to be the CTO of a public company where, where that didn't exist and saw what could happen if you don't have it. So I think the need, seeing it firsthand was kind of the first reason. The second was when we went to try to solve it there nothing existed in the market. There's tools that will help you with cicd, there's tools that will help you kind of build your own environment, you know, you know you can, you can declaratively create them in terraform or other tools, but there's a lot of like tooling requ in order to make a team of that size really effective. So we looked in the market and I say we as a couple of my co founders at the time and there really wasn't an off the shelf solution to it. So we were forced to build an environment management system in house there. So, you know, and being the buyer of a product like that, I would have bought it. Like if there was something off the shelf to go buy, that would have saved our team, you know, a year or two's worth of build time to get something off the ground. We just saw a big gap in the market and as an entrepreneur and being a software developer, developer at heart, I just felt like this is the place to go work.

Absolutely. And it's kind of a tangent. I know a lot of people always like, oh, we only use open source solutions or their company only says they use open source solutions. But if you can tell them, hey, there's a solution out here that we could purchase that's going to accelerate what we need to do, do it correctly, and we don't have to put in all this effort to build it ourselves. It's a big win. So I think that's a critical point that you brought up for sure.

Yeah.

So I think another point you brought up which was interesting is, you know, as people are developing software, a lot of times when they're developing automation scripts, they say on every check in, the developer does, it's slowing down the feedback they're getting because the automation scripts need to run. And so if someone's constantly committing to the main branch, it's just really hushing them mellow because they're not getting the feedback they need quick enough. So are you saying this is a pain point, that a solution like this could help where because you get able to scale up multiple environments, you're able to get the information faster and quicker?

Yeah. So, you know, the premise here is that for every branch, every pull request, an environment which is a full stack, so everything front end, back end, database, cloud, native resources can be created just on the branch that you're working on. So let's say you have 100 developers, you could have a hundred environments all on separate branches. So there's no contention amongst the developers. Everybody has their own isolated copy where they could test, debug, run, automation preview. You'd mentioned that earlier in your intro that previewing those features is also, especially in a larger org, where you've got product QA design, everybody cares a lot about, not just does it work, but what does it look like, does it meet the customer need? And if you only have a few environments that you can use to do that again now those environments are locked up for that purpose. So by parallelizing that, eliminating that bottleneck, individual developers are never really encumbered. So the speed at which you can do that is at the speed of the parallelization that you can create. With having, you know, basically an infinite number of environments now, you know, I think the, the most important part of that is making sure that it's integrated into the tooling. So as you're doing your work within your source control system, you want to make this super easy for the developer, right? The developer. This should just appear, they shouldn't have to go and like, you know, know the infrastructure, know the scripting ecosystem that makes it happen. So I think a really key part of making something like this work is it integrates with GitHub BitBucket or GitLab. So when you do a PR, that environment automatically gets created and when you merge, the environment automatically goes away because you've merged it into a, you know, a higher order environment, staging or multiple staging environments, whatever that might look like. So to the developer, you want that to be seamless. And as they push those changes, that environment is mirroring whatever the changes are locally. So you always have this ready and waiting test preview staging environment on that branch waiting for them.

Great. And you brought up something that really hit home with me. I used to work for a healthcare company and so we had these really complicated environments. So we only had a few of them and a lot of times it'd be one environment we test on. In the department's day, we're giving a demo to this, this, who we're building this feature for. Do not do any testing on it. And it always turned out some would break something while someone was doing a demo. So it sounds like this is another user case for a service like this, Is that correct?

Oh, for sure, yeah. You know, demos, I mean, it's funny, as an entrepreneur and founder, I end up having to do a lot of demos all the time. Customers, you know, investors, whoever it might be, and having the ability to take whatever your production environment is, snapshot it, and do a demo completely off to the side that nobody can touch is the valuable thing that I've derived out of release myself personally, because I don't ever have to worry about the developers going and breaking staging or production while I'm on whatever call or video or whatever I'm doing. So it's actually a use case that customers sometimes buy us for too, which is, hey, I've got a large sales organization. Sales organization where, you know, every salesperson, every se, whoever it might be in their org, they can assign out their own environments to them so that they're not stomping on each other's toes. So demo capabilities, and that's, you know, any kind of demo, it could be the way that I like to use them a lot is, you know, we'll have customers that say, hey, I want this feature. And in the abstract, that feature is described by the customer, like, hey, I wanted to do A, B and C. Well, a lot of times, until that feature makes it all the way out to prod, the customer never really sees it, right? It's like, okay, we're ideating on that. Maybe some wireframes. If a product manager is really good, they'll pass it over, say, hey, is this kind of what you were talking about. But we actually, a lot of times we'll take that change and give them one of our environments that we're doing that change on. Preview it with the customer, customer in the product development life cycle and iterate with them. Live that feature live. So that by the time it makes its way to prod, we already know that it's meeting the needs. And it's not like, wait till it gets there. Oh, that's not right. Now go back all the way through the process again. It's like a real time collaborative way to basically work directly with your customers on things that they might need along the way as well.

Great. And I just thought of another thing that maybe helped with. Curious to know when I worked for healthcare, at the end of a release, we'd have to freeze an environment. And so if someone came into audit us, they'd say, don't. Not only do I want to see a test, but I see the environment you actually tested in without any modifications. So if anyone upgraded the browser or anything, that was a big deal. And so to keep an environment in that pristine condition was an issue. So how are you able to do a snapshot like that and say, okay, here's the exact environment we tested on and just have it come all up on. Push a button?

Yeah, I mean, every environment. I think a key part of an environment management, environments as a service system is the ability to snapshot in time. What did the environment look like along with what did the code look like. So, and this actually rears itself in a case like you talked about, but other times it's just debugging, Right. Like you have an issue that rears its head. You know, it's some version of the state of the environment when you go to test it, the environment isn't what it was when that bug existed. And you always hear, well, I can't reproduce this, right? Well, sometimes you can't reproduce it because the infrastructure, the configuration, whatever had changed. And so if you can go back to a moment in time where the environment looked like it did the time that bug existed, or in your case, making sure that for audits it's exactly what it looked like, you have this ability to ensure that you're looking at exactly what was going on at the time that whatever issue happened, or, you know, the auditor can come in and look at it the way that it was when they needed to see it. So the snapshotting of moments in time is a really important part of this. So that developers, you know, testing quality, all of that stuff comes into play there. Infrastructure is kind of the. It's tough, so it moves in time and it's hard to move it forward and back. And so with an environment management system, you can do that.

Nice. I also think with infrastructure, a lot of times people don't realize just how critical it is because they made it go. It's just a developer resource. But like you said, people are doing demos, you're making sales based on these environments. You're helping to not get an audit and have to pay money because you didn't follow regulations. So it's very critical, for sure. So what do you think is the reason why? I think a lot of times people hear this, they go, oh, that's what Kubernetes and Docker is for. So what's your answer to that? Like, is this what this is? This is just a Kubernetes type of solution. Tell me a little bit more about what release is and how it may be different from Kubernetes. I guess a better question. Sure.

I mean, Kubernetes is definitely an enabler to pull this off. Underneath the covers. We use Kubernetes to orchestrate Docker and containers. And there's a lot of really cool capabilities that Kubernetes brings to the table that allow you to pull this off at scale like we're doing. But the reality of an environment is container runtime engines like Kubernetes are one part of the equation. You still have data, you still have cloud native services. You know, you might have Lambda Serverless Kafka, you might have elasticsearch, you might have all sorts of other componentry in and around your environment that if you're going to reproduce the environment, you got to reproduce all of it. You can't just say, oh, I'm going to reproduce the containers and that's enough. Much like what we just spoke about. Right. You could reproduce the Kubernetes subsystem, but what if your database moved forward in time? Or what. What if your lambdas were different than the way they were when the actual test was running or when you were running your code? So the, the environment itself is a combination of the data config settings, all of the cloud ecosystem around it. Kubernetes is an enabler of this because it helps with the custom code and the runtime of custom code. And there's standard off the shelf things that you can bring in, like helm charts and other things that help you build your application the way you need it. But it's, I would say, it's necessary to pull off what we're doing, but not sufficient. You have to have orchestration of all of the rest of it. And we're pretty fortunate that the world has evolved to a place where there's standards for things like Terraform, so that you can spin up cloud native services or aws, CDK or whatever, pulumi, whatever it is that you're using to do that. So release is a combination of integrating source control, Kubernetes, the ability to orchestrate data so that you have the right data in your environment, and then also the native services that sit around it while mapping it to whatever your application looks like. You might have a monolith, you might have microservices. All of this complexity is really what makes up an environment. So, yeah, Kubernetes is definitely an enabler. But if, if you don't think about all those other things, you're basically just recreating the containers, not creating the whole environment.

So, interesting thing about the environments. I know a lot of people are going more cloud native, or they consume a lot of services that are third party. How does this help that with that? If you're spinning up an environment, are you mocking it? Do you have like a service that you're kind of mocking so that it emulates it, or are you actually kind of. How does that work?

We have customers that do it all sorts of ways. So some customers have mock services that they're using. Other customers, like for a shared service, say it's like a stripe endpoint. If you're doing like, you know, integration, integration with billing, they will, you know, have multiple environments pointing at the same shared external resource, even though they have multiple copies of their environment. And then other companies will actually create snapshots of those shared services if that shared service supports it. So, like, what's a good example of that? We were just working on the other day, we were working with a company that was Shopify Instances, right? Like they need multiple Shopify instances because they had to. They couldn't have them shared, so they needed to create them. We also did an integration with LaunchDarkly, which LaunchDarkly has the concept of environments as well. It's a shared service. Like all the environments wanted to point at one launchdarkly. But we created this integration that allowed every environment to get a copy of a LaunchDarkly environment. So all the feature flags got copied in. So it's a bit of a conversation or a decision that every customer needs to make is like, what do you want to do with these shared resources, sometimes spinning up separate copies of them isn't financially the right decision either. Right. Like for instance, if you were going to spin up a Salesforce Sandbox instance, that might cost you. I'm using my memory from my days back at TrueCar. I think it cost us like $75,000 a year to have another Salesforce Sandbox instance. So in that case, it wouldn't make sense obviously to create a new snapshot of that every time. So that might need to be a shared resource. So it takes some thinking about all of these things along the way. And that's part of what we help with when we bring a customer on is, you know, we, we do a quick call, we talk about all their services, and then we say, okay, here's the way we think we can do it in the most cost effective way to try to get them those services in a way that works for their testing needs.

Nice. I see such a need for this. I'm just thinking back when I worked for a healthcare company. One issue though is this might sound stupid. How do people know what their environment should be? Because a lot of times we build environments and not even realize, oh, we consume this cloud service, or we use this because there's some expert way down the hall that no one talks to that always goes rogue and installs it without anyone knowing. Does this solution help them? Like, can you sniff an existing environment or anything like that?

Yeah, like the first part of the bring up of an environment is we analyze their existing repositories that make up their code bases. And within that you're going to find all sorts of clues. Docker files, package jsons, helm charts. All of these dependencies are kind of lingering throughout the environment. And so we look at that and say, okay, based on what we found, here is the template that we think defines your environment. Now, sometimes that's not completely right. Obviously, if some guy down the hall is doing something that we don't know about, the way that generally our customers will find that out is when you bring up a release environment for the first time, you're bringing up a snapshot outside of your existing environment ecosystem and it's either gonna work or it's not. And usually what we see is that environment comes up and it's kind of in like an 80% working state. And actually the process of trying to bring up your environments in release helps you figure out what dependencies are you actually. And a lot of times, like you said, we'll run up against customers who are like, I Didn't even know we were using this. And it's within that process of recreating that environment for the first time that they discover those. And then what they do is they add those into the template and now they actually have a definition of their environment that's a gold standard. And you know, it's very, very rare for us to come up against a company who actually has a full infrastructure as code defined, you know, ecosystem. I don't think in the entire time we've been working on this for three years we've ever seen a. That's like everything is codified within a single configuration. There's lots of configurations, all of them have to work together and many times they're missing things. And that process of taking that and putting it into an environment, management environments as a service system actually is the first time that they'll ever really get to a place where they've codified and have it all in code, like everybody speaks that you should be doing now.

Yeah, I mean, I'm just thinking once again, for personal experience, it's almost like automated documentation for your environment. So two examples come to my mind is we'd have to list all dependencies of our application, but it was all like just an email. Hey, just send us what dependency using. We know how to list them out. But yeah, come on, I don't know how much we could rely on it. This is much more reliable, much more auditable. And also we had an application and we use third party apps within the company and we'd have like 60, 100 page documents on how to install like this third party app in order to test our. Oh yeah, our integration between the two. This sounds like you could just spin up an instance of that particular third party.

Yeah, at the end goal, the end goal of this is you should be able to click a button and an entire environment is created. And so in the process of doing that, like I said, you'll sniff out like, okay, here are the things that we don't have codified, here are the things that are dependencies. And in order to make a system where you can click a button and your entire environment comes up, you need to declaratively define that somewhere. And that's what we call the application template, which is a core part of what we, we offer. Now you have a fully defined, you know, environment definition. You click a button, you can create a second, a third, a fourth, a fifth, however many you want from that point forward.

So I'm just thinking of all the scenarios that this could help with another one that just came to my mind. Not sure if this is what it helps with. Cyber liability engineering has been big. And if you note probably last year, which is just like a few weeks ago, AWS went down like two, three times. So Hulu, Netflix, all these, Twitch, all went down. Can you use this almost to do, like, experiments? Like, what happens when AWS goes down? How does it fail over? Can you, can you use this type of a solution to help you kind of do these type of experiments as well?

Yeah, for sure. I mean, you can have separate environments that you spin up. They're going to have the same dependencies and you can mock out or experiment with within this environment. Like, what happens if this dependent service goes down? What happens if that dependent service goes down? And the nice part is you're doing it in a throwaway environment. So if you completely screw everything up and hose everything, you're not impacting anybody else.

Right.

You're just, just messing it up yourself and realizing, okay, we're highly dependent on AWS or we're highly dependent on GitHub or whatever it might be. So now I can work on that problem without impacting anybody else. And usually a lot of that can only be really done within a shared staging environment because it's the only place where all of those connections and the dependencies are created, because it's really hard to define all of those. So within release, if you define those dependencies now, you can go play around with shutting those off, turning them back on, see what happens to your application, and you don't impact anybody else. So it's a really, really good to kind of do chaos engineering, if you want to call it that, where you break things, see what happens, keep breaking it until you get to a place where it's more reliable. Then you bring those changes into your main environments and you're much more resilient after that.

Nice. So I always say this on the podcast. I love speaking with vendor solutions because you work with a lot of different customers. I think a lot of times developers are stuck in their own little world within their application, don't realize all these other things. So curious to know, like, can you give any examples of maybe someone that didn't have your particular solution in place, what it was like and then what it was like after?

Yeah.

Do you have any type of case studies or anything like that?

Sure. You know, a lot of the companies are, you know, this single staging environment problem, especially as the engineering headcount grows, it just slows product velocity. And so you'll have customers. One of my favorite, I won't say exactly who it is, you know, to spare them, said to us like, hey, the way that we test our code and the other thing about this job is we find nobody's really truly thrilled with the ecosystem that they've created. There's always like some sort of like, hey, I gotta explain this thing that we do. And it's kind of embarrassing, right? And so this particular company was like, you won't believe this, but we're literally testing all of our environments on MacBooks. We have six environments set up on MacBooks in our office. And the only way that we can really test all of this is to push the code to master main. And then QA person, developer walks over to one of these MacBooks, they pull it down and they do their testing there because it's too difficult to get everything running in the cloud. So that's the way we do it. So they were literally buying MacBooks on a monthly basis to keep up with this. And obviously not the most ideal scenario in the world. Data was a big problem there where getting snapshots of the data to do testing. There was an engineer who had to show up at like 5am in the morning and refresh all of the environments, the lap, the laptops. I'm using a pretty extreme example here, but it's a really funny one. That person has to come in every morning at 5:00am, update 5, 6, 7, 8 MacBooks so that the developers that day had the most fresh data. So in their world, it was incredibly manual and incredibly expensive because they had people buying laptops, buying, you know, setting them up, putting them in their ecosystem. And when they started using release, obviously automation of all of that, you know, eliminated the need for any of these manual processes that they had completely and freed them up essentially across the board to do faster qa, faster deployments. The velocity improvement is normally the biggest thing that you see when you introduce an environment as a service system. You know, another great example, you know, at TrueCar, when we were there, we were were deploying like once every eight days before we built our own version in house. And by the time we were done with building out our own internal version of that, we were deploying hundreds of times a day. So generally the ability to have infinite compute in AWS was designed to help everybody go fast. But you have to have the tools, something like release or something you build in house in order to harness it.

Absolutely. I know you mentioned data a few times. I know for test automation testers that's critical Using a solution like this, I assume you could have like a golden copy of the data. So every time you spin up the environment, it's in a known state, you run your test, you muck around, you close it down, you don't save those changes. So you always have a clean copy which is going to help you debug and run tests quicker, better, faster as well, I would assume.

Yep. That's all a part of, you know, whether it's us or any other solution that you might put together those golden copies, scrub copies free of pii depending on if you're in a privacy, you know, laden environment where you can't let developers see production data, we're able to take a snapshot of any data set and bring it in. We call it instant data set. So that when the environment comes comes up, it instantly attaches to a library. You can have a library of data sets and so you might have a performance data set, you might have a prod replica copy. That one happens a lot. Like if you're doing a massive database migration, you might actually want a prod snapshot in your developer environment because you're making major changes to the database that you can approximate with a seed data set. Right. You have to have a real copy. So we're able to take a snapshot of any data set and bring it into these environments through a thing we call instant data sets. That allows those data sets to come up instantly. The environment comes up, attaches to a ready and waiting data set within the library. And now you can do any testing that you want to do within those environments. It's actually, you know, if you look at the equation of getting a good environment there, you have your code, you have your infrastructure. Data is a really, really critical part of that equation. So it's, it's something that we spend a lot of time focusing on making sure that data is readily available that.

Just there if you're a tester, I mean having an environment like this is a game changer for sure. Also you mentioned something about performance. It's just something flashed in my head. A lot of times we're trying to shift activities sooner in the software development lifecycle, performance being one of them. But to have it on a check in is usually impossible because it takes so long to do or you're gonna crash some other service. Once again, I assume this because this environment's kind of, it's on its own little world. You can do that and not slow down the check in because you have it spun up and running as quickly as possible.

Yep. And within that template, the other thing that's really co cool is you can scale out the services so you might have your developer environments. I'll use a simple example here where you have one replica of your container just to make it so I can test everything. Well, when you go into testing for performance, you're going to want to scale that out. You're going to want to see how far can I push this before I start to see bottlenecks in my ecosystem. So within that template, you can easily go in and say, oh, I want five replicas, I want 10. I want it to auto scale scale so that you can start running Siege or whatever tools you use against that environment that's isolated. Scale it until it breaks. And so you can kind of see where your limiters are. And you don't touch staging, you don't touch your QA environments. You can do this as a developer, which that's generally really hard because the definition of an environment, if it's left in the hands of the DevOps team or whatever, in order to get that kind of test set up, there's lead time in order to get that kind of isolated for me or a separate version of that that I can go run against, or I got to check out staging so nobody else touch while I'm doing it. You know, this kind of pushes that left where as a developer, I'm thinking about building my code. Where are the bottlenecks going to be? You can easily add those kind of statements into the environment template and test it all you want without impacting anything.

Great. So I guess the only downside I've heard, I mean, I don't know how you do modern software development without a solution like this, but one thing I heard is a lot of times the costs associated with something like this, because, yeah, you're running tests quicker and fast, but teams start to do more and more tests and that the time you're using AWS in the background starts coming more and more so that in the end it's still millions of dollars a month or whatever.

So AWS always wins.

Yeah, exactly. Any thoughts around that? How does this give you cost savings? I mean, obviously it gives you cost savings because things run quicker, but any downside of people overusing it or take.

Yeah, one of the ideas of what we call ephemeral environments is they disappear. So if I do a pull request, I spin up an environment like a lot of. We get this question a lot. Well, what if my developer just creates a PR and does touch it right. It's just going to sit there. There's a time to live on the environment. So if they're not being used, they're automatically going to shut themselves down after a period of time. There's also cost savings, things that you can do when you set this ecosystem up by helping the customer with, hey, should I buy an RI for this? Should I use spot instances? You know, if you're building this yourself, all of those things are concerns that you're going to have to think through. And when you take an Environments as a service system out of the box, like we're contemplating all of those things all the time because on one hand we're giving you this ability to create infinite environments parallelize your software development. But on the other hand, if you have infinite environments, AWS gets really happy because the bill goes up. So it's a really, really core part of what an environments as a service platform does is help you understand like, oh, okay, if I'm going to have these environments out there, how long should they live?

How do you.

What is the policy essentially around how many of those environments? You can cap it, put a limit on it, so you can limit your bill. You can have them automatically destroyed after a period of time, after no usage. That whole idea of like cost savings there is really important. It's a very powerful tool. But you're right, if you don't carefully watch the spend, you could come back and be like, wow, that was way more expensive than I thought. So a lot of the things that we built into the product help mitigate any of those kind of out of control ideas. And we help customers figure out what the budget for this needs to look like. On the compute side, you're trading off time and money always in this world. And if you want to move fast, it usually costs you a little bit more money and it will to have infinite amounts of its environments, you just want it to be the minimum amount of money that it possibly would cost you. And that's what a good Environments as a service platform like Release helps you do.

Very nice. So I have a weekly news show and a lot of times I have a Follow the money segment where I looked where companies are investing money. I think you actually got around a funding 20 million recently or something like that.

So yeah, we did, yeah.

Just curious little note more I guess. So you must have something investors are believing in. You're pitching something. What are you telling folks about Release? Sounds like a cool place to work. Are you hiring? Just a little bit more around what you're all doing over there.

I think it comes from, obviously I've felt and dealt with the experience myself. So living the pain point is always incredibly helpful when you, when you build something and you go raise money. But I think the thing that really got investors excited is when they go talk to engineering leaders about this problem. Almost universally, every engineering leader will be, yeah, environments are difficult. Like, they're really, really hard. We spend a lot of time and money working on this, right? We're investing headcount, we're investing in software, investing in tooling, and we still don't have an ecosystem that allows us to move as fast as we want. So in the process of, you know, going out and talking to investors, they do their own work. And I think that was a key thing that came back and our proof in the market, you know, we're growing really quick. We need, you know, good employees to work here. So that led to why we needed to raise the money to keep up with the demand. And I think all of those things being true were the reason why, you know, investors got excited about it. There's also the use cases of a type of product like this. You know, we talked about developer environments, ephemeral environment staging. We have customers using us for production now where they've realized that having a common ecosystem to do ephemeral development, staging, and then also deploy and manage your production environments is really useful and interesting. And then the other use case that we're seeing that's really amazing is once you can, once you can define your application. So here's my containers, my networking, my data, my cloud native services, and I can recreate that. B2B SaaS companies are consistently delta with how do I offer a product to my customers that has a lot of security and privacy? And generally what ends up happening is the customer says, I need your software to run in my cloud account. So I'm a B2B SaaS company and I'm selling to someone and they're like, hey, I love your product, but all the data you need to process is in my AWS account. I need your software to run on premise or on cloud, whatever that might be. Now that we've been able to codify the environment, we can put that application of one of our customers into their customer's account. We call those private deployments or private applications. So that environment now is movable. I can move it. It's basically a virtualized version of their application where it can run an AWS, GCP, Azure, AWS, GovCloud, or I want to deliver a single tenant version of that environment to my customer. I just put it into their AWS account and I can manage it just like it's an environment that I'm managing for myself. So I think the other thing that's really interesting about environments as a service is the use cases. Like there's just environments are everything. Like your application doesn't run unless you have an environment. So if you can make that reproducible, it's kind of an endless set of opportunities. Now we have to be really focused as a company to go after that. But I think that's, you know, another reason why this is a really, really interesting product and space that we're in.

Okay, Tommy, before we go, is there one piece of actionable advice you can give to someone to help them with their environment, automation, infrastructure structure efforts, and what's the best way to find contact you or learn more about release?

Yeah, I think the most actionable thing to do is really contemplate whether your software development life cycle is efficient. Because I think a lot of times people kind of sit on their laurels and say it's good enough because it's hard. Right? Like trying to go fix this yourself is a very difficult problem. We tend to find that a lot when we go talk to companies. It's like, hey, you know, this is how we do it. It seems to work. But they haven't really thought deeply about, well, what if it looked like this, what if, what if it was environments were ubiquitous? How would that change our ability to ultimately get products to our customers faster, which ultimately lets me grow faster. And I think people just kind of live with these non effective ecosystems because getting out of it is really hard. And I think that was something. You know, it took me a good two years plus to solve this problem at my prior company. And it took a lot of fortitude to go after it. Had a product existed in the market that could have shrunk that two year time span to a better world down to a month or six weeks, I would have bought it instantly, but it didn't really work. So I think it really is like, you know, a question of engineering leaders to look at their ecosystem and not just sit there and say it's good enough because it is the way that it is. You got to envision this better state. And once you've envisioned that better state, you know, you got two choices, build versus buy. And it's a waste of money to build it in house. It just really is. So if you want to find out more about how we can help you guys with that. Go to releasehub.com you can email me directly@tommyeleasehub.com I like to take emails and answer questions directly. All of those things are great ways to learn more about what we're doing. Yeah, so that's the best way to get a hold of us.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode. Head on over to testguild.com a383 and while you're there, make sure to click on the Try for Free Today link under the Exclusive Sponsor section to learn all about Sauce Lab's awesome products and services. And if the show has helped you in any way, why not rate it and review it in itunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe. My mission is to help you succeed with creating end to end full stack Automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Automation Podcast. Head on over to Test Guild for full show notes, amazing blog articles and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.