 From the CUBE studios in Palo Alto in Boston, connecting with thought leaders all around the world, this is a CUBE Conversation. Hi, and welcome to this CUBE Conversation. From our Boston area studio, I'm Stu Miniman. Happy to welcome to the program. First of all, we have a first-time guest. Always loved when we have a founder on the program. Anurag Goel is the founder and CEO of Brenda. And we brought along a longtime friend of the program, Dr. Steve Jared. He is a managing director at General Catalysts, a investor and render. Anurag and Steve, thanks so much for joining us. Thank you for having me. Yeah, thanks, Stu. All right, so Anurag, render. Your company, the tagline is the easiest cloud for developers and startups. It's a rather bold statement. Most people feel that the first generation of cloud has happened and there were certain clear winners there. The hearts and minds of developers absolutely has been a key thing for many money companies, one of those drivers in the software world. Why don't you give us a little bit of your background and as the founder of the company, what was it that the opportunity that you saw that had you create render? Yeah, so I was the fifth engineer at Scrype and helped launch the company and grow it to $5 billion in revenue. And throughout that period, I saw just how much money we were spending on just hiring DevOps engineers. AWS was a huge, huge management headache, really. There's no other way to describe it. And even after I left Scrype, I was thinking hard about what I wanted to do next. And a lot of those ideas required some form of development and deployment and putting things in production. And every single time I had to do the same thing over and over and over again as a developer. So despite all the advancements in the cloud, it was always repetitive work that wasn't just for my projects. I think a lot of my friends felt the same way. And so I decided that we needed to automate some of these new things that have come about as part of the regular application deployment process and how it evolves. And that's how render was born. All right, so Steve, remember in the early days, cloud was supposed to be easy and inexpensive. I've been saying on theCUBE, it's like, well, I guess it hasn't quite turned out that way. Love your viewpoint a little bit because you've invested here to really be competitive in the cloud. It's tens of billions of dollars a year that need to go into this, right? Yeah, I had the fortunate chance to meet Anurag early on. General Catalyst was an investor in Scrype. And so seeing what they did sort of spurred us to think about this. But I think we've talked about this before also on theCUBE, even back long ago in the VMware days, we looked very seriously at buying Heroku, one of the early players and still around obviously at Salesforce in this past space. And every single infrastructure conversation I've had from the start, I have to come back to myself and come back to everyone else and just say, don't forget the only reason any infrastructure even exists is to run applications. And as we talked about the first generation of cloud, it was about let's make the infrastructure disappear and make it programmatic. But I think even that we're realizing from developers that is just still way too low of an abstraction level. You want to write code, you want to have it in GitHub and you want to just press go and it should automatically deploy, automatically scale, automatically secure itself and just let the developer focus purely on the app. And that's an idea that people have been talking about for 20 years and should continue to talk about. But I really think with Render, we found a way to make it just super easy to deploy and run. And certainly it is big players out there but it really starts with developers loving the platform and that's been on the rocks obsession since I met him. Yeah, it's interesting when I first was reading, I'm like, wait, it reminds me a lot of somebody like say digital ocean, that cloud for developers or Steve, you've re-walked through. The past discussion has gone through so many iterations. What would containerization do for things? Or serverless was from its name, I don't need to think about that underlying layer. Anurag, give us a little bit as to, how should we think of Render? You are a cloud but you're not so much, you're not an infrastructure layer. You're not trying to compete against the laundry list of features that an AWS, Azure or Google have. You're a little bit different than some of the previous past layers and you're not serverless. So what is Render? Yeah, it is actually a new category that has come about because of the advent of containers and because of container orchestration tools and all the surrounding technologies that make it possible for companies like Render to innovate on top of those things and provide experiences to our two developers that are essentially serverless. So by serverless you could mean one of two things or many things really, but the way in which Render is serverless is you just don't have to think about servers. All you need to do is connect your code to GitHub and give Render a quick start command for your server and a build command if needed and we suggest a lot of those values ourselves. And then every push to your GitHub repo deploys a new version of your service. And then if you wanted to check out pull requests which is a way developers test out code before actually pushing it to deployment every pull request ends up creating a new instance of your service. And you can do everything from a single static site to really complex clusters of several microservices as well as managed Postgres, things like clustered Kafka and Elasticsearch. And really one way to think about Render is it is the platform that every company ends up building internally and spends a lot of time and money to build. And we're just doing it once for everyone and doing it right. This is what we specialize in. So you don't have to. Yeah, just to add to that if I could, what's I think interesting is we've had and talked about a lot of startups doing a lot of different things and there's a huge amount of complexity to enable all this to work at scale and to make it work with all the things you look for whether it's storage or CDNs or metrics and alerting and monitoring all of these little startups that we've gone through and big companies alike if you could just hide that entirely from the developer and just make it super easy to use and deploy. That's been the mission that Anurag's been on the start and as you heard from some of the early customers and how they're increasing the usage, it's just that love of making it simple that is key in this space. All right, yeah, Anurag, maybe it would really help illustrate things if you could talk a little bit about some of your early customers, their use case and give us what statute can about how your company is growing. Certainly, so one of our more prominent customers was the Pete Buttigieg campaign which ran through most of 2019 and through the first couple of months of 2020 and they moved to us from Google Cloud because they just could not or did not want to deal with the complexity inherent in today's sort of standard infrastructure providers where you get a VM and then you have to figure out how to work with it or even manage Kubernetes. Actually, they're trying to run on managed Kubernetes on GKE and that was too complex or too much to manage for the team. And so they moved all of their infrastructure over to render and they were able to service you know, billions of requests over the next few months just on our platform. And every time Pete Buttigieg went on stage during a debate and said, oh, go to PeteforAmerica.com. There's a huge spike in traffic on our platform and it's scaled with every debate. And so that's just one example of where really high quality engineering teams are saying, no, this stuff is too complex. It doesn't need to be. And there is a simpler alternative and render spelling in that gap. We also have customers all over from, you know, single indie hackers who are just building out their new project ideas to late stage companies like Stripe where we are making sure that we scale with our users and we give them the things that they would need without them having to mature into AWS or grow into AWS. I think render is built for the entire life cycle of a company, which is you start off really easy and then you grow with us. And that is what we're seeing with render where a lot of customers are starting out simple and then continuing to grow their usage and their traffic with us. Yeah, I was doing some research getting ready for this on a rug. I saw, you know, it's not necessarily you're saying the keeper, but there are some times that, you know, price can help, performance can be better. If I was, you know, a Heroku customer or an AWS customer, I guess, what might be some of the reasons that I'd be considering render? So for Heroku, I think the comparison of course, there's a big difference in price because we think Heroku is significantly overpriced because they have a perpetual free tier and so their paid customers end up footing the bill for that. We don't have a perpetual free tier that way we make sure that our paid customers pay what's fair. But more importantly, we have features that just haven't been available in any platform as a service until now. For example, you cannot spin up persistent storage, block storage in Heroku. You cannot set up private networking in Heroku as a developer unless you pay for some like crazy enterprise tier which is, you know, $15,000 a month and render just builds all of that into the platform out of the box. And when it comes to AWS, again, there's no comparison in terms of ease of use. We'll never be cheaper than AWS. That's not our goal either. It's our goal to make sure that you never have to deal with the complexity of AWS while still giving you all the functionality that you would need for AWS. And when you think about applications as applications and services as opposed to applications that are running on servers, that's where render makes it much easier for developers and development teams to say, look, we don't actually need to hire hundreds of DevOps people. We can significantly reduce our DevOps team and the existing DevOps team that we have can focus on application level concerns like performance. All right, so Steve, I guess a couple of questions for you. Number one is, we haven't talked about security yet, which I know is a topic near and dear to your heart. You know, was one of the early concerns about cloud but now often is a driver to move the cloud. Give us the security angle for this space. Yeah, I mean, the key thing in all of the spaces to get rid of the complexity and complexity in human error is often, as we've talked about, that is the number one security problem. So by taking this fresh approach, it's all about just the application and a very simple GitOps based workflow for it, you're not going to have the human error that typically has misconfigured things and coming into there. I think more broadly that the overall notion of this serverless world has also been a very nice move forward for security. If you're only bringing up and taking down the pieces of the application as needed, they're not there to be hacked or attacked. So I think for those two reasons, this is really a more modern way of looking at it. And again, I think we've talked about many times, security is the bane of DevOps. It's the slowest part of any deployment. And the more we get rid of that, the more the extra value proposition comes safer and also faster to deploy. The question I'd like to hear both of you is the role of the developer has changed an awful lot. Five years ago, if I talked to companies and they were trying to bring DevOps, the enterprise or anything like that, it seemed like they were doomed. But things have matured. We all understand how important the developer is. And it feels like that line between the infrastructure team and the developer team is starting to move. At least I have tools and communication happening between them. I'd love, maybe Steve, if you can give us a little bit your macro view on it, and Anurag, where that plays for render, too. Yeah, and Anurag, I especially would be able to go into our existing customers. What I love about render, this is a completely sort of clean sheet approach to thinking about, get rid of infrastructure, just make it all go away and have it be purely there for the developers. Certainly the infrastructure people need to audit and make sure that you're passing the certifications and make sure that it has acceptable security and data retention and all those other pieces. But that becomes Anurag's problem, not the developer problem. And so that's really how you look at it. The second thing I've seen across all these startups, you don't typically have, especially you're not talking about startups, but mid-sized companies and above, they don't convert all the way to DevOps. You typically have people peeling off individual projects and trying to move faster and use some new approach for those. And then as those hopefully go successful, more and more of the existing projects will begin to move over there. And so what render's been doing and what we've been hoping from the start is, let's attract some of the key developers and key new projects and then word will spread within the companies from there. But so the answer in a lot of these companies, make developers love you and make the infrastructure team at least supports you. Yeah, and that was a really good point about developers and infrastructure DevOps, people the line between them sort of thinning and becoming more of a gray area. I think that's absolutely right. I think the developers want to continue to think about code, but then in today's environment, outside of render, when we see things like AWS and things like digital ocean, you still see developers struggling. And in some ways, render is making it easy for smaller companies and developers and startups to use the same best practices that a fully fledged DevOps team would give them. And then for larger companies, again, it makes it much easier for them to focus their efforts on business development and making sure they're building features for their users and making their apps sort of more secure outside of the infrastructure realm and not spending as much time just, you know, hurting servers and making those servers more secure. To give you an example, renders machines aren't even accessible from the public internet where our workloads run. So there's no firewall to configure really for your app. There's no DMZ, there's no VPN. And then when you want to make sure that you're just, you want a private network, that's just built into render along with service discovery. All your services are visible to each other, but not to anyone else. And just setting those things up on something like AWS and then managing it on an ongoing basis is a huge, huge, huge cost in terms of resources and people. All right, so Anurag, you just opened your first region in Europe, Frankfurt, if I remember right. Give us a little bit as to what growth we should expect, you know, what you're seeing and how you're going to be expanding your services. Yeah, so the expansion to Europe was by far our most requested feature. We had a lot of European users using render, even though our servers were until now based in the US. In fact, one of, or perhaps the largest recipe sharing site in Italy was using render, even though the servers were in the US and all their users were in Italy. And when we moved to Europe, that was like this, you know, it was Christmas come early for them. And they started, they just started moving over things to our European region. But that's just the start, right? We have to make sure that we make compute as accessible to everyone, not just in the US or Europe, but also in other places. So we're looking forward to expanding in Asia, to expanding in South America and even Africa. And our goal is to make sure that your applications can run in a way that is completely transparent to where sort of they're running. And you can even say, look, I just want my application to run in these four regions across the globe, you figure out how to do it and we will. And that's really the sort of dream that a lot of platform service have been selling, but haven't been able to deliver yet. And I think again, render is sort of this at this point in time where we can work on those crazy, crazy dreams that we've been selling all along and actually make them happen for companies that have been burned by platforms as a service before. Yeah, I guess it brings up a question. You talk about platforms and one of the original ideas of PAS and one of the promises of containerization was, I should be able to focus on my code and not think about where it lives. But part of that was, if I need to be able to run it somewhere else or want to be able to move it to where else that I can. So that whole discussion of portability, you know, in the Kubernetes space, it definitely is something that gets talked quite a bit about and, you know, can I move my code? So where does multi-cloud, you know, fit into your customer's environments on a ROG? And, you know, is it once they come on to render they're happy and it's easy and they're just doing it? Or, you know, are there things that they develop on render and then run somewhere else also, maybe for a region that you don't have? How does multi-cloud fit into your customer's world? That's a great question. And I think that multi-cloud is a reality that will continue to exist and just grow over time because not every cloud provider can give you every possible service you can think of, obviously. And so we have customers who are using, say, Redshift on AWS, but they still want to run their compute workloads on render. And as a result, they connect to AWS from their services running on render. The other thing to point out here is that render does not force you into a specific paradigm of programming. So you can take your existing apps that have been containerized or not and just run them as is on render. And then if you don't like render for whatever reason you can take them away without really changing anything in your app and run them somewhere else. Now, obviously you'll have to build out all the other things that render gives you out of the box but we don't lock you in by forcing you to program in a way that, for example, AWS Lambda does. And when it comes to the future, multi-cloud, I think render will continue to run in all the major clouds as well as our own data centers and make sure that our customers can run the appropriate workloads wherever they are as well as connect to them from the render services really easily. Excellent. And maybe I'll make one more point if I could, Stu, which is one thing I've been excited to watch is in any of these platforms as a service is you can't do everything yourself. So you want the open source package vendors and other folks to really buy into this platform too. And one exciting thing we've seen at render is a lot of the big open source packages are saying, boy, it'd be easier for our customers to use our open source if we were running on render. And so this ecosystem and the set of packages that you can use will just be easier and easier over time. And I think that's going to lead to, you know, at the end of the day, people would like to be able to move their applications and have it run anywhere. And I think by having those services here, ultimately they're going to deploy to AWS or Google or somewhere else. But it is really the right abstraction layer for letting people build the app they want that's going to be future proof. Excellent. Well, Steve and Anurag, thank you so much for the update. Great to hear about render. Look forward to hearing more updates in the future. Thank you, Stu. Thanks, Stu. Good to talk to you. All right. And stay tuned, lots more coverage. If you go to the cube.net, you can see all of the events that we're doing with remote coverage, as well as the back catalog of what we've done. I'm Stu Miniman and thank you for watching theCUBE.