Latest / The MonkCast / Steren Giannini on Google Cloud Run: Past, Present & Future

Transcript

Steren Giannini on Google Cloud Run: Past, Present & Future · The MonkCast

• speaker-0: Hey, this is James Governor from Red Monk. I'm here ⁓ Sarah and Gennini ⁓ from Google Cloud. And the topic of conversation today is Google Cloud Run. ⁓ I think it's a really interesting platform. ⁓ you know, I actually rem remember when it was introduced. ⁓ and I thought to myself, you know what, I would really like a podcast which functions as a bit of a deep dive on the original design thinking and the engineering decisions behind. ⁓ cloud run. ⁓ and obviously we're a few years in now. ⁓ so the the you know what have we learned? ⁓ and you know I think one of the things that we do see at the moment in technology is of course ⁓ tech that may not have been built ⁓ with AI in mind may in fact prove to be rather useful ⁓ as we deploy ⁓ AI agent ⁓ and LLM workloads. So Stern, who are you? Who are you to tell us the story of Cloud Run? speaker-1: Hi James, thanks for having me. So I'm a director of product management at Google, but more importantly for that conversation, I'm one of the founders of Google CloudRam. One of the few people at the beginning who started to ask, hey, what could what if we brought serverless and containers together? Let's let's reimagine something from first principles. So yeah, I've been on this since 2017 and ⁓ leading the product. See S seeing it grow from a prototype to something that ⁓ Google Cloud really stood behind to something that is very popular today. speaker-0: And tell me a bit about that sort of those original design decisions. Like what were some of the reasons? I guess what do you think some of the re some of the choices you made, why have they led to longevity? Why have they led to being a product that sort of hit the mark and has shown consistent value over time? speaker-1: So first, that's an excellent question. And we have been, you know, I would say walking that fine line of opinionation. Like you want to be opinionated so that you make developers more productive. You offer a simple product, but you don't want to be too opinionated because otherwise you end up having opinions which might not fit the market. So CloudRun has been, you know, as an example. At the time when we designed CloudRun, it was all about serverless equal functions. We questioned that. We said, well, you know, what what are the what is the essence of serverless? Right? It's simplicity, scalability, cost efficiency, but it doesn't have to be functions. And at the time it was dominated by products like AWS Lambda and Google Cloud Functions. And we were, okay, let's let's stand back. Let's at the same time there was this thing called Kubernetes and containers happening. You know, hey, what if what if we'd we'd actually dis discarded the notion of serverless equal function and said, you know, let's let's accept any workload, any con any any containerized workload. Which is how Cloudern was originally born. It was, let's reinvent serverless, taking containers as the deployment primitive. So in a sense, we were not too opinionated regarding what you could deploy, but we were opinionated. regarding how simple it has to be, it had to be, and ⁓ you know, the the overall product experience. It was one command to deploy your container to Google Cloud, while ⁓ previously you had to think about clusters and and and and pods and things like that, ⁓ because there was only Kubernetes. So we were opinionated to make that simpler, both in terms of experience and in terms of runtime. ⁓ it's a hyperscalable runtime. At launch we did a demo where we went from zero to ten thousand containers in ten seconds. So that was an opinionated way to ⁓ scale containers at a scale where that we had rarely seen before for a container war runtime. And but at the same time being flexible. So on the design principles that we can still look up on my original document, you can see things like simplicity, but also openness. And at the time you really wanted to ⁓ address a big criticism of serverless, which was the lock in. Like we we we had been operating Google App Engine for quite a while since speaker-0: I was gonna ask about that. Because I I do think that's one of the questions, which is is that, you know, there there was some ⁓ there was some prior art and ⁓ you know, questions about how to get people to adopt a platform ⁓ of this kind, which takes so much of the manageability away, then where do you express that opinion that that that it that that the that allows the openness? I think that's really critical. Because we saw with you know, with App Engine or Elastic Beanstalk at at at AWS, ⁓ it's it's actually really difficult to get people on board with these the th this sort of ⁓ approach. So yeah, no, I'm really interested in that question. speaker-1: So it was it was open. We wanted to be open and portable. ⁓ because that's to address the big criticism we had heard on Google App Engine and later on Google Cloud Functions. ⁓ those two products required you to write your code in a certain way. Yeah. And when you adopted those products, you ⁓ adopted proprietary bespoke packaging format as well as APIs. So with Ploton, we took that from the beginning. We're one, we will be Like the industry seems to have converged towards the container image as the universal packaging format for software. Let's take that as as the as the core deployment artifact. And on top of that, we actually did two things which in retrospect were maybe nice to have, but we are very glad we have them. One is that the CloudRound API actually is compatible. With Kubernetes API, even though it is absolutely not implemented on top of Kubernetes. When when you look at it, when you look at a CloudRound YAML and you know Kubernetes, it looks a lot like Kubernetes. You have the same attributes, the same IPI structure, and the same way of being declarative and ⁓ you know and having a spec. so we did that also to enable portability. So that if you don't stay on CloudRound because you are locked in, you stay Because you can leave at any time, but you love it and you that's why you stay. So I think we delivered on that promise. we also had an open source strategy at the beginning, which really ⁓ helped at large create a very ⁓ strong narrative of openness. speaker-0: Tell me more about the open source strategy. speaker-1: Yeah, so we ⁓ based on on the success of projects like Kubernetes and ECO, in order to address the lock in ⁓ concern that we had heard of offering a severless product, we actually originally invested into something called Knative, which was an open source project that implemented the exact same API as Cloud Run, except that you could run it on your own cluster. So at launch we had Cloud Run implemented ⁓ on Bulk. It you know, it was ⁓ fully managed. Actually, it it it takes some technology from what we had developed from Google App Engine, Google Cloud Functions. And we had this version, and then we had an open source version called K-native. At launch, they implemented the exact same feature set that you could deploy on Google Kubernetes engine, but also as we've demoed. on other clouds, on your own clusters. So that that kind of alleviated the lock in concern from the start. First containers, which you know, honestly, the fact that we took containers probably gave us like eighty percent of the portability. Right. Because the the control plane, the API is not the hard thing to translate, especially now you can just ask an AI to translate like your cloud run to a Terraform config, for example. But ⁓ at the time, like the The container already gave us 80% of the portability, and then you add the additional, like I would say, ⁓ 15% thanks to the API portability as well as the ⁓ open source project. ⁓ but to be very clear, Google Cloud Run is not running this open source project, K-native. Google Cloud Run is not running on a on a managed Kubernetes cluster. It is actually running on a highly efficient multi-tenant serverless infrastructure which Takes its roots from App Engine, which was evolved in order to create Google Cloud Functions. And the story is interesting because when I joined the team, we just had launched Google Cloud Functions. And and I realized, hold on, we have because to achieve that launch, we we we we we actually built a technology that allowed us to run ⁓ unmodified runtimes. ⁓ in ⁓ in our serverless infrastructure. Because back in the day of App Engine, we had to, for every Python version we wanted to release, we had to modify it so that it was securely isolating customers' applications. We went into a fundamental investment to be able to run any ⁓ runtime. So that's why Cloud Functions, when it launched, had Node, but quickly later added Java, Ruby, Python. And That technology actually is a technology that was developed to cr to run any container, but we were only using it to run functions in a set of languages. So when I joined the team and when when we saw that, we were ⁓ what if? What if we actually leveraged that technology to fundamentally offer a container product, container first product? ⁓ so that that was the foundation. At the time, Cloudon was very simple. ⁓ you could Only deploy a container, you probably couldn't even pick the number of CPU and RAM. And at launch we launch in one region while today we are in fifty and you have many, many other options. But this simplicity allowed us to focus ⁓ on on delivering a well crafted product. Because that's something else we we can probably talk about. Is the like yes, we had principles like openness and ⁓ simplicity, but like it's really like There are a lot a lot more design principles that went into CloudRun. You know, we wanted it to be well crafted. We wanted it to be consistent across its surfaces. So if you use YAML CLI UI, you can access the same features. And a lot of product design went into how do we keep common use cases extremely simple. And for the least common use cases, the ones that are more advanced, potentially the more enterprisey ones, how do we allow ourselves to ⁓ to have more clicks, more commands? But definitely the the eighty percent of the use cases had to be very simple. So that's why it was one command to deploy your container at launch. speaker-0: Were there any other from that design perspective, were there what were there any sort of touchstones around perhaps other products that you thought had done it well? or you or or you know, ⁓ maybe not even in maybe not even in tech, you know, maybe it was or at least not in enterprise or cloud technology, you know. There there might be yeah, I'm interested, were there any sort of like wouldn't it be great if it could offer this kind of experience? speaker-1: Yeah, I mean I I think in terms of design principle, that goes beyond tech. Like what one one principle I like to use is progressive complexity. Where y when you learn about something, the cognitive load should be as low as possible. And it should be as familiar as possible so that you can you can start onboarding onto it. so th that's ⁓ a nice an interesting ⁓ story for people is Or in the early days of Cloudrun and Knative, we did not have this obvious CloudRun service object. It was actually a much more complex resource model. And then we realized, no, like we we need to simplify, we need people to think about one box instead of having to think about three three boxes. Like there was like many, many complex boxes. Like when you adopt Kubernetes, like you have to learn about what is a deployment, what is a pod, what is a speaker-0: The first thing you have to do is learn a lot. ⁓ speaker-1: Exactly. So for us we wanted to address that progressive complexity where you you don't have to learn anything. The thing that you learn the only thing you have to learn, you are ideally already familiar with it, and you just give it one thing, which was one container, and then you're good to go. So that was the one egg one example of a design ⁓ principle that is not even coming from tech. Like you can apply progressive complexity ⁓ to every kind of product design. But I think for from tech, I wanna I wanna give shout-out to a products like Heroku. Obviously we are still we are still in admiration about how good Heroku was. Like 'cause it's probably like more than ten years now, but like it it really nailed this radical ⁓ simple developer experience. That was really ⁓ that's another ⁓ key principle that we used across the the design process was idiomatic. So what does idiomatic mean? It means we preferred to embrace developer standards. Than to invent or impose our own. So we prefer to embrace containers rather than to ask people to use our own packaging format. We prefer to embrace, like if you deploy Node.js, we are not going to be asking you to use our own config file. We are just going to be asking you to give us a package.json. So we try to apply this across the board. For every thing we want to introduce, like recently, much later, we introduced .env support. Because of course if you want to declare your environment variables, that should be.env. There's no question about that. Right? But at launch we ⁓ we did not have this and we quickly added it later because it it's clearly one of those idiomatic developer standards. So there is like being idiomatic, and and here I think Heroku was extremely idiomatic with with their support of Git push, right? This is so so nice. By the way, this I never said that to anyone, but ⁓ this is something only for you, James. I wanted the CloudRun. ⁓ developer experience to be Docker push cloud dot run slash my project slash my service. It would have been so nice, right? To not even have a a a CLI, but to use the Docker CLI. The same way Heroku used the Git CLI ⁓ to deploy. speaker-0: It w it ⁓ certainly from the Heroku standpoint, ⁓ I mean you know, it's the extent that as I I've said this to people, the first the first time I saw Heroku, I didn't understand when ⁓ well, I I I was working with a ⁓ the the team that was building Doppler at the time, I think. And and I d I honestly didn't understand that A deployment had happened. Because d ⁓ in my mind I was still like waiting for the next step and it had already been done with the push. And I think that was just really profound. speaker-1: I remember feeling the same. Yes, it was such a nice design that yeah, the same way you push your code to a branch, you would you would you would you would use the same ⁓ like to to to just like store your code repos in a repository, you would use the same action to deploy. That was kind of this beautiful moment. Of cour of course Eroku ended up ⁓ implementing ⁓ a deployment API later as well as a command line. But I think fundamentally taking this ⁓ idiomatic principle ⁓ to the extreme. with git push to deploy, which we added ⁓ very quickly after to cloud and to ⁓ you could ⁓ not at launch at launch we were again focusing on a minimal viable product in order to deliver a well-crafted ⁓ product and no bug and but we later introduced ⁓ this ⁓ connecting a git repository so that when you push to you a given branch it deploys. but by the way if you are curious about this ⁓ How did we focus? We really ⁓ I remember originally we had a big, big plan for what CloudRun should be at launch. Because the idea was it was supposed to be what cloud functions did plus containers. And so that meant we had to support the entire scope of cloud functions, which had events and which had support for languages, not only like with no Docker files so that you don't even have to think about containers. But ⁓ we quickly realized okay that was a big, big scope. And in order for us to to really deliver something that people would would love at launch, we had to to cut the scope. So really we we really cut a lot and and I think that was the right move because when you when you focus, you can actually spend more time on the quality. And we we spent like probably when we launched in ⁓ publicly in April twenty nineteen. We had been already ⁓ working with internal ⁓ with with testers, external testers for almost a year who helped us shape the product and you know identify issue. I'm s you said you were ⁓ following CloudRun since the launch. I I'm sad I did I did not invite you to that trusted tester ⁓ list because we have people from that time who are still like following and ad and evalu advantagizing CloudRun today. ⁓ and they are one of our Every every every Cloud Next I'm very happy to meet the the people who helped us shape CloudRun when it was still in private preview. speaker-0: Yeah, no, that's That's certainly an amazing feeling and I'm sure a lot I mean, they're still on the platform, right? the speaker-1: Yeah, most of them ⁓ really love it and even brought them into their companies, changed companies, so brought them into their other companies. So it's it you know, when Cloud On is is at the top of Google Cloud satisfaction numbers, this is something we've been communicating already about. for speaker-0: About that a little bit because you know, I I I was at a Google event recently and obviously in a company, you know, I was at at Cloud Next and with so many things to talk about in the agent world, ⁓ I was like, Come on, I I want some cloud run, you know, I could do with some cloud run cheerleading. So maybe talk a bit about ⁓ yeah, that the yeah, I'd I'd love to I'd love for you to go into that a little bit. speaker-1: So we you know, when you use the Cloud Console, the Google Cloud Console, you have those small pop-ups that pop up asking you how would you recommend this product to a friend and like how satisfied are you? So these are the satisfaction surveys that we run across the entire console. They also show up in the docs and everywhere. So every month we we look at where Cloud on stands. ⁓ so like satisfaction scores, NPS. And for for years now we've been we've been like like very, very high scores and you know usually ⁓ around around the top of of of GCP services ⁓ sorted by satisfaction. You know, and when you browse like developer forums or Reddit, like you Cloud is one of those those products that is often called out as why people love Google Cloud. Like of course BigQuery is another one. Like BigQuery is amazing. ⁓ and I by the way, I was using the internal version of BigQuery like way before it was ⁓ launched and and I was very glad that it came to the world because this is such a ⁓ a delightful product too. So those products are often called out as why people come to Google Cloud, why they love Google Cloud. And both of those products have it a bit the same characteristics. Like BigQuery is this amazing serverless you know data ⁓ analysis ⁓ product. ⁓ you can process like terabytes of data without even ⁓ blinking an eye, like while in the past this would have been a nightmare to do. And and in the the same way Cloudon is this ⁓ on demand ⁓ runtime to scale applications or agents, right? And ⁓ they they both have a very simple main value proposition, but such a powerful value proposition. speaker-0: Okay, okay. Having said, you know, the agents got all the love at Cloud Next, now you've you've you said the word, and I think I said a a bit about this at the beginning of ⁓ the podcast. ⁓ tell me a bit about that. You know, what we what was your reaction as and and well there we'll we'll do this and then we will talk a bit. What we haven't done is really talk about the s success of the platform. We we could we'll we'll table that one a bit. But tell me about As as agents began to take off, w at what point did you sort of internalize that some of the I guess the primitives that you chosen were going to be so relevant and why Cloud Run was going to be an applicable platform? And then when did you actually begin to see see that in market adoption? speaker-1: So that I would say two years ago I was on stage with the Langchain founder, Harrison Chase, because we had realized that he had built an amazing ⁓ at the time we did not even tell we didn't use the term agent. So the market has evolved regarding its its its definition and perception of agents. But like two years ago already, at CloudNext twenty ⁓ fourteen. I would say I was with Harrison Chase, founder of Langchain, telling the world how easy it was to deploy your Langchain app to CloudRun. And he was the one telling the world l CloudRun is the easiest place to deploy your Langchain app. At the time we we had saying Langchain app because we did not qualify this as agents. Because those things at the time were mainly mostly chat interfaces with very synchronous agents, not a not a lot not that much thinking. We were starting to see rag like retrieval augmented generation where you use a database to inject more context into your prompt. But that was it. So at the time, CloudDon an obvious choice to deploy Langchain because Langchain looked a lot like a web server. And CloudRun has been shining in deploying on demand, you know, web APIs, web servers. So that's when we found an extremely good fit already y two years ago. ⁓ a year later, ⁓ I came back on stage with Harrison, but this time the landscape had evolved a little bit. It was not Langchain anymore, it was Lang Graph. Because now those agents became more complex and they were using tools, right? They were doing a little bit more thinking, they were storing memories. So again, Lang Graph was a good fit to deploy to Cloudline, and we we were seeing people. Coming to Clun, so we started to document the use case. ⁓ and we were on the look for what we need to change. speaker-0: Just a just a a little pin in there, because at this point wasn't there a bit a bit more of a need for that complexity? Because once people are making decisions about memory or there there's less the opinion does the opinion need to change? or yeah, how do you offer the out of the box experience in that environment where it's a slightly different set of constraints and designs from the the user's perspective? speaker-1: So this is where I can tie back to what I said earlier about we are walking a fine line in opinionation. Because you want to have some opinions, but not too strong opinions, especially in a market and in a landscape that changes so quickly like agentic workloads. Because the opinions that we would have had a year ago about what an agent product should be would actually be very different from what an agent product should be today. And so fast forward to today. What you need to give your agent is is is a computing environment where it can run ⁓ command lines and it can manipulate files. Like a year ago, that was not on our radar. But we started to see the need for sandboxes. And so we started to tell the story that CloudRun has been sandboxing your workloads from the beginning, and consequently you could exec start to execute ⁓ untrusted code, especially if you were to use CloudRun jobs, and we had customers running long-running untrusted. environment in CloudRun jobs. But my point to ⁓ to your question is we we we were on the look for how should Cloudrun evolve, but we were not willing to go all in on being too opinionated about how to do agents because those opinions quickly become obsolete. Yes. And I must say, and CloudNext twenty seventeen ⁓ sorry ⁓ twenty fifteen and twenty sixteen was all about ⁓ agent platform. Like to this year was all about agent platform. So Google Cloud was also introducing its agent platform. Already a year ago it was called Vertex Agent Engine. And in a sense, Google Cloud was already offering a very opinionated agent runtime. So CloudRun being less opinionated, CloudRun being more of a compute runtime where you can run a lot of workloads like websites, web APIs. Agents became another type of workloads for us. While for products like Vertex Agent Engine, later renamed ⁓ agent platform runtime, for that product it it was specifically designed for agent workloads. So they could they could have stronger opinions for what the product should be. And internally those two things share ⁓ some technology, yes. speaker-0: Okay. But they're they're ⁓ yes. Okay. So and do you I mean, that's an interesting one. In that case, I mean, well might all the agents move over to the I mean I I think that's a bit of another but w might you see less agent ⁓ deployments to Cloud Run because you've got an agent specific platform also available from Google Cloud, or do you not see the world in that way? speaker-1: At the end of the day, it's Google Cloud, which is, you know, all that matters to to me. and the and the the two teams collaborate a lot. As I said, technically there's a lot of infrastructure shared. so i we I would say we don't want to as as a Google Cloud platform, we don't want to offer a single option. The same way if you wanted to run your container, you could you could You could you could use Kubernetes engine. You could use Cloud Run. And you know, the two platforms have been very successful in their own ways. And it's all about some customers will find it perfect to use a Gemini Enterprise Agent Platform. Some others, maybe the ones who are coming from a more developer angle, they they want something that is more designed for developers, being idiomatic to developers more than agent builders. So they will know they will know what a container is. They will they will be thinking in terms of you know CPU and and and RAM or maybe they will even want to have GPUs for several AI inference next to their AI agents. So for for for maybe the the more developer ⁓ centric ⁓ audience, ⁓ they will they will they will gravitate, they tend to gravitate towards CloudRam because it speaks their their language. speaker-0: Well, I mean if you build something that's idiomatic, then people that know the idiom are g more likely to wanna adopt it, right? So that ⁓ I speaker-1: Yes, yes. But you know, we we are still on the look for how to evolve CloudRun. And this year we've been investing into quite some evolutions because I think there has been this jump into what agents ⁓ are ⁓ over the last year. And so for example, we are launching CloudRun sandboxes from like if your agents need to execute in under like ⁓ five hundred millisecond untrusted code, it can do it in can do so very very idiomatically now ⁓ from the code. We are, you know, there's you you have heard of OpenCloud, right? So everybody buying ⁓ Mac minis or or VMs or local computers to to run a long running, always on background agent. So that kind of workload was not a good fit for CloudRun, ⁓ for the CloudRun of twenty nineteen. And actually we've now evolved CloudRun To support that kind of workload. We we have introduced the CloudRun instance. It's an always-on cheaper ⁓ resource where you can deploy OpenCloud in one command. And it is designed for this kind of long-running ⁓ background agents that need a sandbox and a file system to perform their work. But you know, who knows what agents will be or what they will need in the upcoming years. So that's why we are always on the look for How CloudRun should evolve. What primitive do we need to add to that developer friendly container runtime so that they can the agent builders can deploy agents. Yes. speaker-0: Tell me a bit ⁓ this is a slight change of gear. ⁓ and we can maybe get to the future of agents, we can come back to that as well, but like you mentioned Langchain. ⁓ I mean have you got any other any other AI companies that that you could talk about that are using ⁓ cloud run? speaker-1: Yes, so there are some I cannot talk about, but there are some I can talk about and notably two of them I should call out. One is maybe you might have heard of them called Anthropic. And so Anthropic has been leveraging CloudRun for its high scalability. So basically every prompt you send to Cloud is somehow going through CloudRun. And as you might imagine, the traffic is one enormous and two highly variable. depending on the time of the day, they will see traffic that that that really changes. So that's that's why they they really value CloudRun scalability on demand. I don't think Anthropic scales to zero, right? But a a developer would scale would care about scale to zero, but Anthropic cares about the fast scaling and the on demand compute that CloudRun offers, as well as the pay per use nature of CloudRun, because during during the night when the traffic goes down, you know, they they they have way less usage than during when when it's peak and in that case the the bill becomes lower. so Anthropic was with us on stage this year to call out ⁓ how Cloudon has a lot of benefits for them. You know, very low ⁓ maintenance. ⁓ it's really like they optimize for speed and Cloudon allows them to go fast. Like they have less things to worry about, less infrastructure to manage. And and it you know in in this environment what matters is velocity. And as a consequence, they they are ready to to lever to to to delegate a lot of the operations to Google when when they use CloudRun. And I would say another company which has an AI agent, it's Repelit. So Repelit, if in case ⁓ you don't know, I'm sure you do, but maybe the audience doesn't know. So ⁓ it has been extremely successful among ⁓ developers and even students To create ⁓ applications and and the Repolit agent is helping them create applications, this area of vibe coding, if you want. And so it turns out that when you when you deploy your app from Repelit, ⁓ under the hood, it deploys to CloudRun. And so this has been quite ⁓ successful. ⁓ there a year ago, the Repolit ⁓ founder ⁓ tweeted a chart which was really showing an exponential curve. And it was ⁓ I think a year ago it was like hundred fifty K. ⁓ no, he had hidden the the Y axis, but the the number was publicly disclosed ⁓ at CloneX a year ago, it was 150k applications. This year, Scott, VP of Engineering, shared the same chart, meaning the exponential, you know, was still an exponential at a very different scale because now the number of applications was a million. So who knows where we will be ⁓ in a year, right? ⁓ But ⁓ definitely from the CloudRun side, maybe that leads into the success of the platform, we've been seeing ⁓ a drastic ⁓ increase in the number of deployments and the number of accounts using CloudRun. Like a metric that we we have shared is that we've doubled our number of active accounts and our number of deployed applications over the last year. So considering the product was already quite For some time in the market, you know, doubling your numbers, you know, is is quite something. And it's not stopping. The curves are all looking exponential. And so for us, it has led us to ⁓ really like double down on making sure we can scale like some parts of our system, needing like we you don't see that as a as a customer or or developer, of course, but CloudRun systems had to ⁓ evolve to handle the success of CloudRun. And it's it's it's currently ongoing. speaker-0: Tell me a bit about that, because I I think that as an industry at the moment, we're we're kind of creaking at the seams a little bit. ⁓ the the we you know, we were not built for the load that that agents are creating. ⁓ you know, we we've we've as as as GitHub has publicly attested, ⁓ traffic patterns are making things a bit of a struggle. ⁓ but ac across the board, I mean, we've got Sort of 10x, 100x, ⁓ possibly 1000x ⁓ scale requirements coming in because of the amount of software, well, partly that agents are building, ⁓ but certainly the number of events that they're generating. ⁓ and also I think one of the other things is of course, some of these are long running. A lot of them are ephemeral workloads, but but the The the sheer scale, I think as an industry, we it reminds me of maybe ⁓ maybe even the olden days, actually, sort of the the early days of sort of e-business when the internet came came along and initially it it's a catalog. Well, once it started driving transactions and self-service transactions to those back ends of banks, retailers, ⁓ you know, the web companies. speaker-1: Yeah. speaker-0: The the the the just the sheer scale was not something we built for. So what are you doing to accommodate for that? And what sort of a as you say, you know, we're we're like, wow, Clobron seems to be doing a good job of this, but I'm assuming it's it's it's certainly at at times it's gotta be all hands on deck in order to do what are there any significant architectural changes you're gonna have to make to deal with the scale that agents are putting on the network? speaker-1: The good news is that we were designed for this. We've been waiting for that moment for years. And we are riding the wave. We are f fueling the fire, actually. ⁓ we we've partnered with A Google AI Studio, an amazing vibe coding platform. And you know what? Right now, if you try it and you wanna deploy it to CloudRen, you don't even need to put your credit card anymore. Click deploy, boom, you have your URL deployed to CloudRen. That's gonna be announced tomorrow at Google IO, but it's already rolled out right now if you give it a try. And and so like we are we are looking for troubles, right? Instead of instead of blocking access, we are actually like lowering the barrier to entry. Because yes, vibe coders, they don't want to create a Google Cloud project. They don't want to think about enabling APIs. They you know they they don't want to think about containers, of course not. So that's why Cloud has also evolved to be even more simpler. for them. But we are we are really ⁓ doubling down on that because fundamentally we were designed for it. So our infrastructure is not VM based, you know, when when a when an application scales to zero, we have low no cost on the Google side. So what that means that we have been designed for for this massive scale of very low usage or long tail ⁓ applications. Of course Over the the the lifespan of CloudRun, you know, we we launched and when we we we spent years to become enterprise ready. So I don't wanna dismiss the fact that a lot of enterprises are on CloudRun. Like another customer is like Ford. ⁓ Ford has been ramping up on CloudRun, migrating thousands of services and they're extremely ⁓ happy now and we've designed for them a lot of enterprise features. We've worked on being able to support more legacy you know, ⁓ Java frameworks, for example, that were taking us some time to start. But and and so we we we've checked the enterprise box, I would say. And just at the right time, we saw the rise of vibecoders and AI agents. AI agents also deploying to CloudN. And so we we decided to to double down on that and and and empower vibecoders, empower AI agents to deploy. And yes, we had to make Basically capacity, of course. Like we have to we had like crowding has grown so much that now we have to to do ⁓ capacity planning at the scale of the of the data center, right? It it starts to become so big that we we we plan alongside our compute engine or Kubernetes engine colleagues. But also some parts of the systems that maybe we're not assuming you know that ⁓ that scale of number of deployments per minute or more importantly number of ⁓ of resource in a given region. So those are the systems that we had to evolve, but you it it's software engineering. We we we we know ⁓ when those systems will find their limits. So we we invest early on to lift those limits and and so far so good. ⁓ We of course as we allow people to deploy without a credit card, we we had along the way the need to prevent abuse. speaker-0: I was gonna say that just sounds like an absolute nightmare to me, right? speaker-1: We we're ready for it because as you know, you know, if you allow people like CloudDon always had had a free tier, right? So you could always deploy your side project to Cloud on and not pay anything. And of course when you do that, like people will s will will will try to abuse it. Or they will and so we we've been investing years ago into abuse prevention mechanisms. We can detect Bitcoin mining which are against Google Cloud stands of services, and we can more importantly protect customers. from each other. And you know, we've we've added limits into the product that we are not here at the beginning. You know, when and and and those limits are also very useful for ⁓ for developers. Right? In when we launched CloudRun, we we had a cap of like ⁓ a thousand containers maximum per service. And it turns out that can be quite costly if suddenly you you your app goes viral and and it scales to a very large amount of containers. So what we did was we we actually lowered those those default values, but also we've put quotas in place so that by default you might not want to scale to like 10,000 containers. And if you want to, you can just in one click get more quota. And and what we what was really resonating with the crowd this year was that we are going one step ⁓ further by introducing spend caps. So finally, developers will be able to tell us. I don't want to spend more than X dollars on CloudRunner. And very soon later, I don't want to spend more than X dollars on GCP on Google Cloud Platform. And when you reach that that limit, your CloudRunner resource gets get posed. So it's your choice. Either you you you you decide to to bump the limit and and you can resume your serving your traffic, or you prefer to to to to cap your bill and therefore your your containers and workloads are posed. So that That was ⁓ very well received. it's it's it's it's launching later this summer. And because we you know we've all has have heard those stories of ⁓ no serverless where the function recursively calls itself and like in just by the time your billing alert comes in, you already have writed a large bill. So hopefully we didn't we did not have that many of these in Cloud One because as I said, there was nothing like infinite capacity, infinite limit. We we made it clear from the beginning that There was a limit. And this limit we actually lowered it over time because we realized most people did not need to scale to very high scale by default. And we preferred them to opt into it rather than to ⁓ discover it ⁓ with a bad surprise. But hopefully with spend caps, it goes one step further where you can just say, cap my bill. So ⁓ yeah, a lot of ⁓ I I must say over the past probably ⁓ two years, we've really concluded that we had delivered most enterprise features that we are blocking top enterprises customers and and the business was go doing extremely well. And we were we we were like a a little bit refocusing towards the developer audience. speaker-0: Before we go go on to that, what I mean, I think we all know what enterprisey features are, but what were some of the enterprise features that you've removed blockers that have been valuable, that you found the likes of Ford or others are getting the most value out of? What what have you what have you had to add? speaker-1: I mean, ⁓ when we launched CloudRun, we did not have two things like that in retrospect were big, big gaps. So one was V P C connectivity. Like, you know, those enterprise customers they have workloads, ⁓ virtual machines existing, they even have on prem resources that they want to connect to. So the way to do that is to connect to a V P C Virtual Private Cloud. So we we we really ⁓ delivered that that whole networking. So most of those enterprise features are around security or networking or compliance. So like security, you know, we have things like threat detection. You can you can do ⁓ you can bring your own encryption keys. ⁓ like there are things like access and transparency where ⁓ w when Google Cloud ⁓ support or engineer want to ⁓ help you and ⁓ you know diagnose an issue, like you can that leaves a trace, of course, but can even approve. And there are so many things like that that we we had to deliver and also integrate as part of the horizontal Google Cloud Platform. Organization policies, like customers can now define custom policies for what they allow to be deployed on Cloud One. So for example, if a customer does not want ⁓ their developers to create public applications, they can block that. Which was not the case at the beginning. So they can say, you know, yeah, every cloud and service must be protected by ⁓ an ⁓ an IAM check. It cannot be public on the internet. So those kind of things were ⁓ a long, long list of features we had to build. And I think I mentioned that two two big things. One was VPC connectivity, but another one was all of the integration with ⁓ the Google Cloud application load balancers, the internal load balancers, external load balancers. Because Most enterprises are not just ⁓ publishing like one website under one domain. Like they have a very complex routing mechanism for their ⁓ or even internal ⁓ routing and and and load balancing mechanisms. So we we had to integrate with all that. A lot of things. A lot of things that we we delivered and then at at this point I'm not aware of of of big enterprise blockers. speaker-0: So and I mean that's a whole conversation. You mentioned Ford. I'm sure there are a load of other interesting use cases, but you wanted to talk there a bit about your sort of ⁓ refocusing on on developer. So where where are you on that journey? What how do you how do you make sure that you're meeting the the latest idioms? What are you what are you doing from a developer perspective? speaker-1: I think it's also that ⁓ it's not only developers anymore who deploy to CloudRun. It's also AI agents. And by that I mean the ⁓ notably the the coding agents, which once they have helped you go ⁓ code your application, they can also help you deploy. So for that, for example, we've we've invested like a year ago I I launched ⁓ the CloudRun unofficial MCP server. Which I I wrote myself because I was reading the MCP spectral MCP's model context protocol, which ⁓ has at the time ⁓ was emerging as a s as a standard for how agents can ⁓ consume can can use tools. And so we we were the probably one of the first Google Cloud service to have ⁓ an MCP server and we demonstrated how you can c connect it to Gemini CLI cloud, ⁓ cloud code. ⁓ but then then we actually this was an open source project that you have to you had to install on your local machine. Then we invested into a fundamental platform ⁓ layer to ⁓ offer fully managed, secure and remote MCP servers for many Google Cloud services. And CloudN ⁓ in the first wave of services which launched a fully managed remote MCP server. So that's one example of something that we had to ⁓ deliver to empower not developers but through agents. speaker-0: Agent experience as opposed to speaker-1: And of course, you know, it's developers too because ⁓ yeah, like IDEs support MCPs, ⁓ the MCP ⁓ standards. So then you can ⁓ from VS Code you could deploy to CloudRun just by connecting the MCP, which was fully fully managed and remote. but I mean I I think our our our our focus to developers has always been here, but at one point we had to invest into being enterprise features and now that we believe we have most of them, it was a good time to refocus on making a An even simpler product. And because ⁓ another example is ⁓ of of investment is being compatible with more ⁓ package manager. So not a beyond the Python ecosystem. So yes, of course, you can deploy a container. And you could ⁓ do that from day one. Then we added support for deploying from source code with no Docker file. And in that case, what we do is we use ⁓ technology called build packs to detect what what language is your application using? And we know we have builders for each of those languages and we have ⁓ like runtime. Once you once we've built the app, we have runtime that include, for example, the Python runtime. And those runtimes, by the way, are automatically updated for you. ⁓ with no deployment required on your end, which is something that ⁓ also enterprises value a lot because it it automatically patches the security issues from the runtime. But If we take the example of the Python runtime, it was only supporting requirement.txt. So, you know, like maybe five years ago that was fine, but two years ago or one year ago it wasn't. Like the Python ecosystem had evolved. It was now converging towards like ⁓ pyproject.thermal, and so other ways to declare your dependencies, other ways to to declare your apps. So that was one concrete example of things we observed. And we decided to add support for it in in our Python build packs. And I I must say, right now ⁓ an interesting challenge has been as CloudN delivered those enterprise features, as CloudN delivered features in general, we have to constantly fight entropy. Because what started as an extremely simple product with literally one input field, which was container image. Has now grown into something that supports volume mounts and sidecars and and GPUs and and and tons of networking and security options. And so I must say as a as a product leader for that organization, now my my role is to make sure we when we we are we have a cohesion in terms of experience because like now we have a lot of people working on different aspects of cloud and so they all need to to deliver something that is consistent, but two, to constantly think about simplifying what if we don't pay attention to that, what could become c more and more complex over time. So an example was when you wanted to mount a speaker-0: Do you just do you do you like sit there with the original design docs and occasionally say to the team, Don't don't make me tap the sign? speaker-1: Yes, yes. Yeah, and literally I I I often refer back to it. I literally have it open now and it says common use cases should ease should be easy and facilitated. More rare use cases can require more UI or CLI manipulation. And so like this is something that I always tell the team, yeah, you know, when you design something, think about what most of your users will want to do with it and make that simple. And now the most advanced user, the more advanced use case, it's okay if you need more flags to the command line. It's okay if you need to go down into a config file to achieve the use case. A great example was cloud storage volumes. So you can simply mount cloud storage into your cloud owner resource and they appear as a file system. So amazing because cloud storage is such a strong storage product from Google Cloud. But when we launched this, we defined it as a volume and then you had to mount the volume in a different place because well yeah because now Cloud and supported sidecar containers so maybe you wanted to define one volume that you wanted to mount in two different places in two different containers. But again most of the time users only have one container and they just want to mount that bucket at a certain place. So we ended up even if we launched with a quite complex UI and CLI, we ended up simplifying all that. So that at in command line is dash dash volume type equal cloud storage bucket equal my bucket. And that's it. That's all you need. While you know, the original design was way more complex. So that's one example of simplifying an existing product. speaker-0: Yeah, that's great. I I mean and it actually that's sort of puts me in mind of ⁓ it it it's not exactly the the the same use case, but I was talking to Andy Goodmans, ⁓ obviously one of the senior leaders ⁓ at at Google Cloud, who runs the data and storage businesses, ⁓ which is a lot. speaker-1: Did Andy tell you he's also taking care of deprecations at Google Cloud? speaker-0: He's taking care of deprecations. speaker-1: Yeah, th just this is a side note, but Andy created something called the deprecation council that I belong to. ⁓ like the senior leaders belong to that council to make sure that we respect our customers. And f and you know, f we are pushing back on like when teams want to deprecate something, you know, we are sometimes pushing back on the deprecation itself. But if we agree about like we we had we guide them to make it as good experienced as possible, as respectful to our customers. And I'm calling that out because Andy is ⁓ has been the the founder of of this ⁓ of this effort. So he's not only doing database, he's also in maybe maybe this is internal only, but you know, so be it. He's also taking care of ⁓ deprecations and ⁓ and I'm I'm not part of the team too. speaker-0: So what is super interesting to me about that is one of the conversations that I had with him at Cloud Next, or about the conversation I had with him, the thing that really struck me, and I I came away with this was that, you know, we're now in an environment where Because you do need to gestin your priors, because the use cases change so dramatically, ⁓ because new capabilities emerge, you know, if you think about the the the the well, you know, Gemini now as opposed to where it was and how much we can rely on it. Certainly we've seen that, I think, with all of the frontier models. There's been a huge amount of of ⁓ development. So things that you thought you couldn't do. with agents, it turns out now you can. Or things you couldn't, you know, do with models. He the point he was making was that that that the you know he's making product plans and then less than a year later realizing that they need to change and that something is going to need to be rebuilt. And it may have some slightly different design principles. And there is going to be more change. And of course I think what's really interesting in what you've just raised is is is historically at least, look, I mean it's a meme, you know, told by Google. That is a thing that that people, you know, ⁓ can I rely on this service because it might it might, you know, it might go away. Very interesting that Andy, who had made this point that actually now Google is hacking, say, hang on a minute, you you may need to start again less than a year, less than a year into the product. in order to ensure that it's engineered for the right use cases. That actually he's running the that that council, I think very useful. And ⁓ yeah, that's a a really interesting ⁓ speaker-1: But what you said, mean ⁓ APIs are forever, C L I's are forever. So that's that's one of the design principle of Cloud Run. Like when when we as soon as we go public preview, we know that the thing will be forever. So that's why we we have this tendency of spending a lot of time in private preview because when your customers are on a l under an allow list and when you have their emails and when they have signed up for things to be ⁓ to have early access, they are okay if you introduce a breaking change. Once you go public, you can't. And the CloudN V1 API has like full backward compatibility, the CloudN command line, full backward compatibility. And yes, there are some things, there are some designs that we regret. If we had to do it again, we would do it differently. But we just don't. Because we want to r respect the the countless of CI C D pipelines that depend on that API or depend on that command line. And we must retain backward compatibility. Yeah, I think that's so we pay a lot of attention to that. Across Google Cloud, not only cloudal to be clear. speaker-0: Okay. Yeah, that need for consistency, ⁓ super important. As you say, you can't break everyone's pipelines. Okay, so that's that that's honestly that's yeah another thing for me to sit here thinking about stuff that Andy's doing, the ⁓ the deprecation council. I think that's ⁓ good and important. You know, you need a representative of of the customer that, you know, constantly thinking about, well, you know, things are gonna change, but how do we manage that process? ⁓ Can I ask you just a sort of a general question? I mean, Google is it's pretty good at security, we know that. ⁓ you know, you you've you mentioned you know being able to run untrusted ⁓ environments before. I mean, I'm interested in is there have we crossed a sort of a a Rubicon now from an agent security perspective? And are there new challenges that you really think you've got to nail down for? We've talked about the the requirements of scale. I sort of feel like security I just feel like we're a bit ⁓ we're at the sort of the gray goo period of security. There don't seem to be many things we can rely on. So what are you doing to ensure that that Cloud Run doesn't become ⁓ a vector for attacks that are successful? speaker-1: So I think this is the same way we were designed for that kind of large long tail scale. We were also designed for those untrusted workloads. Because from the start, originally we were using ⁓ so we when we launched your containers were sandboxed in in a in a sandbox technology called Gvisor. ⁓ there is two layers of sandboxing. Like this is the first one, the second one is another layer. ⁓ we've we've since then introduced another sandbox. It's a micro VM sandbox. Okay. Again, two layers of sandboxing. But that's just one thing to know is that well on on other runtimes, your containers are not sandboxed between each other, right? So while on CloudM always have been. So that's one way to okay, if if one of them gets compromised, it cannot escape ⁓ within your your other workloads, and of course not within within other customers' workloads. So that's something that ⁓ we ⁓ we've been like from the start ⁓ having as a core feature of CloudRun. And as I must say, now with agents which need to run untrusted code, we are actually gonna be leveraging that technology to offer this ⁓ sandbox feature, right? Which because for us it it's there in the system. What we need is to expose it in a different way so that your agent can can ask for a sandbox, the same way your container gets put gets wrapped around the sandbox when you deploy it. ⁓ but yeah, I think the ⁓ security ⁓ landscape is constantly evolving. ⁓ I think we've seen some pretty big ones and unfortunately that that are notably in ⁓ in the dependencies, in the language dependencies. ⁓ well. And this is where the contract with with customers that we have is ⁓ that okay, we will secure your your container. If you use one of our managed runtime, we will secure the runtime. So the Node.js version, we would we automatically Like if there is a a C V E in Node.js, if it's a severe one, in twenty-four hours it's get re it's get deployed to the CloudRun fleet. What we don't ⁓ provide is a way to what what's what's within what's above that layer. So your application code might have a vulnerability, potentially because it uses a dependency that has a vulnerability. And these is is the customer's responsibility. So just under exceptional circumstances, we we've blocked the deployment of certain dependencies. Like one of them was the React slash slash Next.js vulnerability we had not that long ago. And so for that one, we actually blocked you ⁓ if you wanted to deploy a vulnerable ⁓ version of ⁓ of React or Next.js. And also ⁓ under those exceptional circumstances, Google is sometimes looking at putting firewall rules to block the attacks once they are known, when their their patterns are known. But this is this is where security is also a shared responsibility. Security of your application is always going to be requiring ⁓ you, the customer, to pay attention to notably the top layer, like your application code, your dependencies. speaker-0: And you should be using I mean at this point, I mean, you really should be using trusted images. ⁓ speaker-1: Yeah. speaker-0: We've we've got an ecosystem, you know, whether you're, you know, working with Docker or Chain Guard, ⁓ hardened images i is absolutely best practice and you should be doing that. speaker-1: We've also added things to CloudRun like container threat detection, like which basically is ⁓ is ⁓ some kind of an agent that runs ⁓ next to your container and and watches for any ⁓ suspicious activity. So you can enable that in one checkbox in in CloudRun. ⁓ actually no, it's even centralized. It's in a Google Cloud Security Command Center, you can enable CloudRun threat detection and you will start to monitor for suspicious activities across your CloudRun workloads. a thing that we had probably more enterprise ish feature is a binary authorization where you you want to ensure that what is deployed has been signed by your CI C D pipeline and not the built on a local developer machine, right? Because you never know if this developer machine was affected. So at least if it's your CI C D pipeline and you can attest that it comes from the C I C D pipeline because you've signed it. So those are things that we've built into the platform and into CloudRun. but yeah, we we are absolutely ⁓ always ⁓ you know looking for how can we make that even ⁓ better for customers. speaker-0: Yeah, a hundred percent. ⁓ something of just I mean, I I frankly I I think it's it's it's a really interesting story. I mean, yeah, maybe maybe it's maybe this is is is is is for a follow up or something. I'd love to know about some of the the the personalities of ⁓ of Cloud Run, some of the people that that were there at the beginning, that it have been through the journey. ⁓ that's always an interesting one, you know, hearing some of the human stories ⁓ behind the engineering. ⁓ but but I think I think yeah, maybe we'll we'll we can come back to that. ⁓ couple of things. would be one, you know, you mentioned Ford. Are there any other sort of of the are there any and they they could be enterprise, they could be ⁓ you know, start, are there any other stories you can tell that you just think are really exciting? Like what are some of the the the the the things perhaps you're proudest of with Cloud Run or just some customers where you're like, wow, it's amazing what they're doing there. speaker-1: We've we've seen companies that are the ones that in the financial sector, for example, they have the obligation to be resilient to a regional outage of a of their cloud provider. In Europe, notably. This is that the they they they must be resilient to regional outage. So CloudN supports out of the box zonal redundancy. Right? So when you deploy, you deploy to a specific region. If a zone goes down of that region, as a customer you barely see it. And we repeat that exercise very often. So that your workloads can get seamlessly rescheduled on other available zones. And for us, it means we have N plus one redundancy in everything we we design and in our capacity. But those customers, they go one step beyond. They want to be resilient to the loss of a Google Cloud region. And that is where Cloudens shines. So those customers are ⁓ DZ Bank in Germany or ⁓ like Commerce Bank, ANZ plus. So basically a lot of ⁓ in the financial sector, they're really availability is is paramount. So they want to build high availability applications. And the beauty of CloudOn is that they don't need to pre provision ⁓ capacity in all of those regions. It doesn't cost them much more to spread their traffic across two regions. And when when one region has an issue, ⁓ to reroute all the traffic to a single region, or maybe even more than two, right? It doesn't cost them more to do that than to go to a single region. Because it's is of its on-demand nature. And that's ⁓ that's one big plus. So that's one example of ⁓ of change we've brought to CloudRun. We've brought multi-regional deployments. Now, still using the same simplicity, gcloud run, deploy, dash dash image, except that now you can pass dash dash regions. in the list of region. And suddenly your deployment becomes multi-regional. So they they really valued the fact that that was baked into the product, the same way you can have a multi-regional database with spanner or even storage with cloud storage. You can ha now have multi-regional compute runtime with CloudRun, and that's baked into the product. So that's ⁓ that's a use case I would like that that's a type like financial services is is a type of customer I would not have predicted would be ⁓ valuing that much CloudRound. But it turns out ⁓ a lot a lot of them are. Some others are speaker-0: Well, I mean, with the Cyber Resiliency Act, I think in Europe, even more the need for that sort of technology ⁓ is gonna be huge. The Cyber Resiliency Act, by the way, if you haven't all looked this up, please do. basically the requirements on organizations that even use software in running their businesses ⁓ are going to significantly increase vis a vis security. ⁓ you know, we've we've been speaking a bit about security the past fifteen minutes or so. ⁓ all of these things are are frankly relevant. ⁓ yeah, that that that ⁓ I I know there are some standards ⁓ the EU has that people don't like. ⁓ GDPR is is something that ⁓ certainly a lot of American firms have have a lot of bugbears about, but certainly European companies are gonna have to get very, very serious ⁓ about the resilience of the systems that they've got in place. So yeah, ⁓ I I think if you're a vendor, find out about it 'cause it's an opportunity. ⁓ if you are an enterprise user, definitely spend some time ⁓ looking ⁓ at the CRA and seeing what your legal implications are because ⁓ you may not be fully aware of them. speaker-1: We've seen a lot of adoption in the media industry where here the traffic patterns are are often can be very spiky. So we supported ⁓ like the World Cups, many World Cups, with ⁓ a company called Televisa Univision. ⁓ the BBC was has been using Clarun and they they've publicly talked about how when when the Queen passed away, you know, they they saw an in a d drastic increase. in ⁓ unpredictable increase in in some of their systems. And the systems that were built on CloudEarn absorbed that with no issue. So this is again the on demand hyperscalability of this compute runtime. Like CloudRe not only a developer product which developers love, it is also an extremely capable and scalable runtime that that that very big customers are using at scale. speaker-0: Okay. ⁓ no surprises there. ⁓ and as I say, I mean I still ⁓ if we think about where we started, ⁓ the simplicity was that was the key. ⁓ but of course now ⁓ we're we're in a slightly different ⁓ we're not we're not in Kansas anymore. So in the Wizard of Oz world of AI and like where we're going as an in industry, like what's next? What's next for Cloud Run? What are your How are you to maintain simplicity, find those new idioms? You know, obviously you can't pre announce anything exactly, but you mentioned ⁓ an announcement at I.O. which is gonna be happening now, ⁓ by the time people hear this podcast that will be public. But yeah, what what sorts of things keep you up at night about where and what you're gonna need to do with the platform going forward? speaker-1: There are really two areas. One is a runtime to host agents. And here is where you will see over the just this year many changes to CloudRun to help you deploy your agents on CloudRun. Many people are already doing it today, but we want to give them the primitives to do it even better or like a a good litmus test is can you run open cloud? Today you cannot. And within two months you will. ⁓ the second one is that to me it's the more profound change is that the who is a developer, the definition of developer, is changing. The barrier to entry used to be high, right? And now you have tools like AI Studio, which literally enables people who were not technical practitioners before. To build applications and to deploy them. So that's that's where we we feel we have like a role to play for Google and for the industry because we are a runtime that has been designed for that. Like those vibecoders, they're not going to be creating a Kubernetes cluster. Those vibecoders, they don't even like want to open the cloud console necessarily. No, 100%.studio. I invite the audience to give that a try. They vibe code an app that they might want to be only sharing with themselves or with their family or who knows, with the world, and build a business on top of it. They wanna click publish and they want that to just work. And the expectations of that audience is probably even like stricter than what developers, like for a developer, yeah, when when it took you days to build your app, it was okay if your deployment took minutes. When it's when it takes you one minute to build your app, your deployment should be instant. So that are that is a kind of investment we are doing to simplify deploying to CloudRun, to speed up deploying to CloudRun, to so that developers don't have even less things to think about. Even if the product was extremely simple, we are we want to simplify it further. speaker-0: That's perfect. Because I've got to tell you, it is that deployment, you know, you know, we talk about the Heroku lesson, you know, we talk about everything you've done. It it vi code vibe coding an app is very often it's actually the deployment is where you get hung up. That's where the the the problems emerge. ⁓ and you know, I I think the models are getting much better than this, but better at this. Obviously, platform integrations, you know, we're seeing it across the board in the industry are making it easier, but that that remains a key point. ⁓ so you're you're you're gonna have you know, you're gonna be having all of those those Google Docs users also creating apps and deploying them to Cloud Run. Is that what you're talking about? speaker-1: Yes. ⁓ no, one one sentence I say to my team is it should be as easy to build and deploy an app that it is to write and share a Google Doc. Like that's that's the bar we are aiming for. And I believe that with AI Studio and the the new publish ⁓ flow that that we are introducing at Google IO, ⁓ we've achieved we we are getting very close to that. It is extremely easy to build the application. And now it is extremely easy to publish it to a point where you don't even need a credit card. By the way, we are talking about cloud run, but your application can use a database, can authenticate users with Firebase. ⁓ we are adding Cloud SQL. that with a with a special developer edition of Cloud SQL. And you can your app can also connect to Google Docs, Google Spreadsheet, Google, Google Slide, Google Tasks. And so all of those ⁓ services help you not only ⁓ run the application but also store data and send emails and connect to the Google workspace ecosystem. And so all of these are like being ⁓ at everybody's reach through AI Studio that they can deploy. You know, a a small personal story. I I have a daughter, she she's like doing doing a spelling spelling quiz every week. And at one point she was struggling to you know to to have good grades on this. And I built her an app using AI Studio that she now uses to ⁓ to study those those spelling tests. And now she's been like ten out of ten every week and she loves it. So you see how like I would not I would not have spent the time to build that application before. I don't have much time. But with AI Studio, I in a few prompt I I ended up building what what she's not using all the time. And when she gives me feedback about something could be better, I just one prompt away to to update the application and in one button it gets redeployed and updated. So those are like I encourage everyone to think about like what what kind of personal software ⁓ would be beneficial to your daily life and and just prompt it because a at this point it is very much ⁓ the barrier to creating is is is is lower than ever. speaker-0: Amazing. I think that's a pretty good place ⁓ to to close. ⁓ but now you're making me think, ⁓ my goodness, I'm gonna have to get this edited quickly because of this Google I.O. content. It feels quite fresh. It was supposed to be about the past, present and future, ⁓ a piece that that would ⁓ stand on its on its own ⁓ for ⁓ be it slightly more longer running. But ⁓ yeah, no. Looking forward to I.O. now. ⁓ great. So Stirren, thanks so much. ⁓ Thanks to all of you ⁓ for joining us. I hope you've enjoyed this episode. I do love a bit of history. ⁓ that's one of the reasons I do what I do at Red Monk, you know, try and put things into ⁓ context in the short term and the long. So thanks all for joining us. ⁓ thanks again, Sterren. And ⁓ we will ⁓ we'll be ⁓ creating more and more hopefully great stories ⁓ in the Red Monk conversations to come. So sign up for the Monk Cast. ⁓ ⁓ you know, all those like, subscribe, that good stuff and please do share this, ⁓ 'cause I think it's a great and interesting story.