Tommy McClung, cofounder and CEO of ReleaseHub, sits down with the home team to talk about environments-as-a-service, what it’s like to work with the same cofounders for more than 20 years, and the role of karma in professional networking.
ReleaseHub provides on-demand environments for development, staging, and production. Every developer knows that environments can be a bottleneck, so ReleaseHub’s mission is to empower developers to share their ideas with the world more quickly and easily, sidestepping what Tommy calls “the big bottlenecks in development.”
As CTO of TrueCar, Tommy was leading an effort to rebuild that company’s tech stack, but he needed an environment management platform, and nothing on the market fit his needs. The homegrown environment management system he developed with his cofounders would become ReleaseHub.
Tommy joined Y Combinator in 2009.
Connect with Tommy on LinkedIn.
Today we’re shouting out the winner of an Inquisitive Badge: L-Samuels asked a well-received question on 30 separate days and maintained a positive question record.
[intro music plays]
Ben Popper Do you know everything going on in your complex cloud environment? Well, Splunk Observability Cloud works in any deployment to help you find problems faster, make your customers happier, and lower MTTR. Get a free trial at splk.it/sopodcast. Head on over, let them know we sent you.
BP Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I am Ben Popper, Director of Content here at Stack Overflow, joined as I often am by my wonderful crew of co-hosts, Cassidy Williams and Ceora Ford. Hi, y'all.
Ceora Ford Hi!
Cassidy Williams Hello!
BP So today we are going to be chatting a little bit about environments as a service. In my time here at Stack Overflow there has been a lot of learning about microservices and containers and staging environments. Is this something you two feel familiar with, both as a concept and maybe as a pain point? I see you breaking a small smile there, Cassidy.
CW Very familiar. Love hearing about things that make things better. I'll leave it at that.
BP Okay. Ceora, you're always up for solving a few problems for developers out there, right?
CF Yeah. I think by now listeners will know that my whole thing is anything that makes a developer's job easier is okay with me.
BP Okay, great. All right, so then without further ado, we'd like to welcome Tommy McClung who's the CEO and co-founder at ReleaseHub to the Stack Overflow Podcast. Hi, Tommy.
Tommy McClung Hi, everybody. Nice to meet you.
BP So the first thing I always do is just ask folks to date themselves to the degree that they're comfortable. How'd you get into the world of software development and technology, and walk us through a little bit of what brought you to the position you're in now.
TM Well, this is definitely going to date me. I started my career as a firmware engineer building blade servers back in the early 2000’s. This is before the cloud, before VMs, and the only real way that you could get a lot of horsepower in compute was to rack as many servers into a rack as you possibly could. So RLX built a 3U server that you could put 24 blades in and I wrote a lot of the systems management software for that company. Ultimately that company was bought by Hewlett Packard, but that systems management idea has stuck with me from my whole career because it was my first foray into making developers' lives easier. And back then, to get a machine to do what you wanted was really difficult. So that was how I got started and I actually ended up being a sales engineer for them after I was a firmware engineer, which is a really cool job where you travel around the country and talk to customers about technology. I really enjoyed that. But I got the bug for entrepreneurship from that startup and started a couple of other companies along the way, and every time we started companies– I say ‘we’, because I've been with the same co-founders for 20+ years now– we always build everything ourselves at the beginning. So the three of us go in a room and we hack on stuff for months until we feel like we've got something good and we put it in front of users. I've done everything from an automotive marketplace startup to a parental control startup to a blade server startup and now environments as a service. And it's kind of a long meandering story about how I got to environments as a service, but I think the theme of my career has always been as an engineer first, when you build a company, making your developers productive saves you a lot of money. And because the three of us have always been engineering-oriented, we kind of have done from the beginning to start with. And the last startup that we had was a company by the name of CarWoo! that was an automotive marketplace that was acquired by TrueCar. And I ended up coming into that to run a product. The team that came in built a product within like three months and then we tried to deploy it into the ecosystem of a nearly public company at the time and it was incredibly difficult. The juxtaposition of being at a startup where you move really quick was really difficult to get technology out into the world there. And so I guess I was the squeaky wheel and complained about it a lot, and over the course of a few years I ended up running the technology team as the CTO there. And environments were a really, really big challenge at this company. They had 300-ish product and technology people. They had one or two staging environments for about 300 technologists, which there's a lot of bottlenecks that occur when 300 people are trying to share a few environments. And this was still in a physical data center, they hadn't yet moved to the cloud. And environments were critical there because obviously just the test code and things they needed it, but they also had about 400 partners that needed to test integrations with them as well and so there were environments for partners and environments were this constant theme of frustration, and nobody ever had enough of them. And I had seen the pain firsthand trying to build a product there and deliver it and it was really difficult so I ended up leading an effort to rebuild the technology stack there as the CTO and an environment management platform was needed. And when we looked in the market to buy something there really wasn't anything at the time. This is like 2016 or so, Docker was still having a lot of DNS issues and it was challenging to use, and containerization was just starting to come on board. Kubernetes wasn't really even a thing at the time, a lot of stuff had to be done in AWS through the console, there wasn't Terraform at the level that it is today. So after about 12 months we had built a homegrown environment management system and my founders and I looked at each other and said, “Man, if there was a product in the market that did this I bet you it would sell.” So we talked to folks along the way and kept hearing the same theme from engineering leaders wherever we went that environments are difficult and if there was a product that existed we'd probably buy it. So my co-founders and I started Release in 2019 right before the pandemic. And the goal of the company is environments are a bottleneck, but ideas getting to the world is always harder than it needs to be, and so the mission of the company is to get ideas to the world faster, and we're starting with the big bottlenecks in development and environments are a big part of that. So that's kind of the long meandering story. I think I've dated myself well enough now talking about blade servers and racking and stacking servers, but it's always been near and dear to me. From the beginning, I'm a developer at heart and like Cassidy said, anything we can do to make developers lives better is what I'm all about.
CW That is all so cool. I think my favorite part of that is the fact that you've worked with the same team of people for so long. That's a testament to not only how well you work together, but how well you communicate and how much you can build.
TM For good or bad.
CW Yeah, for better or for worse.
TM Yeah. There was a period of time, maybe like two years, where David Giffin one of our founders– maybe it was four years in the middle where he left and went to Etsy. And it's really interesting because his time at Etsy was pretty formative in the world of DevOps. If you go back and look at a lot of their blog posts they were really pushing continuous integration and continuous deployment. And David was there, I think he was engineer number eight at Etsy and so a lot of the productivity gains that you could get by having great environments and doing CI/CD, he was at the very beginning of this movement of DevOps. I don't even think they called it DevOps at the time. And then he rejoined Erik and I about three years later at the automotive startup. So there was a little bit of a departure for David but it was really useful for what we're doing because he learned by doing at Etsy.
BP Cool. You mentioned you have this trio of co-founders. How did y'all meet, and when you sit down in a room to hack something out, do you each have a traditional role where you work on different parts of the puzzle? Or does it all get mixed up?
TM Well, we all met at that blade server startup believe it or not. Actually I met Eric when we both went to college together but we didn't really know each other until college was over. And then we both ended up working at RLX and we met David who was a PHP systems management guru at the time. This was when PHP was just starting too, so that's even more dating us. I think when we build something we naturally have strengths and weaknesses. David is kind of the evil genius, mad scientist that will go hack on something and figure it out and blaze the trail of any hard problem. When we started Release, we didn't know anything about Kubernetes and we were like, “Man, Kubernetes could probably be pretty useful for this so we should go figure that out.” And David just put his headphones on and learned it in six weeks. He knew the ins and outs of Kubernetes and he's just really brilliant. And Erik is a really good systems thinker, backend engineer. He can build anything. He's a Rails guy, he's been using Rails since 2006 when Twitter started using it and couldn't make anything work because the performance problems were huge. And I'm like, “Just tell me what to do and I'll figure it out.” And so in one of the startups we built a little Windows application that had to run on any Windows machine, and it was like, “Hey, go figure out Visual Studio and C++,” so I jumped in and figured it out. And in this startup we didn't have a front end engineer and I was like, “Ah, how hard could this be?” So I learned React and struggled through it for about two months and then got to be the front end engineer. I actually wrote front end code at Release for probably about a year. And subsequently the team has thrown everything I did out. They're systematically removing every line of code that I ever wrote, which is good and it makes me happy because I don't want to answer any questions about it, and our team is way smarter than I am with that stuff so they're moving everything to TypeScript and doing some really cool stuff over there now. But yeah, we all kind of just filed into our lane and we just work really well. We know what everyone's good at and it's really nice to work with those two guys. I actually miss the earliest [days]. The earliest six months to a year of a company when you're just hacking in a garage, you always look back at it and you're like, “Man, that was the best time we ever had sitting on David's couch and just hacking on this problem.”
CW Yeah.
CF I'm hearing a lot of pivoting and filling roles that are open because someone needs to fill them, jumping head first into things that you may not be an expert in. I wonder if that has presented any challenges in how you overcame them, because I think that a lot of people just in general, but especially if you're interested in starting a company or a business or whatever the case may be, I think for a lot of people that's a hurdle that they have a hard time getting over. It's the idea that, “Oh, what if I change my mind, or what if I'm not an expert in this thing? What's going to happen later on down the line?” So how did you kind of deal with some of those issues that might come up and overcome them, because obviously you have.
TM Yeah, I think you have to go into it with just ignorance, actually.
CW Ignorance is bliss.
TM It is bliss, because a lot of times if you think about how big the idea you're working on is or how hard it's going to be, you won't take the first step.
CW That’s very true.
TM So becoming ignorant to the challenge and just saying, “Well, I’ve got to figure out React. That's the next thing that I need to do to make progress on this. I can do that, I can go figure out React, and David can go figure out Kubernetes, and Erik can put a data model together that represents what we're trying to do, and we'll start iterating and it'll start to come to life.” I think ignorance is a really big part of it. And then the second part of it is, if it works, whatever you come up with at the beginning is going to go away, so it doesn't live as long as you think it might. That front end code that I wrote sat around for probably six months to a year and smarter people came in and made it a lot better. So at the very beginning, all you're really trying to do is prove that you have something people want and they will pay for it. And if you can do that, it'll start to take a life of its own and then smarter people will come in and clean up the mess that you made. So you don't want to try to be too perfect early on. You’ve just got to get it to work and once you get it to work and a customer can see it or an investor can see it or a user can see it, all of a sudden the feedback starts to flow in and the idea goes from, “Hey, this is a little thing that we're thinking about,” to, “Oh, it has real purpose and meaning and somebody can use it to make their life better,” and then it starts to snowball from there. So I always tend to think, “Well, I’ve just got to get one person to use this. Let's start with one, and if I can get one there's probably more than one out there and then it'll just kind of go.” But that getting to one is always the hardest because there's so many reasons people come up with in their mind– “Well, I can't do this,” or “I'm not smart enough,” or “I don't know this technology.” It's a falsehood. You really can just roll your sleeves up and make something and there's so many tools out there right now that make it easier. I mean, it's so much different to build a startup now than it was. We had to have hardware back in the early days where we were literally sending motherboards to fabrication and if they came back and you had a chip that was wired wrong you were screwed for six months. Now you can mess up and start over in the same day if you want to. So it's really nice.
BP Right, right. So you mentioned when you reached out that you wanted to talk a bit about some of the roadblocks and bottlenecks that emerge, especially related with environments. And you had that experience that led to you becoming CTO at the car company. Talk to us a little bit if you can about the specifics of the pain points there, what the tech stack was. I know you mentioned 300 people sharing one or two environments was a problem, but what did you see there? And what have you built and in what way so that developers who are interested in trying out your tool have a sense of what they're going to get their hands on and how it might work for them?
TM Yeah. I think the easier way to answer that question is, what did they not have in the tech stack? It was literally a little bit of everything, lots of different languages, lots of different versions of databases, physical data centers. It was just kind of a sprawl of lots of different technologies across the board which made it difficult because if you're trying to normalize a process whether it's a development process or how you ship code or whatever that might be, if you have too many moving parts it gets really difficult. So I think that was kind of challenge number one and then challenge number two was, okay, now all of these different technologies converge into a QA environment, a dev environment, and a staging environment. If I remember right, that's what it was. So when you wanted to ship something you kind of had to raise your hand and say, “Okay, I want to ship and I want to do it on this day,” and a group of people would literally go into a room and runbook the next two weeks of how the deployments had to go out in all these various different pieces of technology so they would land in one of these environments so that the developers could actually test it and make sure that their code worked. And the other thing, and I think this is really relevant as modern applications get complicated is, applications have gotten so complicated that you really cannot run most of them on your laptop anymore. You can run parts of them, you might be able to run a service on your laptop, but if you really want to run a version of said product you have to have RDS databases, you have to have all of this technology to make it work. And that was definitely the case there where you couldn't run it locally, it just couldn't happen, so you were dependent on these environments to do your work. Simply speaking, 300 engineers sharing two or three environments, it's not going to go very fast. Just by definition there's a lot of waiting around, and there's a lot of rework. So you would build something and then you'd test it and you'd be like, “Oh, that's not right,” and then you'd be like, “Okay, I’ve got to go fix it,” and then you had to go back into line in the queue before you could get your change out to production. Security was a big challenge there too. We worked with a lot of banks. We worked with a lot of partners like that that really cared about their PII and their security, so you couldn't just give developers access to production. There was a lot of rules around who could get to those environments, what they could do, and every environment had a little bit different security policy which really made it tricky. It was really secure because it would kind of gradually lock itself down as you got closer to production, but every environment was a little different and I think that was another thing that we realized that as environments are different, it becomes tricky because if I test it on my laptop and then I go to staging and then I go to production, all of those are different. Who knows what's going to happen when you launch it. So that was the kind of lay of the land there that really had to be solved. So fast forward to today, I think everybody's pretty familiar with the concept of infrastructure as code now. You can write your Terraforms or your YAML files that describe your infrastructure. Your applications sit on top of your infrastructure, and so there is a layer more than just defining your infrastructure. You have to define your application, its requirements, and the infrastructure that goes along with it, so we talk about this as environments as code. So all the settings, services, data, configuration, infrastructure that goes into getting an application to run lives within an environment. And environments as code allows you to define not just your infrastructure. You might be using Terraform or Pulumi or AWS CDK to define your infrastructure but I also need to define my services and how those services might deploy into that environment so I can literally click a button and reproduce the environment with everything that it needs to run including data in that. So that's what Release does. It gets you to a point where you can define your environments in a template and then you can reuse that template to spin up and down environments whenever you need. So if I'm a developer and I say, “Hey, I want to just test this feature branch,” you can, with a pull request in GitHub, just do a PR and it'll automatically spin up a full stack environment– front ends, back end, databases, all the infrastructure, with just the branch that you're working on. It's dedicated and isolated to you so you're not dependent on all of the other developers that are changing things, you have your own standalone environment to do that. So one way to think of it is parallelized staging environments. Everybody can have their own, you can have it whenever you want, and you shut it down whenever you want. So that's the general core of the platform. It runs in your AWS or GCP account, so all of the infrastructure is running within your AWS or GCP account, so it's not a hosted thing. And it really just unlocks that bottlenecking problem that engineering organizations have. And you'd be surprised, when we sell this thing, almost every engineering team is doing this at some level. They're figuring it out, building it in house, they've got some scripts and they've got a bunch of stuff that they've cobbled together to approximate what we do. But a lot of time and energy goes into building that stuff. And we look at that– my co-founder calls it ‘toil’, which I find is a funny word, but it's this work that you do that isn't really value add. You have to do it to get everything you want for your users, but it doesn't really add a lot of value. And there's a lot of that that goes on in the development world. You're always trying to get your laptop to work and get your packages to install the right way and there's just all of this stuff going on that, if we're trying to get ideas to the world faster, if we can remove that stuff it's definitely going to make that happen.
CF Yeah. I say this every time we interview people who make products that aren't the same, but do this thing where they take away the busy work that prevents people from actually building.
CW The toil?
TM Yeah, the toil. I love that word. It's really good.
CF Yeah, you mentioned that there are so many parts of development that really cut off the ability of a developer to actually develop real stuff, so it's cool to see this. I think this is the first time I've heard of a product that tackles this specific issue that I know from experience and just talking to a lot of developers that it is an issue.
TM Yeah, it definitely is tricky. And you can get by for a while, like when we were first starting I didn't need a dev environment, a QA environment, a staging environment. We just had laptops and we made it work. But as you grow and grow and grow, it's expensive. You hire 300 engineers and they're sitting around trying to get NPM packages to install half the day, that's not a really good use of their time. So our vision and mission of the company is to make developers’ lives easier so they can release ideas faster. And we just have felt this environment problem everywhere we've gone, and if we could solve that then there's tons of other things that we can do, but that's just a really big pain point that is common all over the place.
CF Yeah. This is a hefty issue, it seems like it's a complex issue that a lot of people deal with, and earlier you mentioned that the hardest milestone is getting that first group of customers who trust you enough to pay for your thing to fix this problem. So what was that like? How did you do that? What is it like getting those first groups of customers that are going to actually trust you?
BP Great question.
TM It's kind of a two part answer. One is, always go to your friends first. There's nobody that's going to trust you off the street–
CW And roast you off the street, too.
TM Right, and be honest with you. You’ll go talk to people and they’ll be like, “Oh, that's a really great idea.” And then you're like, “Hey, will you pay me for it?” And the answer is “Well no, I'm not going to pay you for it but it's a really good idea.” So we had a close friend who ran about a Series B startup. We actually were one of their first customers when I was at TrueCar for a marketing automation platform that they have. So I called them and I said, “Hey, we're working on this. Can we talk to your engineering team just to get feedback?” So through a bunch of conversations they were like, “Hey, we'll give it a shot.” So we had our first hand raiser and this was actually before we even technically incorporated and we just were like, “Can we talk to your guys and see what they say?” And they lived through a lot of bumps, let's just put it that way. They were a pretty big company at the time, and one thing that we learned along the way is that if we were to go sell to startups exclusively, their technology stacks are a lot smaller so you don't have to deal with as much complexity. It's like, “Oh, it's a Rails app,” or, “It's a Node.js app.” It's straightforward. But when you go into a company that has 30, 40, 50 engineers, the technology stack starts to get really complicated. And we really wanted to tackle that problem because that's the problem that we felt, as the company gets bigger, let's go after bigger customers and see if we can solve it. And so this company was relatively bigger-sized. We got them to raise their hand and say, “Hey, we'll be the guinea pigs and work with you guys.” And crazy enough, they paid us too, even though it wasn't a perfect product. They were going to try to build something in house to do it and they were like, “Well, we'll just pay you guys to do it and if it works out– great, if not– we'll build it later.” For instance, David, who I talked about and worked at Etsy, worked with this guy at Etsy like 12 years ago so they knew each other really well.
CW So he knew specifically his pain.
TM Right. And so they trusted us because they knew we were good engineers and said, “If you could solve this for us then, great, we don't have to spend time on it.” You'd be surprised, if you call four or five people there's always somebody out there that's close to you that will say, “Yeah, I'll give it a shot.”
BP Right. In part it's the network you've built over time, but also like you said, maybe you're trying out their product at a certain point or you've done it at another company and so being willing to take a risk on someone and then have them return the favor.
TM Karma's a thing, I fully believe in it. You do something good for somebody, at some point they'll do something good for you, and I like to believe that that's the case all over. So that was answer one, close friends that would try it out that happened to be the CEO of a company so we were pretty fortunate to know that person and he vouched for us and said that he'd let us do it. And then after you get your first one you're like, “All right, how do we do that again?” Well, you probably don't have 50 friends like that. So we actually contemplated that problem a lot and said, “You know what? We should apply to YCombinator.” And so I actually did YCombinator in 2009, which was early days for YCombinator. If you don't know about YC, it's a startup accelerator that a lot of companies go through to get off the ground. And in 2009 we did that program when there was about 20 companies in the program, it was really small. That was for the automotive startup. And then fast forward to 2020, we said, “Well, if we want to get access to a lot of early stage companies, joining YCombinator is a really good way to get in where everybody's trying to figure out this first problem.” Everybody's trying to figure out how am I going to get my first customer. So we applied to YC and we got in, and then literally at the tables at dinner, David and I would wander around and just demo what we were doing and convince people to give it a shot. It was grassroots guerilla but we had this advantage because there was like 250 companies that were at YC when we went through it in 2020 versus the 22 or 23 back in 2009. And that was part of the reason why we did it. We had to find a way to get that flywheel going and I think that got us our next 10 customers. And even if you can't go do that, you’ve got to go where the customers are, right? You need to figure out what customers could I get access to that are willing to take a chance on me? And I had said this before that we wanted to go after bigger companies, but we really knew we weren't ready for it, so we did make that decision to switch back to startups and say, “Okay, we can do Rails apps, we can do Node apps, we can solve those. Let's go back to that idea, solve those smaller companies and work our way up to the bigger ones.” And that actually has worked really, really well for us. Two and a half years later, we can handle pretty much any complexity of environment somebody throws at us now, and two years ago we couldn't even handle a Rails app. So you kind of have to crawl, walk, and run, especially if your idea is really big and complicated. What's the smallest footprint of a customer you could work on? Go find where those people are and try to convince them.
[music plays]
BP All right, everybody. It is that time of the show. I want to shout out the winner of a badge. We're out of lifeboat badges because we've been recording so many podcasts, but I will shout out the winner of an inquisitive badge who has asked a well-received question on 30 separate days here on Stack Overflow and maintained a positive question record. So thanks for coming here and being curious, L Samuels, helping to spread some knowledge around the community. I am Ben Popper. I'm the Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper. Email us, podcast@stackoverflow.com with your questions or suggestions. Or if you like the show, leave us a rating and a review. We really appreciate it.
CF My name is Ceora Ford. I'm a Developer Advocate at Auth0. You can find me on Twitter. My username there is @Ceeoreo_.
CW My name is Cassidy Williams. You can find me @Cassidoo on most things.
TM Tommy McClung, co-founder and CEO of Release. You can find me @Tommy_McClung on Twitter, that's usually where I hang out. And our website is ReleaseHub.com.
BP Sweet. All right, everybody. Thanks for listening and we'll talk to you soon.
[outro music plays]