Speaker 2
Now here you are, $155 million deep raised, $80 million recently announced last month. You must be excited. So welcome finally to the changelog.
Speaker 1
Thank you. Yes, it has been a journey, but I'm really happy that we're finally having this conversation.
Speaker 2
You know, I'm such a fan of the boldness it must require and the courage it must require to take on Goliaths. And not just one, but many, right? Like Render is in the shadow and maybe now above the shadow of the days of Heroku. GCP is obviously still there. We'll talk about your infrastructure. I think you're built on the clouds. So you compete with the clouds you're actually built on too, I imagine, but at a different level. I just admire the courage and required tenacity to do what you've done. And you've obviously done it well.
Speaker 1
Thank you. I really appreciate that. It is not how I think about it. No?
Speaker 2
How do you think about it?
Speaker 1
Well, I think this is a large and important problem. And maybe I can give you some background on how I ended up doing what I do now. So before Render, I won't go too far back, but I joined Stripe as the fifth engineer in 2011. And I left in 2016. And the company did well. And so I had this opportunity to really think hard about what I wanted to do for the rest of my career. I could choose to do nothing and sort of chill out, but my wife and I both, we talked about it. And I think it was, we both saw it and see it as a responsibility. Very few people are granted this opportunity to really have the freedom to pursue any goal that they want. And so my goal then became to find a really big problem that I'm also very excited to solve and that I am good at solving. And as part of that, I ended up building applications in a lot of different domains. And I mean, even at Stripe, I had seen our infrastructure team that was managing AWS grow from, you know, when I was there, one person out of five was fully focused on AWS. That number, that percentage, about 20%, stayed about the same as Stripe continued to grow, at least when I was there, 2011 through 2016. And all these people were simply managing VMs on AWS. They weren't contributing to the product. They weren't helping the other teams necessarily move faster. So that was a big waste. And then when I built my own applications post-Stripe to try to figure out which domain I was going to be interested in over the long term, it hit home firsthand. It was very obvious to me that getting something up and running in the cloud was still very broken. Ultimately, you end up building out a Kubernetes cluster and no one wants to do that. I'm sure there are some people in the world who love building out Kubernetes clusters and bringing all the care and feeding that those clusters require over time and spending all the money that Kubernetes ends up sucking out of your ops budget. But ultimately what people want, what I wanted was I want my application to, first of all, I want my cloud to allow me to spin up an application really quickly and get it up and running and make it reliable. But then I wanted to scale. I want a lot of security by default around it. I want all the features that I will need as the application grows. And so the dichotomy between Heroku and AWS when I started Render was Heroku was easy to get started on, but it stopped scaling beyond a certain point. And if you needed more than 14 gigs of RAM, you couldn't have it. You just couldn't. Your applications were restarted every, and a lot of this is still true. Your applications were restarted every 24 hours. And then the price became unsustainable once you went beyond a certain scale. And then AWS was AWS, just even logging in and looking at the dropdown of the 300 plus services. They have a search in their dropdown. Who has a search in a dropdown? AWS does. AWS does. Yeah, AWS does. So, and that's, it comes down to the culture of AWS, right? They were built around two pizza teams. two pizza teams do really well when they are focused on a small surface area that can be deep, but then it doesn't, it's not broad. that are stable, reliable, scalable. But then you have 300 of these primitives on AWS that you then have to go manage and integrate and then build on top of. And the cloud has only become more complex over time. And I was always drawn to developer productivity. But then when I started spinning up all of my own infrastructure, I felt, continued to feel a draw towards infrastructure as well. I enjoyed spinning up infrastructure, but also I knew that I was doing sort of the same thing over and over again. So when I combined those two things together, that led to Vend's genesis in 2018. And it wasn't about taking on AWS. It was about solving the problem that I had seen and in a way that made sense to me from a product standpoint. And AWS is always going to be very, very, very, very successful. Even when Render is a large public company, AWS will still be making a ton of money. And that's because the market we operate in is so massive. And you don't have to have a winner-take mentality. I mean, you think about it, you know, AWS had this massive lead and now they're still the leader in the cloud space, but Azure and I guess GCP have built businesses worth hundreds of billions of dollars coming from behind. So it just comes down to the demand and the market you're in. And certain markets are winner take all. Other markets are multiple people can exist and have their own unique angle on the problem. And that's how I think about Render. Yeah.
Speaker 2
It makes sense hearing that, Baxter, why you didn't agree with my thing of taking on Goliath. I still think you're facing, you know, some sort of imminent threat, at least not so much today, but in the early days, because the threat isn't necessarily the technology, it's the ability to attract a developer's attention, right? To give any care to why render, why try render, why, you know, in that case. But I think a lot of developers had this and still do have haven't had this affinity towards Heroku. Heroku was the very first platform as a service to care, I would say, about developer experience and make it literally just too easy to
Speaker 1
ship. It was just so easy. It was great. For the time, for 2005, it was magic. And you followed in those footsteps to
Speaker 2
take that magic to a new level because, as you said, there's limitations. And I know many friends who have launched their applications there successfully. Smaller shops, smaller applications for a small business, so to speak. But then once you get to a certain scale, there is this limitation that was, you know, hit on Roku. And, you know, that's kind of Salesforce and other things made it not, you know, go beyond where it could have gone. You know, there was a lot of potential that wasn't fully realized beyond, you know, what they'd actually achieved.
Speaker 1
And at the same time, AWS kept launching service after service because, you know, AWS launched in some ways after Heroku did, right? Because we're talking about Heroku launching in, I guess that's not entirely true. Heroku was on the scene in 2007 and then they got acquired in 2010. So they've now been part of Salesforce for 15 years. And AWS was also like S3 came on the scene around 2005-ish. But then EC2 and others. And I think Heroku could have done a better job keeping up to date with how people were building applications. And they really missed the whole trend around static sites and containers and all the other ways in which people build applications. And that's really the differentiation. I think when you think about Render from the beginning, it was about how people were building applications today and what they needed from the cloud. And then that continues. So fundamentally, the way developers build applications changes every few years. And frameworks come and go. Databases come and go. The way we do async processing comes and goes. And these days, it's all about calling out to chat GPT or cloud APIs, and then managing all of those pieces of like all this data that you're feeding to these models, and then you're collecting the results and doing all of this in discrete steps and combining all of them together at the end. So I think the cloud, any cloud, should be constantly thinking about the primitives that developers need that every company ends up building themselves. And when Render started, it wasn't just about Heroku. It was also about Kubernetes because every company ends up building a sort of internal Kubernetes cluster that looks very similar. People end up using the same Helm charts. They end up, you know, installing the same sort of like standard things. The problem, of course, is that that's a lot of wasted work and companies do it because they think that's what needs to be done. And Render is saying, no, actually, what you want to get out of Kubernetes, we give you out of the box. scaling, if you want health checks, zero downtime deploys, if you automatically want to compress your responses, if you want your SSL to be completely managed for you, if you want volumes, if you want the ability to store data on a disk, you can do all of that on render and you don't really need Kubernetes. And that has been one of the ways in which we have attracted a lot of people over the years. And, you know, in January, we signed up 110,000 developers.