Screaming in the Cloud - Google Cloud Run, Satisfaction, and Scalability with Steren Giannini

Episode Date: June 23, 2022

Full Description / Show NotesSteren and Corey talk about how Google Cloud Run got its name (00:49)Corey talks about his experiences using Google Cloud (2:42)Corey and Steren discuss Google Cloud’s cloud run custom domains (10:01)Steren talks about Cloud Run’s high developer satisfaction and scalability (15:54)Corey and Steren talk about Cloud Run releases at Google I/O (23:21)Steren discusses the majority of developer and customer interest in Google’s cloud product (25:33)Steren talks about his 20% projects around sustainability (29:00)About SterenSteren is a Senior Product Manager at Google Cloud. He is part of the serverless team, leading Cloud Run. He is also working on sustainability, leading the Google Cloud Carbon Footprint product.Steren is an engineer from École Centrale (France). Prior to joining Google, he was CTO of a startup building connected objects and multi device solutions.Links Referenced:Google Cloud Run: https://cloud.runsheets-url-shortener: https://github.com/ahmetb/sheets-url-shortenersnark.cloud/run: https://snark.cloud/runTwitter: https://twitter.com/steren

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in parts by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with Postgresquil for 15 years.

And now, EnterpriseDB has you covered wherever you deploy Postgresquil. On-premises, private cloud, and they just announced a fully managed service on AWS and Azure called Big Animal. All one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half-dozen managed databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money. They can even help you migrate legacy applications, including Oracle, to the cloud.

To learn more, try Big Animal for free. Go to biganimal.com slash snark and tell them Corey sent you. DoorDash had a problem. As their cloud-native environment scaled and developers delivered new features, their monitoring system kept breaking down. In an organization where data is used to make better decisions about technology and about the business, losing observability means the entire company loses their competitive edge. With Chronosphere, DoorDash is no longer losing visibility into their application suite. The key? Chronosphere is an open-source compatible, scalable, and reliable observability solution

that gives the observability lead at DoorDash business confidence and peace of mind. Read the full success story at snark.cloud slash chronosphere. That's snark.cloud slash c-h-r-o-n-o-s-p-h-e-r-e. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined today by Starin Janani, who is a Senior Product Manager at Google Cloud, specifically on something called Google Cloud Run. Starin, thank you for joining me today. Thanks for inviting me, Corey.

So I want to start at the very beginning of, oh, a cloud service. What are we going to call it? Well, let's put the word cloud in it. Okay, great. Now, it is cloud, so we have to give it a vague and unassuming name. What does it do? It runs things.

Genius. Let's break and go for work. Now, it's easy to imagine that you spent all of 30 seconds on a name, but it never works that way. How easy was it to get to Cloud Run as a name for the service? Such a good question

because originally it was not named Cloud Run at all. The original name was Google Serverless Engine. A few people know that because they've been helping us since the beginning. But originally, it was Google Serverless Engine. Nobody liked the name internally. And I think at one point, we wondered, hey, can we drop the engine structure and let's just think about the name? And what does this thing do?

It runs things. We already have Cloud Build. Well, wouldn't it be great to have Cloud Run to pair with Cloud Build so that after you've built your containers, you can run them? And that's how we ended up with this very simple Cloud Run, which today seems so obvious. But it took us a long time to get to that name. And we actually had a lot of renaming to do because we were about to ship with Google's serverless engine. That seems like a very interesting last-minute change.

It's not just a find and replace at that point. It's, well, okay, if we call it Cloud Run, which can also be a verb or a noun, depending, is that going to change the meaning of some sentences? And just doing a find and replace without a proofread pass as well, well, that's how you wind up with funny things on Twitter. API endpoints needed to be changed, adding weeks of delays to the launch. That is why we, you know, announced in 2018 and publicly launched in 2019.

I've been doing a fair bit of work in cloud for a while. And I wound up going down a very interesting path. So the first native Google Cloud service, not things like WP Engine that ride on top of GCP, but my first native Google Cloud service was done in service of this podcast. And it is built on Google Cloud Run. I don't think I've told you part of this story yet, but it's one of the reasons I reached out to invite you onto the show. Let me set the stage here with a little bit of backstory that might explain what the hell I'm talking about. As listeners to this show are probably aware, we have sponsors whom we love and adore. In the early days of this show, they would say, great, we want to tell people about our product, which is the point of a sponsorship,

and then send them to a URL. Great. What's the URL? And they would give me something that was three layers deep, then with a bunch of UTM tracking parameters at the end. And you do realize that no one is going to be sitting there typing all of that into a web browser. At best, you're going to get three words or so. So I built myself a URL redirector, a snark.cloud.

I can wind up redirecting things in there anywhere it needs to go. And for a long time, I did this on top of S3 and then put CloudFront in front of it. And this was all well and good until things happened in the fullness of time. And now, holy crap, I have an operations team involved in things and maybe I shouldn't be the only person that knows how to work on all of these bits and bobs. So it was time to come up with something that had a business user-friendly interface that had some level of security so I don't wind up automatically building out a spam redirect service for anything that wants to. And it needs to be something that's easy to work with. So I went on an exploration. So at first, it showed that there were... I have an article out

that I've spoken about before, that there are 17 ways to run containers on AWS. And then I wrote the SQL, 17 more ways to run containers on AWS. And I'm keeping a list. I'm almost to the third installation of that series, which is awful. So great, there's got to be some ways to build some URL redirect stuff with an interface that has an admin panel. And I spent three days on this, trying a bunch of different things. And some were running on deprecated versions of Node that wouldn't build properly, and others were just such complex nonsense things that it got really bad. I was starting to consider something like just paying for Bitly or whatnot and making it someone else's problem.

And then I stumbled upon something on GitHub that really was probably one of the formative things that changed my opinion of Google Cloud for the better. And within half an hour of discovering this thing, it was up and running. I did the entire thing start to finish from my iPad in a web browser, and it just worked. It was written by, let me make sure I get his name correct. Messing up someone's name is a great way to say that we don't care about them. Ahmet Balkan used to work at Google Cloud, now he's over at Twitter. And he has something up on GitHub that is just absolutely phenomenal about this called Sheets-URL-Shortener. And this is going to sound wild, but stick with me.

The interface is simply a Google Sheet, where you have one column that has the shorthand slug, for example, run. If you go to snark.cloud slash run, it will redirect to Google Cloud Run's website. And the second column is where you want it to go, the end.cloud slash run, it will redirect to Google Cloud Run's website. And the second column is where you want it to go. The end. And whenever that gets updated, there's of course some caching issues, which means it can take up to five seconds from finishing that before it'll actually work across the entire internet. And as best I can tell, that is fundamentally magic. But what made it particularly useful and magic from my perspective was how easy it was to get up and running.

There was none of this, oh, but then you have to integrate it with Google Sheets and that's a whole nother team. So there's no way you're going to be able to figure that out from our docs, go talk to them and then come back in a day. There would be get started, click here to proceed. It just worked.

And it really brought back some of the magic of cloud for me in a way that I hadn't seen in quite a while. So all which is to say, amazing service. I continue to use it for all of these sponsor links and I am still waiting for you folks to bill me, but it fits comfortably in the free tier because it turns out that I don't have hundreds of thousands of people typing it in every week. I'm glad it went well. And we measure task success for Cloud Run, and we do know that most new users are able to deploy their apps very quickly. And that was the case for you. Just so you know, we've put a lot of effort to make sure it was true. And I'll be glad to tell

you more about all that. But for that particular service, yes, I suppose Ahmed, who I really enjoyed working with on Cloud Run, he was really helpful designing Cloud Run with us, has open sourced this side project. And basically, you might even have clicked on a deploy to Cloud Run button on GitHub, right, to deploy it. That's exactly what I did. And it somehow just worked. And it knew, even logging into the Google Cloud Console, because it understands who I am, because I use Google Docs and things, I'm already logged in. None of this, oh, which one of these 85 credential sets is it going to be like certain other clouds? It was, oh, wow, wait, cloud can be easy and fun. When did that happen?

So what has happened when you click that deploy to Google Cloud button, basically, the GitHub repository was built into a container with cloud built and then was deployed to Cloud Run. And once on Cloud Run, well, hopefully you have forgotten about it because that's what we do, right? We give us your code in a container if you know containers. If you don't, just we support, you know, many popular languages and we know how to build them. So don't worry about that. And then we run it. And as you said, when there is low traffic or no traffic, it scales to zero.

When there is low traffic, you are likely going to stay under the generous free tier. And if you have more traffic for, you know, screaming in the cloud, suddenly becoming a high-destination URL redirect, well, CloudOn will scale the number of instances of this container to be able to handle the load. Cloud Run scales automatically and very well, but only, as always, charging you when you are processing some requests. I had to fork it and make a couple of changes myself

after I wound up doing some testing. The first was to make the entire thing case-insensitive, which makes obvious sense. And the other was to make the entire thing case insensitive, which makes obvious sense. And the other was to change the permanent redirect to a temporary redirect, because believe it or not, in the fullness of time, sometimes sponsors want to change the landing page in different ways for different campaigns. And that's fine by me.

I just wanted to make sure people's browser cache didn't remember it into perpetuity. But it was easy enough to run. That was back in the early days of my exploring Go, which I've been doing this quarter. And in the couple months this thing has been running, it has been effectively flawless. It's set it, it's forget it. The only challenges I had with it are it was a little opaque getting a custom domain set up, which is still in beta, to be clear. And I've heard some horror stories of people saying it got wedged. In my case, no, I deployed it and I started refreshing it

and suddenly started throwing an SSL error. And it's like, oh, that's not good, but I'm going to break my own lifestyle here and be patient for 10 minutes. And sure enough, it cleared itself and everything started working. And that was the last time I had to think about any of this. And it just worked. So first, CloudOn is HTTPS only.

Why? Because it's 2020, right? It's 2022, but it's launched in 2020. And so basically, we have made a decision that let's just not accept HTTP traffic. It's only HTTPS. As a consequence, we need to provision a cert for your custom domain. That is something that can take some time.

And as you said, we keep it in beta or in preview because we are not yet satisfied with the experience or even the performance of cloud and custom domains. So we are actively working on fixing that with a different approach. So expect some changes, hopefully this year. I will say it does take a few seconds when people go to a snark.cloud URL for it to finish resolving. And it feels, on some level, like it's almost like a cold start problem, but subsequent visits to the same thing also feel a little on the slow and pokey side. And I don't know if that's just me being wildly impatient,

if there's an optimization opportunity, or if that's just inherent to the platform that is not under current significant load. So, it depends. If the Cloud Run service has scaled down to zero, well, of course, your service will need to be started. But what we do know,

if it's a small Go binary, like something that you mentioned, it should really take less than, let's say, 500 milliseconds to go from zero to one of your container instance. Latency can also be due to the way the code is running. If the code is fetching things from Google Sheet at every startup, that is something that could add to the startup latency. So I would need to take a look. But in general, we are not spinning up a virtual machine anytime we need to scale horizontally. Our infrastructure is a multi-tenant, rapidly scalable infrastructure that can materialize a container in literally 300 milliseconds. The rest of the latency comes from

what does the container do at startup time. I just ran a quick test of putting time in front of a curl command. It looks like it took 4.83 seconds. So enough to be perceptive, but again, for just a quick redirect, it's generally not the end of the world. There's probably something I'm

doing that is interesting and odd. Again, I did not invite you on the show to file a bug report. Let's be very clear here. That seems on the very high end of startup latencies. I mean, I would definitely expect under the second. We should deep dive into the code to take a look. And by the way, building stuff on top of spreadsheets, I've done that a ton in my previous lives as a CTO of a startup.

Because, well, that's the best administration interface, right? You just have a CRUD UI. It rules the world and all business users understand it. If people in Microsoft decided they were going to change Microsoft Excel interface even a bit, they would revert the change before noon of the same day after an army of business users grabbed pitchforks and torches and marched on their headquarters. It's one of those things that that is how the world runs. It is the world's most common IDE. And it's great. I mean, I still think of databases through the lens of thinking about it as a spreadsheet, as my default approach to things. I also think of databases as DNS, but that's either here or there. You know, if you have maybe a hundred redirects, that's totally fine. And by the way, the beauty of Cloud Run and Spreadsheet, as you mentioned, is that Cloud Run services run with a certain identity.

And this identity, you can grant it permissions. And in that case, what I would recommend, if you haven't done so yet, is to give an identity to your Cloud Run service that has the permission to read that particular spreadsheet. And how you do that, you invite the email of the service account as a reader of your spreadsheet. And that's probably what you did.

The click button to the roadblock on Google Cloud automatically did that and talked to me how to do it. Here's the thing to look at, the end. It was a flawless user onboarding experience. Very nicely done. But indeed, there is this built-in security, which is the principle of minimal permission. Each of your cloud service should basically only be able to read and write to the backing resources that they should. And by default,

we give you a service account which has a lot of permissions, but our recommendation is to narrow those permissions to basically only look at the cloud storage buckets that this service is supposed to look at. at the cloud storage buckets that this service is supposed to look at. And the same for a spreadsheet. Yes, on some level, I feel like I'm going to write an analysis of my own security approach. It'd be titled, my god, it's full of stars as I look at the IAM policies of everything that I've configured. The idea of least privilege is great. What I like about this approach is that it made it easy to do it, so I don't have to worry about it. At one point, I want to go back and wind up instrumenting it a bit further, just so I can

wind up getting aggregate numbers of, all right, how many times has someone visited this particular link? It'll be good to know. And I don't know if I have to change permissions to do that yet, but that's okay. It's the best kind of problem. Future Corey. So we'll deal with that when the time comes. But across the board, this has just been a phenomenal experience. And it's clear that when you were building Google Cloud Run, you understood the assignment. Because I was looking for people saying negative things about it. And by and large, all of it seemed to come from a perspective of, well, this isn't going to be the most cost-effective or best way to run something

that is hyperscale, globe-spanning. Yes, that's the thing that Kubernetes was originally built to run. And for some godforsaken reason, people run their blog on it instead now. Okay. For something that is small, scales to zero, and has long periods where no one is visiting it, great. This is a terrific answer. And there's absolutely nothing wrong with that. It's clear that you understood who you were aiming at and the migration strategy to something that is a bit more, I want to say robust, but let's be clear what I mean when I'm saying that. If you want something that's a little bit more impressive on your SRE resume as you're trying a multi-year project to get hired by Google or pretend you got hired by Google, yeah, you can

migrate to something else in a relatively straightforward way. But this is up, running, and works without having to think about it. And that is no small thing. So there are two things to say here. The first is, yes, indeed, we know we have high developer satisfaction. We measure this in Google Cloud. You might have seen those small satisfaction surveys popping up sometimes from the user interface. And we are above 90% satisfaction score. We hire third parties to help us understand how usable and what satisfaction score would users get out of Cloud Run. And we are constantly getting very, very good results in absolute, but also compared to the competition. Now, the other thing that you said is that, you know, Cloud Own is for small things. And here, well, it is definitely something that allows you to be productive, something that strives for simplicity, but it also scales a lot. And contrary to other systems,

you do not have any pre-provisioning to make. So we have done demos where we go from zero to 10,000 container instances in 10 seconds. Because of the infrastructure on which Cloud Run runs, which is fully managed and multi-tenant, we can offer you this scale on demand. And many of our biggest customers have actually not switched to something like Kubernetes after starting with Cloud Run

because they value the low maintenance, the no infrastructure management that Cloud Run brings them. So we have like IKEA, Ecobee, for example, Ecobee, you know, the smart thermostats are using Cloud Run to ingest events from the thermostats. I think IKEA is using Cloud Run more and more for more of their websites. You know, those companies scale, right? This is not like scale to zero hobby project. e-commerce and connected smart objects production systems

that have made the choice of being on a fully managed platform in order to reduce their operational overhead. This episode is sponsored in part by our friends at Vulture, spelled V-U-L-T-R, because they're all about helping save money, including on things like, you know, vowels. So what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that, well, sure, they claim it is better than AWS's pricing. And when they say that,

they mean that it's less money. Sure, I don't dispute that. But what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to cost. They have a bunch of advanced networking features. They have 19 global locations and scale things elastically, not to be confused with openly, which is apparently elastic and open. They can mean the same thing sometimes. They have had over a million users. Deployments take less than 60 seconds across 12 pre-selected operating systems, or if you're one of those nutters like me,

you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vulture Cloud Compute, they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something of the scale on their own.

Try Vulture today for free by visiting vulture.com slash screaming, and you'll receive $100 in credit. That's v-u-l-t-r dot com slash screaming. Let me be clear. When I say scale, I think we might be talking past each other on a small point here. When I say scale, I'm talking less about, oh, tens or hundreds of thousands of containers running concurrently.

I'm talking in a more complicated way of, okay, now we have a whole bunch of different microservices talking to one another and affinity as far as location to each other for data transfer reasons. And as you start beginning to service discovery style areas of things, where we built a really complicated application because we hired engineers and failed to properly supervise them, and that type of convoluted, complex architecture, that's where it feels like Cloud Run increasingly, as you move in that direction, starts to look a little bit less like the tool of choice, which is fine. I want to be clear on that point. The sense that I've gotten of it is it's a great way to get started. It's a great way to continue running a thing you don't have to think about because you have a day job that isn't infrastructure management. And it is clear to, as your needs change, to either remain with the service or pivot to a very close service without a whole lot of retooling, which is key.

There's not much of a lock-in story to this, which I love. That was one of the key principles when we started to design CloudLine was, you know, we realized the industry had agreed that the container image was the standard for the deployment artifact of software. And so we made the early choice of focusing on deploying containers. Of course, we are helping users build those containers.

We have things called build packs. We can continuously deploy from GitHub. But at the end of the day, the thing that gets autoscaled on Cloud Run is a container. And that enables portability, as you said. You can literally run the same container, nothing proprietary in it. I want to be clear, like you are just listening on a port

for some incoming requests. Those requests can be HTTP requests, events. You know, we have products that can push events to Cloud Run, like EventArc or PubSub. And this same container, you can run it on your local machine. You can run it on Kubernetes. You can run it on Kubernetes. You can run it on another cloud. You are not locked in

in terms of API of the compute. We even went even above and beyond by having the Cloud Run API looks like a Kubernetes API. I think that was extra effort that we made. I'm not sure people care that much. But if you look at the Cloud on API, it is actually exactly looking like Kubernetes,

even if there is no Kubernetes at all under the hood. We just made it for portability because we wanted to address this concern of serverless, which was lock-in. Like when you use a function as a service product, you are worried that the architecture that you are going to develop around this product is going to be only working in this particular cloud provider.

And you're not in control of the language version that this provider has decided to offer you. You are not in control of more of the complexity that can come as you want to scan this code, as you want to move this code between staging and production or test this code. So containers are really helping with that. So I think we made the right choice

of this new artifact to build Cloud Run around the container artifact. And at the time when we launched, it was a little bit controversial because back in the day, 2018, 2019, serverless really meant functions as a service. So when we launched, we cut a little bit, redefined serverless. And we basically said serverless containers,

which at the time were two words that in the same sentence were incompatible. Like many people, including internally, had concerns around... The serverless versus container war was a big thing for a while. Everyone was on a different side of that divide. Containers are effectively, increasingly, and I know I'll get email for this and I don't even slightly care, they're a packaging format. Exactly. Where it solves the problem of how do I build this thing

to deploy on Debian instances and Ubuntu instances and God forbid Windows somewhere. You an instance in, God forbid, Windows somewhere, you throw a container over the wall, the end. DevOps is about breaking down the walls between dev and ops. That's why containers are here to make them silos that don't have to talk to each other. A container image is a glorified zip file.

Literally, you have a set of layers with files in them. And basically, we decided to adopt that artifact standard, but not the perceived complexity that existed at the time around containers. And so we basically merged containers with serverless to make something as easy to use as a function as a service product, but with the power of rigging your own container. And today we are seeing, you mentioned what kind of architecture would you use CloudOn for?

So I would say there are three big buckets. The obvious one is anything that is a website or an API serving public internet traffic, like your URL redirect service, right? This is, you have an API, it takes a request and returns a response. It can be a REST API, GraphQL API. We recently added support for WebSockets, which is pretty unique for a serverless offering to support natively WebSockets. So what I mean natively is my client can open a socket connection, a bi-directional socket connection with a given instance for up to one hour.

This is pretty unique for something that is as fully managed as Cloud Run. Right. As we recorded this, we are just coming off of Google I.O. And there were a number of announcements around Cloud One that were touching it because of, you know, strange marketing issues. I only found out that Google I.O. was a thing and featured Cloud stuff via Twitter at the time it was happening. What did you folks release around Cloud Run? Good question.

Actually, part of the Google I.O. developer keynote, I pitched a story around how Cloud Run helps developers. And the I.O. team liked this story, so we decided to include that story as part of the live developer keynote. So on stage, we announced Cloud Run Jobs. So, no, I talked to you about Cloud Run services, which can be used to expose an API, but also to do private microservice

to microservice communication, because Cloud Run services don't have to be public. And in that case, we support gRPC and a very strong security mechanism where only service A can invoke service B, for example. But Cloud on Jobs are about non-request-driven containers. So today, I mean, before Google I.O. a few days ago,

the only requirement that we imposed on your container image was that it started to listen for requests or events or GMPs. Web requests. It speaks. What would you want as long as it's HTTP? That was the only requirement we asked you to have on your container image.

And now we've changed that. Now, if you have a container that basically starts and executes to completion, you can deploy it on a Cloud Run job. So you would use Cloud Run jobs for daily batch jobs. And you have the same infrastructure. So on demand, you can go from zero to, I think for now, the maximum is 100 tasks in parallel. Of course, you can run many tasks in sequence, but in parallel, you can go from zero to 100 right away to run your daily batch job, daily admin job, data processing. But this is more in a batch mode than in a streaming mode.

If you would like to use a more streaming data processing, then a Cloud Run service would still be the best fit because you can literally push events to it and it will autoscale to handle any number of events that it receives. Do you find that the majority of your customers are using Cloud Run for one-off jobs that barely will get more than a single container, like my thing? Or do you find that they're doing massively parallel jobs? Where is the lion's share of developer and customer interest? It's both, actually. We have both individual developers, small startups, which really value the scale to zero and pay-per-use model of Cloud Run.

Your URL redirect service probably is staying below the free tier. And there are many, many, many users in your case. But at the same time, we have big, big, big customers who value the on-demand scalability of Cloud Run. And for these customers, of course, they will probably very likely not scale to zero, but they value the fact that we have a media company who uses Cloud Run for TV streaming. And when there is a soccer game somewhere in the world,

they have a big spike of usage of requests coming in to their Cloud Run service. And here they can trust the rapid scaling of Cloud Run. So they don't have to pre-provision things in advance to be able to serve that sudden traffic spike. But for those customers, Cloud Run is priced in a way so that if you know that you are going to consume a lot of Cloud Run CPU and memory, you can purchase committed use discounts, which will lower your bill overall

because you know you are going to spend $1 per hour on Cloud Run. Well, purchase a committed use discount because you will only spend 83 cents instead of $1. And also, Cloud Run comes with two pricing models. One, which is the default, which is the request-based pricing model, which is basically you only have CPU allocated to your container instances if you are processing at least one request. But as a consequence of that, you are not paying outside of the processing of those

requests. Those containers might stay up for you, warm, ready to receive new requests, but you are not paying for them. And so that is, you know, your URL redirect service is probably in that mode where, yes, when you haven't used it for a while, it will scale down to zero. But if you send one request to it, it will serve that request and then it will stay up for a while until it decides to scale down. But you, the user, only pays when you're processing this specific request. A little bit like a function as a service product. Scales to zero is one of those fundamental tenets of serverless that I think that companies calling something serverless

but it always charges you per hour anyway. Yeah, that doesn't work. Storage, let's be clear, is a separate matter entirely. I'm talking about compute. Even if your workload doesn't scale down to zero ever as a workload, that's fine. But if the workload does, you don't get to keep charging before it. Exactly. And so in that other mode where you decide to always have CPU allocated to your Cloud Run container instances, then you pay for the entire lifecycle of these container instances. You still benefit from the autoscaling of Cloud Run, but you will pay for the lifecycle.

And in that case, the price points are lower because you pay for a longer period of time. But that's more the price model that those bigger customers will take because at their scale, they basically always receive requests. So they are ready to pay always, basically.

I really want to thank you for taking the time to chat with me. Before you go, one last question that we'll be using as a teaser for the next episode that we record together. It seems like this is a full-time job, being the product manager on Cloud Run. But no, Google, contrary to popular opinion, does in fact still support 20% projects. What's yours? So I've been looking to work on Cloud Run since it was a prototype.

And for a long time, we've been iterating privately on Cloud Run, launching it, seeing it grow, seeing it adopted. It's great. It's my full-time job. But on Fridays, I still find the time to have a 20% project, which also had quite a bit of impact. And I work on some sustainability efforts for Google Cloud. And notably, we've released two things last year. The first one is that we are sharing some carbon characteristics of Google Cloud regions. So if you have seen those small leaves in the cloud console next to the regions that are emitting the less carbon. That's something that I helped bring to life.

And the second one, which is something quite big, is we are helping customers report and reduce their gross carbon emissions of their Google Cloud usage by providing an out-of-the-box reporting tool called Google Cloud Carbon Footprint. So that's something that I was able to bootstrap with a team a little bit on the side of my Cloud Run project. But I was very glad to see it launched by our CEO at the last Cloud Next conference.

And now it is a fully funded project. So we are very glad that we are able to help our customers better meet their sustainability goals themselves. And we will be talking about it significantly on the next episode. We're giving a teaser, not telling the whole story. I really want to thank you for being as generous with your time as you are. If people want to learn more, where can they find you? Well, if they want to learn more about Cloud Run,

we've talked about how simple was that name. It was obviously not simple to find this simple name, but the domain is https://cloud.run. We will also accept snark.cloud.run. I will take credit for that service too.

There we are. And then people can find me on Twitter at Steren, S-T-E-R-E-N. I'll be happy. I'm always happy to help developers get started or answer questions about Cloud Run.

And yeah, thank you for having me. As I said, you successfully deployed something in just a few minutes to Cloud Run. I would encourage the audience to... In spite of myself, I know I'm as surprised as anyone. The only snag I really hit was the fact that I was riding shotgun while we picked up my daughter from school and went through a dead zone. It's like, why is this thing not loading

in the Google Cloud console? Yeah, fix the cell network in my area, please. I'm impressed that you did all of that from an iPad. But yeah, to the audience, give Cloud Run a try. You can really get started connecting your GitHub repository or deploy your favorite container image. And we've worked very hard to ensure that usability was here. And we know we have pretty strong usability scores because that was a lot of work. Simplicity and product excellence and developer experience is a lot of work to get right.

And we are very proud of what we've achieved with Cloud Run and proud to see that the developer community has been very supportive and likes this product. I'm a big fan of what you've built. Well, of course, with links to all of that in the show notes, I just want to thank you again for being so generous with your time. And thanks again for building something that I think in many ways showcases the best of what Google Cloud has to offer. Thanks for the invite. We'll talk again soon. Staren Janani is a senior product manager at Google Cloud on Cloud Run.

I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice. If it's on YouTube, put the thumbs up and the subscribe buttons as well. But in the event that you hated it, also include an angry comment explaining why your 20% project is being a shithead on the internet. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

This has been a HumblePod production. Stay humble.